Installing trust between IdM and AD

Procedure

1. Log in to the IdM Web UI with administrator privileges.
2. Click the Network Services tab.
3. Click the DNS tab.

4. In the drop down menu, click DNS Forward Zones.

   

5. Click the Add button.
6. In the Add DNS forward zone dialog box, add a zone name.
7. In the Zone forwarders item, click the Add button.
8. In the Zone forwarders field, add the IP address of the server for which you want to create the forward zone.

9. Click the Add button.

   

   The forwarded zone has been added to the DNS settings and you can verify it in the DNS Forward Zones settings. The Web UI informs you about success with the following pop-up message: DNS Forward Zone successfully added.

   Note

   After adding a forward zone to the configuration, the Web UI might display a warning about a DNSSEC validation failure.

   

   DNSSEC (Domain Name System Security Extensions) secures DNS data with a digital signature to protect DNS from attacks. This service is enabled by default in the IdM server. The warning appears because the remote DNS server does not use DNSSEC. Enable DNSSEC on the remote DNS server.

   If you cannot enable DNSSEC validation on the remote server, you can disable DNSSEC in the IdM server:

   1. Open the /etc/named/ipa-options-ext.conf file on your IdM server.

   2. Add the following DNSSEC parameters:

      dnssec-validation no;

   3. Save and close the configuration file.

   4. Restart the DNS service:

      # systemctl restart named

   Note that DNSSEC is only available as Technology Preview in IdM.

Procedure

1. Log in to the Windows Server.
2. Open Server Manager.
3. Open DNS Manager.

4. In Conditional Forwarders, add a new forwarder and enter:

   • DNS Domain: The fully qualified domain name, for example, server.idm.example.com
   • IP Address: The IP address of the IdM DNS server.
5. Save the settings.

Procedure

1. Run a DNS query for the Kerberos over UDP and LDAP over TCP service records.

   [admin@server ~]# dig +short -t SRV _kerberos._udp.idm.example.com.

   0 100 88 server.idm.example.com.

   [admin@server ~]# dig +short -t SRV _ldap._tcp.idm.example.com.

   0 100 389 server.idm.example.com.

   The commands return the SRV records for the IdM servers.

2. Run a DNS query for the TXT record with the IdM Kerberos realm name. The returned value should match the Kerberos realm you specified when installing IdM.

   [admin@server ~]# dig +short -t TXT _kerberos.idm.example.com.

   "IDM.EXAMPLE.COM"

   If the previous steps did not return all the expected records, update the DNS configuration with the missing records:

   • If your IdM environment uses an integrated DNS server, enter the ipa dns-update-system-records command without any options to update your system records:

     [admin@server ~]$ ipa dns-update-system-records

   • If your IdM environment does not use an integrated DNS server:

     1. On the IdM server, export the IdM DNS records into a file:

        [admin@server ~]$ ipa dns-update-system-records --dry-run --out dns_records_file.nsupdate

        The command creates a file named dns_records_file.nsupdate with the relevant IdM DNS records.

     2. Submit a DNS update request to your DNS server using the nsupdate utility and the dns_records_file.nsupdate file. For more information, see Updating External DNS Records Using nsupdate in RHEL 7 documentation. Alternatively, refer to your DNS server documentation for adding DNS records.

3. Verify that IdM is able to resolve service records for AD with a command that runs a DNS query for Kerberos and LDAP over TCP service records:

   [admin@server ~]# dig +short -t SRV _kerberos._tcp.dc._msdcs.ad.example.com.

   0 100 88 addc1.ad.example.com.

   [admin@server ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.ad.example.com.

   0 100 389 addc1.ad.example.com.

Procedure

1. Install the IdM client with the --domain=IPA_DNS_Domain option to ensure the System Security Services Daemon (SSSD) can communicate with the IdM servers:

   [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. Open the /etc/krb5.conf configuration file and locate the existing mapping for the Active Directory domain in the [domain_realm] section.

   .ad.example.com = IDM.EXAMPLE.COM
   ad.example.com = IDM.EXAMPLE.COM

3. Replace both lines with an entry mapping the fully qualified domain name (FQDN) of the Linux clients in the Active Directory DNS zone to the IdM realm:

   idm-client.ad.example.com = IDM.EXAMPLE.COM

   By replacing the default mapping, you prevent 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.

Procedure

1. Configure Kerberos by editing the /etc/krb5.conf file on the IdM client. In the [libdefaults] section, set ignore_acceptor_hostname to true. This allows the application to accept any host-based principal in its keytab:

   ignore_acceptor_hostname = true

2. Ensure a CNAME record exists in the Active Directory DNS, for example idm-client.ad.example.com, pointing to the IdM client’s A/AAAA record in the IdM DNS domain.

Procedure

1. On the IdM server, create a host entry for the AD-side alias. Use --force because the name resolves to a CNAME rather than an A/AAAA record.

   [root@idm-server.idm.example.com ~]# ipa host-add idm-client.ad.example.com --force

2. To allow the physical IdM host to manage the new alias entry in the IdM database, grant management permissions to the host.

   [root@idm-server.idm.example.com ~]# ipa host-add-managedby idm-client.ad.example.com \
         --hosts=idm-client.idm.example.com

3. On the IdM client, use ipa-getcert to request the certificate. Ensure that you include both the FQDN and the CNAME using the -D flags.

   [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

   In SSL/TLS, the client checks the Subject Alternative Name (SAN) field. By using -D twice, you are populating that SAN field with both names so that no matter which URL the user hits, the certificate remains valid.

Procedure

1. Install the required packages:

   [root@ipaserver ~]# dnf install ipa-server-trust-ad samba-client

2. Authenticate as the IdM administrative user:

   [root@ipaserver ~]# kinit admin

3. Run the ipa-adtrust-install utility:

   [root@ipaserver ~]# ipa-adtrust-install

   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.

4. The script prompts you that the /etc/samba/smb.conf already exists and will be rewritten:

   WARNING: The smb.conf already exists. Running ipa-adtrust-install will break your existing Samba configuration.
   
   Do you wish to continue? [no]: yes

5. 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:

   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

6. You are prompted to run the SID generation task to create a SID for any existing users:

   Do you want to run the ipa-sidgen task? [no]: yes

   This is a resource-intensive task, so if you have a high number of users, you can run this at another time.

7. 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.

   [root@ipaserver ~]# net conf setparm global 'rpc server dynamic port range' 55000-65000
   [root@ipaserver ~]# firewall-cmd --add-port=55000-65000/tcp
   [root@ipaserver ~]# firewall-cmd --runtime-to-permanent

8. 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.

9. Restart the ipa service:

   [root@ipaserver ~]# ipactl restart

10. Use the smbclient utility to verify that Samba responds to Kerberos authentication from the IdM side:

    [root@ipaserver ~]# smbclient -L ipaserver.idm.example.com -U user_name --use-kerberos=required

    lp_load_ex: changing to config backend registry
        Sharename       Type      Comment
        ---------       ----      -------
        IPC$            IPC       IPC Service (Samba 4.15.2)
    ...

Procedure

1. In the IdM Web UI, click the IPA Server tab.
2. In the IPA Server tab, click the Trusts tab.

3. In the drop down menu, select the Trusts option.

   

4. Click the Add button.
5. In the Add Trust dialog box, enter the name of the Active Directory domain.

6. In the Account and Password fields, add the administrator credentials of the Active Directory administrator.

   

7. 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.
8. 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.

9. 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:

   1. 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.

   2. 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.

10. Click Add.

Procedure

1. Navigate to your ~/MyPlaybooks/ directory:

   $ cd ~/MyPlaybooks/

2. 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:

     ---
     - 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

     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:

     ---
     - 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

   • 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:

     ---
     - 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

   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.

3. Save the file.

   For details about variables and example playbooks in the FreeIPA Ansible collection, see the /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README-trust.md file and the /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/trust directory on the control node.

4. Run the Ansible playbook. Specify the playbook file, the file storing the password protecting the secret.yml file, and the inventory file:

   $ ansible-playbook --vault-password-file=password_file -v -i inventory add-trust.yml

Procedure

1. Request a ticket for an Active Directory (AD) user:

   [root@ipaserver ~]# kinit user@AD.EXAMPLE.COM

2. Request service tickets for a service within the IdM domain:

   [root@server ~]# kvno -S host server.idm.example.com

   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.

   [root@server ]# 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

   The localauth plug-in maps Kerberos principals to local SSSD user names. This allows AD users to use Kerberos authentication and access Linux services, which support GSSAPI authentication directly.

Procedure

1. Run a DNS query for the MS DC Kerberos over UDP and LDAP over TCP service records.

   [root@server ~]# dig +short -t SRV _kerberos._udp.dc._msdcs.idm.example.com.

   0 100 88 server.idm.example.com.

   [root@server ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.idm.example.com.

   0 100 389 server.idm.example.com.

   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.

2. 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:

   [root@server ~]# dig +short -t SRV _kerberos._tcp.dc._msdcs.ad.example.com.

   0 100 88 addc1.ad.example.com.

   [root@ipaserver ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.ad.example.com.

   0 100 389 addc1.ad.example.com.

Procedure

1. On the AD server, set the nslookup.exe utility to look up service records.

   C:\>nslookup.exe
   > set type=SRV

2. Enter the domain name for the Kerberos over UDP and LDAP over TCP service records.

   > _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

3. Change the service type to TXT and run a DNS query for the TXT record with the IdM Kerberos realm name.

   C:\>nslookup.exe
   > set type=TXT
   > _kerberos.idm.example.com.
   _kerberos.idm.example.com.        text =
   
       "IDM.EXAMPLE.COM"

4. Run a DNS query for the MS DC Kerberos over UDP and LDAP over TCP service records.

   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

   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.

5. Verify that AD services are resolvable from the AD server.

   C:\>nslookup.exe
   > set type=SRV

6. Enter the domain name for the Kerberos over UDP and LDAP over TCP service records.

   > _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

Procedure

1. On an existing trust controller, run the ipa-adtrust-install --add-agents command:

   [root@existing_trust_controller]# ipa-adtrust-install --add-agents

   The command starts an interactive configuration session and prompts you for the information required to set up the agent.

2. Restart the IdM service on the trust agent.

   [root@new_trust_agent]# ipactl restart

3. Remove all entries from the SSSD cache on the trust agent:

   [root@new_trust_agent]# sssctl cache-remove

4. Verify that the replica has the AD trust agent role installed:.

   [root@existing_trust_controller]# ipa server-show new_replica.idm.example.com

   Enabled server roles: CA server, NTP server, AD trust agent

Procedure

1. Display all ID ranges and make note of the AD ID range you want to modify.

   [root@server ~]# 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
   ----------------------------

2. Adjust the automatic private group behavior for the AD ID range with the ipa idrange-mod command.

   [root@server ~]# ipa idrange-mod --auto-private-groups=hybrid AD.EXAMPLE.COM_id_range

3. Reset the SSSD cache to enable the new setting.

   [root@server ~]# sss_cache -E

Procedure

1. Log into the IdM Web UI with your user name and password.
2. Open the IPA Server → ID Ranges tab.
3. Select the ID range you want to modify, such as AD.EXAMPLE.COM_id_range.

4. From the Auto private groups drop down menu, select the hybrid option.

   

5. Click the Save button to save your changes.

4. Create a separate trust object for each trust direction. Each of the objects get created on both sides (IdM and AD). If you are establishing a one-way trust, only one object is created on each side.

5. The IdM server uses the Samba suite to handle domain controller capabilities for Active Directory and creates a trust object on the target AD PDC:

   1. The IdM server establishes a secure connection to the IPC$ share on the target DC. Since RHEL 8.4, the connection requires at least the SMB3 protocol with Windows Server 2012 and above to ensure the connection is sufficiently secure with AES-based encryption used for the session.
   2. The IdM server queries for the presence of the trusted domain object (TDO) using an LSA QueryTrustedDomainInfoByName call.

   3. If the TDO is already present, remove it with an LSA DeleteTrustedDomain call.

      Note

      This call fails if the AD user account used to establish the trust does not have full Enterprise Admin (EA) or Domain Admin (DA) privileges for the forest root, such as members of the Incoming Forest Trust Builders group. If the old TDO is not automatically removed, an AD Administrator must manually remove it from AD.

   4. The IdM server creates a new TDO with an LSA CreateTrustedDomainEx2 call. The TDO credentials are randomly generated using a Samba-provided password generator with 128 random characters.

   5. The new TDO is then modified with an LSA SetInformationTrustedDomain call to make sure encryption types supported by the trust are set properly:

      1. The RC4_HMAC_MD5 encryption type is enabled, even if there are no RC4 keys in use, due to how Active Directory is designed.
      2. AES128_CTS_HMAC_SHA1_96 and AES256_CTS_HMAC_SHA1_96 encryption types are enabled.
6. For a forest trust, verify that in-forest domains can be reached transitively with an LSA SetInformationTrustedDomain call.

7. Add trust topology information about the other forest (IdM in the case of communicating with AD, AD in the case of communicating with IdM) using an LSA RSetForestTrustInformation call.

   Note

   This step might cause a conflict for one of three reasons:

   • A SID namespace conflict, reported as an LSA_SID_DISABLED_CONFLICT error. This conflict cannot be resolved.
   • A NetBIOS namespace conflict, reported as an LSA_NB_DISABLED_CONFLICT error. This conflict cannot be resolved.
   • A DNS namespace conflict with a top level name (TLN), reported as an LSA_TLN_DISABLED_CONFLICT error. The IdM server can automatically resolve a TLN conflict if it is caused by another forest.

   To resolve a TLN conflict, the IdM server performs the following steps:

   1. Retrieve forest trust information for the conflicting forest.
   2. Add an exclusion entry for the IdM DNS namespace to the AD forest.
   3. Set forest trust information for the forest we conflict on.
   4. Re-try establishing the trust to the original forest.

   The IdM server can only resolve these conflicts if you authenticated the ipa trust-add command with the privileges of an AD administrator that can change forest trusts. If you do not have access to those privileges, the administrator of the original forest must manually perform the steps above in the Active Directory Domains and Trusts section of the Windows UI.

8. If it does not exist, create the ID range for the trusted domain.
9. For a forest trust, query Active Directory domain controllers from the forest root for details about the forest topology. The IdM server uses this information to create additional ID ranges for any additional domains from the trusted forest.

Procedure

1. To enable debugging for the IdM server, create the file /etc/ipa/server.conf with the following contents.

   [global]
   debug=True

2. Restart the httpd service to load the debugging configuration.

   [root@trust_controller ~]# systemctl restart httpd

3. Stop the smb and winbind services.

   [root@trust_controller ~]# systemctl stop smb winbind

4. Set the debugging log level for the smb and winbind services.

   [root@trust_controller ~]# net conf setparm global 'log level' 100

5. To enable debug logging for Samba client code used by the IdM framework, edit the /usr/share/ipa/smb.conf.empty configuration file to have the following contents.

       [global]
       log level = 100

6. Remove previous Samba logs.

   [root@trust_controller ~]# rm /var/log/samba/log.*

7. Start the smb and winbind services.

   [root@trust_controller ~]# systemctl start smb winbind

8. Print a timestamp as you attempt to establish a trust with verbose mode enabled.

   [root@trust_controller ~]# date; ipa -vvv trust-add --type=ad ad.example.com

9. Review the following error log files for information about the failed request:

   1. /var/log/httpd/error_log
   2. /var/log/samba/log.*

10. Disable debugging.

    [root@trust_controller ~]# mv /etc/ipa/server.conf /etc/ipa/server.conf.backup
    [root@trust_controller ~]# systemctl restart httpd
    [root@trust_controller ~]# systemctl stop smb winbind
    [root@trust_controller ~]# net conf setparm global 'log level' 0
    [root@trust_controller ~]# mv /usr/share/ipa/smb.conf.empty /usr/share/ipa/smb.conf.empty.backup
    [root@trust_controller ~]# systemctl start smb winbind

11. Optional: If you are unable to determine the cause of the authentication issue:

    1. Collect and archive the log files you recently generated.

       [root@trust_controller ~]# tar -cvf debugging-trust.tar /var/log/httpd/error_log /var/log/samba/log.*

    2. Open a Red Hat Technical Support case and provide the timestamp and debug logs from the attempt.

1. The AD client contacts the AD Kerberos Distribution Center (KDC) to perform a TGS Request for the service in the IdM domain.
2. The AD KDC recognizes that the service belongs to the trusted IdM domain.
3. The AD KDC sends the client a cross-realm ticket-granting ticket (TGT), along with a referral to the trusted IdM KDC.
4. The AD client uses the cross-realm TGT to request a ticket to the IdM KDC.
5. The IdM KDC validates the Privileged Attribute Certificate (MS-PAC) that is transmitted with the cross-realm TGT.
6. The IPA-KDB plugin might check the LDAP directory to see if foreign principals are allowed to get tickets for the requested service.
7. The IPA-KDB plugin decodes the MS-PAC, verifies, and filters the data. It performs lookups in the LDAP server to check if it needs to augment the MS-PAC with additional information, such as local groups.
8. The IPA-KDB plugin then encodes the PAC, signs it, attaches it to the service ticket, and sends it to the AD client.
9. The AD client can now contact the IdM service using the service ticket issued by IdM KDC.

1. The AD client contacts the AD Kerberos Distribution Center (KDC) in its own domain to perform a TGS Request for the service in the IdM domain.
2. The AD KDC in child.ad.example.com, the child domain, recognizes that the service belongs to the trusted IdM domain.
3. The AD KDC in the child domain sends the client a referral ticket for the AD forest root domain ad.example.com.
4. The AD client contacts the KDC in the AD forest root domain for the service in the IdM domain.
5. The KDC in the forest root domain recognizes that the service belongs to the trusted IdM domain.
6. The AD KDC sends the client a cross-realm ticket-granting ticket (TGT), along with a referral to the trusted IdM KDC.
7. The AD client uses the cross-realm TGT to request a ticket to the IdM KDC.
8. The IdM KDC validates the Privileged Attribute Certificate (MS-PAC) that is transmitted with the cross-realm TGT.
9. The IPA-KDB plugin might check the LDAP directory to see if foreign principals are allowed to get tickets for the requested service.
10. The IPA-KDB plugin decodes the MS-PAC, verifies, and filters the data. It performs lookups in the LDAP server to check if it needs to augment the MS-PAC with additional information, such as local groups.
11. The IPA-KDB plugin then encodes the PAC, signs it, attaches it to the service ticket, and sends it to the AD client.
12. The AD client can now contact the IdM service using the service ticket issued by IdM KDC.

1. The IdM client requests a ticket-granting ticket (TGT) from the IdM Kerberos Distribution Center (KDC) for the AD service it wants to contact.
2. The IdM KDC recognizes that the service belongs to the AD realm, verifies that the realm is known and trusted, and that the client is allowed to request services from that realm.
3. Using information from the IdM Directory Server about the user principal, the IdM KDC creates a cross-realm TGT with a Privileged Attribute Certificate (MS-PAC) record about the user principal.
4. The IdM KDC sends back a cross-realm TGT to the IdM client.
5. The IdM client contacts the AD KDC to request a ticket for the AD service, presenting the cross-realm TGT that contains the MS-PAC provided by the IdM KDC.
6. The AD server validates and filters the PAC, and returns a ticket for the AD service.
7. The IPA client can now contact the AD service.