lejeczek via FreeIPA-users freeipa-users@lists.fedorahosted.org writes:
On 08/01/18 08:46, Florence Blanc-Renaud wrote:
On 01/06/2018 08:51 PM, lejeczek via FreeIPA-users wrote:
$ ipa-client-install --no-ntp --force-join Discovery was successful! ... Also note that following ports are necessary for ipa-client working properly after enrollment: TCP: 464 UDP: 464, 123 (if NTP enabled) Failed to obtain host TGT: Major (851968): Unspecified GSS failure. Minor code may provide more information, Minor (2529638936): Preauthentication failed Installation failed. Rolling back changes. -- end
At server's end(one single server in domain): .. Jan 06 15:00:42 swir.priv.xx.xx.priv.xx.xx.x krb5kdc[1560685](info): closing down fd 11 Jan 06 15:00:42 swir.priv.xx.xx.priv.xx.xx.x krb5kdc[1560686](info): AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 10.5.6.17: NEEDED_PREAUTH: host/dzien.priv.xx.xx.priv.xx.xx.x@PRIVATE.xx.xx.PRIVATE.xx.xx.x for krbtgt/PRIVATE.xx.xx.PRIVATE.xx.xx.x@PRIVATE.xx.xx.PRIVATE.xx.xx.x, Additional pre-authentication required Jan 06 15:00:42 swir.priv.xx.xx.priv.xx.xx.x krb5kdc[1560686](info): closing down fd 11 Jan 06 15:00:42 swir.priv.xx.xx.priv.xx.xx.x krb5kdc[1560686](info): preauth (encrypted_timestamp) verify failure: Preauthentication failed Jan 06 15:00:42 swir.priv.xx.xx.priv.xx.xx.x krb5kdc[1560686](info): AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 10.5.6.17: PREAUTH_FAILED: host/dzien.priv.xx.xx.priv.xx.xx.x@PRIVATE.xx.xx.PRIVATE.xx.xx.x for krbtgt/PRIVATE.xx.xx.PRIVATE.xx.xx.x@PRIVATE.xx.xx.PRIVATE.xx.xx.x, Preauthentication failed Jan 06 15:00:42 swir.priv.xx.xx.priv.xx.xx.x krb5kdc[1560686](info): closing down fd 11 Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x krb5kdc[1560681](info): AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 10.5.6.17: NEEDED_PREAUTH: admin@PRIVATE.xx.xx.PRIVATE.xx.xx.x for krbtgt/PRIVATE.xx.xx.PRIVATE.xx.xx.x@PRIVATE.xx.xx.PRIVATE.xx.xx.x, Additional pre-authentication required Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x krb5kdc[1560681](info): closing down fd 11 Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x krb5kdc[1560686](info): AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 10.5.6.17: ISSUE: authtime 1515250943, etypes {rep=18 tkt=18 ses=18}, admin@PRIVATE.xx.xx.PRIVATE.xx.xx.x for krbtgt/PRIVATE.xx.xx.PRIVATE.xx.xx.x@PRIVATE.xx.xx.PRIVATE.xx.xx.x
Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x krb5kdc[1560686](info): closing down fd 11 Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x krb5kdc[1560686](info): TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 10.5.6.17: ISSUE: authtime 1515250943, etypes {rep=18 tkt=18 ses=18}, admin@PRIVATE.xx.xx.PRIVATE.xx.xx.x for ldap/swir.priv.xx.xx.priv.xx.xx.x@PRIVATE.xx.xx.PRIVATE.xx.xx.x
Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x krb5kdc[1560686](info): closing down fd 11 Jan 06 15:02:23 swir.priv.xx.xx.priv.xx.xx.x krb5kdc[1560686](info): TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 10.5.6.17: ISSUE: authtime 1515250943, etypes {rep=18 tkt=18 ses=18}, admin@PRIVATE.xx.xx.PRIVATE.xx.xx.x for HTTP/swir.priv.xx.xx.priv.xx.xx.x@PRIVATE.xx.xx.PRIVATE.xx.xx.x
-- end
But after many tries(randomly) suddenly it would succeed. Client said to use --force-join. VERSION: 4.5.0, API_VERSION: 2.228
what is the content of /etc/krb5.conf on your client? Does it contain "includedir /etc/krb5.conf.d/" and if it is the case, what is the content of the included files?
During the client installation, a temp krb5.conf is created and also contains "includedir /etc/krb5.conf.d/". If there are snippets in this directory which define parameters for the IPA realm, then the parameters might be conflicting with the ones needed by the installer.
I try to make sure that I do clean re-install, thus I do first:
$ yum remove -y `rpm -qa ipa* 389*` pki-base krb5-pkinit krb5-server krb5-workstation ipa-python certmonger
then I install IPA, at this point there is already a /etc/krb5.conf.d/ipa-certauth created, before any -install is run, but there is no "include" in /etc/krb5.conf.
Oh, this is RHEL-7.4? The missing `includedir` is https://bugzilla.redhat.com/show_bug.cgi?id=1431198 then. You can try adding to the top of /etc/krb5.conf:
includedir /etc/krb5.conf.d
and see if it succeeds, but I don't think it'll make a difference.
In /etc/krb5.conf.d/ipa-certauth
[plugins] certauth = { module = ipakdb:kdb/ipadb.so enable_only = ipakdb }
So, should I remove that /etc/krb5.conf.d/ipa-certauth before client installation? I did, even then client installation fails the same way. Like I said(maybe most importantly), it would suddenly(randomly?) succeed after a number of tries - why?
It shouldn't matter for client configurations I think.
Probably one thing I should mention: I have a IPA domain/realm already on the network. I've set up another separate server(master fist) for the same domain and now I'm trying to install a client to that new "stand-alone" server. (details on reason of doing something this weird I'd not go into just yet)
This sounds odd to me, but I'll leave it to someone who knows more about replication than I to comment.
As I understand it, because it's all in DNS, the fact that there are two servers/replicas separately, should not matter to the client candidate which via dns/resolver sees only the new server, the "stand-alone" I point the client to. Installation of that new "stand-alone" server went okey. Client candidate resolves all bits okey. To check, I've also tried --domain= --server --realm, it fails the same way. A the moment a have no means to try another box/system to try as a client to rule out, see, if the network is the culprit here(but how could it be if everything else, in terms of net communication, works fine between "stand-alone" and client candidate.
The "sometimes succeeds" thing sounds like some servers may be working correctly while others may not. Do all servers fail the same way when you try against them specifically?
Thanks, --Robbie