We have observed this behavior too when using external trusts from machines that both have
external trusts to our account domains. Ie our windows resource domain and our IPA domain
both have external trusts with the account domain.
We have used the GPOs to point our windows boxes to IPA where needed.
Verzonden vanaf mijn Samsung-apparaat
-------- Oorspronkelijk bericht --------
Van: Alexander Bokovoy via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org>
Datum: 22-06-17 04:53 (GMT+01:00)
Aan: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
Cc: Robert Johnson <igorvt77(a)gmail.com>, Alexander Bokovoy
<abokovoy(a)redhat.com>
Onderwerp: [Freeipa-users] Re: GSSAPI login from trusted AD domain to FreeIPA clients not
working
On ke, 21 kesä 2017, Alexander Bokovoy via FreeIPA-users wrote:
On ke, 21 kesä 2017, Robert Johnson via FreeIPA-users wrote:
>For what its worth, I dug through my emails with Red Hat tech support and
>this is what we got back from the Identity Management support team:
>-----------
>
>I did some additional research and found another customer which had a
>similar issue - our IPA development team has added some additional comments
>on this:
>
> The external trust in AD has no explicit routing to the trusted
>domain(no name suffix routing table). It may be a bug in putty as in the
>Windows console it is possible to obtain a ticket for the explicitly IPA
>host service principal. For non-external forest trust, things work well.
>
>-----------
Yes. The issue as I reproduced is not about those additional domains.
Additional domains will never work with external trust by definition. It
is about the primary IPA domain.
E.g. you have
ipa.example.com and
ad.example.com +
child.ad.example.com.
You want to establish external trust to
child.ad.example.com from
ipa.example.com. This should make possible users from
child.ad.example.com to access machines in
ipa.example.com with GSSAPI.
However, it should not be able to access machines in
child.ipa.example.com subdomain because that's against the very
definition of the external trust -- it is not transitive.
What happens instead is that even if external trust is established
between
ipa.example.com and
child.ad.example.com, users from
child.ad.example.com cannot authenticate with GSSAPI against hosts in
ipa.example.com. This is a bug, it seems.
This one still is a puzzle.
We reproduced external trust between two child domains of two different
forests using latest builds of Windows Server 2016. While looking at the
trust properties, I can see that Windows does set a bit different flags.
So I set these flags and re-established external trust between IPA and
Windows Server 2016-based child domain and there was no change in
behavior.
There is more. Talking to Microsoft Kerberos people, we found that
'external trust' feature was originally designed to make NT4 domain
trusted by Active Directory. As such, NT4-style domains don't handle
Kerberos, so we've got claims that Kerberos authentication should not be
working across external trusts at all -- at least it is not tested by
Microsoft with each release. This puzzles even more.
Here is what I found:
- if your credentials do not have a service ticket to a remote service
you want to access, e.g. ldap/ipa-master.ipa.example.com(a)IPA.EXAMPLE.COM
when talking to IPA LDAP server, Windows ldp.exe (LDAP browser) will
attempt to use SASL NTLMSSP to authenticate. E.g. it is doing a
password auth.
- However, if you obtained a service ticket before calling the app,
Windows will happily use the ticket and will authenticate with SASL
GSS-SPNEGO. E.g. it is doing Kerberos auth.
So it seems that Kerberos authentication exists in kind of a parallel
space with external trust. If client knows where to talk to a foreign
KDC, it can and would do that. If client does not know where to talk to,
it will attempt to talk to its own AD DC and upon failure of obtaining a
ticket would revert to a password authentication.
I'm sure this is a regression because it used to work just fine in older
builds of Windows Server 2016 and in Windows Server 2012R2 or earlier.
Something did change and it is unlikely to be fixed if I understood
Microsoft engineers properly.
The GPO "solution" is short-circuiting selection of the
target KDC to
talk to for that ticket on the _client_. Without it Windows client will
send a request to its own DC and will get a proper referral back that
tells it "go talk to IPA DC". With GPO "solution" it will request
cross-realm TGT from its own DC and then talk directly to IPA DC. E.g.
decision to talk to IPA is done by the client, not by the KDC. The
latter has certain security consequences.
Finally, this GPO approach on the client
side does actually look as
something that can overcome this problem. Indeed. And it would probably
useful to cover a case where FreeIPA client would need to be placed in
the DNS domain of AD domain too. E.g. if IPA client
linux-client.example.com needs to be enrolled in IPA realm
IPA.EXAMPLE.COM but have its hostname in
example.com DNS zone, then a
GPO policy which explicitly maps
linux-client.example.com to
IPA.EXAMPLE.COM can be used to force all AD clients to properly talk to
IPA KDC when authenticating to
linux-client.example.com.
>
>On Wed, Jun 21, 2017 at 5:03 AM, Tiemen Ruiten <t.ruiten(a)rdmedia.com> wrote:
>
>>I tried the GPO and that actually worked, thanks Robert. I had to specify
>>all the subdomains we use as well in the value field (we have IPA-clients
>>in several subdomains of
i.rdmedia.com). It appears my issue is solved.
>>
>>Looking forward to hear what the Microsoft guys say.
>>
>>On 21 June 2017 at 00:41, Alexander Bokovoy <abokovoy(a)redhat.com> wrote:
>>
>>>On ti, 20 kesä 2017, Robert Johnson wrote:
>>>
>>>>I ran into this exact same problem with my IPA domain in a one way
>>>>external
>>>>trust to our Windows 2012 R2 AD forest. It appears that Microsoft may
>>>>have
>>>>removed the routing suffix option from the Windows 2012 R2 native forest
>>>>trust gui. My solution was to follow the instructions in the
"Define
>>>>host
>>>>name-to-Kerberos realm mappings" section of this document from
Microsoft:
>>>>https://support.microsoft.com/en-us/help/947706/windows-serv
>>>>er-2008-group-policy-settings-for-interoperability-with-non-
>>>>microsoft-kerberos-realms
>>>>
>>>This document is not about a type of trust FreeIPA is using in the case
>>>of external trust to AD (neither in a normal cross-forest trust).
>>>
>>>.
>>>>
>>>>Assuming the IPA realm name is the same as the domain name you would use:
>>>>Value Name:
I.RDMEDIA.COM
>>>>Value: .i.rdmedia.com (Notice the period at the beginning of the
>>>>domain name)
>>>>
>>>>I applied the GPO to all of my workstations (not the servers) but I
don't
>>>>see any harm across all the windows systems.
>>>>
>>>It looks like the GPO change is more of a Kerberos settings modification
>>>on AD side that basically is equivalent of krb5.conf's [domain_realm]
>>>section and is not really related to the technology of the trust.
>>>
>>>BTW, I reproduced the original issue in a lab at the interop here at
>>>Microsoft HQ and I'm going to talk to Microsoft guys to find out what is
>>>happening there in reality.
>>>
>>>
>>>
>>>>Rob Johnson
>>>>
>>>>On Tue, Jun 20, 2017 at 3:04 PM, Alexander Bokovoy via FreeIPA-users <
>>>>freeipa-users(a)lists.fedorahosted.org> wrote:
>>>>
>>>>On ti, 20 kesä 2017, Tiemen Ruiten via FreeIPA-users wrote:
>>>>>
>>>>>Please see the attached screenshot for the Trust settings, and thank
you
>>>>>>for your time.
>>>>>>
>>>>>>Thanks. I'm not sure why is that happening even for the
immediate
>>>>>forest
>>>>>root domain that
i.rdmedia.com is. I'll check with Microsoft doc
help
>>>>>team while here at the Redmond Interop 2017.
>>>>>
>>>>>
>>>>>--
>>>>>/ Alexander Bokovoy
>>>>>_______________________________________________
>>>>>FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>>>>>To unsubscribe send an email to freeipa-users-leave(a)lists.fedo
>>>>>rahosted.org
>>>>>
>>>>>
>>>--
>>>/ Alexander Bokovoy
>>>
>>
>>
>>
>>--
>>Tiemen Ruiten
>>Systems Engineer
>>R&D Media
>>
>_______________________________________________
>FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
--
/ Alexander Bokovoy
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
--
/ Alexander Bokovoy
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org