joeware - never stop exploring... :)

I was recently helping with an issue where someone was trying to set the security to allow some group to directly modify the title field in the Organization tab of Active Directory Users and Computers (ADUC) of users in a specific OU.

They followed the logical path of

1. Right click on OU
2. Select Properties
3. Select the Security tab
4. Click the Advanced button
5. Click Add
6. Type in or browse for security group to assign permissions to
7. Click on the Properties Tab of the Permission Entry for [insert OU Name]
8. Select User objects for the “Apply Onto” dropdown
9. Clickedon Allow Read Title and Allow Write Title
10. Clicked OK
11. Clicked OK
12. Clicked OK

They followed this logical path and then tried to get someone from the group to modify the title field on the Organization tab for one of the users in the OU… It doesn’t work… What happened?

First thing out of many folks mouths will be

1. Didn’t wait for replication
2. Didn’t log off or and log back on

If the person has been helping others for long enough they may even respond with

1. Could be related to adminSDHolder functionality, is the user you are trying to modify in a builtin group that would cause Active Directory to smack your Security Descriptor?
2. Are you sure you did it properly? Maybe you actually selected the wrong OU or didn’t actually hit OK or Apply at the right time and thought that hitting OK at the first screen was enough…

Unfortunately it could be all of those things, but it also doesn’t have to be any of them.

You see the issue here is with how ADUC uses display specifiers. These are a great idea, they allow you to specify what to translate attribute names to for display. For instance, you can add a display specifier such that the attribute description can be displayed as “Joe Rocks My World”, and then realize you spelled my name wrong and correct it to “joe Rocks My World”.

The issue though is that display specifiers are not used consistently… I can’t do any better than give an actual example. At random, let’s pick a field, say title from the Organization Tab….

One thing I will do to work out what fields in ADUC map to what AD attributes (note I purposely keep these terms separate as there is NOT a one to one relationship…) is dump the object I am about to modify and then update the field in ADUC with some goofy value and then dump the object again to see the attribute(s) that was/were changed[1].

So on my test joe userid  I update the Organization Tab’s title field to be “The 6 foot 1 inch driving ubergeek”.

I look at the object

G:\>adfind -default -f name=joe |grep -i title

AdFind V01.31.00cpp Joe Richards (joe@joeware.net) March 2006

File STDIN:
>title: The 6 foot 1 inch driving ubergeek

So the title field in the ADUC Organization tab is actually the title attribute in AD… Ok that is easy to recall…

So now lets follow the directions way above to allow the TEST_DLG_SEC group to modify the title property and see what we really get…

According to adfind outputting the Security Descriptor for the user object and filtering for TEST_DLG_SEC we see for the

G:\>adfind -default -f name=joe ntsecuritydescriptor -resolvesids -sddl+ |grep TEST_DLG_SEC

AdFind V01.31.00cpp Joe Richards (joe@joeware.net) March 2006

File STDIN:
>nTSecurityDescriptor: [DACL] OA;CIID;RPWP;personalTitle;user;TEST\TEST_DLG_SEC

 You see that!!!! That isn’t the title attribute… that is the personalTitle attribute… WTF!

Oh if you can’t read that, let me give it to you in DSACLS format

Allow TEST\TEST_DLG_SEC          SPECIAL ACCESS for personalTitle  
                                                  WRITE PROPERTY
                                                  READ PROPERTY

How did that happen? We already proved that the ADUC Organization Tab Form is showing the field Title and that maps to the title attribute in AD… How did we get to personalTitle???

Let’s go to the display specifiers… I just happen to know that we need to look at the User display specifier for the 409 region/language… Let’s dump the attributeDisplayNames attribute for that object and filter for title in the values

G:\>adfind -b “CN=user-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=test,DC=loc” attributedisplaynames -mvfilter attributedisplaynames=title

AdFind V01.31.00cpp Joe Richards (joe@joeware.net) March 2006

Using server: r2dc2.test.loc:389
Directory: Windows Server 2003

dn:CN=user-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=test,DC=loc
>attributeDisplayNames: title,Job Title
>attributeDisplayNames: personalTitle,Title
1 Objects returned

 Oh so that is fun… title is mapped to “Job Title” and personalTitle is mapped to “Title”… Again WTF…

So now we realize that the form dialogs have fixed naming but some of the other items, notably the ACL editor, the find dialogs, the column manipulations for the right panel will do name translation based on the display specifiers… Yet again… WTF!

There is a logical reason for this that I expect is the answer but it sucks as an answer… The places where display specifiers are actually used are all variable width fields… You know this if you are a programmer, if you aren’t a programmer, take my word for it. In the form, that is all fixed so if you changed say title to display “What should all of you peons call me” (Dogbert is somewhere around here…) it would mess the form up and couldn’t be adjusted by the user….

So if that is it, I understand why it was done. However I think this is a big stupid confusing inconstistent mess around something that really doesn’t need any more stupid confusion… I like the idea of display specifiers but it needs to be consistent.

So what does this mean… It means the same thing I tell people all of the time, try not to use the GUI. I say that for lots of reasons such as the fact that if you consistently use the GUI you are not as efficient in your admin work as someone who doesn’t by a considerable margin… There is also more likelihood of making mistakes in the GUI (clicking the wrong thing, clicking at the wrong time, accidently dragging and dropping or dropping in the wrong place, etc). Finally, the GUI tends to lie to you more than the command line. Obviously this depends entirely on the programs being used but the mainstream admin tools lie considerably because Microsoft mostly has to assume the person doing the admin work could be a complete moron.

I am serious about this because there are quite a few morons who have found their way into admin positions, look around, you probably know a few yourself or don’t get nervous, but maybe it is you…. We can thank the GUI’ness of Admin’ing Windows Servers for that as well as the multitude of MCSE bootcamps and programs out there… Some people like to think that since they can find their way around the GUI, they must be smart enough to be an admin. Hiring managers, keep it up with that strategy, it will be a hoot to watch long term… Sure you saved money up front… what does that get you later though?

I just heard a commercial on the radio yesterday when driving around in thethat went something like… Tired of being stuck in your dead end job washing dishes or cleaning rooms and making less than $50k a year, come join our program to be an MCSE and get a job as a Windows Server Administrator… Hmmm we are appealing to dish washers and house cleaners to be Windows Administrators. Anyone else see this as one of the reasons Windows has a bad rap as a shitty OS? If all the morons of the world drove Volvo’s then Volvo probably wouldn’t have as good a safety record either.

As a whole, Windows has the least knowledgeable users and least knowledgeable admins of any OS, by a tremendous margin. Microsoft HAS to make the admin tools easy for uninformed people to use which means that the real stuff has to be covered up because under the covers it isn’t easy managing an OS or a distributed authentication system, etc.

So stick with DSACLS for setting permissions and if there is something it can’t set, use a script or LDP from ADAM R2/SP1. At least LDP isn’t trying to inconsistently dork around with the names. For just normal management of AD, use command line tools and scripts as well. Think how much more efficient you will be overall if it takes you a couple of seconds to add someone to a group versus a minute or more. If that isn’t enough to get you to do it… consider what you look like to others who are watching you do your work… I know if I watch an admin using the standard GUI tools to do all of their work I wonder just HOW inefficient they are, the question of whether or not they are inefficient is already answered at that point.

  joe

[1] This could also be done by looking at what changed in the replication metadata or having a script that watches a directory and tells you what changed. In actuality this last is what I tend to do myself nowadays but I can’t share the script that I do that with so I tell you the low tech method that I used to use to do it 6 years ago…