If you run Samba on a domain-joined server running sssd and adcli, sssd will call adcli to update the server's machine account password. However, when it does this, the copy of this password in Samba's secrets.tdb becomes invalid, which stops people authenticating with the Samba server with Username/Password. You can somewhat work around the issue by configuring Samba with: kerberos method = system keytab but you can then only authenticate to Samba with Kerberos, and not username/password. Now, "everyone" really should be using Kerberos to access SMB servers, but I'm sure many are not...
For reference see the following threads on the sssd-users mailing list: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/thread/E663NUW5SUGZSKTOTMVEUMVTKCCNSVU3/ https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/thread/SBADSWMVRTXWUEURXTV6ETR3K2AM3NB4/
Confirmed. Way to reproduce: 1. realm join 2. verify samba/winbind trust: wbinfo -tP checking the trust secret for domain DOMAIN via RPC calls succeeded checking the NETLOGON for domain[DOMAIN] dc connection to "random_dc.domian.fqdn" succeeded 3. change machine password: adcli update --verbose --computer-password-lifetime=0 You can see that password is updating, KVNO increased etc. 4. wait some time or restart winbind, then verify samba/winbind trust once more: wbinfo -tP wbcCheckTrustCredentials(DOMAIN): error code was NT_STATUS_ACCESS_DENIED (0xc0000022) failed to call wbcCheckTrustCredentials: WBC_ERR_AUTH_ERROR Could not check secret Note that wbinfo can be absent on your system. Workaround: Under [domain/domain.fqdn] section of sssd.conf append: ad_maximum_machine_account_password_age = 0 that will prevent sssd to changing/updating ad password (clearly, via "adcli update" as sssd log says when debug_level=9) if necessary, append something like that to crontab (if present): 15 5 */30 * * root /usr/bin/net ads changetrustpw | logger on centOS 7.x net ads changetrustpw updates both krb5.keytab and secrets.tdb accordingly Note that net can be absent on your system After dyssynchronising ad password and secrets.tdb, "net ads join" allows to re-join to domain in place (without removing samba, sssd & kerberos confs), while realm is complaining about 'already joined'. Unfortunately, NTLM support can be necesserity in some environments since i.e. Microsoft does not guarantee kerberos working properly between AD forests if external trusts (in place of forest trusts) are used. https://support.microsoft.com/en-us/help/2977475/kerberos-forest-search-order-may-not-work-in-an-external-trust-and-eve
Just to get another dot on the board, I also run into this issue, and thanks for the suggested workaround dijxie@gmail.com ! I also wanted to toss out a potential suggestion of maybe adding a new command to realmd to handle the trust password update -- and it could use the proper command depending on what membership software you chose. Of course that would also involve having sssd call realm changetrustpw or whatever, so that may or may not be more work than getting adcli to update secrets.tdb.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/realmd/adcli/issues/6.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.