samba - Oct 2019 - winbind : suspend nightmare

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