AD Schema setting to copy security settings to new users

mauisun,

I am a little bit lost...maybe if you can clarify in what you are trying to acheive we can work this out a bit easier? When a user is copied, there is a whole load of attributes that are copied...

Regards,

James

Thanks for your reply.  Within AD, first you need to show the advanced features.  Then, you will see a Security tab when you look at the properties of any user.  This Security tab is the info that I would like copied when I want to perform a copy of an existing user to create another user.  The copy feature does not make an exact copy of the security settings when creating a new user, so that is why I am inquiring about making a change to the AD Schema.  I know that setting up OUs would probably be the best solution, but I am working with an AD that has already been created.  I hope that this makes sense.

The Security Settings on the OBJECT in AD are mostly inherited from the Parent structure.

As long as you copy the object to the same OU then it should remain identical.

If you copy it somewhere else, the it will change.  This is by design.

If you need people to have rights over objects, then Delegate those rights on whatever container(s) they need them.

Can you explain why you need this?  There may be alternate ideas if we know what you're trying to do.

I do understand that the rights are inherited from the parent, but here is a quick example.  We have all of our users in the Users OU.  While I know this may not be an ideal setup, that is how it currently is and I am not the Network Admin.  Let's say that a new user in Accounting will be starting.  So, what I do is copy another user from the Accounting department that has permissions that are in addition to what the parent has placed on them.  When I copy the Accounting user, the parent permissions exist but the specific Accounting permissions do not.  What am I missing here?

Are you attempting to make sure the new user belongs to the same Security Groups as the user you are copying?

The entries on the Security tab of the user account are ACEs for the object, not any specific groups the user may belong to - these are completely unrelated things.

If you copy a user that is already a member of (let's say) Accounting then that new user is already a member of the same groups that the original user belongs to.

OK, I just tried it again.  Here is what happens.  The original Accounting user is in the Users container.  I copy a user from Accounting into the same Users container and then compare the security users/groups associated with the original account and the newly created account.  The new account has additional entries that the original does not: Account Operators, Cert Publishers, RAS and IAS Servers, SELF, Terminal Server License Servers, and Windows Authorization Access Group.  Both accounts are set to inherit permissions from the parent, but the parent has a group (Print Operators) that neither the old or new Accounting user shows.  The parent is the Users container, correct?  Is it possible that the permissions of the parent have changed since the original Accounting user was created?  Are inherited permissions static or dynamic?

Ok, let's take this one step at a time.

The Users container is NOT an OU.  This means you can't delegate it.

Which entries are different on the new user?  Just let me know what they are - don't post the entries that are identical.

It is possible that some permissions changed due to Service Packs or patches - this isn't anything to concern yourself with.  Of course, someone may have changed them after the original users were created OR the original users were migrated from another domain.

Either way, unless you have specific issues with these Objects then the defaults are perfectly fine.

The entries that I posted above ARE the ones that are different.  If I understand your comments correctly, then I must assume that inherited permissions are static in that they do not automatically update when a parent changes.  Is this a correct assumption?  If having these extra defaults is not a problem, then I guess that my question has been answered.  I will assume that EXACT copies of security settings are not possible unless you are aware of an AD Schema change that would allow for this.

No, objects in AD act similar to files in the file system.  When you drop a file into a new folder, it inherits the permissions of the parent (if set).

The permissions you are looking at are Directory Object permissions and only affect what can (or cannot) be done to the object and by whom.

If you can manage them as expected then I would consider this a non-issue.

Thanks for clearing much of this up for me.  Your example of dragging a file into a folder with permissions makes sense, but I guess that I was under the impression that changes to the parent would automatically propagate down.  I guess that is not the case unless you manually copy down the permissions.  If my understanding of this issue sounds correct, I will consider this issue closed.  There were not really any problems caused by this issue, I just could not figure out why the differences in security settings existed when performing what I thought was an exact copy of all user attributes.

If you right click a user in that container and select Properties, then select the Security tab - press the Advanced button.

There you should see a checkbox for Inheritance AND a button to reset the Default permissions.

I would advise against setting the Defaults on a production user, however, if you want to see what the differences are then create a test user and try it.

Some of the permissions you see come from Delegation while others are on the object by default.

OK.  If you could just explain why, for example, Print Operators (security) from the Users container does not carry down to a new user in the Users container that has inheritable permissions checked I can put this one to rest.  I just do not understand what blocks certain security objects from carrying over when copying a user or creating a new one.  I understand that permissions can come from delegation or default, but why the Print Operators group excluded on a new user if the Users container has it applied?

Thanks for jumping in NM :)

Thank you very much, Netman66.  This is the answer I was looking for:
"There are certain permissions set directly on containers and/or OUs that only apply to that container and not what's in it."
Thank you for taking so much time to work through this with me.