Active Directory - schema attribute securing
Trying to come to a middle ground with admin on securing attributes in AD (Category 1 base attributes, mind you) , and explain why they shouldn't be.
For the record, I'm against putting any "sensitive information" into AD.
Basically, someone wants to put sensitive information for users into their attributes. Like mobile phone number and other attributes, etc., and they only want certain security groups to be able to see it (so a domain user couldn't just go to AD, or Powershell AD, or any other tool capable of querying a domain to retrieve values in those attributes).
The recommended solution I'm being "advised" to use by said admin, is to modify the security in ADSI: bring up properties of the attribute in Schema Configuration, and simply bring up the Properties > Security, and give "READ" access to "SELF" and "FULL" access to the respective security groups who should only view that attributes data. Or something along those lines...
From what I understand, though, is that this is dangerous and doesn't really satisfy the desire to permit/hide an attribute from certain users/groups.
My understanding is that this permission wouldn't override the explicit permission that "Authenticated Users" gets -- meaning it wouldn't inherit this security permission change of the attribute. My understand this permission would need to be re-run on every single user object in AD constantly.
It's a rare thing and a rare discussion for obviously answers, so I'm just wanting to make sure my concerns with supporting this in AD are not invalid.
Keep in mind this is for base attributes, not custom attributes. So the Confidentiality Bit flag here is not applicable, at least to all the attributes...
Someone help me make a case against this here, lol. I feel I've already made a case, but surely someone else has some wisdom on this.
Screenshot of where attribute security is in ADSI edit
For the record, I'm against putting any "sensitive information" into AD.
Basically, someone wants to put sensitive information for users into their attributes. Like mobile phone number and other attributes, etc., and they only want certain security groups to be able to see it (so a domain user couldn't just go to AD, or Powershell AD, or any other tool capable of querying a domain to retrieve values in those attributes).
The recommended solution I'm being "advised" to use by said admin, is to modify the security in ADSI: bring up properties of the attribute in Schema Configuration, and simply bring up the Properties > Security, and give "READ" access to "SELF" and "FULL" access to the respective security groups who should only view that attributes data. Or something along those lines...
From what I understand, though, is that this is dangerous and doesn't really satisfy the desire to permit/hide an attribute from certain users/groups.
My understanding is that this permission wouldn't override the explicit permission that "Authenticated Users" gets -- meaning it wouldn't inherit this security permission change of the attribute. My understand this permission would need to be re-run on every single user object in AD constantly.
It's a rare thing and a rare discussion for obviously answers, so I'm just wanting to make sure my concerns with supporting this in AD are not invalid.
Keep in mind this is for base attributes, not custom attributes. So the Confidentiality Bit flag here is not applicable, at least to all the attributes...
Someone help me make a case against this here, lol. I feel I've already made a case, but surely someone else has some wisdom on this.
Screenshot of where attribute security is in ADSI edit
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Marked answer as solution to hiding data.
ASKER
This University's article gave me a bit more wisdom about the topic, but am still looking for more.
http://blogs.uw.edu/uwwi-blog/2013/10/18/hiding-data-in-active-directory/
I'm not trying to justify using AD for sensitive information, I'm trying to find out what else could be problematic about using it to store sensitive information, because I feel like there is more "unknown" than what's been discovered by people using it and getting into problems.