[Samba] Cache auth credentials on Samba domain member

[Uri Simchoni]

On 06/01/2017 08:42 PM, Jeremy Allison wrote:
> On Thu, Jun 01, 2017 at 03:11:53PM +0200, Gionatan Danti wrote:
>> Il 01-06-2017 14:45 Data Control Systems - Mike Elkevizth ha scritto:
>>> I've had issues with cached credentials with the Ubuntu packages that
>>> are currently at version 4.3.11.  They are a little old, but I haven't
>>> seen any change logs for the newer versions specifically regarding
>>> this issue.  Maybe I've missed it, but it's the main reason I continue
>>> using sssd.
>>>
>>> Mike E.
>>>
>>> On Thu, Jun 1, 2017, 2:08 AM Gionatan Danti via samba
>>> <samba at lists.samba.org> wrote:
>>>
>>
>> I tried with sssd also, but with the same result: if connection to
>> the main (remote) AD server is down, samba does not authenticate
>> users. To recap my setup:
>>
>> DOMAIN CONTROLLER (Win2003) <-> VPN TUNNEL <-> REMOTE SAMBA SERVER
>> <-> REMOTE CLIENTS
>>
>> If the VPN tunnel goes down, the remote samba server stop
>> authenticating users. It does not seem a winbind or sssd problem,
>> after all: severing the VPN connection, user authentication *outside
>> samba shares* work correctly (I confirmed it by logging in via SSH
>> using domain credential).
>>
>> However, *no* user authentication is possible on samba shares when
>> the VPN tunnel is down?
>>
>> Do you have any suggestions?
> 
> I think Uri and Volker did the work on this. Uri, can you
> give an update on where we stand with offline auth and
> winbindd ?
> 
> Thanks,
> 
> Jeremy.
> 
I can confirm that latest (master) smbd cannot, in the general case,
authenticate users based on the Kerberos ticket, something which *can*
be done in principle, at least for some id-mapping backends.

The architecture of AD is such that if a Windows client has a ticket to
a Windows server cifs service, then the server should generally be able
to authenticate the client without being connected to a domain
controller, all based on the information in the ticket.

The challenges Samba is facing are:
1. being a UNIX program, it also must be able to translate the Windows
security identifier (SID) to a UNIX uid or gid when not connected to AD.
The feasibility of this depends on the idmap backend (for example, the
rid backend does this, as it is purely algorithmic and does not require
any info from AD. OTOH ldap backends need to make a query to a server).
2. it has to construct the user UNIX profile (uid/gid/shell/home dir)
even when not connected to AD. The feasibility of this depends on
whether or not the account templates contains the primary group name (%G
or %g appearing in "homedir template" or "shell template"), as this info
is not conveyed in the Kerberos ticket.
3. If share access lists in smb.conf reference names of AD users and
groups, smbd has to convert those to Windows SIDs in order to check
access. The workaround is not to do it (use registry-based shares, or
nested groups, or put the SIDs of the AD users/groups in smb.conf).

Even if the configuration adheres to all those guidelines, Samba still
fails because of the way it does things. This can be fixed, but requires
code fixes.

Jeremy, here's a recent rebase of the patch set I made to work around
some issues:

https://github.com/urisimchoni/samba/commits/offline

- The first three are small fixes, I think they can be applied.
- The rest is an effort to avoid having to lookup the sid as part of
sid->unix id mapping. Volker suggested other ways of doing this (partly
a matter of taste and partly a matter of legitimate concern about a race
condition that exists in the case of multiple trusted domains), and I
had no time to drive this home.

So that's the update....

Thanks,
Uri.