Restricting access to custom schema attribute in AD

  • 162 Views
  • Last Post 31 August 2016
BrianB posted this 31 August 2016

I have some custom schema attributes that have been created in AD. These are specific to my company and are populated via our Identity management solution from feeds by our HR and SR departments. These attributes should have controlled access to allow only specifically  authorized users the ability to read, i.e. everyone should not have the ability to read a vuStudentDormCode attribute. Only the authorized departments like student records should have the ability to read this attribute.

  Now in our legacy system, we are using ODSEE 11G LDAP and have created ACI’s to restrict access to these attribute. But given the fact that AD allows so much to be viewed by default, I need a way to restrict the access. The goal is to allow certain security groups that are tightly controlled to access these attributes. I would like to do this at the attribute level if possible. Though I am not familiar with this process so I could be off base in wanting that method.

  I have researched a few ways to do this like using LDP and the confidentiality bit. I am a little confused about this method though and wanted to get your take on how to do this.

  Brian Britt        

Order By: Standard | Newest | Votes
SmitaCarneiro posted this 31 August 2016

These links may help:

From Brian Arkills:

https://blogs.uw.edu/barkills/2013/10/18/hiding-data-in-active-directory/

 

And some more

http://windowsitpro.com/active-directory/using-confidentiality-bit-hide-data-active-directory

 

https://technet.microsoft.com/en-us/library/cc753459(v=ws.10).aspx

 

 

We were asked to do something similar, and the above links helped. An attribute is populated and then the searchFlags bit is modified. A group was created that had read rights to this attribute, another with

read and write rights. No one else other than domain admins can view this attribute. You alos have to make sure this attribute does not replicate to RODCs.

 

Smita

show

davyp posted this 31 August 2016

Hi Brian, Each object class has a default ACL defined in the schema.
for example (Allow - authenticated users - read vuStudentDormCode - this object only) on the user class (or the class where you applied the attribute)   This default ACL is only evaluated at creation time, so if you change the default security today, it will only be applied on newly created objects and existing objects' ACLs will have to be adapted by script.   The read access that "authenticated users" have over others user objects might seem pretty broad, but this is only because the normal default ACLs on the user class are defined on property sets (collection of attributes at once)   I think adapting the permissions on the user object will do the trick... So secure the objects in the underlying database, and you don't have to do anything on the protocol level.   But test this before implementing in production of course...   Best regards, DavyP    


Van: "Brian Britt" <brian.britt@xxxxxxxxxxxxxxxx>
Aan: ActiveDir@xxxxxxxxxxxxxxxx
Verzonden: Woensdag 31 augustus 2016 15:14:33
Onderwerp: [ActiveDir] Restricting access to custom schema attribute in AD

I have some custom schema attributes that have been created in AD. These are specific to my company and are populated via our Identity management solution from feeds by our HR and SR departments. These attributes should have controlled access to allow only specifically  authorized users the ability to read, i.e. everyone should not have the ability to read a vuStudentDormCode attribute. Only the authorized departments like student records should have the ability to read this attribute.   Now in our legacy system, we are using ODSEE 11G LDAP and have created ACI’s to restrict access to these attribute. But given the fact that AD allows so much to be viewed by default, I need a way to restrict the access. The goal is to allow certain security groups that are tightly controlled to access these attributes. I would like to do this at the attribute level if possible. Though I am not familiar with this process so I could be off base in wanting that method.   I have researched a few ways to do this like using LDP and the confidentiality bit. I am a little confused about this method though and wanted to get your take on how to do this.   Brian Britt        

jeremyts posted this 31 August 2016

Yep, agreed.

 

You set the confidentiality bit in the value of the objects searchFlags property in the schema. Then you delegate a security group access to the vuStudentDormCode “confidential" attribute by giving it the "Read

Property" right and setting the "Control_Access" flag, which is what is required to get past the confidentiality bit.

 

This is how the BitLocker and TPM data is stored, using the msFVE-RecoveryPassword and msFVE-RecoveryInformation attributes as an example.

 

Also, if you are familiar with the Microsoft LAPS (Local Administrator Password Solution) tool, this is how the password is protected that’s stored in the ms-Mcs-AdmPwd attribute.

 

There is a VBScript here that will demonstrate how to delegate a security group to the attribute:

https://technet.microsoft.com/en-us/library/cc771778(WS.10).aspx

 

Hope that helps.

 

Cheers,

Jeremy

 

 

show

BrianB posted this 31 August 2016

Thank you Brian and Jeremy,

 

Awesome information. I was heading down that path but wanted to ask to be sure that it was sufficient protection for confidential attributes. One article located at



http://windowsitpro.com/active-directory/using-confidentiality-bit-hide-data-active-directory talks more about the confidentiality bit and RODC.



 

Brian Britt.

 

 

show

BrianB posted this 31 August 2016

Brian,

 

I just realized you already included that link in your response. Sorry.



 

Brian Britt

 

show

mikeward posted this 31 August 2016

Keep in mind that if you delegate ‘Replicating Directory Changes’ permissions (e.g. done for SharePoint), the delegated account(s) can view confidential bit data.

 



Mike



 

show

Close