[Samba] potential machine account expiry question

L.P.H. van Belle belle at bazuin.nl
Tue Nov 2 14:31:49 UTC 2021


Keep in mind, if you use SSSD with my packages, you MUST recompile SSSD

Most quickest way is. (enable the sources lines in /etc/apt/sources.list

(* Optional newer SSSD ) 
echo "deb-src http://ftp.nl.debian.org/debian sid main contrib non-free" > /etc/apt/sources.list.d/sid.list

(* buster only as far i know. ) 
apt-get install -t $(lsb_release -sc)-backports debhelper lintian devscripts build-essential fakeroot dh-systemd libdistro-info-perl quilt -y 

(buster + bullseye ) 
apt-get build-dep sssd -y
apt-get source sssd -by 

With winbind, this is all you need. 

    # How you can use kerberos (man smb.conf search : kerberos method )
    # This is "MY/Louis" preffered method on Member servers.
    kerberos method = secrets and keytab
    dedicated keytab file = /etc/krb5.keytab

    # Renew the kerberos ticket or you member its computer password will expire.
    winbind refresh tickets = yes



Greetz, 

Louis


> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens 
> Patrick Goetz via samba
> Verzonden: dinsdag 2 november 2021 15:21
> Aan: samba at lists.samba.org
> Onderwerp: Re: [Samba] potential machine account expiry question
> 
> Hi -
> 
> I can't speak to this from the perspective of winbind, but 
> this has been 
> a chronic problem with sssd (for myself, and others), so I've 
> run into a 
> similar issue many times.
> 
> Once the kerberos ticket for a machine expires, it can't rejoin the 
> domain without manual intervention. Not sure where you read these 
> tickets don't expire, but they do.  Try running
> 
>    klist -kt
> 
> to see ticket timestamps.
> 
> At least in your case it's obvious why the ticket expired. sssd is 
> supposed to be renewing the kerberos ticket automatically, but it 
> doesn't always work for still unknown reasons. My solution to 
> this for 
> sssd is to run a cron job every night:
> 
>    00 12 * * 1 root  msktutil --update --computer-name cns-cryo-krak7 
> --verbose --server austin.utexas.edu
> 
> That appears to have resolved the issue.
> 
> Again, your situation is more obvious, and since I haven't seen any 
> reports of winbind having a similar problem, I'm hoping to 
> not have to 
> deal with this for my windbind-only installs.  <:)
> 
> On 11/2/21 08:49, Jason Keltz via samba wrote:
> > Hi.
> > 
> > I'm dealing with an interesting problem - potentially a 
> machine account 
> > expiry issue in Samba AD (Samba 4.14.8).
> > 
> > We have multiple Linux computer labs of machines joined to 
> AD (running 
> > Winbind).  Two labs of machines have been off for a few 
> months.  When 
> > turned back on, none of those machines appear to be joined to the 
> > domain.  They were all working fine before.  Other machines have 
> > remained on since they were joined to the domain, and they 
> continue to 
> > function perfectly.
> > 
> > I can report the following:
> > 
> > 1) winbind is running on all the hosts, and I don't see any 
> specific 
> > errors on either the client or the server.
> > 
> > 2) wbinfo -u and wbinfo -g still work (does the client have 
> to be joined 
> > to the domain for this to work?), yet getent passwd <user> returns 
> > nothing (/etc/nsswitch.conf is the same as on a working 
> machine with 
> > "passwd: files winbind", and "group: files winbind".
> > 
> > 3) wbinfo -t says "checking the trust secret for domain 
> EECSYORKUCA via 
> > RPC calls succeeded", wbinfo -m reports BUILTIN, the host 
> name, and the 
> > domain name, and wbinfo --online-status reports active 
> connection for 
> > BUILTIN, the hostname, and the domain name.
> > 
> > 4)  if I rejoin one of these AD clients to the domain, then 
> it works 
> > fine without changing any configuration files at all, and 
> continues to 
> > work after a reboot.
> > 
> > 5) Although information online is very sporadic about this 
> particular 
> > issue, the general consensus seems to be (at least for 
> WIndows clients) 
> > that an AD client which is off will never be automatically 
> "expired"  by 
> > the server after any amount of time. For Windows, there is 
> a default 
> > timeout of 30 days, then the *client* should change the workstation 
> > account password itself when it comes online next whether 
> that's in a 
> > month or a year.
> > 
> > 6) I see samba has the "machine password timeout" option.  
> I don't set 
> > it in my smb.conf, so I assume that the the default of 1 
> week will be in 
> > effect.  It's not clear what happens if this value is far 
> exceeded. This 
> > may be the WIndows equivalent of the 30 day password 
> change. However, I 
> > imagine that when the client comes online and winbind sees 
> that it is 
> > far longer than 1 week, it probably should change the 
> account password 
> > in coordination with the AD server.  I don't think the 
> account would be 
> > disabled.
> > 
> > 7) I reviewed pwdLastSet available via "samba-tool show HOST".  I 
> > compared the result of pwdLastSet on two hosts that were 
> joined to the 
> > domain at approximately same time (same day, a few minutes 
> apart) - one 
> > that has remained on, and the other that has remained off.  
> pwdLastSet 
> > on both of them is the time they were joined to the domain. 
> Why would 
> > the one that remained on not have pwdLastSet updated if winbind is 
> > changing the account password weekly?
> > 
> > 8) The clocks on the AD server and clients are in sync.
> > 
> > Any suggestions on what I might run to debug this issue would be 
> > appreciated.  I have many hosts that I can try on, though 
> eventually I 
> > will have to rejoin them to the domain.
> > 
> > Jason.
> > 
> > 
> 
> -- 
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
> 
> 




More information about the samba mailing list