Re: [Samba] Samba4 changing a user's password from linux workstation
- Date: Tue, 14 May 2019 16:14:16 +0100
- From: Rowland penny via samba <samba@xxxxxxxxxxxxxxx>
- Subject: Re: [Samba] Samba4 changing a user's password from linux workstation
On 14/05/2019 15:39, Robert Marcano via samba wrote:
On 5/14/19 9:58 AM, Rowland penny via samba wrote:
On 14/05/2019 14:35, Luc Lalonde wrote:
We’ve been using SSSD with Acitve Directory for a few years now…
It’s been solid for us.
I never said it wasn't solid (possibly because it it is built on top
of some of the winbind code), I just said that you do not need it.
Our Linux clients use the AD-Kerberos via SSSD for secure NFS4
mounts with POSIX attributes defined in AD
(uidNumber, gidNumber, unixHomeDirectory, loginShell).
Funnily enough, you can do all of the above with winbind.
Before putting into production, I tested using Winbind and could not
get it to do what I wanted. If I remember correctly, I had
problems with groups. I didn’t want DOMAIN\groupname… just
groupname to show. I don’t remember why this was causing me
problems… just that this was the main reason.
You mean something like this:
getent group Domain\ Users
If it didn't work for you, then your smb.conf was mis-configured.
That just basically says 'Hey, use our product', it doesn't really
say why and just how sssd is better than winbind.
At the time, I found that the documentation for integrating AD with
Linux was best documented… in particular at RedHat:
They give further reasons for choosing SSSD over Winbind in that
I avoid SSSD discussions on this list for two reasons, It isn't a
support list for SSSD and this kind or responses. winbind is not
perfect and some people use SSSD with valid reasons. If we can't
discuss why people choose it instead of winbind, always saying that
winbind is enough, those people will continue to use sssd.
My two reasons for using SSSD:
1) I have servers that need to be joined to a non Windows Kerberos
realm (MIT Kerberos managed by FreeIPA), this automate many things
like for example services certificates generation and renewal. Those
servers need at the same time to be joined to an AD domain. Using
SSSD/Reamld makes the configuration of those realms too easy, with a
single INI like configuration file, without the need to mess with PAM
configuration that it is too easy to make a hole in your security,
especially when configuring multiple realms like this setup. This will
never be achieved by winbind because it should never have the
responsibility to interact with non AD realms.
This is a valid reason to use sssd and realmd, you are using them with
the directory server they were designed for.
2) SSSD provides an option to generate synthetic private groups 
for users without having to manually manage primary groups on AD, or
having to create groups for that, or polluting AD with a lot of groups
named like users. The default winbind/AD that the primary group is
Domains Users is a security headache that requires to change the
default umask of those users in order to avoid leaking data to all
domain members. This is an option that could help winbind users if
implemented. I remember mentioning it here previously but never
created a RFE bug, I didn't get any response so I forgot, my mistake,
I should have created it.
You can create a group (or groups) that will be used as Unix users
primary group, but you cannot create (in any way) any user private
groups (with the same name) with winbind, but you can lock down group
To unsubscribe from this list go to the following URL and read the