| Identity Management GuideChapter 13. Policy: Managing the Kerberos DomainKerberos authentication is the core of authentication within the IdM domain. The IdM server actually runs a Kerberos server within it, and this Kerberos server can be configured for custom policies for managing tickets and keytabs. Identity Management has its own command-line tools to use to manage Kerberos policies. Do not use kadmin or kadmin.local to manage IdM Kerberos settings. Kerberos provides an authentication layer between services and users. Kerberos centralizes authentication into a single location; a user authenticates to the Kerberos server, and then when that user attempts to access any resource on the network, that resource can check the key distribution center (KDC) for the stored user credentials. This allows users to access multiple resources without having to supply credentials separately to each and every one. All of the users and services, combined, and all of the KDCs and Kerberos servers that are aware of each other constitute a realm. Each user, machine, and service within the realm is identified by a unique name called the principal. The user or service uses the principal and a verifying credential (usually a password) to authenticate to the KDC. The credential that is shared with the KDC is a key and it is stored in a file called a key table or keytab. When the KDC verifies the user's identity, it issues a ticket. The ticket is a long-term pass to any service and machine on the realm. The KDC issues the user a special kind of ticket called a ticket-granting ticket (TGT). Whenever the user tries to access a resource within the Kerberos realm, the resource sends a request for a ticket specifically for it. The TGT is used to issue a resource-specific ticket that the resource then uses to authenticate the user and grant access. When an IdM client is first configured, the host principal is automatically retrieved by the setup script and stored in the /etc/krb5.keytab file. This host principal is stored within the host record so that local service commands cannot be used with this principal. This prepares the client to function in the IdM realm. 13.1.1. About Principal NamesThe principal identifies not only the user or service, but also the realm that that entity belongs to. A principal name has two parts, the identifier and the realm: identifier@REALM
For a user, the identifier is only the Kerberos username. For a service, the identifier is a combination of the service name and the hostname of the machine it runs on: service/FQDN@REALM
The service name is a case-sensitive string that is specific to the service type, like host, ldap, http, and dns. Not all services have obvious principal identifiers; the sshd daemon, for example, uses the host service principal. The host principal is usually stored in /etc/krb5.keytab. When Kerberos requests a ticket, it always resolves the domain name aliases (DNS CNAME records) to the corresponding DNS address (A or AAAA records). The hostname from the address record is then used when service or host principals are created. For example: www.example.comCNAMEweb-01.example.comweb-01.example.comA192.0.2.145 A service attempts to connect to the host using its CNAME alias: $ ssh www.example.com 13.1.2. About Protecting KeytabsTo protect keytab files, reset the permissions and ownership to restrict access to the files to only the keytab owner. For example, set the owner of the Apache keytab (/etc/httpd/conf/ipa.keytab) to apache and the mode to 0600. 13.2. Setting Kerberos Ticket PoliciesThe Kerberos ticket policy sets basic restrictions on managing tickets within the Kerberos realm, such as the maximum ticket lifetime and the maximum renewal age (the period during which the ticket is renewable). The Kerberos ticket policy is set globally so that it applies to every ticket issued within the realm. IdM also has the ability to set user-level ticket policies which override the global policies. This can be used, for example, to set extended expiration times for administrators or to set shorter expiration times for some employees. 13.2.1. Setting Global Ticket Policies13.2.1.1. From the Web UIClick the Policy tab, and then click the Kerberos Ticket Policy subtab. Change the ticket lifetime policies. Click the Update link at the top of the policy page. Restart the KDC. # service krb5kdc restart Any change to the global Kerberos ticket policy requires a restart of the KDC for the changes to take effect.
13.2.1.2. From the Command LineThe ipa krbtpolicy-mod command modifies the policy, while the ipa krbtpolicy-reset command resets the policy to the default values. For example: # ipa krbtpolicy-mod --maxlife=3600 --maxrenew=18000 Max life: 3600 Max renew: 18000 Any change to the global Kerberos ticket policy requires a restart of the KDC for the changes to take effect. Restart the KDC: # service krb5kdc restart 13.2.2. Setting User-Level Ticket PoliciesUser-level Kerberos ticket policies are set using the same commands as global policies, but the user is specified in the command. For example: # ipa krbtpolicy-mod jsmith --maxlife=3600 Max life: 3600 User-level policies take effect immediately on the next requested ticket (such as running kinit), without having to restart the KDC service. 13.3. Refreshing Kerberos TicketsKerberos keys are analogous to passwords. Like passwords, security policies may require that Kerberos tickets are manually refreshed after a specified interval. The version of the key is shown in its key version number (KVNO). Refreshing (also called rotating) the principal's key increments the KVNO in the keytab entry. When a key is refreshed, a new entry is added to the keytab with a higher KVNO. The original key remains in the keytab but is no longer used to issue tickets. Each keytab for the IdM realm has an entry in the IdM LDAP server, which includes its last change time. The principals which need to be refreshed can be regenerated using the ipa-getkeytab command. The ipa-getkeytab command does not delete the old keytab in case it already exists in the file. Find all keytabs issued before the requisite date. For example, this looks for any principals created between midnight on January 1, 2010, and 11:59 PM on December 31, 2010: # ldapsearch -x -b "cn=computers,cn=accounts,dc=example,dc=com" "(&(krblastpwdchange>=20100101000000)(krblastpwdchange<=20101231235959))" dn krbprincipalname # ldapsearch -x -b "cn=services,cn=accounts,dc=example,dc=com" "(&(krblastpwdchange>=20100101000000)(krblastpwdchange<=20101231235959))" dn krbprincipalname Host (machine) principals are stored under the cn=computers,cn=accounts,dc=example,dc=com subtree. Service principals are stored under the cn=services,cn=accounts,dc=example,dc=com subtree. Filter by the last change date (krblastpwdchange). Limit the search result information to only the entry name and principal by specifying the dn krbprincipalname attributes.
Dates are expressed in YYYYMMDD format, and times in HHMMSS format (GMT). Retrieve a new keytab for the principal using the ipa-getkeytab command. This requires the location of the original keytab for the service or host (-k), the principal (-p), and the IdM server hostname (-s). For example, this refreshes the host principal with a keytab in the default location of /etc/krb5.keytab: # ipa-getkeytab -p host/[email protected] -s ipa.example.com -k /etc/krb5.keytab This refreshes the keytab for the Apache service, with a keytab in the default location of /etc/httpd/conf/ipa.keytab: # ipa-getkeytab -p HTTP/[email protected] -s ipa.example.com -k /etc/httpd/conf/ipa.keytab Regenerate the keytab using ipa-getkeytab for every service.
The klist command displays the new key version number for the refreshed keytab. The original keytab still exists in the database, and it is listed with the previous KVNO. # klist -kt /etc/krb5.keytabKeytab: WRFILE:/etc/krb5.keytabKVNO Timestamp Principal---- ----------------- -------------------------------------------------------- 1 06/09/10 11:23:01 host/[email protected](aes256-cts-hmac-sha1-96) 2 06/09/11 05:58:47 host/[email protected](aes256-cts-hmac-sha1-96) 1 03/09/11 13:57:16 krbtgt/[email protected](aes256-cts-hmac-sha1-96) 1 03/09/11 13:57:16 HTTP/[email protected](aes256-cts-hmac-sha1-96) 1 03/09/11 13:57:16 ldap/[email protected](aes256-cts-hmac-sha1-96) Tickets issued against the old keytab continue to work, while new tickets are issued using the key with the highest KVNO. This avoids any disruption to system operations. Some services, such as NFSv4, only support a limited set of encryption types. Pass the appropriate arguments to the ipa-getkeytab command to configure the keytab properly. 13.4. Caching Kerberos PasswordsA machine may not always be on the same network as the IdM domain; for example, a machine may need to be logged into a VPN before it can access the IdM domain. If a user logs into a system when it is offline and then later attempts to connect to IdM services, then the user is blocked because there is no IdM Kerberos ticket for that user. IdM works around that limitation by using SSSD to store the Kerberos passwords in the SSSD cache. This is configured by default by the ipa-client-install script. A configuration parameter is added to the /etc/sssd/sssd.conf file which specifically instructs SSSD to store those Kerberos passwords for the IdM domain: [domain/example.com]cache_credentials = Trueipa_domain = example.comid_provider = ipaauth_provider = ipaaccess_provider = ipachpass_provider = ipaipa_server = _srv_, server.example.comkrb5_store_password_if_offline = true This default behavior can be disabled during the client installation by using the --no-krb5-offline-passwords option. This behavior can also be disabled by editing the /etc/sssd/sssd.conf file and removing the krb5_store_password_if_offline line or changing its value to false. [domain/example.com]...krb5_store_password_if_offline = false Refreshing Kerberos tickets adds a new key to the keytab, but it does not clear the keytab. If a host is being unenrolled and re-added to the IdM domain or if there are Kerberos connection errors, then it may be necessary to remove the keytab and create a new keytab. This is done using the ipa-rmkeytab command. To remove all principals on the host, specify the realm with the -r option: # ipa-rmkeytab -r EXAMPLE.COM -k /etc/krb5.keytab To remove the keytab for a specific service, use the -p option to specify the service principal: # ipa-rmkeytab -p ldap/client.example.com -k /etc/krb5.keytab 13.6. Troubleshooting Kerberos ErrorsKerberos errors frequently become apparent when trying to connect to the realm using kinit or a similar client. For information related to Kerberos, first check the Kerberos manpages, help files, and other resources. Identity Management has its own command-line tools to use to manage Kerberos policies. Do not use kadmin or kadmin.local to manage IdM Kerberos settings. There are several places to look for Kerberos error log information: For kinit problems or other Kerberos server problems, look at the KDC log in /var/log/krb5kdc.log. For IdM-specific errors, look in /var/log/httpd/error_log.
It is possible to disable reverse DNS lookups in the SSH configuration. Rather than using reverse DNS records, SSH passes the given username directly to GSS-API. To disable reverse DNS lookups with SSH, add or edit the GSSAPITrustDNS directive and set the value to no. # vim /etc/ssh/ssh_config GSSAPITrustDNS no Failure to export an updated keytab can cause problems that are difficult to isolate. For example, existing service connections may continue to function, but no new connections may be possible. Chapter 14. Policy: Using sudoIdentity Management provides a mechanism for predictably and consistently apply sudo policies across the IdM domain. The sudo policies apply to domain users and domain hosts. The sudo command allows a system administrator to delegate authority to specific users to run specific commands as root or another specified user. sudo provides an audit trail of the commands and their arguments, so access can be tracked. 14.1.1. General sudo Configuration in Identity Managementsudo uses a local configuration file, /etc/sudoers, which defines the commands and users with sudo access. While this file can be shared among machines, there's no native way to distribute sudo configuration files among machines.
Identity Management uses its centralized LDAP database to contain the sudo configuration, which makes it globally available to all domain hosts. Identity Management also has a specialized LDAP schema for sudo entries that allows a lot more flexible and simpler configuration. This schema adds two key features: The Identity Management schema supports host groups in addition to netgroups for sudo, while sudo only supports netgroups. For every host group, Identity Management also creates a corresponding shadow netgroup. This allows IdM administrators to create sudo rules that reference host groups, while the local sudo command uses the corresponding netgroup. Identity Management introduces the concept of a sudo command group. The group contains multiple commands, and then the command group can be referenced in the sudo configuration.
Because sudo does not support host groups and command groups, Identity Management translates the IdM sudo configuration into native sudo configuration when the sudo rules are created. Because the sudo information is not available anonymously over LDAP by default, Identity Management defines a default sudo user, uid=sudo,cn=sysaccounts,cn=etc,$SUFFIX, which can be set in the LDAP/sudo configuration file, /etc/sud-ldap.conf. Both sudo and Identity Management support user groups as part of the sudo configuration. User groups can be either Unix or non-POSIX groups. Creating non-POSIX groups can create some access issues because any users in the group inherit non-POSIX rights from the group. Having the choice between Unix and non-POSIX groups allows administrators the choice in group formatting and to avoid problems with inherited permissions or GID information. 14.1.2. sudo and NetgroupsAs Section 14.1.1, "General sudo Configuration in Identity Management" mentions, the LDAP schema used for sudo entries in Identity Management supports host group-style groups in addition to netgroups. Really, Identity Management creates two groups, a visible host group and a shadow netgroup. sudo itself only supports NIS-style netgroups for group formats. One important thing to consider is that even though sudo uses NIS netgroups, it is not necessary to have a NIS server installed or a NIS client configured. When any group is created for sudo, the NIS object is created in the Directory Server instance, and then the information is retrieved by NSS_LDAP or by SSSD. The client (in this case, sudo) then extracts the required NIS information from the information provided by Identity Management's Directory Server. In short, sudo configuration requires NIS-formatted netgroups. It does not require NIS. The Identity Management Directory Server instance uses the standard LDAP schema for NIS objects, defined in RFC 2307. 14.1.3. Supported sudo ClientsAny system which is supported as an IdM client system can be configured as a sudo client in IdM. 14.2. Setting up sudo Commands and Command GroupsJust as in regular sudo configuration, any command which will be governed by sudo access must be listed in the configuration. Identity Management adds an extra control measure with sudo command groups, which allow a group of commands to be defined and then applied to the sudo configuration as one. Adding a command or a command group makes it available to IdM to be defined in a sudo rule; simply adding a command does not automatically include it in a sudo rule. 14.2.1. Adding sudo Commands14.2.1.1. Adding sudo Commands with the Web UIClick the Policy tab. Click the Sudo subtab, and then select the Sudo Commands link. Click the Add link at the top of the list of commands. Enter the full system path and name of the command and, optionally, a description. Click the Add and Edit button to go immediately to the edit pages for the command. In the Sudo Command Groups tab, click the Add button to add the sudo command to a command group. Click the checkbox by the groups for the command to join, and click the right arrows button, >>, to move the group to the selection box. Click the Add button.
14.2.1.2. Adding sudo Commands with the Command LineTo add a single command, use the sudocmd-add command. This requires the full, local path to the command executable and a description of the command: $ ipa sudocmd-add --desc "description" /local/path/to/command For example: $ ipa sudocmd-add --desc 'For reading log files' '/usr/bin/less'----------------------------------Added sudo command "/usr/bin/less"---------------------------------- sudo Command: /usr/bin/less Description: For reading log files 14.2.2. Adding sudo Command Groups14.2.2.1. Adding sudo Command Groups with the Web UIClick the Policy tab. Click the Sudo subtab, and then select the Sudo Command Groups link. Click the Add link at the top of the list of command groups. Enter the name and description for the new command group. Click the Add and Edit button to go immediately to the edit pages for the group. In the Sudo Commands tab, click the Add button to add a sudo command to the group. In the Sudo Commands tab, click the Add button to add a sudo command to the group. Click the checkbox by the names of the commands to add, and click the right arrows button, >>, to move the command to the selection box. Click the Add button.
14.2.2.2. Adding sudo Command Groups with the Command LineCreating a command group requires creating two entries, one for the group and one for the command itself: Create the command group using the sudocmdgroup-add command: $ ipa sudocmdgroup-add --desc 'File editing commands' files-----------------------------------Added sudo command group "files"----------------------------------- sudo Command Group: files Description: File editing commands Create a command entry using the sudocmd-add command: $ ipa sudocmd-add --desc 'For editing files' '/usr/bin/vim'----------------------------------Added sudo command "/usr/bin/vim"---------------------------------- sudo Command: /usr/bin/vim Description: For editing files Add the command, using its full directory location as its name, to the command group using the sudocmdgroup-add-member command: $ ipa sudocmdgroup-add-member --sudocmds '/usr/bin/vim' files sudo Command Group: files Description: File editing commands Member sudo commands: /usr/bin/vim-------------------------Number of members added 1-------------------------
14.3. Defining sudo Rulessudo rules are in a sense similar to access control rules: they define users who are granted access, the commands which are within the scope of the rule, and then the target hosts to which the rule applies. In IdM, additional information can be configured in the rule, such as sudoers options and run-as settings, but the basic elements always define who, what (services), and where (hosts).
14.3.1. About External Users and Hostssudo rules define four elements: who can do what, where, and as whom. The who is the regular user, and the as whom is the system or other user identity which the user uses to perform tasks. Those tasks are system commands that can be run (or specifically not run) on a target machine.
Three of those elements - who, as whom, and where - are identities. They are uses and hosts. Most of the time, those identities are going to be entities within the IdM domain because there will be overlap between the system users and machines in the environment and the users and hosts belonging to the IdM domain. However, that is not necessarily the case with all identities that a sudo policy may realistically cover. For example, sudo rules could be used to grant root access to member of the IT group in IdM, and that root user is not a user in IdM. Or, for another example, administrators may want to block access to certain hosts that are on a network but are not part of the IdM domain. The sudo rules in Identity Management support the concept of external users and hosts - meaning, hosts and users which are stored and exist outside of the IdM configuration. When configuring a sudo rule, the user, run-as, and host settings all can point to an external identity to be included and evaluated in the sudo rule. 14.3.2. About sudo Options FormatHowever, the sudo rule configuration in Identity Management does not allow the same formatting as the configuration in the /etc/sudoers file. Specifically, Identity Management does not allow whitespaces in the options parameter, whether it is set in the UI or the CLI. For example, in the /etc/sudoers file, it is permissible to list options in a comma-separate list with spaces between: mail_badpass, mail_no_host, mail_no_perms, syslog = local2 However, in Identity Management, that same configuration would be interpreted as different arguments - including the equals sign (=) since it has spaces around it. Likewise, linebreaks that are ignored in the /etc/sudoers file are not allowed in the Identity Management configuration: env_keep = "COLORS DISPLAY EDITOR HOSTNAME HISTSIZE INPUTRC KDEDIR LESSSECURE LS_COLORS MAIL PATH PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY" To use multiple sudoers options in Identity Management, configure each one as a separate option setting, rather than all on one line, as is allowed in the /etc/sudoers file. 14.3.3. Defining sudo Rules in the Web UIClick the Policy tab. Click the Sudo subtab, and then select the Sudo Rules link. Click the Add link at the top of the list of sudo rules. Enter the name for the rule. Click the Add and Edit button to go immediately to set the configuration for the rule. There are a number of configuration areas for the rule. The most basic elements are set in the Who, Access This Host, and Run Commands areas; the others are optional and are used to refine the rule. Click the + Add link at the right of the options list. Enter the sudoers option. Click Add.
In the Who area, select the users or user groups to which the sudo rule is applied. Click the + Add link at the right of the users list. Click the checkbox by the users to add to the rule, and click the right arrows button, >>, to move the users to the selection box. Click Add.
In the Access This Host area, select the hosts on which the sudo rule is in effect. Click the + Add link at the right of the hosts list. Click the checkbox by the hosts to include with the rule, and click the right arrows button, >>, to move the hosts to the selection box. Click Add.
In the Run Commands area, select the commands which are included in the sudo rule. The sudo rule can grant access or deny access to commands, and it can grant allow access to one command and also deny access to another. In the Allow/Deny area, click the + Add link at the right of the commands list. Click the checkbox by the commands or command groups to include with the rule, and click the right arrows button, >>, to move the commands to the selection box. Click Add.
Optional. The sudo rule can be configured to run the given commands as a specific, non-root user. In the As Whom area, click the + Add link at the right of the users list. Click the checkbox by the users to run the command as, and click the right arrows button, >>, to move the users to the selection box. Click Add.
14.3.4. Defining sudo Rules in the Command LineThe basic outline of a sudo rule command is: $ ipa sudorule-add* options ruleName Example 14.1. Creating Basic sudo Rules In the most basic case, the sudo configuration is going to grant the right to one user for one command on one host. The first step is to add the initial rule entry. $ ipa sudorule-add files-commands-----------------------------------Added sudo rule "files-commands"----------------------------------- Rule name: files-commands Enabled: TRUE Next, add the commands to grant access to. This can be a single command, using --sudocmd, or a group of commands, using --sudocmdgroups. $ ipa sudorule-add-allow-command --sudocmd "/usr/bin/vim" files-commands Rule name: files-commands Enabled: TRUE sudo Commands: /usr/bin/vim-------------------------Number of members added 1------------------------- Add a host or a host group to the rule. $ ipa sudorule-add-host --host server.example.com files-commands Rule name: files-commands Enabled: TRUE Hosts: server.example.com sudo Commands: /usr/bin/vim-------------------------Number of members added 1------------------------- Last, add the user or group to the rule. This is the user who is allowed to use sudo as defined in the rule; if no "run-as" user is given, then this user will run the sudo commands as root. $ ipa sudorule-add-user --user jsmith files-commands Rule name: files-commands Enabled: TRUE Users: jsmith Hosts: server.example.com sudo Commands: /usr/bin/vim"-------------------------Number of members added 1------------------------- Example 14.2. Allowing and Denying Commands The sudo rule can grant access or deny access to commands. For example, this rule would allow read access to files but prevent editing: $ ipa sudorule-add-allow-command --sudocmd "/usr/bin/less" readfiles$ ipa sudorule-add-allow-command --sudocmd "/usr/bin/tail" readfiles$ ipa sudorule-add-deny-command --sudocmd "/usr/bin/vim" readfiles Example 14.3. Using sudoers Options The sudoers file has a lot of potential flags that can be set to control the behavior of sudo users, like requiring (or not requiring) passwords to offer a user to authenticate to sudo or using fully-qualified domain names in the sudoers file. The complete list of options is in the sudoers manpage and at http://www.gratisoft.us/sudo/sudoers.man.html#sudoers_options. Any of these options can be set for the IdM sudo rule using the sudorule-add-option command. When the command is run, it prompts for the option to add: $ ipa sudorule-add-option readfilesSudo Option: !authenticate-----------------------------------------------------Added option "!authenticate" to Sudo rule "readfiles"----------------------------------------------------- Example 14.4. Running as Other Users The sudo rule also has the option of specifying a non-root user or group to run the commands as. The initial rule has the user or group specified using the --sudorule-add-runasuser or --sudorule-add-runasgroup command, respectively. $ ipa sudorule-add-runasuser --users=jsmith readfiles$ ipa sudorule-add-runasgroup --groups=ITadmins readfiles When creating a rule, the sudorule-add-runasuser or sudorule-add-runasgroup command can only set specific users or groups. However, when editing a rule, it is possible to run sudo as all users or all groups by using the --runasusercat or --runasgroupcat option. For example: $ ipa sudorule-mod --runasgroupcat=all ruleName The --sudorule-add-runasuser and --sudorule-add-runasgroup commands do not support an all option, only specific user or group names. Specifying all users or all groups can only be used with options with the sudorule-mod command. Example 14.5. Referencing External Users or Hosts The "who" in a sudo rule can be an IdM user, but there are many logical and useful rules where one of the referents is a system user. Similarly, a rule may need to grant or deny access to a host machine on the network which is not an IdM client. There are three options to add an external identity to a sudo rule: --externaluser --runasexternaluser --externalhost
For example: $ ipa sudorule-add-host --externalhost=external-server.example.com readfiles$ ipa sudorule-add-user --externaluser=ITAdmin readfiles$ ipa sudorule-add-runasuser --runasexternaluser=root readfiles Table 14.1. sudo Commands | Command | Description |
|---|
| sudorule-add | Adds a sudo rule entry. | | sudorule-add-user | Adds a user or a user group to the sudo rule. This user (or every member of the group) is then entitled to sudo any of the commands in the rule. | | sudorule-add-host | Adds a target host for the rule. These are the hosts where the users are granted sudo permissions. | | sudorule-add-runasgroup | Sets a group to run the sudo commands as. This must be a specific user; to specify all users, modify the rule using sudo-rule. | | sudorule-add-runasuser | Sets a user to run the sudo commands as. This must be a specific user; to specify all users, modify the rule using sudo-rule. | | sudorule-add-allow-command | Adds a command that users in the rule have sudo permission to run. | | sudorule-add-deny-command | Adds a command that users in the rule are explicitly denied sudo permission to run. | | sudorule-add-option | Adds a sudoers flag to the sudo rule. |
14.4. Applying the Configured sudo Policies to HostsActually implementing sudo policies is more complicated than simply creating the rules in IdM. Those rules need to be applied to every local machine, which means that each system in the IdM domain has to be configured to refer to IdM (as an LDAP server) for its policies. This example specifically configures a Red Hat Enterprise Linux 6 client for sudo rules. The configuration file in step d is different, depending on the platform. Set up a bind (authenticated) user by setting a password for the default IdM sudo user. The user must be able to authenticate to the server; anonymous access is not supported for sudo policies. Using LDAP tools, set the password for the sudo user, uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com. For example: $ ldappasswd -Y GSSAPI -S -h ipaserver.ipadocs.org uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com New password: Re-enter new password: Enter LDAP Password: Configure every system in the IdM domain. Configure sudo to look to LDAP for the sudoers file. vim /etc/nsswitch.confsudoers: files ldap Leaving the files option in place allows sudo to check its local configuration before checking the LDAP-based IdM configuration. Enable debug logging for sudo operations in the /etc/ldap.conf file. If this file does not exist, it can be created. vim /etc/ldap.confsudoers_debug: 1 Adding the sudoers_debug parameter helps with troubleshooting. Valid values for this parameter are 0, 1, and 2. The sudo documentation at http://www.gratisoft.us/sudo/readme_ldap.html has more information on debugging the process. Optionally, enable debugging in SSSD to show what LDAP settings it is using. vim /etc/sssd/sssd.conf[domain/IPADOMAIN]debug_level = 6.... The LDAP search base used by SSSD for operations is recorded in the sssd_DOMAINNAME.log log. Edit the NSS/LDAP configuration file and add the following sudo-related lines to the /etc/sudo-ldap.conf file: binddn uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=combindpw sudo_passwordssl start_tlstls_cacertfile /etc/ipa/ca.crttls_checkpeer yesbind_timelimit 5timelimit 15uri ldap://ipaserver.example.com ldap://backup.example.com:3890sudoers_base ou=SUDOers,dc=example,dc=com The uri directive must give the fully-qualified domain name of the LDAP server, not an IP address. Otherwise, sudo fails to connect to the LDAP server. Set a name for the NIS domain in the sudo configuration. sudo uses NIS-style netgroups, so the NIS domain name must be set in the system configuration for sudo to be able to find the host groups used in the IdM sudo configuration. Open the /etc/rc.d/rc.local file. Setting the NIS domain name in this file allows the value to persist between reboots. # vim /etc/rc.d/rc.local Add the command to set the NIS domain name. nisdomainname example.com
Even though sudo uses NIS-style netgroups, it is not necessary to have a NIS server installed. Netgroups require that a NIS domain be named in their configuration, so sudo requires that a NIS domain be named for netgroups. However, that NIS domain does not actually need to exist.
|
| |
