[Samba] winbind offline logon

[Kees van Vloten]

Op 10-01-2024 om 17:09 schreef Rowland Penny via samba:
> On Wed, 10 Jan 2024 14:52:12 +0000
> bd730c5053df9efb via samba<samba at lists.samba.org>  wrote:
>
>> I can confirm that on slackware too if I use rid as the backend for
>> the ad domain winbind works offline and the system doesn't slow to a
>> crawl for every process I try to start.
> The 'problem' (if it is a problem) with using  the 'ad' backend is
> that everything has to be pulled from AD, it is my understanding that
> user information is only cached at login.
>   
>> Maybe if ad backend used to work, as stated previously in the thread,
>> it could be fixed since the rid backend has some drawbacks and ad
>> backend has some reasons to be the preferred option but at least for
>> now it is possible for me to use the rid backend until and if the ad
>> backend is fixed to allow offline logon working again. FWIW I'm using
>> samba 4.18.9 in slackware and 4.17.12-Debian in debian.
>>
> What are the drawbacks of using the 'rid' backend that you see ?
> AD, whilst it has all the rfc2307 attributes, it only really uses a
> very small portion of them:
>
> uidNumber
> gidNumber
> gecos
> uid
> loginShell
> unixHomeDirectory
>
> If I run 'getent passwd rowland' on a Unix domain member using the
> 'rid' idmap backend', I get this:
>
> rowland:*:11104:10513:Rowland Penny:/home/rowland:/bin/bash
>
> Which would seem to be:
> username:??:UID:GID:?????:Home Directory:login shell
>
> The '??' is I believe meant for the 'shadow' field.
> The '?????' is the gecos field, but 'rowland' doesn't have a 'gecos'
> attribute, so winbind must be filling in this field from either a
> combination of the givenName and sn attributes, or the displayName
> attribute, all three are in AD.
>
> I cannot see any drawbacks there, which just leaves us with the user
> home directory and login shell. If you use the 'ad' backend, then you
> can set individual paths for home directories and shells, but what does
> this really give you and couldn't you live without this facility ?
>
> The only real thing that using the rfc2307 attributes gives you, is that
> your users & groups will have the same IDs everywhere in Unix land.
> However, do you really need this ? I thought you did, but testing
> proved otherwise.
>
> The following presumes that no rfc2307 attributes are used:
> If I have a share on a DC (yes, I know you shouldn't, but this is
> theoretical) and my user 'rowland' saves a document to that share, it
> will end up belonging to a numeric ID in the '3000000' range.
> If 'rowland' creates another document in a share on a Unix domain
> member that uses the 'rid' backend, with the DOMAIN low range starting
> at '10000', the document will end up belonging to a numeric ID such as
> '11104'
> If you run 'ls' on both machines, the shares will be shown to belong to
> 'rowland', different machines, different IDs, but the same username. If
> you then copy one document from one share to another, it will show as
> belonging to 'rowland' on the new machine.
>
> So I ask again, what are the drawbacks with using the 'rid' backend ?
>
> Rowland
>
The drawbacks I see, are what you already mention. In a more elaborate 
form, that is:

  * A constant UID/GID for a user over multiple systems is important if
    you want to exchange files between machines with other protocols
    than smb, for example nfs or actions by the root user, such as scp
    and untar to/from another machine.
  * In the scenario with users migrated from Samba 3 (or otherwise
    derived from a unix user), they already have a unix UID/GID,
    changing it is a real pain, again due to file ownership.

In the end it boils down to the fact that users are identified by a 
number and that same number is also used for file ownership.

If you are in a greenfield, RID is probably the best choice today, 
otherwise I guess you're stuck with rfc2307 UID/GID assignment.

It would help if nfs was no longer needed. If we could use multi-user 
smb mounts with unix-extensions. The smb protocol will then take care of 
the ownership and adjust it over the wire for a user to the other 
machine's local winbind scheme/backend.
As far as I understood it, there is currently a lot of ongoing work to 
make this last scenario reality, let's hope it becomes reality sooner 
than later :-)


- Kees.