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.x...@private.xx.xx.private.xx.xx.x 
>>> for 
>>> krbtgt/private.xx.xx.private.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.x...@private.xx.xx.private.xx.xx.x 
>>> for 
>>> krbtgt/private.xx.xx.private.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: 
>>> ad...@private.xx.xx.private.xx.xx.x for 
>>> krbtgt/private.xx.xx.private.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}, 
>>> ad...@private.xx.xx.private.xx.xx.x for 
>>> krbtgt/private.xx.xx.private.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}, 
>>> ad...@private.xx.xx.private.xx.xx.x for 
>>> ldap/swir.priv.xx.xx.priv.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}, 
>>> ad...@private.xx.xx.private.xx.xx.x for 
>>> HTTP/swir.priv.xx.xx.priv.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

Attachment: signature.asc
Description: PGP signature

_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

Reply via email to