7장. Configuring DNS and realm settings for a trust
Before you connect Identity Management (IdM) and Active Directory (AD) in a trust, ensure that servers see each other and resolve domain names correctly.
To configure domain name resolution between:
- A primary IdM server using integrated DNS server and Certification Authority (CA)
- An AD Domain Controller
Perform the following tasks:
- Configure DNS zones on the IdM server
- Configure conditional DNS forwarding on the AD server
- Verify correctness of the DNS configuration
7.1. Unique primary DNS domains 링크 복사링크가 클립보드에 복사되었습니다!
In Windows, every domain is a Kerberos realm and a DNS domain at the same time. Every domain managed by the domain controller needs to have its own dedicated DNS zone. The same applies when Identity Management (IdM) is trusted by Active Directory (AD) as a forest. AD expects IdM to have its own DNS domain. For the trust setup to work, the DNS domain must be dedicated to the Linux environment.
Each system must have its own unique primary DNS domain configured. For example:
-
ad.example.comfor AD andidm.example.comfor IdM -
example.comfor AD andidm.example.comfor IdM -
ad.example.comfor AD andexample.comfor IdM
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.
- Kerberos realm names as upper-case versions of primary DNS domain names
-
Kerberos realm names must match the primary DNS domain names, with all letters uppercase. For example, if the domain names are
ad.example.comfor AD andidm.example.comfor IdM, the Kerberos realm names are required to beAD.EXAMPLE.COMandIDM.EXAMPLE.COM. - DNS records resolvable from all DNS domains in the trust
- All machines must resolve DNS records from all DNS domains involved in the trust relationship.
- IdM and AD DNS Domains
- Systems joined to IdM can be distributed over multiple DNS domains. Deploy IdM clients in a DNS zone separate from those managed by Active Directory. The primary IdM DNS domain must have proper SRV records to support AD trusts.
In some environments with trusts between IdM and AD, 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. See Configuring IdM clients in an Active Directory DNS domain for more details.
You can acquire a list of the required SRV records specific to your system setup by running the following command:
$ ipa dns-update-system-records --dry-run
The generated list can look for example like this:
IPA DNS records:
_kerberos-master._tcp.idm.example.com. 86400 IN SRV 0 100 88 server.idm.example.com.
_kerberos-master._udp.idm.example.com. 86400 IN SRV 0 100 88 server.idm.example.com.
_kerberos._tcp.idm.example.com. 86400 IN SRV 0 100 88 server.idm.example.com.
_kerberos._tcp.idm.example.com. 86400 IN SRV 0 100 88 server.idm.example.com.
_kerberos.idm.example.com. 86400 IN TXT "IDM.EXAMPLE.COM"
_kpasswd._tcp.idm.example.com. 86400 IN SRV 0 100 464 server.idm.example.com.
_kpasswd._udp.idm.example.com. 86400 IN SRV 0 100 464 server.idm.example.com.
_ldap._tcp.idm.example.com. 86400 IN SRV 0 100 389 server.idm.example.com.
_ipa-ca.idm.example.com. 86400 IN A 192.168.122.2
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.