n====================================================== Centos ldap installation ======================================================= :Title: Centos ldap installation/configuration :Author: Douglas O'Leary :Description: Notes/links for installation of ldap on centos :Disclaimer: Standard: Use the information that follows at your own risk. If you screw up a system, don't blame it on me... Overview: ========= There are a number of good tutorials out there on getting openldap installed, running, and authenticating. This isn't a tutorial; but, a checklist of steps that I've been able to repeast a number of times. Alot of the process was taken from this site_ .. _site: http://spectlog.com/content/Minimal_LDAP_configuration_on_RHEL6_in_stages_and_details which **is** and excellent tutorial; walking the reader through stages installation and configuration. Excellent job; it was very helpful. This checklist covers installation and configuration of an ldap server for my company. Replace domains and IPs as needed. It also covers configuring ldap authentication on clients both legacy and sssd. For reasons that I haven't explored yet, one client insists on legacy authentication even for rhel6 systems. So, short version: following these steps will get you a functioning openldap server with basic ACLs to cover the shadow passwords and the ability to configure other linux systems to authenticate against the server. Good luck; let me know if there's anything that's unclear or mistaken. Creating ldap directory server: =============================== * Install required packages: * openldap-servers * openldap-clients * migrationtools * Edit */etc/sysconfig/ldap*; ensure ldap, ldapi, and ldaps are enabled. We'll disable ldap (unsecure) later. * ldapi will be used for directory configuration updates * ldaps will be used for normal operations * ldap will be used for verification of initial set up. * Update firewall rules to allow port 636 (ldaps). If using */etc/sysconfig/iptables* * Add two lines to file: :: -A INPUT -m state --state NEW -m udp -p udp --dport 636 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 636 -j ACCEPT * ``service iptables restart`` * Copy, edit initial splad.conf file: * /usr/share/openldap-servers/slapd.conf.obsolete -> /etc/openldap/slapd.oci.com * Change: * Manager -> admin * my-domain -> oci * Add rootpw in the bdb section below the rootdn * Edit ldap.conf, * update BASE and URI * Leave ldap (port 389) enabled for the time being - it's blocked by the firewall so it's local only. * Create startup ldif files: :: # Root entry dn: dc=oci,dc=com objectclass: dcObject objectclass: organization o: OLeary Computers dc: oci # Admin DN dn: cn=admin,dc=oci,dc=com objectclass: organizationalRole cn: admin # Base DN for users dn: ou=users,dc=oci,dc=com changetype: add objectclass: top objectclass: organizationalUnit ou: users # Base DN for groups dn: ou=groups,dc=oci,dc=com changetype: add objectclass: top objectclass: organizationalUnit ou: groups * Initialize slapd.d config: * ``rm -fr /etc/openldap/slapd.d/* /var/lib/ldap/*`` * ``cp /usr/share/openldap-servers/DB_CONFIG.example \ /var/lib/ldap/DB_CONFIG`` * `` echo '' | slapadd -f /etc/openldap/slapd.oci.conf`` * ``slaptest -f /etc/openldap/slapd.oci.conf -F /etc/openldap/slapd.d`` * Initialize directory entries: * ``slapadd -l /root/working/ldap/oci.com.ldif`` * ``slapadd -l /root/working/ldap/admin.oci.com.ldif`` * ``chown -R ldap:ldap /var/lib/ldap /etc/openldap/slapd.d`` * Start up slapd and verify: * ``service slapd start`` * ``ldapsearch -x -b 'dc=oci,dc=com'`` * Add users and groups then verify: * ``ldapadd -x -D "cn=admin,dc=oci,dc=com" -w ${pwd} \ -f /root/working/ldap/users.oci.com.ldif`` * ``ldapadd -x -D "cn=admin,dc=oci,dc=com" -w ${pwd} \ -f /root/working/ldap/groups.oci.com.ldif`` * ``ldapsearch -x -b 'dc=oci,dc=com'`` NOTE: db:config is set up to allow uid:gid 0:0 (root:root) only, based on *access to* lines in the original slapd.oci.conf. cn=admin,dc=oci,dc=com is root for db:bdb. Theoretically, I could set up (os) root to have access to db:bdb too. * Update defaults in migrate_common.ph, create test user and ldif files: * ``vi /usr/share/migrationtools/migrate_common.ph`` * People -> users * Group -> groups * Update DEFAULT_MAIL_DOMAIN * Update DEFAULT_BASE * ``groupadd -g 100000 qwer`` * ``useradd -u 100000 -g qwer qwer`` * ``passwd qwer`` * ``grep qwer /etc/passwd | /usr/share/migrationtools/migrate_passwd.pl \ - qwer.passwd.ldif`` * ``grep qwer /etc/group | /usr/share/migrationtools/migrate_group.pl \ - qwer.group.ldif`` * Add test user to directory, verify, then delete him from the system. * ``ldapadd -x -D "cn=admin,dc=oci,dc=com" -w "${pwd}" \ -f ./qwer.group.ldif`` * ``ldapadd -x -D "cn=admin,dc=oci,dc=com" -w "${pwd}" \ -f ./qwer.passwd.ldif`` * ``ldapsearch -LLL -x -b 'dc=oci,dc=com'`` * ``userdel -r qwer`` * Certificates: * Update certificate definitions in directory: :: # ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b cn=config \* | \ grep -i ^olctlscert SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 olcTLSCertificateFile: "OpenLDAP Server" olcTLSCertificateKeyFile: /etc/openldap/certs/password # cat /root/working/ldap/add.certificate.conf.ldif dn: cn=config changetype: modify replace: olcTLSCertificateFile olcTLSCertificateFile: /etc/pki/tls/certs/slapdcert.pem - replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/pki/tls/certs/slapdkey.pem - # ldapmodify -Y EXTERNAL -H ldapi:/// \ -f /root/working/ldap/add.certificate.conf.ldif [[snip]] # ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b cn=config \* | \ grep -i ^olctlscert SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 olcTLSCertificateFile: /etc/pki/tls/certs/slapdcert.pem olcTLSCertificateKeyFile: /etc/pki/tls/certs/slapdkey.pem * Generate server key and cert request: :: openssl req -new -nodes -keyout \ /etc/pki/tls/private/ldapsvr.oci.com.key \ -out /etc/pki/tls/ldapsvr.oci.com.csr * Get the cert signed. The author of the tutorial also has steps for generating your own Certificate Authority so you can sign your certs w/o having to go through verisign. The signed certs obviously aren't as *trustworth* as ones from the major vendors; but, they work for this purpose. His checkist is available at: http://spectlog.com/content/Create_Certificate_Authority_(CA)_instead_of_using_self-signed_Certificates I have one, too, but I think his is more recent. Mine was taken right from the openssl book and doesn't reflect the directory structure that comes w/rhel6. My page, if you're interested, is at http://www.olearycomputers.com/ll/misc_openssl_ca.html * Obtain the signed cert: ``scp caauth:/etc/pki/CA/certs/ldapsvr.olearycomputers.com.crt /tmp`` * Retrieve and update CA cert: :: # pwd /etc/pki/tls # scp caauth:/etc/pki/CA/cacert.pem certs # hash=$(openssl x509 -noout -hash -in certs/cacert.pem ) # echo ${hash} aa65d400 # ln -s /etc/pki/tls/certs/cacert.pem /etc/pki/tls/certs/${hash}.0 # ll certs/${hash}.0 lrwxrwxrwx. 1 root root 29 Jan 5 08:39 certs/aa65d400.0 -> /etc/pki/tls/certs/cacert.pem # openssl verify /tmp/ldapsvr.olearycomputers.com.crt /tmp/ldapsvr.olearycomputers.com.crt: OK * Copy newly created keys into the place: :: # cp /etc/pki/tls/private/ldapsvr.oci.com.key /etc/pki/tls/certs/slapdkey.pem # cp /tmp/ldapsvr.olearycomputers.com.crt /etc/pki/tls/certs/slapdcert.pem # openssl verify /etc/pki/tls/certs/slapdcert.pem /etc/pki/tls/certs/slapdcert.pem: OK # chown root:ldap /etc/pki/tls/certs/slapdcert.pem /etc/pki/tls/certs/slapdkey.pem # chmod 750 /etc/pki/tls/certs/slapdkey.pem * Disable ldap (port 389): * Set *SLAPD_LDAP=no* in */etc/sysconfig/ldap*; restart slapd * Update firewall rules, if needed. * Set *TLS_REQCERT allow* in */etc/openldap/ldap.conf. Temporary measure while I figure out what's up with the certificates. *allow* enables the sesssion to continue if there's no cert or a bad one is provided. I have verified, via wireshark, that the data is, in fact, encrypted. If someone knows why this isn't working, a tip would be appreciated. * In */etc/openldap/ldap.conf*, remove or replace ldap uri with ldaps. ldaps should be the only one left. * Verify output from ``ldapsearch -x -b dc=oci,dc=com`` Since ldap is disabled and cli switches don't allow for ldapi, this is going through port 636. Use wireshark on the ldap server to verify port and encryption. * ACLs: protect shadow password: * Create access.ldif: :: ## BDB access control list dn: olcDatabase={2}bdb,cn=config changetype: modify add: olcAccess olcAccess: {0}to attrs=userpassword,shadowlastchange by self write by anonymous auth by * none olcAccess: {1}to * by self write by * read * Apply it: :: # ldapmodify -Y EXTERNAL -H ldapi:/// -f /root/working/ldap/access.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "olcDatabase={2}bdb,cn=config" * To delete, use: :: ## BDB access control list dn: olcDatabase={2}bdb,cn=config changetype: modify delete: olcAccess olcAccess: {0} * The syntax is **incredibly** touchy. It took way longer than it should to get those two simple processes down. Legacy authentication: ====================== NOTE: havent' tried this on a rhel5 (or earlier) box yet; works on rhel6. * Install required packages: ``yum -y install openldap-clients nss-pam-ldapd`` * Set *FORCELEGACY=yes* in */etc/sysconfig/authconfig* * Run ``authconfig``: :: authconfig --enableldap --enableldapauth --ldapserver=ldaps://192.168.122.20 \ --ldapbasedn="dc=oci,dc=com" --enablemkhomedir \ --ldaploadcacert=ftp://192.168.122.1/pub/CA/ldapsvr.olearycomputers.com.crt --update * Set *TLS_REQCERT allow* in */etc/openldap/ldap.conf. Temporary measure while I figure out what's up with the certificates. *allow* enables the sesssion to continue if there's no cert or a bad one is provided. I have verified, via wireshark, that the data is, in fact, encrypted. If someone knows why this isn't working, a tip would be appreciated. * Verify output from ``ldapsearch -x -b dc=oci,dc=com`` * Set *tls_reqcert allow* in */etc/nslcd.conf*. Same comment as above. Restart nslcd * Verify: * authentication works: ``getent passwd qwer`` * ssh/mkhomedir work by accessing account. ``ssh -l qwer client1`` sssd authentication: ==================== NOTE: pretty much the same thing minus the forcelegacy entry in /etc/sysconfig/authconfig and you don't need nss-pam-ldapd... * Install required packages: ``yum -y install openldap-clients`` * Run ``authconfig``: :: authconfig --enableldap --enableldapauth \ --ldapserver=ldaps://192.168.122.20 \ --ldapbasedn="dc=oci,dc=com" --enablemkhomedir \ --ldaploadcacert=ftp://192.168.122.1/pub/CA/cacert.pem \ --update * Set *TLS_REQCERT allow* in */etc/openldap/ldap.conf. Temporary measure while I figure out what's up with the certificates. *allow* enables the sesssion to continue if there's no cert or a bad one is provided. I have verified, via wireshark, that the data is, in fact, encrypted. If someone knows why this isn't working, a tip would be appreciated. * Verify output from ``ldapsearch -x -b dc=oci,dc=com`` * Set *ldap_tls_reqcert = allow* in */etc/sssd/sssd.conf*. Same comment as above. Restart sssd * Verify: * authentication works: ``getent passwd qwer`` * ssh/mkhomedir work by accessing account. ``ssh -l qwer client1`` Try #4: ======= Repeatability. I'm going to reset everything back to the start and rerun the process straight again. I want repeatability. Once that's done, try #5 will be to streamline the process a bit. Another interesting tidbit - *authconfig* can download the cacert for me: :: authconfig --enableldap --enableldapauth \ --ldapserver=ldap://ldap.example.com:389,ldap://ldap2.example.com:389 \ --ldapbasedn="ou=people,dc=example,dc=com" --enableldaptls \ --ldaploadcacert=https://ca.server.example.com/caCert.crt --update * ``yum -y install openldap-servers openldap-clients nss-pam-ldapd migrationtools`` * Everything else from initial install worked as expected. * Copy and edit slapd.conf: * From */usr/share/openldap-servers/slapd.conf.obsolete* * Edit * Manager -> admin * my-domain -> oci * Add rootpw * Edit ldap.conf, update BASE and URI * Create startup ldif files: :: # Root entry dn: dc=oci,dc=com objectclass: dcObject objectclass: organization o: OLeary Computers dc: oci # Admin DN dn: cn=admin,dc=oci,dc=com objectclass: organizationalRole cn: admin # Base DN for users dn: ou=users,dc=oci,dc=com changetype: add objectclass: top objectclass: organizationalUnit ou: users # Base DN for groups dn: ou=groups,dc=oci,dc=com changetype: add objectclass: top objectclass: organizationalUnit ou: groups * Blast derbis from one and only ``service slapd start`` and regenerate: * ``rm -fr /etc/openldap/slapd.d/*`` * ``rm -fr /var/lib/ldap/*`` * ``cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG`` * `` echo '' | slapadd -f /etc/openldap/slapd.oci.conf`` * Convert slapd.oci.conf to new format and initialize directory: * ``slaptest -f /etc/openldap/slapd.oci.conf -F /etc/openldap/slapd.d`` * ``slapadd -l /root/working/ldap/oci.com.ldif`` * ``slapadd -l /root/working/ldap/admin.oci.com.ldif`` * ``chown -R ldap:ldap /var/lib/ldap /etc/openldap/slapd.d`` * Start up slapd and verify: :: # service slapd start Starting slapd: [ OK ] # ldapsearch -x -b 'dc=oci,dc=com' # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # oci.com dn: dc=oci,dc=com objectClass: dcObject objectClass: organization o: OLeary Computers dc: oci # admin, oci.com dn: cn=admin,dc=oci,dc=com objectClass: organizationalRole cn: admin # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 * Add users and groups then verify: * ``ldapadd -x -D "cn=admin,dc=oci,dc=com" -w ${pwd} -f /root/working/ldap/users.oci.com.ldif`` * ``ldapadd -x -D "cn=admin,dc=oci,dc=com" -w ${pwd} -f /root/working/ldap/groups.oci.com.ldif`` * ``ldapsearch -x -b 'dc=oci,dc=com' NOTE: db:config is set up to allow uid:gid 0:0 (root:root) only, based on *access to* lines in the original slapd.oci.conf. cn=admin,dc=oci,dc=com is root for db:bdb. Theoretically, I could set up root to have access to db:bdb too. * Update defaults in migrate_common.ph, create test user and ldif files: * ``vi /usr/share/migrationtools/migrate_common.ph`` * People -> users * Group -> groups * Update DEFAULT_MAIL_DOMAIN * Update DEFAULT_BASE * ``groupadd -g 100000 qwer`` * ``useradd -u 100000 -g qwer qwer`` * ``passwd qwer`` * ``grep qwer /etc/passwd | /usr/share/migrationtools/migrate_passwd.pl - qwer.passwd.ldif`` * ``grep qwer /etc/group | /usr/share/migrationtools/migrate_group.pl - qwer.group.ldif`` * Add test user to directory, verify, then delete him. * ``ldapadd -x -D "cn=admin,dc=oci,dc=com" -w "${pwd}" -f ./qwer.group.ldif`` * ``ldapadd -x -D "cn=admin,dc=oci,dc=com" -w "${pwd}" -f ./qwer.passwd.ldif`` * ``ldapsearch -LLL -x -b 'dc=oci,dc=com'`` * ``userdel -r qwer`` * Unencrypted connection: On a client of your choice: * ``yum -y install openldap-clients nss-pam-ldapd`` * Set *FORCELEGACY=yes* in */etc/sysconfig/authconfig* * Edit /etc/openldap/ldap.conf, update BASE and URI * Run ``authconfig``: :: authconfig --enableldap --enableldapauth \ --ldapserver=192.168.122.20 --ldapbase="dc=oci,dc=com" \ --enablemkhomedir --update * Verify: :: # getent passwd qwer qwer:x:100000:100000:qwer:/home/qwer:/bin/bash # ssh -l qwer client1 qwer@client1's password: [qwer@client1 ~]$ * Encrypted connection: * On the ldap server: * Ensure LDAPI is configured in */etc/sysconfig/ldap*. Restart slapd if necessary. * Update tlscertificate entries in cn=config: :: # ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b cn=config \* | grep -i ^olctlscert SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 olcTLSCertificateFile: "OpenLDAP Server" olcTLSCertificateKeyFile: /etc/openldap/certs/password # cat /root/working/ldap/add.certificate.conf.ldif dn: cn=config changetype: modify replace: olcTLSCertificateFile olcTLSCertificateFile: /etc/pki/tls/certs/slapdcert.pem - replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/pki/tls/certs/slapdkey.pem - # ldapmodify -Y EXTERNAL -H ldapi:/// -f /root/working/ldap/add.certificate.conf.ldif [[snip]] # ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b cn=config \* | grep -i ^olctlscert SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 olcTLSCertificateFile: /etc/pki/tls/certs/slapdcert.pem olcTLSCertificateKeyFile: /etc/pki/tls/certs/slapdkey.pem * Create cert request and send it to the CA: :: openssl req -new -nodes -keyout /etc/pki/tls/private/ldapsvr.oci.com.key \ -out /etc/pki/tls/ldapsvr.oci.com.csr * On the CA auth system, sign the cert: :: # openssl ca -policy policy_anything \ -out /etc/pki/CA/certs/ldapsvr.olearycomputers.com.crt \ -infiles /etc/pki/tls/ldapsvr.oci.com.csr * On the ldapsrvr, * retrieve and update CA cert: :: # pwd /etc/pki/tls # scp caauth:/etc/pki/CA/cacert.pem certs # hash=$(openssl x509 -noout -hash -in certs/cacert.pem ) # echo ${hash} aa65d400 # ln -s /etc/pki/tls/certs/cacert.pem /etc/pki/tls/certs/${hash}.0 # ll certs/${hash}.0 lrwxrwxrwx. 1 root root 16 Jan 4 06:36 certs/aa65d400.0 -> cacert.pem # openssl verify /tmp/ldapsvr.olearycomputers.com.crt /tmp/ldapsvr.olearycomputers.com.crt: OK * Copy newly created keys into the place: :: # cp /etc/pki/tls/private/ldapsvr.oci.com.key /etc/pki/tls/certs/slapdkey.pem # cp /tmp/ldapsvr.olearycomputers.com.crt /etc/pki/tls/certs/slapdcert.pem # openssl verify ./slapdcert.pem ./slapdcert.pem: OK # chown -Rf root:ldap /etc/pki/tls/certs/slapdcert.pem /etc/pki/tls/certs/slapdkey.pem # chmod -Rf 750 /etc/pki/tls/certs/slapdkey.pem * Disable ldap (port 389) in favor of ldaps (port 636): * Set *SLAPD_LDAP=no* and *SLAPD_LDAPS=yes* in */etc/sysconfig/ldap* * Replace 389 with 636 in */etc/sysconfig/iptables* and restart iptables service. * Restart slapd * On the client using legacy connection: * */etc/openldap/ldap.conf* * Update URI to reflect ldaps:// vs ldap:// * Add *TLS_REQCERT allow* * */etc/nslcd.conf* * Update URI to reflect ldaps:// vs ldap:// * Add *tls_reqcert allow* * ``service nslcd restart`` * On a client using sssd: * Install openldap-clients: * Install the CA cert w/updated hash: :: # pwd /etc/pki/tls # scp caauth:/etc/pki/CA/cacert.pem certs # hash=$(openssl x509 -noout -hash -in certs/cacert.pem ) # echo ${hash} aa65d400 # ln -s /etc/pki/tls/certs/cacert.pem /etc/pki/tls/certs/${hash}.0 # ll certs/${hash}.0 lrwxrwxrwx. 1 root root 16 Jan 4 06:36 certs/aa65d400.0 -> cacert.pem # openssl verify /tmp/ldapsvr.olearycomputers.com.crt /tmp/ldapsvr.olearycomputers.com.crt: OK * Update */etc/openldap/ldap.conf* as needed: * BASE * URI * TLS_REQCERT (if needed) * Verify ldapsearch returns data. * Run authconfig configure files and to populate sssd.conf authconfig --enableldap --enableldapauth --ldapserver=ldaps://192.168.122.20 \ --ldapbasedn="dc=oci,dc=com" --enablemkhomedir \ --ldaploadcacert=ftp://192.168.122.1/pub/CA/ldapsvr.olearycomputers.com.crt --update * Update */etc/sssd/sssd.conf* * Update ldap_uri to reflect ldaps, if needed * Add *ldap_tls_reqcert = allow* if needed. * ``service sssd restart`` * ``getent passwd qwer`` Try #3: ======= 01/01/14: Retrying using the directions straight, now that I know where to get the doubly damned original slapd.conf file... I'm not going to keep individual notes unless something goes awry. ``cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG`` Interesting, the doc has me adding users and groups via slapadd; however, that doesn't work but no indication that it's supposed to error out in the doc. Next section has me start the directory, then add users and groups via ldapadd... Bastards! ldap auth w/o encryption: ------------------------- This is where things are going to get tricky as some of the shit the doc takes for granted doesn't exist on my client systems. Install *nss-pam-ldapd* to support the unencrypted connection. client works the first time: :: # getent passwd qwer qwer:x:501:100000:qwer:/home/qwer:/bin/bash Authentication works too although I still ran into that error writing the .Xauthority file. ldap auth w/encryption: ----------------------- Got through configuring the ldap server to use IPC. Next step is arguing with SSL certificates and I don't think I have the energy for that right at the moment. Maybe later. I do have the unencrypted auhtentication working, though, and I'm quite pleased with that. 01/02/14: First item, author has us adding the certificate entries vs replacing. Can't add as they're already extent: :: # ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b cn=config | grep -i ^olctlscert SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 olcTLSCertificateFile: "OpenLDAP Server" olcTLSCertificateKeyFile: /etc/openldap/certs/password Alrighty; all the way up through reconfiguring nslcd to use certs; although, I'm not sure it actually is. The slapdcert.pem file isn't in the certs directory. I'm betting the traffic's unecrypted... yet, I turned off ldap and the port's not active on the firewal.. It took a bit of playing around w/wireshark - including getting it installed (wireshark-gnome? really??) but I was able to verify that the ldap queries are, in fact, encrypted. Excellent. Later: After generating the ca authority per the author's other doc, he has us copying the request - not newly signed cert - to */etc/pki/tls/certs/slapdcert.pem*. Go figure, that doesn't work: :: # openssl verify /etc/pki/tls/certs/slapdcert.pem unable to load certificate 139947499087688:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:703:Expecting: TRUSTED CERTIFICATE Once I copied the signed cert to the file, it verifies fine: :: # cp /tmp/ldapsvr.olearycomputers.com.crt /etc/pki/tls/certs/slapdcert.pem # openssl verify /etc/pki/tls/certs/slapdcert.pem /etc/pki/tls/certs/slapdcert.pem: OK And, naturally, the last section, getting sssd to work, doesn't. I checked and updated * /etc/openldap/ldap.conf * /etc/sssd/sssd.conf * /etc/sysconfig/authconfig I even ran system-config-authentication to no avail. I remembered a setting that I had to put into */etc/openldap/ldap.conf*, specifically, ``TLS_REQCERT allow``. Once I put that into the sssd.conf file, I'm able to see getent requests - on both client1 and client2. Outstanding. Now, there should be a way to put in the cert for the ldap server directly. Try #2: ======= 12/31/13: I was able to get the legacy style working on one and only one client box and then only for a little while. Working my way through the rest of the doc, though. sssd apparently doesn't like self signed certs so I gen'ed a new system, caauth, and am going to create some *signed* certs. Interesting. There's an /etc/nslcd.conf file. Web site didn't have us modify that the first time around. This time it is. Wonder if that's the cause of my initial failure? There are a bunch of other entries in that file so there's more than likely something in there affecting the issue. Starting over from scratch - rebuilding the ldap server and clients. I'm saw some log messages on one of the clients saying that nscd was conflicting with sssd which probably explains the issue. Rather than using the disks outright, I'm going to make copies so that I don't have to rebuild the damn things from scratch again - and lose the host key. ldapsvr and client1 are done, client2 and 3 are in the process of patching now. OK: everything's rebuilt and I have copies of the original disks so going back will be a simple matter of mv'ing the backup disk in place. 1. Initial installation: * ``yum -y install openldap-servers openldap-clients`` * Add lines to */etc/sysconfig/iptables* :: -A INPUT -m state --state NEW -m udp -p udp --dport 389 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 389 -j ACCEPT * ``service iptables restart`` 2. Update administrative account, password, and domain: Update */etc/openldap/slapd.d/cn=config/olcDatabase={2}bdb.ldif* * Manager => admin * my-domain => oci * Add *olcRootPw: {SSHA} [[snip]]* 3. Create initial content: :: ### oci.com.ldif # Root entry dn: dc=oci,dc=com objectclass: dcObject objectclass: organization o: OLeary Computers Inc dc: oci ### admin.oci.com.ldif # Admin DN dn: cn=admin,dc=oci,dc=com objectclass: organizationalRole cn: admin ### users.oci.com.ldif # Base DN for users dn: ou=users,dc=oci,dc=com changetype: add objectclass: top objectclass: organizationalUnit ou: users ### groups.oci.com.ldif # Base DN for groups dn: ou=groups,dc=oci,dc=com changetype: add objectclass: top objectclass: organizationalUnit ou: groups 4. Clean out installed content: ``rm -fr /var/lib/ldap/*`` 5. Adding files: issue w/adding users and groups. Tired; don't want to wrestle with it right now. May have to start afresh w/ldapsvr (grr) Original try: ============= Trying the steps from this site_ .. _site: http://spectlog.com/content/Minimal_LDAP_configuration_on_RHEL6_in_stages_and_details As expected, the first issue I run into is the chicken/egg thing. The new model for directory maintenance doesn't provide a method of getting things going from ground zero. Most of the guides, this one included, tell you to copy /etc/openldap/slapd.conf.bak to slapd.conf, edit it, and use it to kickstart the new paradigm. Problem: centos/rhel6 no longer supply slapd.conf.bak to copy in order to kickstart the new config. There doesn't seem to be a full example of what the file should look like. I did find one link_ that suggest, counter to what everything else said, editing the slapd.d files directly: .. _link: http://blog.christophersmart.com/articles/openldap-how-to-fedora/ Combining both those docs, I'm going to edit * /etc/openldap/slapd.d/cn=config/olcDatabase={2}bdb.ldif* * Update Manager and my-domain to something sane: :: perl -i -ple 's/Manager/admin/g' olcDatabase={2}bdb.ldif perl -i -ple 's/my-domain/oci/g' olcDatabase={2}bdb.ldif * Add password: :: # add to bdb file: olcRootPw: {SSHA}[[snipped]] Install: openldap-servers openldap-clients migrationtools nss-pam-ldapd pam_ldap __DATA__ # old version I found two excellent pages for the installation of ldap on centos. The first_, is from linuxhome and walks step by step thorugh the installation. He also references the second_ which details some problems and fixes to the SSL/TLS configuration that were caused by simple yum update. .. _first: http://linuxserverathome.com/articles/installing-and-configuring-openldap-2423-centos-63 .. _second: http://www.bradchen.com/blog/2012/08/openldap-tls-issue I want to get the steps outlined here as well because whenever I keep a link like those two, they tend to disappear on me... Thanks kkruger and Brad Chen! #. Install centos, update kernel and others. #. Install requisite packages: a. yum -y install openldap openldap-servers openldap-clients b. yum -y install sssd perl-LDAP.noarch #. cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG #. Create db.ldif, updating info as needed:: dn: olcDatabase={0}config,cn=config changetype: modify replace: olcRootPW olcRootPW: [[snipped]] - replace: olcRootDN olcRootDN: cn=admin,cn=config dn: olcDatabase={2}bdb,cn=config changetype: modify replace: olcRootPW olcRootPW: [[snipped]] - replace: olcSuffix olcSuffix: dc=oci,dc=com - replace: olcRootDN olcRootDN: cn=manager,dc=oci,dc=com dn: olcDatabase={1}monitor,cn=config changetype: modify replace: olcAccess olcAccess: {0}to * by \ dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" \ read by dn.base="cn=manager,dc=oci,dc=com" read by * none Note the pwd updates. Use ``slappasswd`` to obtain the encrypted string. Also note the olcAccess ACL which allows external authentication by the root user. #. Add the updates to db:: # ldapadd -Y EXTERNAL -H ldapi:/// -f /root/working/ldap/ldif/db.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "olcDatabase={0}config,cn=config" modifying entry "olcDatabase={2}bdb,cn=config" modifying entry "olcDatabase={1}monitor,cn=config" #. Create the base.ldif, updating info as needed:: dn: dc=oci,dc=com dc: oci objectClass: top objectClass: domain dn: ou=people,dc=oci,dc=com ou: people objectClass: top objectClass: organizationalUnit dn: ou=groups,dc=oci,dc=com ou: groups objectClass: top objectClass: organizationalUnit #. Add the base updates, testing the new password:: # ldapadd -f /root/working/ldap/ldif/base.ldif Enter LDAP Password: adding new entry "dc=oci,dc=com" adding new entry "ou=people,dc=oci,dc=com" adding new entry "ou=groups,dc=oci,dc=com" #. Was having some rather extreme difficulties getting the ssl/tls working. I finally blasted /var/lib/ldap and /etc/openldap, then reinstalled the pkgs. Once I did that, I am able to get ssl queries running correctly. There **may** be an interaction w/sssd as that's running this iteration now where it wasn't before. #. Another url, http://blog.christophersmart.com/articles/openldap-how-to-fedora/, goes into the required details on setting up the account and group info. - example ldif file users - example ldif file groups After following some of those dirs, though, I suddenly lost access to my cert. Not sure how I'm going to proceed, but taking a break for the moment. Original slapd.conf.{bak,obsolete}: =================================== :: # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/corba.schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/duaconf.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/java.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/collective.schema # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args # Load dynamic backend modules # - modulepath is architecture dependent value (32/64-bit system) # - back_sql.la overlay requires openldap-server-sql package # - dyngroup.la and dynlist.la cannot be used at the same time # modulepath /usr/lib/openldap # modulepath /usr/lib64/openldap # moduleload accesslog.la # moduleload auditlog.la # moduleload back_sql.la # moduleload chain.la # moduleload collect.la # moduleload constraint.la # moduleload dds.la # moduleload deref.la # moduleload dyngroup.la # moduleload dynlist.la # moduleload memberof.la # moduleload pbind.la # moduleload pcache.la # moduleload ppolicy.la # moduleload refint.la # moduleload retcode.la # moduleload rwm.la # moduleload seqmod.la # moduleload smbk5pwd.la # moduleload sssvlv.la # moduleload syncprov.la # moduleload translucent.la # moduleload unique.la # moduleload valsort.la # The next three lines allow use of TLS for encrypting connections using a # dummy test certificate which you can generate by running # /usr/libexec/openldap/generate-server-cert.sh. Your client software may balk # at self-signed certificates, however. TLSCACertificatePath /etc/openldap/certs TLSCertificateFile "\"OpenLDAP Server\"" TLSCertificateKeyFile /etc/openldap/certs/password # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! # enable on-the-fly configuration (cn=config) database config access to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * none # enable server status monitoring (cn=monitor) database monitor access to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by dn.exact="cn=Manager,dc=my-domain,dc=com" read by * none ####################################################################### # database definitions ####################################################################### database bdb suffix "dc=my-domain,dc=com" checkpoint 1024 15 rootdn "cn=Manager,dc=my-domain,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. # rootpw secret # rootpw {crypt}ijFYNcSNctBYg # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap # Indices to maintain for this database index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub # Replicas of this database #replogfile /var/lib/ldap/openldap-master-replog #replica host=ldap-1.example.com:389 starttls=critical # bindmethod=sasl saslmech=GSSAPI # authcId=host/ldap-master.example.com@EXAMPLE.COM