Este conteúdo não está disponível no idioma selecionado.
Chapter 9. Setting up a trust
This section describes how to configure the Identity Management (IdM)/Active Directory (AD) trust on the IdM side using the command line.
Prerequisites
- DNS is correctly configured. Both IdM and AD servers must be able to resolve each other names. For details, see Configuring DNS and realm settings for a trust.
- Supported versions of AD and IdM are deployed. For details, see Supported versions of Windows Server.
- You have obtained a Kerberos ticket. For details, see Using kinit to log in to IdM manually.
9.1. Preparing the IdM server for the trust
Before you can establish a trust with AD, you must prepare the IdM domain using the ipa-adtrust-install
utility on an IdM server.
Any system where you run the ipa-adtrust-install
command automatically becomes an AD trust controller. However, you must run ipa-adtrust-install
only once on an IdM server.
Prerequisites
- IdM server is installed.
- You have root privileges to install packages and restart IdM services.
Procedure
Install the required packages:
[root@ipaserver ~]# dnf install ipa-server-trust-ad samba-client
Authenticate as the IdM administrative user:
[root@ipaserver ~]# kinit admin
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.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
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
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.
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 to55000-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
Make sure that DNS is properly configured, as described in Verifying the DNS configuration for a trust.
ImportantRed Hat strongly recommends you verify the DNS configuration as described in Verifying the DNS configuration for a trust every time after running
ipa-adtrust-install
, especially if IdM or AD do not use integrated DNS servers.Restart the
ipa
service:[root@ipaserver ~]# ipactl restart
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) ...
9.2. Setting up a trust agreement using the command line
Follow this procedure to set up the trust agreement using the command line. The Identity Management (IdM) server allows you to configure three types of trust agreements:
- One-way trust — default option. One-way trust enables Active Directory (AD) users and groups to access resources in IdM, but not the other way around. The IdM domain trusts the AD forest, but the AD forest does not trust the IdM domain.
Two-way trust — Two-way trust enables AD users and groups to access resources in IdM.
You must configure a two-way trust for solutions such as Microsoft SQL Server that expect the
S4U2Self
andS4U2Proxy
Microsoft extensions to the Kerberos protocol to work over a trust boundary. An application on a RHEL IdM host might requestS4U2Self
orS4U2Proxy
information from an Active Directory domain controller about an AD user, and a two-way trust provides this feature.Note that this two-way trust functionality does not allow IdM users to login to Windows systems, and the two-way trust in IdM does not give the users any additional rights compared to the one-way trust solution in AD.
-
To create the two-way trust, add the following option to the command:
--two-way=true
-
To create the two-way trust, add the following option to the command:
External trust — a trust relationship between IdM and an AD domain in different forests. While a forest trust always requires establishing a trust between IdM and the root domain of an Active Directory forest, an external trust can be established from IdM to a domain within a forest. This is only recommended if it is not possible to establish a forest trust between forest root domains due to administrative or organizational reasons.
-
To create the external trust, add the following option to the command:
--external=true
-
To create the external trust, add the following option to the command:
The steps below show you how to create a one-way trust agreement.
Prerequisites
- User name and password of a Windows administrator.
- You have prepared the IdM server for the trust.
Procedure
Create a trust agreement for the AD domain and the IdM domain by using the
ipa trust-add
command:To have SSSD automatically generate UIDs and GIDs for AD users based on their SID, create a trust agreement with the
Active Directory domain
ID range type. This is the most common configuration.[root@server ~]# ipa trust-add --type=ad ad.example.com --admin <ad_admin_username> --password --range-type=ipa-ad-trust
If you have configured POSIX attributes for your users in Active Directory (such as
uidNumber
andgidNumber
) and you want SSSD to process this information, create a trust agreement with theActive Directory domain with POSIX attributes
ID range type:[root@server ~]# ipa trust-add --type=ad ad.example.com --admin <ad_admin_username> --password --range-type=ipa-ad-trust-posix
If you do not specify an ID Range type when creating a trust, IdM attempts to automatically select the appropriate range type by requesting details from AD domain controllers in the forest root domain. If IdM does not detect any POSIX attributes, the trust installation script selects the Active Directory domain
ID range.
If IdM detects any POSIX attributes in the forest root domain, the trust installation script selects the Active Directory domain with POSIX attributes
ID range and assumes that UIDs and GIDs are correctly defined in AD. If POSIX attributes are not correctly set in AD, you will not be able to resolve AD users.
For example, if the users and groups that need access to IdM systems are not part of the forest root domain, but instead are located in a child domain of the forest domain, the installation script may not detect the POSIX attributes defined in the child AD domain. In this case, Red Hat recommends that you explicitly choose the POSIX ID range type when establishing the trust.
9.3. Setting up a trust agreement in the IdM Web UI
Follow this procedure to configure the Identity Management (IdM)/Active Directory (AD) trust agreement on the IdM side using the IdM Web UI.
Prerequisites
- DNS is correctly configured. Both IdM and AD servers must be able to resolve each other names.
- Supported versions of AD and IdM are deployed.
- You have obtained a Kerberos ticket.
- Before creating a trust in the Web UI, prepare the IdM server for the trust as described in: Preparing the IdM server for the trust.
- You are logged in as an IdM administrator. For details, see Accessing the IdM Web UI in a web browser.
Procedure
- In the IdM Web UI, click the IPA Server tab.
- In the IPA Server tab, click the Trusts tab.
In the drop down menu, select the Trusts option.
- Click the Add button.
- In the Add Trust dialog box, enter the name of the Active Directory domain.
In the Account and Password fields, add the administrator credentials of the Active Directory administrator.
- Optional: Select Two-way trust, if you want to enable AD users and groups to access resources in IdM. However, the two-way trust in IdM does not give the users any additional rights compared to the one-way trust solution in AD. Both solutions are considered equally secure because of default cross-forest trust SID filtering settings.
- Optional: Select External trust if you are configuring a trust with an AD domain that is not the root domain of an AD forest. While a forest trust always requires establishing a trust between IdM and the root domain of an Active Directory forest, you can establish an external trust from IdM to any domain within an AD forest.
Optional: By default, the trust installation script tries to detect the appropriate ID range type. You can also explicitly set the ID range type by choosing one of the following options:
-
To have SSSD automatically generate UIDs and GIDs for AD users based on their SID, select the
Active Directory domain
ID range type. This is the most common configuration. If you have configured POSIX attributes for your users in Active Directory (such as
uidNumber
andgidNumber
) and you want SSSD to process this information, select theActive Directory domain with POSIX attributes
ID range type.WarningIf 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 theActive 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 may not detect the POSIX attributes defined in the child AD domain. In this case, Red Hat recommends that you explicitly choose the POSIX ID range type when establishing the trust.
-
To have SSSD automatically generate UIDs and GIDs for AD users based on their SID, select the
- Click Add.
Verification
If the trust has been successfully added to the IdM server, you can see the green pop-up window in the IdM Web UI. It means that the:
- Domain name exists
User name and password of the Windows Server has been added correctly.
Now you can continue to test the trust connection and Kerberos authentication.
9.4. Setting up a trust agreement using Ansible
Follow this procedure to set up a one-way trust agreement between Identity Management (IdM) and Active Directory (AD) by using an Ansible playbook. You can configure three types of trust agreements:
- One-way trust — default option. One-way trust enables Active Directory (AD) users and groups to access resources in IdM, but not the other way around. The IdM domain trusts the AD forest, but the AD forest does not trust the IdM domain.
Two-way trust — Two-way trust enables AD users and groups to access resources in IdM.
You must configure a two-way trust for solutions such as Microsoft SQL Server that expect the
S4U2Self
andS4U2Proxy
Microsoft extensions to the Kerberos protocol to work over a trust boundary. An application on a RHEL IdM host might requestS4U2Self
orS4U2Proxy
information from an Active Directory domain controller about an AD user, and a two-way trust provides this feature.Note that this two-way trust functionality does not allow IdM users to login to Windows systems, and the two-way trust in IdM does not give the users any additional rights compared to the one-way trust solution in AD.
-
To create the two-way trust, add the following variable to the playbook task below:
two_way: true
-
To create the two-way trust, add the following variable to the playbook task below:
External trust — a trust relationship between IdM and an AD domain in different forests. While a forest trust always requires establishing a trust between IdM and the root domain of an Active Directory forest, an external trust can be established from IdM to a domain within a forest. This is only recommended if it is not possible to establish a forest trust between forest root domains due to administrative or organizational reasons.
-
To create the external trust, add the following variable to the playbook task below:
external: true
-
To create the external trust, add the following variable to the playbook task below:
Prerequisites
- User name and password of a Windows administrator.
-
The IdM
admin
password. - You have prepared the IdM server for the trust.
-
You are using the 4.8.7 version of IdM or later. To view the version of IdM you have installed on your server, run
ipa --version
. You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipa
package. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_password
.
-
The target node, that is the node on which the
ansible-freeipa
module is executed, is part of the IdM domain as an IdM client, server or replica.
Procedure
Navigate to your ~/MyPlaybooks/ directory:
$ cd ~/MyPlaybooks/
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
andgidNumber
, create anadd-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
oripa-ad-trust-posix
, by requesting details from AD domain controllers in the forest root domain, create anadd-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
WarningIf 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 may not detect the POSIX attributes defined in the child AD domain. In this case, Red Hat recommends that you explicitly choose the POSIX ID range type when establishing the trust.
- Save the file.
Run the Ansible playbook. Specify the playbook file, the file storing the password protecting the secret.yml file, and the inventory file:
$ ansible-playbook --vault-password-file=password_file -v -i inventory add-trust.yml
Additional resources
- /usr/share/doc/ansible-freeipa/README-trust.md
- /usr/share/doc/ansible-freeipa/playbooks/trust
9.5. Verifying the Kerberos configuration
To verify the Kerberos configuration, test if it is possible to obtain a ticket for an Identity Management (IdM) user and if the IdM user can request service tickets.
Procedure
Request a ticket for an Active Directory (AD) user:
[root@ipaserver ~]# kinit user@AD.EXAMPLE.COM
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 System Security Services Daemon (SSSD) user names. This allows AD users to use Kerberos authentication and access Linux services, which support GSSAPI authentication directly.
9.6. Verifying the trust configuration on IdM
Before configuring trust, verify that the Identity Management (IdM) and Active Directory (AD) servers can resolve themselves and each other.
Prerequisites
- You need to be logged in with administrator privileges.
Procedure
Run a DNS query for the MS DC Kerberos over UDP and LDAP over TCP service records.
[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 ifipa-adtrust-install
has not been executed on any IdM server, which is typically before establishing the first trust relationship.Run a DNS query for the Kerberos and LDAP over TCP service records to verify that IdM is able to resolve service records for AD:
[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.
9.7. Verifying the trust configuration on AD
After configuring the trust, verify that:
- The Identity Management (IdM)-hosted services are resolvable from the Active Directory (AD) server.
- AD services are resolvable from the AD server.
Prerequisites
- You need to be logged in with administrator privileges.
Procedure
On the AD server, set the
nslookup.exe
utility to look up service records.C:\>nslookup.exe > set type=SRV
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
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"
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 theipa server-role-find --role 'AD trust controller'
command.Verify that AD services are resolvable from the AD server.
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
9.8. Creating a trust agent
A trust agent is an IdM server that can perform identity lookups against AD domain controllers.
For example, if you are creating a replica of an IdM server that has a trust with Active Directory, you can set up the replica as a trust agent. A replica does not automatically have the AD trust agent role installed.
Prerequisites
- IdM is installed with an Active Directory trust.
-
The
sssd-tools
package is installed.
Procedure
On an existing trust controller, run the
ipa-adtrust-install --add-agents
command:[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.
Restart the IdM service on the trust agent.
[root@new_trust_agent]# ipactl restart
Remove all entries from the SSSD cache on the trust agent:
[root@new_trust_agent]# sssctl cache-remove
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
Additional resources
-
ipa-adtrust-install(1)
man page on your system - Trust controllers and trust agents
9.9. Enabling automatic private group mapping for a POSIX ID range on the CLI
By default, SSSD does not map private groups for Active Directory (AD) users if you have established a POSIX trust that relies on POSIX data stored in AD. If any AD users do not have primary groups configured, IdM is not be able to resolve them.
This procedure explains how to enable automatic private group mapping for an ID range by setting the hybrid
option for the auto_private_groups
SSSD parameter on the command line. As a result, IdM is able to resolve AD users that do not have primary groups configured in AD.
Prerequisites
- You have successfully established a POSIX cross-forest trust between your IdM and AD environments.
Procedure
Display all ID ranges and make note of the AD ID range you want to modify.
[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 ----------------------------
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
Reset the SSSD cache to enable the new setting.
[root@server ~]# sss_cache -E
Additional resources
9.10. Enabling automatic private group mapping for a POSIX ID range in the IdM WebUI
By default, SSSD does not map private groups for Active Directory (AD) users if you have established a POSIX trust that relies on POSIX data stored in AD. If any AD users do not have primary groups configured, IdM is not be able to resolve them.
This procedure explains how to enable automatic private group mapping for an ID range by setting the hybrid
option for the auto_private_groups
SSSD parameter in the Identity Management (IdM) WebUI. As a result, IdM is able to resolve AD users that do not have primary groups configured in AD.
Prerequisites
- You have successfully established a POSIX cross-forest trust between your IdM and AD environments.
Procedure
- Log into the IdM Web UI with your user name and password.
-
Open the IPA Server
ID Ranges tab. -
Select the ID range you want to modify, such as
AD.EXAMPLE.COM_id_range
. From the Auto private groups drop down menu, select the
hybrid
option.- Click the Save button to save your changes.
Additional resources