[Samba] (no subject)

Ryan rlichtenwalter at gmail.com
Wed Jun 12 14:26:01 UTC 2019


Sorry for the repost: my message delivery was set to digest, and that was
hard to manage use for conversation. I changed that setting. So starting
clean with the same subject...

I don't care about SSSD or whether it's even on the machine or not. Right
now, it's only used by the machine for login. It isn't used by Samba, and I
am very careful to let libwbclient-sssd nowhere near the system to avoid
the problems that causes.

I have looked into the idmap_rid backend, and I do not understand how it
could be helpful here. I'm not saying I think it isn't; I'm just saying I
don't understand. If I'm missing something, please do help if you can.

What I essentially need, which is accomplished by the configuration in the
wiki article I provided for old Samba versions when winbindd is not used is:

1. Windows user attempts to access share with credentials from either
already having logged in on a machine with a domain account or by employing
"Connect using different credentials" to spontaneously login with a domain
account.

2. Samba (with winbindd) performs authentication of username %U against
Active Directory domain EXAMPLE.COM, effectively authenticating EXAMPLE.COM
\%U

3. If authentication fails, stop. If authentication succeeds, ignore SID,
groups and everything else from the AD server, because that server is
*only* to be used for authentication of %U. Continue processing.

4. Use username %U to query the LDAP server at ldap.mydomain.com for UID,
GID, and UNIX groups.

5. Given information returned from step 4, check user authorization against
share definition requirements and permit access for user with UID and GID
set as per LDAP lookup.

And it's essentially just:

https://wiki.samba.org/index.php/Samba,_Active_Directory_%26_LDAP

that works with Samba 4.8.0 and winbindd instead of relying on the old
Samba fallback mechanism.

How can this be accomplished with winbind?

Kind regards,

Ryan

P.S. This may be a fairly common use case, since each large organization
may deploy Kerberos authentication via AD but relatively many smaller
sub-organizations may want to rely on the existing authentication
architecture while managing their own authorization (e.g. physics,
chemistry, mathematics, and computer science departments who each want
autonomous authorization without deploying un-synced authentication
themselves and leaving users with more credentials to manage). The current
use is the third organization I've seen it in or needed it in
professionally, but since EL 7 picked up Samba 4.8.0, it is broken as
deployed. :-(


More information about the samba mailing list