| Identity Management GuideChapter 19. Configuration: Configuring the IdM ServerThe IdM servers and backend services are configured with default settings that are applicable in most environments. There are some configuration areas where the IdM server configuration can be tweaked to improve security or performance in certain situations. This chapter covers information about the IdM configuration, including files and logs used by the IdM server, and procedures for updating the IdM server configuration itself. 19.1. Identity Management Files and LogsIdentity Management is a unifying framework that combines disparate Linux services into a single management context. However, the underlying technologies - such as Kerberos, DNS, 389 Directory Server, and Dogtag Certificate System - retain their own configuration files and log files. Identity Management directly manages each of these elements through their own configuration files and tools. This section covers the directories, files, and logs used specifically by IdM. For more information about the configuration files or logs for a specific server used within IdM, see the product documentation. 19.1.1. A Reference of IdM Server Configuration Files and DirectoriesTable 19.1. IdM Server Configuration Files and Directories | Directory or File | Description |
|---|
| Server Configuration | | /etc/ipa | The main IdM configuration directory. | | /etc/ipa/default.conf | The primary configuration file for IdM. | | /etc/ipa/ca.crt | The CA certificate issued by the IdM server's CA. | | ~/.ipa/ | A user-specific IdM directory that is created on the local system in the system user's home directory the first time the user runs an IdM command. | | IdM Logs | | ~/.ipa/log/cli.log | The log file for all XML-RPC calls and responses by the IdM command-line tools. This is created in the home directory for the system user who runs the tools, who may have a different name than the IdM user. | | /var/log/ipaclient-install.log | The installation log for the client service. | | /var/log/ipaserver-install.log | The installation log for the IdM server. | | System Services | | /etc/rc.d/init.d/ipa | The IdM server init script. | | Web UI | | /etc/ipa/html | A symlink directory in the main configuration directory for the HTML files used by the IdM web UI. | | /etc/httpd/conf.d/ipa.conf | | /etc/httpd/conf.d/ipa-rewrite.conf |
| The configuration files used by the Apache host for the web UI application. | | /etc/httpd/conf/ipa.keytab | The keytab file used by the web UI service. | | /usr/share/ipa | The main directory for all of the HTML files, scripts, and stylesheets used by the web UI. | | /usr/share/ipa/ipa-rewrite.conf | | /usr/share/ipa/ipa.conf |
| The configuration files used by the Apache host for the web UI application. | | /usr/share/ipa/updates | Contains any updated files, schema, and other elements for Identity Management. | | /usr/share/ipa/html | Contains the HTML files, JavaScript files, and stylesheets used by the web UI. | | /usr/share/ipa/ipaclient | Contains the JavaScript files used to access Firefox's autoconfiguration feature and set up the Firefox browser to work in the IdM Kerberos realm. | | /usr/share/ipa/migration | Contains HTML pages, stylesheets, and Python scripts used for running the IdM server in migration mode. | | /usr/share/ipa/ui | Contains all of the scripts used by the UI to perform IdM operations. | | /var/log/httpd | The log files for the Apache web server. | | Kerberos | | /etc/krb5.conf | The Kerberos service configuration file. | | SSSD | | /etc/sssd/sssd.api.d/sssd-ipa.conf | The configuration file used to identify the IdM server, IdM Directory Server, and other IdM services used by SSSD. | | /var/log/sssd | The log files for SSSD. | | 389 Directory Server | | /var/lib/dirsrv/slapd-REALM_NAME | All of the schema, configuration, and database files associated with the Directory Server instance used by the IdM server. | | /var/log/dirsrv/slapd-REALM_NAME | Log files associated with the Directory Server instance used by the IdM server. | | Dogtag Certificate System | | /etc/pki-ca | The main directory for the IdM CA instance. | | /etc/pki-ca/conf/CS.cfg | The main configuration file for the IdM CA instance. | | /var/lib/dirsrv/slapd-PKI-IPA/ | All of the schema, configuration, and database files associated with the Directory Server instance used by the IdM CA. | | /var/log/dirsrv/slapd-PKI-IPA/ | Log files associated with the Directory Server instance used by the IdM CA. | | Cache Files | | /var/cache/ipa | Cache files for the IdM server and the IdM Kerberos password daemon. | | System Backups | | /var/lib/ipa/sysrestore | Contains backups of all of the system files and scripts that were reconfigured when the IdM server was installed. These include the original .conf files for NSS, Kerberos (both krb5.conf and kdc.conf), and NTP. | | /var/lib/ipa-client/sysrestore | Contains backups of all of the system files and scripts that were reconfigured when the IdM client was installed. Commonly, this is the sssd.conf file for SSSD authentication services. |
19.1.2. About default.conf and Context Configuration FilesCertain global defaults - like the realm information, the LDAP configuration, and the CA settings - are stored in the default.conf file. This configuration file is referenced when the IdM client and servers start and every time the ipa command is run to supply information as operations are performed. The parameters in the default.conf file are simple attribute=value pairs. The attributes are case-insensitive and order-insensitive. [global]basedn=dc=example,dc=comrealm=EXAMPLE.COMdomain=example.comxmlrpc_uri=https://server.example.com/ipa/xmlldap_uri=ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socketenable_ra=Truera_plugin=dogtagmode=production When adding more configuration attributes or overriding the global values, users can create additional context configuration files. A server.conf and cli.conf file can be created to create different options when the IdM server is started or when the ipa command is run, respectively. The IdM server checks the server.conf and cli.conf files first, and then checks the default.conf file. Any configuration files in the /etc/ipa directory apply to all users for the system. Users can set individual overrides by creating default.conf, server.conf, or cli.conf files in their local IdM directory, ~/.ipa/. This optional file is merged with default.conf and used by the local IdM services. 19.1.3. Checking IdM Server LogsIdentity Management unifies several different Linux services, so it relies on those services' native logs for tracking and debugging those services. The other services (Apache, 389 Directory Server, and Dogtag Certificate System) all have detailed logs and log levels. See the specific server documentation for more information on return codes, log formats, and log levels. Table 19.2. IdM Log Files | Service | Log File | Description | Additional Information |
|---|
| IdM server | /var/log/ipaserver-install.log | Server installation log | | | IdM server | ~/.ipa/log/cli.log | Command-line tool log | | | IdM client | /var/log/ipaclient-install.log | Client installation log | | | Apache server | | /var/log/httpd/access | | /var/log/httpd/error |
| These are standard access and error logs for Apache servers. Both the web UI and the XML-RPC command-line interface use Apache, so some IdM-specific messages will be recorded in the error log along with the Apache messages. | Apache log chapter | | Dogtag Certificate System | /var/log/pki-ca-install.log | The installation log for the IdM CA. | | | Dogtag Certificate System | | /var/log/pki-ca/debug | | /var/log/pki-ca/system | | /var/log/pki-ca/transactions | | /var/log/pki-ca/signedAudit |
| These logs mainly relate to certificate operations. In IdM, this is used for service principals, hosts, and other entities which use certificates. | Logging chapter | | 389 Directory Server | | /var/log/dirsrv/slapd-REALM/access | | /var/log/dirsrv/slapd-REALM/audit | | /var/log/dirsrv/slapd-REALM/errors |
| The access and error logs both contain detailed information about attempted access and operations for the domain Directory Server instance. The error log setting can be changed to provide very detailed output. | The access log is buffered, so the server only writes to the log every 30 seconds, by default. | | 389 Directory Server | | /var/log/dirsrv/slapd-REALM/access | | /var/log/dirsrv/slapd-REALM/audit | | /var/log/dirsrv/slapd-REALM/errors |
| This directory server instance is used by the IdM CA to store certificate information. Most operational data here will be related to server-replica interactions. | The access log is buffered, so the server only writes to the log every 30 seconds, by default. | | Kerberos | /var/log/krb5libs.log | This is the primary log file for Kerberos connections. | This location is configured in the krb5.conf file, so it could be different on some systems. | | Kerberos | /var/log/krb5kdc.log | This is the primary log file for the Kerberos KDC server. | This location is configured in the krb5.conf file, so it could be different on some systems. | | Kerberos | /var/log/kadmind.log | This is the primary log file for the Kerberos administration server. | This location is configured in the krb5.conf file, so it could be different on some systems. | | DNS | /var/log/messages | DNS error messages are included with other system messages. | DNS logging is not enabled by default. DNS logging is enabled by running the querylog command: /usr/sbin/rndc querylog This begins writing log messages to the system's /var/log/messages file. To turn off logging, run the querylog command again. |
19.1.3.1. Enabling Server Debug LoggingDebug logging for the IdM server is set in the server.conf file. Editing the defaults.conf configuration file affects all IdM components, not only the IdM server. Edit or create the server.conf file. vim server.conf Add the debug line and set its value to true. [global]debug=True Restart the Apache daemon to load the changes. service httpd restart
19.1.3.2. Debugging Command-Line OperationsAny command-line operation with the ipa command can return debug information by using the -v option. For example: $ ipa -v user-show adminipa: INFO: trying https://ipaserver.example.com/ipa/xmlFirst name: JohnLast name: SmytheUser login [jsmythe]:ipa: INFO: Forwarding 'user_add' to server u'https://ipaserver.example.com/ipa/xml'--------------------Added user "jsmythe"-------------------- User login: jsmythe First name: John Last name: Smythe Full name: John Smythe Display name: John Smythe Initials: JS Home directory: /home/jsmythe GECOS field: John Smythe Login shell: /bin/sh Kerberos principal: [email protected] UID: 1966800003 GID: 1966800003 Keytab: False Password: False Using the option twice, -vv, displays the XML-RPC exchange: $ ipa -vv user-add ipa: INFO: trying https://ipaserver.example.com/ipa/xmlFirst name: JaneLast name: RussellUser login [jrussell]:ipa: INFO: Forwarding 'user_add' to server u'https://ipaserver.example.com/ipa/xml'send: u'POST /ipa/xml HTTP/1.0\r\nHost: ipaserver.example.com\r\nAccept-Language: en-us\r\nAuthorization: negotiate YIIFgQYJKoZIhvcSAQICAQBuggVwMIIFbKADAgEFoQMCAQ6iBwMFACAAAACjggGHYYIBgzCCAX+gAwIBBaEZGxdSSFRTLkVORy5CT1MuUkVESEFULkNPTaI5MDegAwIBA6EwMC4bBEhUVFAbJmRlbGwtcGUxODUwLTAxLnJodHMuZW5nLmJvcy5yZWRoYXQuY29to4IBIDCCARygAwIBEqEDAgECooIBDgSCAQpV2YEWv03X+SENdUBfOhMFGc3Fvnd51nELV0rIB1tfGVjpNlkuQxXKSfFKVD3vyAUqkii255T0mnXyTwayE93W1U4sOshetmG50zeU4KDmhuupzQZSCb5xB0KPU4HMDvP1UnDFJUGCk9tcqDJiYE+lJrEcz8H+Vxvvl+nP6yIdUQKqoEuNhJaLWIiT8ieAzk8zvmDlDzpFYtInGWe9D5ko1Bb7Npu0SEpdVJB2gnB5vszCIdLlzHM4JUqX8p21AZV0UYA6QZOWX9OXhqHdElKcuHCN2s9FBRoFYK83gf1voS7xSFlzZaFsEGHNmdA0qXbzREKGqUr8fmWmNvBGpDiR2ILQep09lL56JqSCA8owggPGoAMCARKiggO9BIIDuarbB67zjmBu9Ax2K+0klSD99pNv97h9yxol8c6NGLB4CmE8Mo39rL4MMXHeOS0OCbn+TD97XVGLu+cgkfVcuIG4PMMBoajuSnPmIf7qDvfa8IYDFlDDnRB7I//IXtCc/Z4rBbaxk0SMIRLrsKf5wha7aWtN1JbizBMQw+J0UlN8JjsWxu0Ls75hBtIDbPf3fva3vwBf7kTBChBsheewSAlck9qUglyNxAODgFVvRrXbfkw51Uo++9qHnhh+zFSWepfv7US7RYK0KxOKFd+uauY1ES+xlnMvK18ap2pcy0odBkKu1kwJDND0JXUdSY08MxK2zb/UGWrVEf6GIsBgu122UGiHp6C+0fEu+nRrvtORY65Bgi8E1vm55fbb/9dQWNcQheL9m6QJWPw0rgc+E5SO99ON6x3Vv2+Zk17EmbZXinPd2tDe7fJ9cS9o/z7Qjw8z8vvSzHL4GX7FKi2HJdBST3nEgOC8PqO46UnAJcA8pf1ZkwCK9xDWH+5PSph6WnvpRqugqf/6cq+3jk3MEjCrx+JBJ8QL6AgN3oEB4kvjZpAC+FfTkdX59VLDwfL/r0gMw3ZNk0nLLCLkiiYUMTEHZBzJw9kFbsX3LmS8qQQA6rQ2L782DYisElywfZ/0Sax8JO/G62Zvy7BHy7SQSGIvcdAOafeNyfxaWM1vTpvSh0GrnllYfs3FhZAKnVcLYrlPTapR23uLgRMv+0c9wAbwuUDfKgOOl5vAd1j55VUyapgDEzi/URsLdVdcF4zigt4KrTByCwU2/pI6FmEPqB2tsjM2A8JmqA+9Nt8bjaNdNwCOWE0dF50zeL9P8oodWGkbRZLk4DLIurpCW1d6IyTBhPQ5qZqHJWeoGiFa5y94zBpp27goMPmE0BskXT0JQmveYflOeKEMSzyiWPL2mwi7KEMtfgCpwTIGP2LRE/QxNvPGkwFfO+PDjZGVw+APKkMKqclVXxhtJA/2NmBrO1pZIIJ9R+41sR/QoACcXIUXJnhrTwwR1viKCB5Tec87gN+e0Cf0g+fmZuXNRscwJfhYQJYwJqdYzGtZW+h8jDWqa2EPcDwIQwyFAgXNQ/aMvh1yNTECpLEgrMhYmFAUDLQzI2BDnfbDftIs0rXjSC0oZn/Uaoqdr4F5syOrYAxH47bS6MW8CxyylreH8nT2qQXjenakLFHcNjt4M1nOc/igzNSeZ28qW9WSr4bCdkH+ra3BVpT/AF0WHWkxGF4vWr/iNHCjq8fLF+DsAEx0Zs696Rg0fWZy079A\r\nUser-Agent: xmlrpclib.py/1.0.1 (by www.pythonware.com)\r\nContent-Type: text/xml\r\nContent-Length: 1240\r\n\r\n'send: "<?xml version='1.0' encoding='UTF-8'?>\n<methodCall>\n<methodName>user_add</methodName>\n<params>\n<param>\n<value><array><data>\n<value><string>jrussell</string></value>\n</data></array></value>\n</param>\n<param>\n<value><struct>\n<member>\n<name>all</name>\n<value><boolean>0</boolean></value>\n</member>\n<member>\n<name>displayname</name>\n<value><string>Jane Russell</string></value>\n</member>\n<member>\n<name>cn</name>\n<value><string>Jane Russell</string></value>\n</member>\n<member>\n<name>noprivate</name>\n<value><boolean>0</boolean></value>\n</member>\n<member>\n<name>uidnumber</name>\n<value><int>999</int></value>\n</member>\n<member>\n<name>raw</name>\n<value><boolean>0</boolean></value>\n</member>\n<member>\n<name>version</name>\n<value><string>2.11</string></value>\n</member>\n<member>\n<name>gecos</name>\n<value><string>Jane Russell</string></value>\n</member>\n<member>\n<name>sn</name>\n<value><string>Russell</string></value>\n</member>\n<member>\n<name>krbprincipalname</name>\n<value><string>[email protected]</string></value>\n</member>\n<member>\n<name>givenname</name>\n<value><string>Jane</string></value>\n</member>\n<member>\n<name>initials</name>\n<value><string>JR</string></value>\n</member>\n</struct></value>\n</param>\n</params>\n</methodCall>\n"reply: 'HTTP/1.1 200 OK\r\n'header: Date: Thu, 15 Sep 2011 00:50:39 GMTheader: Server: Apache/2.2.15 (Red Hat)header: WWW-Authenticate: Negotiate YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKicQRvVl5x6Zt9PbWNzvPEWkdu+3PTCq/ZVKjGHM+1zDBz81GL/f+/Pr75zTuveLYn9de0C3k27vz96fn2HQsy9qVH7sfqn0RWGQWzl+kDkuD6bJ/Dp/mpJvicW5gSkCSH6/UCNuE4I0xqwabLIz8MM/5oheader: Connection: closeheader: Content-Type: text/xml; charset=utf-8body: "<?xml version='1.0' encoding='UTF-8'?>\n<methodResponse>\n<params>\n<param>\n<value><struct>\n<member>\n<name>result</name>\n<value><struct>\n<member>\n<name>dn</name>\n<value><string>uid=jrussell,cn=users,cn=accounts,dc=example,dc=com</string></value>\n</member>\n<member>\n<name>has_keytab</name>\n<value><boolean>0</boolean></value>\n</member>\n<member>\n<name>displayname</name>\n<value><array><data>\n<value><string>Jane Russell</string></value>\n</data></array></value>\n</member>\n<member>\n<name>uid</name>\n<value><array><data>\n<value><string>jrussell</string></value>\n</data></array></value>\n</member>\n<member>\n<name>objectclass</name>\n<value><array><data>\n<value><string>top</string></value>\n<value><string>person</string></value>\n<value><string>organizationalperson</string></value>\n<value><string>inetorgperson</string></value>\n<value><string>inetuser</string></value>\n<value><string>posixaccount</string></value>\n<value><string>krbprincipalaux</string></value>\n<value><string>krbticketpolicyaux</string></value>\n<"body: 'value><string>ipaobject</string></value>\n</data></array></value>\n</member>\n<member>\n<name>loginshell</name>\n<value><array><data>\n<value><string>/bin/sh</string></value>\n</data></array></value>\n</member>\n<member>\n<name>uidnumber</name>\n<value><array><data>\n<value><string>1966800004</string></value>\n</data></array></value>\n</member>\n<member>\n<name>initials</name>\n<value><array><data>\n<value><string>JR</string></value>\n</data></array></value>\n</member>\n<member>\n<name>gidnumber</name>\n<value><array><data>\n<value><string>1966800004</string></value>\n</data></array></value>\n</member>\n<member>\n<name>gecos</name>\n<value><array><data>\n<value><string>Jane Russell</string></value>\n</data></array></value>\n</member>\n<member>\n<name>sn</name>\n<value><array><data>\n<value><string>Russell</string></value>\n</data></array></value>\n</member>\n<member>\n<name>homedirectory</name>\n<value><array><data>\n<value><string>/home/jrussell</string></value>\n</data></array></value>\n</member>\n<member>\n<name>has_password</name>\n<value><boolean>0</'body: 'boolean></value>\n</member>\n<member>\n<name>krbprincipalname</name>\n<value><array><data>\n<value><string>[email protected]</string></value>\n</data></array></value>\n</member>\n<member>\n<name>givenname</name>\n<value><array><data>\n<value><string>Jane</string></value>\n</data></array></value>\n</member>\n<member>\n<name>cn</name>\n<value><array><data>\n<value><string>Jane Russell</string></value>\n</data></array></value>\n</member>\n<member>\n<name>ipauniqueid</name>\n<value><array><data>\n<value><string>bba27e6e-df34-11e0-a5f4-001143d2c060</string></value>\n</data></array></value>\n</member>\n</struct></value>\n</member>\n<member>\n<name>value</name>\n<value><string>jrussell</string></value>\n</member>\n<member>\n<name>summary</name>\n<value><string>Added user "jrussell"</string></value>\n</member>\n</struct></value>\n</param>\n</params>\n</methodResponse>\n'---------------------Added user "jrussell"--------------------- User login: jrussell First name: Jane Last name: Russell Full name: Jane Russell Display name: Jane Russell Initials: JR Home directory: /home/jrussell GECOS field: Jane Russell Login shell: /bin/sh Kerberos principal: [email protected] UID: 1966800004 GID: 1966800004 Keytab: False Password: False The -v and -vv options are global options and must be used before the subcommand when running ipa. 19.2. Disabling Anonymous BindsAccessing domain resources and running client tools always require Kerberos authentication. However, the backend LDAP directory used by the IdM server allows anonymous binds by default. This potentially opens up all of the domain configuration to unauthorized users, including information about users, machines, groups, services, netgroups, and DNS configuration. It is possible to disable anonymous binds on the 389 Directory Server instance by using LDAP tools to reset the nsslapd-allow-anonymous-access attribute. Change the nsslapd-allow-anonymous-access attribute to rootdse. ldapmodify -x -D "cn=Directory Manager" -w secret -h server.example.com -p 389Enter LDAP Password:dn: cn=configchangetype: modifyreplace: nsslapd-allow-anonymous-accessnsslapd-allow-anonymous-access: rootdse Anonymous access can be completely allowed (on) or completely blocked (off). However, completely blocking anonymous access also blocks external clients from checking the server configuration. LDAP and web clients are not necessarily domain clients, so they connect anonymously to read the root DSE file to get connection information. The rootdse allows access to the root DSE and server configuration without any access to the directory data. Restart the 389 Directory Server instance to load the new setting. service dirsrv restart
19.3. Configuring Alternate Certificate AuthoritiesIdM creates a Dogtag Certificate System certificate authority (CA) during the server installation process. To use an external CA, it is possible to create the required server certificates and then import them into the 389 Directory Server and the HTTP server, which require IdM server certificates. Save an ASCII copy of the CA certificate as /usr/share/ipa/html/ca.crt. This allows users to download the correct certificate when they configure their browsers. Use the ipa-server-certinstall command to install the certificate. # /usr/sbin/ipa-server-certinstall -d /path/to/pkcs12.p12 To keep using browser autoconfiguration in Firefox, regenerate the /usr/share/ipa/html/configure.jar file. Create a directory, and then create the new security databases in that directory. # mkdir /tmp/signdb# certutil -N -d /tmp/signdb Import the PKCS #12 file for the signing certificate into that directory. # pk12util -i /path/to/pkcs12.p12 -d /tmp/signdb Make a temporary signing directory, and copy the IdM JavaScript file to that directory. # mkdir /tmp/sign# cp /usr/share/ipa/html/preferences.html /tmp/sign Use the object signing certificate to sign the JavaScript file and to regenerate the configure.jar file. # signtool -d /tmp/signdb -k Signing_cert_nickname -Z /usr/share/ipa/html/configure.jar -e .html /tmp/sign
19.4. Configuring CRLs and OCSP RespondersA certificate is created with a validity period, meaning it has a point where it expires and is no longer valid. The expiration date is contained in the certificate itself, so a client always checks the validity period in the certificate to see if the certificate is still valid. However, a certificate can also be revoked before its validity period is up, but this information is not contained in the certificate. A CA publishes a certificate revocation list (CRL), which contains a complete list of every certificate that was issued by that CA and subsequently revoked. A client can check the CRL to see if a certificate within its validity period has been revoked and is, therefore, invalid. Validity checks are performed using the online certificate status protocol (OCSP), which sends a request to an OCSP responder. Each CA integrated with the IdM server uses an internal OCSP responder, and any client which runs a validity check can check the IdM CA's internal OCSP responder. Every certificate issued by the IdM CA puts its OCSP responder service URL in the certificate. For example: http://ipaserver.example.com:9180/ca/ocsp For the IdM OCSP responder to be available, port 9180 needs to be open in the firewall. 19.4.1. Using an OSCP Responder with SELinuxClients can use the Identity Management OCSP responder to check certificate validity or to retrieve CRLs. A client can be a number of different services, but is most frequently an Apache server and the mod_revocator module (which handles CRL and OCSP operations). The Identity Management CA has an OCSP responder listening over port 9180, which is also the port available for CRL retrieval. This port is protected by default SELinux policies to prevent unauthorized access. If an Apache server attempts to connect to the OCSP port, then it may be denied access by SELinux. The Apache server, on the local machine, must be granted access to port 9180 for it to be able to connect to the Identity Management OCSP responder. There are two ways to work around this by changing the SELinux policies: Edit the SELinux policy to allow Apache servers using the mod_revocator module to connect to port 9180: semodule -i revoker.pp Generate a new SELinux policy to allow access based on the SELinux error logs for the mod_revocator connection attempt. audit2allow -a -M revoker
19.4.2. Changing the CRL Update IntervalThe CRL file is automatically generated by the Dogtag Certificate System CA every four hours. This interval can be changed by editing the Dogtag Certificate System configuration. Stop the CA server. service pki-ca stop Open the CS.cfg file. vim /etc/pki-ca/CS.cfg Change the ca.crl.MasterCRL.autoUpdateInterval to the new interval setting. Restart the CA server. service pki-ca start
19.4.3. Changing the OCSP Responder LocationEach IdM server generates its own CRL. Likewise, each IdM server uses its own OCSP responder, with its own OCSP responder URL in the certificates it issues. A DNS CNAME can be used by IdM clients, and then from there be redirected to the appropriate IdM server OCSP responder. Open the certificate profile. vim /var/lib/pki-ca/profiles/ca/caIPAserviceCert.cfg Change the policyset.serverCertSet.9.default.params.crlDistPointsPointName_0 parameter to the DNS CNAME hostname. Restart the CA server. service pki-ca restart
That change must be made on every IdM server, with the crlDistPointsPointName_0 parameter set to the same hostname. 19.5. Setting DNS Entries for Multi-Homed ServersSome server machines may support multiple network interface cards (NICs). Multi-homed machines typically have multiple IPs, all assigned to the same hostname. This works fine in IdM most of the time because it listens on all available interfaces, except localhost. For a server to be available through any NIC, edit the DNS zone file and add entries for each IP address. For example: ipaserver IN A 192.168.1.100ipaserver IN A 192.168.1.101ipaserver IN A 192.168.1.102 19.6. Managing Replication Agreements Between IdM ServersInformation is shared between the IdM servers and replicas using multi-master replication. What this means is that servers and replicas all receive updates and, therefore, are data masters. The domain information is copied between the servers and replicas using replication. As replicas are added to the domain, mutual replication agreements are automatically created between the replica and the server it is based on. Additional replication agreements can be created between other replicas and servers or the configuration of the replication agreement can be changed using the ipa-replica-manage command. When a replica is created, the replica install script creates two replication agreements: one going from the master server to the replica and one going from the replica to the master server. As more replicas and servers are added to the domain, there can be replicas and servers that have replication agreements to other servers and replicas but not between each other. For example, the first IdM server is Server A. Then, the admin creates Replica B, and the install script creates a Server A => Replica B replication agreement and a Replica B => Server A replication agreement. Next, the admin creates Replica C based on Server A. The install script creates a Server A => Replica C replication agreement and a Replica C => Server A replication agreement. Replica B and Replica C both have replication agreements with Server A - but they do not have agreements with each other. For data availability, consistency, failover tolerance, and performance, it can be beneficial to create a pair of replication agreements between Replica B and Replica C, even though their data will eventually be replicated over to each other through replication with Server A. 19.6.1. Listing Replication AgreementsThe ipa-replica-manage command can list all of the servers and replicas in the replication topology, using the list command: # ipa-replica-manage listsrv1.example.comsrv2.example.comsrv3.example.comsrv4.example.com After getting the server/replica list, then it is possible to list the replication agreements for the server. These are the other servers/replicas to which the specified server sends updates. # ipa-replica-manage list srv1.example.comsrv2.example.comsrv3.example.com 19.6.2. Creating and Removing Replication AgreementsReplication agreements are created by connecting one server to another server. ipa-replica-manage server1 server2 If only one server is given, the replication agreements are created between the local host and the specified server. For example: # ipa-replica-manage connect srv2.example.com srv4.example.com Replication occurs over standard LDAP; to enable SSL, then include the CA certificate for the local host (or the specified server1). The CA certificate is then installed in the remote server's certificate database to enable TLS/SSL connections. For example: # ipa-replica-manage connect --cacert=/etc/ipa/ca.crt srv2.example.com srv4.example.com To remove a replication agreement between specific servers/replicas, use the disconnect command: # ipa-replica-manage disconnect srv2.example.com srv4.example.com Using the disconnect command removes that one replication agreement but leaves both the server/replica instances in the overall replication topology. To remove a server entirely from the IdM replication topology, with all its data, (and, functionally, removing it from the IdM domain as a server), use the del server: # ipa-replica-manage del srv2.example.com 19.6.3. Forcing ReplicationReplication between servers and replicas occurs on a schedule. Although replication is frequent, there can be times when it is necessary to initiate the replication operation manually. For example, if a server is being taken offline for maintenance, it is necessary to flush all of the queued replication changes out of its changelog before taking it down. To initiate a replication update manually, use the force-sync command. The server which receives the update is the local server; the server which sends the updates is specified in the --from option. # ipa-replica-manage force-sync --from srv1.example.com 19.6.4. Reinitializing IdM ServersWhen a replica is first created, the database of the master server is copied, completely, over to the replica database. This process is called initialization. If a server/replica is offline for a long period of time or there is some kind of corruption in its database, then the server can be re-initialized, with a fresh and updated set of data. This is done using the re-initialize command. The target server being initialized is the local host. The server or replica from which to pull the data to initialize the local database is specified in the --from option: # ipa-replica-manage re-initialize --from srv1.example.com 19.6.5. Resolving Replication ConflictsChanges - both for IdM domain data and for certificate and key data - are replicated between IdM servers and replicas (and, in similar paths, between IdM and Active Directory servers). Even though replication operations are run continuously, there is a chance that changes can be made on one IdM server at the same time different changes are made to the same entry on a different IdM server. When replication begins to process those entries, the changes collide - this is a replication conflict. Every single directory modify operation is assigned a server-specific change state number (CSN) to track how those modifications are propagated during replication. The CSN also contains a modify timestamp. When there is a replication conflict, the timestamp is checked and the last change wins. Simply accepting the most recent change is effective for resolving conflicts with attribute values. That method is too blunt for some types of operations, however, which affect the directory tree. Some operations, like modrdn, DN changes, or adding or removing parent and child entries, require administrator review before the conflict is resolved. Replication conflicts are resolved by editing the entries directory in the LDAP database. When there is a replication conflict, both entries are added to the directory and are assigned a nsds5ReplConflict attribute. This makes it easy to search for entries with a conflict: ldapsearch -x -D "cn=directory manager" -w password -b "dc=example,dc=com" "nsds5ReplConflict=*" \* nsds5ReplConflict 19.6.5.1. Solving Naming ConflictsWhen two entries are added to the IdM domain with the same DN, both entries are added to the directory, but they are renamed to use the nsuniqueid attribute as a naming attribute. For example: nsuniqueid=0a950601-435311e0-86a2f5bd-3cd26022+uid=jsmith,cn=users,cn=accounts,dc=example,dc=com Those entries can be searched for and displayed in the IdM CLI, but they cannot be edited or deleted until the conflict is resolved and the DN is updated. To resolve the conflict: Rename the entry using a different naming attribute, and keep the old RDN. For example: ldapmodify -x -D "cn=directory manager" -w secret -h ipaserver.example.com -p 389 dn: nsuniqueid=66446001-1dd211b2+uid=jsmith,cn=users,cn=accounts,dc=example,dc=com changetype: modrdn newrdn: cn=TempValue deleteoldrdn: 0 Remove the old RDN value of the naming attribute and the conflict marker attribute. For example: ldapmodify -x -D "cn=directory manager" -w secret -h ipaserver.example.com -p 389 dn: cn=TempValue,cn=users,cn=accounts,dc=example,dc=com changetype: modify delete: uid dc: jsmith - delete: nsds5ReplConflict - The unique identifier attribute nsuniqueid cannot be deleted. Rename the entry with the intended attribute-value pair. For example: ldapmodify -x -D "cn=directory manager" -w secret -h ipaserver.example.com -p 389 dn: cn=TempValue,dc=example,dc=com changetype: modrdn newrdn: uid=jsmith deleteoldrdn: 1 Setting the value of the deleteoldrdn attribute to 1 deletes the temporary attribute-value pair cn=TempValue. To keep this attribute, set the value of the deleteoldrdn attribute to 0.
19.6.5.2. Solving Orphan Entry ConflictsWhen a delete operation is replicated and the consumer server finds that the entry to be deleted has child entries, the conflict resolution procedure creates a glue entry to avoid having orphaned entries in the directory. In the same way, when an add operation is replicated and the consumer server cannot find the parent entry, the conflict resolution procedure creates a glue entry representing the parent so that the new entry is not an orphan entry. Glue entries are temporary entries that include the object classes glue and extensibleObject. Glue entries can be created in several ways: If the conflict resolution procedure finds a deleted entry with a matching unique identifier, the glue entry is a resurrection of that entry, with the addition of the glue object class and the nsds5ReplConflict attribute. In such cases, either modify the glue entry to remove the glue object class and the nsds5ReplConflict attribute to keep the entry as a normal entry or delete the glue entry and its child entries. The server creates a minimalistic entry with the glue and extensibleObject object classes.
In such cases, modify the entry to turn it into a meaningful entry or delete it and all of its child entries. Deleting or demoting a replica removes the IdM replica from the server/replica topology so that it no longer processes IdM requests and it also removes the host machine itself from the IdM domain. On an IdM server, obtain a Kerberos ticket before running IdM tools. [root@replica ~]#kinit admin List all of the configured replication agreements for the IdM domain. [root@replica ~]# ipa-replica-manage listDirectory Manager password: ipaserver.example.com: masteripaserver2.example.com: masterreplica.example.com: masterreplica2.example.com: master Removing the replica from the topology involves deleting all the agreements between the replica and the other servers in the IdM domain and all of the data about the replica in the domain configuration. [root@replica ~]# ipa-replica-manage del replica.example.com If the replica was configured with its own CA, then also use the ipa-csreplica-manage command to remove all of the replication agreements between the certificate databases for the replica. This is required if the replica itself was configured with a Dogtag Certificate System CA. It is not required if only the master server or other replicas were configured with a CA. [root@replica ~]# ipa-csreplica-manage del replica.example.com On the replica, uninstall the replica packages. [root@replica ~]# ipa-server-install --uninstall -U
19.8.1. Starting IdM with Expired CertificatesIf IdM administrative server certificates expire, then most IdM services will be inaccessible, including administrative services. The underlying Apache and 389 Directory Server services can be configured to allow SSL access to those services, even if the certificates are expired. Allowing limited access with expired certificates permits Apache, Kerberos, DNS, and 389 Directory Server services to continue working. With those services active, users are able to log into the domain. Client services such as sudo that require SSL for access will still fail because of the expired server certificates. Change the mod_nss configuration for the Apache server to not enforce valid certificates, in the NSSEnforceValidCerts parameter. If this parameter is not already in the file, then add it. Set the value to off. [root@ipaserver ~]# vim /etc/httpd/conf.d/nss.confNSSEnforceValidCerts off Restart Apache. [root@ipaserver ~]# service httpd restart Change the nsslapd-validate-cert attribute in the 389 Directory Server configuration to warn instead of true to disable validity checks. [root@ipaserver ~]# ldapmodify -D "cn=directory manager" -w secret -p 389 -h ipaserver.example.comdn: cn=configchangetype: modifyreplace: nsslapd-validate-certnsslapd-validate-cert: warn Restart 389 Directory Server. [root@ipaserver ~]# service dirsrv restart
19.8.2. There are SASL, GSS-API, and Kerberos errors in the 389 Directory Server logs when the replica starts.When the replica starts, there can be a series of SASL bind errors recorded in the 389 Directory Server logs stating that the GSS-API connection failed because it could not find a credentials cache: slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_496' not found)) ... The replica is looking for a credentials cache in /tmp/krb5cc_496 (where 496 is the 389 Directory Server user ID) and cannot find it. There may also be messages that the server could not obtain Kerberos credentials for the host principal: set_krb5_creds - Could not get initial credentials for principal [ldap/ replica1.example.com] in keytab [WRFILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error) These errors are both related to how and when the 389 Directory Server instance loads its Kerberos credentials cache. While 389 Directory Server itself supports multiple different authentication mechanisms, Identity Management only uses GSS-API for Kerberos connections. The 389 Directory Server instance for Identity Management keeps its Kerberos credentials cache in memory. When the 389 Directory Server process ends - like when the IdM replica is stopped - the credentials cache is destroyed. Also, the 389 Directory Server is used as the backend storage for the principal information for the KDC. When the replica then restarts, the 389 Directory Server instance starts first, since it supplies information for the KDC, and then the KDC server starts. This start order is what causes the GSS-API and Kerberos connection errors. The 389 Directory Server attempts to open a GSS-API connection, but since there is no credentials cache yet and the KDC is not started, the GSS connection fails. Likewise, any attempt to obtain the host credentials also fails. These errors are transient. The 389 Directory Server re-attempts the GSS-API connection after the KDC starts and it has a credentials cache. The 389 Directory Server logs then record a bind resumed message. These startup GSS-API connection failures can be ignored as long as that connection is successfully established. |
| |
