Problems renewing machine account password in AD
by Gordon Messmer
We're seeing problems with some hosts which appears to be caused by the new ad_maximum_machine_account_password_age support in sssd (which notes that a recent adcli is required for this functionality).
For some hosts, there is one set of credentials in krb5.keytab, and AD indicates that the machine account password was changed 30 days after the timestamp on those credentials. On other hosts, we see a second set of credentials,
30 days newer than the first set, whose timestamp matches AD's PasswordLastSet property for that host. For the latter set, users report that authentication works some of the time.
It may be relevant that this is a large multi-site domain, and we've also found that some hosts have been set up with "ad_site" specified in sssd.conf, pointing at a site that is incorrect (in that it is not the closest site).
Both sssd and adcli are out of date on the hosts we're troubleshooting, but I don't see any bugzilla entries, mailing list topics, or release notes that indicate that this is a known problem that has been fixed.
Which components should I be looking at when diagnosing this problem further, and what log settings might be most useful as I'm hunting down the problem?
Symptoms for host1:
System keytab contains old credentials.
[root@host1 ~]# klist -kt /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp Principal
---- ------------------- ------------------------------------------------------
4 05/04/2018 11:10:30 host/host1.domain.lan(a)DOMAIN.LAN
4 05/04/2018 11:10:30 host/HOST1(a)DOMAIN.LAN
4 05/04/2018 11:10:30 host/host1.domain.lan(a)DOMAIN.LAN
4 05/04/2018 11:10:30 host/HOST1(a)DOMAIN.LAN
4 05/04/2018 11:10:30 host/host1.domain.lan(a)DOMAIN.LAN
4 05/04/2018 11:10:30 host/HOST1(a)DOMAIN.LAN
4 05/04/2018 11:10:30 host/host1.domain.lan(a)DOMAIN.LAN
4 05/04/2018 11:10:30 host/HOST1(a)DOMAIN.LAN
4 05/04/2018 11:10:30 host/host1.domain.lan(a)DOMAIN.LAN
4 05/04/2018 11:10:30 host/HOST1(a)DOMAIN.LAN
4 05/04/2018 11:10:30 HOST1$(a)DOMAIN.LAN
4 05/04/2018 11:10:30 HOST1$(a)DOMAIN.LAN
4 05/04/2018 11:10:30 HOST1$(a)DOMAIN.LAN
4 05/04/2018 11:10:30 HOST1$(a)DOMAIN.LAN
4 05/04/2018 11:10:30 HOST1$(a)DOMAIN.LAN
The date of the new credentials matches the “PasswordLastSet” property on that host in AD:
PS H:\> Get-ADComputer -Identity host1 -Properties name,LastLogonDate,PasswordLastSet,modified,modifyTimeStamp
DistinguishedName : CN=HOST1,OU=Build,OU=DOMAIN_DevIT,DC=domain,DC=lan
DNSHostName : host1.domain.lan
Enabled : True
LastLogonDate : 6/1/2018 10:41:59 AM
Modified : 6/3/2018 3:27:10 PM
modifyTimeStamp : 6/3/2018 3:27:10 PM
Name : HOST1
ObjectClass : computer
ObjectGUID : d21d7f72-xxxx-xxxx-xxxx-aac9cf895d31
PasswordLastSet : 6/3/2018 3:26:59 PM
SamAccountName : HOST1$
SID : S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxx-xxxxxx
UserPrincipalName :
UserPrincipalName :
adcli and sssd are out of date on that host:
[root@host1 ~]# rpm -q adcli sssd
adcli-0.8.1-3.el7.x86_64
sssd-1.15.2-50.el7_4.11.x86_64
The current versions are:
$ yum list adcli sssd
…
Installed Packages
sssd.x86_64 1.16.0-19.el7 @base
Available Packages
adcli.x86_64 0.8.1-4.el7 base
Logs include:
[sssd[ldap_child[1271]]]: Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Preauthentication failed. Unable to create GSSAPI-encrypted LDAP connection.
[sssd[ldap_child[1271]]]: Preauthentication failed
Symptoms for host2:
System keytab contains new credentials, 30 days newer than a previous set.
[it@host2 ~]$ sudo klist -kt /etc/krb5.keytab
[sudo] password for it:
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp Principal
---- ------------------- ------------------------------------------------------
3 05/21/2018 11:50:41 host/host2.domain.lan(a)DOMAIN.LAN
3 05/21/2018 11:50:41 host/host2.domain.lan(a)DOMAIN.LAN
3 05/21/2018 11:50:41 host/host2.domain.lan(a)DOMAIN.LAN
3 05/21/2018 11:50:41 host/host2.domain.lan(a)DOMAIN.LAN
3 05/21/2018 11:50:41 host/host2.domain.lan(a)DOMAIN.LAN
3 05/21/2018 11:50:41 host/HOST2(a)DOMAIN.LAN
3 05/21/2018 11:50:41 host/HOST2(a)DOMAIN.LAN
3 05/21/2018 11:50:41 host/HOST2(a)DOMAIN.LAN
3 05/21/2018 11:50:41 host/HOST2(a)DOMAIN.LAN
3 05/21/2018 11:50:41 host/HOST2(a)DOMAIN.LAN
3 05/21/2018 11:50:41 HOST2$(a)DOMAIN.LAN
3 05/21/2018 11:50:41 HOST2$(a)DOMAIN.LAN
3 05/21/2018 11:50:41 HOST2$(a)DOMAIN.LAN
3 05/21/2018 11:50:41 HOST2$(a)DOMAIN.LAN
3 05/21/2018 11:50:41 HOST2$(a)DOMAIN.LAN
4 06/21/2018 08:09:02 HOST2$(a)DOMAIN.LAN
4 06/21/2018 08:09:02 HOST2$(a)DOMAIN.LAN
4 06/21/2018 08:09:02 HOST2$(a)DOMAIN.LAN
4 06/21/2018 08:09:02 HOST2$(a)DOMAIN.LAN
4 06/21/2018 08:09:02 HOST2$(a)DOMAIN.LAN
4 06/21/2018 08:09:02 host/host2.domain.lan(a)DOMAIN.LAN
4 06/21/2018 08:09:02 host/host2.domain.lan(a)DOMAIN.LAN
4 06/21/2018 08:09:02 host/host2.domain.lan(a)DOMAIN.LAN
4 06/21/2018 08:09:02 host/host2.domain.lan(a)DOMAIN.LAN
4 06/21/2018 08:09:02 host/host2.domain.lan(a)DOMAIN.LAN
4 06/21/2018 08:09:02 host/HOST2(a)DOMAIN.LAN
4 06/21/2018 08:09:02 host/HOST2(a)DOMAIN.LAN
4 06/21/2018 08:09:02 host/HOST2(a)DOMAIN.LAN
4 06/21/2018 08:09:02 host/HOST2(a)DOMAIN.LAN
4 06/21/2018 08:09:02 host/HOST2(a)DOMAIN.LAN
The date of the new credentials matches the “PasswordLastSet” property on that host in AD:
PS H:\> Get-ADComputer -Identity host2 -Properties name,LastLogonDate,PasswordLastSet,modified,modifyTimeStamp
DistinguishedName : CN=HOST2,OU=Build,OU=DOMAIN_DevIT,DC=domain,DC=lan
DNSHostName : host2.domain.lan
Enabled : True
LastLogonDate : 7/6/2018 10:51:11 PM
Modified : 7/6/2018 10:52:06 PM
modifyTimeStamp : 7/6/2018 10:52:06 PM
Name : HOST2
ObjectClass : computer
ObjectGUID : f70a3bab-xxxx-xxxx-xxxx-932457b18768
PasswordLastSet : 6/21/2018 8:09:02 AM
SamAccountName : HOST2$
SID : S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxx-xxxxxx
UserPrincipalName :
adcli and sssd are out of date on that host:
[root@host2 ~]# rpm -q adcli sssd
adcli-0.8.1-3.el7.x86_64
sssd-1.14.0-43.el7_3.14.x86_64
The current versions are:
$ yum list adcli sssd
…
Installed Packages
sssd.x86_64 1.16.0-19.el7 @base
Available Packages
adcli.x86_64 0.8.1-4.el7 base
Logs include:
[sssd[krb5_child[21580]]]: Preauthentication failed
5 years, 9 months
[sssd PR#612][opened] crypto: Silence a Coverity warning in sss_hmac_sha1()
by jhrozek
URL: https://github.com/SSSD/sssd/pull/612
Author: jhrozek
Title: #612: crypto: Silence a Coverity warning in sss_hmac_sha1()
Action: opened
PR body:
"""
It looks like the case where the key_len was exactly 64 was Confusing
Coverity. The trace looks like this:
3. cond_at_most: Checking key_len > 64UL implies that key_len may be up to 64 on the false branch.
49 if (key_len > HMAC_SHA1_BLOCKSIZE) {
50 /* keys longer than blocksize are shortened */
51 if (!EVP_DigestInit_ex(ctx, EVP_sha1(), NULL)) {
52 ret = EIO;
53 goto done;
54 }
55
56 EVP_DigestUpdate(ctx, (const unsigned char *)key, key_len);
57 EVP_DigestFinal_ex(ctx, ikey, &res_len);
58 memset(ikey + SSS_SHA1_LENGTH, 0, HMAC_SHA1_BLOCKSIZE - SSS_SHA1_LENGTH);
59 } else {
60 /* keys shorter than blocksize are zero-padded */
61 memcpy(ikey, key, key_len);
CID 18054 (#1 of 1): Out-of-bounds read (OVERRUN)4. overrun-local: Overrunning array of 64 bytes at byte offset 64 by dereferencing pointer ikey + key_len. [Note: The source code implementation of the function has been overridden by a builtin model.]
62 memset(ikey + key_len, 0, HMAC_SHA1_BLOCKSIZE - key_len);
63 }
64
I think this is a false positive because then HMAC_SHA1_BLOCKSIZE-key_len
will be 0, so ikey+key_len will not be dereferenced at all, but let's be
helpful to Coverity and make sure the branch is not evaluated at all if
key_len == HMAC_SHA1_BLOCKSIZE.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/612/head:pr612
git checkout pr612
5 years, 9 months
[sssd PR#613][opened] cache_req: Keep the files provider as the first domain to be searched
by fidencio
URL: https://github.com/SSSD/sssd/pull/613
Author: fidencio
Title: #613: cache_req: Keep the files provider as the first domain to be searched
Action: opened
PR body:
"""
Currently we can't guarantee any order on which domain will the first to
be searched. More than that, in case domain_resolution_order is set, we
actually enforce that the first domain searched will respect the option
set.
This behaviour is not exactly the expect, as the implicit files domain
has to be searched first in order to avoid querying for local users in
remote domains. In order to enforce this, let's just keep the files
domain as the first to be searched, always!
Resolves:
https://pagure.io/SSSD/sssd/issue/3768
Signed-off-by: Fabiano Fidêncio <fidencio(a)redhat.com>
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/613/head:pr613
git checkout pr613
5 years, 9 months
[sssd PR#609][opened] SUDO: Don't save duplicates when saving qualified names
by jhrozek
URL: https://github.com/SSSD/sssd/pull/609
Author: jhrozek
Title: #609: SUDO: Don't save duplicates when saving qualified names
Action: opened
PR body:
"""
The sudoUser attribute which is part of the sudo rule can contain any name
that sudo can parse on the LDAP side. Internally, however, the attribute is
always qualified with the name of the SSSD domain.
This patch makes sure that if two or more sudoUser attributes contain the
same name in both qualified and an unqualified form, the rule is actually
saved. Previously, the rule would have failed to be saved and the sysdb
sudo code would have errored out with EEXIST.
Resolves: https://pagure.io/SSSD/sssd/issue/3596
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/609/head:pr609
git checkout pr609
5 years, 9 months