On Sat, 2009-06-06 at 15:53 -0500, Doug Coats wrote: <snip> We are using almost an identical setup except for Dovecot and we started with DS 8.0 and upgraded to 8.1. I'm afraid I'm up to my eyeballs in a project so I can't customize this for you but I'll paste in as much of our internal documentation as would be prudent to do. You will need to understand the principles behind the steps so you can adapt it accordingly. For example, we installed the master replica on a vserver - a great project (www.linux-vserver.org) but it does introduce some complexity to LDAP. We also use a RO replica on KVM. Both are in an iSCSI environment. We also sync passwords with Active Directory for multiple clients - oh, and yes, this is a multi-tenant environment - hence the unusual hierarchical structure and bizarre ACIs. As I said, you will need to adapt but hopefully this will get you started. (and I hope it is not dropped for SPAM because of its length - hmm come to think of it, I think I'll send this email separately and then send the same email with all the notes. This way, if it does get trapped as SPAM, you can fish it out). -- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan(a)opensourcedevel.com http://www.spiritualoutreach.com Making Christianity intelligible to secular society

On Sat, 2009-06-06 at 15:53 -0500, Doug Coats wrote: <snip> We are using almost an identical setup except for Dovecot and we started with DS 8.0 and upgraded to 8.1. I'm afraid I'm up to my eyeballs in a project so I can't customize this for you but I'll paste in as much of our internal documentation as would be prudent to do. You will need to understand the principles behind the steps so you can adapt it accordingly. For example, we installed the master replica on a vserver - a great project (www.linux-vserver.org) but it does introduce some complexity to LDAP. We also use a RO replica on KVM. Both are in an iSCSI environment. We also sync passwords with Active Directory for multiple clients - oh, and yes, this is a multi-tenant environment - hence the unusual hierarchical structure and bizarre ACIs. As I said, you will need to adapt but hopefully this will get you started. (and I hope it is not dropped for SPAM because of its length - hmm come to think of it, I think I'll send this email separately and then send the same email with all the notes. This way, if it does get trapped as SPAM, you can fish it out) I'm sure there are errors in this document and would appreciate corrections, improvements, and comments from those who really know what they're doing (unlike me). Names and numbers changed to protect the innocent and my job! Create the VServer guest - probably not necessary to you - sorry but the formatting is being lost - this will be very hard to follow :-( Clone a new server named ldap1.mycompany.com with IP address 172.x.x.48/24 on the Internal VServer: vserver ldap1 build -m clone --hostname ldap1.mycompany.com --interface ethx:172.x.x.48/24 -- --source centos-basevs Set the proper /tmp file size and an adequate number of file handles for directory services: On the VServer HOST do: cd /etc/vservers/ldap1 Edit fstab by setting the options for the tmpfs mounted on /tmp to: size=128m,mode=1777,nosuid,nodev,noexec mkdir /etc/vservers/ldap1/ulimits echo 65535 > /etc/vservers/ldap1/ulimits/nofile (otherwise the DS installation will complain about only 1024 file handles available which may indeed be a problem) cd CentOS installations enforce pam_loginuid.so by default. Since it requires write access to /proc which is not available in the vserver, it will cause key processes to fail. We this disable it with the following one-line command: sed -i -e "s/^session.*required.*pam_loginuid.so/# session\trequired \tpam_loginuid.so/g" /vservers/ldap1/etc/pam.d/* Edit the /vservers/ldap1/etc/hosts file so it contains the following two lines: 127.0.0.1 localhost localhost.localdomain 172.x.x.48 ldap1 ldap1.mycompany.com Install Directory Server Start the new VServer guest (vserver ldap1 start) and connect to it (vserver ldap1 enter). The rest of these instructions assume one is on the ldap1 console unless specified otherwise. Create the ldap group and user groupadd -g 6xx ldap useradd -s /sbin/nologin -d /var/lib/dirsrv -g ldap -u 6xx ldap Edit /etc/yum.repos.d/CentOS-Base.repo by enabling the centosplus repository and adding the test repository with the following stanza: [c5-testing] name=CentOS-5 Testing baseurl=http://dev.centos.org/centos/$releasever/testing/$basearch/ enabled=0 gpgcheck=1 gpgkey=http://dev.centos.org/centos/RPM-GPG-KEY-CentOS-testing exclude=java-1.7.0-icedtea Install the directory server: yum --enablerepo=c5-testing install centos-ds java-1.6.0-openjdk After centos-ds and its many dependencies have installed, install these additional packages: yum install xorg-x11-xauth bitstream-vera-fonts dejavu-lgc-fonts urw-fonts firefox Run setup-ds-admin.pl Enter yes to continue and to accept the license terms The setup routine will run dsktune and may issue a warning about file handles or tcp keepalives. Enter yes to continue unless there is a more serious error. Choose a custom installation (because we must specify the vserver guest address) The default Computer name should be fine (ldap1.mycompany.com) System user is ldap System group is ldap There is no configuration directory server yet Administrator ID is someone Password is <password> Administration domain is mycompany.com Take the default 389 port for now. We will implement LDAPS later Directory server identifier is ldap1 Suffix is dc=mycompany,dc=com Directory Manager DN is cn=Directory Manager Use the <different password> Do not install sample entries We do not want any suggested entries so type none Take the default administration port IP address is 172.x.x.48 - NO, now that we have loopback remapping and Single IP Special Casing, we can leave this blank. NOOOO!!!!! We can't if we want to use Single IP Special Casing (which we probably do because we will be setting up lots of connections). This completely destroyed our setup when we implemented SSL. We did recover using the procedures outlined in the notes but then reinstalled anyway just in case. Run Administration Server as ldap Enter yes to set up the servers Start the console GUI with (the viewing computer must be running X and using ssh X forwarding - configured in /etc/ssh/ssh_config). Beware the idm-console windows open minimized: centos-idm-console -a http://ldap1.mycompany.com:9830 -s slapd-ldap1 Login using cn=Directory Manager and the associated password Click on the Configuration tab Select the top level item in the tree on the left side (ldap1.mycompany.com:389) and click on the SNMP tab. Fill in the following details: Name: ldap1-ds Description: Directory Server on ldap1 Organization: My Company Location: Data Center 1 Contact: Operators Go to the SASL Mapping tab and add a new item with the following details: Name: kerberos uid mapping clients Regular Expression: \(.*\)(a)\(.*\)\.\(.*\) Search Base DN: o=Internal,dc=mycompany,dc=com Search Filter: (uid=\1) Click on Save We will need to install the SAMBA schema. Copy the schema from the SAMBA server (/usr/share/doc/samba-*/LDAP/samba.schema) and download the schema importer (http://directory.fedoraproject.org/download/ol-schema-migrate.pl) Run the importer: perl ol-schema-migrate.pl -b samba.schema Even easier, copy the already created 61samba.ldif file from the test lab into /etc/dirsrv/slapd-ldap1/schema/ Change ownership and permissions on 61samba.ldif: chown ldap:ldap 61samba.ldif chmod 440 61samba.ldif Restart the directory server (service dirsrv restart) Return to the idm-console window, the Configuration tab, and click on the Data object in the left panel Click on the Passwords tab. Enable fine grained password policy User must change after reset - Oops! That's a problem with X2Go. There is currently no way to change the password on first login via X2Go. Here is the email explanation from Alex: SKIP DETAILS - another great project (www.x2go.org) Keep six passwords Password expires in 31 days Warned four days before (to account for long weekends) Allow 4 login attempts after expiration Check password syntax to enforce minimum length of 9 characters with 3 character category and a token length of 2 (We need the last two in order to synchronize with Windows AD) Click the Account Lockout tab Enable account lockout after 4 failures with a 10 minute reset. Lock out for 10 minutes - This is more than three because of X2Go. It appears to make three logins during the session setup process. Thus, a single mistyped password locks an account limited to only three failed attempts. Here is the email explanation from Alex: SKIP DETAILS Click on Save Expand Data, expand dc=mycompany,dc=com, go to the UserRoot database for dc=mycompany,dc=com. Add the nsroledn attribute. Enable the presence index for member, nsroledn, owner, seeAlso, and uniquemember. Click Save. Expand the Logs item in the left panel. Enable Audit logging allowing 5 logs rotating each week or 100 MB with total storage of 500 MB held for 40 months or delete when space is below 50MB. Click Save. Disable Access logging. Click Save. Expand the Plugins item in the left panel Click on the Referential Integrity plugin and enable it. Click on Save. Click on the attribute uniqueness plugin, enable it and change the second argument to o=Internal,dc=mycompany,dc=com. Click on Save. To this point, we have been working on the Configuration tab. Now click on the Directory tab. Left click on the top level item (ldap1.mycompany.com:389). We left click first because this java implementation does not select automatically when right clicking. Once the top level item has been selected with a left click, right click and choose New Root Object and select dc=mycompany,dc=com. Select dcobject from the ensuing dialog box and click OK and then OK again. Expand the config object in the left panel. Click on plugins Left click and then right click the attribute uniqueness plugin and choose copy. Go to mycompany, left/right click and paste. Edit the new copy of attribute uniqueness by changing the word attribute to gidnumber in the name, nsslapd-plugindescription, and entrydn fields, and the nsslapd-pluginarg0 to gidnumber. Click OK. Left click then right click the new gidnumber uniqueness entry and copy. Then paste it back into config / plugins. For some reason, the DS GUI tries to copy in everything previously copied so ignore the errors about duplicate objects. Return to the first copy under mycompany and edit it so name, description, and entrydn use uidnumber instead of gidnumber, and change nsslapd-arg0 to uidnumber. Save changes. Right click, copy, and then paste into config / plugins. Return to the first copy under ssiservices and edit it so name, description, and entrydn use cn instead of uidnumber, and change nsslapd-arg0 to cn. Save changes. Right click, cut, and then paste into config / plugins. Restart the directory server (service dirsrv restart or use the idm-console task tab) WE DO NOT ALLOW ANONYMOUS BINDS AND MUST ALLOW CLIENTS TO ADMINISTER THEIR OWN PORTION OF THE TREE SO THIS MAY NOT APPLY TO YOU. PLUS, I BELIEVE WILD CARDS IN THE GROUPDN DEFINITIONS DID NOT WORK IN 8.0 AND WE HAVE STILL NOT FIXED OUR ACIS IN RESPONSE. WE HAVE NOT TESTED THIS WTIH 8.1 We need to create a root searcher named uid=searcher,dc=mycompany,dc=com with a custom password policy that does not require the user to change the password and does not expire passwords. Create the user with givenname (or first name)=Directory, sn (or last name)=Searcher, uid=cn=searcher (all lower case - remember to change the cn). Give it the medium security password - oops - we do not want to do that as the password will be recorded in the ldap.conf file on vd1 which is world readable. Instead, us a password as would be created for a searcher user by the clientsetup script. See the script for the details. To do this: Left and then right click on mycompany in the left panel and choose New User. Set the fields as above. Save the new user, then left/right click on the new user, choose Manage Password Policy and then For user. Enable fine grained passwords on the password tab. Set the password syntax as above (9 characters, 1 character category, 7 tokens). Click Save. Next we must make many adjustments to security. Left/right click on mycompany and choose Set Access Permissions Delete the Enable anonymous access ACI (click on the ACI, then click Remove). Since we have removed anonymous access, we must grant users rights to see themselves in a different ACI. Thus, edit the "Allow self entry modification except for nsroledn and aci attributes" ACI by adding Search, Compare, and Read rights. Add a new ACI to allow the global searcher (click on New, click on Edit Manually and paste in the following: (targetattr != "sambaLMPassword || sambaNTPassword || userPassword") (version 3.0; acl "Root Searcher"; allow (read,compare,search) (userdn = "ldap:///uid=searcher,dc=mycompany, dc=com") ;) Click Check Syntax to ensure there are no errors and then click on OK. Create two more new ACIs to allow client browsing of their portion of the Internal and External branches of the tree with the following two stanzas - one for each ACI. Remember to click Check Syntax to ensure there are no errors and then click on OK.: (target = "ldap:///($dn),o=external,dc=mycompany,dc=com")(targetattr != "sambaLMPassword || sambaNTPassword || userPassword") (version 3.0;acl "Client External Directory Searcher";allow (read,compare,search)(userdn = "ldap:///uid=*searcher, [$dn],o=sysaccounts,dc=mycompany,dc=com");) (target = "ldap:///($dn),o=internal,dc=mycompany,dc=com")(targetattr != "sambaLMPassword || sambaNTPassword || userPassword") (version 3.0;acl "Client Internal Directory Searcher";allow (read,compare,search)(userdn = "ldap:///uid=*searcher, [$dn],o=sysaccounts,dc=mycompany,dc=com");) Create two more ACIs in the same way to allow client administrative access to their portions of the tree with the following two ACIs: (targetattr = "*") (target = "ldap:///($dn),o=external,dc=mycompany, dc=com") (version 3.0;acl "Client Administrators External";allow (all)(groupdn = "ldap:///cn=*ldapadmins,ou=groups,[$dn],o=internal,dc=mycompany,dc=com");) (targetattr = "*") (target = "ldap:///($dn),o=internal,dc=mycompany, dc=com") (version 3.0;acl "Client Administrators Internal";allow (all)(groupdn = "ldap:///cn=*ldapadmins,ou=groups,[$dn],o=internal,dc=mycompany,dc=com");) Now we need an explicit deny ACI to prevent client administrators from adding or deleting users (this is how we determine their billing so they must not change it). Use this ACI: (targetattr = "") (target = "ldap:///ou=Desktops,($dn),o=internal,dc=mycompany,dc=com") (version 3.0;acl "Client Internal Deny";deny (delete,add)(groupdn = "ldap:///cn=*ldapadmins,ou=Groups,[$dn],o=Internal,dc=mycompany,dc=com");) We need an ACI to allow the user account used to enumerate uids for the DSGW application for each client to browse the client's portion of the Internal tree. Use this ACI: (target = "ldap:///ou=Desks,($dn),o=Internal,dc=mycompany,dc=com")(targetattr = "uid || st || sn || ou || name || entrydn || dn || dc || objectClass || cn || o || l || c || givenName") (version 3.0;acl "Client DSGW Lister";allow (search,read)(userdn = "ldap:///uid=*gwlister,[$dn],o=sysaccounts,dc=mycompany,dc=com");) We need the following ACIs to allow users to see selected attributes of all normally viewable entries in their own tree: (target = "ldap:///($dn),o=external,dc=mycompany,dc=com")(targetattr = "documentPublisher || documentTitle || physicalDeliveryOfficeName || preferredDeliveryMethod || documentVersion || subject || postalAddress || documentStore || roomNumber || drink || givenName || vacationenddate || documentAuthor || searchGuide || teletexTerminalIdentifier || mobile || manager || entrydn || objectClass || displayName || telexNumber || secretary || uid || certificateRevocationList || st || sn || description || mail || labeledUri || documentIdentifier || uidNumber || postOfficeBox || ou || seeAlso || registeredAddress || postalCode || photo || gidNumber || preferredTimeZone || title || uniqueMember || street || preferredLocale || presentationAddress || documentLocation || pager || dn || dc || o || cn || l || c || cACertificate || telephoneNumber || preferredLanguage || facsimileTelephoneNumber || memberOf || vacationstartdate") (version 3.0;acl "Client User Rights External";allow (read,compare,search)(userdn = "ldap:///uid=*,ou=Desks,[$dn],o=Internal,dc=mycompany,dc=com");) (target = "ldap:///($dn),o=internal,dc=mycompany,dc=com")(targetattr = "documentPublisher || documentTitle || physicalDeliveryOfficeName || preferredDeliveryMethod || documentVersion || subject || postalAddress || documentStore || roomNumber || drink || givenName || vacationenddate || documentAuthor || searchGuide || teletexTerminalIdentifier || mobile || manager || entrydn || objectClass || displayName || telexNumber || secretary || uid || certificateRevocationList || st || sn || description || mail || labeledUri || documentIdentifier || uidNumber || postOfficeBox || ou || seeAlso || registeredAddress || postalCode || photo || gidNumber || preferredTimeZone || title || uniqueMember || street || preferredLocale || presentationAddress || documentLocation || pager || dn || dc || o || cn || l || c || cACertificate || telephoneNumber || preferredLanguage || facsimileTelephoneNumber || memberOf || vacationstartdate") (version 3.0;acl "Client User Rights Internal";allow (read,compare,search)(userdn = "ldap:///uid=*,ou=Desks,[$dn],o=Internal,dc=mycompany,dc=com");) Click OK to save the new ACIs. Create three Organizations directly under dc=mycompany,dc=com, viz., Internal, External, and SysAccounts. Left/right click on mycompany, choose New and then Other. Select organization from the ensuing dialog and click OK. Replace "New" with the proper name in the name field and click OK. Do this for each of the three new organizations. Set a custom password policy for SysAccounts that users do not need to change passwords after reset and passwords never expire. Left/right click on SysAccounts in the right pane (<CTL> R if the window needs to be refreshed) and choose Manage Password Policy, then For Subtree. Enable Create subtree level password policy. Set the password syntax as above (9 characters, 1 character category, 7 tokens). Click on Save and then Close. The admin server complains about not being able to determine the server name on startup. To fix this problem, edit /etc/dirsrv/admin-serv/httpd.conf and set ServerName ldap1.mycompany.com:9830 Set the services to automatically start on boot: chkconfig dirsrv-admin on chkconfig dirsrv on Configure SSL communication Copy the ldap1admin PKCS#12 package generated as part of the PKI project to /etc/dirsrv/admin-serv/. Copy the CA cert (CA.pem) to /etc/dirsrv/admin-serv/ . Change ownership and permissions, import the PKCS#12 package and CA cert into Directory Admin Server with the following commands executed on ldap1: cd /etc/dirsrv/admin-serv chown ldap:ldap CA.pem chown ldap:ldap ldap1admin.p12 chmod 600 ldap1admin.p12 pk12util -i ldap1admin.p12 -d . (N.B. The terminal "." standing for the current directory) Use the medium security SSI password to secure the certificate store (the first password prompt) certutil -A -d . -n "CA certificate" -t "CT,," -a -i CA.pem Create a file in the /etc/dirsrv/admin-serv directory named password.conf with the following contents: internal:<the password> Set permissions and ownership on it as follows: chown ldap:ldap /etc/dirsrv/admin-serv/password.conf chmod 0400 /etc/dirsrv/admin-serv/password.conf Edit /etc/dirsrv/admin-serv/nss.conf to point the NSSPassPhraseDialog parameter to file://etc/dirsrv/admin-serv/password.conf At this point, we could delete ldap1admin.p12 but we will keep it just in case we need it in the future. Restart dirsrv-admin from the command line (NOT from the console) (service dirsrv-admin restart) Copy the ldap1 PKCS#12 package generated as part of the PKI project to /etc/dirsrv/slapd-ldap1/. Change ownership and permissions, import the PKCS#12 package and CA cert into Directory Server with the following commands executed on ldap1: cd /etc/dirsrv/slapd-ldap1 chown ldap:ldap ldap1.p12 chmod 600 ldap1.p12 pk12util -i ldap1.p12 -d . (N.B. The terminal "." standing for the current directory) Use the medium security SSI password to secure the certificate store (the first password prompt) certutil -A -d . -n "CA certificate" -t "CT,," -a -i /etc/dirsrv/admin-serv/CA.pem Create a file in the /etc/dirsrv/slapd-ldap1 directory named pin.txt with the following contents: Internal (Software) Token:<the password> Set permissions and ownership on it as follows: chown ldap:ldap /etc/dirsrv/slapd-ldap1/pin.txt chmod 0400 /etc/dirsrv/slapd-ldap1/pin.txt Restart dirsrv (service dirsrv restart) Open centos-idm-console (we want the full console this time and not just the directory server (-s slapd-ldap1). Expand ldap1.mycompany.com, expand Server Group, open the Directory Server (double click in left panel or click Open on right panel). Go to the Configuration tab of the Directory Server, click on the top level item in the left panel (ldap1.mycompany.com:389), click on the Encryption tab in the right panel. Enable SSL Check the Enable this cipher family:RSA check box Click on the Settings button and uncheck any "none" or "RC2" ciphers. Click OK Enable Use SSL in Console Click Save Click OK on the warnings about setting taking effect only after restart and having to start as root to use a port below 1024. Return to the main console, open the Administration Server and go to the Configuration tab, click on the top level item in the left panel (Administration Server), click on the Encryption tab in the right panel. Enable SSL Check the Enable this cipher family:RSA check box Click on the Settings button and uncheck any "none" or "RC2" ciphers. Click OK Go to the Configuration DS tab (authentication for the Directory Services config directory) Enable Secure Connection and make sure the port changes to 636. Go to the User DS tab (configuration for the DIT (Directory Information Tree)) Click Set User Directory LDAP host and port: ldap1.mycompany.com:636 Click on Secure Connection User Directory Subtree: dc=mycompany,dc=com (we need access to both Internal and SysAccounts) Click Save Go to the Main Console Click on mycompany.com in the left pane Click on Edit at the bottom of the right pane Click on Secure Connection and set the port to 636 Click on OK Close all console windows Stop the directory server (service dirsrv stop) Restart the admin server (service dirsrv-admin restart) If the restart fails with a error about NSSNickname only takes a single argument, it is most likely because pk12util gave a nickname to the cert with spaces in it. Edit the /etc/dirsrv/admin-serv/console.conf file at the line indicated by the error and enclose the nickname in quotation marks. We may also want to edit /etc/dirsrv/admin-serv/httpd.conf by setting: ServerName ldap1.mycompany.com:9830 in order to eliminate the cosmetic error about not determining the server name. Start the directory server (service dirsrv start) We need to import the CA cert into the database of the centos-idm-console user, i.e., the user running the GUI. In their home directory is a .centos-idm-console. Enter that directory and issue the following command (assuming it is running on the same computer as the admin-server - otherwise change the CA cert source appropriately): certutil -A -d . -n "CA certificate" -t "CT,," -a -i /etc/dirsrv/admin-serv/CA.pem Close the centos-idm-console if it is still running. Reopen it but be sure to change the login Administration url to https://ldap1.mycompany.com:9830 rather than http. Click on the top level item in the left pane (mycompany.com), click edit in the right pane, enable Secure connection and change the port on the User directory host and port setting from 389 to 636. Stop the directory server (service dirsrv stop) Restart the administration server (service dirsrv-admin restart) Start the directory server (service dirsrv start) Set the services to automatically start on boot: chkconfig dirsrv-admin on chkconfig dirsrv on Create read-only replica The rest of these instructions assume one is on the ldap2 console unless specified otherwise. Create the ldap group and user groupadd -g 6xx ldap useradd -s /sbin/nologin -d /var/lib/dirsrv -g ldap -u 6xx ldap Edit /etc/yum.repos.d/CentOS-Base.repo by enabling the centosplus repository and adding the test repository with the following stanza: [c5-testing] name=CentOS-5 Testing baseurl=http://dev.centos.org/centos/$releasever/testing/$basearch/ enabled=0 gpgcheck=1 gpgkey=http://dev.centos.org/centos/RPM-GPG-KEY-CentOS-testing exclude=java-1.7.0-icedtea Install the directory server: yum --enablerepo=c5-testing install centos-ds After centos-ds and its many dependencies have installed, install these additional packages: yum install xorg-x11-xauth bitstream-vera-fonts dejavu-lgc-fonts urw-fonts firefox We will need to trust the CA in order to connect to the existing directory server via ldaps. Create the /etc/dirsrv/admin-serv directory, copy the CA cert (CA.pem) into it, and set ownership and permissions: mkdir /etc/dirsrv/admin-serv cd /etc/dirsrv/admin-serv scp as appropriate chown ldap:ldap CA.pem chmod 660 CA.pem We need to increase the number of allowable file handles. Edit /etc/sysctl.conf by adding the following line: fs.file-max = 64000 Run sysctl -p to effect the new settings Add the following line to /etc/security/limits.conf * - nofile 8192 Reboot ldap2 from the KVM console Run setup-ds-admin.pl Enter yes to continue and to accept the license terms The setup routine will run dsktune and may issue a warning about file handles. Enter yes to continue unless there is a more serious error. Choose a custom installation (because we must specify the KVM guest address) The default Computer name should be fine (ldap2.mycompany.com) System user is ldap System group is ldap We do to register with an existing directory server. The configuration directory server is ldaps://ldap1.mycompany.com:636/o=NetscapeRoot Administrator ID is someone Password is <the password> Administration domain is mycompany.com The CA cert is in /etc/dirsrv/admin-serv/CA.pem Take the default 389 port for now. We will implement LDAPS later Directory server identifier is ldap2 Suffix is dc=mycompany,dc=com Directory Manager DN is cn=Directory Manager Use a different password Do not install sample entries We do not want any suggested entries so type none Take the default administration port IP address is 172.x.x.49 Run Administration Server as ldap Enter yes to set up the servers Start the console GUI with (the viewing computer must be running X and using ssh X forwarding - configured in /etc/ssh/ssh_config - may need to enable X11Trusted). Beware the idm-console windows open minimized: centos-idm-console -a http://ldap2.mycompany.com:9830 -s slapd-ldap2 Login using cn=DirMan and the associated password Click on the Configuration tab Select the top level item in the tree on the left side (ldap2.mycompany.com:389) and click on the SNMP tab. Fill in the following details: Name: ldap2-ds Description: Directory Server on ldap2 Organization: My Company Location: Data Center 1 Contact: Operators Go to the SASL Mapping tab and add a new item with the following details: Name: kerberos uid mapping clients Regular Expression: \(.*\)(a)\(.*\)\.\(.*\) Search Base DN: dc=mycompany,dc=com Search Filter: (uid=\1) Click on Save We will need to install the SAMBA schema. Copy the schema from the SAMBA server (/usr/share/doc/samba-*/LDAP/samba.schema) and download the schema importer (http://directory.fedoraproject.org/download/ol-schema-migrate.pl) Run the importer: perl ol-schema-migrate.pl -b samba.schema Even easier, copy the already created 61samba.ldif file from the test lab into /etc/dirsrv/slapd-ldap2/schema/ Change ownership and permissions on 61samba.ldif: chown ldap:ldap 61samba.ldif chmod 440 61samba.ldif Restart the directory server (service dirsrv restart) Return to the idm-console window, the Configuration tab, and click on the Data object in the left panel Click on the Passwords tab. Enable fine grained password policy User must change after reset Keep six passwords Password expires in 31 days Warned four days before (to account for long weekends) Allow 4 login attempts after expiration Check password syntax to enforce minimum length of 9 characters with 3 character category and a token length of 2 Click the Account Lockout tab Enable account lockout after 4 failures with a 10 minute reset. Lock out for 10 minutes. Click on Save Expand Data, expand dc=mycompany,dc=com, go to the UserRoot database for dc=mycompany,dc=com. Add the nsroledn attribute. Enable the presence index for member, nsroledn, owner, seeAlso, and uniquemember. Click Save. Expand the Logs item in the left panel. Enable Audit logging allowing 5 logs rotating each week or 100 MB with total storage of 500 MB held for 40 months or delete when space is below 50MB. Click Save. Disable Access logging. Click Save. The admin server complains about not being able to determine the server name on startup. To fix this problem, edit /etc/dirsrv/admin-serv/httpd.conf and set ServerName ldap2.mycompany.com:9830 Set the services to automatically start on boot: chkconfig dirsrv-admin on chkconfig dirsrv on Configure SSL communication Copy the ldap2admin PKCS#12 package generated as part of the PKI project to /etc/dirsrv/admin-serv/. Copy the CA cert (CA.pem) to /etc/dirsrv/admin-serv/ . Change ownership and permissions, import the PKCS#12 package and CA cert into Directory Admin Server with the following commands executed on ldap2: cd /etc/dirsrv/admin-serv chown ldap:ldap CA.pem chown ldap:ldap ldap2admin.p12 chmod 600 ldap2admin.p12 pk12util -i ldap2admin.p12 -d . (N.B. The terminal "." standing for the current directory) Use the medium security SSI password to secure the certificate store (the first password prompt) certutil -A -d . -n "CA certificate" -t "CT,," -a -i CA.pem Create a file in the /etc/dirsrv/admin-serv directory named password.conf with the following contents: internal:medium security SSI password Set permissions and ownership on it as follows: chown ldap:ldap /etc/dirsrv/admin-serv/password.conf chmod 0400 /etc/dirsrv/admin-serv/password.conf Edit /etc/admin-serv/nss.conf to point the NSSPassPhraseDialog parameter to file://etc/dirsrv/admin-serv/password.conf At this point, we could delete ldap2admin.p12 but we will keep it just in case we need it in the future. Restart dirsrv-admin from the command line (NOT from the console) (service dirsrv-admin restart) Copy the ldap2 PKCS#12 package generated as part of the PKI project to /etc/dirsrv/slapd-ldap2. Change ownership and permissions, import the PKCS#12 package and CA cert into Directory Server with the following commands executed on ldap2: cd /etc/dirsrv/slapd-ldap2 chown ldap:ldap ldap2.p12 chmod 600 ldap2.p12 pk12util -i ldap2.p12 -d . (N.B. The terminal "." standing for the current directory) Use the medium security SSI password to secure the certificate store (the first password prompt) certutil -A -d . -n "CA certificate" -t "CT,," -a -i /etc/dirsrv/admin-serv/CA.pem Create a file in the /etc/dirsrv/slapd-ldap2 directory named pin.txt with the following contents: Internal (Software) Token:medium security SSI password Set permissions and ownership on it as follows: chown ldap:ldap /etc/dirsrv/slapd-ldap2/pin.txt chmod 0400 /etc/dirsrv/slapd-ldap2/pin.txt Restart the directory server (service dirsrv restart) We need to import the CA cert into the database of the centos-idm-console user, i.e., the user running the GUI. In their home directory is a .centos-idm-console. Enter that directory and issue the following command (assuming it is running on the same computer as the admin-server - otherwise change the CA cert source appropriately): certutil -A -d . -n "CA certificate" -t "CT,," -a -i /etc/dirsrv/admin-serv/CA.pem Open centos-idm-console (we want the full console this time and not just the directory server (-s slapd-ldap2), open the Directory Server for ldap2. Go to the Configuration tab of the Directory Server, click on the top level item in the left panel (ldap2.mycompany.com:389), click on the Encryption tab in the right panel. Enable SSL Check the Enable this cipher family:RSA check box Click on the Settings button and uncheck any "none" or "RC2" ciphers. Click OK Enable Use SSL in Console Click Save Click OK on the warnings about setting taking effect only after restart and having to start as root to use a port below 1024. Open the Administration Server for ldap2 and go to the Configuration tab, click on the top level item in the left panel (Administration Server), click on the Encryption tab in the right panel. Enable SSL Check the Enable this cipher family:RSA check box Click on the Settings button and uncheck any "none" or "RC2" ciphers. Click OK Go to the Configuration DS tab Enable Secure Connection and make sure the port changes to 636 and it points to ldap1.mycompany.com and not ldap2 since ldap1 houses the DS configuration. Go to the User DS tab Click on the Set User Directory radio button Set LDAP host and port to ldap2.mycompany.com:636 ldap1.mycompany.com:636 Enable Secure Connection Set User Directory Subtree to dc=mycompany,dc=com Click Save Open the ldap1 Administration Server and go to the Configuration tab, click on the top level item in the left panel (Administration Server), click on the Encryption tab in the right panel. Go to the User DS tab Click on the Set User Directory radio button Set LDAP host and port to ldap1.mycompany.com:636 ldap2.mycompany.com:636 Enable Secure Connection Set User Directory Subtree to dc=mycompany,dc=com Click Save Close all consoles. Stop the directory server (service dirsrv stop) Restart the admin server (service dirsrv-admin restart) If the restart fails with a error about NSSNickname only takes a single argument, it is most likely because pk12util gave a nickname to the cert with spaces in it. Edit the /etc/dirsrv/admin-serv/console.conf file at the line indicated by the error and enclose the nickname in quotation marks. Start the directory server (service dirsrv start) Restart the admin server on ldap1. Close the centos-idm-console if it is still running. Reopen it but be sure to change the login Administration url to https://ldap2/mycompany.com:9830 rather than http. Setup replication Create the Replication Manager entry on ldap2. Stop the directory server on ldap2 (service dirsrv stop). Edit the /etc/dirsrv/slapd-ldap2/dse.ldif file by adding the following stanza: dn: cn=repuser,cn=config uid: repuser objectClass: inetorgperson objectClass: person objectClass: top cn: repuser givenname: Replication sn: Manager userPassword: <password> passwordExpirationTime: 20380119031407Z Start the directory server (service dirsrv start) Argh! This always complains about trailing spaces. If it does, start the Directory Server and use the GUI to delete the repuser user and then create them with the above data. Be sure to change both the uid and cn to repuser and the name attribute to cn. One must save the new user and then edit the advanced properties after the first save in order to set the passwordExpirationTime as above. Argh! Apparently we cannot change the name attribute so, if we use this method, we must remember to use uid=repuser instead of cn=repuser in the Replication Agreement created below. The repuser user must have a separate password policy so the password is not required to be changed on login and does not expire. This is normally done as done previously, i.e., left/right click on the repuser user object in the ldap2 directory under cn=config. However, there is a bug in the UI which frequently makes the password manager UI unusable. If this is the case, we can create the password policy using the following process on the ldap2 directory: Left/right click on config in the left directory panel Add new other and choose nscontainer object Name the container "nsPwPolicyContainer" Left/right click nsPwPolicyContainer and add new other and choose passwordpolicy Add a new object class of ldapsubentry Add a cn attribute with value "cn=nsPwPolicyEntry,uid=repuser,cn=config" Change the naming attribute to cn (button toward bottom right of dialog) Hmm . . very strange, I was not looking forward to entering all the different password policy attributes manually when I realized I had mistyped the name of the nsPwPolicyEntry. I deleted the password policy entity so the nsPwPolicyContainer was empty. Somehow, this enabled the custom password policy to appear properly when right clicking the repuser entity! Hmm . . . it appears that, once we create the nsPwPolicyEntry, the menu appears and can then be used to add all the other attributes. THIS IS ALL FIXED IN 8.1 Go to the Directory Server GUI for ldap1 (this can now be done from centos-idm-console on ldap1 or ldap2), choose the Configuration tab, select Replication in the left panel and then the Supplier Settings in the right panel. Enable the Change Log Click the Use default button Click Save Expand the Replication object and choose the userRoot database Enable the replica Set to single master Give it a replica ID of 1 Click Save Go to the Directory Server GUI for ldap2, choose the Configuration tab. Expand the Replication object and choose the userRoot database Enable the replica Set to dedicated consumer Enter cn=repuser,cn=config in the Enter a new Supplier DN field and click Add. Click on Save. Go to the Directory tab Left/right click on config in the left panel and choose properties. Set the passwordisglobalpolicy to on. Click OK. Go back to the centos-idm-console on ldap1 Go to the Configuration tab, select the userRoot under the Replication object in the left panel. Left/right client and choose New Replication Agreement The name is "mycompany.com ldap1->ldap2" and the Description is "Replicates mycompany.com from ldap1 to ldap2". Click Next. Set the Consumer to ldap2.mycompany.com:389 from the drop down box (389 is correct even though we are really using 636) - Oops! That is not true despite what the documentation says. Click other and create a new entry for ldap2.mycompany.com on port 636. Enable the SSL connection. Enter cn=repuser,cn=config for the Bind As and enter the password. Click Next and then Next again. We will always keep directories in sync so click Next again. Choose Initialize Consumer Now and click Next Click Done Setup DSGW for client user administration We will install DSGW on ldap1 so clients can administer their own users. Thus, we will significantly restrict what DSGW can do. The Centos RPMs for the web based user interface have not yet been released. In the meantime, we can download the DSGW source from http://directory.fedoraproject.org/sources/fedora-ds-dsgw-1.1.1.tar.bz2 (1.1.2 is available but fails to compile for an unmet dependency) yum install wget tar gzip bzip2 mkdir /download cd /download wget http://directory.fedoraproject.org/sources/fedora-ds-dsgw-1.1.1.tar.bz2 These have some dependencies so we must do - oops! For some reason, there is a broken dependency setting for httpd-devel so we will need to download it manually after installing its dependencies: yum install apr-devel apr-util-devel pkgconfig cd /download wget http://dev.centos.org/centos/5/testing/x86_64/httpd-devel-2.2.8-1.el5s2.c... rpm -Uvh httpd-devel*.rpm Now we can do: yum --enablerepo=c5-testing install icu libicu-devel mozldap-devel apr-devel pam-devel openssl-devel lm_sensors-devel net-snmp-devel cyrus-sasl gcc-c++ bzip2 make nspr-devel nss-devel adminutil-devel file svrcore-devel As a non-root user, untar the dsgw tarball and make dsgw: useradd -m someuser chown -R someuser /download su someuser cd /download tar jxfv fedora-ds-dsgw-1.1.1.tar.bz2 cd fed* ./configure --prefix=/usr --libdir=/usr/lib64 --sysconfdir=/etc --localstatedir=/var && make && su -c "make install" exit (to root) Copy the CA cert into /etc/dirsrv/dsgw so we can use LDAPS. cp /etc/dirsrv/admin-serv/CA.pem /etc/dirsrv/dsgw/ Now we configure DSGW by running setup-ds-dsgw We want to prevent any access to the Directory Manager account so we edit /etc/dirsrv/dsgw/dsgw.conf by commenting out the current dirmgr directory and creating a new one for the non-existent user "Intentionally Broken" dirmgr "cn=Intentionally Broken" Change the baseurl parameter in dsgw.conf to use port 636 (LDAPS). It may have detected ldaps during installation and already be set properly. We want to remove the hyperlinks to local server administration. To do this, edit /usr/share/dirsrv/html/admserv.html by commenting out the two table rows (<tr></tr>) containing the "CentOS Home Page" and the CentOS Administration Express". While we are editing, change the <title></title> to SSI Directory Management Console and CentOS Server Products (note the breaks in between) to SSI Directory Management. In fact, we may want to comment out the user services altogether. We may also wish to rename the files to which the links point so they cannot be found explicitly by someone who has researched DSGW. mv /usr/share/dirsrv/html/htmladmin.html{,x} Because we do not allow anonymous access, we need a binddn and bindpw to access the tree. Since this is a client application, that will be different for each client. We will store the various bind information files in /etc/dirsrv/bindings so we need to make that directory: mkdir /etc/dirsrv/bindings dsgw.conf needs a binddnfile directive but we will add this on a per client basis. Thus we will construct customized files combining the binddnfile and a template which is simply the dsgw.conf file without the binddnfile directive. Thus do: cd /etc/dirsrv/dsgw cp dsgw.conf dsgw.template chown ldap:ldap /etc/dirsrv/dsgw/dsgw.template Restart dirsrv-admin The service is now available from https://ldap1.mycompany.com:9830 BECAUSE WE STARTED WITH 8.0, WE HAD TO UPGRADE TO 8.1 WITH SOMETHING SIMILAR TO THIS PROCEDURE. IT MAY CONTAIN IMPORTANT INFORMATION FOR YOU ldap2 SSH to ldap2 as root Backup the current database as follows: cd /usr/lib64/dirsrv/slap* ./db2ldif -n userRoot -a /tmp/ssi.<datestamp>.ldif mv /tmp/ssi*.ldif ~/ (it seems we cannot save it here directly - I assume the backup process does not run as root but rather as ldap) Update centos ds as follows: yum --exclude=kernel --enablerepo=c5-testing upgrade Argh!! silly bug - because we are using ldaps, it asks for the CA cert but then complains that the CA cert is already installed. To work around the bug we need to uninstall the CA cert first with: certutil -D -d /etc/dirsrv/admin-serv -n "CA certficate" setup-ds-admin.pl -u Add the new plugins as follows: service dirsrv stop service dirsrv-admin stop Copy the contents of /usr/share/dirsrv/data/template-dse.ldif and /usr/share/dirsrv/data/template-dnaplugin.ldif into /etc/dirsrv/slapd-ldap2/dse.ldif Argh!! The MemberOf definition has an error in it. Change memberOfGroupAttr from member to uniqueMember and change nsslapd-pluginenabled from off to on. service dirsrv start service dirsrv-admin start ldap1 SSH to ldap1 as root Backup the current database as follows: cd /usr/lib64/dirsrv/slap* ./db2ldif -n userRoot -a /tmp/ssi.<datestamp>.ldif ./db2ldif -n NetscapeRoot -a /tmp/ssi-config.<datestamp>.ldif mv /tmp/ssi*.ldif ~/ Update centos ds as follows: yum --exclude=kernel --exclude=postgresql-libs --enablerepo=c5-testing upgrade setup-ds-admin.pl -u Add the new plugins as follows: service dirsrv stop service dirsrv-admin stop Copy the MemberOf definition from /usr/share/dirsrv/data/template-dse.ldif and the contents of /usr/share/dirsrv/data/template-dnaplugin.ldif into /etc/dirsrv/slapd-ldap1/dse.ldif Argh!! The MemberOf definition has an error in it. Change memberOfGroupAttr from member to uniqueMember and change nsslapd-pluginenabled from off to on. service dirsrv start service dirsrv-admin start Another Argh!! The memberOf plugin requires each user on whom it should operate to have the inetuser object class which is not created by default. We need to add it to each user. Add group membership to existing users as follows: fixup-memberof.pl Hmm . . . it cannot find fixup-memberof.pl so we try to do this with ldapmodify as follows: /usr/lib64/mozldap/ldapmodify -h ldap01 -D "cn=Directory Manager" -w - -ZZZ -P /etc/dirsrv/admin-serv Enter bind password: dn: cn=fixMemberOf,cn=memberof task,cn=tasks,cn=config changetype: add objectclass: top objectclass: extensibleObject cn: fixMemberOf basedn: o=Internal,dc=mycompany,dc=com filter: (objectClass=inetOrgPerson) <enter twice then CTL D> LDAP Active Directory Integration This procedure outlines setting up clients with Windows users by integrating their Active Directory with the main LDAP directory. Unlike non-Windows client setups, we need to create the client Internal organization ( e.g., o=abcdefgh,o=Internal,dc=mycompany,dc=com) before the main user creation routine. This is because the synchronization agreement between LDAP and AD must be in place before the users are created lest the users be created disabled with passwords which must be changed at the first login. We will thus alter the clientsetup script to not fail automatically if it finds the Internal client organization already exists but will give the administrator a choice to continue. We will use a flag named ADINT to keep track of what to do with AD integration. It may have one of three values: 1.0 = The Internal client organization does not exist which implies no AD integration 2.1 = The Internal client organization does exist but the WTSUser group has not yet been created 3.2 = The Internal client organization does exist as does the WTSUser group so we simply add the Windows enabled user to that group. We begin by creating the client Internal organization in LDAP. Right click o=Internal and choose new other and then choose organization. We next go to the Windows domain controller and create organizational units named Desktops and Groups underneath the top level of AD, e.g., at dc=mycompany,dc=com. Right click on the top level of the domain and choose New / Organizational Unit. We create a user in the main cn=Users context of Active Directory to function as the binddn for LDAP. The user must be a member of the domain admins group. We go to centos-idm-console -s slapd-ldap1 on ldap1 to administer LDAP. Go to the configuration tab. Expand Replication and right click on UserRoot. Choose New Windows Sync Agreement. Give it an appropriate and unique name and a description. Enter the Windows domain name as appropriate; it should be the FQDN of the top level of AD, e.g., mycompany.com. Do NOT check Sync New Windows Users or Sync New Windows Groups as we do not want this information pushed from Windows to LDAP. We only want to go from LDAP to Windows. Synchronize with the top level of AD so we can access both users and groups in separate OUs, e..g, dc=mycompany,dc=com. The top level should synchronize with the client's Internal organization in LDAP, e.g., o=abcdefgh,o=Internal,dc=ssiservices,dc=biz. Enter the hostname for the domain controller and port 636. Check "Using encrypted SSL connection" and enter the credentials for the AD synchronization user created earlier. Click next and done. If there is a problem connecting to the LDAP server, it may be a bad password, bad binddn, or bad hostname. Left/right click on the new windows synchronization agreement under Replication / UserRoot in the left panel and choose Initiate Full Synchronization. Check the Replication status on the Status tab to ensure it was successful. Next, create the new users using the clientsetup script as normal. Answer "Y" to the question if it is OK that the client ID already exists. Once the objects have been created in LDAP, go to the configuration tab, left/right click on the Windows synchronization agreement and Send and Receive Updates Now. Go to the Windows Terminal Server console and open the Terminal Services Configuration utility. Double click the RDP-tcp connection. Go to the permissions tab and add the WTSUsers group (it will be named WTSUsers-<a unique client identifier>). Set the permissions to User Allow for the WTSUsers group. LDAP configurations Now that we have defined the SSI users, we need to install and configure the LDAP client and related modules for all installed servers. We will start with host01. First copy the CA cert (CA.pem) into /etc/pki/tls/certs/ and ensure it is world readable. Then: yum install nscd nss_ldap authconfig authconfig --update --enableldap --enableldapauth --disablenis --enablecache --ldapserver=ldapxx.mycompany.com --ldapbasedn=dc=mycompany,dc=com --enableldaptls We must edit the resultant /etc/ldap.conf file as follows: binddn uid=searcher,o=abcdefg,o=SysAccounts,dc=mycompany,dc=com Oops! This is the case on all servers except this one as this one needs to see all the client data thus: binddn uid=searcher,dc=ssiservices,dc=biz bindpw <searcher password> rootbinddn <the ldap administrator DN> (we will not set this for the guests systems on this vserver host) tls_cacertfile /etc/pki/tls/certs/CA.pem (toward the bottom) uri ldap://ldapxx.mycompany.com/ ssl start_tls pam_password md5 tls_checkpeer yes comment out tls_certdir Create the /etc/ldap.secret file containing the passphrase and set it rw for root only (chmod 600 /etc/ldap.secret). Edit /etc/nscd.conf to change the group positive cache limit (positive-time-to-live) to 600 seconds from the default 3600. Otherwise, group changes may take up to an hour to propagate. Edit /etc/pam.d/system-auth by changing: password sufficient pam_unix.so shadow nullok try_first_pass use_authtok to password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok (addition of md5) lest we only use the first eight characters of any password. It looks like this is the new default setting so no need to change it. Setup SAMBA In order for Windows Terminal Server users to see their data from their TS sessions, TS needs to map a drive to their data stored on host01. Thus, we need to install SAMBA and integrate it with LDAP. First, we install the needed packages: yum install samba samba-client samba-common Then edit /etc/samba/smb.conf from the default values as follows: [global] workgroup = WORKGROUP server string = HOST01 Version %v interfaces = lo bond0 172.x.x.8/16 disable netbios = yes large readwrite = yes Standalone Server Options security = user passdb backend = ldapsam:ldap://ldapxx.mycompany.com ldap ssl = start_tls ldap admin dn = uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot ldap suffix = dc=mycompany,dc=com ldap delete dn = no Browser Control Options local master = no Printing Options ; load printers = yes (i.e., comment it out) [homes] Comment out everything including the heading - we not want to map home drive access by default [printers] Comment out everything including the heading - we do not want to expose all printers [data-template] writable = yes create mask = 0770 directory mask = 0770 browseable = no case sensitive = yes block size = 4096 follow symlinks = no # ====== abcdefgh Shares ============ [data-abcdefgh] copy = data-template path = /data/clients/abcdefgh valid users = user1 user2 hosts allow = windows1.mycompany.com Create the secrets.tdb file to store the searcher password: smbpasswd -w <password> history -c Add password to PasswordLocations file Edit /etc/openldap/ldap.conf (NOT /etc/ldap.conf) by setting TLS_CACERT /etc/pki/tls/certs/CA.pem Start the SAMBA service and set it to start on boot: service smb start chkconfig smb on Modifying SAMBA LDAP users Add needed object classes to the user by doing the following from host01: smbpasswd -a <userID> (enter current password - we have a problem in that there is currently no way to change the smbpasswd from LDAP - just the other way around) Although we are still not sure this is doing anything as all sources seem to say we cannot sync passwords from LDAP to SAMBA, just the other way around, without implementing FreeIPA, edit /etc/pam.d/system-auth-ac so the password section reads as follows: password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok password sufficient pam_smbpass.so use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so END I think that is just about everything we did. Perhaps it is more confusing than helpful and it certainly needs to be adapted. Wish I had more time to do that for you but it's time to shackle up my chains, head back to the pile and break more IT rocks. Good luck - John -- John A. Sullivan III Open Source Development Corporation Street Preacher: Are you SAVED?????!!!!!! Educated Skeptic: Saved from WHAT?????!!!!!! Educated Believer: From our selfishness that hurts the ones we love and condemns us to an eternity of hurting each other. http://www.spiritualoutreach.com Christianity that makes sense

On Sun, 2009-06-07 at 14:33 -0500, Doug Coats wrote: <snip> The bottom part of the plan should give you most of that information. Some of the essential bits are in the clientsetup script we created and I really shouldn't post that. We do set up our users with objectlclasses of posixaccount and ntuser (I believe that's correct). On RedHat systems we also do something that I believe is technically incorrect, we add a posixgroup objectclass to the users to account for the personal group created by default. To keep the IDs unique among all the systems, we enforce unique uid, uidnumber, and gidnumber and, for other reasons in our multi-client environment, cn. This is one of the major reasons why we divide our DIT at the top level between Internal objects (which must enforce this uniqueness) and External objects (such as client contact lists) which do not enforce that uniqueness. At that point, one can use ldap.conf, nsswitch.conf, and the pam.d modules (largely configured automatically by, oh I forget the package name, I think it is authconfig - it's in the plan) to allow the Linux systems to authenticate users against LDAP. Certainly because we are a multi-client environment but even if we weren't, we do not believe in the hard and crunchy outside, soft and chewy inside security model. The network revolution means the primary attack vector is now on the inside of the network and not the outside. Truth be told, it always was. That's why we use SSL even on the internal network. If someone plants a protocol analyzer on the network, with a little bit of ARP poisoning, there's nothing they can't see traversing the wire. That's why we launched the ISCS network security project (http://iscs.sourceforge.net) and tend to "firepipe" rather than firewall our networks. Hope this helps - John -- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan(a)opensourcedevel.com http://www.spiritualoutreach.com Making Christianity intelligible to secular society