ldap and Active directory notes...

Need a place to squirrel my notes about LDAP and Active Directory. This seems as good a place as any. Have a bunch of book marks in Del.icio.us but they're unorganized and there's no naritive to link them together.

So I'm having issues with sun's Identity sync for windows product (which they seem to have renamed). I like the product, but this issue is driving me crazy. We have an intermediate fix for now, but I need a long term fix. At any rate, here's my crib-sheet of LDAP and AD links and notes.

Finding your Active Directory Site and Domain Controllers

This is an interesting read, gives you the ldapsearch syntax to ask AD via LDAP who your domain controllers are.

Querying Active Directory with Unix LDAP tools.

Another good one, goes into some more details.

Using ldapsearch to query Active Directory

This is a Mac-slanted version of some of the same stuff covered already.

It's worth noting I'll be using the ldapsearch syntax from OpenLDAP. I used MacPorts to intsall OpenLDAP on my MacBook Pro. The Sun ldapsarch has a different syntax but can do the same things.

So one of the things I was having trouble with is finding the domain controllers so I can add the BIO domain to the ISW. I could see them, but for what ever reason ISW couldn't. I assumed that there was some issue with the username I was binding with. Turns out, that's not the case.

For the first domain I'd run the following and get:

ldapsearch -v -H ldaps://<Domain_Controller_domain1> -x -b "ou=domain controllers,DC=<DOMAIN>,DC=<FOREST>" -D "<BIND_USER>" -W "(objectclass=computer)" "distinguishedName | dNSHostName | name"

ldap_initialize( ldaps://<Domain_Controller_domain1> )

Enter LDAP Password:

filter: (objectclass=computer)

requesting: distinguishedName|dNSHostName|name

# extended LDIF

#

# LDAPv3

# base <ou=domain controllers,DC=<DOMAIN1>,DC=<FOREST>> with scope subtree

# filter: (objectclass=computer)

# requesting: distinguishedName|dNSHostName|name

#

# <DC_NAME1>, Domain Controllers, <DOMAIN1>.<FOREST>

dn: CN=<DC_NAME1>,OU=Domain Controllers,DC=<DOMAIN1>,DC=<FOREST>

# <DC_NAME2>, Domain Controllers, <DOMAIN1>.<FOREST>

dn: CN=<DC_NAME2>,OU=Domain Controllers,DC=<DOMAIN1>,DC=<FOREST>

What'd you would expect to find, the list of domain controllers. There were actually 52 in my list, but you get the idea. If you take the "distinguishedName | dNSHostName | name" off the end, it will give you a lot more details about each DC record.

ldapsearch -v -H ldaps://<Domain_Controller_DOMAIN2> -x -b "ou=domain controllers,DC=<DOMAIN2>,DC=<FOREST>" -D "<BIND_USER>" -W "(objectclass=computer)" "distinguishedName|dNSHostName|name"

ldap_initialize( ldaps://<Domain_Controller_DOMAIN2> )

Enter LDAP Password:

filter: (objectclass=computer)

requesting: distinguishedName|dNSHostName|name

# extended LDIF

#

# LDAPv3

# base <ou=domain controllers,DC=<DOMAIN2>,DC=<FOREST>> with scope subtree

# filter: (objectclass=computer)

# requesting: distinguishedName|dNSHostName|name

#

# <DC_NAME3>, BP1 Domain Controllers, Domain Controllers, <DOMAIN2>.<FOREST>

dn: CN=<DC_NAME3>,OU=BP1 Domain Controllers,OU=Domain Controllers,DC=<DOMAIN2>,DC=<FOREST>

# <DC_NAME4>, BP1 Domain Controllers, Domain Controllers, <DOMAIN2>.<FOREST>

dn: CN=<DC_NAME4>,OU=BP1 Domain Controllers,OU=Domain Controllers,DC=<DOMAIN2>,DC=<FOREST>

# <DC_NAME5>, BP2 Domain Controllers, Domain Controllers, <DOMAIN2>.<FOREST>

dn: CN= <DC_NAME5>,OU=BP2 Domain Controllers,OU=Domain Controllers,DC=<DOMAIN2>,DC=<FOREST>

Almost what you'd expect to see. And I thought it was exactly what I'd expect to see. But what I noticed later is that there's an extra OU, which adds no value, I might add, no policies are set at that OU level, inserted into the domain structure. Someone wanted to tidy up and made OU=BP2 Domain Controllers and OU=BP1 Domain Controllers and flung all the DC's into those two folders. Turns out ISW doesn't traverse sub-OU's and that's why it wasn't getting the missing DOMAIN2. Quick fix was to move a few DC's up a level, let it do the discovery and then run with it. But if I didn't have the ldapsearch ability, I probably would have never figured it out.

Further investigating has put me in the hunt for how to find out who has the PDC FMSO role via LDAP, because that seems to be where I'm falling down now. The adventure continues and I'm sure I'l be updating this...