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

Correct, we don't have idmap entries because we were not using winbind

As I understand it, for UNIX shell logins our LDAP is used for authentication
(passwords are in there) and authorization (since the info is not in AD)

For SAMBA users, AD is for authentication and LDAP is for authorization to the
share data (since the uid and gid info is all in our LDAP)

Our corp assigns the UID and GID numbers so we can't rely on any winbind
generation, we need winbind to find them in our LDAP (if that makes sense)

I thought maybe it could do that with a backend nss and the range set properly

There is a local passwd file user that needs to map as well (which should also
be found from nss with setting 'files ldap', or in the case of our Linux
'files sss')

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 Thu, 2022-03-03 at 20:33 +0000, Vaughan, Robert J via samba
wrote:
> Correct, we don't have idmap entries because we were not using
> winbind
Problem is, you should be. Before Samba 4.8.0 the smbd daemon could
'talk' directly to AD, but from 4.8.0 smbd now has to go via winbind if
'security = ADS'
> 
> As I understand it, for UNIX shell logins our LDAP is used for
> authentication (passwords are in there) and authorization (since the
> info is not in AD)
> 
> For SAMBA users, AD is for authentication and LDAP is for
> authorization to the share data (since the uid and gid info is all in
> our LDAP)
> 
> Our corp assigns the UID and GID numbers so we can't rely on any
> winbind generation, we need winbind to find them in our LDAP (if that
> makes sense)
Why are they doing this ? and if they are doing this, why are they not
using AD
> 
> I thought maybe it could do that with a backend nss and the range set
> properly
No, not really, because it uses SID's to identify the user and them
maps the user to a local user i.e. one in /etc/passwd
> 
> There is a local passwd file user that needs to map as well (which
> should also be found from nss with setting 'files ldap', or in the
> case of our Linux 'files sss')
If you use the 'autorid' or 'rid' idmap backends, you can make
your AD
into local Unix users without them being in your ldap or /etc/passwd.
If you need to set your user & group ID's and/or have individual login
shells and home directories, then you need to use the 'ad' idmap
backend.

The stumbling block here seems to be your corps insistence on setting
the ID's without there being a valid method of using them, you wouldn't
be a university would you ?

Rowland