Restricting Control Access - Write Personal Information in AD

  • 72 Views
  • Last Post 03 February 2017
BrianB posted this 02 February 2017

All:   I currently have an AD environment where the typical writeable attributes that SELF can perform is prevented so that our IDM solution (Home grown back in the day and now Purchased) can solely mange user accounts. It is windows 2008 R2 and has been upgraded over time from 2000 by introducing a NEW modern OS DC into the environment to upgrade the forest and domain and then REPLACING the remaining legacy DC’s with newly rebuilt Modern OS DC’s until all have been replaced. So no OS upgrades in any of the DC’s. As you can guess, this is an old AD environment and the documentation does not exist pertaining the what the original designers did to limit this ability. I am building a new 2012 R2 forest and we are going to move to it sometime this calendar year.   I want to continue to restrict user’s ability to modify their own attributes and am assuming that this pertains to the “Write-personal-Information” access right group. I have the ability currently to modify my address, phone number, etc. in the new environment. I cannot see any difference on the ACE’s between each forest. But, something is limiting my ability to write to those attributes in my existing forest and is by default allowing me to write to those same attributes in the new forest. A comparison of ACE using dsacls and viewing the security descriptor in LDP.exe yields no information. It seems the SELF permissions are identical in each forest. Maybe I am looking for the wrong thing. No DENY’s are present in the ACE list at the root or on the users OU.   Is there something else I should be looking at that may not be in the ACE like some sort of dsheuristics mod or account control mod or other that the originators may have done. Is there a better tool or location that I need to look at to hopefully reveal this information. Help is appreciated.     Brian Britt        

Order By: Standard | Newest | Votes
amalchev posted this 02 February 2017

Hi,
Not sure if you have read that blog post:
https://blogs.technet.microsoft.com/craigf/2013/06/23/removing-permission-for-users-to-upload-their-image-to-ad/
Best Regards,
Atanas Malchev
On Feb 2, 2017 9:59 PM, "Britt, Brian" <brian.britt@xxxxxxxxxxxxxxxx> wrote:

All:   I currently have an AD environment where the typical writeable attributes that SELF can perform is prevented so that our IDM solution (Home grown back in the day and now Purchased) can solely mange user accounts. It is windows 2008 R2 and has been upgraded over time from 2000 by introducing a NEW modern OS DC into the environment to upgrade the forest and domain and then REPLACING the remaining legacy DC’s with newly rebuilt Modern OS DC’s until all have been replaced. So no OS upgrades in any of the DC’s. As you can guess, this is an old AD environment and the documentation does not exist pertaining the what the original designers did to limit this ability. I am building a new 2012 R2 forest and we are going to move to it sometime this calendar year.   I want to continue to restrict user’s ability to modify their own attributes and am assuming that this pertains to the “Write-personal-Information” access right group. I have the ability currently to modify my address, phone number, etc. in the new environment. I cannot see any difference on the ACE’s between each forest. But, something is limiting my ability to write to those attributes in my existing forest and is by default allowing me to write to those same attributes in the new forest. A comparison of ACE using dsacls and viewing the security descriptor in LDP.exe yields no information. It seems the SELF permissions are identical in each forest. Maybe I am looking for the wrong thing. No DENY’s are present in the ACE list at the root or on the users OU.   Is there something else I should be looking at that may not be in the ACE like some sort of dsheuristics mod or account control mod or other that the originators may have done. Is there a better tool or location that I need to look at to hopefully reveal this information. Help is appreciated.     Brian Britt        

bdesmond posted this 02 February 2017

What’s in the Personal Information bucket of attributes is all stored in the schema – it’s not DC version specific. You can see which attributes have the attributeSecurityGUID

value for that property set to see what’s included.

 

 

 



Thanks,

Brian Desmond

 

w – 312.625.1438 | c – 312.731.3132



 

show

Milo posted this 02 February 2017

Hi Brian,




Are you looking at the OU level or at the leaf-object level? I would have thought the Self permission would be present on the user object itself.




Milo









show

BrianB posted this 02 February 2017

I was just using those attributes as an example of what I can write to. I want to remove the ability for SELF to write on the own account. We don’t want someone to update address or phone or any of the other

attributes included in personal-information since we have authoritative sources and IDM to manage and populate that information. My problem is that somewhere in the current forest this has been restricted and it is not obvious how it was done. I would expect

to see a DENY write-personal-information OR the absence of a default ACE. But when I compare the two forests, I cannot see a difference in ACE’s.



 

Brian

 

show

Milo posted this 02 February 2017

Hi Brian,




Have they changed the "default security descriptor" of the User class object in the schema? Compare the one in the new forest to the one in the exsiting forest.




Thanks




Milo






show

barkills posted this 02 February 2017

We haven’t modified the ability for a user to write to their own user object in our AD. However, long ago I wrote a document that clearly delineates what user attributes can be SELF written, which just happens

to tell you the source of the permission.

 

https://itconnect.uw.edu/wares/msinf/design/arch/users/self-writable-attributes/

 

Those who are familiar with how AD permissions work should be able to follow that document, but I suspect a short review would be helpful.

 

An AD object starts out life with a set of explicit permissions that are defined by the defaultSecurityDescriptor specified in the AD schema for the structural objectclass of that object. Note that because these

are explicit permissions on the object itself, you can’t use inherited deny permissions to override them (because for AD-DS, explicit allow overrides inherited deny).

 

What’s this business about a structural objectclass, you ask? Well, almost all objects have multiple classes—for example, a computer is a user and a computer, and a bunch of other classes.

The computer class is the structural class—the top (or bottom, depending on your point of view) of the chain of inherited classes. An AD object might also have optional auxiliary classes, but those auxiliary classes never supply default ACEs for an AD object.

OK, back to the main narrative.

 

The AD object is placed in a container somewhere in AD. That container will have some set of inheritable ACEs on it which apply to this new AD object.

 

One can also set explicit ACEs on the object itself.

 

When you view the ACL of any given object, you’ll see all of this, but there are lots of other details.

 

Brian mentioned property sets. And they are very much relevant to your question. There are three property sets granted SELF permissions on the user object (see my URL above). One of the property sets

has no attributes in it (one of many weird Microsoft schema mistakes), so effectively there are only two to pay attention to.

 

So … let’s put this all together.

 

To do what you want, you need to do one of two things:

1.      

Modify the ntSecurityDescriptor in the AD schema for the user class. Drop what you don’t want. Maybe add what you do want. This change will only affect new user objects after that point, so

you may need to fix (via an automated script/code) existing user objects to remove the explicit ACEs put there at object creation.

2.      

Write ACL management code which fires as part of your user provisioning process. This code would remove the undesired explicit ACEs from the schema and add desired ACEs. We do exactly this with our

group provisioning process.

 

You might even go one step further, like Stanford did and do both 1 and 2. For #1, they emptied the defaultSecurityDescriptor for users. For #2, they only add those ACEs that are needed given the user. Principle

of least privilege and maximum amount of control. J

 

It’s possible there is another option, and my memory here is shaky. You might edit the definition of the property sets to remove those attributes you don’t want. I have a vague sense that you can’t edit the Microsoft

defined property sets, but that might not be correct. If this option is possible, this might be the least amount of work, but don’t overlook the risk of a future AD schema change from Microsoft overriding your change.

 

Brian

 

show

bdesmond posted this 02 February 2017

Adam’s reply is probably where you want to look. I don’t have something to look at up in front of me, but looking at the default SD on the user class is where I’d start.



 



Thanks,

Brian Desmond

 

w – 312.625.1438 | c – 312.731.3132



 

show

BrianB posted this 03 February 2017

Great write-up Brian. I will look into this deeper tomorrow morning. Though, I cant imagine that back in 200x they took the time to go to this length. This is one of the reason why I harp on my team about D.O.C.U.M.E.N.T.A.T.I.O.N.

It would have been helpful in this case – for sure.

 

I will keep this up to date so that maybe it will help anyone else in this scenario in the future.



 

Thanks again Brian.

 

show

BrianB posted this 03 February 2017

Brian D.

 

I have looked at the root and to container where all of our users reside, comparing them across both forests. I have also looked at the user object to see what it might be inheriting. I think I will try looking

to see if the default securityDescriptor was modified in the morning. To be sure, I am bound to learn something new so no time wasted. I will update this chain once I can get some definitive answers.



 

Brian

 

show

BrianB posted this 03 February 2017

Thank you Sakari.

 

I will definitely check it out. I also wrote a script, with significant help from a script by Ashley McGlone in the technet script gallery, to pull the ACE’s for objects in AD. I ran it against the Root, specific

OU’s, and leaf objects. But it did not reveal the issue.

 

I actually followed the advice from Brian Arkills and check the securityDescriptor on the USER object in the schema, and BEHOLD! The original designers did modify the default.



 

In a default installation of AD, the USER object in the schema as the following ACE for SELF:

 

Allow     SELF       Special

Allow     SELF       Change Password

Allow     SELF       Send as

Allow     SELF       Receive as

Allow     SELF       Read/Write personal information

Allow     SELF       Read/Write Phone and mail options

Allow     SELF       Read/Write web information

 

However, the original designers removed some of the default ACE’s from the default securityDescriptor on the USER object.  

 

Thanks Brian Arkills for the lead on this. Never would have thought to look here.



 

Brian Britt

 

 

show

Close