5.2. Creating Cross-forest Trusts 5.2.1. Environment and Machine Requirements Before configuring a trust agreement, make sure that both the Active Directory and Identity Management servers, machines, and environments meet the requirements and settings described in this section. 5.2.1.1. Supported Windows Platforms You can establish a trust relationship with Active Directory forests that use the following forest and domain functional levels: Forest functional level range: Windows Server 2008 - Windows Server 2016 Domain functional level range: Windows Server 2008 - Windows Server 2016 The following operating systems are supported and tested for establishing a trust using the mentioned functional levels: Windows Server 2012 R2 Windows Server 2016 versions of Windows Server are not supported for establishing a trust. 5.2.1.2. DNS and Realm Settings To establish a trust, Active Directory and Identity Management require specific DNS configuration: Unique primary DNS domains Each system must have its own unique primary DNS domain configured. For example: ad.example.com for AD and idm.example.com for IdM example.com for AD and idm.example.com for IdM ad.example.com for AD and example.com for IdM Important If the IdM domain is the parent domain of the AD domain, the IdM servers must run on Red Hat Enterprise Linux 7.5 or later. The most convenient management solution is an environment where each DNS domain is managed by integrated DNS servers, but it is possible to use any other standard-compliant DNS server as well. It is not possible for AD or IdM to share the primary DNS domain with another system for identity management. For more information, see documentation for host name and DNS configuration requirements in the Linux Domain Identity, Authentication, and Policy Guide . Kerberos realm names as upper-case versions of primary DNS domain names Kerberos realm names must be the same as the primary DNS domain names, with all letters uppercase. For example, if the domain names are ad.example.com for AD and idm.example.com for IdM, the Kerberos realm names are required to be AD.EXAMPLE.COM and IDM.EXAMPLE.COM . DNS records resolvable from all DNS domains in the trust All machines must be able to resolve DNS records from all DNS domains involved in the trust relationship: When configuring IdM DNS, follow the instructions described in the section on configuring DNS services within the IdM domain and section on managing DNS forwarding in the Linux Domain Identity, Authentication, and Policy Guide . If you are using IdM without integrated DNS, follow the instructions described in the section describing the server installation without integrated DNS in the Linux Domain Identity, Authentication, and Policy Guide . No overlap between IdM and AD DNS domains Systems joined to IdM can be distributed over multiple DNS domains. DNS domains containing IdM clients must not overlap with DNS domains containing machines joined to AD. The primary IdM DNS domain must have proper SRV records to support AD trusts. Note 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. 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. You can acquire a list of the required SRV records specific to your system setup by running the USD ipa dns-update-system-records --dry-run command. The generated list can look for example like this: For other DNS domains that are part of the same IdM realm, it is not required for the SRV records to be configured when the trust to AD is configured. The reason is that AD domain controllers do not use SRV records to discover KDCs but rather base the KDC discovery on name suffix routing information for the trust. Verifying the DNS Configuration Before configuring trust, verify that the Identity Management and Active Directory servers can resolve themselves and also each other. If running the commands described below does not display the expected results, inspect the DNS configuration on the host where the commands were executed. If the host configuration seems correct, make sure that DNS delegations from the parent to child domains are set up correctly. Note that AD caches the results of DNS lookups, and changes you make in DNS are therefore sometimes not visible immediately. You can delete the current cache by running the ipconfig /flushdns command. Verify that the IdM-hosted services are resolvable from the IdM domain server used for establishing trust Run a DNS query for the Kerberos over UDP and LDAP over TCP service records. The commands are expected to list all IdM servers. Run a DNS query for the TXT record with the IdM Kerberos realm name. The obtained value is expected to match the Kerberos realm that you specified when installing IdM. After you execute the ipa-adtrust-install utility, as described in Section 5.2.2.1.1, "Preparing the IdM Server for Trust" , run a DNS query for the MS DC Kerberos over UDP and LDAP over TCP service records. The commands are expected to list all IdM servers on which ipa-adtrust-install has been executed. Note that the output is empty if ipa-adtrust-install has not been executed on any IdM server, which is typically before establishing the very first trust relationship. Verify that IdM is able to resolve service records for AD Run a DNS query for the Kerberos over UDP and LDAP over TCP service records. These commands are expected to return the names of AD domain controllers. Verify that the IdM-hosted services are resolvable from the AD server 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. The expected output contains the same set of IdM servers as displayed in Verify that the IdM-hosted services are resolvable from the IdM domain server used for establishing trust . Change the service type to TXT and run a DNS query for the TXT record with the IdM Kerberos realm name. The output is expected to contain the same value as displayed in Verify that the IdM-hosted services are resolvable from the IdM domain server used for establishing trust . After you execute the ipa-adtrust-install utility, as described in Section 5.2.2.1.1, "Preparing the IdM Server for Trust" , run a DNS query for the MS DC Kerberos over UDP and LDAP over TCP service records. The command is expected to list all IdM servers on which the ipa-adtrust-install utility has been executed. Note that the output is empty if ipa-adtrust-install has not been executed on any IdM server, which is typically before establishing the very first trust relationship. Verify that AD services are resolvable from the AD server 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. The expected output contains the same set of AD servers as displayed in Verify that IdM is able to resolve service records for AD . 5.2.1.3. NetBIOS Names The NetBIOS name is critical for identifying the Active Directory (AD) domain and, if IdM has a trust configured with AD, for identifying the IdM domain and services. As a consequence, you must use a different NetBIOS name for the IdM domain than the NetBIOS names used in the AD domains to which you want to establish the forest trust. The NetBIOS name of an Active Directory or IdM domain is usually the far-left component of the corresponding DNS domain. For example, if the DNS domain is ad.example.com , the NetBIOS name is typically AD . Note The maximum length of a NetBIOS name is 15 characters. 5.2.1.4. Firewalls and Ports To enable communication between AD domain controllers and IdM servers, make sure you meet the following port requirements: Open ports required for an AD trust and ports required by an IdM server in an AD trust on IdM servers and all AD domain controllers in both directions: from the IdM servers to the AD domain controllers and back. Open the port required by an IdM client in an AD trust on all AD domain controllers of the trusted AD forest. On the IdM clients, make sure the port is open in the outgoing direction (see Prerequisites for Installing a Client in the Linux Domain Identity, Authentication, and Policy Guide ). Table 5.2. Ports Required for an AD Trust Service Port Protocol Endpoint resolution portmapper 135 TCP NetBIOS-DGM 138 TCP and UDP NetBIOS-SSN 139 TCP and UDP Microsoft-DS 445 TCP and UDP Endpoint mapper listener range 1024-1300 TCP AD Global Catalog 3268 TCP LDAP 389 TCP [a] and UDP [a] The TCP port 389 is not required to be open on IdM servers for trust, but it is necessary for clients communicating with the IdM server. Table 5.3. Ports Required by IdM Servers in a Trust Service Port Protocol Kerberos See Port Requirements in the Linux Domain Identity, Authentication, and Policy Guide . LDAP DNS Table 5.4. Ports Required by IdM Clients in an AD Trust Service Port Protocol Notes Kerberos 88 UDP and TCP The libkrb5 library uses UDP and falls-back to the TCP protocol if the data sent from the Kerberos Distribution Center (KDC) is too large. Active Directory attaches a Privilege Attribute Certificate (PAC) to the Kerberos ticket, which increases the size and requires in most cases to use the TCP protocol. To avoid the fall-back and resending the request, by default, SSSD in Red Hat Enterprise Linux 7.4 and later uses TCP for user authentication. To configure the size before libkrb5 uses TCP, set the udp_preference_limit in the /etc/krb.5.conf file. For details, see the krb5.conf (5) man page. Additional Resources For advice on how to open the required ports, see Port Requirements in the Linux Domain Identity, Authentication, and Policy Guide . 5.2.1.5. IPv6 Settings The IdM system must have the IPv6 protocol enabled in the kernel. If IPv6 is disabled, then the CLDAP plug-in used by the IdM services fails to initialize. 5.2.1.6. Clock Settings Both the Active Directory server and the IdM server must have their clocks in sync. 5.2.1.7. Creating a Conditional Forwarder for the IdM Domain in AD Prepare the AD DNS server to forward queries for the IdM domain to the IdM DNS server: On a Windows AD domain controller, open the Active Directory (AD) DNS console. Right-click Conditional Forwarders , select New Conditional Forwarder . Enter the IdM DNS domain name and the IP address of the IdM DNS server Select Store this conditional forwarder in Active Directory, and replicate it as follows , and select the replication setting that matches your environment. Click OK . To verify that the AD domain controller (DC) can resolve DNS entries from the IdM domain, open a command prompt and enter: If the command returns the IP address of the IdM server, the conditional forwarder is working correctly. 5.2.1.8. Creating a Forward Zone for the AD Domain in IdM Prepare the IdM DNS server to forward queries for the AD domain to the AD DNS server: On the IdM server, create a forward zone entry for the AD DNS domain. For further details about creating a DNS forward zone in IdM see the Configuring Forward Zones section in the Linux Domain Identity, Authentication, and Policy Guide . If the AD DNS server does not support DNSSEC, disable DNSSEC validation on the IdM server: Edit the /etc/named.conf file and set the dnssec-validation parameter to no : Restart the named-pkcs11 service: To verify that the IdM server can resolve DNS entries from the AD domain, enter: If the command returns the IP address of the AD DC, the forward zone is working correctly. 5.2.1.9. Supported User Name Formats IdM performs user name mapping in the local SSSD client. The default output user name format for users from trusted domains supported by SSSD is user_name@domain . Active Directory supports several different kinds of name formats: user_name , user_name@DOMAIN_NAME , and DOMAIN_NAME\user_name . Users can use either only their user name ( user_name ) or their fully-qualified user name ( user_name@domain_name ), for example, to authenticate to the system. Warning Preferably, use the fully-qualified user name to avoid conflicts if the same user name exists in multiple domains. If a user specifies only the user name with out the domain, SSSD searches the account in all domains configured in the /etc/sssd/sssd.conf file and in trusted domains. If you configured a domain resolution order as described in Section 8.5.3, "Configuring the Domain Resolution Order on an IdM Client" , SSSD searches for the user in the defined order. In any case, SSSD uses the first entry found. This can lead to problems or confusion if the same user name exists in multiple domains and the first entry found is not the expected one. By default, SSSD displays user names always in the fully-qualified format. For details about changing the format, see Section 5.5, "Changing the Format of User Names Displayed by SSSD" . To identify the user name and the domain to which the user name belongs, SSSD uses a regular expression defined in the re_expression option. The regular expression is used for IdM back ends or AD back ends and supports all the mentioned formats: 5.2.2. Creating Trusts The following sections describe creating trusts in various configuration scenarios. Section 5.2.2.1, "Creating a Trust from the Command Line" contains the full procedure for configuring a trust from the command line. The other sections describe the steps which are different from this basic configuration scenario and reference the basic procedure for all other steps. Note If you set up a replica in an existing trust environment, the replica is not automatically configured as a trust controller. To configure the replica as an additional trust controller, follow the procedures in this section. After creating a trust, see Section 5.2.3, "Post-installation Considerations for Cross-forest Trusts" . 5.2.2.1. Creating a Trust from the Command Line Creating a trust relationship between the IdM and Active Directory Kerberos realms involves the following steps: Preparing the IdM server for the trust, described in Section 5.2.2.1.1, "Preparing the IdM Server for Trust" Creating a trust agreement, described in Section 5.2.2.1.2, "Creating a Trust Agreement" Verifying the Kerberos configuration, described in Section 5.2.2.1.3, "Verifying the Kerberos Configuration" 5.2.2.1.1. Preparing the IdM Server for Trust To set up the IdM server for a trust relationship with AD, follow these steps: Install the required IdM, trust, and Samba packages: Configure the IdM server to enable trust services. You can skip this step if you installed the server with the ipa-replica-install --setup-adtrust command. Run the ipa-adtrust-install utility: The utility adds DNS service records required for AD trusts. These records are created automatically if IdM was installed with an integrated DNS server. If IdM was installed without an integrated DNS server, ipa-adtrust-install prints a list of service records that you must manually add to the DNS before you can continue. Important Red Hat strongly recommends to verify the DNS configuration as described in the section called "Verifying the DNS Configuration" every time after running ipa-adtrust-install , especially if IdM or AD do not use integrated DNS servers. The script prompts to configure the slapi-nis plug-in, a compatibility plug-in that allows older Linux clients to work with trusted users. At least one user (the IdM administrator) exists when the directory is first installed. The SID generation task can create a SID for any existing users to support the trust environment. This is a resource-intensive task; for a high number of users, this can be run separately. Make sure that DNS is properly configured, as described in Section 5.2.1.2, "DNS and Realm Settings" . Start the smb service: Optionally, configure that the smb service starts automatically when the system boots: Optionally, use the smbclient utility to verify that Samba responds to Kerberos authentication from the IdM side. 5.2.2.1.2. Creating a Trust Agreement Create a trust agreement for the Active Directory domain and the IdM domain by using the ipa trust-add command: The ipa trust-add command sets up a one-way trust by default. It is not possible to establish a two-way trust in RHEL 7. To establish an external trust, pass the --external=true option to the ipa trust-add command. See Section 5.1.5, "External Trusts to Active Directory" for details. Note The ipa trust-add command configures the server as a trust controller by default. See Section 5.1.6, "Trust Controllers and Trust Agents" for details. The following example establishes a two-way trust by using the --two-way=true option: 5.2.2.1.3. Verifying the Kerberos Configuration To verify the Kerberos configuration, test if it is possible to obtain a ticket for an IdM user and if the IdM user can request service tickets. To verify a two-way trust: Request a ticket for an IdM user: Request service tickets for a service within the IdM domain: Request service tickets for a service within the AD 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 /AD.DOMAIN@IPA.DOMAIN . To verify a one-way trust from the IdM side: Request a ticket for an Active Directory 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 SSSD user names. This allows AD users to use Kerberos authentication and access Linux services, which support GSSAPI authentication directly. Note For more information about the plug-in, see Section 5.3.7.2, "Using SSH Without Passwords" . 5.2.2.2. Creating a Trust Using a Shared Secret A shared secret is a password that is known to trusted peers and can be used by other domains to join the trust. The shared secret can configure both one-way and two-way trusts within Active Directory (AD). In AD, the shared secret is stored as a trusted domain object (TDO) within the trust configuration. IdM supports creating a one-way or two-way trust using a shared secret instead of the AD administrator credentials. Setting up such a trust requires the administrator to create the shared secret in AD and manually validate the trust on the AD side. 5.2.2.2.1. Creating a Two-Way Trust Using a Shared Secret To create a two-way trust with a shared secret with a Microsoft Windows Server 2012, 2012 R2, or 2016: Prepare the IdM server for the trust, as described in Section 5.2.2.1.1, "Preparing the IdM Server for Trust" . If the IdM and AD hosts use a DNS server that cannot resolve both domains, set up forwarding for the DNS zones: Prepare the AD DNS server to forward queries for the IdM domain to the IdM DNS server. For details, see Section 5.2.1.7, "Creating a Conditional Forwarder for the IdM Domain in AD" . Prepare the IdM DNS server to forward queries for the AD domain to the AD DNS server. For details, see Section 5.2.1.8, "Creating a Forward Zone for the AD Domain in IdM" . Configure a trust in the Active Directory Domains and Trusts console. In particular: Create a new trust. Give the trust the IdM domain name, for example idm.example.com . Specify that this is a forest type of trust. Specify that this is a two-way type of trust. Specify that this is a forest-wide authentication. Set the trust password . Note The same password must be used when configuring the trust in IdM. When asked to confirm the incoming trust, select No . Create a trust agreement, as described in Section 5.2.2.1.2, "Creating a Trust Agreement" . When running the ipa trust-add command, use the --type , --trust-secret and --two-way=True options, and omit the --admin option. For example: Retrieve the list of domains: On the IdM server, verify that the trust relationship is established by using the ipa trust-show command. Optionally, search for the trusted domain: Verify the Kerberos configuration, as described in Section 5.2.2.1.3, "Verifying the Kerberos Configuration" . 5.2.2.2.2. Creating a One-Way Trust Using a Shared Secret To create a one-way trust using a shared secret with a Microsoft Windows Server 2012, 2012 R2 or 2016: Prepare the IdM server for the trust, as described in Section 5.2.2.1.1, "Preparing the IdM Server for Trust" . If the IdM and AD hosts use a DNS server that cannot resolve both domains, set up forwarding for the DNS zones: Prepare the AD DNS server to forward queries for the IdM domain to the IdM DNS server. For details, see Section 5.2.1.7, "Creating a Conditional Forwarder for the IdM Domain in AD" . Prepare the IdM DNS server to forward queries for the AD domain to the AD DNS server. For details, see Section 5.2.1.8, "Creating a Forward Zone for the AD Domain in IdM" . Configure a trust in the Active Directory Domains and Trusts console: Right click to the domain name, and select Properties . On the Trusts tab, click New Trust . Enter the IdM domain name, and click . Select Forest trust , and click . Select One-way: incoming , and click . Select This domain only , and click . Enter a shared secret (trust password), and click . Verify the settings, and click . When the system asks if you want to confirm the incoming trust, select No, do not confirm the incoming trust , and click . Click Finish . Create a trust agreement: Enter the shared secret you set in the AD Domains and Trusts console. Validate the trust in the Active Directory Domains and Trusts console: Right click to the domain name, and select Properties . On the Trusts tab, select the domain in the Domains that trust this domain (incoming trusts) pane , and click Properties . Click the Validate button. Select Yes, validate the incoming trust , and enter the credentials of the IdM admin user. Update the list of trusted domains: List the trusted domains: Optionally, verify that the IdM server can retrieve user information from AD domain: 5.2.2.3. Verifying the ID Mapping To verify the ID mapping: Run the following command on a Windows Active Directory domain controller (DC) to list the highest ID: List the ID ranges on an IdM server: You require the first POSIX ID value in a later step. On the Active Directory DC, display the security identifier (SID) or a user. For example, to display the SID of administrator : The last part of the SID is the relative identifier (RID). You require the user's RID in the step. Note If the RID is higher than the default ID range (200000), use the ipa idrange-mod command to extend the range. For example: Display the user ID of the same user on the IdM server: If you add the first POSIX ID value (610600000) to the RID (500), it must match the user ID displayed on the IdM server (610600500). 5.2.2.4. Creating a Trust on an Existing IdM Instance When configuring a trust for an existing IdM instance, certain settings for the IdM server and entries within its domain are already configured. However, you must set the DNS configuration for the Active Directory domain and assign Active Directory SIDs to all existing IdM users and groups. Prepare the IdM server for the trust, as described in Section 5.2.2.1.1, "Preparing the IdM Server for Trust" . Create a trust agreement, as described in Section 5.2.2.1.2, "Creating a Trust Agreement" . Generate SIDs for each IdM user. Note Do not perform this step if the SIDs were generated when the ipa-adtrust-install utility was used to establish the trust. Add a new ipaNTSecurityIdentifier attribute, containing a SID, automatically for each entry by running the ipa-sidgen-task operation on the back-end LDAP directory. After the task completes successfully, a message is recorded in the error logs that the SID generation task ( Sidgen task ) finished with a status of zero (0). Verify the Kerberos configuration, as described in Section 5.2.2.1.3, "Verifying the Kerberos Configuration" . 5.2.2.5. Adding a Second Trust When adding a trust on an IdM server that already has one or more trust agreements configured, certain general IdM trust settings, such as installing the trust-related packages or configuring SIDs, is no longer required. To add an additional trust, you only must configure DNS and establish a trust agreement. Make sure that DNS is properly configured, as described in Section 5.2.1.2, "DNS and Realm Settings" . Create a trust agreement, as described in Section 5.2.2.1.2, "Creating a Trust Agreement" . 5.2.2.6. Creating a Trust in the Web UI Before creating a trust in the web UI, prepare the IdM server for the trust. This trust configuration is easiest to perform from the command line, as described in Section 5.2.2.1.1, "Preparing the IdM Server for Trust" . Once the initial configuration is set, a trust agreement can be added in the IdM web UI: Open the IdM web UI: Open the IPA Server main tab, and select the Trusts subtab. In the Trusts subtab, click Add to open the new trust configuration window. Fill in the required information about the trust: Provide the AD domain name in the Domain field. To set up the trust as two-way, select the Two-way trust check box. To set up the trust as one-way, leave Two-way trust unselected. For more information about one-way and two-way trusts, see Section 5.1.4, "One-Way and Two-Way Trusts" . To establish an external trust to a domain in another forest, select the External Trust check box. For more information, see Section 5.1.5, "External Trusts to Active Directory" . The Establish using section defines how the trust is to be established: To establish the trust using the AD administrator's user name and password, select Administrative account and provide the required credentials. Alternatively, to establish the trust with a shared password, select Pre-shared password and provide the trust password. Define the ID configuration for the trust: The Range type option allows you to choose the ID range type. If you want IdM to automatically detect what kind of ID range to use, select Detect . To define the starting ID of the ID range, use the Base ID field. To define the size of the ID range, use the Range size field. If you want IdM to use default values for the ID range, do not specify these options. For more information about ID ranges, see the section called "ID Ranges" . Figure 5.5. Adding a Trust in the Web UI Click Add to save the new trust. After this, verify the Kerberos configuration, as described in Section 5.2.2.1.3, "Verifying the Kerberos Configuration" . 5.2.3. Post-installation Considerations for Cross-forest Trusts 5.2.3.1. Potential Behavior Issues with Active Directory Trust 5.2.3.1.1. Active Directory Users and IdM Administration Currently, Active Directory (AD) users and administrators can only see their self-service page after logging into the IdM Web UI. AD administrators cannot access the administrator's view of IdM Web UI. For details, see the Authenticating to the IdM Web UI as an AD User section in the Linux Domain Identity, Authentication, and Policy Guide . Additionally, AD users currently cannot manage their own ID overrides. Only IdM users can add and manage ID overrides. 5.2.3.1.2. Authenticating Deleted Active Directory Users By default, every IdM client uses the SSSD service to cache user identities and credentials. If the IdM or AD back-end provider is temporarily unavailable, SSSD enables the local system to reference identities for users who have already logged in successfully once. Because SSSD maintains a list of users locally, changes that are made on the back end might not be immediately visible to clients that run SSSD offline. On such clients, users who have previously logged into IdM resources and whose hashed passwords are stored in the SSSD cache are able to log in again even if their user accounts have been deleted in AD. If the above conditions are met, the user identity is cached in SSSD, and the AD user is able to log into IdM resources even if the user account is deleted AD. This problem will persist until SSSD becomes online and is able to verify AD user logon against AD domain controllers. If the client system runs SSSD online, the password provided by the user is validated by an AD domain controller. This ensures that deleted AD users are not allowed to log in. 5.2.3.1.3. Credential Cache Collections and Selecting Active Directory Principals The Kerberos credentials cache attempts to match a client principal to a server principal based on the following identifiers in this order: service name host name realm name When the client and server mapping is based on the host name or real name and credential cache collections are used, unexpected behavior can occur in binding as an AD user. This is because the realm name of the Active Directory user is different than the realm name of the IdM system. If an AD user obtains a ticket using the kinit utility and then uses SSH to connect to an IdM resource, the principal is not selected for the resource ticket. an IdM principal is used because the IdM principal matches the realm name of the resource. For example, if the AD user is Administrator and the domain is ADEXAMPLE.ADREALM , the principal is Administrator@ADEXAMPLE.ADREALM . This is set as the default principal in the Active Directory ticket cache. However, if any IdM user also has a Kerberos ticket (such as admin ), then there is a separate IdM credentials cache, with an IdM default principal. That IdM default principal is selected for a host ticket if the Active Directory user uses SSH to connect to a resource. This is because the realm name of the IdM principal matches the realm of the IdM resource. 5.2.3.1.4. Resolving Group SIDs Losing Kerberos Tickets Running a command to obtain a SID from the Samba service, such as net getlocalsid or net getdomainsid , removes any existing admin ticket from the Kerberos cache. Note You are not required to run commands such as net getlocalsid or net getdomainsid in order to use Active Directory trusts. Cannot Verify Group Membership for Users It is not possible to verify that a specific trusted user is associated with a specific IdM group, external or POSIX. Cannot Display Remote Active Directory Group Memberships for an Active Directory User Important Note that this problem no longer occurs if the IdM server and client run on Red Hat Enterprise Linux 7.1 or later. The id utility can be used to display local group associations for Linux system users. However, id does not display Active Directory group memberships for Active Directory users, even though Samba tools do display them. To work around this, you can use the ssh utility to log into an IdM client machine as the given AD user. After the AD user logs in successfully for the first time, the id search detects and displays the AD group memberships: 5.2.3.2. Configuring Trust Agents After you set up a new replica in a trust environment, the replica does not automatically have the AD trust agent role installed. To configure the replica as a trust agent: 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. For further information about the --add-agents option, see the ipa-adtrust-install (1) man page. On the new replica: Restart the IdM service: Remove all entries from the SSSD cache: Note To use the sssctl command, the sssd-tools package must be installed. Optionally, verify that the replica has the AD trust agent role installed:

Commands:
ipa dns-update-system-records --dry-run IPA DNS records: _kerberos-master._tcp.example.com. 86400 IN SRV 0 100 88 server.example.com. _kerberos-master._udp.example.com. 86400 IN SRV 0 100 88 server.example.com. _kerberos._tcp.example.com. 86400 IN SRV 0 100 88 server.example.com. _kerberos._udp.example.com. 86400 IN SRV 0 100 88 server.example.com. _kerberos.example.com. 86400 IN TXT "EXAMPLE.COM" _kpasswd._tcp.example.com. 86400 IN SRV 0 100 464 server.example.com. _kpasswd._udp.example.com. 86400 IN SRV 0 100 464 server.example.com. _ldap._tcp.example.com. 86400 IN SRV 0 100 389 server.example.com. _ntp._udp.example.com. 86400 IN SRV 0 100 123 server.example.com.
dig +short -t SRV _kerberos._udp. ipa.example.com. 0 100 88 ipamaster1.ipa.example.com. dig +short -t SRV _ldap._tcp. ipa.example.com. 0 100 389 ipamaster1.ipa.example.com.
dig +short -t TXT _kerberos. ipa.example.com. IPA.EXAMPLE.COM
dig +short -t SRV _kerberos._udp.dc._msdcs. ipa.example.com. 0 100 88 ipamaster1.ipa.example.com. dig +short -t SRV _ldap._tcp.dc._msdcs. ipa.example.com. 0 100 389 ipamaster1.ipa.example.com.
dig +short -t SRV _kerberos._udp.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.ipa.example.com. _kerberos._udp.ipa.example.com. SRV service location: priority = 0 weight = 100 port = 88 svr hostname = ipamaster1.ipa.example.com > _ldap._tcp.ipa.example.com _ldap._tcp.ipa.example.com SRV service location: priority = 0 weight = 100 port = 389 svr hostname = ipamaster1.ipa.example.com
C:\>nslookup.exe > set type=TXT > _kerberos.ipa.example.com. _kerberos.ipa.example.com. text = "IPA.EXAMPLE.COM"
C:\>nslookup.exe > set type=SRV > _kerberos._udp.dc._msdcs.ipa.example.com. _kerberos._udp.dc._msdcs.ipa.example.com. SRV service location: priority = 0 weight = 100 port = 88 svr hostname = ipamaster1.ipa.example.com > _ldap._tcp.dc._msdcs.ipa.example.com. _ldap._tcp.dc._msdcs.ipa.example.com. SRV service location: priority = 0 weight = 100 port = 389 svr hostname = ipamaster1.ipa.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
C:\> nslookup server.idm.example.com
dnssec-validation no;
systemctl restart named-pkcs11
host server.ad.example.com
re_expression = (((?P<domain>[^\\]+)\\(?P<name>.+USD))|((?P<name>[^@]+)@(?P<domain>.+USD))|(^(?P<name>[^@\\]+)USD))
yum install ipa-server ipa-server-trust-ad samba-client
ipa-adtrust-install
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]: y
Do you want to run the ipa-sidgen task? [no]: yes
systemctl start smb
systemctl enable smb
smbclient -L ipaserver.ipa.example.com -k lp_load_ex: changing to config backend registry Sharename Type Comment --------- ---- ------- IPCUSD IPC IPC Service (Samba 4.9.1) Reconnecting with SMB1 for workgroup listing. Server Comment --------- ------- Workgroup Master --------- -------
ipa trust-add --type= type ad_domain_name --admin ad_admin_username --password
ipa trust-add --type=ad ad.example.com --admin Administrator --password --two-way=true Active Directory domain administrator's password: ------------------------------------------------------- Added Active Directory trust for realm "ad.example.com" ------------------------------------------------------- Realm-Name: ad.example.com Domain NetBIOS name: AD Domain Security Identifier: S-1-5-21-796215754-1239681026-23416912 SID blacklist incoming: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18 SID blacklist outgoing: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18 Trust direction: Two-way trust Trust type: Active Directory domain Trust status: Established and verified
kinit user
kvno -S host ipaserver.example.com
kvno -S cifs adserver.example.com
klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: user@IPA.DOMAIN Valid starting Expires Service principal 06/15/12 12:13:04 06/16/12 12:12:55 krbtgt/IPA.DOMAIN@IPA.DOMAIN 06/15/12 12:13:13 06/16/12 12:12:55 host/ipaserver.ipa.example.com@IPA.DOMAIN 06/15/12 12:13:23 06/16/12 12:12:55 krbtgt/AD.DOMAIN@IPA.DOMAIN 06/15/12 12:14:58 06/15/12 22:14:58 cifs/adserver.ad.example.com@AD.DOMAIN
kinit user @ AD.DOMAIN
kvno -S host ipaserver.example.com
klist Ticket cache: KEYRING:persistent:0:krb_ccache_hRtox00 Default principal: user@AD.DOMAIN Valid starting Expires Service principal 03.05.2016 18:31:06 04.05.2016 04:31:01 host/ipaserver.ipa.example.com@IPA.DOMAIN renew until 04.05.2016 18:31:00 03.05.2016 18:31:06 04.05.2016 04:31:01 krbtgt/IPA.DOMAIN@AD.DOMAIN renew until 04.05.2016 18:31:00 03.05.2016 18:31:01 04.05.2016 04:31:01 krbtgt/AD.DOMAIN@AD.DOMAIN renew until 04.05.2016 18:31:00
ipa trust-add --type=ad ad.example.com --trust-secret --two-way=True Shared secret for the trust: ------------------------------------------------------- Added Active Directory trust for realm "ad.example.com" ------------------------------------------------------- Realm-Name: ad.example.com Domain NetBIOS name: AD Domain Security Identifier: S-1-5-21-796215754-1239681026-23416912 SID blacklist incoming: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18 SID blacklist outgoing: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18 Trust direction: Trusting forest Trust type: Active Directory domain Trust status: Waiting for confirmation by remote side
ipa trust-fetch-domains ad_domain
ipa trust-show ad.example.com Domain NetBIOS name: AD Domain Security Identifier: S-1-5-21-796215754-1239681026-23416912 Trust direction: Trusting forest Trust type: Active Directory domain
ipa trustdomain-find ad.example.com Domain name: ad.example.com Domain NetBIOS name: AD Domain Security Identifier: S-1-5-21-796215754-1239681026-23416912 Domain enabled: True
ipa trust-add --type=ad --trust-secret ad.example.com Shared secret for the trust: password ------------------------------------------------------- Added Active Directory trust for realm " ad.example.com " ------------------------------------------------------- Realm name: ad.example.com Domain NetBIOS name: AD Domain Security Identifier: S-1-5-21-1762709870-351891212-3141221786 Trust direction: Trusting forest Trust type: Active Directory domain Trust status: Waiting for confirmation by remote side
ipa trust-fetch-domains ad.example.com ---------------------------------------------------------------------------------------- List of trust domains successfully refreshed. Use trustdomain-find command to list them. ---------------------------------------------------------------------------------------- ---------------------------- Number of entries returned 0 ----------------------------
ipa trustdomain-find ad.example.com Domain name: ad.example.com Domain NetBIOS name: AD Domain Security Identifier: S-1-5-21-1762709870-351891212-3141221786 Domain enabled: True ---------------------------- Number of entries returned 1 ----------------------------
getent passwd administrator @ ad.example.com administrator @ ad.example.com :*: 610600500 : 610600500 : Administrator : /home/ad.example.com/administrator :
C:\> dcdiag /v /test:ridmanager /s:ad.example.com Available RID Pool for the Domain is 1600 to 1073741823
ipa idrange-find ---------------- 1 range matched ---------------- Range name: AD.EXAMPLE.COM_id_range First Posix ID of the range: 610600000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 0 Domain SID of the trusted domain: S-1-5-21-796215754-1239681026-23416912 Range type: Active Directory domain range ---------------------------- Number of entries returned 1 ----------------------------
C:\> wmic useraccount where name="administrator" get sid S-1-5-21-796215754-1239681026-23416912- 500
ipa idrange-mod --range-size= 1000000 AD.EXAMPLE.COM_id_range
id ad\\administrator uid= 610600500 (administrator@ad.example.com)
ldapmodify -x -H ldap:// ipaserver.ipa.example.com :389 -D "cn=directory manager" -w password dn: cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config changetype: add objectClass: top objectClass: extensibleObject cn: sidgen nsslapd-basedn: dc=ipadomain,dc=com delay: 0 adding new entry "cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config"
grep "sidgen_task_thread" /var/log/dirsrv/slapd-IDM-EXAMPLE-COM/errors [20/Jul/2012:18:17:16 +051800] sidgen_task_thread - [file ipa_sidgen_task.c, line 191]: Sidgen task starts [20/Jul/2012:18:17:16 +051800] sidgen_task_thread - [file ipa_sidgen_task.c, line 196]: Sidgen task finished [0].
https:// ipaserver.example.com
kinit Administrator@ADEXAMPLE.ADREALM Password for Administrator@ADEXAMPLE.ADREALM: klist Ticket cache: KEYRING:persistent:0:0 Default principal: Administrator@ADEXAMPLE.ADREALM Valid starting Expires Service principal 27.11.2015 11:25:23 27.11.2015 21:25:23 krbtgt/ADEXAMPLE.ADREALM@ADEXAMPLE.ADREALM renew until 28.11.2015 11:25:16
ssh -l Administrator@adexample.adrealm ipaclient.example.com Administrator@adexample.adrealm@ipaclient.example.com's password: klist -A Ticket cache: KEYRING:persistent:0:0 Default principal: Administrator@ADEXAMPLE.ADREALM Valid starting Expires Service principal 27.11.2015 11:25:23 27.11.2015 21:25:23 krbtgt/ADEXAMPLE.ADREALM@ADEXAMPLE.ADREALM renew until 28.11.2015 11:25:16 Ticket cache: KEYRING:persistent:0:0 Default principal: admin@EXAMPLE.COM >>>>> IdM user Valid starting Expires Service principal 27.11.2015 11:25:18 28.11.2015 11:25:16 krbtgt/EXAMPLE.COM@EXAMPLE.COM 27.11.2015 11:25:48 28.11.2015 11:25:16 host/ipaclient.example.com@EXAMPLE.COM >>>>> host principal
id ADDOMAIN\user uid=1921801107(user@ad.example.com) gid=1921801107(user@ad.example.com) groups=1921801107(user@ad.example.com),129600004(ad_users),1921800513(domain users@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