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

We've suffering from this bug too. What I've found so far, systems experiencing this issue: - both latest RHEL 7.6 and RHEL 6.10 are affected - there are more entries in keytab than host/$hostname and HOSTNAME$ (in our case, the cifs/ prefix) - winbind is running (from 4.8, it's a must) - you're using NTLM authentication (besides kerberos)

The losing the membership after 30 days from sssd, specifically it calls adcli to renew the keytab and forgets to inform samba about the change. Similar talks: <- we believe this is the root cause and a potential fix &

With log_level=7 sssd logs the adcli invocation: /usr/sbin/adcli update --verbose --domain=acme.local --host-fqdn=testmachine.acme.local --computer-password-lifetime=0 --domain-controller=dc.acme.local

Which clearly WRONG because it does not call adcli with "add-samba-data" options. After that invocation: - sssd works - samba works when using kerberos - samba does not work with NTLM

The quick workaround is disabling sssd's auto-renew feature: ad_maximum_machine_account_password_age=0

When calling with "add-samba-data" parameters: /usr/sbin/adcli update --verbose --domain=acme.local --host-fqdn=testmachine.acme.local --computer-password-lifetime=0 --domain-controller=dc.acme.local --add-samba-data - sssd & samba works both with kerberos & ntlm

I just opened an official Red Hat ticket on this since the issue is clearly reproducable in our testing environment.

Basically the answer was from RH support to use 'ad_maximum_machine_account_password_age=0' as a workaround, until upstream responds the issue tracked at