On 11/06/2019 16:03, Goetz, Patrick G via samba wrote:>
> On 6/9/19 7:00 AM, Rowland Penny wrote:
>
>> I said that Samba does not support it because we do not produce it and
that it does very little that winbind doesn't.
>
> I'm not sure I understand how winbind and sssd are even comparable.
> sssd is sort of a unified replacement for pam_ldap and nscd and can, for
> example be configured to allow authentication from an AD and an
> unrelated LDAP server at the same time.
sssd can do things out of the box that winbindd cannot do, but these
things usually rely on extending the AD schema. You can use these schema
extensions with other programs instead of sssd, sudo-ldap instead of
sssd for instance.>
> In our case, our university provides a campus-wide AD authentication
> service with UserName = IDs that people use for other university
> business, so it is convenient to set up linux machines to use AD for
> authentication. Everyone already knows their username and password, so
> it's just up to us to restrict machine access to the appropriate set of
> users.
Winbind will do this>
> sssd also respects AD security groups, so, we are able to create
> security groups in AD and then limit logins on a particular group of
> machines to a particular set of security groups so that, say, the
> structural biology workstations are restricted to the structural biology
> group.
I bet these machines are all in the same place, so you could use PAM to
do this>
> One of the biggest selling points is that there is no need to do any
> kind of id mapping. With sssd we are able to use the SID directly as
> the UID, circumventing mismatched uid issues down the road. As with
> LDAP, account information is not stored locally save for in ephemeral
> caches. The only thing which doesn't work nicely is that everyone is
> assigned to the "Domain Users" group (groups and what they can do
are
> one of the biggest disconnects between Windows and linux), so what I've
> resorted to doing is creating local groups (/etc/group) consisting of AD
> usernames and this works great, if is somewhat inelegant, as I'm
> managing user information in two different locations. There's probably
> a better way to do this, but I haven't seen or thought of anything yet.
This isn't a Unix problem, it is the way AD works, but you can set
different user primary groups with winbind, but it only works with Samba
connecting to shares.>
> Anyway, we've been using sssd in a linux-only environment using
> NFS/autofs to mount file shares.
Autofs will talk directly to AD> Now I'm needing to add some Windows
> machines to the mix and have installed the complete Samba package (sssd
> already uses Samba) on a file server. Jettisoning sssd is not an
> option, so hopefully there is a way to get this to work. Right now,
> when attempting to mount a share:
>
> net use I: \\krakenhost\emtifs /user:austin\pgoetz
>
> I get a password prompt, but then the authentication fails even though I
> can use my AD username to log in to the Samba host directly with no
> problem. Anyway, working on this now.
I couldn't get this to work either, but pam_mount
works.>
> > You are also correct that on a Unix domain member you need to have
> winbind running, so you might as well use it
>
> Not following this comment, either. What is a UNIX domain member?
Exactly what it sounds like, A Unix domain member, just like a Windows
domain member> What
> kind of domain? Again, we have linux machines bound to an AD domain and
> are able to login to these machines with AD accounts with nothing but a
> skeletal version of Samba installed and no winbind at all.
Must be an old version of Samba, later versions require winbind on a
Unix domain member> Using an
> LDAP server has much better integration with the linux ecosystem, but
> then we get stuck with account creation and maintenance, password
> changes, etc.. I've also used Samba with LDAP authentication in an NT
> Domain configuration, and that worked well. I don't recall needing to
> use winbind there, either, but that was a while ago.
>
You can integrate an AD DC pretty much as easy as an LDAP server.
I wouldn't recommend using an NT4 domain any more, it is getting harder
& harder to keep them working with Windows.
Rowland