lejeczek via FreeIPA-users <freeipa-users(a)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(a)PRIVATE.xx.xx.PRIVATE.xx.xx.x
>> for
>> krbtgt/PRIVATE.xx.xx.PRIVATE.xx.xx.x(a)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(a)PRIVATE.xx.xx.PRIVATE.xx.xx.x
>> for
>> krbtgt/PRIVATE.xx.xx.PRIVATE.xx.xx.x(a)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(a)PRIVATE.xx.xx.PRIVATE.xx.xx.x for
>> krbtgt/PRIVATE.xx.xx.PRIVATE.xx.xx.x(a)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(a)PRIVATE.xx.xx.PRIVATE.xx.xx.x for
>> krbtgt/PRIVATE.xx.xx.PRIVATE.xx.xx.x(a)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(a)PRIVATE.xx.xx.PRIVATE.xx.xx.x for
>> ldap/swir.priv.xx.xx.priv.xx.xx.x(a)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(a)PRIVATE.xx.xx.PRIVATE.xx.xx.x for
>> HTTP/swir.priv.xx.xx.priv.xx.xx.x(a)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