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

Thanks for the details Szabolcs. I have tried implementing 'ad_maximum_machine_account_password_age=0', but to know for sure if this worked I will need to check the server in 30 days. Can you confirm if this worked for you?

Hi, add this line in /etc/sssd/sssd.conf

service sssd stop ; rm -f /var/lib/sss/db/* /var/log/sssd/* ; service sssd start

will do the job, I have done the same and samba works for 6 months without any problems.

We were faced with this issue, and because we only use samba (running daemon) on selected systems, we cannot relay completely on samba to refresh the trust, nor can we rely on sssd to ensure samba trusts are updated.

In the end, we have told sssd to not update via the suggested directive "ad_maximum_machine_account_password_age=0 "

and rely on a cron still. However, a static cron for this has proven (at least lately, AD upgrades recently too) to be a pain as "MANY" systems refresh there trust at the exactly same time and has become overwhelming for the AD servers to serve out.

ads_connect: No logon servers are currently available to service the logon request.

So, what I have done is created a cron.d file that will run every Sun Night (before Mon morning) to generate a completely random cron string to trigger the trust update once a week "/usr/bin/net ads changetrustpw" (This could be anywheres from 2-13 days between refreshes)

# cat /etc/cron.d/weekly_cron_setups 
55 23 * * Sun root  hour=$(echo -n 2; echo "$(( 1$(date +\%N) \% 4 ))"); min=$(( 1$(date +\%N) \% 60 )); days=(Mon Tue Wed Thu Fri Sat Sun); rd="$(( RANDOM \% 7 ))"; day="${days[$rd]}"; echo "$min $hour * * $day root /usr/bin/net ads changetrustpw | logger -t changetrustpw 2>&1" > /etc/cron.d/ads_changetrustpw

this will generate a random min (0-60) and a random hour between 8pm and 11pm 2(1-3) and select a random weekday name

# cat /etc/cron.d/ads_changetrustpw 
11 20 * * Sat root /usr/bin/net ads changetrustpw | logger -t changetrustpw 2>&1

None of the discussed solutions above have solved my problem.