[Freeipa-users] Re: GSSAPI login from trusted AD domain to FreeIPA clients not working

[Alexander Bokovoy via FreeIPA-users]

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@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  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  wrote:


On ti, 20 kesä 2017, Robert Johnson 

[Freeipa-users] Re: GSSAPI login from trusted AD domain to FreeIPA clients not working

[Alexander Bokovoy via FreeIPA-users]

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.

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.




On Wed, Jun 21, 2017 at 5:03 AM, Tiemen Ruiten  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  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-le...@lists.fedo
rahosted.org



--
/ Alexander Bokovoy





--
Tiemen Ruiten
Systems Engineer
R Media




___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org



--
/ Alexander Bokovoy
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: GSSAPI login from trusted AD domain to FreeIPA clients not working

[Tiemen Ruiten via FreeIPA-users]

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  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-le...@lists.fedo
>>> rahosted.org
>>>
>>>
> --
> / Alexander Bokovoy
>



-- 
Tiemen Ruiten
Systems Engineer
R Media
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: GSSAPI login from trusted AD domain to FreeIPA clients not working

[Alexander Bokovoy via FreeIPA-users]

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-server-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-le...@lists.fedorahosted.org



--
/ Alexander Bokovoy
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: GSSAPI login from trusted AD domain to FreeIPA clients not working

[Robert Johnson via FreeIPA-users]

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-server-2008-group-policy-settings-for-interoperability-with-non-microsoft-kerberos-realms
.

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.

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-le...@lists.fedorahosted.org
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: GSSAPI login from trusted AD domain to FreeIPA clients not working

[Alexander Bokovoy via FreeIPA-users]

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-le...@lists.fedorahosted.org

[Freeipa-users] Re: GSSAPI login from trusted AD domain to FreeIPA clients not working

[Tiemen Ruiten via FreeIPA-users]

Please see the attached screenshot for the Trust settings, and thank you
for your time.

On 20 June 2017 at 19:36, Tiemen Ruiten  wrote:

> On 20 June 2017 at 18:07, Alexander Bokovoy  wrote:
>
>> On ti, 20 kesä 2017, Tiemen Ruiten via FreeIPA-users wrote:
>>
>>> Hello,
>>>
>>> I have a FreeIPA domain, i.rdmedia.com, (CentOS 7.3, fully up-to-date:
>>> rpm
>>> versions are 4.4.0-14.el7.centos.7) with a two-way, non-transitive,
>>> external trust to an Active Directory domain in another forest,
>>> clients.rdmedia.com, (Windows Server 2012R2). I've setup the trust using
>>> the Administrator credentials.
>>>
>>> As one of the final steps, I would like to get passwordless SSH-access
>>> using GSSAPI to work, but unfortunately I get the following error in the
>>> Putty log when connecting from an AD domain-joined client:
>>>
>>> Event Log: GSSAPI authentication initialisation failed
>>> Event Log: The target was not recognized
>>>
>> "Target was not recognized" means your AD DC does not know that
>> requests for services in .i.rdmedia.com domain must be routed to FreeIPA
>> DC.
>> What does
>>
>>  netdom trust clients.rdmedia.com /namesuffixes:i.rdmedia.com
>>
>> say on clients.rdmedia.com's DC?
>
>
> It says: The parameter is incorrect.
>
> Actually, I don't see the Name Suffix Routing tab in the incoming/outgoing
> trust properties either, only the General and Authentication tabs.
>
>
>>
>> --
>> / Alexander Bokovoy
>>
>
>


-- 
Tiemen Ruiten
Systems Engineer
R Media
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: GSSAPI login from trusted AD domain to FreeIPA clients not working

[Tiemen Ruiten via FreeIPA-users]

On 20 June 2017 at 18:07, Alexander Bokovoy  wrote:

> On ti, 20 kesä 2017, Tiemen Ruiten via FreeIPA-users wrote:
>
>> Hello,
>>
>> I have a FreeIPA domain, i.rdmedia.com, (CentOS 7.3, fully up-to-date:
>> rpm
>> versions are 4.4.0-14.el7.centos.7) with a two-way, non-transitive,
>> external trust to an Active Directory domain in another forest,
>> clients.rdmedia.com, (Windows Server 2012R2). I've setup the trust using
>> the Administrator credentials.
>>
>> As one of the final steps, I would like to get passwordless SSH-access
>> using GSSAPI to work, but unfortunately I get the following error in the
>> Putty log when connecting from an AD domain-joined client:
>>
>> Event Log: GSSAPI authentication initialisation failed
>> Event Log: The target was not recognized
>>
> "Target was not recognized" means your AD DC does not know that
> requests for services in .i.rdmedia.com domain must be routed to FreeIPA
> DC.
> What does
>
>  netdom trust clients.rdmedia.com /namesuffixes:i.rdmedia.com
>
> say on clients.rdmedia.com's DC?


It says: The parameter is incorrect.

Actually, I don't see the Name Suffix Routing tab in the incoming/outgoing
trust properties either, only the General and Authentication tabs.


>
> --
> / Alexander Bokovoy
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org