Wrapping this tutorial up by looking at security issues, I'll show you how to enable the Transport Layer Security for OpenLDAP, PAM, and Samba, and how to test the configuration.
In this step, we will instruct our LDAP server to use the security certificates we generated in Step 3: Configure the schemas, directories, and keys needed by OpenLDAP. Simply open /etc/openldap/slapd.conf and uncomment the following three lines:
Listing 11. Enabling TLS for OpenLDAP
TLSCipherSuite HIGH TLSCertificateFile /etc/openldap/slapd-cert.pem TLSCertificateKeyFile /etc/openldap/slapd-key.pem
Now we need to instruct PAM to communicate with the LDAP server over an encrypted connection. Fedora users can launch
authconfig and let the tool do all of the dirty work. Alternatively, you can simply edit /etc/ldap.conf and add the following line
Some people may experience difficulty getting PAM to communicate with their LDAP server after enabing TLS. If you are unable to see the Windows groups you created in your LDAP database with
getent group, try adding the following line at the end of your ldap.conf file:
This is a screen shot depicting the TLS being enabled through
Figure 4. LDAP Authentication over TLS in authconfig
Here is a listing of ldap.conf with TLS enabled.
Listing 12. ldap.conf with TLS enabled
## IMPORTANT ## The /etc/ldap.conf file is used by PAM. There is another ldap.conf file in ## /etc/openldap. ## The file, /etc/openldap/ldap.conf, is used by ldap tools, such as ldapsearch. ## If you intend to use those tools you will need to add a TLS_CACERT directive to that ## file also. # Your LDAP server. Must be resolvable without using LDAP. # Multiple hosts may be specified, each separated by a # space. host 127.0.0.1 # MODIFY # The distinguished name of the search base. base dc=somedomain,dc=com # MODIFY # The distinguished name to bind to the server with. # We will not be using the root dn. Instead we will create # lesser privileged user. binddn uid=samba,ou=Users,dc=somedomain,dc=com bindpw <your password here> # MODIFY # Note: "ou=Users" and "ou=Groups" should match what # you entered in smb.conf for "ldap group suffix" # and "ldap user suffix" nss_base_passwd ou=Users,dc=somedomain,dc=com?one nss_base_passwd ou=Computers,dc=somedomain,dc=com?one nss_base_shadow ou=Users,dc=somedomain,dc=com?one nss_base_group ou=Groups,dc=somedomain,dc=com?one ssl start_tls pam_password md5 # We need to tell PAM where the certificate used to authenticate the LDAP # server (i.e. is the LDAP server the one we think it is). tls_cacertfile /etc/openldap/cacert.pem # If you experience difficulty authenticating after enabling TLS, try uncommenting # the next line. You will know that you are having problems if you # issue "getent group" and do not see any of the MS Windows groups # that have been created in your LDAP database. tls_checkpeer no
Finally, we will enable Samba to communicate with the LDAP server over TLS. To accomplish this, we need to configure the IDEALX scripts to use TLS when communicating with the LDAP server. Make the following modifications to /var/lib/samba/sbin/smbldap.conf.
Listing 13. Getting Samba to talk to LDAP server via TLS
# Set this variable to 1 to enable TLS ldapTLS="1" # Require that the client (i.e. samba) verify the authenticity of the LDAP server verify="require" # You should have already created this certificate during the LDAP configuration phase. cafile="/etc/openldap/slapd-cert.pem"
You may have noticed that there are other options in the smbldap.conf file for authentication,
client key. These two options are there for the truly paranoid and would allow the LDAP server to authenticate the client.
Now it is time to test the secured configuration; however, we should restart our LDAP server and our Samba server. Execute:
Listing 14. To test, restart LDAP and Samba servers
/etc/init.d/ldap restart /etc/init.d/smb restart
To test a TLS security between Samba and LDAP try the following:
/var/lib/samba/sbin/smbldap-usershow dilbert. This should cause the IDEALX scripts to communicate with the LDAP server over a TLS connection and return all of the information the LDAP server has about the user dilbert.
- Next, try to log in to the
BIGTIMEdomain from a Windows workstation.