The ACL is modified and all of the answers for what people
can and can't do in AD is a story well told by the ACL of the object in
question.
The adminSDHolder ACL on my test domain (I don't think I
have touched it) looks like
G:\TEMP>adfind -default -f name=adminsdholder
ntsecuritydescriptor -sddl+ -resolvesids
AdFind V01.31.00cpp Joe Richards ([EMAIL PROTECTED])
March 2006
Using server: 2k3dc01.joe.com:389
Directory: Windows Server 2003
Base DN: DC=joe,DC=com
Directory: Windows Server 2003
Base DN: DC=joe,DC=com
dn:CN=AdminSDHolder,CN=System,DC=joe,DC=com
>nTSecurityDescriptor: [OWNER] JOE\Domain Admins
>nTSecurityDescriptor: [GROUP] JOE\Domain Admins
>nTSecurityDescriptor: [DACL] PAI
>nTSecurityDescriptor: [DACL] OA;;RPWP;userCertificate;;JOE\Cert Publishers
>nTSecurityDescriptor: [DACL] OA;CI;RPWP;displayName;;JOE\Exchange Enterprise Servers
>nTSecurityDescriptor: [DACL] OA;CI;RPWP;Public Information;;JOE\Exchange Enterprise Servers
>nTSecurityDescriptor: [DACL] OA;CI;RPWP;Personal Information;;JOE\Exchange Enterprise Servers
>nTSecurityDescriptor: [DACL] OA;;RP;tokenGroupsGlobalAndUniversal;;BUILTIN\Windows Authorization Access Group
>nTSecurityDescriptor: [DACL] OA;;RPWP;terminalServer;;BUILTIN\Terminal Server License Servers
>nTSecurityDescriptor: [DACL] OA;;CR;Change Password;;Everyone
>nTSecurityDescriptor: [DACL] OA;;CR;Change Password;;NT AUTHORITY\SELF
>nTSecurityDescriptor: [DACL] A;;CCDCLCSWRPWPLOCRRCWDWO;;;JOE\Domain Admins
>nTSecurityDescriptor: [DACL] A;;CCDCLCSWRPWPLOCRRCWDWO;;;JOE\Enterprise Admins
>nTSecurityDescriptor: [DACL] A;CI;LC;;;JOE\Exchange Enterprise Servers
>nTSecurityDescriptor: [DACL] A;;LCRPLORC;;;BUILTIN\Pre-Windows 2000 Compatible Access
>nTSecurityDescriptor: [DACL] A;;CCDCLCSWRPWPLOCRSDRCWDWO;;;BUILTIN\Administrators
>nTSecurityDescriptor: [DACL] A;;LCRPLORC;;;NT AUTHORITY\Authenticated Users
>nTSecurityDescriptor: [DACL] A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;NT AUTHORITY\SYSTEM
>nTSecurityDescriptor: [SACL] AI
>nTSecurityDescriptor: [SACL] AU;SA;WPEveryoneWO;;;WD
>nTSecurityDescriptor: [SACL] OU;CIIOIDSA;WP;gPLink;organizationalUnit;Everyone
>nTSecurityDescriptor: [SACL] OU;CIIOIDSA;WP;gPOptions;organizationalUnit;Everyone
>nTSecurityDescriptor: [OWNER] JOE\Domain Admins
>nTSecurityDescriptor: [GROUP] JOE\Domain Admins
>nTSecurityDescriptor: [DACL] PAI
>nTSecurityDescriptor: [DACL] OA;;RPWP;userCertificate;;JOE\Cert Publishers
>nTSecurityDescriptor: [DACL] OA;CI;RPWP;displayName;;JOE\Exchange Enterprise Servers
>nTSecurityDescriptor: [DACL] OA;CI;RPWP;Public Information;;JOE\Exchange Enterprise Servers
>nTSecurityDescriptor: [DACL] OA;CI;RPWP;Personal Information;;JOE\Exchange Enterprise Servers
>nTSecurityDescriptor: [DACL] OA;;RP;tokenGroupsGlobalAndUniversal;;BUILTIN\Windows Authorization Access Group
>nTSecurityDescriptor: [DACL] OA;;RPWP;terminalServer;;BUILTIN\Terminal Server License Servers
>nTSecurityDescriptor: [DACL] OA;;CR;Change Password;;Everyone
>nTSecurityDescriptor: [DACL] OA;;CR;Change Password;;NT AUTHORITY\SELF
>nTSecurityDescriptor: [DACL] A;;CCDCLCSWRPWPLOCRRCWDWO;;;JOE\Domain Admins
>nTSecurityDescriptor: [DACL] A;;CCDCLCSWRPWPLOCRRCWDWO;;;JOE\Enterprise Admins
>nTSecurityDescriptor: [DACL] A;CI;LC;;;JOE\Exchange Enterprise Servers
>nTSecurityDescriptor: [DACL] A;;LCRPLORC;;;BUILTIN\Pre-Windows 2000 Compatible Access
>nTSecurityDescriptor: [DACL] A;;CCDCLCSWRPWPLOCRSDRCWDWO;;;BUILTIN\Administrators
>nTSecurityDescriptor: [DACL] A;;LCRPLORC;;;NT AUTHORITY\Authenticated Users
>nTSecurityDescriptor: [DACL] A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;NT AUTHORITY\SYSTEM
>nTSecurityDescriptor: [SACL] AI
>nTSecurityDescriptor: [SACL] AU;SA;WPEveryoneWO;;;WD
>nTSecurityDescriptor: [SACL] OU;CIIOIDSA;WP;gPLink;organizationalUnit;Everyone
>nTSecurityDescriptor: [SACL] OU;CIIOIDSA;WP;gPOptions;organizationalUnit;Everyone
1 Objects returned
I see no mention of Account Operators in there so Acc Ops
aren't granted anything explicitly though they will pick up all of the bolded
items for obvious reasons.
I see one mention of NT AUTHORITY\SELF and that is very
simply OA;;CR;Change Password;;NT AUTHORITY\SELF which means
Object Access Allowed to SELF for Control
Access of the extended right called "Change Password"
This means SELF can change the password assuming SELF knows
the old password. It is actually redundant because Everyone has the same
permission and you would assume that SELF would be considered part of Everyone.
You also have some basic access rights granted to Pre-W2K
and Auth Users. List Contents, Read Property, List Object, and Read Permissions.
Nothing too exciting there either. Certainly nothing writing hope
about...
Finally as for your EA/DA question, you will note that
Domain and Enterprise Admins have a little more granted to them, I will let
folks work through what that is (good to learn SDDL decoding) or use DSACLS to
go look at the adminSDHolder ACL. The WP is the key though... Also you will note
that Domain Admins have an ace in the hole as well, check out the line that has
[OWNER] in it...
joe
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Kern
Sent: Friday, April 28, 2006 3:59 PM
To: [email protected]
Subject: Re: [ActiveDir] unable to modify personal info
Points taken.
Thanks
Just one rehash-
Due to the adminSDHolder, account operators cannot modify other account
operators.
But why should this be true as well for modifying their own
properties?
Why shouldn't an account op change his/her phone # or address or
displayname etc?
Is it just due to the nature of the adminSDHolder that once you
prevent account op's from modifying other account ops, that same process stops
them from modifying themselves?
Then shouldn't this also affect DA's or EA's too?
Thanks
On 4/27/06, joe
<[EMAIL PROTECTED]>
wrote:
> I have an admin who is an Account Operator but can't modify his own account info like address or phone number.Yes, that is correct.> Does anyone have any ideas?Glad you asked...1. You really shouldn't use builtin accounts. Your account op could one day decide to become an enterprise admin and I have fear you would not be able to stop him.2. Use account provisioning systems and don't give people rights in the directory directly.3. Barring 2, use delegated accounts, not accounts in built in groups, you will find this to be similar to #14. If you must give users rights in the directory, do yourself a favor and make them use different accounts for admin work and normal every day things like EMAIL. Someone just may send your company a nice email with a script that deletes all users and groups and your acc op buddy if reading email with their acc op account would help you test your entire DR scenario. As a quick hint, when I was the lead admin doing work for a Fortune 5 Widget factory's Global Forest with some 250,000 users I rarely logged in interactively with my DA or EA IDs (like maybe once per week to a DC) and I used the DA or EA IDs through RUNAS/CPAU maybe 2 hours tops out of a 10-12 hour day. The enhanced permission IDs do not need phone numbers and addresses configured on them. You could follow the standard I have followed for about 10 years with separation of admin level and normal IDs and name the admin ID the same as the normal ID with a prepended $. And yes, I said 10 years, I started doing this way back on NT where it also worked perfectly fine. I would say over the course of that time fully 95% of my troubleshooting has all been done from a normal level user ID.
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Tom Kern
Sent: Thursday, April 27, 2006 4:58 PM
To: activedirectory
Subject: [ActiveDir] unable to modify personal info
I have an admin who is an Account Operator but can't modify his own account info like address or phone number.I know via the adminSDHolder, account ops can't modify other account ops but this user should be able to modifiy his own account.There is no entry for Self in the ACL editor for his user object.Does anyone have any ideas?Thanks
