n====================================================== Centos ldap installation ======================================================= :Title: Centos ldap installation/configuration :Author: Douglas O’Leary <dkoleary@olearycomputers.com> :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

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 <dc=oci,dc=com> 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

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:

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.

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!

  1. Install centos, update kernel and others.

  2. Install requisite packages:

    1. yum -y install openldap openldap-servers openldap-clients

    2. yum -y install sssd perl-LDAP.noarch

  3. cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG

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

  5. 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"

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

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

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

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