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...

Sun Identity Sync for Windows troubles...

Sun's Identity Sync for Windows has been a pain in my butt lately. Turns out ISW doesn't make it easy to point at new global catalogs.

Products in play:

• MS WIndows AD (unsure of AD version right now, servers are 2k3).



• SunONE identity Server 5.2 patch 2



• Sun Identity Sync for WIndows 2004Q3

So what brought this about? At ${CLIENT} they have an application that for various reasons can not authenticate directly against AD for credentials and group memberships. It needs some attributes set for the user and setting those in AD was problematic, if I remember correctly. This was set up a long time ago and a lot as changed, so if we were doing this from scratch today, it's likely that this version could be made to work with AD. The latest version of this Documentum product does support native AD anyway so it's kind of a moot point. Anyway, on the 'issue' at hand.

The theory of operation is that an account is created in AD, added to the appropriate AD ou's, groups, and given the correct attributes. ISW then takes that information and creates the corresponding LDAP entries. After creation, ISW then montiors AD for changes and makes the corrisponding LDAP changes. It does this by talking/listenting to the Domain Controller (DC) with the PDC FSMO role. Now when a user changes their password, the ISW sees this. But it's not a domain controller so it can't actually capture the password. So ISW does the next best thing, it tells LDAP that the stored password it has is invalid and that it needs to verify AD for it next time the user logs in. So if I change my password, the LDAP password entry gets set to PW-NEEDS-SYNC (i'll try to find an actual entry to get the 'real' value). Anyway, when I try to log in via LDAP, the LDAP server takes the uname and password credentials I have provided and does a bind to an AD server with my credentials. It's the actual password I provided, not an encrypted hash or what not, which is why all of this is done over SSL This uname/password pair is then used to attempt a bind to the AD servers via LDAP. If the bind is succesfull, LDAP does two things: One, it lets me into the app. Two, it stores that password it just used as the new LDAP password, and presto, it has my 'changed' password. Pretty clever.

Now on to my story. So this has been working, not perfectly, but it worked, It talked to three AD servers I'll call them DC2, DC4 and VDC1. So, DC2 is my PDC role, and DC4 and VDC1 are the DC's we were using to talk to the two domains in play. Well, $CLIENT is moving their data center from Falls Church, VA to a CSC facility in Chicago. The datacenter move as been a great project. I should write up some of my experiences with that. It went about as well as could be expected. Part of this is to migrate to new domain controllers. So my DC2, DC4 and VDC1 are going away. Three big problems: One, DC2 is the SSL-CA for the enterprise (they failed to notice this and migrate it's services). Two, the AD team didn't realize they had an ISW/LDAP dependancy. Three, ISW doesn't let you simply repoint the Global Catalogs or Domain Controllers. Anyway, water under the bridge, we stood up a new enterprise CA, installed certs on the DC's and allowed LDAPS on them.

The big troubles have been with repointing ISW. Turns out you have to uninstall the ISW connectors and reinstall them to repoint them. Once you do that you can specify a new global catalog from which the ISW can learn the PDC FSMO role from. One issue we did come across is that when the ISW does a search for DC's in the GC, it does something equivelent to:

ldapsearch -v -H ldaps://<DC-hostname> -x -b "ou=domain controllers,DC=<DOMAIN TREE STUFF>t" -D "<USER TO LOG IN AS>" -W "(objectclass=computer)"

But it doesn't traverse sub-folders. So if your domain controllers are 'organized' into sub-folders, you're sunk. This happened in my case. The quick fix was to move a few 'core' DCs to the top level. This allowed ISW to find the DC's to talk to. I'm still having issues getting it work with the GC correctly for some reason. My ticket has been open with SUN for over a month now.

More to come I'm sure...

HP's Array-based Replication Cookbook

Found the following article on the Wikibon storage portal today.

HP's Array-based Replication Cookbook

It came out in December of 2007, but it provides a great overview of how a potential oracle 11G with ASM (booooooo) and HP EVA8x00 arrays would work.

From the PDF:

This white paper provides a comprehensive set of test-proven best practices for properly configuring, deploying, and operating an Oracle 11g database with Oracle’s Automatic Storage Manager (ASM) on an HP Enterprise Virtual Array (EVA), using Continuous Access (CA) as the remote copy infrastructure.

It's a good read, even if you're not an EVA or ASM person. It's a revist of the same topic they did for 10G/ASM/8x00. Nice to see them update it, although they seem to have forgotten to update some of the graphics...

Ooops... Should be 11G RAC.

Rijndael animation...

So if you ever wanted a a graphical representation of how Rijndael works, want no more.

Formaestudio.com hosts a great rijndael inspector animation.

It walks through the encryption process step by step.

Playing with simple logo ideas...

So I need a logo. Well, not a logo so much as a graphic for my simple website. I'm playing with "Art Text" a neat app for making text into logo-esc graphics.

So far, I'm toying with:

or

or

Perhaps I'd do it in a green glowing font to look like an old-school terminal, which is kind of the effect I want. All these are in blue simply because blue is my favorite color.