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@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@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@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@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@lists.fedorahosted.org
>>>>>>To unsubscribe send an email to freeipa-users-leave@lists.fedo
>>>>>>rahosted.org
>>>>>>
>>>>>>
>>>>--
>>>>/ Alexander Bokovoy
>>>>
>>>
>>>
>>>
>>>--
>>>Tiemen Ruiten
>>>Systems Engineer
>>>R&D Media
>>>
>
>>_______________________________________________
>>FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>>To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
>
>
>--
>/ Alexander Bokovoy
>_______________________________________________
>FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
--
/ Alexander Bokovoy
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org