[Samba] id mapping

[Patrick Goetz]

To clarify, my previous message, the proposed configuration would be for 
a linux Samba file server bound to the domain, not the DC, for which, I 
believe, it is not recommended to use the RFC2307 mappings (also not 
sure why this is, but since I'm not letting uses login in to the DC, it 
doesn't matter much).

On 9/19/21 1:16 PM, 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; i.e. 
> accounts found in /etc/passwd. So on this system (assuming no other 
> directory services are configured), UIDs 3000-7999 are available for use 
> in /etc/passwd. 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.
> 
> 
> 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 the uidNumber and 
> gidNumber attributes associated with their user record.
> 
> It seems like you don't necessarily need:
> 
>    idmap config SAMDOM:unix_nss_info = yes
> 
> 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"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 like the authorization to work the same 
> for Samba shares to AD bound Windows machines and the standalone linux 
> workstations, since these systems mount the same remote filesystems via 
> either SMB or NFS in the case of the linux systems. So my thought is to 
> do something like this:
> 
> portion of [global] section of smb.conf
> -------------------------------------
> idmap config * : backend = tdb
> idmap config * : range = 2000-2999
> # - 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 = 1001-1999
> -------------------------------------
> 
> Again, very unclear why I'm configuring a tdb database for local 
> accounts, if my understanding of how this works is correct. This would 
> reserve the UIDs 2000-2999 for potential local use, while creating an AD 
> UID mapping that seamlessly works with the existing linux systems. Then 
> if I do end up binding some of these linux machines to the domain, 
> everything just works with no acl mapping, or anything like this.
> 
> Any thoughts?  Am I confused about how this works?  My understanding of 
> how the default domain works is based on this RHEL article:
> https://access.redhat.com/solutions/1984483
> 
> 
> 
>