freeipa

#8091 unable to reinstall ipa-client when ad trust is configured
Closed: worksforme by elytscha1. Opened by elytscha1.

Closed: worksforme
Reopen Issue

Request for enhancement

the functionallity to re-enroll a host when ad trust is configured should be available and not bug blocked

invoked client install command:

ipa-client-install -d --hostname=elias-rami.devops.lx.linux.at --server=freeipa74.lx.linux.at --domain=devops.lx.linux.at --ssh-trust-dns --mkhomedir --enable-dns-updates --configure-firefox --no-ntp --force-join

Issue

when a host is enrolled in freeipa with configured ad trust and you try to enroll it again it fails with:

Password for admin@LX.LINUX.AT: 
Initializing principal admin@LX.LINUX.AT using password
Starting external process
args=['/usr/bin/kinit', u'admin@LX.LINUX.AT', '-c', '/tmp/krbccPwYspG/ccache']
Process finished, return code=0
stdout=Password for admin@LX.LINUX.AT: 
stderr=
trying to retrieve CA cert via LDAP from freeipa74.lx.linux.at
get_ca_certs_from_ldap() error: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Server krbtgt/ACTIVEDIRECTORY.AT@LX.LINUX.AT not found in Kerberos database)
Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Server krbtgt/ACTIVEDIRECTORY.AT@LX.LINUX.AT not found in Kerberos database)
Unable to download CA cert from LDAP.
Do you want to download the CA cert from http://freeipa74.lx.linux.at/ipa/config/ca.crt?
(this is INSECURE) [no]: yes
Host: freeipa74.lx.linux.at
Accept: */*
Content-Type: text/xml
User-Agent: ipa-join/4.7.2
Referer: https://freeipa74.lx.linux.at/ipa/xml
X-Original-User-Agent: Xmlrpc-c/1.33.14 Curl/7.64.0
Content-Length: 481
* upload completely sent off: 481 out of 481 bytes
< HTTP/1.1 401 Unauthorized
< Date: Tue, 08 Oct 2019 14:08:53 GMT
< Server: Apache/2.4.37 (centos) OpenSSL/1.1.1 mod_auth_gssapi/1.6.1 mod_wsgi/4.6.4 Python/3.6
* gss_init_sec_context() failed: Server krbtgt/ACTIVEDIRECTORY.AT@LX.LINUX.AT not found in Kerberos database.
< WWW-Authenticate: Negotiate
* Added cookie ipa_session="" for domain freeipa74.lx.linux.at, path /ipa, expire 1
< Set-Cookie: ipa_session=;Max-Age=0;path=/ipa;httponly;secure;
< X-Frame-Options: DENY
< Content-Security-Policy: frame-ancestors 'none'
< Last-Modified: Tue, 25 Jun 2019 21:44:58 GMT
< Accept-Ranges: bytes
< Content-Length: 2719
< Cache-Control: no-cache
< Content-Type: text/html; charset=UTF-8
<
* Connection #0 to host freeipa74.lx.linux.at left intact
HTTP response code is 401, not 200
Installation failed. Rolling back changes.

Steps to Reproduce

  1. install freeipa
  2. configure onewaytrust do ad
  3. enroll client
  4. (you can try to delete everything on client machine from ipa-client-install and delete everything about this host in freeipa webinterface, it will make no difference)
  5. re-enroll client

Actual behavior

Password for admin@LX.LINUX.AT: 
Initializing principal admin@LX.LINUX.AT using password
Starting external process
args=['/usr/bin/kinit', u'admin@LX.LINUX.AT', '-c', '/tmp/krbccPwYspG/ccache']
Process finished, return code=0
stdout=Password for admin@LX.LINUX.AT: 
stderr=
trying to retrieve CA cert via LDAP from freeipa74.lx.linux.at
get_ca_certs_from_ldap() error: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Server krbtgt/ACTIVEDIRECTORY.AT@LX.LINUX.AT not found in Kerberos database)
Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Server krbtgt/ACTIVEDIRECTORY.AT@LX.LINUX.AT not found in Kerberos database)
Unable to download CA cert from LDAP.
Do you want to download the CA cert from http://freeipa74.lx.linux.at/ipa/config/ca.crt?
(this is INSECURE) [no]: yes
Host: freeipa74.lx.linux.at
Accept: */*
Content-Type: text/xml
User-Agent: ipa-join/4.7.2
Referer: https://freeipa74.lx.linux.at/ipa/xml
X-Original-User-Agent: Xmlrpc-c/1.33.14 Curl/7.64.0
Content-Length: 481
* upload completely sent off: 481 out of 481 bytes
< HTTP/1.1 401 Unauthorized
< Date: Tue, 08 Oct 2019 14:08:53 GMT
< Server: Apache/2.4.37 (centos) OpenSSL/1.1.1 mod_auth_gssapi/1.6.1 mod_wsgi/4.6.4 Python/3.6
* gss_init_sec_context() failed: Server krbtgt/ACTIVEDIRECTORY.AT@LX.LINUX.AT not found in Kerberos database.
< WWW-Authenticate: Negotiate
* Added cookie ipa_session="" for domain freeipa74.lx.linux.at, path /ipa, expire 1
< Set-Cookie: ipa_session=;Max-Age=0;path=/ipa;httponly;secure;
< X-Frame-Options: DENY
< Content-Security-Policy: frame-ancestors 'none'
< Last-Modified: Tue, 25 Jun 2019 21:44:58 GMT
< Accept-Ranges: bytes
< Content-Length: 2719
< Cache-Control: no-cache
< Content-Type: text/html; charset=UTF-8
<
* Connection #0 to host freeipa74.lx.linux.at left intact
HTTP response code is 401, not 200
Installation failed. Rolling back changes.

Expected behavior

client-install successfull with --force-join

Version/Release/Distribution

centos 8
$ rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server

ipa-server-4.7.1-11.module_el8.0.0+79+bbd20d7b.x86_64
ipa-client-4.7.1-11.module_el8.0.0+79+bbd20d7b.x86_64
ipa-server-4.7.1-11.module_el8.0.0+79+bbd20d7b.x86_64
ipa-client-4.7.1-11.module_el8.0.0+79+bbd20d7b.x86_64
389-ds-base-1.4.0.20-10.module_el8.0.0+46+21f6e250.x86_64
pki-ca-10.6.9-2.module_el8.0.0+51+16e82d22.noarch
krb5-server-1.16.1-22.el8.x86_64

Additional info:

Any additional information, configuration, data or log snippets that is needed for reproduction or investigation of the issue.

folks which already encounterd this failure:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/CE5IIHDILAHPBBWAAJZQ2DBRZEGKCWLC/
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/QUJMLUUPTDA5ASMSENZXMT6OMLE6ACYA/
https://www.redhat.com/archives/freeipa-devel/2017-March/msg01764.html
https://www.redhat.com/archives/freeipa-users/2016-October/msg00279.html

just saying, we bypass this with running ipa client containerized on systems to connect the vm's to the ipa server

without using containers this is a major blocker

We'd need to see the full /var/log/ipaclient-install.log and a description of your environment (what realm is the IPA and what are AD).

Based on the names provide it sure looks like the client is trying to enroll against an AD master (krbtgt/ACTIVEDIRECTORY.AT@LX.LINUX.AT).

yup and exactly that is the problem, there it should not try to auth against ad master, it should auth against freeipa

if i install client first time, it auth correctly against freeipa
if i install client second time, it trys to auth against ad and fails constantly

i just rewrote MYCOMPANY.AT to ACTIVEDIRECTORY.AT and LX.MYCOMPANY.AT to LX.LINUX.AT
Edited by elytscha1

Redacting the logs is fine as long as you are consistent and the meanings are defined.

The logs, preferably demonstrating a successful and a failed enrolled, are needed to evaluate what is going on.

ipaclient-install.log-failureipaclient-install.log-success

logs redacted changed company name to "company"
Edited by elytscha1

The installation options are different. The failures cli includes --servers freeipa74. --domain devops.lx.company.at

The clients are being in different sub-domains ("prod.lx.company.at" vs "devops.lx.company.at").

Both end up finding the same realm LX.COMPANY.AT and master freeipa74.lx.company but a different domain value.

The successful enrolling is using an OTP, the failing one admin credentials.

In the failing case the kinit succeeds but the ticket is unusable.

The domain_realms are different from the failing and successful cases.

The report is that once configured a client can never be re-configured. Is it possible to reproduce on the same client a success and a failure? That will wash out any domain-related configuration issues and make comparing more apples to apples.

Now that --domain is to specify primary IPA domain, not your client system domain. It has to be the same regardless what is the client domain.

even when the domains are added as dns zones + sub domains in freeipa, i have to specify the primary ipa domain, so --domain == --realm?

i will try to reproduce the error on a freshly installed system tomorrow, couldn't reproduce the problem yesterday, today it appeared again on a different system but there the successfull install logs where gone, but the successfull first install command was the same command invoked after running --uninstall

maybe to note:
we have a global linux (freeipa) domain: lx.company.at
+ active directory: company.at in a one-way-trust:

and subdomains configured in freeipa with their own dns zones:
devops.lx.company.at
dev.lx.company.at
int.lx.company.at
test.lx.company.at
prod.lx.company.at
Edited by elytscha1

Realm is for kerberos and it is upper case. Primary domain is for DNS and it must correspond to kerberos realm. See https://www.freeipa.org/page/Deployment_Recommendations#Domain for details

Are you still having issues with this?

i couldn reproduce it, the problems where gone with using the primary IPA domain as stated by abbra

Metadata Update from @elytscha1:
- Issue close_status updated to: worksforme
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.