Chapter 9. Setting up a trust You can configure the Identity Management (IdM)/Active Directory (AD) trust on the IdM side using the command line. Prerequisites DNS is correctly configured. Both IdM and AD servers must be able to resolve each other names. For details, see Configuring DNS and realm settings for a trust . Supported versions of AD and IdM are deployed. For details, see Supported versions of Windows Server . You have obtained a Kerberos ticket. For details, see Using kinit to log in to IdM manually . 9.1. Preparing the IdM server for the trust Before you can establish a trust with AD, you must prepare the IdM domain using the ipa-adtrust-install utility on an IdM server. Note Any system where you run the ipa-adtrust-install command automatically becomes an AD trust controller. However, you must run ipa-adtrust-install only once on an IdM server. Prerequisites IdM server is installed. You have root privileges to install packages and restart IdM services. Procedure Install the required packages: Authenticate as the IdM administrative user: Run the ipa-adtrust-install utility: The DNS service records are created automatically if IdM was installed with an integrated DNS server. If you installed IdM without an integrated DNS server, ipa-adtrust-install prints a list of service records that you must manually add to DNS before you can continue. The script prompts you that the /etc/samba/smb.conf already exists and will be rewritten: The script prompts you to configure the slapi-nis plug-in, a compatibility plug-in that allows older Linux clients to work with trusted users: You are prompted to run the SID generation task to create a SID for any existing users: This is a resource-intensive task, so if you have a high number of users, you can run this at another time. Optional: By default, the Dynamic RPC port range is defined as 49152-65535 for Windows Server 2008 and later. If you need to define a different Dynamic RPC port range for your environment, configure Samba to use different ports and open those ports in your firewall settings. The following example sets the port range to 55000-65000 . Make sure that DNS is properly configured, as described in Verifying the DNS configuration for a trust . Important Red Hat strongly recommends you verify the DNS configuration as described in Verifying the DNS configuration for a trust every time after running ipa-adtrust-install , especially if IdM or AD do not use integrated DNS servers. Restart the ipa service: Use the smbclient utility to verify that Samba responds to Kerberos authentication from the IdM side: 9.2. Setting up a trust agreement using the command line You can set up the trust agreement using the command line. The Identity Management (IdM) server allows you to configure three types of trust agreements: One-way trust - default option. One-way trust enables Active Directory (AD) users and groups to access resources in IdM, but not the other way around. The IdM domain trusts the AD forest, but the AD forest does not trust the IdM domain. Two-way trust - Two-way trust enables AD users and groups to access resources in IdM. You must configure a two-way trust for solutions such as Microsoft SQL Server that expect the S4U2Self and S4U2Proxy Microsoft extensions to the Kerberos protocol to work over a trust boundary. An application on a RHEL IdM host might request S4U2Self or S4U2Proxy information from an Active Directory domain controller about an AD user, and a two-way trust provides this feature. Note that this two-way trust functionality does not allow IdM users to login to Windows systems, and the two-way trust in IdM does not give the users any additional rights compared to the one-way trust solution in AD. To create the two-way trust, add the following option to the command: --two-way=true External trust - a trust relationship between IdM and an AD domain in different forests. While a forest trust always requires establishing a trust between IdM and the root domain of an Active Directory forest, an external trust can be established from IdM to a domain within a forest. This is only recommended if it is not possible to establish a forest trust between forest root domains due to administrative or organizational reasons. To create the external trust, add the following option to the command: --external=true The steps below show you how to create a one-way trust agreement. Prerequisites User name and password of a Windows administrator. You have prepared the IdM server for the trust . Procedure Create a trust agreement for the AD domain and the IdM domain by using the ipa trust-add command: To have SSSD automatically generate UIDs and GIDs for AD users based on their SID, create a trust agreement with the Active Directory domain ID range type. This is the most common configuration. If you have configured POSIX attributes for your users in Active Directory (such as uidNumber and gidNumber ) and you want SSSD to process this information, create a trust agreement with the Active Directory domain with POSIX attributes ID range type: Warning If you do not specify an ID Range type when creating a trust, IdM attempts to automatically select the appropriate range type by requesting details from AD domain controllers in the forest root domain. If IdM does not detect any POSIX attributes, the trust installation script selects the Active Directory domain ID range. If IdM detects any POSIX attributes in the forest root domain, the trust installation script selects the Active Directory domain with POSIX attributes ID range and assumes that UIDs and GIDs are correctly defined in AD. If POSIX attributes are not correctly set in AD, you will not be able to resolve AD users. For example, if the users and groups that need access to IdM systems are not part of the forest root domain, but instead are located in a child domain of the forest domain, the installation script might not detect the POSIX attributes defined in the child AD domain. In this case, explicitly choose the POSIX ID range type when establishing the trust. 9.3. Setting up a trust agreement in the IdM Web UI You can configure the Identity Management (IdM)/Active Directory (AD) trust agreement on the IdM side using the IdM Web UI. Prerequisites DNS is correctly configured. Both IdM and AD servers must be able to resolve each other names. Supported versions of AD and IdM are deployed. You have obtained a Kerberos ticket. Before creating a trust in the Web UI, prepare the IdM server for the trust as described in: Preparing the IdM server for the trust . You are logged in as an IdM administrator. For details, see Accessing the IdM Web UI in a web browser . Procedure In the IdM Web UI, click the IPA Server tab. In the IPA Server tab, click the Trusts tab. In the drop down menu, select the Trusts option. Click the Add button. In the Add Trust dialog box, enter the name of the Active Directory domain. In the Account and Password fields, add the administrator credentials of the Active Directory administrator. Optional: Select Two-way trust , if you want to enable AD users and groups to access resources in IdM. However, the two-way trust in IdM does not give the users any additional rights compared to the one-way trust solution in AD. Both solutions are considered equally secure because of default cross-forest trust SID filtering settings. Optional: Select External trust if you are configuring a trust with an AD domain that is not the root domain of an AD forest. While a forest trust always requires establishing a trust between IdM and the root domain of an Active Directory forest, you can establish an external trust from IdM to any domain within an AD forest. Optional: By default, the trust installation script tries to detect the appropriate ID range type. You can also explicitly set the ID range type by choosing one of the following options: To have SSSD automatically generate UIDs and GIDs for AD users based on their SID, select the Active Directory domain ID range type. This is the most common configuration. If you have configured POSIX attributes for your users in Active Directory (such as uidNumber and gidNumber ) and you want SSSD to process this information, select the Active Directory domain with POSIX attributes ID range type. Warning If you leave the Range type setting on the default Detect option, IdM attempts to automatically select the appropriate range type by requesting details from AD domain controllers in the forest root domain. If IdM does not detect any POSIX attributes, the trust installation script selects the Active Directory domain ID range. If IdM detects any POSIX attributes in the forest root domain, the trust installation script selects the Active Directory domain with POSIX attributes ID range and assumes that UIDs and GIDs are correctly defined in AD. If POSIX attributes are not correctly set in AD, you will not be able to resolve AD users. For example, if the users and groups that need access to IdM systems are not part of the forest root domain, but instead are located in a child domain of the forest domain, the installation script might not detect the POSIX attributes defined in the child AD domain. In this case, explicitly choose the POSIX ID range type when establishing the trust. Click Add . Verification If the trust has been successfully added to the IdM server, you can see the green pop-up window in the IdM Web UI. It means that the: Domain name exists User name and password of the Windows Server has been added correctly. Now you can continue to test the trust connection and Kerberos authentication. 9.4. Setting up a trust agreement using Ansible You can set up a one-way trust agreement between Identity Management (IdM) and Active Directory (AD) by using an Ansible playbook. You can configure three types of trust agreements: One-way trust - default option. One-way trust enables Active Directory (AD) users and groups to access resources in IdM, but not the other way around. The IdM domain trusts the AD forest, but the AD forest does not trust the IdM domain. Two-way trust - Two-way trust enables AD users and groups to access resources in IdM. You must configure a two-way trust for solutions such as Microsoft SQL Server that expect the S4U2Self and S4U2Proxy Microsoft extensions to the Kerberos protocol to work over a trust boundary. An application on a RHEL IdM host might request S4U2Self or S4U2Proxy information from an Active Directory domain controller about an AD user, and a two-way trust provides this feature. Note that this two-way trust functionality does not allow IdM users to login to Windows systems, and the two-way trust in IdM does not give the users any additional rights compared to the one-way trust solution in AD. To create the two-way trust, add the following variable to the playbook task below: two_way: true External trust - a trust relationship between IdM and an AD domain in different forests. While a forest trust always requires establishing a trust between IdM and the root domain of an Active Directory forest, an external trust can be established from IdM to a domain within a forest. This is only recommended if it is not possible to establish a forest trust between forest root domains due to administrative or organizational reasons. To create the external trust, add the following variable to the playbook task below: external: true Prerequisites User name and password of a Windows administrator. The IdM admin password. You have prepared the IdM server for the trust . You are using the 4.8.7 version of IdM or later. To view the version of IdM you have installed on your server, run ipa --version . You have configured your Ansible control node to meet the following requirements: You are using Ansible version 2.15 or later. You have installed the ansible-freeipa package. The example assumes that in the ~/ MyPlaybooks / directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server. The example assumes that the secret.yml Ansible vault stores your ipaadmin_password . The target node, that is the node on which the ansible-freeipa module is executed, is part of the IdM domain as an IdM client, server or replica. Procedure Navigate to your ~/ MyPlaybooks / directory: Select one of the following scenarios based on your use case: To create an ID mapping trust agreement, in which SSSD automatically generates UIDs and GIDs for AD users and groups based on their SIDs, create an add-trust.yml playbook with the following content: In the example: realm defines the AD realm name string. admin defines the AD domain administrator string. password defines the AD domain administrator's password string. To create a POSIX trust agreement, in which SSSD processes POSIX attributes stored in AD, such as uidNumber and gidNumber , create an add-trust.yml playbook with the following content: To create a trust agreement in which IdM attempts to automatically select the appropriate range type, ipa-ad-trust or ipa-ad-trust-posix , by requesting details from AD domain controllers in the forest root domain, create an add-trust.yml playbook with the following content: Warning If you do not specify an ID range type when creating a trust, and if IdM does not detect any POSIX attributes in the AD forest root domain, the trust installation script selects the Active Directory domain ID range. If IdM detects any POSIX attributes in the forest root domain, the trust installation script selects the Active Directory domain with POSIX attributes ID range and assumes that UIDs and GIDs are correctly defined in AD. However, if POSIX attributes are not correctly set in AD, you will not be able to resolve AD users. For example, if the users and groups that need access to IdM systems are not part of the forest root domain, but instead are located in a child domain of the forest domain, the installation script might not detect the POSIX attributes defined in the child AD domain. In this case, explicitly choose the POSIX ID range type when establishing the trust. Save the file. Run the Ansible playbook. Specify the playbook file, the file storing the password protecting the secret.yml file, and the inventory file: Additional resources /usr/share/doc/ansible-freeipa/README-trust.md /usr/share/doc/ansible-freeipa/playbooks/trust 9.5. Verifying the Kerberos configuration To verify the Kerberos configuration, test if it is possible to obtain a ticket for an Identity Management (IdM) user and if the IdM user can request service tickets. Procedure Request a ticket for an Active Directory (AD) user: Request service tickets for a service within the IdM domain: If the AD service ticket is successfully granted, there is a cross-realm ticket-granting ticket (TGT) listed with all of the other requested tickets. The TGT is named krbtgt/IPA.DOMAIN@AD.DOMAIN. The localauth plug-in maps Kerberos principals to local System Security Services Daemon (SSSD) user names. This allows AD users to use Kerberos authentication and access Linux services, which support GSSAPI authentication directly. 9.6. Verifying the trust configuration on IdM Before configuring trust, verify that the Identity Management (IdM) and Active Directory (AD) servers can resolve themselves and each other. Prerequisites You need to be logged in with administrator privileges. Procedure Run a DNS query for the MS DC Kerberos over UDP and LDAP over TCP service records. These commands list all IdM servers on which ipa-adtrust-install has been executed. The output is empty if ipa-adtrust-install has not been executed on any IdM server, which is typically before establishing the first trust relationship. Run a DNS query for the Kerberos and LDAP over TCP service records to verify that IdM is able to resolve service records for AD: 9.7. Verifying the trust configuration on AD After configuring the trust, verify that: The Identity Management (IdM)-hosted services are resolvable from the Active Directory (AD) server. AD services are resolvable from the AD server. Prerequisites You need to be logged in with administrator privileges. Procedure On the AD server, set the nslookup.exe utility to look up service records. Enter the domain name for the Kerberos over UDP and LDAP over TCP service records. Change the service type to TXT and run a DNS query for the TXT record with the IdM Kerberos realm name. Run a DNS query for the MS DC Kerberos over UDP and LDAP over TCP service records. Active Directory only expects to discover domain controllers that can respond to AD-specific protocol requests, such as other AD domain controllers and IdM trust controllers. Use the ipa-adtrust-install tool to promote an IdM server to a trust controller, and you can verify which servers are trust controllers with the ipa server-role-find --role 'AD trust controller' command. Verify that AD services are resolvable from the AD server. Enter the domain name for the Kerberos over UDP and LDAP over TCP service records. 9.8. Creating a trust agent A trust agent is an IdM server that can perform identity lookups against AD domain controllers. For example, if you are creating a replica of an IdM server that has a trust with Active Directory, you can set up the replica as a trust agent. A replica does not automatically have the AD trust agent role installed. Prerequisites IdM is installed with an Active Directory trust. The sssd-tools package is installed. Procedure On an existing trust controller, run the ipa-adtrust-install --add-agents command: The command starts an interactive configuration session and prompts you for the information required to set up the agent. Restart the IdM service on the trust agent. Remove all entries from the SSSD cache on the trust agent: Verify that the replica has the AD trust agent role installed:. Additional resources ipa-adtrust-install(1) man page on your system Trust controllers and trust agents 9.9. Enabling automatic private group mapping for a POSIX ID range on the CLI By default, SSSD does not map private groups for Active Directory (AD) users if you have established a POSIX trust that relies on POSIX data stored in AD. If any AD users do not have primary groups configured, IdM is not be able to resolve them. This procedure explains how to enable automatic private group mapping for an ID range by setting the hybrid option for the auto_private_groups SSSD parameter on the command line. As a result, IdM is able to resolve AD users that do not have primary groups configured in AD. Prerequisites You have successfully established a POSIX cross-forest trust between your IdM and AD environments. Procedure Display all ID ranges and make note of the AD ID range you want to modify. Adjust the automatic private group behavior for the AD ID range with the ipa idrange-mod command. Reset the SSSD cache to enable the new setting. Additional resources Options for automatically mapping private groups for AD users 9.10. Enabling automatic private group mapping for a POSIX ID range in the IdM WebUI By default, SSSD does not map private groups for Active Directory (AD) users if you have established a POSIX trust that relies on POSIX data stored in AD. If any AD users do not have primary groups configured, IdM is not be able to resolve them. This procedure explains how to enable automatic private group mapping for an ID range by setting the hybrid option for the auto_private_groups SSSD parameter in the Identity Management (IdM) WebUI. As a result, IdM is able to resolve AD users that do not have primary groups configured in AD. Prerequisites You have successfully established a POSIX cross-forest trust between your IdM and AD environments. Procedure Log into the IdM Web UI with your user name and password. Open the IPA Server ID Ranges tab. Select the ID range you want to modify, such as AD.EXAMPLE.COM_id_range . From the Auto private groups drop down menu, select the hybrid option. Click the Save button to save your changes. Additional resources Options for automatically mapping private groups for AD users

Commands:
dnf install ipa-server-trust-ad samba-client
kinit admin
ipa-adtrust-install
WARNING: The smb.conf already exists. Running ipa-adtrust-install will break your existing Samba configuration. Do you wish to continue? [no]: yes
Do you want to enable support for trusted domains in Schema Compatibility plugin? This will allow clients older than SSSD 1.9 and non-Linux clients to work with trusted users. Enable trusted domains support in slapi-nis? [no]: yes
Do you want to run the ipa-sidgen task? [no]: yes
net conf setparm global 'rpc server dynamic port range' 55000-65000 firewall-cmd --add-port=55000-65000/tcp firewall-cmd --runtime-to-permanent
ipactl restart
smbclient -L ipaserver.idm.example.com -U user_name --use-kerberos=required lp_load_ex: changing to config backend registry Sharename Type Comment --------- ---- ------- IPCUSD IPC IPC Service (Samba 4.15.2)
ipa trust-add --type=ad ad.example.com --admin <ad_admin_username> --password --range-type=ipa-ad-trust
ipa trust-add --type=ad ad.example.com --admin <ad_admin_username> --password --range-type=ipa-ad-trust-posix
cd ~/ MyPlaybooks /
--- - name: Playbook to create a trust hosts: ipaserver vars_files: - /home/user_name/MyPlaybooks/secret.yml tasks: - name: ensure the trust is present ipatrust: ipaadmin_password: "{{ ipaadmin_password }}" realm: ad.example.com admin: Administrator password: secret_password state: present
--- - name: Playbook to create a trust hosts: ipaserver vars_files: - /home/user_name/MyPlaybooks/secret.yml tasks: - name: ensure the trust is present ipatrust: ipaadmin_password: "{{ ipaadmin_password }}" realm: ad.example.com admin: Administrator password: secret_password range_type: ipa-ad-trust-posix state: present
--- - name: Playbook to create a trust hosts: ipaserver vars_files: - /home/user_name/MyPlaybooks/secret.yml tasks: - name: ensure the trust is present ipatrust: ipaadmin_password: "{{ ipaadmin_password }}" realm: ad.example.com admin: Administrator password: secret_password state: present
ansible-playbook --vault-password-file=password_file -v -i inventory add-trust.yml
kinit user@AD.EXAMPLE.COM
kvno -S host server.idm.example.com
klist Ticket cache: KEYRING:persistent:0:krb_ccache_hRtox00 Default principal: user@AD.EXAMPLE.COM Valid starting Expires Service principal 03.05.2016 18:31:06 04.05.2016 04:31:01 host/server.idm.example.com@IDM.EXAMPLE.COM renew until 04.05.2016 18:31:00 03.05.2016 18:31:06 04.05.2016 04:31:01 krbtgt/IDM.EXAMPLE.COM@AD.EXAMPLE.COM renew until 04.05.2016 18:31:00 03.05.2016 18:31:01 04.05.2016 04:31:01 krbtgt/AD.EXAMPLE.COM@AD.EXAMPLE.COM renew until 04.05.2016 18:31:00
dig +short -t SRV _kerberos._udp.dc._msdcs.idm.example.com. 0 100 88 server.idm.example.com. dig +short -t SRV _ldap._tcp.dc._msdcs.idm.example.com. 0 100 389 server.idm.example.com.
dig +short -t SRV _kerberos._tcp.dc._msdcs.ad.example.com. 0 100 88 addc1.ad.example.com. dig +short -t SRV _ldap._tcp.dc._msdcs.ad.example.com. 0 100 389 addc1.ad.example.com.
C:\>nslookup.exe > set type=SRV
> _kerberos._udp.idm.example.com. _kerberos._udp.idm.example.com. SRV service location: priority = 0 weight = 100 port = 88 svr hostname = server.idm.example.com > _ldap._tcp.idm.example.com _ldap._tcp.idm.example.com SRV service location: priority = 0 weight = 100 port = 389 svr hostname = server.idm.example.com
C:\>nslookup.exe > set type=TXT > _kerberos.idm.example.com. _kerberos.idm.example.com. text = "IDM.EXAMPLE.COM"
C:\>nslookup.exe > set type=SRV > _kerberos._udp.dc._msdcs.idm.example.com. _kerberos._udp.dc._msdcs.idm.example.com. SRV service location: priority = 0 weight = 100 port = 88 svr hostname = server.idm.example.com > _ldap._tcp.dc._msdcs.idm.example.com. _ldap._tcp.dc._msdcs.idm.example.com. SRV service location: priority = 0 weight = 100 port = 389 svr hostname = server.idm.example.com
C:\>nslookup.exe > set type=SRV
> _kerberos._udp.dc._msdcs.ad.example.com. _kerberos._udp.dc._msdcs.ad.example.com. SRV service location: priority = 0 weight = 100 port = 88 svr hostname = addc1.ad.example.com > _ldap._tcp.dc._msdcs.ad.example.com. _ldap._tcp.dc._msdcs.ad.example.com. SRV service location: priority = 0 weight = 100 port = 389 svr hostname = addc1.ad.example.com
ipa-adtrust-install --add-agents
ipactl restart
sssctl cache-remove
ipa server-show new_replica.idm.example.com Enabled server roles: CA server, NTP server, AD trust agent
ipa idrange-find ---------------- 2 ranges matched ---------------- Range name: IDM.EXAMPLE.COM_id_range First Posix ID of the range: 882200000 Number of IDs in the range: 200000 Range type: local domain range Range name: AD.EXAMPLE.COM_id_range First Posix ID of the range: 1337000000 Number of IDs in the range: 200000 Domain SID of the trusted domain: S-1-5-21-4123312420-990666102-3578675309 Range type: Active Directory trust range with POSIX attributes ---------------------------- Number of entries returned 2 ----------------------------
ipa idrange-mod --auto-private-groups=hybrid AD.EXAMPLE.COM_id_range
sss_cache -E