Difference between revisions of "Labeled NFS/Demo/Manual/LDAP"

From SELinux Wiki
Jump to: navigation, search
m (LDAP Server)
m (SSL Certificate)
Line 43: Line 43:
 
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 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 [[Labeled_NFS/Demo/Manual/LDAP/CA|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
+
The [[Labeled_NFS/Demo/Manual/LDAP/CA|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
 
must contain all of the aliases. For example, if the LDAP Server can
 
be looked up in the DNS under host1.domain, ldap.domain,
 
be looked up in the DNS under host1.domain, ldap.domain,

Revision as of 19:54, 11 December 2008

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