I made a brief mention of some of the default security permissions that apply to users in my article on Delegating Privileges in Active Directory for Windows IT Pro. I’ve gotten a couple of e-mail questions so I thought I’d elaborate here since I don’t have to worry about how many words I have to work with in this space. 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 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 can take advantage of this. The easiest way to edit or view the value for this attribute is using the Active Directory Schema MMC. 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 on the Name column and scroll down to SELF, you’ll see three entries (highlighted in yellow below) which are interesting:
These three ACEs grant the user permissions to write to the attributes in those three property sets for their account. 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 adfind. The first thing you’ll need to do is convert the friendly display name (e.g. Personal Information) into the GUID of the property set:
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: BRIAN-RTDC01.brianlab.local:389
Directory: Windows Server 2003
Base DN: cn=extended-rights,CN=Configuration,DC=brianlab,DC=local
dn:CN=Personal-Information,CN=Extended-Rights,CN=Configuration,DC=brianlab,DC=local
>rightsGuid: 77B5B886-944A-11d1-AEBD-0000F80367C1
You can paste that GUID into a second adfind command to list all of the attributes in the property set:
adfind -sc propsetmembersl:"77b5b886-944a-11d1-aebd-0000f80367c1"
Depending on the schema your directory has, your results might vary a bit, but in my test forest this is the result:
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, hypothetically an end user could put other data in them and start breaking things. 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.