I am trying to allow an account to update very specific attributes on all User objects. I am setting this security on the "User" object. When I add the account on the security tab, go to advanced, edit the accounts permissions, and start going through the list of attributes I am only able to find a few, like First Name, but most of the attributes I want to let them write to are missing. How can I grant the account write access to these attributes?

Attributes I need to grant permission for:

  • First Name (givenName)
  • Last Name (sn)
  • Initials (initials)
  • Department (department)
  • Company (company)
  • Title (title)
  • Manager (manager)
  • Location Info (physicalDeliveryOfficeName, streetAddress, postOfficeBox)
  • Work Phone (telephoneNumber)
  • Pager (pager)
  • IP Phone (ipPhone)
  • IP Phone Other (otherIpPhone)
  • ThumbnailLogo (thumbnailLogo)
  • jpegPhoto (jpegPhoto)
  • Description (displayName)


  • It's much easier, safer, and probably better overall to do this via the Delegation of Control wizard. – joeqwerty Jun 16 '10 at 23:19
  • While the delegation wizard does allow you to customize access to many properties it does not show ALL of the properties we are trying to control access to. – Peter Jun 16 '10 at 23:54
  • Please note that @MadBoy has a much more thorough answer. – yougotiger May 4 '17 at 15:21

While @sysdmin1138 answer was correct it's worth mentioning that changing the scope is not the only reason why things are missing from the view. There are things that invisible by default.

Some objects such as physicalDeliveryOfficeName are hidden from view so you can't delegate them easily. A lot of other attributes are also hidden, but physicalDeliveryOfficeName is very specific and can be good example on how things works for Delegation.

The Per-Property Permissions tab for a user object that you view through Active Directory Users and Computers may not display every property of the user object. This is because the user interface for access control filters out object and property types to make the list easier to manage. While the properties of an object are defined in the schema, the list of filtered properties that are displayed is stored in the Dssec.dat file that is located in the %systemroot%\System32 folder on all domain controllers. You can edit the entries for an object in the file to display the filtered properties through the user interface.

A filtered property looks like this in the Dssec.dat file:


To display the read and write permissions for a property of an object, you can edit the filter value to display one or both of the permissions. To display both the read and write permissions for a property, change the value to zero (0):


To display only the write permission for a property, change the value to 1:


To display only the read permissions for a property, change the value to 2:


After you edit the Dssec.dat file, you must quit and restart Active Directory Users and Computers to see the properties that are no longer filtered. The file is also machine specific so changing it on one machine doesn’t update all others. It’s up to you whether you want it visible everywhere or not.

enter image description here

Full story about physicalDeliveryOfficeName and how to change it with screenshots can be read at my blog.

PS1. Since physicalDeliveryOfficeName is special case, after modifying this setting look for Read/Write Office Location. Unfortunately the name physicalDeliveryOfficeName never shows up.

PS2. Unless those settings are uncovered by modifying dssec.dat you won't be able to see them. Since this file is per computer it's entirely possible it's visible on some computers and not visible on others depending whether someone made the change earlier or not. This could explain why you could see it before and not later on.

PS3. Sorry for resurrection but just spent few hours trying to find the cause so thought I would share it for future reference.

| improve this answer | |
  • Note also to find the physicalDeliveryOfficeName under [User]. This setting is also available in [computer] and [organization] sections. – yougotiger May 4 '17 at 15:19
  • @MadBoy maybe you will answer my question: I went through your guide(Clean and Fantastic). Does manually changing properties brake any inheritance from parent OU? I am trying to limit the access on the mobile property so only two groups will be able to see it, hoping that this will create a way that when users install Exchange on their phone, the ones who have read access to mobile property will have others users personal mobile number added to their contact list. – BlooB Feb 2 '18 at 4:20
  • This has no effect on Windows 10 1803 – Arrow_Raider Jan 16 '19 at 21:26

I believe to get the full list you have to change "Apply onto" to "user" instead of "this object and all child objects". This changes the property selection dialog to include all of these.

| improve this answer | |
  • this was the first thing we tried... Most of them still did not show up. – Peter Jun 16 '10 at 23:53
  • 2
    I bet you have to also select "User" on apply-onto in the Object tab too. – sysadmin1138 Jun 17 '10 at 3:19
  • That was it, just had to pick user from the object tab as well. thanks. – Peter Jun 17 '10 at 19:58

Go to the "Advanced" ACL editor. Add the principal to whom the rights should be granted. In the "Permission for [principal name]" dialog, go to the "Properties" tab, choose "User objects" in the "Apply onto:" list, and select the properties and desired permissions from the list.

I spot-checked most of your list and I found everything I looked for there.

| improve this answer | |
  • ... I could swear this is exactly what we looked at earlier... except now I see them. I don't see Last Name/Surname, is it under a different name? – Peter Jun 17 '10 at 3:02

Not the answer you're looking for? Browse other questions tagged or ask your own question.