Celebrate National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17

x
?
Solved

AD Schema setting to copy security settings to new users

Posted on 2007-03-31
15
Medium Priority
?
539 Views
Last Modified: 2008-06-01
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.
0
Comment
Question by:mauisun
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 7
  • 6
  • 2
15 Comments
 
LVL 48

Expert Comment

by:Jay_Jay70
ID: 18833446
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
 
LVL 1

Author Comment

by:mauisun
ID: 18836307
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
 
LVL 51

Expert Comment

by:Netman66
ID: 18849779
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
Get your Conversational Ransomware Defense e‑book

This e-book gives you an insight into the ransomware threat and reviews the fundamentals of top-notch ransomware preparedness and recovery. To help you protect yourself and your organization. The initial infection may be inevitable, so the best protection is to be fully prepared.

 
LVL 1

Author Comment

by:mauisun
ID: 18850522
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
 
LVL 51

Expert Comment

by:Netman66
ID: 18851013
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
 
LVL 1

Author Comment

by:mauisun
ID: 18851411
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
 
LVL 51

Expert Comment

by:Netman66
ID: 18852016
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
 
LVL 1

Author Comment

by:mauisun
ID: 18852265
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
 
LVL 51

Expert Comment

by:Netman66
ID: 18852476
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
 
LVL 1

Author Comment

by:mauisun
ID: 18852574
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
 
LVL 51

Expert Comment

by:Netman66
ID: 18852865
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
 
LVL 1

Author Comment

by:mauisun
ID: 18853067
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
 
LVL 51

Accepted Solution

by:
Netman66 earned 2000 total points
ID: 18855107
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
 
LVL 48

Expert Comment

by:Jay_Jay70
ID: 18855187
Thanks for jumping in NM :)
0
 
LVL 1

Author Comment

by:mauisun
ID: 18857751
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

Featured Post

Learn Veeam advantages over legacy backup

Every day, more and more legacy backup customers switch to Veeam. Technologies designed for the client-server era cannot restore any IT service running in the hybrid cloud within seconds. Learn top Veeam advantages over legacy backup and get Veeam for the price of your renewal

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Auditing domain password hashes is a commonly overlooked but critical requirement to ensuring secure passwords practices are followed. Methods exist to extract hashes directly for a live domain however this article describes a process to extract u…
This process allows computer passwords to be managed and secured without using LAPS. This is an improvement on an existing process, enhanced to store password encrypted, instead of clear-text files within SQL
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller. Log onto the new domain controller with a user account t…
Are you ready to implement Active Directory best practices without reading 300+ pages? You're in luck. In this webinar hosted by Skyport Systems, you gain insight into Microsoft's latest comprehensive guide, with tips on the best and easiest way…

730 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question