From sbose at redhat.com Tue Aug 7 12:11:16 2018 From: sbose at redhat.com (Sumit Bose) Date: Tue, 7 Aug 2018 14:11:16 +0200 Subject: [Authentication] realmd domain join with kinit not working on Ubuntu 18.04 In-Reply-To: References: <17dd3877-c317-5799-8648-d5111943b57b@uni-muenster.de> <2a18eddc-6bad-b576-7510-0685108d55b4@uni-muenster.de> Message-ID: <20180807121116.GI13952@p50> On Fri, Jul 27, 2018 at 06:02:38PM +0200, Simon May wrote: > I checked: > > > # kinit -kt /path/to/keytab my_username > # klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: my_username at EXAMPLE.COM > > Valid starting Expires Service principal > 25.07.2018 17:01:13 26.07.2018 03:01:13 krbtgt/EXAMPLE.COM at EXAMPLE.COM > > > So the ticket is definitely there, but realmd doesn’t use/see it. Have you tried to tell realm explicitly about the ccache file by calling KRB5CCNAME=FILE:/tmp/krb5cc_0 realm join ... HTH bye, Sumit > > > On 21.07.2018 03:00, Simon May wrote: > > Well, I’m not the one specifying these options. The only commands I ran were > > # kinit -kt /path/to/keytab my_username > > # realm join ad.example.com > > The call to “adcli” and all the options used for it were generated by > > the “realm” command. My question is why it is using these options in > > particular instead of the Kerberos ticket. > > > > I will check if the ticket is actually there using “klist”, perhaps it > > disappears for some reason. > > > > > > On 20.07.2018 20:48, Niklas Andersson wrote: > >> AFAIK you don't need any of these options "--login-type user > >> --login-user Administrator --stdin-password" if you have a valid > >> Kerberos ticket (check with klist) > >> > >> The purpose with Kerberos is that you don't need to specify user or > >> password. > >> > >> Regards, > >> Niklas > >> > > > > > > _______________________________________________ > Authentication mailing list > Authentication at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/authentication From sbose at redhat.com Tue Aug 7 12:33:21 2018 From: sbose at redhat.com (Sumit Bose) Date: Tue, 7 Aug 2018 14:33:21 +0200 Subject: [Authentication] Problems renewing machine account password in AD In-Reply-To: <25ad-5b466700-1-150c6660@82024373> References: <25ad-5b466700-1-150c6660@82024373> Message-ID: <20180807123321.GJ13952@p50> On Wed, Jul 11, 2018 at 01:23:16PM -0700, Gordon Messmer wrote: > > 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 at 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 at DOMAIN.LAN >        4 05/04/2018 11:10:30 host/HOST1 at DOMAIN.LAN >        4 05/04/2018 11:10:30 host/host1.domain.lan at DOMAIN.LAN >        4 05/04/2018 11:10:30 host/HOST1 at DOMAIN.LAN >        4 05/04/2018 11:10:30 host/host1.domain.lan at DOMAIN.LAN >        4 05/04/2018 11:10:30 host/HOST1 at DOMAIN.LAN >        4 05/04/2018 11:10:30 host/host1.domain.lan at DOMAIN.LAN >        4 05/04/2018 11:10:30 host/HOST1 at DOMAIN.LAN >        4 05/04/2018 11:10:30 host/host1.domain.lan at DOMAIN.LAN >        4 05/04/2018 11:10:30 host/HOST1 at DOMAIN.LAN >        4 05/04/2018 11:10:30 HOST1$@DOMAIN.LAN >        4 05/04/2018 11:10:30 HOST1$@DOMAIN.LAN >        4 05/04/2018 11:10:30 HOST1$@DOMAIN.LAN >        4 05/04/2018 11:10:30 HOST1$@DOMAIN.LAN >        4 05/04/2018 11:10:30 HOST1$@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 : According to the timestamps the password was update on AD but not in the local keytab. I would expect that the value of the msDS-KeyVersionNumber attribute in the AD entry for host1 is '5' and not '4' as in the keytab. There is an issue with password changes at least with MIT Kerberos http://krbdev.mit.edu/rt/Ticket/Display.html?id=7905. As you said that some of the client might not talk to the "nearest" DC it might be possible that you hit this issues. As a workaround you might want to set 'udp_preference_limit = 0' in the [libdefaults] section of /etc/krb5.conf. This will tell the MIT Kerberos client library to always use TCP and not try UPD first. This will force all Kerberos request to use TCP but this does typically no harm in AD envirionments becasue the Kerberos tickets are too large for UDP due the PAC anyway and the library will switch automatically to TCP while processing the request. > > adcli and sssd are out of date on that host: > >     [root at 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 at 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 at DOMAIN.LAN >       3 05/21/2018 11:50:41 host/host2.domain.lan at DOMAIN.LAN >       3 05/21/2018 11:50:41 host/host2.domain.lan at DOMAIN.LAN >       3 05/21/2018 11:50:41 host/host2.domain.lan at DOMAIN.LAN >       3 05/21/2018 11:50:41 host/host2.domain.lan at DOMAIN.LAN >       3 05/21/2018 11:50:41 host/HOST2 at DOMAIN.LAN >       3 05/21/2018 11:50:41 host/HOST2 at DOMAIN.LAN >       3 05/21/2018 11:50:41 host/HOST2 at DOMAIN.LAN >       3 05/21/2018 11:50:41 host/HOST2 at DOMAIN.LAN >       3 05/21/2018 11:50:41 host/HOST2 at DOMAIN.LAN >       3 05/21/2018 11:50:41 HOST2$@DOMAIN.LAN >       3 05/21/2018 11:50:41 HOST2$@DOMAIN.LAN >       3 05/21/2018 11:50:41 HOST2$@DOMAIN.LAN >       3 05/21/2018 11:50:41 HOST2$@DOMAIN.LAN >       3 05/21/2018 11:50:41 HOST2$@DOMAIN.LAN >       4 06/21/2018 08:09:02 HOST2$@DOMAIN.LAN >       4 06/21/2018 08:09:02 HOST2$@DOMAIN.LAN >       4 06/21/2018 08:09:02 HOST2$@DOMAIN.LAN >       4 06/21/2018 08:09:02 HOST2$@DOMAIN.LAN >       4 06/21/2018 08:09:02 HOST2$@DOMAIN.LAN >       4 06/21/2018 08:09:02 host/host2.domain.lan at DOMAIN.LAN >       4 06/21/2018 08:09:02 host/host2.domain.lan at DOMAIN.LAN >       4 06/21/2018 08:09:02 host/host2.domain.lan at DOMAIN.LAN >       4 06/21/2018 08:09:02 host/host2.domain.lan at DOMAIN.LAN >       4 06/21/2018 08:09:02 host/host2.domain.lan at DOMAIN.LAN >       4 06/21/2018 08:09:02 host/HOST2 at DOMAIN.LAN >       4 06/21/2018 08:09:02 host/HOST2 at DOMAIN.LAN >       4 06/21/2018 08:09:02 host/HOST2 at DOMAIN.LAN >       4 06/21/2018 08:09:02 host/HOST2 at DOMAIN.LAN >       4 06/21/2018 08:09:02 host/HOST2 at 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 at 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 Can you send the full sequence for an authentication attempt from krb5_child.log (if possible with debug_level=9 set in the [domain/...] section of sssd.conf) so that I can get a better understanding at which point this errors happens. I would expect that it happens while setting up a FAST tunnel but even here it would be good to know additional details like the principal which was used. bye, Sumit > >   > _______________________________________________ > Authentication mailing list > Authentication at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/authentication