You can use the User Manager GUI (system-config-users) to add or delete users and groups and to modify settings such as passwords, home directories, login shells, and group membership. Alternatively, you can use commands such as useradd and groupadd. The User Manager GUI is available if you install the system-config-users package.

To enable local access control, select the Enable local access control check box on the Advanced Options tab of the Authentication Configuration GUI (system-config-authentication). The system can then read the /etc/security/access.conf file for local user authorization rules that specify login combinations that the system accepts or refuses.

Figure 1-2 Authentication Configuration Advanced Options

Alternatively, use the following command:

# authconfig --enablepamaccess --update   

Each entry in /etc/security/access.conf takes the form:

permission : users : origins [ except ]

The following is a description of each entry in the file:

permission

Set to + or - to grant or deny login respectively.

users

Specifies a space-separated list of user or group names or ALL for any user or group. Enclose group names in parentheses to distinguish them from user names. You can use the EXCEPT operator to exclude a list of users from the rule.

origins

Specifies a space-separated list of host names, fully qualified domain names, network addresses, terminal device names, ALL, or NONE. You can use the EXCEPT operator to exclude a list of origins from the rule.

For example, the following rule denies login access by anyone except root from the network 192.168.2.0/24:

- : ALL except root : 192.168.2.0/24

For more information, see the access.conf(5) manual page and Local Account Configuration.

If appropriate hardware is installed and supported, the system can use fingerprint scans to authenticate users.

To enable fingerprint reader support, select the Enable fingerprint reader support check box on the Advanced Options tab of the Authentication Configuration GUI (system-config-authentication).

Alternatively, use the following command:

# authconfig --enablefingerprint --update     

If appropriate hardware is installed and supported, the system can use smart cards to authenticate users. The pam_pkcs11 package provides a PAM login module that enables X.509 certificate-based user authentication. The module uses the Name Service Switch (NSS) to manage and validate PKCS #11 smart cards by using locally stored root CA certificates, online or locally accessible certificate revocation lists (CRLs), and the Online Certificate Status Protocol (OCSP).

To enable smart card authentication:

1. Install the pam_pkcs11 package:

   # yum install pam_pkcs11

2. Use the following command to install the root CA certificates in the NSS database:

   # certutil -A -d /etc/pki/nssdb -t "TC,C,C" -n "Root CA certificates" -i CACert.pem

   In the previous command, CACert.pem is the base-64 format root CA certificate file.

3. Run the Authentication Configuration GUI:

   # system-config-authentication

4. On the Advanced Options tab, select the Enable smart card support check box.

5. If you want to disable all other login authentication methods, select the Require smart card for login check box.

   Caution:

   Do not select this option until you have tested that can use a smart card to authenticate with the system.

6. From the Card removal action menu, select the system's response if a user removes a smart card while logged in to a session:

   Ignore

   The system ignores card removal for the current session.

   Lock

   The system locks the user out of the session .

You can also use the following command to configure smart card authentication:

# authconfig --enablesmartcard --update

To specify the system's response if a user removes a smart card while logged in to a session:

authconfig --smartcardaction=0|1 --update

Specify a value of 0 to --smartcardaction to lock the system if a card is removed. To ignore card removal, use a value of 1.

Once you have tested that you can use a smart card to authenticate with the system, you can disable all other login authentication methods.

# authconfig --enablerequiresmartcard --update

To be able to configure IPA authentication, use yum to install the ipa-client and ipa-admintools packages. The ipa-server package is only required if you want to configure a system as an IPA server.

You can choose between two versions of IPA in the Authentication Configuration GUI:

• FreeIPA (effectively, IPAv1) supports identity management and authentication of users and groups, and does not require you to join your system to an IPA realm. Enter information about the LDAP and Kerberos configuration.

• IPAv2, which supports identity management and authentication of machines, requires you to join your system to an IPA realm. Enter information about the IPA domain configuration, optionally choose to configure NTP, and click Join Domain to create a machine account on the IPA server. After your system has obtained permission to join the IPA realm, you can select and configure the authentication method.

If you use the Authentication Configuration GUI and select IPA v2 as the user account database, you are prompted to enter the names of the IPA domain, realm, and server. You can also select to configure NTP so that the system time is consistent with the IPA server. If you have initialized Kerberos, you can click Join Domain to create a machine account on the IPA server and grant permission to join the domain.

For more information about configuring IPA, see http://www.freeipa.org/page/Documentation.

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 empty space at the ends of lines. An empty space at the start of a line indicates a continuation of the previous line.

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 in OpenLDAP administrator guides at https://www.openldap.org/doc/.

   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/slapd, 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

   Ensure that you also define the correct SLAPD_URLS for the ports that are enabled. For instance, if you intend to use SSL and you wish slapd to listen on port 636, you must specify ldaps:// as one of the supported URLS. For example:

   SLAPD_URLS="ldapi:/// ldap:/// ldaps:///"

3. Configure the system firewall to allow incoming TCP connections on port 389, for example:

   # firewall-cmd --zone=zone --add-port=389/tcp
   # firewall-cmd --permanent --zone=zone --add-port=389/tcp

   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:

   # firewall-cmd --zone=zone --add-port=636/tcp
   # firewall-cmd --permanent --zone=zone --add-port=636/tcp

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:

   # systemctl start slapd
   # systemctl enable slapd

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/openldap/schema/cosine.ldif
   
   include file:///etc/openldap/schema/nis.ldif
   
   include file:///etc/openldap/schema/inetorgperson.ldif
   
   # Load the HDB (hierarchical database) backend modules
   dn: cn=module,cn=config
   objectClass: olcModuleList
   cn: module
   olcModulepath: /usr/lib64/openldap
   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 https://www.openldap.org/doc/.

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 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:

   # systemctl restart slapd

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

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.

      # systemctl start httpd
      # systemctl enable httpd    

   6. If you have enabled the firewall on your system, configure it to allow incoming HTTP connection requests on TCP port 80, for example:

      # firewall-cmd --zone=zone --add-port=80/tcp
      # firewall-cmd --permanent --zone=zone --add-port=80/tcp

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.

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

   In the previous example, nfssvr is the host name or IP address of the NFS server that exports the home directories of the users.

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

If you configure users in user private groups (UPGs), define that group along with the user. See 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.

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.

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

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 1-3 Authentication Configuration Using LDAP

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 Enabling Kerberos Authentication.

The administrative files within an NIS domain are NIS maps, which are dbm-format files that you generate from existing configuration files such as /etc/passwd, /etc/shadow, and /etc/groups. Each map is indexed on one field, and records are retrieved by specifying a value from that field. Some source files such as /etc/passwd have two maps:

passwd.byname

Indexed on user name.

passwd.byuid

Indexed on user ID.

The /var/yp/nicknames file contains a list of commonly used short names for maps such as passwd for passwd.byname and group for group.byname.

You can use the ypcat command to display the contents of an NIS map, for example:

# ypcat - passwd | grep 1500
guest:$6$gMIxsr3W$LaAo...6EE6sdsFPI2mdm7/NEm0:1500:1500::/nethome/guest:/bin/bash

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

NIS primary servers act as a central, authoritative repository for NIS information. NIS worker servers act as mirrors of this information. There must be only one NIS primary server in an NIS domain. The number of NIS worker servers is optional, but creating at least one worker server provides a degree of redundancy should the primary server be unavailable.

To configure an NIS primary or worker server:

1. Install the ypserv package:

   # yum install ypserv

2. Edit /etc/sysconfig/network and add an entry to define the NIS domain, for example:

   NISDOMAIN=mynisdom

3. Edit /etc/ypserv.conf to configure NIS options and to add rules for which hosts and domains can access which NIS maps.

   For example, the following entries allow access only to NIS clients in the mynisdom domain on the 192.168.1 subnet:

   192.168.1.0/24: mynisdom : * : none
   * : * : * : deny

   For more information, see the ypserv.conf(5) manual page and the comments in /etc/ypserv.conf.

4. Create the file /var/yp/securenets and add entries for the networks for which the server should respond to requests, for example:

   # cat > /var/yp/securenets <<!
   255.255.255.255 127.0.0.1
   255.255.255.0   192.168.1.0
   !
   # cat /var/yp/securenets 
   255.255.255.255 127.0.0.1
   255.255.255.0   192.168.1.0

   In this example, the server accepts requests from the local loopback interface and the 192.168.1 subnet.

5. Edit /var/yp/Makefile:

   1. Set any required map options and specify which NIS maps to create using the all target, for example:

      all:
      passwd group auto.home
      # hosts rpc services netid protocols mail \
      # netgrp shadow publickey networks ethers bootparams printcap \
      # amd.home auto.local. passwd.adjunct \
      # timezone locale netmasks

      This example allows NIS to create maps for the /etc/passwd, /etc/group, and /etc/auto.home files. By default, the information from the /etc/shadow file is merged with the passwd maps, and the information from the /etc/gshadow file is merged with the group maps.

      For more information, see the comments in /var/yp/Makefile.

   2. If you intend to use Kerberos authentication instead of NIS authentication, change the values of MERGE_PASSWD and MERGE_GROUP to false:

      MERGE_PASSWD=false
      MERGE_GROUP=false

      Note:

      These settings prevent password hashes from appearing in the NIS maps.

   3. If you configure any NIS worker servers in the domain, set the value of NOPUSH to false:

      NOPUSH=false

      If you update the maps, this setting allows the primary server to automatically push the maps to the worker servers.

6. Configure the NIS services:

   1. Start the ypserv service and configure it to start after system reboots:

      # systemctl start ypserv
      # systemctl enable ypserv

      The ypserv service runs on the NIS primary server and any worker servers.

   2. If the server will act as the primary NIS server and there will be at least one worker NIS server, start the ypxfrd service and configure it to start after system reboots:

      # systemctl start ypxfrd
      # systemctl enable ypxfrd

      The ypxfrd service speeds up the distribution of very large NIS maps from an NIS primary to any NIS worker servers. The service runs on the primary server only, and not on any worker servers. You do not need to start this service if there are no worker servers.

   3. Start the yppasswdd service and configure it to start after system reboots:

      # systemctl start yppasswdd
      # systemctl enable yppasswdd

      The yppasswdd service allows NIS users to change their password in the shadow map. The service runs on the NIS primary server and any worker servers.

7. Configure the firewall settings:

   1. Edit /etc/sysconfig/network and add the following entries that define the ports on which the ypserv and ypxfrd services listen:

      YPSERV_ARGS="-p 834"
      YPXFRD_ARGS="-p 835"

      These entries fix the ports on which ypserv and ypxfrd listen.

   2. Allow incoming TCP connections to ports 111 and 834 and incoming UDP datagrams on ports 111 and 834:

      # firewall-cmd --zone=zone --add-port=111/tcp --add-port=111/udp \
        --add-port=834/tcp --add-port=834/udp
      # firewall-cmd --permanent --zone=zone --add-port=111/tcp --add-port=111/udp \
        --add-port=834/tcp --add-port=834/udp

      portmapper services requests on TCP port 111 and UDP port 111, and ypserv services requests on TCP port 834 and UDP port 834.

   3. On the primary server, if you run the ypxfrd service to support transfers to worker servers, allow incoming TCP connections to port 835 and incoming UDP datagrams on port 835:

      # firewall-cmd --zone=zone --add-port=835/tcp --add-port=835/udp
      # firewall-cmd --permanent --zone=zone --add-port=835/tcp --add-port=835/udp

   4. Allow incoming UDP datagrams on the port on which yppasswdd listens:

      # firewall-cmd --zone=zone \
        --add-port=`rpcinfo -p | gawk '/yppasswdd/ {print $4}'`/udp

      Note:

      Do not make this rule permanent. The UDP port number that yppasswdd uses is different every time that it restarts.

   5. Edit /etc/rc.local and add the following line:

      firewall-cmd --zone=zone \
        --add-port=`rpcinfo -p | gawk '/yppasswdd/ {print $4}'`/udp

      This entry creates a firewall rule for the yppasswdd service when the system reboots. If you restart yppasswdd, you must correct the firewall rules manually unless you modify the /etc/init.d/yppasswdd script.

8. After you have started all the servers, create the NIS maps on the primary NIS server:

   # /usr/lib64/yp/ypinit -m
   
   At this point, we have to construct a list of the hosts which will run NIS
   servers.  nisprimary is in the list of NIS server hosts.  Please continue to add
   the names for the other hosts, one per line.  When you are done with the
   list, type a <control D>."
         next host to add:  nisprimary
         next host to add:  nisworker1
         next host to add:  nisworker2
         next host to add:  ^D
   
   The current list of NIS servers looks like this:
   
   nisprimary nisworker1 nisworker2
   
   Is this correct?  [y/n: y]  y
   We need a few minutes to build the databases...
   ...
   localhost has been set up as a NIS master server.
   
   Now you can run ypinit -s nisprimary on all slave server.

   Enter the host names of the NIS worker servers (if any), type Ctrl-D to finish, and enter y to confirm the list of NIS servers. The host names must be resolvable to IP addresses in DNS or by entries in /etc/hosts.

   The ypinit utility builds the domain subdirectory in /var/yp and makes the NIS maps that are defined for the all target in /var/yp/Makefile. If you have configured NOPUSH=false in /var/yp/Makefile and the names of the worker servers in /var/yp/ypservers, the command also pushes the updated maps to the worker servers.

9. On each NIS worker server, run the following command to initialize the server:

   # /usr/lib64/yp/ypinit -s nisprimary

   In the previous command, nisprimary is the host name or IP address of the NIS primary server.

   For more information, see the ypinit(8) manual page.

# make -C /var/yp

To create an account for an NIS user on the NIS primary server:

1. If the NIS primary server does not already export the base directory of the users' home directories, perform the following steps on the NIS primary 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

   4. If you have configured /var/yp/Makfile to make the auto.home map available to NIS clients, create the following entry in /etc/auto.home:

      *    -rw,sync    nissvr:/nethome/&

      In the previous example, nissvr is the host name or IP address of the NIS server.

2. Create the user account:

   # useradd -b /nethome username

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

3. Depending on the type of authentication that you have configured:

   • For Kerberos authentication, on the Kerberos server or a client system with kadmin access, use kadmin to create a principal for the user in the Kerberos domain, for example:

     # kadmin -q "addprinc username@KRBDOMAIN"

     The command prompts you to set a password for the user, and adds the principal to the Kerberos database.

   • For NIS authentication, use the passwd command:

     # passwd username

     The command updates the /etc/shadow file with the hashed password.

4. Update the NIS maps:

   # make -C /var/yp

   This command makes the NIS maps that are defined for the all target in /var/yp/Makefile. If you have configured NOPUSH=false in /var/yp/Makefile and the names of the worker servers in /var/yp/ypservers, the command also pushes the updated maps to the worker servers.

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

1. Install the yp-tools and ypbind packages:

   # yum install yp-tools ypbind

2. Run the Authentication Configuration GUI:

   # system-config-authentication

3. Select NIS as the user account database and enter values for:

   NIS Domain

   The name of the NIS domain. For example: mynisdom.

   NIS Server

   The domain name or IP address of the NIS server. For example, nissvr.mydom.com.

4. Select either Kerberos password or NIS password for authentication.

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

6. Click Apply to save your changes.

   Attention:

   NIS authentication is deprecated as it has security issues, including a lack of protection of authentication data.

Figure 1-4 Authentication Configuration of NIS with Kerberos Authentication

You can also enable and configure NIS or Kerberos authentication by using the authconfig command.

For example, to use NIS authentication, specify the --enablenis option together with the NIS domain name and the host name or IP address of the primary server, as shown in the following example:.

# authconfig --enablenis --nisdomain mynisdom \
  --nisserver nissvr.mydom.com --update

The --enablenis option configures /etc/nsswitch.conf to enable the system to use NIS for information services. The --nisdomain and --nisserver settings are added to /etc/yp.conf.

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

For information about using Kerberos authentication with NIS, see Enabling Kerberos Authentication.

If you want to configure any client systems to use Kerberos authentication, it is recommended that you first configure a Kerberos server. You can then configure any clients that you require.

To configure a Kerberos server that can act as a key distribution center (KDC) and a Kerberos administration server:

1. Configure the server to use DNS and that both direct and reverse name lookups of the server's domain name and IP address work.

   For more information about configuring DNS, see Name Service Configuration in Oracle Linux 7: Setting Up Networking.

2. Configure the server to use network time synchronization mechanism such as the Network Time Protocol (NTP), Precision Time Protocol (PTP), or chrony. Kerberos requires that the system time on Kerberos servers and clients are synchronized as closely as possible. If the system times of the server and a client differ by more than 300 seconds (by default), authentication fails.

   For more information, see Network Time Configuration in Oracle Linux 7: Setting Up Networking

3. Install the krb5-libs, krb5-server, and krb5-workstation packages:

   # yum install krb5-libs krb5-server krb5-workstation

4. Edit /etc/krb5.conf and configure settings for the Kerberos realm, for example:

   [logging]
    default = FILE:/var/log/krb5libs.log
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmind.log
   
   [libdefaults]
    default_realm = MYDOM.COM
    dns_lookup_realm = false
    dns_lookup_kdc = false
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = true
   
   [realms]
    MYDOM.COM = {
     kdc = krbsvr.mydom.com
     admin_server = krbsvr.mydom.com
    }
   
   [domain_realm]
    .mydom.com = MYDOM.COM mydom.com = MYDOM.COM
   
   [appdefaults]
    pam = {
      debug = true
      validate = false
    }

   In this example, the Kerberos realm is MYDOM.COM in the DNS domain mydom.com and krbsvr.mydom.com (the local system) acts as both a KDC and an administration server. The [appdefaults] section configures options for the pam_krb5.so module.

   For more information, see the krb5.conf(5) and pam_krb5(5) manual pages.

5. Edit /var/kerberos/krb5kdc/kdc.conf and configure settings for the key distribution center, for example:

   kdcdefaults]
    kdc_ports = 88
    kdc_tcp_ports = 88
   
   [realms]
    MYDOM.COM = {
     #master_key_type = aes256-cts
     master_key_type = des-hmac-sha1
     default_principal_flags = +preauth
     acl_file = /var/kerberos/krb5kdc/kadm5.acl
     dict_file = /usr/share/dict/words
     admin_keytab = /etc/kadm5.keytab
     supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal \
     arcfour-hmac:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
    }

   For more information, see the kdc.conf(5) manual page.

6. Create the Kerberos database and store the database password in a stash file:

   # /usr/sbin/kdb5_util create -s

7. Edit /var/kerberos/krb5kdc/kadm5.acl and define the principals who have administrative access to the Kerberos database, for example:

   */admin@EXAMPLE.COM     *

   In this example, any principal who has an instance of admin, such as alice/admin@MYDOM.COM, has full administrative control of the Kerberos database for the MYDOM.COM domain. Ordinary users in the database usually have an empty instance, for example bob@MYDOM.COM. These users have no administrative control other than being able to change their password, which is stored in the database.

8. Create a principal for each user who should have the admin instance, for example:

   # kadmin.local -q "addprinc alice/admin"

9. Cache the keys that kadmind uses to decrypt administration Kerberos tickets in /etc/kadm5.keytab:

   # kadmin.local -q "ktadd -k /etc/kadm5.keytab kadmin/admin"
   # kadmin.local -q "ktadd -k /etc/kadm5.keytab kadmin/changepw"

10. Start the KDC and administration services and configure them to start following system reboots:

    # systemctl start krb5kdc
    # systemctl start kadmin
    # systemctl enable krb5kdc
    # systemctl enable kadmin

11. Add principals for users and the Kerberos server and cache the key for the server's host principal in /etc/kadm5.keytab by using either kadmin.local or kadmin, for example:

    # kadmin.local -q "addprinc bob"
    # kadmin.local -q "addprinc -randkey host/krbsvr.mydom.com"
    # kadmin.local -q "ktadd -k /etc/kadm5.keytab host/krbsvr.mydom.com"

12. Allow incoming TCP connections to ports 88, 464, and 749 and UDP datagrams on UDP port 88, 464, and 749:

    # firewall-cmd --zone=zone --add-port=88/tcp --add-port=88/udp \
      --add-port=464/tcp --add-port=464/udp \
      --add-port=749/tcp --add-port=749/udp
    # firewall-cmd --permanent --zone=zone --add-port=88/tcp --add-port=88/udp \
      --add-port=464/tcp --add-port=464/udp \
      --add-port=749/tcp --add-port=749/udp

    krb5kdc services requests on TCP port 88 and UDP port 88, and kadmind services requests on TCP ports 464 and 749 and UDP ports 464 and 749.

    In addition, you might need to allow TCP and UDP access on different ports for other applications.

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

Setting up a Kerberos client on a system allows it to use Kerberos to authenticate users who are defined in NIS or LDAP, and to provide secure remote access by using commands such as ssh with GSS-API enabled or the Kerberos implementation of telnet.

To set up a system as a Kerberos client:

1. Configure the client system to use DNS and that both direct and reverse name lookups of the domain name and IP address for both the client and the Kerberos server work.

   For more information about configuring DNS, see Name Service Configuration in Oracle Linux 7: Setting Up Networking

2. Configure the system to use a network time synchronization protocol such as the Network Time Protocol (NTP). Kerberos requires that the system time on Kerberos servers and clients are synchronized as closely as possible. If the system times of the server and a client differ by more than 300 seconds (by default), authentication fails.

   To configure the server as an NTP client:

   1. Install the ntp package:

      # yum install ntp
      

   2. Edit /etc/ntp.conf and configure the settings as required. See the ntp.conf(5) manual page and http://www.ntp.org.

   3. Start the ntpd service and configure it to start following system reboots.

      # systemctl start ntpd
      # systemctl enable ntpd
      

3. Install the krb5-libs and krb5-workstation packages:

   # yum install krb5-libs krb5-workstation
   

4. Copy the /etc/krb5.conf file to the system from the Kerberos server.

5. Use the Authentication Configuration GUI or authconfig to set up the system to use Kerberos with either NIS or LDAP, for example:

   # authconfig --enablenis --enablekrb5 --krb5realm=MYDOM.COM \
     --krb5adminserver=krbsvr.mydom.com --krb5kdc=krbsvr.mydom.com \
     --update
   

   See Enabling Kerberos Authentication.

6. On the Kerberos KDC, use either kadmin or kadmin.local to add a host principal for the client, for example:

   # kadmin.local -q "addprinc -randkey host/client.mydom.com"
   

7. On the client system, use kadmin to cache the key for its host principal in /etc/kadm5.keytab, for example:

   # kadmin -q "ktadd -k /etc/kadm5.keytab host/client.mydom.com"
   

8. To use ssh and related OpenSSH commands to connect from Kerberos client system to another Kerberos client system:

   1. On the remote Kerberos client system, verify that GSSAPIAuthentication is enabled in /etc/ssh/sshd_config:

      GSSAPIAuthentication yes

   2. On the local Kerberos client system, enable GSSAPIAuthentication and GSSAPIDelegateCredentials in the user's .ssh/config file:

      GSSAPIAuthentication yes
      GSSAPIDelegateCredentials yes

      Alternatively, the user can specify the -K option to ssh.

   3. Test that the principal can obtain a ticket and connect to the remote system, for example:

      $ kinit principal_name@MYDOM.COM
                                       
      $ ssh username@remote.mydom.com
                                       
      

   To allow use of the Kerberos versions of rlogin, rsh, and telnet, which are provided in the krb5-appl-clients package, you must enable the corresponding services on the remote client.

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

To be able to use Kerberos authentication with an LDAP or NIS client, use yum to install the krb5-libs and krb5-workstation packages.

If you use the Authentication Configuration GUI (system-config-authentication) and select LDAP or NIS as the user account database, select Kerberos password as the authentication method and 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

Figure 1-6 Authentication Configuration of LDAP with Kerberos Authentication

Alternatively, you can use the authconfig command to configure Kerberos authentication with LDAP, for example:

# authconfig --enableldap \
  --ldapbasedn="dc=mydom,dc=com" --ldapserver=ldap://ldap.mydom.com:389 \
  [--enableldaptls --ldaploadcacert=https://ca-server.mydom.com/CAcert.pem] \
  --enablekrb5  \
  --krb5realm=MYDOM.COM | --enablekrb5realmdns \
  --krb5kdc=krbsvr.mydom.com --krb5adminserver=krbsvr.mydom.com | --enablekrb5kdcdns \
  --update

or with NIS:

# authconfig --enablenis \
  --enablekrb5 \
  --krb5realm=MYDOM.COM | --enablekrb5realmdns \
  --krb5kdc=krbsvr.mydom.com --krb5adminserver=krbsvr.mydom.com | --enablekrb5kdcdns \
  --update

The --enablekrb5 option enables Kerberos authentication by modifying the PAM configuration files in /etc/pam.d to use the pam_krb5.so module. The --enableldap and --enablenis options configure /etc/nsswitch.conf to enable the system to use LDAP or NIS for information services.

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

To configure an SSSD server:

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 = LDAP
   services = nss, pam
   
   [domain/LDAP]
   id_provider = ldap
   ldap_uri = ldap://ldap.mydom.com
   ldap_search_base = dc=mydom,dc=com
   
   auth_provider = krb5
   krb5_server = krbsvr.mydom.com
   krb5_realm = 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

   The [sssd] section contains configuration settings for SSSD monitor options, domains, and services. The SSSD monitor service manages the services that SSSD provides.

   The services entry defines the supported services, which should include nss for the Name Service Switch and pam for Pluggable Authentication Modules.

   The domains entry specifies the name of the sections that define authentication domains.

   The [domain/LDAP] section defines a domain for an LDAP identity provider that uses Kerberos authentication. Each domain defines where user information is stored, the authentication method, and any configuration options. SSSD can work with LDAP identity providers such as OpenLDAP, Red Hat Directory Server, IPA, and Microsoft Active Directory, and it can use either native LDAP or Kerberos authentication.

   The id_provider entry specifies the type of provider (in this example, LDAP). ldap_uri specifies a comma-separated list of the Universal Resource Identifiers (URIs) of the LDAP servers, in order of preference, to which SSSD can connect. ldap_search_base specifies the base distinguished name (dn) that SSSD should use when performing LDAP user operations on a relative distinguished name (RDN) such as a common name (cn).

   The auth_provider entry specifies the authentication provider (in this example, Kerberos). krb5_server specifies a comma-separated list of Kerberos servers, in order of preference, to which SSSD can connect. krb5_realm specifies the Kerberos realm. cache_credentials specifies if SSSD caches user credentials such as tickets, session keys, and other identifying information to support offline authentication and single sign-on.

   Note:

   To allow SSSD to use Kerberos authentication with an LDAP server, you must configure the LDAP server to use both Simple Authentication and Security Layer (SASL) and the Generic Security Services API (GSSAPI). For more information about configuring SASL and GSSAPI for OpenLDAP, see https://www.openldap.org/doc/admin24/sasl.html.

   The min_id and max_id entries specify upper and lower limits on the values of user and group IDs. enumerate specifies whether SSSD caches the complete list of users and groups that are available on the provider. The recommended setting is False unless a domain contains relatively few users or groups.

   The [nss] section configures the Name Service Switch (NSS) module that integrates the SSS database with NSS. The filter_users and filter_groups entries prevent NSS retrieving information about the specified users and groups being retrieved from SSS. reconnection_retries specifies the number of times that SSSD should attempt to reconnect if a data provider crashes. enum_cache_timeout specifies the number of seconds for which SSSD caches user information requests.

   The [pam] section configures the PAM module that integrates SSS with PAM. The offline_credentials_expiration entry specifies the number of days for which to allow cached logins if the authentication provider is offline. offline_failed_login_attempts specifies how many failed login attempts are allowed if the authentication provider is offline. offline_failed_login_delay specifies how many minutes after offline_failed_login_attempts failed login attempts that a new login attempt is permitted.

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

   Note:

   If you edit /etc/sssd/sssd.conf, use this command to update the service.

   The --enablesssd option updates /etc/nsswitch.conf to support SSS.

   The --enablesssdauth option updates /etc/pam.d/system-auth to include the required pam_sss.so entries to support SSSD.

Depending on the security model that you choose, you might also need to specify the following information:

Your selection updates the security directive in the [global] section of the /etc/samba/smb.conf configuration file.

If you have initialized Kerberos, you can click Join Domain to create a machine account on the Active Directory server and grant permission for the Samba domain member server to join the domain.

# authconfig --enablewinbind --enablewinbindauth --smbsecurity user \
  [--enablewinbindoffline] --smbservers="ad1.mydomain.com ad2.mydomain.com" \
  --smbworkgroup=MYDOMAIN --update

To allow user authentication using information that has been cached by the System Security Services Daemon (SSSD) if the domain controllers are offline, specify the --enablewinbindoffline option.

For the domain security model, additionally specify the template shell, for example:

# authconfig --enablewinbind --enablewinbindauth --smbsecurity domain \
  [--enablewinbindoffline] --smbservers="ad1.mydomain.com ad2.mydomain.com" \
  --smbworkgroup=MYDOMAIN --update --winbindtemplateshell=/bin/bash --update

For the ADS security model, additionally specify the ADS realm and template shell, for example:

# authconfig --enablewinbind --enablewinbindauth --smbsecurity ads \
  [--enablewinbindoffline] --smbservers="ad1.mydomain.com ad2.mydomain.com" \
  --smbworkgroup=MYDOMAIN --update --smbrealm MYDOMAIN.COM \
  --winbindtemplateshell=/bin/bash --update

For more information, see the authconfig(8) manual page.