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
Is it possible to configure GSSAPI authentication for a cross-forest trust or should I setup the trust as a 'Trusted Forest' ie. not external?
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?
On 20 June 2017 at 18:07, Alexander Bokovoy abokovoy@redhat.com 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
Please see the attached screenshot for the Trust settings, and thank you for your time.
On 20 June 2017 at 19:36, Tiemen Ruiten t.ruiten@rdmedia.com wrote:
On 20 June 2017 at 18:07, Alexander Bokovoy abokovoy@redhat.com 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
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.
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-po... .
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-leave@lists.fedorahosted.org
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-po...
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.fedorahosted.org
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
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.
-----------
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
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 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
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
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@lists.fedorahosted.org Datum: 22-06-17 04:53 (GMT+01:00) Aan: FreeIPA users list freeipa-users@lists.fedorahosted.org Cc: Robert Johnson igorvt77@gmail.com, Alexander Bokovoy abokovoy@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@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
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Robert Johnson -
Tiemen Ruiten -
wouter.hummelink＠kpn.com