[Samba] id mapping

[Patrick Goetz]

On 9/23/21 14:39, Rowland Penny via samba wrote:
> On Thu, 2021-09-23 at 13:50 -0500, Patrick Goetz via samba wrote:
>> Finally getting back to this.
>>
>> On 9/19/21 13:51, Rowland Penny via samba wrote:
>>> On Sun, 2021-09-19 at 13:16 -0500, Patrick Goetz via samba wrote:
>>>> Hi -
>>>>
>>>> This question is with reference to:
>>>>     https://wiki.samba.org/index.php/Idmap_config_ad
>>>>
>>>> I think I know how this works, but there are still points of
>>>> confusion.
>>>> Given the example smb.conf file provided on the page referenced
>>>> above:
>>>>
>>>> [global] section of smb.conf:
>>>> -------------------------------------
>>>>      security = ADS
>>>>      workgroup = SAMDOM
>>>>      realm = SAMDOM.EXAMPLE.COM
>>>>
>>>>      log file = /var/log/samba/%m.log
>>>>      log level = 1
>>>>
>>>>      # Default ID mapping configuration for local BUILTIN accounts
>>>>      # and groups on a domain member. The default (*) domain:
>>>>      # - must not overlap with any domain ID mapping
>>>> configuration!
>>>>      # - must use a read-write-enabled back end, such as tdb.
>>>>      idmap config * : backend = tdb
>>>>      idmap config * : range = 3000-7999
>>>>      # - You must set a DOMAIN backend configuration
>>>>      # idmap config for the SAMDOM domain
>>>>      idmap config SAMDOM:backend = ad
>>>>      idmap config SAMDOM:schema_mode = rfc2307
>>>>      idmap config SAMDOM:range = 10000-999999
>>>>      idmap config SAMDOM:unix_nss_info = yes
>>>>
>>>>      vfs objects = acl_xattr
>>>>      map acl inherit = yes
>>>>      store dos attributes = yes
>>>> -------------------------------------
>>>>
>>>> I believe "Default domain" is a bit of a misnomer referring to
>>>> accounts
>>>> that are identified by nss before it gets to winbind or sssd;
>>>
>>> You cannot use sssd with Samba.
>>>
>>>>    i.e.
>>>> accounts found in /etc/passwd.
>>>
>>> No, they are for the AD BUILTIN domain and are not in etc/passwd or
>>> /etc/group
>>>
>>>> So on this system (assuming no other
>>>> directory services are configured), UIDs 3000-7999 are available
>>>> for
>>>> use
>>>> in /etc/passwd.
>>>
>>> No, you cannot use that range in /etc/passwd or /etc/group
>>>
>>>> What I don't understand is why you're assigning a tdb
>>>> backend to this when the authentication is going to be handled by
>>>> pam_unix rather than pam_windbind.  That's the main point of
>>>> confusion.
>>>
>>> That it is where your confusion starts, the ranges set in smb.conf
>>> are
>>> not handled by pam_unix, they are handled by pam_winbind or
>>> pam_krb5
>>>
>>
>> Yes, I'm confused, but mainly because I don't understand the purpose
>> of
>> the default BUILTIN domain. The domain we're configuring in the
>> documentation is SAMDOM -- what is the default domain for?
> 
> The default domain (*) is meant for the Well Known SID's (see here
> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/81d92bba-d22b-4a8c-908a-554ab29148ab
> ) and anything outside the 'DOMAIN' domain (trusted domains etc)
> 
>>
>>
>>>>
>>>> Second, I'm assuming these 2 lines:
>>>>
>>>>      idmap config SAMDOM:schema_mode = rfc2307
>>>>      idmap config SAMDOM:range = 10000-999999
>>>>
>>>> Refer to the values that can be set for the uidNumber attribute
>>>> in
>>>> the
>>>> Active Directory database and further that users authenticating
>>>> on
>>>> this
>>>> linux system will have the UIDs and GIDs specified in
>>>> thedesicion uidNumber
>>>> and
>>>> gidNumber attributes associated with their user record.
>>>
>>> Yes, but whilst the users & groups are authenticated by Samba AD,
>>> they
>>> are also Unix users & groups
>>>
>>>> It seems like you don't necessarily need:
>>>>
>>>>      idmap config SAMDOM:unix_nss_info = yes
>>>
>>> You only require this setting if you want to use a specific login
>>> shell
>>> & home directory per user
>>>    
>>>> if everyone uses the same default shell and has the same home
>>>> directory
>>>> path; i.e. if these can be set using a global template.
>>>>
>>>> Based on the correctness of the above,
>>>
>>> I think you may need to rethink your ranges etc. Also are you aware
>>> that Samba has a way to upgrade an NT4-style domain to an AD domain
>>> ?
>>>
>>>>    I"m converting a small NT domain
>>>> to Active Directory (by hand).  The environment has several linux
>>>> machines with local UIDs assigned in the 1001-2000 range (but
>>>> with
>>>> the
>>>> UIDs the same across the linux hosts).  Since I don't plan to
>>>> bind
>>>> most
>>>> of the linux machines to the domain (there is a vague user-driven
>>>> business case for this),
>>>
>>> I would rethink this, it is always better to join machines to the
>>> domain.
>>>
>>>> I would like the authorization to work the same
>>>> for Samba shares to AD bound Windows machines and the standalone
>>>> linux
>>>> workstations,
>>>
>>> Good luck with that, it is probably impossible to get the same
>>> numeric
>>> ID's on unjoined machines.
>>
>> You've convinced me I need to bind all machines (including the linux
>> machines) to the domain, but then I don't really see the point of
>> using
>> RFC 2307 extensions. The AD server will equate the user's SID with
>> their
>> UID regardless of what the UID is, and all users have an assigned
>> UID
>> based on the id mapping, whatever it is. I guess if you already have
>> a
>> large filesystem with legacy POSIX permissions, using RFC 2307
>> prevents
>> you from having to re-assign all the permissions. In the absence of
>> that
>> concern, and in the case of a single domain with Samba AD I would
>> probably just use UID=RID, which I think is one of the options.
> 
> You only need the rfc2307 attributes if you want your Unix users to
> have different login shells and home directories. If you are happy for
> your users to all have the same login shells (/bin/bash for instance)
> and the same home directories (/home/SAMDOM/username), you can use the
> 'rid' or autorid' winbind backend, these use the AD RID to calculate
> the user or group Unix ID, read 'man idmap_rid' and 'man idmap_autorid'
> for more information.
> 
>>
>> However, I'm not seeing why this wouldn't work: User foobar has the
>> UID/GID 1517 on an unaffiliated linux host. So in AD, I set the
>> uidNumber and gidNumber for UserName foobar to 1517.  Presumably the
>> owner UID for any files on the Samba file server for AD user foobar
>> would be 1517, so an NFS mount using sec=sys to the linux machine
>> would
>> have the right permissions. If they log in to a Windows client, the
>> SID
>> would be equated to UID 1517 by the DC and permissions on the Samba
>> share to the Windows client would work, too. (Yes, of course this
>> would
>> turn into a maintenance headache, which is why you've convinced me
>> to
>> bind everything to the domain.) I'm pushing back on the "impossible"
>> claim.
> 
> Looking at how the 'rid' backend works, it uses this formula:
> 
> ID = RID - BASE_RID + LOW_RANGE_ID
> 
> The Base_RID is 0 by default, so it becomes:
> 
> ID = RID + LOW_RANGE_ID
> 
>  From that, I hope you can see that it is unlikely you will get '1517'
> for the ID. you would need this user to be the first user you create
> and the the DOMAIN range would need to be set to something like 517-
> 999999, which would lead to:
> 
> 1517 = 1000 + 517
> 
> 'autorid' uses a slightly different formula, but works in the same way.
> 
> Rowland
> 
> 
> 

Right.  But I"m talking about the use case where you use the ad id 
mapping. Sorry to be a pest, I'm perfectly willing to accept that I'm 
still confused, but my understanding is that if you use the ad id 
mapping, when a user saves a file to the Samba file server the UID it 
uses for file owner is the uidNumber attribute stored in AD with the 
user's record.  If that same file server is providing NFS service with 
sec=sys, the UIDs on the respective systems would match even though the 
linux client has a local /etc/passwd user with UID 1517. Not suggesting 
this is advisable, just that it's do-able.

OK, just thought of a use case where this might make sense: a compute 
cluster where the nodes live entirely behind the master node with no 
network access. Warewulf, for example, has nodes boot from a golden 
image and has scripts to update /etc/passwd, /etc/shadow, and /etc/group 
in the golden image when your user base changes. In this case it's 
conceivable that your master node could be bound to a domain and you 
have some automated mechanism for regularly updating the nodes' 
/etc/passwd file from the AD security group authorized to access the 
cluster. Typically one doesn't allow password authentication to such 
nodes anyway. You use either ssh keys, host-based authentication, or in 
many cases you don't want the users mucking about on the nodes at all 
because they're supposed to submit jobs through a scheduling system and 
not try to game the system. You do, however, need authorization to work 
for data file access.