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