AD Schema setting to copy security settings to new users

How is it possible within the AD Schema (Windows Server 2003) to use the "Attribute is copied when duplicating user" to allow one user's security permissions to be copied to new users?  In other words, which class or attribute within the AD Schema is involved with this setting?  Thanks for any help offered.
LVL 1
mauisunAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Jay_Jay70Commented:
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
0
mauisunAuthor Commented:
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.
0
Netman66Commented:
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.


0
The Ultimate Tool Kit for Technolgy Solution Provi

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy for valuable how-to assets including sample agreements, checklists, flowcharts, and more!

mauisunAuthor Commented:
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?
0
Netman66Commented:
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.

0
mauisunAuthor Commented:
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?
0
Netman66Commented:
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.

0
mauisunAuthor Commented:
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.
0
Netman66Commented:
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.

0
mauisunAuthor Commented:
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.
0
Netman66Commented:
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.

0
mauisunAuthor Commented:
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?
0
Netman66Commented:
Print Operators (in this case) are given permissions to create and delete Printer objects in that container only.  This allows them to Publish printers to the Directory in their default location - Users.

Print Operators do not have rights to user accounts, just the container - and ONLY for specific permissions.

There are certain permissions set directly on containers and/or OUs that only apply to that container and not what's in it.  

This is why it isn't inherited.

As for why your new accounts have different Groups in the Security ACL than older accounts can only be possible if a group or user has been delegated permissions to the container or a Service Pack or patch has changed functionality after some accounts had been created.

You can choose to rewrite permissions on the accounts just as you would a file- the problem is that if some things were set for a specific reason, you'll undo them.  Delegation is like that - you can't tell what was delegated to a group very easily after the wizard completes unless you record all your changes.


0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Jay_Jay70Commented:
Thanks for jumping in NM :)
0
mauisunAuthor Commented:
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.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Active Directory

From novice to tech pro — start learning today.