Labeled NFS/Demo/Manual/LDAP
Contents
- 1 Software Packages
- 2 Kerberos Configuration
- 3 /etc/sysconfig/ldap
- 4 SSL Certificate
- 5 /etc/openldap/slapd.conf
- 6 Edit /etc/openldap/ldap.conf
- 7 Edit /etc/ldap.conf
- 8 Add Initial Entries to LDAP Directory
- 9 Firewall
- 10 Start LDAP Server and Start at Boot
- 11 Test local LDAP access
- 12 Troubleshooting
- 13 LDAP Client
- 14 LDAP References
Software Packages
# yum install openldap openldap-devel openldap-servers openldap-clients \ krb5-server-ldap nss_ldap
The LDAP server is also a Kerberos client and is required to be configured as such.
Other useful packages:
- ldapvi
Kerberos Configuration
The LDAP server must be configured to use Kerberos.
Each LDAP server requires a Kerberos principal. The special principal, ldap/hostname must be extracted to a key table to which the LDAP server (slapd) has access.
- The following needs to be done for each LDAP Server
[root@sefos ~]# kadmin Authenticating as principal root/admin@EXAMPLE.COM with password. Password for root/admin@EXAMPLE.COM: kadmin: addprinc -randkey ldap/sefos.example.com kadmin: ktadd -k /etc/openldap/ldap.keytab ldap/sefos.example.com kadmin: exit [root@sefos ~]# chgrp ldap /etc/openldap/ldap.keytab [root@sefos ~]# chmod 640 /etc/openldap/ldap.keytab
/etc/sysconfig/ldap
- Edit /etc/sysconfig/ldap and configure the ldap server, slapd.
- Set it to use SSL certificates which are configured next.
- Set it to use the Kerberos key table created above, /etc/openldap/ldap.keytab.
SLAPD_LDAPS=yes ... export KRB5_KTNAME=/etc/openldap/ldap.keytab
SSL Certificate
The LDAP server will require an SSL certificate. It could be purchased, but this isn’t necessary. The certificate authority can be easily distributed to the clients during configuration. The openssl package provides the necessary scripts to create the required certificates.
The certificate guide shows how to create a Certificate Authority (CA) certificate and also CA signed Server Certificates. NOTE: If the LDAP Server has one or more aliases, then the certificate must contain all of the aliases. For example, if the LDAP Server can be looked up in the DNS under host1.domain, ldap.domain, ldap.someotherdomain. The openssl.conf file should be configured by adding the followinging line in the usr_cert section:
subjectAltName=DNS:ldap.domain,DNS:ldap.otherdomain
The CA certificate and the server certificate should be copied into the /etc/openldap directory.
[root@sefos ~]# cp /etc/pki/CA/cacert.pem /etc/openldap/cacerts/cacert.pem [root@sefos ~# cp /etc/pki/tls/misc/newreq.pem /etc/openldap/slapd.key [root@sefos ~]# cp /etc/pki/tls/misc/newcert.pem /etc/openldap/slapd.pem [root@sefos ~]# chmod 640 /etc/openldap/slapd.key [root@sefos ~]# chgrp -R ldap /etc/openldap
/etc/openldap/slapd.conf
Add references to the SSL certificates
TLSCACertificateFile /etc/openldap/cacerts/cacert.pem TLSCertificateFile /etc/openldap/slapd.pem TLSCertificateKeyFile /etc/openldap/slapd.key
Add idle timeout
idletimeout 3600
Failure to add this idle timeout will result in LDAP failing after a period of time. The number of TCP connections is limited internally. If connections are not released, the LDAP daemon (slapd) is unable to open files. This causees slapd to return an error to all queries. If this value is too high (or disabled), then slapd will run out of file handles. If this value is set too low, the system log will fill with messages about reconnecting to the LDAP server. The '3600' used here is somewhat arbitrary and may need to change depending on LDAP service demands.
configure suffix and rootdn to match system domain
suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com"
Add temporary Manager account
This is need for the initial load. A simple method is to add an encrypted password using slappasswd. Run slappasswd to create the file entry. NOTE: if you are using the MLS policy, you will have to run slappasswd
via run_init
.
[root@sefos ~]# slappasswd New password: Re-enter new password: {SSHA}ISM1CdMvg6jOMNjASCKZvOWxXy6F8jY4
In the rootpw section of /etc/openldap/slapd.conf:
rootpw {SSHA}ISM1CdMvg6jOMNjASCKZvOWxXy6F8jY4
Access Control
This is a bit of a hack to restrict the SASL mechanisms that the server advertises to just GSSAPI. Otherwise it also advertises DIGEST-MD5, which the clients prefer. Then you have to add "-Y GSSAPI" to all of your ldapsearch/ldapmodify/etc. command lines, which is annoying. The default for this is noanonymous,noplain so the addition of noactive is what makes DIGEST-MD5 and the others go away.
sasl-secprops noanonymous,noplain,noactive
Map SASL authentication properly:
# Map SASL authentication DNs to LDAP DNs # This leaves "username/admin" principals untouched sasl-regexp "uid=([^/]*),cn=GSSAPI,cn=auth" "uid=$1,ou=people,dc=example,dc=com" # This should be a ^ plus, not a star, but slapd won't accept it
Access Control:
Add global access control restrictions. These must go before any database
line in the file, or else the settings will not be global!
# Users can change their shell, anyone else can see it access to attrs=loginShell by dn.regex="uid=.*/admin,cn=GSSAPI,cn=auth" write by self write by * read # Only the user can see their employeeNumber access to attrs=employeeNumber by dn.regex="uid=.*/admin,cn=GSSAPI,cn=auth" write by self read by * none # Default read access for everything else access to * by dn.regex="uid=.*/admin,cn=GSSAPI,cn=auth" write by * read
Here are a number of additional security options:
In order to make slapd require integrity-encryption (i.e. SSL connection):
- The number value is roughly equivalent to the bit length of the encryption key that is required.
security ssf=1 update_ssf=112 simple_bind=64
Edit /etc/openldap/ldap.conf
This file needs to reside on each host that accesses the LDAP server including the LDAP server(s) themselves.
BASE dc=example,dc=com URI ldap://sefos.example.com TLS_CACERT /etc/openldap/cacerts/cacert.pem TLS_REQCERT hard
Edit /etc/ldap.conf
Note Editing this file is done in order to copy the file to the client during the client configuration. The file isn't necessary for the server unless it is running as a client and using the ldap user information, which is not suggested. The server using the ldap user information hasn't been tested here and would require some careful configuration.
# The distinguished name of the search base. base dc=example,dc=com ... uri ldap://sefos.example.com/ ssl start_tls tls_cacertdir /etc/openldap/cacerts
Add Initial Entries to LDAP Directory
To avoid an annoying warning message, create a DB_CONFIG for ldap:
[root@sefos ~]# touch /var/lib/ldap/DB_CONFIG
Next the root of the directory service needs to be added. This is
the Distinguished Name for the Realm that the user and group data
resides under within the LDAP directory. The LDAP directory is
stored conceptually as a hierarchical tree structure with the user
and group information for a realm stored underneath the realm name.
The realm name needs to be added to the LDAP directory to provide
the base name for the user and group data. To enter this root name
create the following LDAP Data Interchange Format (LDIF) file.
Create a file /tmp/ldap-init.ldif
:
# Our top level domain dn: dc=example,dc=com objectclass: dcObject objectclass: organization o: SEFOS Test dc: example # The Manager dn: cn=Manager,dc=example,dc=com objectclass: organizationalRole cn: Manager
Then add it by running
# chcon system_u:object_r:slapd_db_t:s0 /tmp/ldap-init.ldif # run_init slapadd -v -l /tmp/ldap-init.ldif
This has created several files in the LDAP database directory which are owned by root. The LDAP server runs as the user ldap, so permissions must be fixed:
[root@sefos ~]# chown ldap:ldap /var/lib/ldap/*
Firewall
If the LDAP server is behind a firewall the fallowing ports are necessary to be open:
- 389 TCP | LDAP
- 636 TCP | LDAP over TLS/SSL
The following rules should be added to /etc/sysconfig/iptables
just before the INPUT REJECT rule:
# ldap server -A INPUT -m tcp -p tcp --dport 389 -j ACCEPT -A INPUT -m tcp -p tcp --dport 636 -j ACCEPT
And then iptables needs to be restarted:
[root@sefos ~]# run_init service iptables restart
Start LDAP Server and Start at Boot
Start the LDAP server on the system and configure the system to start LDAP during boot.
[root@sefos /]# run_init service ldap start [root@sefos /]# chkconfig ldap on
Test local LDAP access
Now 2 nodes need to be added; one for groups and one for users. Create /tmp/usernodes.ldif
# Now we create a organizational unit to hold our users: dn: ou=people,dc=example,dc=com objectClass: organizationalUnit ou: People # And, finally, one to hold our groups: dn: ou=group,dc=example,dc=com objectClass: organizationalUnit ou: Group
And, assuming you have kerberos credentials, add them like so:
# chcon system_u:object_r:slapd_db_t:s0 /tmp/usernodes.ldif # ldapadd -ZZ -f /tmp/usernodes.ldif
Troubleshooting
- If you get " Insufficient access (50); additional info: no write access to parent", then make sure the access control rules added to slapd.conf are global (i.e. they occur before any
database
statements).
- If you get "ldap_sasl_interactive_bind_s: Local error (-2)", Then you don't have any kerberos credentials, or they have expired. Simply run
kinit -p root/admin
and you should get some proper credentials after supplying the admin password.
LDAP Client
F9 LDAP Client Packages
# yum install openldap openldap-devel openldap-clients nss_ldap
The LDAP client is also a Kerberos client and is required to be configured as such.
LDAP Client Configuration
Copy the following files from the LDAP server.
- /etc/ldap.conf
- /etc/openldap/ldap.conf
- /etc/openldap/cacerts/cacert.pem
Make sure the certificate is world readable
chmod 644 /etc/openldap/cacerts/cacert.pem
Testing LDAP from the Client
We should be able to query the LDAP server from the client and extract information. Here is a sample query and the expected output:
[root@sefos /] ldapsearch -b 'dc=example,dc=com' -L "cn=Manager" SASL/GSSAPI authentication started SASL username: root/admin@EXAMPLE.COM SASL SSF: 56 SASL data security layer installed. version: 1 # # LDAPv3 # base <dc=example,dc=com> with scope subtree # filter: cn=Manager # requesting: ALL # # Manager, example.com dn: cn=Manager,dc=example,dc=com objectClass: organizationalRole cn: Manager # search result # numResponses: 2 # numEntries: 1 [root@sefos /]
If you get this error
ldap_sasl_interactive_bind_s: Local error (-2)
Then you don't have any kerberos credentials, or they have expired. Simply run
kinit -p root/admin
and you should get some proper credentials after supplying the admin password.
LDAP References
- OpenLDAP Software 2.4 Administrator's Guide
- Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map, RFC 4510
- Lightweight Directory Access Protocol (LDAP): The Protocol, RFC 4511
- LDAP Data Interchange Format (LDIF) - Technical Specification: RFC 2849
- Lightweight Directory Access Protocol (LDAP): Directory Information Models: RFC 4512
- Lightweight Directory Access Protocol (LDAP): Schema for User Applications, RFC 4519