joeware - never stop exploring... :)

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=loc

Adding 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