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?
>>
>>
>> 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.
>
> 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.
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.
>
>> 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
>
> That will allow you ONE local Unix user and 1998 AD Unix users
> I wouldn't recommended it.
>> -------------------------------------
>>
>> Again, very unclear why I'm configuring a tdb database for local
>> accounts, if my understanding of how this works is correct.
>
> You aren't and, unfortunately, it appears you do not understand how it
> works.
>
>> 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.
>
> If you are using the winbind 'ad' backend, then there is no acl
> mapping.
>
>>
>> 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
>>
>
> Try reading our documentation:
> https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member
> https://wiki.samba.org/index.php/Idmap_config_ad
>
> If you still do not understand something, please ask.
>
> I personally would ignore what you have now and set up a new AD domain
> and wouldn't use standalone servers, I would join everything to the
> domain.
>
> Rowland
>
>
>
>