21.4 About LDAP Authentication

21.4.1 About LDAP Data Interchange Format
21.4.2 Configuring an LDAP Server
21.4.3 Replacing the Default Certificates
21.4.4 Creating and Distributing Self-signed CA Certificates
21.4.5 Initializing an Organization in LDAP
21.4.6 Adding an Automount Map to LDAP
21.4.7 Adding a Group to LDAP
21.4.8 Adding a User to LDAP
21.4.9 Adding Users to a Group in LDAP
21.4.10 Enabling LDAP Authentication

The Lightweight Directory Access Protocol (LDAP) allows client systems to access information stored on LDAP servers over a network. An LDAP directory server stores information in a directory-based database that is optimized for searching and browsing, and which also supports simple functions for accessing and updating entries in the database.

Database entries are arranged in a hierarchical tree-like structure, where each directory can store information such as names, addresses, telephone numbers, network service information, printer information, and many other types of structured data. Systems can use LDAP for authentication, which allows users to access their accounts from any machine on a network.

The smallest unit of information in an LDAP directory is an entry, which can have one or more attributes. Each attribute of an entry has a name (also known as an attribute type or attribute description) and one or more values. Examples of types are domain component (dc), common name (cn), organizational unit (ou) and email address (mail). The objectClass attribute allows you to specify whether an attribute is required or optional. An objectClass attribute's value specifies the schema rules that an entry must obey.

A distinguished name (dn) uniquely identifies an entry in LDAP. The distinguished name consists of the name of the entry (the relative distinguished name or RDN) concatenated with the names of its ancestor entries in the LDAP directory hierarchy. For example, the distinguished name of a user with the RDN uid=arc815 might be uid=arc815,ou=staff,dc=mydom,dc=com.

The following are examples of information stored in LDAP for a user:

# User arc815
dn: uid=arc815,ou=People,dc=mydom,dc=com
cn: John Beck
givenName: John
sn: Beck
uid: arc815
uidNumber: 5159
gidNumber: 626
homeDirectory: /nethome/arc815
loginShell: /bin/bash
mail: johnb@mydom.com
objectClass: top
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
userPassword: {SSHA}QYrFtKkqOrifgk8H4EYf68B0JxIIaLga

and for a group:

# Group employees
dn: cn=employees,ou=Groups,dc=mydom,dc=com
cn: employees
gidNumber: 626
objectClass: top
objectClass: posixGroup
memberUid: arc815
memberUid: arc891

21.4.1 About LDAP Data Interchange Format

LDAP data itself is stored in a binary format. LDAP Data Interchange Format (LDIF) is a plain-text representation of an LDAP entry that allows the import and export LDAP data, usually to transfer the data between systems, but it also allows you to use a text editor to modify the content.

The data for an entry in an LDIF file takes the form:

[id] dn: distinguished_name
attribute_type: value | [attribute=]value[, [attribute=] value]...
...
objectClass: value
...

The optional id number is determined by the application that you use to edit the entry. Each attribute type for an entry contains either a value or a comma-separated list of attribute and value pairs as defined in the LDAP directory schema.

There must be a blank line between each dn definition section or include: line. There must not be any other blank lines or any white space at the ends of lines. White space at the start of a line indicates a continuation of the previous line.

21.4.2 Configuring an LDAP Server

OpenLDAP is an open-source implementation of LDAP that allows you configure an LDAP directory server.

To configure a system as an LDAP server:

  1. Install the OpenLDAP packages:

    # yum install openldap openldap-servers openldap-clients nss-pam-ldapd

    The OpenLDAP configuration is stored in the following files below /etc/openldap:

    ldap.conf

    The configuration file for client applications.

    slapd.d/cn=config.ldif

    The default global configuration LDIF file for OpenLDAP.

    slapd.d/cn=config/*.ldif

    Configuration LDIF files for the database and schema.

    slapd.d/cn=config/cn=schema/*.ldif

    Schema configuration LDIF files. More information about the OpenLDAP schema is available at http://www.openldap.org/doc/admin/schema.html.

    Note

    You should never need to edit any files under /etc/openldap/slapd.d as you can reconfigure OpenLDAP while the slapd service is running.

  2. If you want configure slapd to listen on port 636 for connections over an SSL tunnel (ldaps://), edit /etc/sysconfig/ldap, and change the value of SLAPD_LDAPS to yes:

    SLAPD_LDAPS=yes

    If required, you can prevent slapd listening on port 389 for ldap:// connections, by changing the value of SLAPD_LDAP to no:

    SLAPD_LDAP=no
  3. Allow incoming TCP connections on port 389 from the local network:

    # iptables -I INPUT -s subnet_addr/prefix_length -p tcp \
      -m state --state NEW -m tcp –dport 389 -j ACCEPT
    # service iptables save

    where subnet_addr/prefix_length specifies the network address, for example 192.168.2.0/24.

    The primary TCP port for LDAP is 389. If you configure LDAP to use an SSL tunnel (ldaps), substitute the port number that the tunnel uses, which is usually 636, for example:

    # iptables -I INPUT -s subnet_addr/prefix_length -p tcp \
      -m state --state NEW -m tcp -–dport 636 -j ACCEPT
    # service iptables save

    Add similar rules for other networks from which LDAP clients can connect.

  4. Change the user and group ownership of /var/lib/ldap and any files that it contains to ldap:

    # cd /var/lib/ldap
    # chown ldap:ldap ./*
  5. Start the slapd service and configure it to start following system reboots:

    # service slapd start
    # chkconfig slapd on
  6. Generate a hash of the LDAP password that you will use with the olcRootPW entry in the configuration file for your domain database, for example:

    # slappasswd -h {SSHA}
    New password: password
    Re-enter new password: password
    {SSHA}lkMShz73MZBic19Q4pfOaXNxpLN3wLRy
  7. Create an LDIF file with a name such as config-mydom-com.ldif that contains configuration entries for your domain database based on the following example:

    # Load the schema files required for accounts
    include file:///etc/ldap/schema/cosine.ldif
    
    include file:///etc/ldap/schema/nis.ldif
    
    include file:///etc/ldap/schema/inetorgperson.ldif
    
    # Load the HDB (hierarchical database) backend modules
    dn: cn=module,cn=config
    objectClass: olcModuleList
    cn: module
    olcModulepath: /usr/lib/ldap
    olcModuleload: back_hdb
    
    # Configure the database settings
    dn: olcDatabase=hdb,cn=config
    objectClass: olcDatabaseConfig
    objectClass: olcHdbConfig
    olcDatabase: {1}hdb
    olcSuffix: dc=mydom,dc=com
    # The database directory must already exist
    # and it should only be owned by ldap:ldap.
    # Setting its mode to 0700 is recommended
    olcDbDirectory: /var/lib/ldap
    olcRootDN: cn=admin,dc=mydom,dc=com
    olcRootPW: {SSHA}lkMShz73MZBic19Q4pfOaXNxpLN3wLRy
    olcDbConfig: set_cachesize 0 10485760 0
    olcDbConfig: set_lk_max_objects 2000
    olcDbConfig: set_lk_max_locks 2000
    olcDbConfig: set_lk_max_lockers 2000
    olcDbIndex: objectClass eq
    olcLastMod: TRUE
    olcDbCheckpoint: 1024 10
    # Set up access control
    olcAccess: to attrs=userPassword
      by dn="cn=admin,dc=mydom,dc=com"
      write by anonymous auth
      by self write
      by * none
    olcAccess: to attrs=shadowLastChange
      by self write
      by * read
    olcAccess: to dn.base=""
      by * read
    olcAccess: to *
      by dn="cn=admin,dc=mydom,dc=com"
      write by * read
    Note

    This configuration file allows you to reconfigure slapd while it is running. If you use a slapd.conf configuration file, you can also update slapd dynamically, but such changes do not persist if you restart the server.

    For more information, see the slapd-config(5) manual page.

  8. Use the ldapadd command to add the LDIF file:

    # ldapadd -Y EXTERNAL -H ldapi:/// -f config-mydom-com.ldif
    SASL/EXTERNAL authentication started
    SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
    SASL SSF: 0
    adding new entry "cn=module,cn=config"
    
    adding new entry "olcDatabase=hdb,cn=config"

For more information about configuring OpenLDAP, see the slapadd(8C), slapd(8C), slapd-config(5), and slappasswd(8C) manual pages, the OpenLDAP Administrator’s Guide (/usr/share/doc/openldap-servers-version/guide.html), and the latest OpenLDAP documentation at http://www.openldap.org/doc/.

21.4.3 Replacing the Default Certificates

If you configure LDAP to use Transport Layer Security (TLS) or Secure Sockets Layer (SSL) to secure the connection to the LDAP server, you need a public certificate that clients can download. You can obtain certificates from a Certification Authority (CA) or you can use the openssl command to create the certificate. See Section 21.4.4, “Creating and Distributing Self-signed CA Certificates”.

Once you have a server certificate, its corresponding private key file, and a root CA certificate, you can replace the default certificates that are installed in /etc/openldap/certs.

To display the existing certificate entries that slapd uses with TLS, use the ldapsearch command:

# ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b "cn=config" \
  olcTLSCACertificatePath olcTLSCertificateFile olcTLSCertificateKeyFile 
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: cn=config
olcTLSCACertificatePath: /etc/openldap/certs
olcTLSCertificateFile: "OpenLDAP Server"
olcTLSCertificateKeyFile: /etc/openldap/certs/password
...

To replace the TLS attributes in the LDAP configuration:

  1. Create an LDIF file that defines how to modify the attributes, for example:

    dn: cn=config
    changetype: modify
    delete: olcTLSCACertificatePath
    
    # Omit the following clause for olcTLSCACertificateFile
    # if you do not have a separate root CA certificate
    dn: cn=config
    changetype: modify
    add: olcTLSCACertificateFile
    olcTLSCACertificateFile: /etc/ssl/certsCAcert.pem
    
    dn: cn=config
    changetype: modify
    replace: olcTLSCertificateFile
    olcTLSCertificateFile: /etc/ssl/certs/server-cert.pem
    
    dn: cn=config
    changetype: modify
    replace: olcTLSCertificateKeyFile
    olcTLSCertificateKeyFile: /etc/ssl/certs/server-key.pem
    
    dn: cn=config
    changetype: modify
    add: olcTLSCipherSuite
    olcTLSCipherSuite: TLSv1+RSA:!NULL
    
    dn: cn=config
    changetype: modify
    add: olcTLSVerifyClient
    olcTLSVerifyClient: never

    If you generate only a self-signed certificate and its corresponding key file, you do not need to specify a root CA certificate.

  2. Use the ldapmodify command to apply the LDIF file:

    # ldapmodify -Y EXTERNAL -H ldapi:/// -f mod-TLS.ldif 
    SASL/EXTERNAL authentication started
    SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
    SASL SSF: 0
    modifying entry "cn=config"
    
    modifying entry "cn=config"
    
    modifying entry "cn=config"
    ...
  3. Verify that the entries have changed:

    # ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b "cn=config" \
      olcTLSCACertificatePath olcTLSCertificateFile olcTLSCertificateKeyFile 
    SASL/EXTERNAL authentication started
    SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
    SASL SSF: 0
    dn: cn=config
    olcTLSCACertificateFile: /etc/ssl/certs/CAcert.pem
    olcTLSCertificateFile: /etc/ssl/certs/server-cert.pem
    olcTLSCertificateKeyFile: /etc/ssl/certs/server-key.pem
    olcTLSCipherSuite: TLSv1+RSA:!NULL
    olcTLSVerifyClient: never
    ...
  4. Restart the slapd service to make it use the new certificates:

    # service slapd restart

For more information, see the ldapmodify(1), ldapsearch(1) and openssl(1) manual pages.

21.4.4 Creating and Distributing Self-signed CA Certificates

For usage solely within an organization, you might want to create certificates that you can use with LDAP. There are a number of ways of creating suitable certificates, for example:

  • Create a self-signed CA certificate together with a private key file.

  • Create a self-signed root CA certificate and private key file, and use the CA certificate and its key file to sign a separate server certificate for each server.

The following procedure describes how to use openssl to create a self-signed CA certificate and private key file, and then use these files to sign server certificates.

To create the CA certificate and use it to sign a server certificate:

  1. Change directory to /etc/openldap/certs on the LDAP server:

    # cd /etc/openldap/certs
  2. Create the private key file CAcert-key.pem for the CA certificate:

    # openssl genrsa -out CAcert-key.pem 1024
    Generating RSA private key, 1024 bit long modulus
    ......++++++
    ....++++++
    e is 65537 (0x10001)
  3. Change the mode on the key file to 0400:

    # chmod 0400 CAcert-key.pem
  4. Create the certificate request CAcert.csr:

    # openssl req -new -key CAcert-key.pem -out CAcert.csr
    You are about to be asked to enter information that will be incorporated
    into your certificate request.
    What you are about to enter is what is called a Distinguished Name or a DN.
    There are quite a few fields but you can leave some blank
    For some fields there will be a default value,
    If you enter '.', the field will be left blank.
    -----
    Country Name (2 letter code) [XX]:US
    State or Province Name (full name) []:California
    Locality Name (eg, city) [Default City]:Redwood City
    Organization Name (eg, company) [Default Company Ltd]:Mydom Inc
    Organizational Unit Name (eg, section) []:Org
    Common Name (eg, your name or your server's hostname) []:www.mydom.org
    Email Address []:root@mydom.org
    
    Please enter the following 'extra' attributes
    to be sent with your certificate request
    A challenge password []:<Enter>
    An optional company name []:<Enter>
  5. Create a CA certificate that is valid for approximately three years:

    # openssl x509 -req -days 1095 -in CAcert.csr -signkey CAcert-key.pem -out CAcert.pem
    rt-key.pem -out CAcert.pem
    Signature ok
    subject=/C=US/ST=California/L=Redwood City/O=Mydom 
    Inc/OU=Org/CN=www.mydom.org/emailAddress=root@mydom.org
    Getting Private key
  6. For each server certificate that you want to create:

    1. Create the private key for the server certificate:

      # openssl genrsa -out server-key.pem 1024
      Generating RSA private key, 1024 bit long modulus
      .............++++++
      ...........................++++++
      e is 65537 (0x10001)
      Note

      If you intend to generate server certificates for several servers, name the certificate, its key file, and the certificate request so that you can easily identify both the server and the service, for example, ldap_host02-cert.pem, ldap_host02-key.pem, and ldap_host02-cert.csr.

    2. Change the mode on the key file to 0400, and change its user and group ownership to ldap:

      # chmod 0400 server-key.pem
      # chown ldap:ldap server-key.pem
    3. Create the certificate request server-cert.csr:

      # openssl req -new -key server-key.pem -out server-cert.csr
      You are about to be asked to enter information that will be incorporated
      into your certificate request.
      What you are about to enter is what is called a Distinguished Name or a DN.
      There are quite a few fields but you can leave some blank
      For some fields there will be a default value,
      If you enter '.', the field will be left blank.
      -----
      Country Name (2 letter code) [XX]:US
      State or Province Name (full name) []:California
      Locality Name (eg, city) [Default City]:Redwood City
      Organization Name (eg, company) [Default Company Ltd]:Mydom Inc
      Organizational Unit Name (eg, section) []:Org
      Common Name (eg, your name or your server's hostname) []:ldap.mydom.com
      Email Address []:root@mydom.com
      
      Please enter the following 'extra' attributes
      to be sent with your certificate request
      A challenge password []:<Enter>
      An optional company name []:<Enter>
      Note

      For the Common Name, specify the Fully Qualified Domain Name (FQDN) of the server. If the FQDN of the server does not match the common name specified in the certificate, clients cannot obtain a connection to the server.

    4. Use the CA certificate and its corresponding key file to sign the certificate request and generate the server certificate:

      # openssl x509 -req -days 1095 -CAcreateserial \
        -in server-cert.csr -CA CAcert.pem -CAkey CAcert-key.pem \
        -out server-cert.pem
      Signature ok
      subject=/C=US/ST=California/L=Redwood City/O=Mydom 
      Inc/OU=Org/CN=ldap.mydom.com/emailAddress=root@mydom.com
      Getting CA Private Key
  7. If you generate server certificates for other LDAP servers, copy the appropriate server certificate, its corresponding key file, and the CA certificate to /etc/openldap/certs on those servers.

  8. Set up a web server to host the CA certificate for access by clients. The following steps assume that the LDAP server performs this function. You can use any suitable, alternative server instead.

    1. Install the Apache HTTP server.

      # yum install httpd
    2. Create a directory for the CA certificate under /var/www/html, for example:

      # mkdir /var/www/html/certs
    3. Copy the CA certificate to /var/www/html/certs.

      # cp CAcert.pem /var/www/html/certs
      Caution

      Do not copy the key files.

    4. Edit the HTTP server configuration file, /etc/httpd/conf/httpd.conf, and specify the resolvable domain name of the server in the argument to ServerName.

      ServerName server_addr:80

      If the server does not have a resolvable domain name, enter its IP address instead.

      Verify that the setting of the Options directive in the <Directory "/var/www/html"> section specifies Indexes and FollowSymLinks to allow you to browse the directory hierarchy, for example:

      Options Indexes FollowSymLinks
    5. Start the Apache HTTP server, and configure it to start after a reboot.

      # service httpd start
      # chkconfig httpd on
    6. If you have enabled a firewall on your system, configure it to allow incoming HTTP connection requests on TCP port 80.

      For example, the following command configures iptables to allow incoming HTTP connection requests and saves the change to the firewall configuration:

      # iptables -I INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
      # service iptables save

21.4.5 Initializing an Organization in LDAP

Before you can define people, groups, servers, printers, and other entitles for your organization, you must first set up information in LDAP for the organization itself.

To define an organization in LDAP:

  1. Create an LDIF file that defines the organization, for example mydom-com-organization.ldif:

    # Organization mydom.com
    dn: dc=mydom,dc=com
    dc: mydom
    objectclass: dcObject
    objectclass: organizationalUnit
    ou: mydom.com
    
    # Users
    dn: ou=People,dc=mydom,dc=com
    objectClass: organizationalUnit
    ou: people
    
    # Groups
    dn: ou=Groups,dc=mydom,dc=com
    objectClass: organizationalUnit
    ou: groups
  2. If you have configured LDAP authentication, use the ldapadd command to add the organization to LDAP:

    # ldapadd -cxWD "cn=admin,dc=mydom,dc=com" -f mydom-com-organization.ldif
    Enter LDAP Password: admin_password
    adding new entry "dc=mydom,dc=com"
    
    adding new entry "ou=People,dc=mydom,dc=com"
    
    adding new entry "ou=Groups,dc=mydom,dc=com"

    If you have configured Kerberos authentication, use kinit to obtain a ticket granting ticket (TGT) for the admin principal, and use this form of the ldapadd command:

    # ldapadd -f mydom-com-organization.ldif

For more information, see the ldapadd(1) manual page.

21.4.6 Adding an Automount Map to LDAP

You can make an automount map such as auto.home available in LDAP so that the automounter mounts a user's home directory on demand.

To add the auto.home map to LDAP:

  1. Create an LDIF file that defines entries for the map's name and its contents, for example auto-home.ldif:

    dn: nisMapName=auto.home,dc=mydom,dc=com
    objectClass: top
    objectClass: nisMap
    nisMapName: auto.home
    
    dn: cn=*,nisMapName=auto.home,dc=mydom,dc=com
    objectClass: nisObject
    cn: *
    nisMapEntry: -rw,sync nfssvr:/nethome/&
    nisMapName: auto.home

    where nfssvr is the host name or IP address of the NFS server that exports the users' home directories.

  2. If you have configured LDAP authentication, use the following command to add the map to LDAP:

    # ldapadd -xcWD "cn=admin,dc=mydom,dc=com" \
      -f auto-home.ldif
    Enter LDAP Password: user_password
    adding new entry "nisMapName=auto.home,dc=mydom,dc=com"
    
    adding new entry "cn=*,nisMapName=auto.home,dc=mydom,dc=com"

    If you have configured Kerberos authentication, use kinit to obtain a ticket granting ticket (TGT) for the admin principal, and use this form of the command:

    # ldapmodify -f auto-home.ldif
  3. Verify that the map appears in LDAP:

    # ldapsearch -LLL -x -b "dc=mydom,dc=com" nisMapName=auto.home
    dn: nisMapName=auto.home,dc=mydom,dc=com
    objectClass: top
    objectClass: nisMap
    nisMapName: auto.home
    
    dn: cn=*,nisMapName=auto.home,dc=mydom,dc=com
    objectClass: nisObject
    cn: *
    nisMapEntry: -rw,sync nfssvr.mydom.com:/nethome/&
    nisMapName: auto.home

21.4.7 Adding a Group to LDAP

If you configure users in user private groups (UPGs), define that group along with the user. See Section 21.4.8, “Adding a User to LDAP”.

To add a group to LDAP:

  1. Create an LDIF file that defines the group, for example employees-group.ldif:

    # Group employees
    dn: cn=employees,ou=Groups,dc=mydom,dc=com
    cn: employees
    gidNumber: 626
    objectClass: top
    objectclass: posixGroup
  2. If you have configured LDAP authentication, use the following command to add the group to LDAP:

    # ldapadd -cxWD "cn=admin,dc=mydom,dc=com" -f employees-group.ldif
    Enter LDAP Password: admin_password
    adding new entry "cn=employees,ou=Groups,dc=mydom,dc=com"

    If you have configured Kerberos authentication, use kinit to obtain a ticket granting ticket (TGT) for the admin principal, and use this form of the ldapadd command:

    # ldapadd -f employees-group.ldif
  3. Verify that you can locate the group in LDAP:

    # ldapsearch -LLL -x -b "dc=mydom,dc=com" gidNumber=626
    dn: cn=employees,ou=Groups,dc=mydom,dc=com
    cn: employees
    gidNumber: 626
    objectClass: top
    objectClass: posixGroup

For more information, see the ldapadd(1) and ldapsearch(1) manual pages.

21.4.8 Adding a User to LDAP

Note

This procedure assumes that:

To create an account for a user on the LDAP server:

  1. If the LDAP server does not already export the base directory of the users' home directories, perform the following steps on the LDAP server:

    1. Create the base directory for user directories, for example /nethome:

      # mkdir /nethome
    2. Add an entry such as the following to /etc/exports:

      /nethome    *(rw,sync)

      You might prefer to restrict which clients can mount the file system. For example, the following entry allows only clients in the 192.168.1.0/24 subnet to mount /nethome:

      /nethome    192.168.1.0/24(rw,sync)
    3. Use the following command to export the file system:

      # exportfs -i -o ro,sync *:/nethome
  2. Create the user account, but do not allow local logins:

    # useradd -b base_dir -s /sbin/nologin -u UID -U username

    For example:

    # useradd -b /nethome -s /sbin/nologin -u 5159 -U arc815

    The command updates the /etc/passwd file and creates a home directory under /nethome on the LDAP server.

    The user's login shell will be overridden by the LoginShell value set in LDAP.

  3. Use the id command to list the user and group IDs that have been assigned to the user, for example:

    # id arc815
    uid=5159(arc815) gid=5159(arc815) groups=5159(arc815)
  4. Create an LDIF file that defines the user, for example arc815-user.ldif:

    # UPG arc815
    dn: cn=arc815,ou=Groups,dc=mydom,dc=com
    cn: arc815
    gidNumber: 5159
    objectclass: top
    objectclass: posixGroup
    
    # User arc815
    dn: uid=arc815,ou=People,dc=mydom,dc=com
    cn: John Beck
    givenName: John
    sn: Beck
    uid: arc815
    uidNumber: 5159
    gidNumber: 5159
    homeDirectory: /nethome/arc815
    loginShell: /bin/bash
    mail: johnb@mydom.com
    objectClass: top
    objectClass: inetOrgPerson
    objectClass: posixAccount
    objectClass: shadowAccount
    userPassword: {SSHA}x

    In this example, the user belongs to a user private group (UPG), which is defined in the same file. The user’s login shell attribute LoginShell is set to /bin/bash. The user's password attribute userPassword is set to a placeholder value. If you use Kerberos authentication with LDAP, this attribute is not used.

  5. If you have configured LDAP authentication, use the following command to add the user to LDAP:

    # ldapadd -cxWD cn=admin,dc=mydom,dc=com -f arc815-user.ldif
    Enter LDAP Password: admin_password
    adding new entry "cn=arc815,ou=Groups,dc=mydom,dc=com"
    
    adding new entry "uid=arc815,ou=People,dc=mydom,dc=com"

    If you have configured Kerberos authentication, use kinit to obtain a ticket granting ticket (TGT) for the admin principal, and use this form of the ldapadd command:

    # ldapadd -f arc815-user.ldif
  6. Verify that you can locate the user and his or her UPG in LDAP:

    # ldapsearch -LLL -x -b "dc=mydom,dc=com" '(|(uid=arc815)(cn=arc815))'
    dn: cn=arc815,ou=Groups,dc=mydom,dc=com
    cn: arc815
    gidNumber: 5159
    objectClass: top
    objectClass: posixGroup
    
    dn: uid=arc815,ou=People,dc=mydom,dc=com
    cn: John Beck
    givenName: John
    sn: Beck
    uid: arc815
    uidNumber: 5159
    gidNumber: 5159
    homeDirectory: /home/arc815
    loginShell: /bin/bash
    mail: johnb@mydom.com
    objectClass: top
    objectClass: inetOrgPerson
    objectClass: posixAccount
    objectClass: shadowAccount
  7. If you have configured LDAP authentication, set the user password in LDAP:

    # ldappasswd -xWD "cn=admin,dc=mydom,dc=com" \
      -S "uid=arc815,ou=people,dc=mydom,dc=com"
    New password: user_password
    Re-enter new password: user_password
    Enter LDAP Password: admin_password

    If you have configured Kerberos authentication, use kinit to obtain a ticket granting ticket (TGT) for the admin principal, and use the kadmin command to add the user (principal) and password to the database for the Kerberos domain, for example:

    # kadmin -q "addprinc alice@MYDOM.COM"

For more information, see the kadmin(1), ldapadd(1), ldappasswd(1), and ldapsearch(1) manual pages.

21.4.9 Adding Users to a Group in LDAP

To add users to an existing group in LDAP:

  1. Create an LDIF file that defines the users that should be added to the memberuid attribute for the group, for example employees-add-users.ldif:

    dn: cn=employees,ou=Groups,dc=mydom,dc=com
    changetype: modify
    add: memberUid
    memberUid: arc815
    
    dn: cn=employees,ou=Groups,dc=mydom,dc=com
    changetype: modify
    add: memberUid
    memberUid: arc891
    
    ...
  2. If you have configured LDAP authentication, use the following command to add the group to LDAP:

    # ldapmodify -xcWD "cn=admin,dc=mydom,dc=com" \
      -f employees-add-users.ldif
    Enter LDAP Password: user_password
    modifying entry "cn=employees,ou=Groups,dc=mydom,dc=com"
    ...

    If you have configured Kerberos authentication, use kinit to obtain a ticket granting ticket (TGT) for the admin principal, and use this form of the command:

    # ldapmodify -f employees-add-users.ldif
  3. Verify that the group has been updated in LDAP:

    # ldapsearch -LLL -x -b "dc=mydom,dc=com" gidNumber=626
    dn: cn=employees,ou=Groups,dc=mydom,dc=com
    cn: employees
    gidNumber: 626
    objectClass: top
    objectClass: posixGroup
    memberUid: arc815
    memberUid: arc891
    ...

21.4.10 Enabling LDAP Authentication

To enable LDAP authentication for an LDAP client by using the Authentication Configuration GUI:

  1. Install the openldap-clients package:

    # yum install openldap-clients
  2. Run the Authentication Configuration GUI:

    # system-config-authentication
  3. Select LDAP as the user account database and enter values for:

    LDAP Search Base DN

    The LDAP Search Base DN for the database. For example: dc=mydom,dc=com.

    LDAP Server

    The URL of the LDAP server including the port number. For example, ldap://ldap.mydom.com:389 or ldaps://ldap.mydom.com:636.

    LDAP authentication requires that you use either LDAP over SSL (ldaps) or Transport Layer Security (TLS) to secure the connection to the LDAP server.

  4. If you use TLS, click Download CA Certificate and enter the URL from which to download the CA certificate that provides the basis for authentication within the domain.

  5. Select either LDAP password or Kerberos password for authentication.

  6. If you select Kerberos authentication, enter values for:

    Realm

    The name of the Kerberos realm.

    KDCs

    A comma-separated list of Key Distribution Center (KDC) servers that can issue Kerberos ticket granting tickets and service tickets.

    Admin Servers

    A comma-separated list of Kerberos administration servers.

    Alternatively, you can use DNS to configure these settings:

    • Select the Use DNS to resolve hosts to realms check box to look up the name of the realm defined as a TXT record in DNS, for example:

      _kerberos.mydom.com    IN TXT "MYDOM.COM"
    • Select the Use DNS to locate KDCs for realms check box to look up the KDCs and administration servers defined as SVR records in DNS, for example:

      _kerberos._tcp.mydom.com      IN SVR 1  0 88  krbsvr.mydom.com
      _kerberos._udp.mydom.com      IN SVR 1  0 88  krbsvr.mydom.com
      _kpasswd._udp.mydom.com       IN SVR 1  0 464 krbsvr.mydom.com
      _kerberos-adm._tcp.mydom.com  IN SVR 1  0 749 krbsvr.mydom.com
  7. Click Apply to save your changes.

Figure 21.3 shows the Authentication Configuration GUI with LDAP selected for the user account database and for authentication.

Figure 21.3 Authentication Configuration Using LDAP

The figure shows the Authentication Configuration GUI with LDAP selected as the user account database and for authentication.


You can also enable LDAP by using the authconfig command.

To use LDAP as the authentication source, specify the --enableldapauth option together with the full LDAP server URL including the port number and the LDAP Search Base DN, as shown in the following example:.

# authconfig --enableldap --enableldapauth \
  --ldapserver=ldaps://ldap.mydom.com:636 \
  --ldapbasedn="ou=people,dc=mydom,dc=com" \
  --update

If you want to use TLS, additionally specify the --enableldaptls option and the download URL of the CA certificate, for example:

# authconfig --enableldap --enableldapauth \
  --ldapserver=ldap://ldap.mydom.com:389 \
  --ldapbasedn="ou=people,dc=mydom,dc=com" \
  --enableldaptls \
  --ldaploadcacert=https://ca-server.mydom.com/CAcert.pem \
  --update 

The --enableldap option configures /etc/nsswitch.conf to enable the system to use LDAP and SSSD for information services. The --enableldapauth option enables LDAP authentication by modifying the PAM configuration files in /etc/pam.d to use the pam_ldap.so module.

For more information, see the authconfig(8), pam_ldap(5), and nsswitch.conf(5) manual pages.

For information about using Kerberos authentication with LDAP, see Section 21.6.3, “Enabling Kerberos Authentication”.

Note

You must also configure SSSD to be able to access information in LDAP. See Section 21.4.10.1, “Configuring an LDAP Client to use SSSD”.

If your client uses automount maps stored in LDAP, you must configure autofs to work with LDAP. See Section 21.4.10.2, “Configuring an LDAP Client to Use Automount Maps”.

21.4.10.1 Configuring an LDAP Client to use SSSD

The Authentication Configuration GUI and authconfig configure access to LDAP via sss entries in /etc/nsswitch.conf so you must configure the System Security Services Daemon (SSSD) on the LDAP client.

To configure an LDAP client to use SSSD:

  1. Install the sssd and sssd-client packages:

    # yum install sssd sssd-client
  2. Edit the /etc/sssd/sssd.conf configuration file and configure the sections to support the required services, for example:

    [sssd]
    config_file_version = 2
    domains = default
    services = nss, pam
    
    [domain/default]
    id_provider = ldap
    ldap_uri = ldap://ldap.mydom.com
    ldap_id_use_start_tls = true
    ldap_search_base = dc=mydom,dc=com
    ldap_tls_cacertdir = /etc/openldap/cacerts
    
    auth_provider = krb5
    chpass_provider = krb5
    krb5_realm = MYDOM.COM
    krb5_server = krbsvr.mydom.com
    krb5_kpasswd = krbsvr.mydom.com
    cache_credentials = true
    
    [domain/LDAP]
    id_provider = ldap
    ldap_uri = ldap://ldap.mydom.com
    ldap_search_base = dc=mydom,dc=com
    
    auth_provider = krb5
    krb5_realm = MYDOM.COM
    krb5_server = kdcsvr.mydom.com
    cache_credentials = true
    
    min_id = 5000
    max_id = 25000
    enumerate = false
    
    [nss]
    filter_groups = root
    filter_users = root
    reconnection_retries = 3
    entry_cache_timeout = 300
    
    [pam]
    reconnection_retries = 3
    offline_credentials_expiration = 2
    offline_failed_login_attempts = 3
    offline_failed_login_delay = 5
  3. Change the mode of /etc/sssd/sssd.conf to 0600:

    # chmod 0600 /etc/sssd/sssd.conf
  4. Enable the SSSD service:

    # authconfig --update --enablesssd –-enablesssdauth

For more information, see the sssd.conf(5) manual page and Section 21.8, “About the System Security Services Daemon”.

21.4.10.2 Configuring an LDAP Client to Use Automount Maps

If you have configured an automount map for auto.home in LDAP, you can configure an LDAP client to mount the users' home directories when they log in.

To configure an LDAP client to automount users' home directories:

  1. Install the autofs package:

    # yum install autofs 
  2. Verify that the auto.home map is available :

    # ldapsearch -LLL -x -b "dc=mydom,dc=com" nisMapName=auto.home
    dn: nisMapName=auto.home,dc=mydom,dc=com
    objectClass: top
    objectClass: nisMap
    nisMapName: auto.home
    
    dn: cn=*,nisMapName=auto.home,dc=mydom,dc=com
    objectClass: nisObject
    cn: *
    nisMapEntry: -rw,sync nfssvr.mydom.com:/nethome/&
    nisMapName: auto.home

    In this example, the map is available. For details of how to make this map available, see Section 21.4.6, “Adding an Automount Map to LDAP”.

  3. If the auto.home map is available, edit /etc/auto.master and create an entry that tells autofs where to find the auto.home map in LDAP, for example:

    /nethome    ldap:nisMapName=auto.home,dc=mydom,dc=com

    If you use LDAP over SSL, specify ldaps: instead of ldap:.

  4. Edit /etc/autofs_ldap_auth.conf and configure the authentication settings for autofs with LDAP, for example:

    <autofs_ldap_sasl_conf
         usetls="yes"
         tlsrequired="no"
         authrequired="autodetect"
         authtype="GSSAPI"
         clientprinc="host/ldapclient.mydom.com@MYDOM.COM" 
         />

    This example assumes that Kerberos authentication with the LDAP server uses TLS for the connection. The principal for the client system must exist in the Kerberos database. You can use the klist -k command to verify this. If the principal for the client does not exist, use kadmin to add the principal.

  5. If you use Kerberos Authentication, use kadmin to add a principal for the LDAP service on the LDAP server, for example:

    # kadmin -q "addprinc ldap/ldap.mydom.com@MYDOM.COM
  6. Restart the autofs service, and configure the service to start following a system reboot:

    # service autofs restart
    # chkconfig autofs on

    The autofs service creates the directory /nethome. When a user logs in, the automounter mounts his or her home directory under /nethome.

    If the owner and group for the user's files are unexpectedly listed as the anonymous user or group (nobody or nogroup) and all_squash has not been specified as a mount option, verify that the Domain setting in /etc/idmapd.conf on the NFS server is set to the DNS domain name. Restart the NFS services on the NFS server if you change this file.

For more information, see the auto.master(5) and autofs_ldap_auth.conf(5) manual pages.