Ce contenu n'est pas disponible dans la langue sélectionnée.
5.3. Managing and Configuring a Cross-forest Trust Environment
5.3.1. User Principal Names in a Trusted Domains Environment
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.
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.
Active Directory Domain and Trust
utility or the PowerShell
command line tool.
Note
Active Directory Domain and Trust
utility.
ldapmodify
commands to set the userPrincipalName
attribute for users, because Active Directory does not validate those operations.
[root@ipaserver ~]# ipa trust-fetch-domains Realm-Name: ad.example.com ------------------------------- No new trust domains were found ------------------------------- ---------------------------- Number of entries returned 0 ----------------------------
[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
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
Important
5.3.2.1. Kerberos Single Sign-on to the IdM Client is not Required
- 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. - 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 hostidm-client.ad.example.com
the IdM KDC is set.
Note
Handling of SSL certificates
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
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
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.
[libdefaults]
section of the /etc/krb5.conf
configuration file:
ignore_acceptor_hostname = true
Handling of SSL certificates
certmonger
can request a certificate for this name:
- 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. - 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
[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
Note
- 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.
- Create an external group in the IdM domain for the Active Directory users by adding the
--external
option to theipa 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 inmember
attributes of a group, and IdM uses this attribute to resolve the members. However, Active Directory stores the primary group of users in theprimaryGroupID
attribute in the user's entry, which is not resolved. - 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
- 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
orDOMAIN\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 -------------------------
- 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
5.3.4.1. Editing the Global Trust Configuration
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.
- 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
cn=domain,cn=ad,cn=etc,dc=example,dc=com
subtree.
5.3.4.1.1. Changing the NetBIOS Name
Important
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
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.
ipa trustconfig-mod
command:
[root@server ~]# kinit admin [root@server ~]# ipa trustconfig-mod --fallback-primary-group="Example Windows Group"
- Open the IdM web UI.
https://ipaserver.example.com
- Under the IPA Server main tab, select the Trusts subtab, and then open the Global Configuration section.
- Select a new group from all of the IdM groups in thedrop-down list.
Figure 5.6. Configuring the Default Group for Windows Users
- Clickto save the new configuration.
5.3.4.2. Discovering, Enabling, and Disabling Trust Domains
cn=subdomain,cn=trust_name,cn=ad,cn=trusts,dc=example,dc=com
in the trusts subtree.
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
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.
[root@ipaserver ~]# kinit admin [root@ipaserver ~]# ipa trustdomain-disable test.ad.example.com ------------------------------------------ Disabled trust domain "test.ad.example.com" ------------------------------------------
trustdomain-enable
command.
[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
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
- A domain is automatically added to the domains list after a new DNS zone is added to IdM using the
ipa dnszone-add
command. Runningipa 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.
- 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
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
[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
5.3.4.5. Adjusting DNA ID ranges manually
ipa idrange-find
command. If the newly adjusted range is not included in the IdM ID range, the command fails.
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
ipa-replica-manage dnarange-set
command:
# ipa-replica-manage dnarange-set masterA.example.com 1250-1499
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
OK_AS_DELEGATE
is required.
5.3.5. Setting PAC Types for Services
5.3.5.1. Setting Default PAC Types
- Open the IPA Server tab.
- Select the Configuration subtab.
- Scroll to the Service Options area.
Figure 5.7. The Service Options Area
- 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. - Click the Update link at the top of the page to save the changes.
5.3.5.2. Setting PAC Types for a Service
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 ...
- Open the Identity tab, and select the Services subtab.
- Click the name of the service to edit.
- 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.
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. - 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
5.3.6.2. Transferring Login Shell and Home Directory Attributes
Important
- the
loginShell
attribute, which specifies the AD user's shell - the
unixHomeDirectory
attribute, which specifies the AD user's home directory
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
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
5.3.7.1. Caching Considerations
- 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
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.
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.
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
localauth
Kerberos plug-in.
user@AD.DOMAIN
, ad.domain\user
and AD\user
.
Note
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
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.
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.
- Open the
/etc/krb5.conf
file. - In the
[realms]
section, identify the IdM realm by name, and then add twoauth_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 }
- Restart the KDC service.
[root@server ~]# systemctl restart krb5kdc.service
Note that if you configure Kerberos authentication using theauth_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
andUser
are considered different users because of the different cases.
For more information about settingauth_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.
- Create the
.k5login
file in the user's home directory. - 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 formatad_user@ad_domain
.For more information about configuring the.k5login
file, see the .k5login(5) man page.
5.3.8. Using a Trust with Kerberos-enabled Web Applications
Note
[root@ipaserver ~]# systemctl restart httpd.service
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
andKrbMethodNegotiate
- The
KrbMethodK5Passwd
Kerberos method option enables password-based authentication for valid users. TheKrbMethodNegotiate
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 HTTPKrbAuthRealms 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
- On IdM clients, add the Active Directory realm to the [realms] section of the
/etc/krb5.conf
file. Set thekdc
andkpasswd_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 }
- 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 thekrb5_use_kdcinfo
toFalse
:[domain/example.com] krb5_use_kdcinfo = False
- On IdM servers, set the
use_dns
option totrue
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. - On IdM servers, restart IPA services:
# ipactl restart
- 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 ...]