Add ActiveDirectory integration for existing users?

[jmoses]

I've got a question about active directory integration.

We're trialling Scalix now, and want to setup a bunch of users to test the new system.

If we purchase Scalix, we'll be making use of the "Active Directory" integration. However, we won't want to delete the already existing accounts, but we will want them to be managed via AD.

Is there a way to "link" exiting AD accounts with exiting Scalix accounts so that future changes will be handled via AD, but the existing mail for those accounts doesn't get deleted?

Thanks,
-jon

[Valerion]

How many accounts are you talking about? What I did on my home test machine is to omcpoutu the mailboxes, then delete the accounts, sync with AD, then omcpinu the mailbox data from earlier. This is, however, a bit labor-intensive for many users.

I'm not sure if there's a way to set this up to link into another authentication source.

[Derek]

It seems that for users managed through AD there is an attribute in their directory entry that looks like:

Code: Select all

ADMINISTERED-BY=ldapsync-<sync agreement name>

I'm wondering if all you need to do is add that attribute/value pair.

[jmoses]

How many accounts are you talking about?

I'm not sure yet. At least a couple of dozen, probably.

I'm wondering if all you need to do is add that attribute/value pair.

That would be so awesome. I'll have to setup our AD to play nice with Scalix and try it.

[Valerion]

It seems that for users managed through AD there is an attribute in their directory entry that looks like:

Code: Select all

ADMINISTERED-BY=ldapsync-<sync agreement name>

I'm wondering if all you need to do is add that attribute/value pair.

I think you will also need to add GLOBAL-UNIQUE-ID (the same as the UUID in my LDAP) and FOREIGN-ADDR (contains my DN from LDAP, with "=" replaced by "\="). Problem is, if you change the GLOBAL-UNIQUE-ID, the link between the entry in the USERLIST and SYSTEM directories may be broken, causing issues. Not sure how to prevent this from happening.

Interestingly enough I don't have an ADMINISTERED-BY attribute, even though my user accounts are created from a OpenLDAP directory.

[florian]

Administered-by was introduced to ldapsync in Scalix 10; the main purpose is to tag the entries with the agreement so that they can be easily recognized and deleted if necessary. omldapsync has an option since 10.0 that allows entries associated with an agreement to be deleted.

I assume you have created those entries initially with a pre-10 version. It might also be that the sync.cfg template you used for openldap integration simply does not contain the mapping for administered-by. it is just another attribute. check the ldapsync11.cfg Scalix 10 AD template for an example.

On the actual task, please see the note below from Karl who runs our US professional services team... Hope this helps. Example is OpenLDAP but AD would work in a similar way. The key attribute is the UUID.
Florian.

FYI - this works like a champ. I'll be owning a technote and some scripts,
delivered by end of Q1, then we can close this as fixed.

Prerequisites
- OpenLDAP v3 (Linux rpms will be 2.1 or later)
- Scalix 10 or later

Assumptions
- Scalix mailboxes already exist – but do not exist on the OpenLDAP side
- Scalix directory entries are removed – only mailboxes exist

Steps (High Level)
1. Extend the schema on OpenLDAP using ldapsync13.schema
2. Setup and test the omldapsync agreement (-c), make sure it is working
correctly, no errors.
3. Perform initial load of OpenLDAP entries into Scalix (optionally, if there
are no OpenLDAP entries, skip this step)
4. Load existing Scalix mailbox entries (and attributes) into OpenLDAP
5. Run omldapsync –n –u sync-id (test add of the user, no actual add)
6. Run omldapsync –A –u sync-id (accepts test results, no actual mod)
7. Run omldapsync –M –u sync-id (modifies all)
8. Populate OpenLDAP entryUUID’s into Scalix (Global-Unique-ID) with ommodent
9. Run omldapsync –M –u sync-id (modifies all)

When this last step runs, it will apply any differences in the OpenLDAP attribs
directly to the Scalix user (who's GUID matches the UUID), hence you've got to
get as close as possible attribute matching in Step 4.

Script that need to be written to help automate this process for future
customers would be for Step 4 (ldapsearch from Scalix, morph to LDIF, ldapadd to
OpenLDAP) and for Step 8 (ldapsearch OpenLDAP on UID and entryUUID, morph to
script with multiple ommodents to be run against Scalix)

[Derek]

Administered-by was introduced to ldapsync in Scalix 10; the main purpose is to tag the entries with the agreement so that they can be easily recognized and deleted if necessary. omldapsync has an option since 10.0 that allows entries associated with an agreement to be deleted.

What about changing this attribute?

Right now I have about 5 users on Scalix, all of which were created by AD via an omldapsync. However, I want to change the agreement and the name of it. Can I just change this attribute via ommodent for those users to the new agreement?

[florian]

Why would you want to change the name of the agreement?

In theory that should be possible - again, the only case in which the field is relevant for omldapsync is when you use the delete-all-imported-by functionality of omldapsync in scalix 10.

-- Florian.

[Derek]

I want to change the name of it just for the sake of continuity.

I originally named it after the hostname of the DC I was hitting at the time. All of our DC's are named with the convention <hostname>.corp.abc.com

The AD/network manager recently showed me that just pointing to corp.abc.com will cause the first responding DC to be used. I like this approach much better since we seem to be having a problem with our DC's lately. Additionally, where our Scalix box sits, there are two DC's within the same subnet. I figured this would provide pseudo-load-balancing functionality.


I'm not sure I follow your comment. Are you saying that the ADMINISTERED-BY attribute plays no role in the importing/updating of users, only the "delete-all-imported-by" function? So any user can be updated by any sync agreement?

[florian]

In principle, yes; the connection is acutallly made by the GLOBAL-UNIQUE-ID attribute being used to identify the record.

So, just renaming the directory in which the agreement is stored and changing the agreements name in sync.cfg is fine. You can certainly change the attribute's value for additional consistency.

Florian.

[Derek]

Ok, good info to know. Thanks as always for the prompt replies.