In the last couple of months, I found myself in a position where I could only access a domain controller through a reverse proxy port redirector and was simply redirecting port 389. This adds some level of difficulty to doing some things since AD isn’t strictly LDAP based. There is quite a bit of stuff going on through RPC, etc. I stumbled on some issues with Phantom Root that I am working out with the MSFT Directory Services Dev guys but this post is about SID resolution and some possible new functionality for AdFind because it just doesn’t have enough switches yet….
One of the items that I ran into issues with was my -resolvesids switch. This was configured to go immediately to RPC and obviously that isn’t very helpful when you don’t have RPC available… I added some functionality into my personal test versions that allows me to resolve some, but not all of the SIDs through LDAP due to some objects not being resolvable that way such as SIDs to trusted domains, etc. It also works for ADAM since the only way to resolve an ADAM SID is through LDAP calls. Again though, inconsistent because ADAM is locked down much tighter than Active Directory and you may or may not have rights to the objects to look the SIDs up.
Very useful at least to me, but not as consistent as I like things to be for general release. I figured I would keep my personal build versions with it and keep it out of the public build versions. Then, out of the blue, I get an email from one of my previous co-workers asking for that exact functionality for ADAM… Now that people are asking for it, the push to putting the capability in the public build version is worth reconsidering. I am still a bit conflicted about it though… I visualize getting a good amount of questions when SIDs are resolved to different formats or aren’t resolved.
Currently the resolve function will try LDAP if the directory is ADAM or if a special switch is specified against a Windows Server 2003 or better directory. Anything it can’t resolve it will drop into RPC and try to resolve that way. This means you could see SIDs resolved to DN’s (a la LDAP resolution), NT Format (a la RPC resolution), or not resolved so shown as a SID. The big change from the current configuration is the DN format. I could try to figure out an NT format for the AD SIDs but that is actually more work than I want to put into it. UPNs could be used but ADAM doesn’t necessarily have UPN’s set and there isn’t a default UPN like there is with AD. DN is the only identifier guaranteed to be in place when doing an LDAP resolution and it is actually about the easiest thing I can do (how unusual).
Here is an example of tokenGroups being dumped from an ADAM instance. It illustrates what I mean by the different formats.
Using server: 2k38500.joe.com:389
Directory: Active Directory Application Mode
dn:
>tokenGroups: 2K38500\$jricha34
>tokenGroups: 2K38500\None
>tokenGroups: Everyone
>tokenGroups: BUILTIN\Administrators
>tokenGroups: BUILTIN\Remote Desktop Users
>tokenGroups: BUILTIN\Users
>tokenGroups: NT AUTHORITY\INTERACTIVE
>tokenGroups: NT AUTHORITY\Authenticated Users
>tokenGroups: NT AUTHORITY\This Organization
>tokenGroups: Logon Session (S-1-5-5-0-120902)
>tokenGroups: LOCAL
>tokenGroups: NT AUTHORITY\NTLM Authentication
>tokenGroups: CN=Administrators,CN=Roles,CN=Configuration,CN={7017763A-D4D1-4EBA-AA7D-B3C8FDA427D3}
>tokenGroups: CN=Administrators,CN=Roles,OU=mytest
1 Objects returned
If RPC wasn’t available, only the DN format SIDs and well known SIDs would have been converted.
Thoughts?
joe
