2:16 a.m.
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