joeware - never stop exploring... :)

I recently mentioned the beauty of Phantom Root and how you can use it to search all of the NCs on a DC in a single fell swoop. This works great but I stumbled upon a slight oddity. I am discussing it with the MSFT DS Dev team as there is some debate/question on exactly what the behavior should be. Whatever the decision, I do classify the current behaviour as odd at a minimum and the more I think about it the more I think the current behaviour is incorrect.

So what is the oddity?

If you query a DC that happens to be a Global Catalog and you specify the base that is within a naming context that is only read-only on the DC (i.e. a Domain that the DC doesn’t host) then instead of the query running on that DC, a referral will be returned to redirect you to a DC of the domain specified. This doesn’t happen when querying the GC port on the same though obviously.

So lets give a couple of examples. These examples have the following constants:

The forest design is

dc=root,dc=com
    cn=configuration
          cn=schema
    dc=child1

There are two domain controllers that are GCs; DC1 is a DC for root.com and a GC, DC2 is a DC for child1.root.com and is also a GC.

You can use phantom root to query with multiple bases and the two GCs will give different results for some of those bases. I don’t believe that is correct as it belies underlying implementation when GCs are all supposed to be created equal. There are other examples of this especially around linked attributes but having that problem in one area doesn’t validate it as ok in another.

Scenario 1

Search Base: “” (null base)
Filter : objectclass=*
Result: Correct
Both GCs will return identical results. Will return all objects in forest.

Scenario 2

Search Base: dc=com
Filter : objectclass=*
Result: Correct
Both GCs will return identical results. Will return all objects in forest.

Scenario 3

Search Base: dc=root,dc=com
Filter : objectclass=*
Result: Incorrect (IMO)
GCs will return different results. DC1 will return all objects in forest. DC2 will return a referral.

Scenario 4

Search Base: dc=child1,dc=root,dc=com
Filter : objectclass=*
Result: Incorrect (IMO)
GCs will return different results. DC1 will return a referral. DC2 will return all objects in forest.

Scenario 5

Search Base: cn=configuration,dc=root,dc=com
Filter : objectclass=*
Result: Correct
GCs will return identical results. Will return all objects in config and schema NCs

Scenario 6

Search Base: cn=users,dc=root,dc=com (or any other container in root.com domain)
Filter : objectclass=*
Result: Incorrect (IMO)
Same as Scenario 3

Scenario 7

Search Base: cn=users,dc=child1,dc=root,dc=com (or any other container in child1.root.com domain)
Filter : objectclass=*
Result: Incorrect (IMO)
Same as Scenario 4

The answer to this could be a simple “so query the GC port then…”. There are reasons why this may not be feasible. One example is that maybe you are working through a reverse proxy or through router ACLs and only port 389 is available. Maybe you are porting an application that is designed from the ground up to only use port 389 and you want to minimize the changes but still need to query any of the partitions directly and you don’t want the overhead of referrals. etc etc etc

One messy issue that could come up when you have multiple DCs for root.com or you have a single DC for root.com but it isn’t a GC and you initially are using a child1.root.com GC for all of your queries and you happen to specify dc=root,dc=com for a base (it is the root domain, this wouldn’t be unusual) and you get a redirection like

REFERRAL: ldap://root.com/dc=root,dc=com

which could take you to ANY root.com DC in the root.com domain including one that isn’t a GC. So say you hit a non-GC DC, the query is executed there and since it isn’t a GC, none of the child1.root.com objects are returned. Referrals are usually handled in the background with no outward visible signs of the referral so many people would be quite shocked if they were expecting some child1.root.com objects to be returned and in fact none were… They would likely have to do a network query to even start to crack the problem or worse, have the app vendor try to figure it out.

I do really hope that MSFT either changes this behaviour or adds some sort of additional control that allows you to disable the referral from being returned and just forces the search. Since these aren’t continuation referrals you cannot block them with the currently available server side referral blocking mechanisms like you can with continuation referrals. In fact, continuation referrals are already disabled when you use Phantom Root.

   joe

I was working on some additional functionality for AdFind to decode the replication metadata in a little more readable format than the default XML format you get with msDS-ReplAttributeMetaData and ran into an issue with DS_REPL_ATTR_META_DATA_BLOB.

The structure is defined on MSDN – http://msdn2.microsoft.com/en-us/library/ms676250.aspx

It looks like

typedef struct {
DWORD oszAttributeName;
DWORD dwVersion;
FILETIME ftimeLastOriginatingChange;
UUID uuidLastOriginatingDsaInvocationID;
USN usnOriginatingChange;
USN usnLocalChange;
DWORD oszLastOriginatingDsaDN; } DS_REPL_ATTR_META_DATA_BLOB;

The code sample shows

DS_REPL_ATTR_META_DATA_BLOB *pdsReplAttrMetaDataBlob;

// Retrieve the replication data into pdsReplAttrMetaDataBlob.

LPWSTR pwszAttributeName = (LPWSTR)((LPBYTE)pdsReplAttrMetaDataBlob + pdsReplAttrMetaDataBlob->oszAttributeName);

LPWSTR pwszLastOriginatingDsaDN = (LPWSTR)((LPBYTE)pdsReplAttrMetaDataBlob + pdsReplAttrMetaDataBlob->oszLastOriginatingDsaDN);

The issue I encountered is that if the DSA GUID can’t be resolved to a DN (i.e. deleted) then oszLastOriginatingDsaDN returns 0 instead of an offset into the string block at the end of the blob. That means the sample code provided will return a garbage value because it will be pointing to the beginning of the blob which absolutely is not the correct place to be pointing to and the resulting string will simply be a decode of the binary at the beginning of the blob to whatever Unicode string it works out to be.

The fix is simple, you need to validate that the offset has a value before setting the string to the blob+offset. If the offset is 0, then determine what you want to output in lieu of the correct DN because you don’t have a choice – you don’t have the correct DN.

I haven’t checked the other attributes yet that are also decoded through the repl BLOB structures but I would not be entirely surprised if the same issue crops up in the others.

I have fired a note off to a couple of my friends at MSFT who can get something done on this. I figure it could go one of two ways. The documentation could be corrected and/or the blob returned from the server could be corrected to actually send an offset as documented that simply points to a null string.

Personally, this latter solution is probably the correct long term action though the docs need to be updated for current implementations… If anyone used the code from the MSDN site unmodified they have a ticking time bomb. This is a realistic possibility because it seems that a lot of code slingers writing AD code don’t test against fully beat up directories, they spin up a simple domain/forest that hasn’t gone through any real churn and if their code works there it must work anywhere… right? If a DC hasn’t been removed from the domain and a change to the given test object(s) wasn’t/weren’t originated on that DC then they would not have run into this issue. The fallout of this could vary wildly from nothing to odd output to application crash. You cannot guess unless you understand how the value is used in the program.

   joe

Dana says it very well here… http://silverstr.ufies.org/blog/archives/001001.html

 I agree with him, the UAC stuff was extremely obtrusive in the beta phases and *might* get annoying when initially setting up a new PC if you are loading a ton of stuff but honestly, it hasn’t really bothered me since Beta2. That beta was rough and I actually turned it off permanently. With the RCs it was much better. With the released product I have only had to turn it off once and that was to get my Borland compiler to install. Other than that it runs all of the time and I really am not all that bothered by it because it doesn’t pop up that much.

I posted yesterday about AdFind being on the bench and I received a couple of emails. One of the emails came from a friend who now works for MSFT. The core of the note was

In ADFind, could you also have a switch to tell you the size of the ntSecurityDescriptors attribute? I’ve noticed quite a few applications (such as exchange 2k and 2k3) have issues reading this blob when it gets over/around 32k on an object. Let me know what you think. 

What do I think? I think that is an awesome idea Brandon! I love it. Just the kind of off the wall out of the box thinking that I think is a great trait… It is a simple thing that is tough to do normally that has real life practical use in some important cases. It isn’t something that you will use everyday or in fact most users may never ever use it. But if you need it, it is cool that it is “in there”. There is another tool out there that will tell you SD lengths on AD Objects; I recall seeing it on a couple of occasions but I can NEVER recall the name. Anyway, I read that email on my lunch break and let it sit and spin in the back of my head all afternoon and evening and when I sat down at around midnight to look at the AdFind source code I pulled up those thoughts from the trenches and had it solved so just punched in the source code to do it… After a little bit of futzing around with formatting for a bit and some testing it appears to be working great. Since I already add prefix strings in describing sections of the SD when using -sddl++, etc I decided to add a new prefix string called [SIZE] which will appear in the output when the SD size is requested.

Here are a couple of examples of output…

CSV Output of object security descriptor and mailbox security descriptor, if present, specified in KB (1024 Bytes).

F:\Dev\CPP\AdFind>adfind -default  ntsecuritydescriptor msexchmailboxsecuritydescriptor -sdsize kb -csv -maxe 20
“dn”,”ntsecuritydescriptor”,”msexchmailboxsecuritydescriptor”
“DC=joe,DC=com”,”[SIZE] 1.70KB”,””
“CN=Users,DC=joe,DC=com”,”[SIZE] 1.24KB”,””
“CN=$jricha34,CN=Users,DC=joe,DC=com”,”[SIZE] 0.79KB”,”[SIZE] 0.49KB”
“OU=Exchange,DC=joe,DC=com”,”[SIZE] 1.30KB”,””
“OU=joeware2,OU=Exchange,DC=joe,DC=com”,”[SIZE] 1.36KB”,””
“OU=MailUsers,OU=joeware2,OU=Exchange,DC=joe,DC=com”,”[SIZE] 1.36KB”,””
“CN=postmaster,OU=MailUsers,OU=joeware2,OU=Exchange,DC=joe,DC=com”,”[SIZE] 1.95KB”,”[SIZE] 0.53KB”
“OU=Domain Controllers,DC=joe,DC=com”,”[SIZE] 1.12KB”,””
“CN=Computers,DC=joe,DC=com”,”[SIZE] 1.41KB”,””
“CN=2K3DC02,OU=Domain Controllers,DC=joe,DC=com”,”[SIZE] 1.88KB”,””
“CN=System,DC=joe,DC=com”,”[SIZE] 1.14KB”,””
“CN=RID Manager$,CN=System,DC=joe,DC=com”,”[SIZE] 1.16KB”,””
“CN=LostAndFound,DC=joe,DC=com”,”[SIZE] 1.07KB”,””
“CN=Infrastructure,DC=joe,DC=com”,”[SIZE] 1.09KB”,””
“CN=ForeignSecurityPrincipals,DC=joe,DC=com”,”[SIZE] 1.07KB”,””
“CN=Program Data,DC=joe,DC=com”,”[SIZE] 1.07KB”,””
“CN=Microsoft,CN=Program Data,DC=joe,DC=com”,”[SIZE] 1.07KB”,””
“CN=NTDS Quotas,DC=joe,DC=com”,”[SIZE] 1.11KB”,””
“CN=WinsockServices,CN=System,DC=joe,DC=com”,”[SIZE] 1.14KB”,””
“CN=RpcServices,CN=System,DC=joe,DC=com”,”[SIZE] 1.14KB”,””

Standard output without decoding any of the SDDL in Bytes.

F:\Dev\CPP\AdFind>adfind -default ntsecuritydescriptor msexchmailboxsecuritydescriptor -sdsize -maxe 5

AdFind V01.36.00cpp Joe Richards (joe@joeware.net) February 2007

Using server: 2k3dc02.joe.com:389
Directory: Windows Server 2003
Base DN: DC=joe,DC=com

dn:DC=joe,DC=com
>nTSecurityDescriptor: [SIZE] 1736B

dn:CN=Users,DC=joe,DC=com
>nTSecurityDescriptor: [SIZE] 1268B

dn:CN=$jricha34,CN=Users,DC=joe,DC=com
>nTSecurityDescriptor: [SIZE] 812B
>msExchMailboxSecurityDescriptor: [SIZE] 504B

dn:OU=Exchange,DC=joe,DC=com
>nTSecurityDescriptor: [SIZE] 1332B

dn:OU=joeware2,OU=Exchange,DC=joe,DC=com
>nTSecurityDescriptor: [SIZE] 1388B

5 Objects returned

And finally, standard output and decoding in -sddl++ mode and again in KB

F:\Dev\CPP\AdFind>adfind -default ntsecuritydescriptor msexchmailboxsecuritydescriptor -sdsize kb -maxe 2 -sddl++

AdFind V01.36.00cpp Joe Richards (joe@joeware.net) February 2007

Using server: 2k3dc02.joe.com:389
Directory: Windows Server 2003
Base DN: DC=joe,DC=com

dn:DC=joe,DC=com
>nTSecurityDescriptor: [SIZE] 1.70KB
>nTSecurityDescriptor: [OWNER] BA
>nTSecurityDescriptor: [GROUP] BA
>nTSecurityDescriptor: [DACL] (FLAGS:INHERIT)
>nTSecurityDescriptor: [DACL] OBJ ALLOW;;[CTL];Manage Replication Topology;;S-1-5-21-1862701446-4008382571-2198042679-1674
>nTSecurityDescriptor: [DACL] OBJ ALLOW;;[CTL];Replicating Directory Changes All;;DD
>nTSecurityDescriptor: [DACL] OBJ ALLOW;[CONT INHERIT];[WRT PROP];groupType;;S-1-5-21-1862701446-4008382571-2198042679-1674
>nTSecurityDescriptor: [DACL] OBJ ALLOW;[CONT INHERIT];[WRT PROP];displayName;;S-1-5-21-1862701446-4008382571-2198042679-1674
>nTSecurityDescriptor: [DACL] OBJ ALLOW;[CONT INHERIT];[WRT PROP];Public Information;;S-1-5-21-1862701446-4008382571-2198042679-1674
>nTSecurityDescriptor: [DACL] OBJ ALLOW;[CONT INHERIT];[WRT PROP];Personal Information;;S-1-5-21-1862701446-4008382571-2198042679-1674
>nTSecurityDescriptor: [DACL] OBJ ALLOW;[CONT INHERIT][INHERIT ONLY];[READ PROP];tokenGroups;computer;ED
>nTSecurityDescriptor: [DACL] OBJ ALLOW;[CONT INHERIT][INHERIT ONLY];[READ PROP];tokenGroups;group;ED
>nTSecurityDescriptor: [DACL] OBJ ALLOW;[CONT INHERIT][INHERIT ONLY];[READ PROP];tokenGroups;user;ED
>nTSecurityDescriptor: [DACL] OBJ ALLOW;[CONT INHERIT][INHERIT ONLY];[LIST CHILDREN][READ PROP][LIST OBJ][READ];;inetOrgPerson;S-1-5-21-1862701446-4008382571-2198042679-1674
>nTSecurityDescriptor: [DACL] OBJ ALLOW;[CONT INHERIT][INHERIT ONLY];[LIST CHILDREN][READ PROP][LIST OBJ][READ];;user;S-1-5-21-1862701446-4008382571-2198042679-1674
>nTSecurityDescriptor: [DACL] OBJ ALLOW;[CONT INHERIT][INHERIT ONLY];[LIST CHILDREN][READ PROP][LIST OBJ][READ][WRT PERMS];;group;S-1-5-21-1862701446-4008382571-2198042679-1674
>nTSecurityDescriptor: [DACL] OBJ ALLOW;;[CTL];Replicating Directory Changes;;BA
>nTSecurityDescriptor: [DACL] OBJ ALLOW;;[CTL];Replication Synchronization;;BA
>nTSecurityDescriptor: [DACL] OBJ ALLOW;;[CTL];Manage Replication Topology;;BA
>nTSecurityDescriptor: [DACL] OBJ ALLOW;;[CTL];Replicating Directory Changes All;;BA
>nTSecurityDescriptor: [DACL] OBJ ALLOW;;[CTL];Create Inbound Forest Trust;;S-1-5-32-557
>nTSecurityDescriptor: [DACL] OBJ ALLOW;[CONT INHERIT][INHERIT ONLY];[LIST CHILDREN][READ PROP][LIST OBJ][READ];;inetOrgPerson;RU
>nTSecurityDescriptor: [DACL] OBJ ALLOW;[CONT INHERIT][INHERIT ONLY];[LIST CHILDREN][READ PROP][LIST OBJ][READ];;group;RU
>nTSecurityDescriptor: [DACL] OBJ ALLOW;[CONT INHERIT][INHERIT ONLY];[LIST CHILDREN][READ PROP][LIST OBJ][READ];;user;RU
>nTSecurityDescriptor: [DACL] OBJ ALLOW;;[CTL];Replicating Directory Changes;;ED
>nTSecurityDescriptor: [DACL] OBJ ALLOW;;[CTL];Replication Synchronization;;ED
>nTSecurityDescriptor: [DACL] OBJ ALLOW;;[CTL];Manage Replication Topology;;ED
>nTSecurityDescriptor: [DACL] ALLOW;;[READ];;;S-1-5-21-1862701446-4008382571-2198042679-1674
>nTSecurityDescriptor: [DACL] ALLOW;;[LIST CHILDREN][READ PROP][READ];;;S-1-5-21-3593593216-2729731540-1825052264-13170
>nTSecurityDescriptor: [DACL] ALLOW;;[CR CHILD][LIST CHILDREN][SELF WRT][READ PROP][WRT PROP][LIST OBJ][CTL][READ][WRT PERMS][WRT OWNER];;;DA
>nTSecurityDescriptor: [DACL] ALLOW;[CONT INHERIT];[LIST CHILDREN];;;S-1-5-21-1862701446-4008382571-2198042679-1674
>nTSecurityDescriptor: [DACL] ALLOW;[CONT INHERIT];[FC];;;EA
>nTSecurityDescriptor: [DACL] ALLOW;;[READ PROP][READ];;;RU
>nTSecurityDescriptor: [DACL] ALLOW;[CONT INHERIT];[LIST CHILDREN];;;RU
>nTSecurityDescriptor: [DACL] ALLOW;[CONT INHERIT];[CR CHILD][LIST CHILDREN][SELF WRT][READ PROP][WRT PROP][LIST OBJ][CTL][DEL][READ][WRT PERMS][WRT OWNER];;;BA
>nTSecurityDescriptor: [DACL] ALLOW;;[READ PROP];;;WD
>nTSecurityDescriptor: [DACL] ALLOW;;[LIST CHILDREN][READ PROP][LIST OBJ][READ];;;ED
>nTSecurityDescriptor: [DACL] ALLOW;;[LIST CHILDREN][READ PROP][LIST OBJ][READ];;;AU
>nTSecurityDescriptor: [DACL] ALLOW;;[FC];;;SY
>nTSecurityDescriptor: [SACL] (FLAGS:INHERIT)
>nTSecurityDescriptor: [SACL] OBJ AUDIT;[CONT INHERIT][SUCCESS];[WRT PROP];gPLink;organizationalUnit;WD
>nTSecurityDescriptor: [SACL] OBJ AUDIT;[CONT INHERIT][SUCCESS];[WRT PROP];gPOptions;organizationalUnit;WD
>nTSecurityDescriptor: [SACL] AUDIT;[SUCCESS];[CTL];;;DU
>nTSecurityDescriptor: [SACL] AUDIT;[SUCCESS];[CTL];;;BA
>nTSecurityDescriptor: [SACL] AUDIT;[SUCCESS];[WRT PROP][WRT PERMS][WRT OWNER];;;WD

dn:CN=Users,DC=joe,DC=com
>nTSecurityDescriptor: [SIZE] 1.24KB
>nTSecurityDescriptor: [OWNER] DA
>nTSecurityDescriptor: [GROUP] DA
>nTSecurityDescriptor: [DACL] (FLAGS:INHERIT)
>nTSecurityDescriptor: [DACL] OBJ ALLOW;;[CR CHILD][DEL CHILD];inetOrgPerson;;AO
>nTSecurityDescriptor: [DACL] OBJ ALLOW;;[CR CHILD][DEL CHILD];group;;AO
>nTSecurityDescriptor: [DACL] OBJ ALLOW;;[CR CHILD][DEL CHILD];printQueue;;PO
>nTSecurityDescriptor: [DACL] OBJ ALLOW;;[CR CHILD][DEL CHILD];user;;AO
>nTSecurityDescriptor: [DACL] ALLOW;;[CR CHILD][DEL CHILD][LIST CHILDREN][SELF WRT][READ PROP][WRT PROP][LIST OBJ][CTL][READ][WRT PERMS][WRT OWNER];;;DA
>nTSecurityDescriptor: [DACL] ALLOW;;[LIST CHILDREN][READ PROP][LIST OBJ][READ];;;AU
>nTSecurityDescriptor: [DACL] ALLOW;;[FC];;;SY
>nTSecurityDescriptor: [DACL] OBJ ALLOW;[CONT INHERIT][INHERITED];[WRT PROP];groupType;;S-1-5-21-1862701446-4008382571-2198042679-1674
>nTSecurityDescriptor: [DACL] OBJ ALLOW;[CONT INHERIT][INHERITED];[WRT PROP];displayName;;S-1-5-21-1862701446-4008382571-2198042679-1674
>nTSecurityDescriptor: [DACL] OBJ ALLOW;[CONT INHERIT][INHERITED];[WRT PROP];Public Information;;S-1-5-21-1862701446-4008382571-2198042679-1674
>nTSecurityDescriptor: [DACL] OBJ ALLOW;[CONT INHERIT][INHERITED];[WRT PROP];Personal Information;;S-1-5-21-1862701446-4008382571-2198042679-1674
>nTSecurityDescriptor: [DACL] OBJ ALLOW;[CONT INHERIT][INHERIT ONLY][INHERITED];[READ PROP];tokenGroups;computer;ED
>nTSecurityDescriptor: [DACL] OBJ ALLOW;[CONT INHERIT][INHERIT ONLY][INHERITED];[READ PROP];tokenGroups;group;ED
>nTSecurityDescriptor: [DACL] OBJ ALLOW;[CONT INHERIT][INHERIT ONLY][INHERITED];[READ PROP];tokenGroups;user;ED
>nTSecurityDescriptor: [DACL] OBJ ALLOW;[CONT INHERIT][INHERIT ONLY][INHERITED];[LIST CHILDREN][READ PROP][LIST OBJ][READ];;inetOrgPerson;S-1-5-21-1862701446-4008382571-2198042679-1674
>nTSecurityDescriptor: [DACL] OBJ ALLOW;[CONT INHERIT][INHERIT ONLY][INHERITED];[LIST CHILDREN][READ PROP][LIST OBJ][READ];;user;S-1-5-21-1862701446-4008382571-2198042679-1674
>nTSecurityDescriptor: [DACL] OBJ ALLOW;[CONT INHERIT][INHERIT ONLY][INHERITED];[LIST CHILDREN][READ PROP][LIST OBJ][READ][WRT PERMS];;group;S-1-5-21-1862701446-4008382571-2198042679-1674
>nTSecurityDescriptor: [DACL] OBJ ALLOW;[CONT INHERIT][INHERIT ONLY][INHERITED];[LIST CHILDREN][READ PROP][LIST OBJ][READ];;inetOrgPerson;RU
>nTSecurityDescriptor: [DACL] OBJ ALLOW;[CONT INHERIT][INHERIT ONLY][INHERITED];[LIST CHILDREN][READ PROP][LIST OBJ][READ];;group;RU
>nTSecurityDescriptor: [DACL] OBJ ALLOW;[CONT INHERIT][INHERIT ONLY][INHERITED];[LIST CHILDREN][READ PROP][LIST OBJ][READ];;user;RU
>nTSecurityDescriptor: [DACL] ALLOW;[CONT INHERIT][INHERITED];[LIST CHILDREN];;;S-1-5-21-1862701446-4008382571-2198042679-1674
>nTSecurityDescriptor: [DACL] ALLOW;[CONT INHERIT][INHERITED];[FC];;;EA
>nTSecurityDescriptor: [DACL] ALLOW;[CONT INHERIT][INHERITED];[LIST CHILDREN];;;RU
>nTSecurityDescriptor: [DACL] ALLOW;[CONT INHERIT][INHERITED];[CR CHILD][LIST CHILDREN][SELF WRT][READ PROP][WRT PROP][LIST OBJ][CTL][DEL][READ][WRT PERMS][WRT OWNER];;;BA
>nTSecurityDescriptor: [SACL] (FLAGS:INHERIT)
>nTSecurityDescriptor: [SACL] OBJ AUDIT;[CONT INHERIT][INHERIT ONLY][INHERITED][SUCCESS];[WRT PROP];gPLink;organizationalUnit;WD
>nTSecurityDescriptor: [SACL] OBJ AUDIT;[CONT INHERIT][INHERIT ONLY][INHERITED][SUCCESS];[WRT PROP];gPOptions;organizationalUnit;WD

2 Objects returned

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