Issues with SSO from AD Clients

[Hannes Eberhardt]

Hi,

I am currently evaluating FreeIPA for a deployment in our department and I am running into
problems with GSSAPI authentication from AD managed Windows clients to IPA managed
servers.

The situation:
We do want to build an IPA domain for our departments' Linux infrastructure. Our plan
is to create a trust between our IPA domain to the existing Active Directory so that we
can continue to use our regular office workstations for managing our systems. 
So far so good, we got the trust set up together with our IT department and
username/password authentication works as expected. 
The only issue I am facing right now is that we can't do a GSSAPI based authentication
to a FreeIPA client system.
We are running FreeIPA under CentOS 8 from the official repositories. Version 4.8.4.
Active Directory runs on Server 2016 (Forest Functional Level and Domain Functional Level
are both 2012R2).

We (our department and the rest of the company) do have completely separated DNS domains.
Let's say the AD is running within the domain example.int and realm EXAMPLE.INT, our
primary DNS domain is example.com and our Kerberos Realm is IDM.EXAMPLE.COM. FreeIPA is of
course also running the authoritative nameserver for idm.example.com.

As to the IPA clients:
We currently do not plan to enroll our IPA clients directly underneath the idm.example.com
domain, but under serveral (sub-)domains under example.com (e.g. dc.example.com /
site1.example.com / staging.example.com). 
And here comes the pitfall: If I enroll a FreeIPA client directly the subdomain
idm.example.com (e.g ipaclient.idm.example.com) we are able to do a proper GSSAPI
authentication from our AD managed workstation. If we do enroll them in any other
subdomain. The AD clients or AD DCs are not able to map the domains to the right kerberos
realms.
We checked the suffix routing at the AD side of the trust and noticed, that there is only
a route with the domain *.idm.example.com.

So what I did and still are trying to do are basically two things:

First thing:
In my opiniont it would be the cleanest solution to just get the whole example.com domain
routed to our FreeIPA system. So what I did was:
I deleted the trust again and added the entry example.com to the 'Realm Domains'
tab in the Web UI. I am not sure if this is the right place to put it, because after this
I was not able to establish a new trust, it just failed with the following in the httpd
error_log.

[Wed Aug 12 09:32:40.973936 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
10.100.7.223:59760] ipa: ERROR: non-public: NTSTATUSError: (3221225485, 'An invalid
parameter was passed to a service or function.')
[Wed Aug 12 09:32:40.973975 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
10.100.7.223:59760] Traceback (most recent call last):
[Wed Aug 12 09:32:40.973977 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
10.100.7.223:59760]   File
"/usr/lib/python3.6/site-packages/ipaserver/rpcserver.py", line 368, in
wsgi_execute
[Wed Aug 12 09:32:40.973979 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
10.100.7.223:59760]     result = command(*args, **options)
[Wed Aug 12 09:32:40.973981 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
10.100.7.223:59760]   File
"/usr/lib/python3.6/site-packages/ipalib/frontend.py", line 450, in __call__
[Wed Aug 12 09:32:40.973983 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
10.100.7.223:59760]     return self.__do_call(*args, **options)
[Wed Aug 12 09:32:40.973985 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
10.100.7.223:59760]   File
"/usr/lib/python3.6/site-packages/ipalib/frontend.py", line 478, in __do_call
[Wed Aug 12 09:32:40.973987 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
10.100.7.223:59760]     ret = self.run(*args, **options)
[Wed Aug 12 09:32:40.973989 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
10.100.7.223:59760]   File
"/usr/lib/python3.6/site-packages/ipalib/frontend.py", line 800, in run
[Wed Aug 12 09:32:40.973991 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
10.100.7.223:59760]     return self.execute(*args, **options)
[Wed Aug 12 09:32:40.973992 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
10.100.7.223:59760]   File
"/usr/lib/python3.6/site-packages/ipaserver/plugins/trust.py", line 758, in
execute
[Wed Aug 12 09:32:40.974009 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
10.100.7.223:59760]     result = self.execute_ad(full_join, *keys, **options)
[Wed Aug 12 09:32:40.974011 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
10.100.7.223:59760]   File
"/usr/lib/python3.6/site-packages/ipaserver/plugins/trust.py", line 1019, in
execute_ad
[Wed Aug 12 09:32:40.974013 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
10.100.7.223:59760]     trust_type
[Wed Aug 12 09:32:40.974014 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
10.100.7.223:59760]   File
"/usr/lib/python3.6/site-packages/ipaserver/dcerpc.py", line 1732, in
join_ad_full_credentials
[Wed Aug 12 09:32:40.974016 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
10.100.7.223:59760]     trust_type, trust_external)
[Wed Aug 12 09:32:40.974018 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
10.100.7.223:59760]   File
"/usr/lib/python3.6/site-packages/ipaserver/dcerpc.py", line 1415, in
establish_trust
[Wed Aug 12 09:32:40.974020 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
10.100.7.223:59760]     self.update_ftinfo(another_domain)
[Wed Aug 12 09:32:40.974022 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
10.100.7.223:59760]   File
"/usr/lib/python3.6/site-packages/ipaserver/dcerpc.py", line 1286, in
update_ftinfo
[Wed Aug 12 09:32:40.974024 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
10.100.7.223:59760]     ftinfo, 0)
[Wed Aug 12 09:32:40.974027 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
10.100.7.223:59760] samba.NTSTATUSError: (3221225485, 'An invalid parameter was passed
to a service or function.')
[Wed Aug 12 09:32:40.974032 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
10.100.7.223:59760]

The second thing:
I found an older thread that stated one could configure domain-to-realm maps on each
client (via GPO).
This is something I am still troublshooting because I first tried to put the mapping in my
local registry, but this seems to not work. I have to check this again together with a
colleague of our IT department.
But this solution is definitly not my first choice as it forces the clients to do the
mapping, as we are going to deliver services to the complete company this would mean our
IT must roll out this GPO to all systems. I would rather try to get our whole domain
mapped to our realm on DC side.

To get to the actual question:
Is Realm Domains the right place to put our complete domain or is this a bug in FreeIPA?
An if it is not the right place: Where can I put it then?

Thanks for your help,

Hannes

[Sumit Bose]

On Thu, Aug 13, 2020 at 07:16:29AM -0000, Hannes Eberhardt via FreeIPA-users wrote:
>  Hi,
>  
>  I am currently evaluating FreeIPA for a deployment in our department and I am running
> into problems with GSSAPI authentication from AD managed Windows clients to IPA managed
> servers.
>  
>  The situation:
>  We do want to build an IPA domain for our departments' Linux infrastructure. Our plan
> is to create a trust between our IPA domain to the existing Active Directory so that we
> can continue to use our regular office workstations for managing our systems. 
>  So far so good, we got the trust set up together with our IT department and
> username/password authentication works as expected. 
>  The only issue I am facing right now is that we can't do a GSSAPI based
> authentication to a FreeIPA client system.
>  We are running FreeIPA under CentOS 8 from the official repositories. Version 4.8.4.
>  Active Directory runs on Server 2016 (Forest Functional Level and Domain Functional Level
> are both 2012R2).
>  
>  We (our department and the rest of the company) do have completely separated DNS domains.
> Let's say the AD is running within the domain example.int and realm EXAMPLE.INT, our
> primary DNS domain is example.com and our Kerberos Realm is IDM.EXAMPLE.COM. FreeIPA is of
> course also running the authoritative nameserver for idm.example.com.
>  
>  As to the IPA clients:
>  We currently do not plan to enroll our IPA clients directly underneath the
> idm.example.com domain, but under serveral (sub-)domains under example.com (e.g.
> dc.example.com / site1.example.com / staging.example.com).  
Hi,

have you made IPA and hence AD aware that IPA should handle those
domains with the 'ipa realmdomains-mod ....' ?

HTH

bye,
Sumit

>  And here comes the pitfall: If I enroll a FreeIPA client directly the
> subdomain idm.example.com (e.g ipaclient.idm.example.com) we are able to do a proper
> GSSAPI authentication from our AD managed workstation. If we do enroll them in any other
> subdomain. The AD clients or AD DCs are not able to map the domains to the right kerberos
> realms.
>  We checked the suffix routing at the AD side of the trust and noticed, that there is only
> a route with the domain *.idm.example.com.
>  
>  So what I did and still are trying to do are basically two things:
>  
>  First thing:
>  In my opiniont it would be the cleanest solution to just get the whole example.com domain
> routed to our FreeIPA system. So what I did was:
>  I deleted the trust again and added the entry example.com to the 'Realm Domains'
> tab in the Web UI. I am not sure if this is the right place to put it, because after this
> I was not able to establish a new trust, it just failed with the following in the httpd
> error_log.
>  
>  [Wed Aug 12 09:32:40.973936 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760] ipa: ERROR: non-public: NTSTATUSError: (3221225485, 'An invalid
> parameter was passed to a service or function.')
>  [Wed Aug 12 09:32:40.973975 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760] Traceback (most recent call last):
>  [Wed Aug 12 09:32:40.973977 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]   File
> "/usr/lib/python3.6/site-packages/ipaserver/rpcserver.py", line 368, in
> wsgi_execute
>  [Wed Aug 12 09:32:40.973979 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]     result = command(*args, **options)
>  [Wed Aug 12 09:32:40.973981 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]   File
> "/usr/lib/python3.6/site-packages/ipalib/frontend.py", line 450, in __call__
>  [Wed Aug 12 09:32:40.973983 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]     return self.__do_call(*args, **options)
>  [Wed Aug 12 09:32:40.973985 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]   File
> "/usr/lib/python3.6/site-packages/ipalib/frontend.py", line 478, in __do_call
>  [Wed Aug 12 09:32:40.973987 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]     ret = self.run(*args, **options)
>  [Wed Aug 12 09:32:40.973989 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]   File
> "/usr/lib/python3.6/site-packages/ipalib/frontend.py", line 800, in run
>  [Wed Aug 12 09:32:40.973991 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]     return self.execute(*args, **options)
>  [Wed Aug 12 09:32:40.973992 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]   File
> "/usr/lib/python3.6/site-packages/ipaserver/plugins/trust.py", line 758, in
> execute
>  [Wed Aug 12 09:32:40.974009 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]     result = self.execute_ad(full_join, *keys, **options)
>  [Wed Aug 12 09:32:40.974011 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]   File
> "/usr/lib/python3.6/site-packages/ipaserver/plugins/trust.py", line 1019, in
> execute_ad
>  [Wed Aug 12 09:32:40.974013 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]     trust_type
>  [Wed Aug 12 09:32:40.974014 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]   File
> "/usr/lib/python3.6/site-packages/ipaserver/dcerpc.py", line 1732, in
> join_ad_full_credentials
>  [Wed Aug 12 09:32:40.974016 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]     trust_type, trust_external)
>  [Wed Aug 12 09:32:40.974018 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]   File
> "/usr/lib/python3.6/site-packages/ipaserver/dcerpc.py", line 1415, in
> establish_trust
>  [Wed Aug 12 09:32:40.974020 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]     self.update_ftinfo(another_domain)
>  [Wed Aug 12 09:32:40.974022 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]   File
> "/usr/lib/python3.6/site-packages/ipaserver/dcerpc.py", line 1286, in
> update_ftinfo
>  [Wed Aug 12 09:32:40.974024 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]     ftinfo, 0)
>  [Wed Aug 12 09:32:40.974027 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760] samba.NTSTATUSError: (3221225485, 'An invalid parameter was passed
> to a service or function.')
>  [Wed Aug 12 09:32:40.974032 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]
>  
>  The second thing:
>  I found an older thread that stated one could configure domain-to-realm maps on each
> client (via GPO).
>  This is something I am still troublshooting because I first tried to put the mapping in
> my local registry, but this seems to not work. I have to check this again together with a
> colleague of our IT department.
>  But this solution is definitly not my first choice as it forces the clients to do the
> mapping, as we are going to deliver services to the complete company this would mean our
> IT must roll out this GPO to all systems. I would rather try to get our whole domain
> mapped to our realm on DC side.
>  
>  To get to the actual question:
>  Is Realm Domains the right place to put our complete domain or is this a bug in FreeIPA?
>  An if it is not the right place: Where can I put it then?
>  
>  Thanks for your help,
>  
>  Hannes
>  _______________________________________________
>  FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail]...

[Hannes Eberhardt]

Hi Sumit,

First: Yes I also tried to add our domain example.com with the ipa realmdomains-mod
command.

But isn't the ipa realmdomains-mod the cli equivalent to the Realm Domains tab in the
WebUI?

Thanks

Hannes

[Alexander Bokovoy]

On to, 13 elo 2020, Hannes Eberhardt via FreeIPA-users wrote:
> Hi,
>
> I am currently evaluating FreeIPA for a deployment in our department
> and I am running into problems with GSSAPI authentication from AD
> managed Windows clients to IPA managed servers.
>
> The situation:
> We do want to build an IPA domain for our departments' Linux
> infrastructure. Our plan is to create a trust between our IPA domain to
> the existing Active Directory so that we can continue to use our
> regular office workstations for managing our systems.
>
> So far so good, we got the trust set up together with our IT department
> and username/password authentication works as expected.
>
> The only issue I am facing right now is that we can't do a GSSAPI based
> authentication to a FreeIPA client system.
>
> We are running FreeIPA under CentOS 8 from the official repositories. Version 4.8.4.
>
> Active Directory runs on Server 2016 (Forest Functional Level and Domain Functional Level
> are both 2012R2).
>
> We (our department and the rest of the company) do have completely
> separated DNS domains. Let's say the AD is running within the domain
> example.int and realm EXAMPLE.INT, our primary DNS domain is
> example.com and our Kerberos Realm is IDM.EXAMPLE.COM. FreeIPA is of
> course also running the authoritative nameserver for idm.example.com.
>
> As to the IPA clients:
> We currently do not plan to enroll our IPA clients directly underneath the idm.example.com
> domain, but under serveral (sub-)domains under example.com (e.g. dc.example.com /
> site1.example.com / staging.example.com).
>
> And here comes the pitfall: If I enroll a FreeIPA client directly the
> subdomain idm.example.com (e.g ipaclient.idm.example.com) we are able
> to do a proper GSSAPI authentication from our AD managed workstation.
> If we do enroll them in any other subdomain. The AD clients or AD DCs
> are not able to map the domains to the right kerberos realms.
>
> We checked the suffix routing at the AD side of the trust and noticed,
> that there is only a route with the domain *.idm.example.com. 
Do you have those separate DNS domains mentioned in the realm domains
associated with IPA?

   $ kinit admin
   $ ipa realmdomains-show

If that only shows idm.example.com, then you need to manually add the
remainig DNS domains with

   $ ipa realmdomains-mod --add-domain dc.example.com

and refresh the suffix routing from AD side. If the refresh doesn't
work, you'd need to re-establish trust again, during this process we
update the topology on AD side. This only works when using AD
administrative credentials, obviously.

> So what I did and still are trying to do are basically two things:
>
> First thing:
> In my opiniont it would be the cleanest solution to just get the whole
> example.com domain routed to our FreeIPA system. So what I did was:
>
> I deleted the trust again and added the entry example.com to the 'Realm
> Domains' tab in the Web UI. I am not sure if this is the right place to
> put it, because after this I was not able to establish a new trust, it
> just failed with the following in the httpd error_log.
>
> [Wed Aug 12 09:32:40.973936 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760] ipa: ERROR: non-public: NTSTATUSError: (3221225485, 'An invalid
> parameter was passed to a service or function.')
> [Wed Aug 12 09:32:40.973975 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760] Traceback (most recent call last):
> [Wed Aug 12 09:32:40.973977 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]   File
> "/usr/lib/python3.6/site-packages/ipaserver/rpcserver.py", line 368, in
> wsgi_execute
> [Wed Aug 12 09:32:40.973979 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]     result = command(*args, **options)
> [Wed Aug 12 09:32:40.973981 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]   File
> "/usr/lib/python3.6/site-packages/ipalib/frontend.py", line 450, in __call__
> [Wed Aug 12 09:32:40.973983 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]     return self.__do_call(*args, **options)
> [Wed Aug 12 09:32:40.973985 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]   File
> "/usr/lib/python3.6/site-packages/ipalib/frontend.py", line 478, in __do_call
> [Wed Aug 12 09:32:40.973987 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]     ret = self.run(*args, **options)
> [Wed Aug 12 09:32:40.973989 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]   File
> "/usr/lib/python3.6/site-packages/ipalib/frontend.py", line 800, in run
> [Wed Aug 12 09:32:40.973991 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]     return self.execute(*args, **options)
> [Wed Aug 12 09:32:40.973992 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]   File
> "/usr/lib/python3.6/site-packages/ipaserver/plugins/trust.py", line 758, in
> execute
> [Wed Aug 12 09:32:40.974009 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]     result = self.execute_ad(full_join, *keys, **options)
> [Wed Aug 12 09:32:40.974011 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]   File
> "/usr/lib/python3.6/site-packages/ipaserver/plugins/trust.py", line 1019, in
> execute_ad
> [Wed Aug 12 09:32:40.974013 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]     trust_type
> [Wed Aug 12 09:32:40.974014 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]   File
> "/usr/lib/python3.6/site-packages/ipaserver/dcerpc.py", line 1732, in
> join_ad_full_credentials
> [Wed Aug 12 09:32:40.974016 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]     trust_type, trust_external)
> [Wed Aug 12 09:32:40.974018 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]   File
> "/usr/lib/python3.6/site-packages/ipaserver/dcerpc.py", line 1415, in
> establish_trust
> [Wed Aug 12 09:32:40.974020 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]     self.update_ftinfo(another_domain)
> [Wed Aug 12 09:32:40.974022 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]   File
> "/usr/lib/python3.6/site-packages/ipaserver/dcerpc.py", line 1286, in
> update_ftinfo
> [Wed Aug 12 09:32:40.974024 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760]     ftinfo, 0)
> [Wed Aug 12 09:32:40.974027 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760] samba.NTSTATUSError: (3221225485, 'An invalid parameter was passed
> to a service or function.')
> [Wed Aug 12 09:32:40.974032 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote
> 10.100.7.223:59760] 
You cannot define top level of the forest root as belonging to the
forest topology, this conflicts with the forest root entry in the
topology. See https://pagure.io/freeipa/issue/6666

So you should use realm domains entries that do not overlap with
existing forest root (idm.example.com):

   - dc.example.com
   - site1.example.com
   - ...

but you cannot use example.com realm domain entry because it conflicts
with idm.example.com and AD DCs do the validation according to the rules
in MS-ADTS 6.1.6.9.3.2.


-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Hannes Eberhardt]

Thanks for your fast reply.

I did'nt know that I must not use the root domain under the domain realms. Thanks for
the hint and the reference.
We configured the trust again, now with all relevant subdomains and SSO is now working.

I noticed only one thing after login: It seems that the GSSAPI Credential Delegation is
still not working.
I would assume to have a valid ticket from the example.int domain after login. As for now
I have to manually do a kinit and it prompts me for the AD user password. After that I
have a valid ticket.

Is this problem still related to some suffix routing problem or is this a new separat
issue?

Thanks,

Hannes

[Alexander Bokovoy]

On to, 13 elo 2020, Hannes Eberhardt via FreeIPA-users wrote:
> Thanks for your fast reply.
>
> I did'nt know that I must not use the root domain under the domain
> realms. Thanks for the hint and the reference.  We configured the trust
> again, now with all relevant subdomains and SSO is now working.
>
> I noticed only one thing after login: It seems that the GSSAPI
> Credential Delegation is still not working.  I would assume to have a
> valid ticket from the example.int domain after login. As for now I have
> to manually do a kinit and it prompts me for the AD user password.
> After that I have a valid ticket.
>
> Is this problem still related to some suffix routing problem or is this
> a new separat issue? 
It is a separate issue and is under control of AD DCs. Microsoft changed
defaults to disable delegation over forest trust in July 2019.

See thread
https://lists.fedorahosted.org/archives/list/[e-mail]...
for more details.



-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Hannes Eberhardt]

Thanks again for the the reference and being a huge help.

Hannes