This one isn’t from my personal inbox but from a thread on ActiveDir Org a little while ago. I wanted to post it to the blog as well because I actually think I get a little wider audience here and this blog seems to be popular with the search engines and this is good info to share with folks because they truly are pretty common questions.
The original post:
Hi,
We have the UNIX attibs added in your AD with uidNumber and gidNumber etc. One part of our file storage uses UNIX rights (with gidNumber). The goal is to transfer the group definitions from the file storage into the AD, but I have a concern.
We delegate rights to create groups on various places (every department have their own OU where they can create groups and other objects). If we have a group with a certain gidNumber centrally, what stops a creative admin to create another group (with a different name), but with the same gidNumber and then access the UNIX share?
I can think of two solutions on this problem:
1. Is it possible to modify the attribute to only allow unique values?
2. Is it possible to add ACL:s to the attribute (in the schema) so only a service account have write access?
Thank you
Here is my response to the post…
1. No. The OS does not have that functionality available to enable/disable for attributes, would be nice though. 😉 The MSFT answer here is that all of your provisioning should be handled through a provisioning tool such as FIM which allows you to configure business rules such as this.
2. No. If you give someone the ability to create groups, it is entirely up to them what the ACL will be on that object when they create it or even after they create it if you allow default creator/owner functionality. The defaultSecurityDescriptor in the Schema is *only* used when a security descriptor is not specified in the object create. Granted this is the default most of the time, but if someone is looking to side step you, it is less than trivial to do so if you have granted CREATE rights.
For an example of #2…
This first request creates a group using the default security descriptor (because I didn’t specify one)
C:\>admod -default -rb cn=group1,ou=defaultsdtest -add objectclass::group
AdMod V01.12.00cpp Joe Richards (joe@joeware.net) February 2010
DN Count: 1
Using server: TEST-DC1.test.loc:389
Directory: Windows Server 2003
Base DN: cn=group1,ou=defaultsdtest,DC=test,DC=locAdding specified objects…
DN: cn=group1,ou=defaultsdtest,DC=test,DC=loc…The command completed successfully
This second request creates a group using the security descriptor I want
C:\>admod -default -rb cn=group2,ou=defaultsdtest -add objectclass::group SD##ntsecuritydescriptor::D:P(A;;GA;;;WD)
AdMod V01.12.00cpp Joe Richards (joe@joeware.net) February 2010
DN Count: 1
Using server: TEST-DC1.test.loc:389
Directory: Windows Server 2003
Base DN: cn=group2,ou=defaultsdtest,DC=test,DC=loc
Adding specified objects…
DN: cn=group2,ou=defaultsdtest,DC=test,DC=loc…
The command completed successfully
And here is what AD has for the ACL for group1
C:\>dsacls cn=group1,ou=defaultsdtest,DC=test,DC=loc
Access list:
Effective Permissions on this object are:
Allow TEST\Domain Admins FULL CONTROL
Allow BUILTIN\Account Operators FULL CONTROL
Allow NT AUTHORITY\SELF SPECIAL ACCESS
READ PERMISSONS
LIST CONTENTS
READ PROPERTY
LIST OBJECT
Allow NT AUTHORITY\Authenticated Users SPECIAL ACCESS
READ PERMISSONS
LIST CONTENTS
READ PROPERTY
LIST OBJECT
Allow NT AUTHORITY\SYSTEM FULL CONTROL
Allow BUILTIN\Pre-Windows 2000 Compatible Access SPECIAL ACCESS <Inherited from parent>
READ PERMISSONS
LIST CONTENTS
READ PROPERTY
LIST OBJECT
Allow TEST\Enterprise Admins FULL CONTROL <Inherited from parent>
Allow BUILTIN\Pre-Windows 2000 Compatible Access SPECIAL ACCESS <Inherited from parent>
LIST CONTENTS
Allow BUILTIN\Administrators SPECIAL ACCESS <Inherited from parent>
DELETE
READ PERMISSONS
WRITE PERMISSIONS
CHANGE OWNERSHIP
CREATE CHILD
LIST CONTENTS
WRITE SELF
WRITE PROPERTY
READ PROPERTY
LIST OBJECT
CONTROL ACCESS
Allow BUILTIN\Windows Authorization Access Group SPECIAL ACCESS for tokenGroupsGlobalAndUniversal
READ PROPERTY
Allow NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS SPECIAL ACCESS for tokenGroups <Inherited from parent>
READ PROPERTY
Allow NT AUTHORITY\Authenticated Users Send To
Permissions inherited to subobjects are:
Inherited to all subobjects
Allow TEST\Enterprise Admins FULL CONTROL <Inherited from parent>
Allow BUILTIN\Pre-Windows 2000 Compatible Access SPECIAL ACCESS <Inherited from parent>
LIST CONTENTS
Allow BUILTIN\Administrators SPECIAL ACCESS <Inherited from parent>
DELETE
READ PERMISSONS
WRITE PERMISSIONS
CHANGE OWNERSHIP
CREATE CHILD
LIST CONTENTS
WRITE SELF
WRITE PROPERTY
READ PROPERTY
LIST OBJECT
CONTROL ACCESS
Inherited to user
Allow BUILTIN\Pre-Windows 2000 Compatible Access SPECIAL ACCESS <Inherited from parent>
READ PERMISSONS
LIST CONTENTS
READ PROPERTY
LIST OBJECT
Inherited to inetOrgPerson
Allow BUILTIN\Pre-Windows 2000 Compatible Access SPECIAL ACCESS <Inherited from parent>
READ PERMISSONS
LIST CONTENTS
READ PROPERTY
LIST OBJECT
Inherited to user
Allow NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS SPECIAL ACCESS for tokenGroups <Inherited from parent>
READ PROPERTY
Inherited to computer
Allow NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS SPECIAL ACCESS for tokenGroups <Inherited from parent>
READ PROPERTY
The command completed successfully
And here is the ACL that AD has for group2.
C:\>dsacls cn=group2,ou=defaultsdtest,DC=test,DC=loc
Access list:
{This object is protected from inheriting permissions from the parent}
Effective Permissions on this object are:
Allow Everyone FULL CONTROL
The command completed successfully
As you can see I effectively killed the inheritance for any permissions flowing down from above and I have taken the defaultSecurityDescriptor out of the picture.
A quick comment on Brian’s response too. He mentioned
2: Yes and no. You could restrict the ability to write to gidNumber on objects of group class, however, if you’ve given the ability to create objects of the group class to anyone, or full control of groups, then they can circumvent that ACL. Explicit Allow ACEs trump inherited Deny ACEs in AD. And object owners (by default whoever creates an object) have full control.
Assuming the defaultSecurityDescriptor was used to add the DENY modify of gidNumber, it would be applied as an explicit DENY and therefore override the creator’s explicit FC for the object. However, as mentioned above, the defaultSecurityDescriptor is moot. But also… if the creator has FC applied, even with an explicit DENY, they will just modify the ACL on the object to remove the explicit DENY and voila, they are in the game yet again.
BTW, another fun point here… Some people try to circumvent this security issue by having an agent constantly monitoring ACLs and “correcting” the “bad” ones when found. This can also be beaten, once the person finds out what the security context of the agent is running in (assuming not localsystem on DCs as that is discouraged as a best practice right?), you just set up the DACL that you lay down on the object to deny FC for that object and then the agent has no power over the object if it even sees it at all (it won’t be returned in queries right?). Maybe it will flag an error, maybe it won’t, depending on how well it was written. Maybe the flagged error will be looked at by an administrator, maybe it won’t, depending on how well that process is being managed/supported.
As Brian indicated, the proper way to handle this is to not allow people to create groups natively. Provisioning as a general statement should be done through a gatekeeper system, either a team that is responsible strictly for provisioning or a tool that does it. Giving random folks ability to create objects in AD is in general a bad idea. It should be a team or person that is dedicated to that function and on the hook to know and follow the rules.
joe
So you have to set a minimum bar and the bar is set via the DFL and FFL requirements. You want the whole domain or the whole forest to be at that required level because you want consistency. Say you only have fine grained password policy working on 1/3 of your domain controllers, how much fun would that be for your users? Not much at all if I can hazard a guess. You would need to know what the OS of your DC is before you could know properly what kind of password you might be able to use or whether you will lock out or not for some given bad number of attempts. Or from a replication standpoint, if 1/4 of your DCs know about LVR but the other 3/4’s don’t, that would be a pain in the butt to deal with even if MSFT said, we will waste the time to write the code to make this work for you by sending the whole group membership to those 3/4 that don’t know LVR. 
