I was perusing the newsgroups this evening and ran across someone with a “case” issue with logon names in Active Directory. It seems some software he was using required a specific case[1]. Well AD doesn’t case about case… at all. However this person was having a problem changing the case. I looked at it and didn’t see an issue… then Richard Mueller caught on that the poster meant the issue was with the userPrincipalName and ADUC was indeed not letting him change the case…
I tried this and sure enough, on my version of ADUC this was also the case… ADUC 5.2.3790.1830… I fired off a quick note to one of the really good MSFT developers I know who has the most likely chance of getting something done with that problem and fessed up in the newsgroups that yes that appears to be an issue in ADUC, but rest assured it isn’t an AD bug… I then offered a solution…
The solution was to use adfind and admod together to change the userPrincipalNames to lowercase… Previously I might have said this will take a script… However this is actually extremely easy to do now with the latest rev of admod…
Assuming you want to change the userPrincipalNames to all be lowercase across your entire default domain you would use a command sequence like so:
adfind -default -f userprincipalname=* userprincipalname -adcsv | admod userprincipalname::{{.:_lc}} -unsafe
I don’t care if you have 10 objects with UPNs or 10,000,000 this will handle it… Not only will it handle it but I doubt there is a script that could touch it for processing speed regardless of the number of objects that have to be made…
So let’s break this down into its components.
adfind -default -f userprincipalname=* userprincipalname -adcsv
This generates a CSV stream containing the DNs of matching objects combined with the current userPrincipalName, it will generate something that looks like
~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~~~~ADCSV~~~
“dn”,”userprincipalname”
“CN=_TestUser1,OU=Users,OU=TestOU,DC=test,DC=loc”,”_TestUser1@test.loc”
“CN=ADMINONLY,OU=Users,OU=TestOU,DC=test,DC=loc”,”adminonly@test.loc”
“CN=TestAdminClone,OU=Users,OU=TestOU,DC=test,DC=loc”,”TestAdminClone@test.loc”
“CN=TestEmail,OU=Email,OU=My,DC=test,DC=loc”,”TestEmail@test.loc”
“CN=user\, test,OU=Users,OU=TestOU,DC=test,DC=loc”,”testuser@test.loc”
Next this CSV stream flies across the pipe (that would be the | character) to admod which then executes the following:
admod userprincipalname::{{.:_lc}} -unsafe
First thing off, the -unsafe part simply says no matter how many DNs are read in from the CSV, process them all… You also have the option of setting a specific safety number that you would want to bail out on everything if you exceed with the -safety X switch or you can say do up to X with -upto X.
The other part is the fun part…
userprincipalname::{{.:_lc}}
This tells admod that you want to:
- update the userPrincipalName attribute (userprincipalname)
- the update is a replace (::)
- the value it should be set to is the userprincipalname field from the CSV Stream ({{.}})
- but you want the value from the stream changed to lower case (:_lc)
How cool is that? Heck I have been playing with stuff like that for some time now and I still think it is cool. 😉
joe
[1] WHY WHY WHY WHY WHY WHY WHY WHY? If you are a developer and your application is case sensitive for userids…. WHY? Do you really need the ability to have a joe and a JOE as two completely different users?
