AD integration with SSSD

Latest response

We have several domain-joined servers running RHEL7 and configured (as per the Red Hat docs) to use SSSD for identity management and authentication. Initially, everything seemed fine but we started to notice problems on the hosts acting as Samba servers for Windows clients.

After a while the Samba shares were prompting for credentials but rejected them anyway. The problem was identified as the machine account passwords expiring every 30 days which is default AD behaviour. It seems SSSD was not renewing them automatically. Disjoining and re-joining the servers to AD was one workaround but not really practical.

The other solution found in the comments here suggest using a cron job with the command “net ads changetrustpw". This would reset the machine password periodically before it expired after 30 days. This seemed to be a workable solution but in fact leads to SSH authentication problems due to broken trust. The error in the logs:

[sssd[krb5_child[38028]]][38028]: Cannot find key for host/ kvno 79 in keytab

Has anybody else running RHEL7 servers joined to AD with realmd/SSSD encountered this?

Other links I’ve looked at so far…

Potential conflict between Samba and realmd-based setup, and resolution

msktutil to reset machine password

Using adcli instead of realmd to join the domain



We have exact same issue, the first workaround

Just opened a ticket to RH :

We are hit by this exact problem described here :

Little story : we use SSSD and Samba without Winbind. Currently, SSSD is not able to update "secrets.tdb" by triggering "adcli update". The first workaround was to use "net ads changetrustpw" with "secrets and keytab" config of Samba to update keytab and secrets.

Unfortunately, looks like that workaround need a fix as once you use "net ads changetrustpw", it will suddenly stop updating the keytab and then, will stay at KVNO-1 (not the last). Sometime, could be KVNO-2" (probably too fast tests).

Looks like the net ads changetrustpw is doing ldap on another DC to update keytab and that DC didnt' yet receive the update (of course ..). If I try to fix directly with a "net ads keytab create", I hit the exact same issue as could connect to a DC which is not yet up-to-date and will simply provide previous KVNO. It is possible that it works well sometimes (chance) but we always ends up hitting that issue.

Found that issue on RHEL 7.5 but even with 7.6, the problem is still there.

Second workaround will be to "net ads keytab create" after a while once we are sure all DC's are updated. But this require admin password and so, not secure if to be used with cronjob ...

Hope that will help.

Hi Laurent,

Thank you for your reply. I tested your workaround by manually using "net ads changetrustpw", confirming that SSH auth was broken and then running "net ads keytab create -U Administrator". This does appear to resolve the auth problems which is great although it seems less than ideal having to run a command with Domain Admin credentials.

I'm still not sure I fully understand the cause of this problem in terms of your DC explanation. As far as I can tell replication is functioning well between our 3 DCs. The bug post you linked mentions something about the LDAP DC being different to the KDC. I don't believe this is the case but I'm not 100% sure how to confirm.

For now, I think recreating the keytab following a machine password reset is a solution we can live with.

Kind regards,

Just to add to this. It seems you can just run the following command without any AD credentials to fix the keytab.

net ads keytab create -P