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
_______________________________________________
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]
