Re: [EXTERNAL] Re: It ain't easy to dig a user's last login time info out of IdM/FreeIPA

[Shane Frasier]

Hello,

Apologies for reviving an old thread, but I was wondering if there is any
way to turn this replication on for our local FreeIPA cluster?  I'd like to
use the krbLastAuthentication data to disable inactive users, but
the timestamps are reset every time I upgrade the cluster.

Thank you,
Shane Frasier ([e-mail])

[EXTERNAL] Re: It ain't easy to dig a user's last login time info out of IdM/FreeIPA

[Rob Crittenden]

Shane Frasier via FreeIPA-users wrote:
> Hello,
>
> Apologies for reviving an old thread, but I was wondering if there is
> any way to turn this replication on for our local FreeIPA cluster?  I'd
> like to use the krbLastAuthentication data to disable inactive users,
> but the timestamps are reset every time I upgrade the cluster.

To enable it you need to remove "KDC:Disable Last Success" from the
password plugin feature configuration.

By default it is:

Password plugin features: AllowNThash, KDC:Disable Last Success

You can drop it using something like:

ipa config-mod --ipaconfigstring AllowNThash

You only need to do this on one server. The change will replicate to the
others.

Note that depending on how many authentications you have you'll notice
the additional replication. It will most likely be worse in the mornings.

To re-enable it you use a similar command:

ipa config-mod --ipaconfigstring={AllowNThash,"KDC:Disable Last Success"}

rob

[EXTERNAL] Re: It ain't easy to dig a user's last login time info out of IdM/FreeIPA

[Shane Frasier]

Rob,

I do that, but currently when I upgrade my FreeIpa cluster I lose all the
last login timestamps.  After the upgrade ipa user-status shows them all to
be the value N/A.

I upgrade my three-node cluster (in AWS) by:
1. Removing node 0 as a replica
2. Redeploying node 0 with an updated AMI that has the latest versions of
the OS and FreeIPA
3. Re-adding node 0 to the cluster as a replica
4. Repeat for node 1
5. Repeat for node 2

When my script to disable inactive users kicks off it looks like all the
users were created months or years ago but never logged in, so they all get
disabled. How do I get the last login timestamps to persist across upgrades?

Thanks,
Shane

On Wed, May 28, 2025, 4:14 PM Rob Crittenden  wrote:
> Shane Frasier via FreeIPA-users wrote:
> > Hello,
> >
> > Apologies for reviving an old thread, but I was wondering if there is
> > any way to turn this replication on for our local FreeIPA cluster?  I'd
> > like to use the krbLastAuthentication data to disable inactive users,
> > but the timestamps are reset every time I upgrade the cluster.
>
> To enable it you need to remove "KDC:Disable Last Success" from the
> password plugin feature configuration.
>
> By default it is:
>
> Password plugin features: AllowNThash, KDC:Disable Last Success
>
> You can drop it using something like:
>
> ipa config-mod --ipaconfigstring AllowNThash
>
> You only need to do this on one server. The change will replicate to the
> others.
>
> Note that depending on how many authentications you have you'll notice
> the additional replication. It will most likely be worse in the mornings.
>
> To re-enable it you use a similar command:
>
> ipa config-mod --ipaconfigstring={AllowNThash,"KDC:Disable Last Success"}
>
> rob

[EXTERNAL] Re: It ain't easy to dig a user's last login time info out of IdM/FreeIPA

[Rob Crittenden]

Shane Frasier wrote:
> Rob,
>
> I do that, but currently when I upgrade my FreeIpa cluster I lose all
> the last login timestamps.  After the upgrade ipa user-status shows them
> all to be the value N/A.

That doesn't make sense. IPA definitely does not wipe data from user
entries on upgrade.

I can see an upgrade attempting to set the password plugin defaults and
wiping out configuration changes but I can't replicate this behavior.

You could, for example, enable the 389-ds audit log then run the
upgrade. This would show whether changes were made.

rob
> I upgrade my three-node cluster (in AWS) by:
> Removing node 0 as a replica
> Redeploying node 0 with an updated AMI that has the latest versions
>
> of the OS and FreeIPA
> 3. Re-adding node 0 to the cluster as a replica
> 4. Repeat for node 1
> 5. Repeat for node 2
>
> When my script to disable inactive users kicks off it looks like all the
> users were created months or years ago but never logged in, so they all
> get disabled. How do I get the last login timestamps to persist across
> upgrades?
>
> Thanks,
> Shane
>
> On Wed, May 28, 2025, 4:14 PM Rob Crittenden <[e-mail]
> > wrote:
> Shane Frasier via FreeIPA-users wrote:
> > Hello,
> >
> > Apologies for reviving an old thread, but I was wondering if there is
> > any way to turn this replication on for our local FreeIPA
> cluster?  I'd
> > like to use the krbLastAuthentication data to disable inactive users,
> > but the timestamps are reset every time I upgrade the cluster.
>
> To enable it you need to remove "KDC:Disable Last Success" from the
> password plugin feature configuration.
>
> By default it is:
>
>  Password plugin features: AllowNThash, KDC:Disable Last Success
>
> You can drop it using something like:
>
> ipa config-mod --ipaconfigstring AllowNThash
>
> You only need to do this on one server. The change will replicate to the
> others.
>
> Note that depending on how many authentications you have you'll notice
> the additional replication. It will most likely be worse in the
> mornings.
>
> To re-enable it you use a similar command:
>
> ipa config-mod --ipaconfigstring={AllowNThash,"KDC:Disable Last
> Success"}
>
> rob

[EXTERNAL] Re: It ain't easy to dig a user's last login time info out of IdM/FreeIPA

[Shane Frasier]

Hi Rob,

When I perform step 1 I use, e.g.:
ipa server-del --ignore-topology-disconnect ipa0.<domain>
for id in $(ipa cert-find --sizelimit=0 --status=VALID --subject=ipa0.<domain> | grep "Serial number:" | sed "s/^\ *Serial number: //"); do ipa cert-revoke $id --revocation-reason=5; done
ipa-replica-manage del ipa0.<domain>

It occurred to me that perhaps the "ipa server-del" command is overly aggressive and causing the last authentication timestamps to be deleted.  Should I drop that step?  Would I then need to un-join ipa0 from the domain after the "ipa-replica-manage" command?

If the process for this sort of in situ upgrade is documented someplace then feel free to simply point me there.  I searched but didn't find it.

Thank you,
Shane

[EXTERNAL] Re: It ain't easy to dig a user's last login time info out of IdM/FreeIPA

[Rob Crittenden]

Shane Frasier via FreeIPA-users wrote:
> Hi Rob,
>
> When I perform step 1 I use, e.g.:
> ipa server-del --ignore-topology-disconnect ipa0.<domain>
> for id in $(ipa cert-find --sizelimit=0 --status=VALID --subject=ipa0.<domain> | grep "Serial number:" | sed "s/^\ *Serial number: //"); do ipa cert-revoke $id --revocation-reason=5; done
> ipa-replica-manage del ipa0.<domain>
>
> It occurred to me that perhaps the "ipa server-del" command is overly aggressive and causing the last authentication timestamps to be deleted.  Should I drop that step?  Would I then need to un-join ipa0 from the domain after the "ipa-replica-manage" command?
>
> If the process for this sort of in situ upgrade is documented someplace then feel free to simply point me there.  I searched but didn't find it.

As I've said before, IPA doesn't systematically delete user attributes
upon on removing a server or upgrading a server. It would generate a
literal storm of replication events which is something we try hard to avoid.

Since this is reproducible for you I'd suggest you enabling audit
logging on a server you plan to keep. Verify that the last
authentication date exists in at least some user entries, then setup a
new replica and remove it using your process.

You should see MOD for all those users. It may help you identify the source.

rob