[Samba] Cache auth credentials on Samba domain member

Jeremy Allison jra at samba.org
Tue Jun 6 23:46:43 UTC 2017


On Tue, Jun 06, 2017 at 08:34:15PM +0300, Uri Simchoni wrote:
> 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.

Can you resend those as a patchset to the list so I can review
and add as normal ?

Thanks !

Jeremy.



More information about the samba mailing list