adamsync

Fri, 24 Aug 2012 00:00:00 +0000

Following on from my post about getting ADAM to work with Openfire, using adamsync to pull in information from the source domains was also an interesting experience.

Adamsync uses an xml file to define what it should pull in, and what it should do with it. There are plenty of references out there to adamsync and the XML file, so I won’t go into any general detail.

Groups and Users

The ‘object-filter’ tag in the file can be used to look for Groups in the same file as is used to sync users. The ‘user-proxy’ tag is only used for the appropriately specified classes, so groups will just be imported as groups (with all the attributes that you set to include).

The caveat of this is that the ampersand (at least - I haven’t come across any other characters) will need to be encoded ala HTML. So a valid value for object-filter is:

(|(&(objectCategory=person)(objectClass=user))(objectClass=group))

This will find users who are persons and groups. Just ensure you include the attributes you want for the group ! (i.e. ‘member’)

Narrowing the scope / Multiple sources

The ‘base-dn’ tag can be used more than once - so you can specify more than one OU/Container that your users/groups are saved within to sync with ADAM. This becomes important a bit later in this post ;)

Universal Groups

When syncing a Universal Group that contains members outside of the domain in which it resides, the log file for the sync can contain:

Will not synchronize dn-ref to . Target does not exist.

adamsync cannot find the member outside of the domain and so does not include it in the group. I have no idea how to fix this - I put in a workaround - I create a universal group in the adam instance and have a script that runs on a schedule that will populate it with userProxy objects that have been created in certain OU/Containers within the instance.

Deleting a user from a source domain

If you delete Â a user from the directory that ADAM is synchronising with, it can haveÂ unforeseenÂ consequences. This thread led me discover this.

What I found (so YMMV) is that if a user is deleted from AD then the next time that adamsync runs it will state “ldap error occured” for that object. If the user is moved to a container that adamsync does not have visibility on then adamsync will delete the user from ADAM. The userProxy object also appears to be deleted from ADAM groups aswell !

There is a blog entryÂ here that mentions that permissions could be given on the deleted objects container - this isn’t something I’ve tried yet so have no idea if that would work.

Error: 317 when running sync

This I’ve had when installing an XML file with adamsync as one user and trying to run it as a user. The only way I’ve avoided this is to either:

a) Log on interactively or b) Run a cmd windowÂ as the user I will be running the /sync or /fs command as.

If you opt for (b) then you’ll need to log on with the profile of the user, so the command to start the cmd window would be:

runas /profile /user:DOMAIN\user cmd

That’s it !

This has just been a compilation of my experiences with adamsync and Openfire for 3 domains and 2 forests. It’s been reliable and easy to use since setting it up, though I wish the ageing of entries would be better. Hope this helps !

ADAM / LDS

Mon, 30 Jul 2012 00:00:00 +0000

A recent project has been to configure an ADAM instance to allow Openfire (homepage) to allow users from multiple domains to connect to it. It has been interesting and at times frustrating. I wanted to sync to two domains, both in the same forest and create userProxy objects in the ADAM instance to allow for binding.

There is a source document for using ADAM with Openfire at this link.Â

The first thing I tried wasn’t ADAM running on Server 2003 - it was Lightweight Directory Services running on Server 2008. This worked for the most part - I set up two domains and my adamsync XML files to sync them to the domainDNS objects that I had created. They synced without any problems. Then I tried to use Openfire with the root partition object and immediately found 0 users.

The root cause of this issue is that when you create a domainDNS object in LDS, the instanceType attribute has a value of 5 - this indicates it is writeable and at the top of the partition. So by creating two domainDNS objects I had created two additional partitions in my instance and Openfire does not appear to be able to traverse partitions when looking for users.

Fair enough. I tore the instance down and started again from scratch, thinking “I’ll just put all the users in the one partition I create”. This didn’t work either - adamsync in LDS will only sync to the top of a partition, and you can only have one adamsync configuration per partition. So I could sync one domain and nothing else - leaving me in exactly the same situation as I am if I point Openfire to a single domain.

There was only one thing for it Â - going back to ADAM on Server 2003. This worked ! How come ?

- domainDNS objects have instanceType set to 4 (writeable) and because they do not have the “top of partition” bit set, they do not represent a new partition. - adamsync can sync to these domainDNS objects, which aren’t at the top of a partition, without a complaint. I didn’t try syncing to CN’s or OU’s though ;)

Hence I can put the users from two domains into one ADAM instance. So, if you are looking at using Openfire with multiple domains and you decide to go the ADAM route - ignore LDS, stick to 2003 !

Adam on Neale's Corner

adamsync

ADAM / LDS