Difference between revisions of "Omldapsync HowTo - Three"

From Scalix Wiki
Jump to: navigation, search
 
(Managing Groups with LDAP)
Line 1: Line 1:
== Managing Groups with LDAP ==
+
== Managing ==
 
   
 
   
 
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.
 
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.

Revision as of 14:06, 18 March 2008

Managing

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 Porky Pig, but Porky doesn't have an entry in the LDAP directory.

  1. omshowu -n pig

Authentication ID: Porky.Pig@sxlab.mydomain.net Globally Unique ID: 14b10000d320aa74-121.0.861.291 User Name : Porky Pig /CN=Porky Pig MailNode : mail,node Internet Address : "Porky Pig" <Porky.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 Porky Pig entry to the LDAP directory: $ cat /tmp/addpig dn: uid=ppig,dc=mydomain,dc=net uid: ppig sn: Pig givenname: Porky cn: Porky 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 Porky 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. omldapsync -u 13fubar -M This causes omldapsync to attempt to modify all the records in the directory. It will cough up an error when it tries to modify the Porky Pig account, because the global-unique-id in LDAP is different from the one in Scalix. 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 Porky 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="porky pig" entryUUID Sun ONE: $ ldapsearch -h fubar.mydomain.net -b dc=mydomain,dc=net "cn=porky pig" nsUniqueId

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

  1. ommodent -e cn="porky pig" \

-n global-unique-id=e701c65e-70e6-102c-8b25-1be75418929d

  1. ommodent -d userlist -t h \

-e cn="porky pig"/ul-type=primerecip \ -n global-unique-id=e701c65e-70e6-102c-8b25-1be75418929d Now run omldapsync one more time, modifying all entries. omldapsync -u 13fubar -M

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 authid. Only the attribute name changes; the value remains the same.

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

  1. global unique id

entryUUID|GLOBAL-UNIQUE-ID|*|*

Sun ONE:

  1. global unique id

nsUniqueId|GLOBAL-UNIQUE-ID|*|*

The common name in Scalix can be derived a few different ways:

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