Every object class definition in the Active Directory schema has the option to define a “defaultSecurityDescriptor” value which holds the initial ACL that will apply to any new instances of that object when they are created. This rule doesn’t hold true if you specify a security descriptor explicitly when creating an object, however, as in this case the defaultSecurityDescriptor will be ignored.
The default value for the defaultSecurityDescriptor for the user class has a couple of entries in it which most administrators don’t know about, and fortunately neither do many end users. Out of the box, the user which an object in AD represents has the permissions to modify quite a few attributes on their own account. Anyone who can figure out how to make an LDAP call against their object in the directory or can use the Active Directory Users and Computers snap-in can take advantage of this. The easiest way to edit or view the value for this attribute is using the Active Directory Schema MMC.
By default the Active Directory Schema MMC snap-in is not available on a domain controller or any member server or client computer with the RSAT tools installed. To use it you must first register the COM DLL it depends on by running “regsvr32 schmmgmt.dll” from an elevated command prompt. Once you have done this, you will be able to open a new MMC and go to File->Add/Remove Snap-ins and add the Active Directory Schema snap-in to your console.
Browse to the Classes folder and then open the properties of the user class. Switch to the Default Security tab and click Advanced.
If you sort the list on the Name column and scroll down to SELF, you’ll see three entries (highlighted in red below) which are interesting for this article:
The default value for the defaultSecurityDescriptor for the user class has a couple of entries in it which most administrators don’t know about, and fortunately neither do many end users. Out of the box, the user which an object in AD represents has the permissions to modify quite a few attributes on their own account. Anyone who can figure out how to make an LDAP call against their object in the directory or can use the Active Directory Users and Computers snap-in can take advantage of this. The easiest way to edit or view the value for this attribute is using the Active Directory Schema MMC.
By default the Active Directory Schema MMC snap-in is not available on a domain controller or any member server or client computer with the RSAT tools installed. To use it you must first register the COM DLL it depends on by running “regsvr32 schmmgmt.dll” from an elevated command prompt. Once you have done this, you will be able to open a new MMC and go to File->Add/Remove Snap-ins and add the Active Directory Schema snap-in to your console.
Browse to the Classes folder and then open the properties of the user class. Switch to the Default Security tab and click Advanced.
If you sort the list on the Name column and scroll down to SELF, you’ll see three entries (highlighted in red below) which are interesting for this article:
These three ACEs grant the user permissions to write to the attributes in those three property sets for their account. (personal information, phone and mail options and web information) If you’re not familiar with Property Sets, they’re a construct that allows you to group attributes and apply security for all the attributes in a single ACE which applies to the property set. An easy way to get a nice list of the attributes in these property sets is with the tool adfind. You can download adfind on the following webpage http://www.joeware.net/freetools/tools/adfind/index.htm. Now that we’ve got adfind we need to convert the friendly display name (e.g. Personal Information) into the GUID of the property set. We need to do this with the other two permissions as well.
adfind -sc findpropsetrg:"Personal Information"
You should get a result similar to this:
AdFind V01.37.00cpp Joe Richards (joe@joeware.net) June 2007
Using server: DC01.intern.lechner-online.net:389
Directory: Windows Server 2003
Base DN: cn=extended-rights,CN=Configuration,DC=inter,DC=lechner-online,DC=net
dn:CN=Personal-Information,CN=Extended-Rights,CN=Configuration,DC=inter,DC=lechner-online,DC=net
>rightsGuid: 77B5B886-944A-11d1-AEBD-0000F80367C1
You can paste the found GUID into a second adfind command to list all of the attributes in the property set that are writeable by the user itself:
adfind -sc propsetmembersl:"77b5b886-944a-11d1-aebd-0000f80367c1"
Depending on your Active Directory schema and maybe preceded changes, your results might vary a bit:
assistant
c
facsimileTelephoneNumber
homePhone
homePostalAddress
info
internationalISDNNumber
ipPhone
l
mobile
mSMQDigests
mSMQSignCertificates
otherFacsimileTelephoneNumber
otherHomePhone
otherIpPhone
otherMobile
otherPager
otherTelephone
pager
personalTitle
physicalDeliveryOfficeName
postalAddress
postalCode
postOfficeBox
preferredDeliveryMethod
primaryInternationalISDNNumber
primaryTelexNumber
publicDelegates
registeredAddress
st
street
streetAddress
telephoneNumber
teletexTerminalIdentifier
telexNumber
thumbnailPhoto
userCert
userCertificate
userSharedFolder
userSharedFolderOther
userSMIMECertificate
x121Address
If you’ve got an automated system that populates any of these attributes (e.g. an identity management system like Microsoft FIM2010 or SAP Netweaver Identity Manager), hypothetically an end user could put other data in them and start breaking processes. I’ve only ever heard once or twice of this happening, and I’m not fully aware of all the implications of removing these ACEs if you wanted to prevent the possibility. Keep in mind that this is applied as an individual ACE to each user as it’s created, so, in order to clean this up in an existing forest you’d need a script to go through and remove the ACEs from each user individually. New users would get the updated defaults based on modifying the defaultSecurityDescriptor of the user class, though.
Have fun
Chris
