SupportConsoleDevelopersStart a trialContact

5.3. Managing and Configuring a Cross-forest Trust Environment

5.3.1. User Principal Names in a Trusted Domains Environment

IdM supports the logging in using user principal names (UPN). A UPN is an alternative to the user name to authenticate with, and has the format username@KERBEROS-REALM. In an Active Directory forest it is possible to configure additional UPN suffixes. These enterprise principal names are used to provide alternative logins to the default UPN.
For example, if a company uses the Kerberos realm AD.EXAMPLE.COM, the default UPN for a user is user@ad.example.com. However often a company want instead their users to be able to log in using their email addresses, like user@example.com. In this case the administrator adds an additional UPN suffix example.com to the Active Directory forest and sets the new suffix in the user's account properties.
UPN suffixes are only visible for IdM when defined in the AD forest root. As an AD administrator, you can define UPNs with the Active Directory Domain and Trust utility or the PowerShell command line tool.

Note

To configure UPN suffixes for users, Red Hat recommends to use tools that perform error validation, such as the Active Directory Domain and Trust utility.
Red Hat recommends against configuring UPNs through low-level modifications, such as using ldapmodify commands to set the userPrincipalName attribute for users, because Active Directory does not validate those operations.
When you add or remove UPN suffixes in a trusted AD forest, you have to refresh the information for the trusted forest on the IdM master: 
[root@ipaserver ~]# ipa trust-fetch-domains
Realm-Name: ad.example.com
-------------------------------
No new trust domains were found
-------------------------------
----------------------------
Number of entries returned 0
----------------------------
Verify that the alternative UPN was fetched, by running: 
[root@ipaserver ~]# ipa trust-show
Realm-Name: ad.example.com
  Realm-Name: ad.example.com
  Domain NetBIOS name: AD
  Domain Security Identifier: S-1-5-21-796215754-1239681026-23416912
  Trust direction: Two-way trust
  Trust type: Active Directory domain
  UPN suffixes: example.com
The UPN suffixes for a domain are stored in the multi-value attribute ipaNTAdditionalSuffixes in the cn=trusted_domain_name,cn=ad,cn=trusts,dc=idm,dc=example,dc=com subtree.

5.3.2. IdM Clients in an Active Directory DNS Domain

In some environments with trusts between IdM and Active Directory, you can install an IdM client on a host that is part of the Active Directory DNS domain. The host can then benefit from the Linux-focused features of IdM.

Important

This is not a recommended configuration and has some limitations. Red Hat recommends to always deploy IdM clients in a DNS zone different from the ones owned by Active Directory and access IdM clients through their IdM host names.

5.3.2.1. Kerberos Single Sign-on to the IdM Client is not Required

For IdM clients set up in the Active Directory DNS domain, only password authentication is available to access resources on this IdM host. To configure the client for this scenario:
  1. To ensure that the System Security Service Daemon (SSSD) on the client can communicate with the IdM servers, install the IdM client with the --domain=IPA_DNS_Domain option: 
    [root@idm-client.ad.example.com ~]# ipa-client-install --domain=idm.example.com
    This option disables the SRV record auto-detection for the Active Directory DNS domain.
  2. Locate the existing mapping for the Active Directory domain in the [domain_realm] section of the /etc/krb5.conf configuration file: 
    .ad.example.com = IDM.EXAMPLE.COM
ad.example.com = IDM.EXAMPLE.COM
    Replace both lines with a mapping entry for the Linux clients fully qualified domain name (FQDN) in the Active Directory DNS zone to the IdM realm: 
    idm-client.ad.example.com = IDM.EXAMPLE.COM
    Replacing the default mapping prevents Kerberos from sending its requests for the Active Directory domain to the IdM Kerberos Distribution Center (KDC). Instead Kerberos uses auto-discovery through SRV DNS records to locate the KDC. Only for the added host idm-client.ad.example.com the IdM KDC is set.

Note

Authenticating to resources on clients that are not within an IdM-owned DNS zone is only possible by using user name and password.

Handling of SSL certificates

SSL-based services require a certificate with dNSName extension records that cover all system host names, because both original (A/AAAA) and CNAME records must be in the certificate. Currently, IdM only issues certificates to host objects in the IdM database.
In the described setup without single sign-on available, IdM already has a host object for the FQDN in the database, and certmonger can request a certificate for this name: 
[root@idm-client.ad.example.com ~]# ipa-getcert request -r \
      -f /etc/httpd/alias/server.crt \
      -k /etc/httpd/alias/server.key \
      -N CN=ipa-client.ad.example.com \
      -D ipa-client.ad.example.com \
      -K host/idm-client.ad.example.com@IDM.EXAMPLE.COM \
      -U id-kp-serverAuth
The certmonger service uses the default host key stored in the /etc/krb5.keytab file to authenticate to the IdM Certificate Authority (CA).

5.3.2.2. Kerberos Single Sign-on to the IdM Client is Required

If you require Kerberos single sign-on to access resources on the IdM client, the client must be within the IdM DNS domain, for example idm-client.idm.example.com. You must create a CNAME record idm-client.ad.example.com in the Active Directory DNS domain pointing to the A/AAAA record of the IdM client.
For Kerberos-based application servers, MIT Kerberos supports a method to allow the acceptance of any host-based principal available in the application's keytab. To disable the strict checks on what Kerberos principal was used to target the Kerberos server, set the following option in the [libdefaults] section of the /etc/krb5.conf configuration file: 
ignore_acceptor_hostname = true

Handling of SSL certificates

SSL-based services require a certificate with dNSName extension records that cover all system host names, because both original (A/AAAA) and CNAME records must be in the certificate. Currently, IdM only issues certificates to host objects in the IdM database.
In the described setup without single sign-on available, IdM already has a host object for the FQDN in the database, and certmonger can request a certificate for this name:
  1. Create a new host object: 
    [root@idm-server.idm.example.com ~]# ipa host-add idm-client.ad.example.com --force
    Use the --force option, because the host name is a CNAME and not an A/AAAA record.
  2. Allow the IdM DNS host name to manage the Active Directory host entry in the IdM database: 
    [root@idm-server.idm.example.com ~]# ipa host-add-managedby idm-client.ad.example.com \
      --hosts=idm-client.idm.example.com
With this setup, the IdM client can request an SSL certificate with dNSName extension record for its host name within the Active Directory DNS domain: 
[root@idm-client.idm.example.com ~]# ipa-getcert request -r \
      -f /etc/httpd/alias/server.crt \
      -k /etc/httpd/alias/server.key \
      -N CN=`hostname --fqdn` \
      -D `hostname --fqdn` \
      -D idm-client.ad.example.com \
      -K host/idm-client.idm.example.com@IDM.EXAMPLE.COM \
      -U id-kp-serverAuth

5.3.3. Creating IdM Groups for Active Directory Users

User groups are required to set access permissions, host-based access control, sudo rules, and other controls on IdM users. These groups are what grant access to IdM domain resources, as well as restricting access.
Both AD users and AD groups can be added directly to IdM user groups. To do that, first add the AD users or groups to a non-POSIX IdM external group and then to a local IdM POSIX group. The POSIX group can then be used for user and role management of the AD users. The principles of handling non-POSIX groups in IdM are described in Section 5.1.3.2, “Active Directory Users and Identity Management Groups”.

Note

It is also possible to add AD user groups as members to IdM external groups. This might make it easier to define policies for Windows users, by keeping the user and group management within the single AD realm.
  1. Optional. Create or select the group in the AD domain to use to manage AD users in the IdM realm. Multiple groups can be used and added to different groups on the IdM side.
  2. Create an external group in the IdM domain for the Active Directory users by adding the --external option to the ipa group-add command. The --external option indicates that this group is intended to contain members from outside the IdM domain. For example: 
    [root@ipaserver ~]# ipa group-add --desc='AD users external map' ad_users_external --external
-------------------------------
Added group "ad_users_external"
-------------------------------
  Group name: ad_users_external
  Description: AD users external map

    Note

    The external group must be linked to a additional group of a user and not to the user's primary group. Active Directory stores group members in member attributes of a group, and IdM uses this attribute to resolve the members. However, Active Directory stores the primary group of users in the primaryGroupID attribute in the user's entry, which is not resolved.
  3. Create a new IdM POSIX group or select an existing one for administering the IdM policies. For example, to create a new group: 
    [root@ipaserver ~]# ipa group-add --desc='AD users' ad_users
----------------------
Added group "ad_users"
----------------------
  Group name: ad_users
  Description: AD users
  GID: 129600004
  4. Add the AD users or groups to the IdM external group as an external member. The AD member is identified by its fully-qualified name, such as DOMAIN\group_name or DOMAIN\username. The AD identity is then mapped to the Active Directory SID for the user or group.
    For example, for an AD group: 
    [root@ipaserver ~]# ipa group-add-member ad_users_external --external "AD\Domain Users"
 [member user]:
 [member group]:
  Group name: ad_users_external
  Description: AD users external map
  External member: S-1-5-21-3655990580-1375374850-1633065477-513 SID_DOM_GROUP (2)
-------------------------
Number of members added 1
-------------------------
  5. Add the external IdM group to the POSIX IdM group as a member. For example: 
    [root@ipaserver ~]# ipa group-add-member ad_users --groups ad_users_external
  Group name: ad_users
  Description: AD users
  GID: 129600004
  Member groups: ad_users_external
-------------------------
Number of members added 1
-------------------------

5.3.4. Maintaining Trusts

Trust management involves several areas, such as global trust configuration, Kerberos trust configuration, DNS realm configuration, or ID ranges assignment to Active Directory users.

5.3.4.1. Editing the Global Trust Configuration

The ipa-adtrust-install utility automatically automatically configures background information for the IdM domain which is required to create a trust with the Active Directory domain.
The global trust configuration contains five attributes:
  • A Windows-style security ID (SID); this attribute is autogenerated and cannot be modified
  • A domain GUID; this attribute is autogenerated and cannot be modified
  • A Kerberos domain name; this attribute comes from the IdM configuration and cannot be modified
  • The default group to which to add IdM users; this attribute can be modified
  • The NetBIOS name; it is not recommended to modify this attribute
The trust configuration is stored in the cn=domain,cn=ad,cn=etc,dc=example,dc=com subtree.
5.3.4.1.1. Changing the NetBIOS Name

Important

Changing the NetBIOS name in most cases requires to re-establish all existing trusts. Therefore, Red Hat recommends not to change the attribute.
A NetBIOS name compatible within an Active Directory topology is configured for the IdM server when running the ipa-adtrust-install utility. To change it later, run ipa-adtrust-install again and specify the new NetBIOS name using the --netbios-name option: 
[root@ipaserver ]# ipa-adtrust-install --netbios-name=NEWBIOSNAME
5.3.4.1.2. Changing the Default Group for Windows Users
When Identity Management is configured to trust an Active Directory forest, an MS-PAC record is added to the Kerberos tickets of IdM users. An MS-PAC record contains security identifiers (SIDs) of the groups to which an IdM user belongs. If the primary group of the IdM user has no SID assigned, the value of the security identifier defined for the Default SMB Group will be used. The same logic is applied by the Samba suite when the AD domain controller requests user information from the IdM trust controller.
The Default SMB Group is a fallback group created automatically by the ipa-adtrust-install utility. The default group cannot be deleted, but you can use the global trust configuration to specify another IdM group to be used as a fallback for the primary group of the IdM users.
To set the default group from the command line, use the ipa trustconfig-mod command: 
[root@server ~]# kinit admin
[root@server ~]# ipa trustconfig-mod --fallback-primary-group="Example Windows Group"
To set the default group from the IdM web UI:
  1. Open the IdM web UI. 
    https://ipaserver.example.com
  2. Under the IPA Server main tab, select the Trusts subtab, and then open the Global Configuration section.
  3. Select a new group from all of the IdM groups in the Fallback primary group drop-down list.
    Configuring the Default Group for Windows Users

    Figure 5.6. Configuring the Default Group for Windows Users

  4. Click Save to save the new configuration.

5.3.4.2. Discovering, Enabling, and Disabling Trust Domains

A transitive trust means that the trust path can follow a chain of domains. It is described in more detail in Section 5.1.1, “The Architecture of a Trust Relationship”.
IdM has a trust with the root domain in a forest and, due to transitivity, all of its child domains and other domains from the same forest are implicitly included in that trust. IdM follows that topology as Windows users from anywhere in the forest attempt to access IdM resources. Each domain and child domain is a trust domain in the IdM trust configuration. Each domain is stored in its own entry, cn=subdomain,cn=trust_name,cn=ad,cn=trusts,dc=example,dc=com in the trusts subtree.
IdM attempts to discover and map the full Active Directory topology when the trust is first configured, although in some cases it is required or beneficial to retrieve that topology manually. That is done with the trust-fetch-domains command: 
[root@ipaserver ~]# kinit admin
[root@ipaserver ~]# ipa trust-fetch-domains ad.example.com
--------------------------------------------
List of trust domains successfully refreshed
--------------------------------------------
  Realm name: test.ad.example.com
  Domain NetBIOS name: TEST
  Domain Security Identifier: S-1-5-21-87535643-5658642561-5780864324

  Realm name: users.ad.example.com
  Domain NetBIOS name: USERS
  Domain Security Identifier: S-1-5-21-91314187-2404433721-1858927112

  Realm name: prod.ad.example.com
  Domain NetBIOS name: PROD
  Domain Security Identifier: S-1-5-21-46580863-3346886432-4578854233
----------------------------
Number of entries returned 3
----------------------------

Note

When adding a trust with a shared secret, you need to manually retrieve topology of the AD forest. After running the ipa trust-add ad.domain --trust-secret command, validate incoming trust at AD side using forest trust properties in the AD Domains and Trusts tool. Then, run the ipa trust-fetch-domains ad.domain command. IdM will receive information about the trust, which will then be usable.
Once the topology is retrieved (through automatic or manual discovery), individual domains and child domains in that topology can be enabled, disabled, or removed entirely within the IdM trust configuration.
For example, to disallow users from a specific child domain from using IdM resources, disable that trust domain: 
[root@ipaserver ~]# kinit admin
[root@ipaserver ~]# ipa trustdomain-disable test.ad.example.com
------------------------------------------
Disabled trust domain "test.ad.example.com"
------------------------------------------
That trust domain can be re-enabled using the trustdomain-enable command.
If a domain should be permanently removed from the topology, than it can be deleted from the IdM trust configuration. 
[root@ipaserver ~]# kinit admin
[root@ipaserver ~]# ipa trustdomain-del prod.ad.example.com
-------------------------------------------------------------------
Removed information about the trusted domain " "prod.ad.example.com"
-------------------------------------------------------------------

5.3.4.3. Viewing and managing domains associated with IdM Kerberos realm

Domains that are associated with the IdM Kerberos realm are stored in the cn=Realm Domains,cn=ipa,cn=etc,dc=example,dc=com subtree in the IdM directory. The list of domains is used by IdM when it establishes a trust with Active Directory. Knowing the full list of domains managed by IdM allows the AD domain controller to know which authentication requests to route to the IdM KDC. The list of configured domains associated with IdM realm can be displayed using the realmdomains-show command: 
[root@ipaserver ~]# kinit admin
[root@ipaserver ~]# ipa realmdomains-show
Domain: ipa.example.org, ipa.example.com, example.com
In an IdM setup with integrated DNS:
  • A domain is automatically added to the domains list after a new DNS zone is added to IdM using the ipa dnszone-add command. Running ipa realmdomains-show shows the new domain in the list of domains controlled by the IdM KDC: 
    # kinit admin
# ipa dnszone-add ipa2.example.com
# ipa realmdomains-show
Domain: ipa.example.org, ipa.example.com, example.com, ipa2.example.com
    Deletion and other types of modification of domains associated with the IdM Kerberos realm are also taken care of automatically.
In an IdM setup without integrated DNS:
  • If a DNS zone has been added that is part of the IdM Kerberos realm, the new domain has to be added manually to the IdM list of domains under the control of the IdM KDC. Add the new domain using the ipa realmdomains-mod command with the --add-domain option: 
    [root@ipaserver ~]# kinit admin
[root@ipaserver ~]# ipa realmdomains-mod --add-domain=ipa2.example.com
Domain: ipa.example.org, ipa.example.com, example.com, ipa2.example.com
    If a DNS zone has been deleted, you need to delete the domain associated with the IdM Kerberos realm manually, too: 
    [root@ipaserver ~]# kinit admin
[root@ipaserver ~]# ipa realmdomains-mod --del-domain=ipa2.example.com
Domain: ipa.example.org, ipa.example.com, example.com
    If there are multiple changes to be made to the list of domains, the list itself can be modified and replaced using the --domain option. 
    [root@ipaserver ~]# ipa realmdomains-mod --domain={ipa.example.org,ipa2.example.com}

5.3.4.4. Adding Ranges for UID and GID Numbers in a Transitive Trust

Creating ID ranges at the time when a trust is originally configured is described in the section called “ID Ranges”. To add an ID range later, use the ipa idrange-add command with the following options:
  • the --base-id option sets the base ID for the POSIX range, which is the starting number
  • The --range-size option sets the size of the POSIX ID range IdM uses. IdM maps the RID of users and groups in a trusted AD domain to POSIX IDs. The --range-size option defines the maximum number of IDs IdM creates. AD uses a new RID for each user and group you create. If you delete a user or group, AD will not re-use the RID for future AD entries. Therefore, the range must be large enough for IdM to assign an ID to each existing AD user and group as well as the ones you create in the future. For example, if an administrator deletes 20000 of 50000 AD users and will, during the time, create 10000 new accounts, the range must be at least set to 60000. However, it is important that the range also contains enough reserves. In large environments, in which you expect that the default (200000) range size is not sufficient, set --range-size to a higher value.
  • the --rid-base option sets the starting number of the RID, which is the far-right number in the SID; the value represents the range to add to the base ID to prevent conflicts
  • the --dom-sid option sets the domain SID, because there can be multiple domains configured for trusts
In the following example, the base ID is 1,200,000 and the RID is 1,000. The resulting ID number is then 1,201,000. 
[root@server ~]$ kinit admin
[root@server ~]$ ipa idrange-add --base-id=1200000 --range-size=200000 --rid-base=0 --dom-sid=S-1-5-21-123-456-789 trusted_dom_range

Important

Make sure that the manually defined ID range does not overlap with the ID range used by IdM.

5.3.4.5. Adjusting DNA ID ranges manually

In some cases, you may need to manually adjust Distributed Numeric Assignment (DNA) ID ranges for existing replicas, for example to recover a DNA ID range assigned to a non-functioning replica or to extend a range that has run out of IDs.
When adjusting a DNA ID range manually, make sure that the newly adjusted range is included in the IdM ID range. You can check this using the ipa idrange-find command. If the newly adjusted range is not included in the IdM ID range, the command fails.
To recover a DNA ID range from a non-functioning replica, use the ipa-replica-manage dnarange-show command to see currently assigned DNA ranges. To see the currently assigned on-deck DNA ranges, use the ipa-replica-manage dnanextrange-show command.

Important

Do not create overlapping ID ranges. If any of the ID ranges you assign to servers or replicas overlap, it could result in two different servers assigning the same ID value to different entries.
To define the current DNA ID range for a specified server, use the ipa-replica-manage dnarange-set command: 
# ipa-replica-manage dnarange-set masterA.example.com 1250-1499
To define the next DNA ID range for a specified server, use the ipa-replica-manage dnanextrange-set command: 
# ipa-replica-manage dnanextrange-set masterB.example.com 1500-5000

5.3.4.6. Kerberos Flags for Services and Hosts

Accessing services or hosts in a trusted domain can require special flags for the Kerberos ticket-granting ticket (TGT). For example, if you want to log in using single sign-on to an IdM client with an Active Directory (AD) account from an AD client, the Kerberos TGT flag OK_AS_DELEGATE is required.
For more information and how to set Kerberos flags, see Kerberos Flags for Services and Hosts in the Linux Domain Identity, Authentication, and Policy Guide.

5.3.5. Setting PAC Types for Services

On IdM resources, if an Active Directory user requests a ticket for a service, then IdM forwards the request to Active Directory to retrieve the user information. Access data, associated with the Active Directory group assignments for the user, is sent back by Active Directory and embedded in the Kerberos ticket.
Group information in Active Directory is stored in a list of identifiers in each Kerberos ticket for Active Directory users in a special data set called privileged access certificates or MS-PAC. The group information in the PAC has to be mapped to the Active Directory groups and then to the corresponding IdM groups to help determine access.
IdM services can be configured to generate PACs for each authentication request when a user first attempts to authenticate to a domain service.

5.3.5.1. Setting Default PAC Types

The IdM server configuration defines which PAC types are generated by default for a service. The global settings can be overridden by changing the local settings on a specific service.
  1. Open the IPA Server tab.
  2. Select the Configuration subtab.
  3. Scroll to the Service Options area.
    The Service Options Area

    Figure 5.7. The Service Options Area

  4. To use PAC, select the MS-PAC check box, which adds a certificate that can be used by AD services. If no check box is selected, then no PAC is added to Kerberos tickets.
    If you select the nfs:NONE check box, the MS-PAC record will not be added to the service tickets issued against NFS servers.

    Note

    You can ignore the PAD check box. This functionality is not yet available in IdM.
  5. Click the Update link at the top of the page to save the changes.

5.3.5.2. Setting PAC Types for a Service

The global policy sets what PAC types to use for a service if nothing is set explicitly for that service. However, the global settings can be overridden on the local service configuration.
To change the PAC setting from the command line, use the ipa service-mod command with the --pac-type option. For information on how to use the command, run it with the --help option added: 
$ ipa service-mod --help
Usage: ipa [global-options] service-mod PRINCIPAL [options]

Modify an existing IPA service.
Options:
-h, --help            show this help message and exit
...
To change the PAC setting in the web UI:
  1. Open the Identity tab, and select the Services subtab.
  2. Click the name of the service to edit.
  3. In the Service Settings area, check the Override inherited settings option and then select the MS-PAC check box to add a certificate that can be used by AD services.
    The Service Settings Area

    Figure 5.8. The Service Settings Area

    If no check box is selected, then no PACs are added to Kerberos tickets.

    Note

    You can ignore the PAD check box. This functionality is not yet available in IdM.
  4. Click the Update link at the top of the page to save the changes.

5.3.6. Using POSIX Attributes Defined in Active Directory

5.3.6.1. Defining UID and GID Attributes for Active Directory Users

If the Windows administrator manually defines POSIX UID and GID attributes for a user, create a matching group on the IdM server with the same GID for the user.
Creating the group ensures that the user is associated with a primary user group. If such group does not exist, the IdM server is unable to look up all groups to which the user belongs.

5.3.6.2. Transferring Login Shell and Home Directory Attributes

Important

The client must be enrolled with an IdM server based on Red Hat Enterprise Linux 7.1 or later to benefit from this functionality.
SSSD is able to read the following attribute values from an Active Directory server in a trust relationship with IdM:
  • the loginShell attribute, which specifies the AD user's shell
  • the unixHomeDirectory attribute, which specifies the AD user's home directory
When a custom shell or home directory value is defined on the AD server using these attributes, the custom value is then displayed to the IdM client for the AD user. Therefore, the same user shell is displayed for the AD user both on the AD side and on the IdM side.
Note that to display the AD user's home directory to the IdM client, the subdomain_homedir option in the [domain] section of the /etc/sssd/sssd.conf file on the IdM server must be set to %o. The %o value represents the home directory retrieved from the identity provider. For example: 
[domain/example.com]
subdomain_homedir = %o
If the AD administrator modifies loginShell or unixHomeDirectory on the AD side, the change is automatically reflected on the IdM side as well. If the attributes are not defined on the AD server, SSSD uses a template default value. This default value is then displayed to the IdM client.

5.3.7. Using SSH from Active Directory Machines for IdM Resources

When a trust is configured, Active Directory users can access machines, services, and files on IdM hosts using SSH and their AD credentials.

5.3.7.1. Caching Considerations

IdM clients do not connect to Active Directory domain controllers (DC) directly to retrieve user attributes. Instead, a client connects to an IdM server who caches this information. For this reason, if you disable a user in Active Directory, the user can still authenticate to IdM clients using SSH key authentication until the record of the user expires in the IdM database.
IdM updates a record of a user in the following situations:
  • The entry has expired automatically.
  • You manually expire the entry of the user in the cache using the sss_cache utility: 
    # sss_cache --user user_name
  • The user authenticates to an IdM server using the kinit utility or the web UI.

5.3.7.2. Using SSH Without Passwords

The localauth Kerberos plug-in for local authorization ensures that Kerberos principals are automatically mapped to local SSSD user names. With localauth, Windows users from a trusted AD domain are not prompted for a password when logging in using Kerberos and can therefore use SSH without passwords.
The plug-in provides a reliable mapping mechanism across multiple realms and trusts: when sssd connects to the Kerberos library to map the principal to a local POSIX identity, the SSSD plug-in maps them according to the trust agreements defined in IdM.
In certain situations, users use an SSH bastion host to access other Red Hat Enterprise Linux machines. By default, if you use Kerberos to authenticate to SSH on the bastion host, the Kerberos ticket cannot be forwarded to authenticate using Kerberos to other Red Hat Enterprise Linux hosts. To enable such forward authentication, add the OK_AS_DELEGATE Kerberos flag to the bastions host principal: 
# ipa host-mod bastion_host.idm.example.com --ok-as-delegate=true

Kerberos Authentication for AD Users on Red Hat Enterprise Linux 7.1 and newer Systems

In Red Hat Enterprise Linux 7.1 and newer systems, SSSD automatically configures the localauth Kerberos plug-in.
SSSD allows user names in the format user@AD.DOMAIN, ad.domain\user and AD\user.

Note

On systems with localauth, it is not required to set the auth_to_local option in the /etc/krb5.conf file or list Kerberos principals in the .k5login file. The localauth plug-in makes this previously used configuration for logins without passwords obsolete.

Manual Configuration of Kerberos Authentication for AD Users

On systems where the localauth plug-in is not present, SSH prompts for a user password for Active Directory domain users even if the user obtains a proper Kerberos ticket.
To enable Active Directory users to use Kerberos for authentication in this situation, configure the auth_to_local option in the /etc/krb5.conf file or list the user Kerberos principals in the .k5login file in the home directory of the user.
Configuring /etc/krb5.conf
The following procedure describes how to configure realm mapping in the Kerberos configuration.
  1. Open the /etc/krb5.conf file.
  2. In the [realms] section, identify the IdM realm by name, and then add two auth_to_local lines to define the Kerberos principal name mapping:
    • In one rule, include a rule to map different Active Directory user name formats and the specific Active Directory domain.
    • In the other rule, set the value of DEFAULT, for standard Unix user names.
    For example: 
    [realms]
IDM = {
....
auth_to_local = RULE:[1:$1@$0](^.*@ADDOMAIN$)s/@ADDOMAIN/@addomain/
auth_to_local = DEFAULT
}
  3. Restart the KDC service. 
    [root@server ~]# systemctl restart krb5kdc.service
Note that if you configure Kerberos authentication using the auth_to_local option, the user name used for SSH access must meet the following criteria:
  • The user name must have the format ad_user@ad_domain.
  • The domain name must be lowercase.
  • The case of the user name must match the case of the user name in Active Directory. For example, user and User are considered different users because of the different cases.
For more information about setting auth_to_local, see the krb5.conf(5) man page.
Configuring .k5login
The following procedure configures the system to find the Kerberos principal name for a local user name.
  1. Create the .k5login file in the user's home directory.
  2. List the Kerberos principals used by the user in the file.
If the authenticating user matches the principal in an existing Kerberos ticket, the user is allowed to log in using the ticket and is not prompted for a password.
Note that if you configure Kerberos authentication using the .k5login configuration, the user name used for SSH access must have the format ad_user@ad_domain.
For more information about configuring the .k5login file, see the .k5login(5) man page.
Either one of these configuration procedures results in AD users being able to log in using Kerberos.

5.3.8. Using a Trust with Kerberos-enabled Web Applications

Any existing web application can be configured to use Kerberos authentication, which references the trusted Active Directory and IdM Kerberos realms. For the full Kerberos configuration directives, see the Configuration page for the mod_auth_kerb module.

Note

After changing the Apache application configuration, restart the Apache service: 
[root@ipaserver ~]# systemctl restart httpd.service
For example, for an Apache server, there are several options that define how the Apache server connects to the IdM Kerberos realm:
KrbAuthRealms
The KrbAuthRealms option gives the application location to the name of the IdM domain. This is required.
Krb5Keytab
The Krb5Keytab option gives the location for the IdM server keytab. This is required.
KrbServiceName
The KrbServiceName option sets the Kerberos service name used for the keytab (HTTP). This is recommended.
KrbMethodK5Passwd and KrbMethodNegotiate
The KrbMethodK5Passwd Kerberos method option enables password-based authentication for valid users. The KrbMethodNegotiate option enables single sign-on (SSO) if a valid Kerberos ticket is available.
These options are recommended for ease of use for many users.
KrbLocalUserMapping
The KrbLocalUserMapping option enables normal web logins (which are usually the UID or common name of the account) to be mapped to the fully-qualified user name (which has a format of user@REALM.COM).
This option is strongly recommended. Without the domain name/login name mapping, the web login appears to be a different user account than the domain user. This means that users cannot see their expected data.
For information on supported user name formats, see Section 5.2.1.9, “Supported User Name Formats”.

Example 5.1. Kerberos Configuration in an Apache Web Application

<Location "/mywebapp">
   AuthType Kerberos
   AuthName "IPA Kerberos authentication"
   KrbMethodNegotiate on
   KrbMethodK5Passwd on
   KrbServiceName HTTP
   KrbAuthRealms IDM_DOMAIN
   Krb5Keytab /etc/httpd/conf/ipa.keytab
   KrbLocalUserMapping on
   KrbSaveCredentials off
   Require valid-user
</Location>

5.3.9. Configuring an IdM server as a Kerberos Distribution Center Proxy for Active Directory Kerberos communication

In certain situations, network restrictions or firewall rules prevent Identity Management (IdM) clients from sending Kerberos traffic to port 88 on Active Directory (AD) domain controllers. The solution is to set up a Kerberos proxy, for instance on an Identity Management server, to relay traffic from IdM clients to AD.
  1. On IdM clients, add the Active Directory realm to the [realms] section of the /etc/krb5.conf file. Set the kdc and kpasswd_server parameters to point to the IdM server's fully qualified domain name followed by /KdcProxy': 
    AD.EXAMPLE.COM = {
	        kdc = https://server.idm.example.com/KdcProxy
	        kpasswd_server = https://server.idm.example.com/KdcProxy
	    }
  2. On IdM clients, disable the creation of /var/lib/sss/pubconf/kdcinfo.* files which could override the /etc/krb5.conf specifications from the previous step. Edit the /etc/sssd/sssd.conf file, setting the krb5_use_kdcinfo to False: 
    [domain/example.com]
krb5_use_kdcinfo = False
  3. On IdM servers, set the use_dns option to true in the /etc/ipa/kdcproxy/kdcproxy.conf file to utilize DNS service (SRV) records to find AD servers to communicate with: 
    use_dns = true
    Alternatively, if you do not want to use DNS SRV records, add explicit AD servers to the [realms] section of the /etc/krb5.conf file: 
    AD.EXAMPLE.COM = {
        kdc = ad-server.ad.example.com
        kpasswd_server = ad-server.ad.example.com
    }

    Note

    You can perform steps 2 and 3 of the procedure by running a script, for example an Ansible script. This is especially useful when making changes on multiple systems.
  4. On IdM servers, restart IPA services: 
    # ipactl restart
  5. To verify that the procedure has been successful, run the following on an IdM client: 
    # rm /var/lib/sss/pubconf/kdcinfo*
# kinit ad_user@AD.EXAMPLE.COM
Password for ad_user@AD.EXAMPLE.COM:
# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: ad_user@AD.EXAMPLE.COM

Valid starting     Expires            Service principal
[... output truncated ...]
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.