Password has expired while getting initial ticket during replication

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Password has expired while getting initial ticket during replication

Stephen Carville (Kerberos List)
Kind of at wits end here...

Recently replication to the slave servers broke.  I last update was on
Sep 10 07:01 but did not discover it until starting to migrate from
CentOS 6 to CentOS 7.

The following script runs hourly

----
SLAVES="
scakerb02.lereta.com
"

# export the Kerberos database
/usr/sbin/kdb5_util dump /var/kerberos/krb5kdc/slave_datatrans

# propogate to all the slave servers
for SLAVE in $SLAVES; do
   /usr/sbin/kprop -f /var/kerberos/krb5kdc/slave_datatrans $SLAVE
done
----

The error is:

/usr/sbin/kprop: Password has expired while getting initial ticket

I restarted krb5kdc on both servers and kpropd on the slave server.  I
recreated the keytab file on both servers.  Error is still the same

I can get a ticket using either server but I just cannot get replication
working again.

system is CentOS 6

Kerberos version is 1.10.3

--
Stephen
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Password has expired while getting initial ticket during replication

Greg Hudson
On 12/2/19 12:02 PM, Stephen Carville (Kerberos List) wrote:
> /usr/sbin/kprop: Password has expired while getting initial ticket

At startup, kprop retrieves a TGT for the client principal
host/<kdchostname>@REALM using the keytab.  You can simulate this with
"kinit -k host/<kdchostname>@REALM".

It sounds like this client principal has a password expiry time, which
has elapsed.  If this hypothesis is true, running "getprinc
host/<kdchostname>" within kadmin.local should display:

Password expiration date: <some date in the past>

You can clear this with "modprinc -pwexpire never host/<kdchostname>".

The password expiration time might have been the result of a password
policy (displayed under "Policy:" in the getprinc output).  You might
not want to apply password policies to service principals which use
random keys.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Password has expired while getting initial ticket during replication

Stephen Carville (Kerberos List)
On 12/2/19 11:22 AM, Greg Hudson wrote:

> On 12/2/19 12:02 PM, Stephen Carville (Kerberos List) wrote:
>> /usr/sbin/kprop: Password has expired while getting initial ticket
>
> At startup, kprop retrieves a TGT for the client principal
> host/<kdchostname>@REALM using the keytab.  You can simulate this with
> "kinit -k host/<kdchostname>@REALM".
>
> It sounds like this client principal has a password expiry time, which
> has elapsed.  If this hypothesis is true, running "getprinc
> host/<kdchostname>" within kadmin.local should display:
>
> Password expiration date: <some date in the past>
>
> You can clear this with "modprinc -pwexpire never host/<kdchostname>".

That worked. Replication is now working normally. Thank you.

It seems that when I add a key to the keytab file the password
expiration date for that host is set to somewhen in 1903.  I've never
noticed that behavior before and it only seems to happen to KDCs.

> The password expiration time might have been the result of a password
> policy (displayed under "Policy:" in the getprinc output).  You might
> not want to apply password policies to service principals which use
> random keys.
> ________________________________________________
> Kerberos mailing list           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos
>

--
Stephen
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Password has expired while getting initial ticket during replication

Greg Hudson
On 12/2/19 3:23 PM, Stephen Carville (Kerberos List) wrote:
> It seems that when I add a key to the keytab file the password
> expiration date for that host is set to somewhen in 1903.  I've never
> noticed that behavior before and it only seems to happen to KDCs.

I would guess that these principal entries have a policy object
associated with them (as displayed in the Policy field of the getprinc
output), and that the policy (display with "getpol <policyname>") has a
maximum password life of 20 years, likely because whoever set it up
didn't really want a maximum password life but didn't know how to
disable it ("modpol -maxlife 0 <policyname>", or 'modpol -maxlife "0
seconds" <policyname>' for releases before 1.15).

When 20 years is added to the current time, the result is a timestamp
later than the 32-bit signed overflow point in January 2038.  Release
1.16 and later can handle timestamps past that point (up until the year
2106) on 64-bit platforms, but earlier releases wrap around to
historical dates.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Password has expired while getting initial ticket during replication

Stephen Carville (Kerberos List)
On 12/2/19 12:58 PM, Greg Hudson wrote:

> Lereta Email Checkpoint: External email. Please make sure you trust this source before clicking links or opening attachments.
>
> **********************************************************************
>
> On 12/2/19 3:23 PM, Stephen Carville (Kerberos List) wrote:
>> It seems that when I add a key to the keytab file the password
>> expiration date for that host is set to somewhen in 1903.  I've never
>> noticed that behavior before and it only seems to happen to KDCs.
>
> I would guess that these principal entries have a policy object
> associated with them (as displayed in the Policy field of the getprinc
> output), and that the policy (display with "getpol <policyname>") has a
> maximum password life of 20 years, likely because whoever set it up
> didn't really want a maximum password life but didn't know how to
> disable it ("modpol -maxlife 0 <policyname>", or 'modpol -maxlife "0
> seconds" <policyname>' for releases before 1.15).

You guessed right.  I had the policy -maxlife on host policy set to
+7305 days.  It never occurred to me that the timestamp would be 32 bit
instead of 64 bit.  It is fixed now.

Thank you again.

> When 20 years is added to the current time, the result is a timestamp
> later than the 32-bit signed overflow point in January 2038.  Release
> 1.16 and later can handle timestamps past that point (up until the year
> 2106) on 64-bit platforms, but earlier releases wrap around to
> historical dates.
> ________________________________________________
> Kerberos mailing list           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos