I added support for the input DN control in AdFind V01.39.00. What is the input DN control? It is a new control for Windows Server 2008 which will show you the RODC caching policy for a given (or set of) RODC(s) for a given security principal. This is done by specifying the LDAP_SERVER_INPUT_DN_OID control and with the DN of the security principal while asking for the msDS-IsUserCachableAtRodc attribute for the RODC computer objects.
Today while testing the functionality with a matching shortcut (so you don’t have to remember the switches and attribute to use) of –sc rodc_cachable:secprin_DN it initially worked fine
[Mon 12/29/2008 11:37:55.97]
F:\Dev\Current\CPP\AdFind\Debug>adfind -sc rodc_cachable:cn=testuser,cn=users,dc=trouble,dc=loc -exterr
AdFind V01.39.00cpp ***BETA*** Joe Richards (joe@joeware.net) December 2008
Transformed Filter: (&(objectcategory=computer)(useraccountcontrol:1.2.840.113556.1.4.803:=67108864))
Using server: TROUBLE-DC1.trouble.loc:3268
Directory: Windows Server 2008
dn:CN=TROUBLE-RODC1,OU=Domain Controllers,DC=trouble,DC=loc
>msDS-IsUserCachableAtRodc: 2 [CACHABLE(2)]
1 Objects returned
but then I tried it on a second security principal that I thought I had created but hadn’t.
[Mon 12/29/2008 11:38:38.41]
F:\Dev\Current\CPP\AdFind\Debug>adfind -sc rodc_cachable:cn=testuser1,cn=users,dc=trouble,dc=loc -exterr
AdFind V01.39.00cpp ***BETA*** Joe Richards (joe@joeware.net) December 2008
Transformed Filter: (&(objectcategory=computer)(useraccountcontrol:1.2.840.113556.1.4.803:=67108864))
Using server: TROUBLE-DC1.trouble.loc:3268
Directory: Windows Server 2008
ldap_get_next_page_s: [TROUBLE-DC1.trouble.loc] Error 0x1 (1) – Operations Error
Extended Error: 00002121: SvcErr: DSID-0312048E, problem 5012 (DIR_ERROR), data 8333
0 Objects returned
and as you can see I got an error. I didn’t expect that error. I am documenting it here for anyone who may run into it later (including myself) so they are aware of what happened.
The error, 2121, decodes to
ERROR_DS_CANT_RETRIEVE_ATTS winerror.h
# The search failed to retrieve attributes from the database.
Initially I thought it should just return 0, not cached. But then thought, well the DN is wrong, shouldn’t we tell the user somehow that they may have screwed up? So from that angle it makes sense.
Oh, here is what it looks like for an account that isn’t cached.
[Mon 12/29/2008 11:38:44.07]
F:\Dev\Current\CPP\AdFind\Debug>adfind -sc rodc_cachable:cn=administrator,cn=users,dc=trouble,dc=loc -exterr
AdFind V01.39.00cpp ***BETA*** Joe Richards (joe@joeware.net) December 2008
Transformed Filter: (&(objectcategory=computer)(useraccountcontrol:1.2.840.113556.1.4.803:=67108864))
Using server: TROUBLE-DC1.trouble.loc:3268
Directory: Windows Server 2008
dn:CN=TROUBLE-RODC1,OU=Domain Controllers,DC=trouble,DC=loc
>msDS-IsUserCachableAtRodc: 0 []
1 Objects returned
Here is what the shortcut decodes to if you want to do it manually in AdFind V01.39.00 or better…
-f (&(objectcategory=computer)(useraccountcontrol:AND:=67108864))
-gcb
-inputdn cn=administrator,cn=users,dc=trouble,dc=loc
-recmute
-samdc
Selected Attributes
msDS-IsUserCachableAtRodc
