2

I know that some attributes in AD are classified as personal information and some are classified as public information (see the "property set" column here - http://www.kouti.com/tables/userattributes.htm).

My question is, how do I use that information to hide those attributes when users are logged in from a particular computer. I'm thinking this would be a great extra layer of protection against data leakage if you were planning to put a computer in a public area. If the machine got compromised this should limit the amount of data that can dumped from AD.

I don't want to restrict access to these attributes based on the user account, I only want to restrict access to attributes classified as "personal information" from a particular computer.

Sapg
  • 21
  • 1
  • 2

2 Answers2

1

If a user currently has access to read those attributes and you want to prevent them from reading those attributes only in certain locations, then about the only thing I can think that might do the trick is a RODC with FAS (Filtered Attribute Set).

http://technet.microsoft.com/en-us/library/cc753459%28v=ws.10%29.aspx

What you would do is setup a read only domain controller and have those public machines only point to that DC. Then you can extend the default Filtered Attribute Set to include the attributes you wish to hide (mark as confidential). This would prevent those attributes from being readable on the RODC.

This is actually listed as one of the benefits of a RODC.

http://technet.microsoft.com/en-us/library/cc770320%28v=ws.10%29.aspx

There might be other ways but I'm not really sure, I'm just the new guy here.

New Guy
  • 356
  • 2
  • 5
  • 13
  • +1 for thinking outside the box. However, I don't think this would work because authenticated users can still READ those attributes with an AD query that will be passed on to a DC that holds those attributes...this is more for preventing those objects from being replicated/stored on the RODC from what I understand reading the first link. But I've never used this functionality, so you may be on to something... – TheCleaner Dec 05 '14 at 15:32
  • ...From the first link: `"See the note: "In general, if an authenticated user requests READ_PROPERTY permissions for an attribute or for its property set, read access is granted. Default security in AD DS is set so that authenticated users have read access to all attributes."` – TheCleaner Dec 05 '14 at 15:33
  • @TheCleaner Indeed, I read that note as well but took it to mean that "in general" that is the behavior, so to change that behavior you need to make the change that immediately precedes the note you mentioned. Rereading the section above that note it does say, `Mark the attributes as confidential, which removes the ability to read the data for members of the Authenticated Users group`. I have never used this feature either so you could be right as well, I don't know. – New Guy Dec 05 '14 at 15:58
  • @TheCleaner One other thing to point out, is this feature is definitely not intended to be used this way. It's primary purpose is to prevent a scenario where a DC with poor physical security is stolen. In which case you could find a way to read all the attributes in the domain directly off the locally stored copy of AD. – New Guy Dec 05 '14 at 16:04
  • Correct...knew that part...wasn't sure if it would work to alleviate the OPs issue or not was my point. Maybe it does...I've never tried...but that Note field keeps me suspicious. – TheCleaner Dec 05 '14 at 16:11
1

You'd have to restrict it based on user account, that's the account object that would be "reading" this info based on the property set "Personal Information" not the computer object.

If you are wanting to limit a computer's exposure to AD's info, based on your "put it in a public area" then you are better off leaving the computer not joined to the domain and using local authentication on it instead. It could still access corporate resources with RUNAS or RemoteApps or something similar that gives that computer access to the resources it needs.

TheCleaner
  • 32,627
  • 26
  • 132
  • 191
  • Or have the kiosk autologin with a "guest"-type domain account that has Deny rights on those AD fields. – mfinni Dec 05 '14 at 15:48
  • True @mfinni but since the OP talks about "I don't want to restrict access to these attributes based on the user account" it's an either/or scenario. – TheCleaner Dec 05 '14 at 15:52
  • Yup, my suggestion would require a modification or clarification of their requirements – mfinni Dec 05 '14 at 17:31