Omldapsync HowTo - Three
Managing Groups (PDLs) with LDAP
Groups can be managed from OpenLDAP and subsequently synchronized to Scalix where they will appear as Public Distribution Lists (also termed “Groups” in the Scalix Administration Console). The members of the group in OpenLDAP can be internet users or they can have Scalix mailboxes. For example, assume the same scenario described in the beginning of the is document – where the LDAP directory contains two users that have been synchronized to Scalix. Mildred Mouse is an internet user, and Dora Duck has a Scalix account.
You can make a group of these two users within LDAP, using an LDIF file and the ldapadd command. The format of the LDIF file is as follows:
$ cat /tmp/group dn: cn=testgroup,dc=mydomain,dc=net objectClass: groupOfNames cn: testgroup member: uid=mmouse,dc=mydomain,dc=net member: uid=dduck,dc=mydomain,dc=net objectClass: scalixGroupClass scalixScalixObject: TRUE scalixMailnode: mail,node scalixEmailAddress: testgroup@fubar.mydomain.net displayName: Testgroup
On the LDAP server, add to LDAP with ldapadd.
$ ldapadd -x -D cn=admin,dc=mydomain,dc=net -w secret -f /tmp/group
or
$ ldapadd -D "cn=directory manager" -w secret -f /tmp/group
On the Scalix server, synchronize:
omldapsync -u 13fubar
You can omsearch for the PDL, or group:
# omsearch -e s=testgroup S=testgroup2/OU1=mail/OU2=node/CN=Testgroup/INTERNET-ADDR=testgroup@fubar.mydomain.net/ENTRY-TYPE=4/DL-POLICY=0/FOREIGN-ADDR=cn\=testgroup,dc\=mydomain,dc\=net/ADMINISTERED-BY=ldapsync-13fubar/DL-MEMBERS=[CN=Mildred Mouse/G=Mildred/S=Mouse/OU1=internet]=[CN=Dora Duck/G=Dora/S=Duck/OU1=mail/OU2=node]
You can also see that the members' entries have been updated to reflect their membership in the PDL, or group:
# omsearch -e s=duck CN=Dora Duck/G=Dora/S=Duck/OU1=mail/ADMINISTERED-BY=ldapsync-13fubar/FOREIGN-ADDR=uid\=DDuck,dc\=mydomain,dc\=net/INTERNET-ADDR=dora.duck@mydomain.net=dduck@mydomain.net=dora.duck@fubar.mydomain.net/OU2=node/UL-AUTHID=DDuck/UL-IL=ENGLISH/UL-CAPS=6/ENTRY-TYPE=1/UL-CLASS=Full/PARENT-DL=704
Integrating Existing Scalix Mailboxes into LDAP
Sometimes you will have an existing Scalix implementation that you want to integrate with LDAP. To do that, we'll need to populate the LDAP directory with Scalix users in a way that will cause both LDAP and Scalix to accept them and to establish the fact that the entries are being administered in LDAP rather than Scalix.
Assume you have a Scalix account for Portly Pig, but Portly doesn't have an entry in the LDAP directory.
# omshowu -n pig Authentication ID: Portly.Pig@sxlab.mydomain.net Globally Unique ID: 14b10000d320aa74-121.0.861.291 User Name : Portly Pig /CN=Portly Pig MailNode : mail,node Internet Address : "Portly Pig" <Portly.Pig@sxlab.mydomain.net> System Login : 60538 Password : set Admin Capabilities : NO Mailbox Admin Capabilities : NO Language : C Mail Account: Unlocked Last Signon : Never. Receipt of mail : ENABLED Service level : 0 Excluded from Tidying : NO Recovery Folder visible : NO User Class : Full SIS URL : sxidx://sxlab.mydomain.net/04b10000d320aa74-121.0.861.291
Ensure that omldapsync -u will run without error. If you have any errors, fix them before proceeding.
Add the Portly Pig entry to the LDAP directory:
$ cat /tmp/addpig dn: uid=ppig,dc=mydomain,dc=net uid: ppig sn: Pig givenname: Portly cn: Portly Pig userpassword: PigPass objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson objectClass: scalixUserClass scalixScalixObject: TRUE scalixMailnode: mail,node scalixServerLanguage: ENGLISH scalixAdministrator: TRUE scalixMailboxAdministrator: TRUE scalixEmailAddress: ppig@sxlab.mydomain.net
OpenLDAP:
$ ldapadd -x -D cn=admin,dc=mydomain,dc=net -w secret -f /tmp/addpig
SunONE:
$ ldapadd -D "cn=directory manager" -w secret -f /tmp/addpig
Now we "trick" omldapsync into accepting the entry as foreign. This takes several steps.
omldapsync -u 13fubar -n
This causes omldapsync to show what updates would normally be made, without actually applying them. Thus, omldapsync updates its working files so that the new LDAP entry for Portly Pig is added to search.curr, but no additions to the Scalix directory are attempted.
omldapsync -u 13fubar -A
This causes omldapsync to run and accept all errors. Without the -A option, we'd get an error saying "[OM 8024] The name/mailnode "CN=Portly Pig/G=Portly/S=Pig/OU1=mail/OU2=node/INTERNET-ADDR=ppig@sxlab.mydomain.net" already exists. The name/mailnode is that of an existing user." We know this name exists, and it's okay. So we accept the error and run omldapsync anyway.
Incidentally, you cannot just run omldapsync -A the first time; the errors have to have been generated before they can be accepted.
Now we change the global-unique-id in Scalix. We want to use the one in LDAP, because that's where we will be administering the Portly Pig account from now on. The LDAP global-unique-id is authoritative.
First, find the LDAP global-unique-id.
OpenLDAP:
$ ldapsearch -h fubar.mydomain.net -x -b dc=mydomain,dc=net cn="portly pig" entryUUID
Sun ONE:
$ ldapsearch -h fubar.mydomain.net -b dc=mydomain,dc=net "cn=portly pig" nsUniqueId
# ppig, mydomain.net dn: uid=ppig,dc=mydomain,dc=net entryUUID: e701c65e-70e6-102c-8b25-1be75418929d
Now, copy the global-unique-id into the Scalix entry. This takes two ommodent commands:
# ommodent -e cn="portly pig" -n global-unique-id=e701c65e-70e6-102c-8b25-1be75418929d # ommodent -d userlist -t h -e cn="portly pig" -n global-unique-id=e701c65e-70e6-102c-8b25-1be75418929d
Now run omldapsync one more time, modifying all entries.
omldapsync -u 13fubar -M
This causes omldapsync to attempt to modify all the records in the directory, so it can take a while for this command to run. After this command is run, you can do an omsearch for the Portly Pig account and you will see it is administered-by ldapsync-13fubar.
Understanding the Mapping Table
One of the most important parts of the sync agreement is the mapping table. The mapping table comprises one section of the configuration file which was made when you created the omldapsync agreement. The mapping table for each agreement can be found in /var/opt/scalix/sb/s/ldapsync/13fubar/sync.cfg, where 13fubar is the name of the sync agreement.
A mapping table is a collection of mapping rules which will be applied to every record that is imported or exported between the Scalix directory and LDAP via omldapsync.
Each mapping rule consists of 4 fields separated by “|” of the form
<from_tag>|<to_tag>|<from_value>|<to_value>
Below are some sample entries from the mapping table for a type 13 sync agreement. Because type 13 agreements only import from LDAP to Scalix, these mappings are all from LDAP attributes to Scalix attributes.
The first shows that the LDAP uid becomes the Scalix UL-AUTHID. Only the attribute name changes; the value remains the same.
# authentication id uid|UL-AUTHID|*|*
The global unique ID is derived from the entryUUID of an OpenLDAP record, and from the nsUniqueID attribute of a Sun ONE Directory Server record.
OpenLDAP:
# global unique id entryUUID|GLOBAL-UNIQUE-ID|*|*
Sun ONE:
# global unique id nsUniqueId|GLOBAL-UNIQUE-ID|*|*
The common name in Scalix can be derived a few different ways:
# common name cn|CN|*,1,64!ISMISSING=displayName|* cn||*|#suppress it otherwise displayName|CN|*,1,64|*
The first line says that if the LDAP record does NOT contain a displayName, use the substring of the LDAP cn attribute beginning at position 1 but only going to position 64. This is because the Scalix CN cannot exceed a length of 64 characters.
The second line says that if cn exists (and there is a displayName), we'll just ignore it by mapping it to nothing.
The third line says if a displayName is present in the LDAP record, map it to the Scalix CN attribute, but don't exceed 64 characters in length.
Although this looks daunting, if you consult the man page for omldaputil, it won't be nearly as mystical :-) It's all explained very nicely.
