On 7/6/20 11:00 AM, Rowland penny via samba wrote:> On 06/07/2020 16:29, Georg.Biberger--- via samba wrote:
>> Hello,
>>
>> Get same output with "getent passwd qqeda11" and with
"cat /etc/passwd | grep
>> 'qqeda11'"
>> qqeda11:x:79846:65600:Project Account for EDA:/home/qqeda11:/bin/bash
>> When you say it is not supported, do you mean it is not supported by
samba, or
>> by what else?
>>
>> Georg
>>
> It isn't supported by Samba.
>
> the 'passwd' line in /etc/nsswitch.conf is probably something like
this:
>
> passwd:? compat winbind
>
> Though 'compat' might be 'files'
>
> What this means is search in /etc/passwd for your user, return if found, if
not
> found, search via winbind (in AD)
>
> So if you run 'getent passwd qqeda11' with 'qqeda11' in
/etc/passwd, then this
> the user that will be returned and the user in AD will be ignored.
>
> The LOCAL Unix user != the Domain user
>
IMHO, these discussion are beneficial. "compat" traces back to NIS
(mostly), so
usually means a "combo" search of "+/-" style NIS or other
allow/deny sources in
addition to /etc/passwd (group, etc.).
This may muddy the waters a bit, but this what I wrote in our ansible module
that creates users.
#
# IMPORTANT: There are namespaces in Linux (as in most Unix). Therefore,
# it is possible for there to be a local Linux account defined in
# /etc/passwd, /etc/shadow, etc. and a like named account coming in from
# a different namespace source of identity, e.g. samba/winbind.
#
# nsswitch.conf which is read once by processes that need to know about
# namespaces, can therefore attempt, for example, authentication, against
# multiple disparate identity sources when auth is requested for a name
# that exists in multiple namespaces. While nsswitch.conf determines order
# of lookup, other "things" (like PAM) might thwart further lookup and
# actions.
#
# This ambiguity can be a feature or curse. Just note that things like
# adding a user to be a local Linux account (/etc/passwd, etc) may fail
# if the user can be found already inside a different namespace. Why does
# this matter? Consider provisioning a host with a set of local users.
# And then later joining the same box to a Windows domain using winbind.
# If there are usernames matching both in the list of provisioned local
# users and now via winbind (samba joined to a AD domain), you create the
# scenario of ambiguity. Depending on how a session is established for
# a user found in both namespaces determines their real identity (uid).
# Note, this same ambiguity can be created for system level users that are
# defined in AD as well. In other words, even without any provisioning of
# local users, this problem is possible. If there's any good news, is
# usually login is disabled for such local users Linux side (so session
# confusion is less), but the namespace ambiguity (collision) still exists.
#
# Let's say that you, as mentioned above, provision local Linux accounts
# using some sort of CM or other mechanism. After a target host is running
# winbind after joining a domain, calls to create and/or manipulate users
# may fail or give unexpected results since there is now ambiguity.
#
# But let's say you still want those local accounts, that is, you will
# actually be creating a local user for which there is already one in
# winbind. The way you'd have to do this is to disable the other namespaces
# (winbind). One way to do this would be to shutdown winbind in order to
# create or manipulate local users. Once done, winbind can be re-enabled.
# Just realize that you now have the same username defined in different
# namespaces, and thus depending on how a session is established, a
# different real uid identity for the same username.
#
# Other problems. The namespace origins do not understand each other
# (most of the time). While some tools might query, for example, using getent,
# to determine user existence, and getent passwd, for example, searches
# multiple namespaces, other tools might not and might make assumptions and
# operate solely with regards to their own namespace. Some tools may do a
# little of both. Might query multiple namespaces, but make manipulation
# assumptions based on one namespace.
#
# Linux can see and somewhat understand multiple namespaces. However, other
# systems that you might be dependent upon for identity, likely don't know
# anything about local users on your Linux host (duh). The ability for Linux
# to "smash" multiple identities by name could be a feature. However,
because
# of this multiple identify ambiguity, it can also cause confusion.
#
# nsswitch.conf, ideally, but again, read once by service processes, can
# determine order of name lookup. However, rules inside of a PAM (Pluggable
# Authentication Modules) stack can actually implement a different forced
# ordering based on how an individual module works or ordering there. Again,
# this can be a feature or curse. In short, anytime you have multiple disparate
# namespaces, you have the opportunity for this sort of ambiguity. But
# obviously, querying against multiple sources of auth is a feature, the curse
# usually comes in the form of session identity (or rule stacks like PAM).
#
# I could write a book on this. And we just mostly picked on local
# users vs. samba and didn't touch on NIS, LDAP, rfc2307 and interesting
things
# from the past like Windows Service For Unix (SFU) (what I'm trying to say
is
# that identify ambiguity caused by different namespaces, and the features and
# curses it creates, have been around a very very long time).
#
# One possible mitigation, is where possible (and this is not 100%), you
# can attempt to ensure the same uids (and gids, service ids, etc) in all
# sources. Just remember, these namespace owners don't usually respect one
# another. So success cannot be guaranteed, even if working at first. Just as
# a simple case, when there are multiple disparate sources, even if agreement
# can be made initially with regards to uid session identity, as modifications
# get made independently over time, there is great likelihood that that
# preserving unified agreements will degrade to the point of disagreement. Why?
# Because the sources are disparate. If you can somehow force control of every
# namespace through a common control that understands and can manipulate all the
# namespaces, then, in theory, you might be able to maintain consistency across
# the namespaces. But you might have to control entire systems (e.g. operating
# systems) in total. And such deep embedding of control is probably not
# possible, not entirely.
#