5.2. Creating Cross-forest Trusts
5.2.1. Environment and Machine Requirements
5.2.1.1. Supported Windows Platforms
- Forest functional level range: Windows Server 2008 - Windows Server 2016
- Domain functional level range: Windows Server 2008 - Windows Server 2016
- Windows Server 2012 R2
- Windows Server 2016
5.2.1.2. DNS and Realm Settings
- Unique primary DNS domains
- Each system must have its own unique primary DNS domain configured. For example:
ad.example.com
for AD andidm.example.com
for IdMexample.com
for AD andidm.example.com
for IdMad.example.com
for AD andexample.com
for IdMImportant
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 andidm.example.com
for IdM, the Kerberos realm names are required to beAD.EXAMPLE.COM
andIDM.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
- Machines 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.You can acquire a list of the required SRV records specific to your system setup by running the
$ ipa dns-update-system-records --dry-run
command.The generated list can look for example like this:$ 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.
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
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.
[root@ipaserver ~]# dig +short -t SRV _kerberos._udp.ipa.example.com. 0 100 88 ipamaster1.ipa.example.com. [root@ipaserver ~]# dig +short -t SRV _ldap._tcp.ipa.example.com. 0 100 389 ipamaster1.ipa.example.com.
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.
[root@ipaserver ~]# dig +short -t TXT _kerberos.ipa.example.com. IPA.EXAMPLE.COM
- 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.[root@ipaserver ~]# dig +short -t SRV _kerberos._udp.dc._msdcs.ipa.example.com. 0 100 88 ipamaster1.ipa.example.com. [root@ipaserver ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.ipa.example.com. 0 100 389 ipamaster1.ipa.example.com.
The commands are expected to list all IdM servers on whichipa-adtrust-install
has been executed. Note that the output is empty ifipa-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.
[root@ipaserver ~]# dig +short -t SRV _kerberos._udp.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.
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.C:\>nslookup.exe > set type=SRV
- Enter the domain name for the Kerberos over UDP and LDAP over TCP service records.
> _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
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.
C:\>nslookup.exe > set type=TXT > _kerberos.ipa.example.com. _kerberos.ipa.example.com. text = "IPA.EXAMPLE.COM"
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.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
The command is expected to list all IdM servers on which theipa-adtrust-install
utility has been executed. Note that the output is empty ifipa-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.C:\>nslookup.exe > set type=SRV
- 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
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
ad.example.com
, the NetBIOS name is typically AD
.
Note
5.2.1.4. Firewalls and Ports
- 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
5.2.1.6. Clock Settings
5.2.1.7. Creating a Conditional Forwarder for the IdM Domain in AD
- On a Windows AD domain controller, open the Active Directory (AD)
DNS
console. - Right-click New Conditional Forwarder., select
- 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.
- To verify that the AD domain controller (DC) can resolve DNS entries from the IdM domain, open a command prompt and enter:
C:\> nslookup server.idm.example.com
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
- 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 thednssec-validation
parameter tono
:dnssec-validation no;
- Restart the
named-pkcs11
service:# systemctl restart named-pkcs11
- To verify that the IdM server can resolve DNS entries from the AD domain, enter:
# host server.ad.example.com
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
user_name@domain
. Active Directory supports several different kinds of name formats: user_name
, user_name@DOMAIN_NAME
, and DOMAIN_NAME\user_name
.
user_name
) or their fully-qualified user name (user_name@domain_name
), for example, to authenticate to the system.
Warning
/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.
re_expression
option. The regular expression is used for IdM back ends or AD back ends and supports all the mentioned formats:
re_expression = (((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$))
5.2.2. Creating Trusts
Note
5.2.2.1. Creating a Trust from the Command Line
- 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
- Install the required IdM, trust, and Samba packages:
[root@ipaserver ]# yum install ipa-server ipa-server-trust-ad samba-client
- 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:[root@ipaserver ]# ipa-adtrust-install
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 runningipa-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.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
- 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.
Do you want to run the ipa-sidgen task? [no]: yes
- Make sure that DNS is properly configured, as described in Section 5.2.1.2, “DNS and Realm Settings”.
- Start the
smb
service:[root@ipaserver ~]# systemctl start smb
- Optionally, configure that the
smb
service starts automatically when the system boots:[root@ipaserver ~]# systemctl enable smb
- Optionally, use the
smbclient
utility to verify that Samba responds to Kerberos authentication from the IdM side.[root@ipaserver ~]# smbclient -L ipaserver.ipa.example.com -k lp_load_ex: changing to config backend registry Sharename Type Comment --------- ---- ------- IPC$ IPC IPC Service (Samba 4.9.1) Reconnecting with SMB1 for workgroup listing. Server Comment --------- ------- Workgroup Master --------- -------
5.2.2.1.2. Creating a Trust Agreement
ipa trust-add
command:
# ipa trust-add --type=type ad_domain_name --admin ad_admin_username --password
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.
--external=true
option to the ipa trust-add
command. See Section 5.1.5, “External Trusts to Active Directory” for details.
Note
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.
--two-way=true
option:
[root@ipaserver ~]# 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
5.2.2.1.3. Verifying the Kerberos Configuration
- Request a ticket for an IdM user:
[root@ipaserver ~]# kinit user
- Request service tickets for a service within the IdM domain:
[root@ipaserver ~]# kvno -S host ipaserver.example.com
- Request service tickets for a service within the AD domain:
[root@ipaserver ~]# kvno -S cifs adserver.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 namedkrbtgt/AD.DOMAIN@IPA.DOMAIN
.[root@ipaserver ]# 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
- Request a ticket for an Active Directory user:
[root@ipaserver ~]# kinit user@AD.DOMAIN
- Request service tickets for a service within the IdM domain:
[root@ipaserver ~]# kvno -S host ipaserver.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 namedkrbtgt/IPA.DOMAIN@AD.DOMAIN
.[root@ipaserver ]# 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
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
5.2.2.3. Verifying the ID Mapping
- Run the following command on a Windows Active Directory domain controller (DC) to list the highest ID:
C:\> dcdiag /v /test:ridmanager /s:ad.example.com ... Available RID Pool for the Domain is 1600 to 1073741823 ...
- List the ID ranges on an IdM server:
[root@ipaserver ~]# 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 ----------------------------
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
:C:\> wmic useraccount where name="administrator" get sid S-1-5-21-796215754-1239681026-23416912-500
The last part of the SID is the relative identifier (RID). You require the user's RID in the next step.Note
If the RID is higher than the default ID range (200000), use theipa idrange-mod
command to extend the range. For example:# ipa idrange-mod --range-size=1000000 AD.EXAMPLE.COM_id_range
- Display the user ID of the same user on the IdM server:
[root@ipaserver ~]# id ad\\administrator uid=610600500(administrator@ad.example.com)...
- 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
- 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 theipa-adtrust-install
utility was used to establish the trust.- Add a new
ipaNTSecurityIdentifier
attribute, containing a SID, automatically for each entry by running theipa-sidgen-task
operation on the back-end LDAP directory.[root@ipaserver ]# 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"
- 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).[root@ipaserver ]# 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].
- 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
- 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
- Open the IdM web UI:
https://ipaserver.example.com
- 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
- Clickto save the new trust.
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
5.2.3.1.2. Authenticating Deleted Active Directory Users
5.2.3.1.3. Credential Cache Collections and Selecting Active Directory Principals
- service name
- host name
- realm name
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.
Administrator
and the domain is ADEXAMPLE.ADREALM
, the principal is Administrator@ADEXAMPLE.ADREALM
.
[root@server ~]# kinit Administrator@ADEXAMPLE.ADREALM Password for Administrator@ADEXAMPLE.ADREALM: [root@server ~]# 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
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.
[root@vm-197 ~]# ssh -l Administrator@adexample.adrealm ipaclient.example.com Administrator@adexample.adrealm@ipaclient.example.com's password: [root@vm-197 ~]# 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:0Default 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.COM27.11.2015 11:25:48 28.11.2015 11:25:16 host/ipaclient.example.com@EXAMPLE.COM
>>>>> host principal
5.2.3.1.4. Resolving Group SIDs
Losing Kerberos Tickets
net getlocalsid
or net getdomainsid
, removes any existing admin ticket from the Kerberos cache.
Note
net getlocalsid
or net getdomainsid
in order to use Active Directory trusts.
Cannot Verify Group Membership for Users
Cannot Display Remote Active Directory Group Memberships for an Active Directory User
Important
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.
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:
[root@ipaserver ~]# 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)
5.2.3.2. Configuring Trust Agents
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:[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.For further information about the--add-agents
option, see the ipa-adtrust-install(1) man page. - On the new replica:
- Restart the IdM service:
[root@new_trust_controller]# ipactl restart
- Remove all entries from the SSSD cache:
[root@new_trust_controller]# sssctl cache-remove
Note
To use thesssctl
command, the sssd-tools package must be installed. - Optionally, verify that the replica has the
AD trust agent
role installed:[root@new_trust_controller]# ipa server-show new_replica.idm.example.com ... Enabled server roles: CA server, NTP server, AD trust agent