Bug 1914618
| Summary: | missing _kerberos._udp.dc._msdcs in Windows AD when integrated with IDM | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | kevin <welin> |
| Component: | ipa | Assignee: | Florence Blanc-Renaud <frenaud> |
| Status: | CLOSED NOTABUG | QA Contact: | ipa-qe <ipa-qe> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.8 | CC: | abokovoy, rcritten, tscherf |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-01-29 08:56:17 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
kevin
2021-01-10 09:49:21 UTC
The process is much more than just verifying DNS SRV records. It includes AD DC discovery according to Active Directory specifications. This discovery process actually happens on *both* sides -- AD DCs will do the same discovery against IPA trust controller when asked to verify trust. This is covered in the [MS-ADTS] specification, section 6.3.6, Locating Domain Controller, which has two parts: 1. Locating Domain Controller using DNS-based discovery: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/7fcdce70-5205-44d6-9c3a-260e616a2f04 2. Locating Domain Controller using NetbIOS-based discovery: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/bbd104fb-7d78-44d5-9e50-48ea120a0d91 Perhaps, more commonly this described in section 6.3 itself: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/8ebcf782-87fd-4dc3-8585-1301569dfe4f Both approaches require communication with the target domain controller using what is called 'LDAP ping' or 'Mailslot ping' (in the NetBIOS-based discovery). The backend operation is the same, just the protocol to send 'ping' is different. DNS-based discovery sends it over LDAP UDP: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/59614181-6ddd-4f46-8603-5e716737c99a Microsoft also has the troubleshooting article which digests this information in more user-friendly way: https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/how-domain-controllers-are-located In conclusion, there is more to verify than just SRV records and the way it is done also depends on whether firewall is permitting the access. We have to adhere to AD requirements, so it is all described in AD documentation and not in RHEL IdM documentation. Now, to your specific question about _kerberos._udp.dc._msdcs records. Depending on the type of an AD DC, this record can be registered or can be missing. Non-RODC domain controllers should have UDP SRV record but practice show that many administrators omit it -- a reason is that PAC records in the Kerberos tickets are larger than what UDP transport can take and thus most likely a retransmission will be required using TCP transport. This is covered in [MS-ADTS] 6.3.2.3 'SRV Records': https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/c1987d42-1847-4cc9-acf7-aab2136d6952. On IPA side, we configure MIT Kerberos to always try TCP transport instead of UDP. We set udp_preference_limit = 0 in /etc/krb5.conf to disable UDP transport in Kerberos protocol and use TCP directly. If you have clients that do not have this setting in krb5.conf, they'd try UDP first and thus would require UDP SRV records to exist. Kevin, does my comment 2 address your questions? I am considering to close this bug because there is nothing actionable left for us. CLOSED I want to close this bug, but I don't know where can modify the status to close Thanks. Closing. The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days |