On Tue, 2019-10-22 at 22:26 -0700, Jeremy Allison via samba wrote:> On Mon, Oct 21, 2019 at 10:07:20AM +0200, Prunk Dump via samba wrote: > > I don't know if winbind "officially" support suspending. Currently > > I > > have written a systemd hook that kill winbind before suspend and > > restarting it after. > > It hasn't been tested in that mode as far as I know. > > Congratulations, you're the first ! :-). >(Sorry for the wall of words) Not exactly the first. I have been using winbind for several years now to integrate my workstations and laptops into a Windows world. My goal is to be able to hand a Linux laptop to an end user and off they trot with everything in place and properly useable. I'm rather close to my goal. Evolution for Exchange, Libre Office for errrr office, Kerberos all over the shop for as much as possible (Evo EWS can do Kerb). autofs with mount.cifs and Kerb for "drive mappings". CUPS can take Kerb auth and supports everything that prints (ta Apple). You can import your AD CA cert to the OpenSSL trust store so LDAPS works properly and your browsers can be persuaded to trust it as well. If you enable NDES on your AD CA then you can grab SSL certs for your Linux boxes with Certmonger and then you can do Wifi 802.1X and trusted web server etc. The last major hurdle is the laptop experience, ie suspend/resume. To be honest it isn't too bad and not too far from using Windows but Windows will always allow you to login with cached creds but a winbind based box will give you a fairly random result. I use nss_winbind and the rid idmap backed to get the same user on each device. It really does work very nicely for ethernet wired workstations - by the time everything has woken up in a short time, the user is available for auth via winbind. On a laptop with say VPNs over wifi to wake up you have to wait a while otherwise your userid will come up as unknown and it looks like there is some sort of caching (I've binned nscd) for quite a while. If you restart winbind then the userid will become available much quicker, so that systemd hook sounds like a great idea, that I will try out soon. winbind has a concept of offline and online but I don't know what that is, nor how nss works with it. I've tried using smbcontrol to tell winbind it is offline or online but that does not seem to work. Restarting winbind normally gets my account working again. If I had to guess, then offline and online mean "network available" (layer 2/3) and not "AD available" (layer 3/4) Cheers Jon
On Wed, Oct 23, 2019 at 11:58:33PM +0000, Jon Gerdes wrote:> > winbind has a concept of offline and online but I don't know what that > is, nor how nss works with it. I've tried using smbcontrol to tell > winbind it is offline or online but that does not seem to work. > Restarting winbind normally gets my account working again. If I had to > guess, then offline and online mean "network available" (layer 2/3) and > not "AD available" (layer 3/4)I implemented the 'winbind offline' code many years ago whilst working for SuSE to cover this exact use case. It detects when it can't contact a DC and puts itself into the 'offline' mode, which means serve logins out of local cache. It should do this for whatever reason when it can't talk to a DC (network fail, DC not found etc. etc.). On startup if winbind can't talk to a DC it sets a retry timer to go off every 10 seconds to try and re-connect to the DC. It keeps that timeout until it does contact a DC, when it resets the reconnect timer to be 30 seconds. If it loses connection to the DC after it has once made connection it puts itself in offline mode and then retries every 30 seconds. The long (30) second timeout can be changed by setting the parameter: winbind reconnect delay = X. Hope this helps ! Jeremy.
On Wed, 2019-10-23 at 22:21 -0700, Jeremy Allison wrote:> On Wed, Oct 23, 2019 at 11:58:33PM +0000, Jon Gerdes wrote: > > winbind has a concept of offline and online but I don't know what > > that > > is, nor how nss works with it. I've tried using smbcontrol to tell > > winbind it is offline or online but that does not seem to work. > > Restarting winbind normally gets my account working again. If I had > > to > > guess, then offline and online mean "network available" (layer 2/3) > > and > > not "AD available" (layer 3/4) > > I implemented the 'winbind offline' code many years ago > whilst working for SuSE to cover this exact use case. > > It detects when it can't contact a DC and puts itself > into the 'offline' mode, which means serve logins out > of local cache. It should do this for whatever reason > when it can't talk to a DC (network fail, DC not > found etc. etc.). > > On startup if winbind can't talk to a DC it sets > a retry timer to go off every 10 seconds to try > and re-connect to the DC. It keeps that timeout > until it does contact a DC, when it resets the > reconnect timer to be 30 seconds. If it loses > connection to the DC after it has once made > connection it puts itself in offline mode and > then retries every 30 seconds. > > The long (30) second timeout can be changed > by setting the parameter: > > winbind reconnect delay = X. > > Hope this helps ! > > Jeremy.Jeremy Thanks for that. I was steeling myself to diving into the code but having the author describe it is fantastic. Cheers Jon
On Wed, 2019-10-23 at 22:21 -0700, Jeremy Allison wrote:> On Wed, Oct 23, 2019 at 11:58:33PM +0000, Jon Gerdes wrote: > > winbind has a concept of offline and online but I don't know what > > that > > is, nor how nss works with it. I've tried using smbcontrol to tell > > winbind it is offline or online but that does not seem to work. > > Restarting winbind normally gets my account working again. If I had > > to > > guess, then offline and online mean "network available" (layer 2/3) > > and > > not "AD available" (layer 3/4) > > I implemented the 'winbind offline' code many years ago > whilst working for SuSE to cover this exact use case. > > It detects when it can't contact a DC and puts itself > into the 'offline' mode, which means serve logins out > of local cache. It should do this for whatever reason > when it can't talk to a DC (network fail, DC not > found etc. etc.). > > On startup if winbind can't talk to a DC it sets > a retry timer to go off every 10 seconds to try > and re-connect to the DC. It keeps that timeout > until it does contact a DC, when it resets the > reconnect timer to be 30 seconds. If it loses > connection to the DC after it has once made > connection it puts itself in offline mode and > then retries every 30 seconds. > > The long (30) second timeout can be changed > by setting the parameter: > > winbind reconnect delay = X. > > Hope this helps ! > > Jeremy.Now I've had a chance to think about this and your notes, the way ahead is looking clearer to me. As you say, your code was written years ago in the days when sysvinit was boss (I was using openrc back then as well as sysvinit.) My only modern use case is systemd and (probably) NetworkManager. My initial effort is going to be: * System suspends to RAM or disc - shutdown the winbind service * System wakes from RAM or disc - start winbind service I initially thought to make winbind depend on network which will work when net is available but delay or break an offline logon when net is not available. Windows seems to generally get the ogin experience right in most cases but then MS gets to write all the code and declare all the APIs and they get to break things at will for a laugh. Given where Unixy stuff came from and where X Windows and all the other gear in our preferred OS started from, it is a bloody miracle that anything hangs together (no it's not - we have some damn fine engineers working on our gear). This all might all sound a bit naff to most people but the login experience on a roaming device is really, really hard to get right. wifi might need a login or a button click - Windows is a bit shit here. You cannot accept a wifi arrangement on Win10 before login. That means your VPN has not started up (no trusted network) and that means you have not authenticated yourself to your domain - you can only do cached creds. So, Mr A: Are you able to reliably login to a Linux powered laptop with an AD mediated account? I have to employ a few workarounds for several scenarios. wifi on/off, VPN on/off, wired vs wifi, IPv6 vs IPv4 are some of the considerations. Could I request you look at your winbind on/offline code with a modern viewpoint. I suspect you need to require the environment to tell winbind what is happening to it rather than deploying a few randomly chosen timers. Cheers Jon