samba - Mar 2022 - Samba forces domain members to use winbind now

Before the winbind requirement, our Samba (ads member) worked I suppose
something along these lines ..

Windows user authenticated by AD and then DOMAIN\user reduced to 'user'
by Samba and found a match in our UNIX LDAP (via nsswitch sss or ldap entry)
because we have all our Samba users setup in our UNIX LDAP with the same
(matching) userid to get the UNIX uid and gid info

Now we must use winbind to authenticate with AD and winbind needs to be
configured as to how it gets the UNIX uid/gid info (either by generating them,
or looking them up in some backend facility)

So I want to use our UNIX LDAP as that backend facility

It seems to work fairly well with a config like this ..

        idmap config * : backend = tdb
        idmap config * : range = 1000000-1999999
        idmap config XXX : backend = nss
        idmap config XXX : range = 400-199999


but I have seen where a test user (and me too) who could map a share one day be
unable to map it the next with this error ..

create_connection_session_info: user 'my userid' (from session setup)
not permitted to access this share

If I stop smb and winbind at that point, delete tdb files, restart smb and
winbind it starts working again

So I feel like I am close to something that works for us

Rob

----------------------------------------------------------------------
This is an e-mail from General Dynamics Land Systems. It is for the intended
recipient only and may contain confidential and privileged information.  No one
else may read, print, store, copy, forward or act in reliance on it or its
attachments.  If you are not the intended recipient, please return this message
to the sender and delete the message and any attachments from your computer.
Your cooperation is appreciated.

On Fri, 2022-03-04 at 17:43 +0000, Vaughan, Robert J via samba
wrote:
> Before the winbind requirement, our Samba (ads member) worked I
> suppose something along these lines ..
> 
> Windows user authenticated by AD and then DOMAIN\user reduced to
> 'user' by Samba and found a match in our UNIX LDAP (via nsswitch
sss
> or ldap entry) because we have all our Samba users setup in our UNIX
> LDAP with the same (matching) userid to get the UNIX uid and gid info
Before Samba 4.8.0 that would have worked
> 
> Now we must use winbind to authenticate with AD and winbind needs to
> be configured as to how it gets the UNIX uid/gid info (either by
> generating them, or looking them up in some backend facility)
That is correct.
> 
> So I want to use our UNIX LDAP as that backend facility
Not sure that is going to work.
> 
> It seems to work fairly well with a config like this ..
> 
>         idmap config * : backend = tdb
>         idmap config * : range = 1000000-1999999
>         idmap config XXX : backend = nss
>         idmap config XXX : range = 400-199999
The 'nss' backend requires you to have the same users in your database
and AD and the AD users would be mapped to the users in your database.
> 
> 
> but I have seen where a test user (and me too) who could map a share
> one day be unable to map it the next with this error ..
> 
> create_connection_session_info: user 'my userid' (from session
setup)
> not permitted to access this share
> 
> If I stop smb and winbind at that point, delete tdb files, restart
> smb and winbind it starts working again
If an error occurs looking up your user in your ldap, then winbind will
not have a user to map to. You could also have intermittent problems
connecting to AD.
> 
> So I feel like I am close to something that works for us
No, you seem to have something that sometimes works for you.

As you have already admitted that the ldap is only used for
authentication, your best bet would be to add your user and group ID's
to AD and then use the 'ad' winbind idmap backend.

Rowland