Hi,

at a customer site there is a multidomain forest, one Schema master, sure :-).

The Default Security Permissions for the classschema object "user" is not an option.
In the Default Security Permission there are Domain-Admins and so on.
The Multi Domain Forest contains a lot of companies and is managed by an external Service Provider.
If we create new User Objects and Organizational Units for the datacenter,
every object is in full rights by the external Service Provider and we have to correct this.

For 30 000 Users and a lot of changes, also no Option.

I Know how to create a new classschema, but how can i add a new user in the domain

of the subforest that uses the new created class?
Got same subclass but commands like dsadd do not accept a classschema that i defined.

Is it possible to modifiy the dsadd function?

Got test Environment, so dont hesitate to give me a hint.
I cannot find anything in mcse documentations, Internet and Tools like adsiedit do not have this Option...

Thanks for ideas!

Bye Mathias Rhn

• Edited by Mathias Rühn Thursday, September 10, 2015 6:32 PM corrected questions

I am not sure I understand the scenario.

You modified the defaultSecurityDescriptor of the user and OU class and added delegation for the service provider? Or don't want to do it? Not sure why you bring this one up... Or have you created a delegation on your domain for them? And wish to update it?

If you don't want the external provider to have right on your environment remove them from the domain admins group. Every security modification you will do on your domain can be undone by the external provider if you don't take them off the domain admins group (and maybe more groups since you mentioned "and so on"... so maybe other highly privileged groups as well).

Hi,

no, thats not the case.

We cannot Change Domain admin or forest Schema Memberships,

but we got a secure Environment with a new datacenter.

we do not want to delegate permissions.

what we want to do is

- creating a new user classschema and create new accounts with this Schema.

- modify the corresponding classschema for every existing user object to the new user classschema

- extending also to organizational Units and Groups, if we introduced secure objects with user accounts...

the new security behaviour is for our Domain in the forest.
The other organizations will still use the standard user/ou/group classchema...

So lets make it easier.
If we create new objects for users, Group and ous we want to create a resticted security permission on the objects.

In Standard Microsoft ADS, if we modify the security permissions on the object, they come back after some replication time with the Schema master...

In actual Environment there are to much People in Domain admin Group, and we cannot Change this with the implementation of a central datacenter.

So i still know what to do, but if i have to use the new class, there is a Problem.

the commandlet dsadd only accepts Computer or user and so on, redirecting to the corresponding classschema.
But lets say i want to use the commandlet dsadd Company-user with my new objectclass,
it will not be accepted.

How can i create new objects with newly created classschemas in one Domain?

Modifiy the dsadd function?
Or is there another way?

Hope this helps you in understanding.

Mathias

The behavior you are describing is not related to the defaultSecurityDescriptor attribute (this one is just effective at the time of the creation on the object and is not retro active). What you see is due to adminSDHolder protection. More info here: AdminSDHolder, Protected Groups and SDPROP. In a nutshell, if a user is a member of a protected group (such as Domain Admins, Schema Admins etc.. cf article I mentioned), all custom delegation will be reset once the adminSDHolder protective task run (by default every hour on the ePDC).

Even though you can create your own class of objects, you won't be able to use those custom object to actually open a session. Besides, this is not the way to address delegation issue.

The point is, and this is especially true is like yo mentioned security matters, nobody but the actual individuals managing the domain should be a member of the domain admins groups. Enterprise and Schema admins could even be empty and you can add account to it only when an infrastructure operation requires it.

I know it is not quite appealing, but before going further in your plans, please read the following document: Best Practices for Securing Active Directory. It is really worth reading, very good use of your time, definitely.