The only open issue we have with IPA is Windows clients not being directed to the Kerberos servers of the IPA realm.
We can solve this issue using domain_realm registry keys as mentioned on the mailing list before.
But is there any different method to accomplish this?
As far as I know/read, Windows clients only use SRV DNS records (and can fail back to NetBIOS-based discovery) to locate domain services, not TXT records. As IETF Kerberos Clarification drafts recommend against using (then) unsecured DNS for domain_realm mappings. So TXT DNS domain_realm mappings are also not an option.
Sincerely Pieter
On ke, 16 loka 2019, Pieter Baele via FreeIPA-users wrote:
The only open issue we have with IPA is Windows clients not being directed to the Kerberos servers of the IPA realm.
I think there is lack of a context here in your question.
For forest trust to Active Directory, all cross-realm routing is being done by AD DCs according to the topology associated with the trusted domain object. FreeIPA pushes out that information when trust is created and AD DCs follow it. We take all domains from the list maintained by realmdomains command.
So there is no need to have anything additional there. Windows clients will properly use SRV DNS records from primary IPA DNS domain. I think there is one missing DNS record right now that was found recently in FreeIPA 4.8.1: https://bugzilla.redhat.com/show_bug.cgi?id=1711958
However, this has nothing to do with Kerberos.
We do not support non-enrolled Windows configurations, so if by 'Windows clients' you mean exactly that, sorry, nothing can be done.
All Windows clients are properly enrolled into the AD domain.
We can't use two-way trust because of reasons you explained here before. A one-way external trust is used. All perfectly established and working, but somehow windows clients don't follow the topology.
By adding a domain_realm mapping to a windows client, also describe on FreeIPA-users before, the routing problem is solved. But I (and especially the AD admins ;-) ) would prefer to solve the underlying issue.
Thanks a lot, it is quite hard to find experts (with knowledge of both LDAP, AD and different Kerberos implementations)(we are reaching out to RH)
Sincerely Pieter
On Wed, 16 Oct 2019, 10:08 Alexander Bokovoy, abokovoy@redhat.com wrote:
On ke, 16 loka 2019, Pieter Baele via FreeIPA-users wrote:
The only open issue we have with IPA is Windows clients not being directed to the Kerberos servers of the IPA realm.
I think there is lack of a context here in your question.
For forest trust to Active Directory, all cross-realm routing is being done by AD DCs according to the topology associated with the trusted domain object. FreeIPA pushes out that information when trust is created and AD DCs follow it. We take all domains from the list maintained by realmdomains command.
So there is no need to have anything additional there. Windows clients will properly use SRV DNS records from primary IPA DNS domain. I think there is one missing DNS record right now that was found recently in FreeIPA 4.8.1: https://bugzilla.redhat.com/show_bug.cgi?id=1711958
However, this has nothing to do with Kerberos.
We do not support non-enrolled Windows configurations, so if by 'Windows clients' you mean exactly that, sorry, nothing can be done.
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
On pe, 18 loka 2019, Pieter Baele wrote:
All Windows clients are properly enrolled into the AD domain.
We can't use two-way trust because of reasons you explained here before. A one-way external trust is used. All perfectly established and working, but somehow windows clients don't follow the topology.
Ok, so this is the key information you did not say in the original email. ;)
External trust only works for the domain you trust directly, not for anything else. Remember that in Active Directory each DNS domain is considered a separate AD domain unless it is marked as top level name route in forest trust information. As far as I understand, the routing does not apply to externally trusted domains. At least, https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-se...) explicitly claims it in the table comparing external and forests trusts:
"Since it is an external trust, the cross-forest targets only cover the domains that have direct trusts. Only these DCs should be used to target Kerberos requests or Kerberos Forest Searches."
and just before that there is a generic explanation how the information about trust is stored -- note that for forest trust there is topology information (forest trust information attribute):
-------------------- External trusts are used to enable trusts between two domains that are in different forests. A forest trust is similar to an external trust between the root domains of both forests, but it takes the trust one step further to encompass all of the domains. The basic trust information (for both external trust and forest trust) is represented by a trusted domain object (TDO). The TDO for an external trust contains the name of the other domain with which the trust is established, its domain security identifier (SID), the trust direction, the type of trust, and some other attributes.
When there is a forest trust, the trust is marked as "Forest." The TDO also contains an additional Forest Trust Information attribute. The Forest Trust Information attribute contains information about all of the domains in the remote forest, the tree names, and any alternate name suffixes. This information is used to route authentication and lookups to the remote forest when needed. This information is propagated to the global catalogs so that any domain controller can look it up. The TDOs are stored in the Domain container that is in Active Directory.
The tree names and alternate name suffixes are stored in TopLevelName (or TLN) records. The DNS name, network basic input/output system (NetBIOS) name, and SID for every domain is stored in DomainInfo records. Because of this, the forest trust contains enough information to reasonably determine which services or users can reside in the other forest.
--------------------
By adding a domain_realm mapping to a windows client, also describe on FreeIPA-users before, the routing problem is solved. But I (and especially the AD admins ;-) ) would prefer to solve the underlying issue.
Don't use external trust, use forest trust. The effect you see is a design limit of external trust.
Thanks a lot, it is quite hard to find experts (with knowledge of both LDAP, AD and different Kerberos implementations)(we are reaching out to RH)
If you are reaching out to Red Hat support, your request will eventually get to my hands.
On Fri, Oct 18, 2019 at 8:26 AM Alexander Bokovoy abokovoy@redhat.com wrote:
On pe, 18 loka 2019, Pieter Baele wrote:
All Windows clients are properly enrolled into the AD domain.
We can't use two-way trust because of reasons you explained here before. A one-way external trust is used. All perfectly established and working, but somehow windows clients don't follow the topology.
Ok, so this is the key information you did not say in the original email. ;)
Yeah. Sorry :-)
External trust only works for the domain you trust directly, not for ....
Perfect explanation.
By adding a domain_realm mapping to a windows client, also describe on FreeIPA-users before, the routing problem is solved. But I (and especially the AD admins ;-) ) would prefer to solve the underlying issue.
Don't use external trust, use forest trust. The effect you see is a design limit of external trust.
The AD admins don't trust IdM ;-) Their Microsoft consultant/expert also thinks we are doing dangerous things. Conclusion: - they either have to choose between applying the GPO - or forest trust.
I understand completely, because there was a precedent because of some old interconnection between Samba as PDC and the AD domain. This required the AD domain to stay on an old functional level. Same thing with enctypes in Kerberos tickets
Thanks a lot, it is quite hard to find experts (with knowledge of both LDAP, AD and different Kerberos implementations)(we are reaching out to
RH) If you are reaching out to Red Hat support, your request will eventually get to my hands.
I know. Sometimes difficult when there is other support people in-between....
Thanks a lot, this made things very very clear
On pe, 18 loka 2019, Pieter Baele wrote:
By adding a domain_realm mapping to a windows client, also describe on FreeIPA-users before, the routing problem is solved. But I (and especially the AD admins ;-) ) would prefer to solve the underlying issue.
Don't use external trust, use forest trust. The effect you see is a design limit of external trust.
The AD admins don't trust IdM ;-) Their Microsoft consultant/expert also thinks we are doing dangerous things. Conclusion:
- they either have to choose between applying the GPO
- or forest trust.
I understand completely, because there was a precedent because of some old interconnection between Samba as PDC and the AD domain. This required the AD domain to stay on an old functional level. Same thing with enctypes in Kerberos tickets
I don't see how this applicable. FreeIPA is using the same method (forest trust) as Active Directory. Even Active Directory itself sees it as another Active Directory deployment. Forest trust has clear demarcation in terms of SID filtering and Kerberos ticket policy processing.
As you said, it is hard to find people who actually understand these complex technologies...
freeipa-users@lists.fedorahosted.org