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
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]

Reply via email to