I recently had the pleasure to help one of our Premier customers with a query they have regarding saving images in Active Directory.
By default, users have permission to save a jpeg or bmp file to their own AD user account. This file can be up to 100KB in size. In a large AD with hundreds of thousands of users, this could quickly increase the size of the AD database. The increase in size can increase backup times, increase the backup size and slow down restores.
This permission is granted via the constructed security principal, “SELF”.
“SELF” is given permission to a set of attributes, not to the individual attributes themselves. By combining attributes into groups of common attributes, you reduce the size of the ACL entry. These groups are called Permission Sets. The attributes which relate to images are:
The attribute Picture is in a Permission Set called Personal-Information. You can see the permission is applied to all users like this:
They wanted to take away the permission for SELF to be able to write to the Picture attribute, but this shouldn’t be a high-level deny for Everyone to write to this attribute. It could be that some users somewhere at sometime need to write to this attribute.
What I suggested they do was de-couple the Picture attribute from the Property-Set called Personal-Information. Then apply an explicit permission to the root of the domain for a group which has write access to this attribute instead.
But how do you link (and therefore unlink) an attribute to a Property-Set?
The property sets are not found in the schema, but instead are found in the Configuration partition, under Extended-Rights.
Each of the Property Sets has an attribute identifying it, called rightsGuid. This GUID is used to pull in attributes as members of the property set by specifying the same GUID in the attribute of the attribute called attributeSecurityGUID. If these 2 GUIDs are the same, then the attribute will be a member of the Property Set. By removing the attributeSecurityGUID entry on the Picture attribute, it is no longer a member of the Personal-Information Property Set. And the SELF will lose permission to write to this attribute.
While this sounds very complicated, here’s a simple picture to explain it all:
The object on the left “CN=Personal-Information” is the property set. The object on the right “CN=Picture” is the attribute in the schema. It’s lDAPDisplayName is thumbnailPhoto. The attributes of these objects, rightsGuid and attributeSecurityGUID have the same value, a matching GUID.
When you remove the attributeSecurityGUID, open the attribute and click the button on the bottom left called “Clear”, as shown below:
Notice also that the text in the attribute editor isn’t the same as the text you see in the window behind. The characters appear as pairs and the pairs in the blocks have been switched around.
In order to restore the GUID if you change your mind, you need to copy the same form of the GUID from another attribute. I chose Post-Code as this is also in the Personal Information Permission Set.
I hope this helps someone else to delegate their Active Directory if needed.
Thanks, that worked perfectly.
Hi, I've cleared the attributeSecurityGUID from CN=Picture under Schema. However, I'm still able to change my photo in Outlook 2013 (we're using Office 365 for our mailboxes). Is there something else that I may have missed out? I've waited for several
days for any replication that needs to take place and its been weeks since the change but I can still change my photo. Any advice would be much appreciated. Thanks.
@Terrence: Your photo is being stored in the AD that is used by the hosted Exchange server of Office 365, not your corporate AD. You can't modify the Office 365 AD schema or attributes. Although you don't need to. If the Office 365 AD is happy to host
your photos, then let them - there is no downside for you by letting them do that. You don't pay for the amount of data stored in AD and aren't concerned about the size of their database or how long it takes to restore. Enjoy the service!
First of all thanks for your detailed description for this.
Unfortunately, after this change, limited users already have access to change their Picture using OWA in Internal AD Schema not Office 365. Also as I checked and using this method to make another restrictions, end users still can change their Location and Phones
using OWA or such other mail clients. Would you please let me know how can make these restrictions?
@Babak - I'm not sure about the mechanism used by OWA to impersonate users. Blog forums are not good places to troubleshoot problems. Try raising a Premier Support case and someone will be able to work with you to resolve your issue.