samba - Oct 2024 - Member server plus local accounts - can it be done?

Good morning list,

due to several changes we have to move from a pure local-users scenario 
to a member server scenario for our "public" data servers
("public" in
terms of "all members of the chair" and "all machines").

The member server is running, managing access via group memberships 
works. We can't add any account to the ad, as we are only a user of that 
ad, and accounts are only created for real persons and machines.

But we also have ancient systems, that use a local useraccount from the 
dataserver to put data on it.
So, is something like:
         realm = REALM.TLD
         security = ADS
         server role = member server
         username map = /etc/samba/user.map
         winbind refresh tickets = Yes
         winbind use default domain = Yes
         workgroup = REALM
         idmap config REALM : backend = rid
         idmap config REALM : range = 10000-9999999
         idmap config * : backend = tdb
         idmap config * : range = 3000-7999
possible?
I would then create the local useraccount with smbpasswd ...

Thanks in advance!

Cheeres,
Torsten

Op 28-10-2024 om 09:51 schreef lists--- via samba:
> Good morning list,
>
> due to several changes we have to move from a pure local-users 
> scenario to a member server scenario for our "public" data
servers
> ("public" in terms of "all members of the chair" and
"all machines").
>
> The member server is running, managing access via group memberships 
> works. We can't add any account to the ad, as we are only a user of 
> that ad, and accounts are only created for real persons and machines.
>
> But we also have ancient systems, that use a local useraccount from 
> the dataserver to put data on it.
> So, is something like:
> ??????? realm = REALM.TLD
> ??????? security = ADS
> ??????? server role = member server
> ??????? username map = /etc/samba/user.map
> ??????? winbind refresh tickets = Yes
> ??????? winbind use default domain = Yes
> ??????? workgroup = REALM
> ??????? idmap config REALM : backend = rid
> ??????? idmap config REALM : range = 10000-9999999
> ??????? idmap config * : backend = tdb
> ??????? idmap config * : range = 3000-7999
> possible?
> I would then create the local useraccount with smbpasswd ...
>
A user in posix terms is just a UID/GID, where it is defined does not 
matter. Files are owned by a user based on owner/group which is a 
UID/GID number combination.

A user can just be one pair of UID/GID at a time, the lookup order is 
defined in /etc/nsswitch.conf. It will either get UID/GID for a username 
from AD or from the local /etc/passwd and /etc/group.? There is no 
objection against having users defined in both places but the lookup 
will just resolve to one of them and use that UID/GID.

When your users are moved from locally defined to AD, they probably get 
a different UID/GID, which means you have to renumber the owner/group of 
the files and directories of those users on the machine.

There is no real alternative, if you ask me.

- Kees.

> Thanks in advance!
>
> Cheeres,
> Torsten
>

On 10/28/24 9:51 AM, lists--- via samba wrote:
> But we also have ancient systems, that use a local useraccount from the 
> dataserver to put data on it.
> So, is something like:
>  ??????? realm = REALM.TLD
>  ??????? security = ADS
>  ??????? server role = member server
>  ??????? username map = /etc/samba/user.map
>  ??????? winbind refresh tickets = Yes
>  ??????? winbind use default domain = Yes
>  ??????? workgroup = REALM
>  ??????? idmap config REALM : backend = rid
>  ??????? idmap config REALM : range = 10000-9999999
>  ??????? idmap config * : backend = tdb
>  ??????? idmap config * : range = 3000-7999
> possible?
> I would then create the local useraccount with smbpasswd ...
yes. As you're using "winbind use default domain" I guess those
local
users will have to authenticate with the local SAM name as prefix 
("${netbiosname}\username"), otherwise they will be treated as REALM 
users and REALM doesn't know about them.

Or the other way around, remove "winbind use default domain = Yes",
but
then domain users must specify the domain prefix. You'll have to die one 
death...

-slow

-- 
SerNet Samba Team Lead https://sernet.de/
Samba Team Member      https://samba.org/
SAMBA+ packages       https://samba.plus/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.samba.org/pipermail/samba/attachments/20241028/d21f4362/OpenPGP_signature.sig>

On Mon, 28 Oct 2024 09:51:33 +0100
lists--- via samba <samba at lists.samba.org> wrote:
> Good morning list,
> 
> due to several changes we have to move from a pure local-users
> scenario to a member server scenario for our "public" data
servers
> ("public" in terms of "all members of the chair" and
"all machines").
> 
> The member server is running, managing access via group memberships 
> works. We can't add any account to the ad, as we are only a user of
> that ad, and accounts are only created for real persons and machines.
> 
> But we also have ancient systems, that use a local useraccount from
> the dataserver to put data on it.
> So, is something like:
>          realm = REALM.TLD
>          security = ADS
>          server role = member server
>          username map = /etc/samba/user.map
>          winbind refresh tickets = Yes
>          winbind use default domain = Yes
>          workgroup = REALM
>          idmap config REALM : backend = rid
>          idmap config REALM : range = 10000-9999999
>          idmap config * : backend = tdb
>          idmap config * : range = 3000-7999
> possible?
No ;-)
> I would then create the local useraccount with smbpasswd ...
No that wouldn't work, it would have to create the user in AD to work
and it will not do that.

Samba will need to know the user and the only way for Samba to know the
user is if the user is in AD.
Two ways out of this, allow the guest user to connect to the share, or
map your ancient user to an existing AD user.
 
Rowland