1:58 a.m.
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
3:08 a.m.
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
10:45 p.m.
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(a)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
1:26 a.m.
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...
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.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
2:13 a.m.
On Fri, Oct 18, 2019 at 8:26 AM Alexander Bokovoy <abokovoy(a)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
2:36 a.m.
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...
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
1651
days inactive
1653
days old
freeipa-users@lists.fedorahosted.org
5 comments
2 participants
participants (2)
-
Alexander Bokovoy -
Pieter Baele