[Samba] samba4 and sssd and user mapping

[Denis Cardon]

Hi everyone,

on a server running samba4 with sssd for nsswitch mapping, I realized
recently that on windows workstation in the "folder propery/security
tab", users are mapped as "Unix user\userlogin" instead of
"DOMAINNAME\userlogin".

I guess this is due to the fact that sssd mapping with getent passwd
gives me user name without domain name (eg. userlogin), and in the
samba4 smb.conf I don't know how to specify to use default domain, so it
probably maps users to DOMAINNAME\userlogin.

Looking at sssd doc, I didn't find how to add domain name in sssd.conf,
and in smb.conf, the only related command is "winbind use default
domain", and I'd like to use sssd instead of winbind.

So I'd like to ask if there is a "use default domain" command for
smb.conf without winbind?

Cheers,

Denis


--
Denis Cardon
Tranquil IT Systems
Les Espaces Jules Verne, bâtiment A
12 avenue Jules Verne
44230 Saint Sébastien sur Loire
tel : +33 (0) 2.40.97.57.55
http://www.tranquil-it-systems.fr

--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

[steve]

On Mon, 2014-01-20 at 11:25 +0100, Denis Cardon wrote:

>
> So I'd like to ask if there is a "use default domain" command for
> smb.conf without winbind?

In sssd, it is the default. You get just the name of the object. Nothing
needs to be added to either sssd.conf nor smb.conf.

HTH
Steve

[Rowland Penny]

On 20/01/14 10:25, Denis Cardon wrote:
> Hi everyone,
>
> on a server running samba4 with sssd for nsswitch mapping, I realized
> recently that on windows workstation in the "folder propery/security
> tab", users are mapped as "Unix user\userlogin" instead of
> "DOMAINNAME\userlogin".
>
> I guess this is due to the fact that sssd mapping with getent passwd
> gives me user name without domain name (eg. userlogin), and in the
> samba4 smb.conf I don't know how to specify to use default domain, so
> it probably maps users to DOMAINNAME\userlogin.
>
> Looking at sssd doc, I didn't find how to add domain name in
> sssd.conf, and in smb.conf, the only related command is "winbind use
> default domain", and I'd like to use sssd instead of winbind.
>
> So I'd like to ask if there is a "use default domain" command for
> smb.conf without winbind?
>
> Cheers,
>
> Denis
>
>

Hi, I do not think that this has anything to do with sssd, the problem
seems to occur only on a windows workstation where sssd is not used. Did
you create the unix users with samba-tool?

If you did, then this could be where the problem lies, if you create a
user through ADUC and then add the Unix attributes, ADUC adds the
following attributes to the user:

msSFU30NisDomain
msSFU30Name
uidNumber
gidNumber
loginShell
unixHomeDirectory
uid

I think that it is the lack of at least the first on the list that is
giving you your problem.

If you think about it, where is 'Unix user' coming from? I think it is
something windows uses if it cannot get the 'msSFU30NisDomain' but does
find 'uidNumber'

Try adding the attributes to one of your users and see if it cures your
problem.

Rowland

[Sven Schwedas]

As an aside, are the msSFU*-attributes explained somewhere? "It works
like Windows Server" is not really helpful for people who have a pure
Linux environment. :-)

> I think that it is the lack of at least the first on the list that is
> giving you your problem.
>
> If you think about it, where is 'Unix user' coming from? I think it is
> something windows uses if it cannot get the 'msSFU30NisDomain' but does
> find 'uidNumber'
>
> Try adding the attributes to one of your users and see if it cures your
> problem.
>
> Rowland
>

--

Mit freundlichen Grüßen, / Best Regards,
Sven Schwedas
Systemadministrator
TAO Beratungs- und Management GmbH | Lendplatz 45 | A - 8020 Graz
Mail/XMPP: sven.s...@tao.at | +43 (0)680 301 7167
http://software.tao.at

[Denis Cardon]

Hi Rownland and Steve,

Indeed this is not linked to sssd per se. I have looked at another setup
(samba3 + sssd, so not exactly the same stuff) where I set the unix
attribute throught ADUC and security tab displays properly. I'll look at
the msSFU30NisDomain in deeper detail by tomorow.

Thanks for the input!

Denis




>
> Rowland

>


--
Denis Cardon
Tranquil IT Systems
Les Espaces Jules Verne, bâtiment A
12 avenue Jules Verne
44230 Saint Sébastien sur Loire
tel : +33 (0) 2.40.97.57.55
http://www.tranquil-it-systems.fr

[Rowland Penny]

Hi, if adding the msSFU30 attributes cures your problem, I think that a
bug needs to be raised. I personally think that 'samba-tool user create'
should work just like creating a user through ADUC, but this would
require a big rewrite and additions to ypServ30.ldif.

Rowland

[steve]

On Tue, 2014-01-21 at 08:50 +0100, Sven Schwedas wrote:
> On 2014-01-20 16:13, Rowland Penny wrote:

> ADUC adds the
> > following attributes to the user:
> >
> > msSFU30NisDomain
> > msSFU30Name
> > uidNumber
> > gidNumber
> > loginShell
> > unixHomeDirectory
> > uid
>
> As an aside, are the msSFU*-attributes explained somewhere? "It works
> like Windows Server" is not really helpful for people who have a pure
> Linux environment. :-)

Yes. I'd recommend that you begin with the one liners and leave the
ldifs and schema updates for later:
http://blogs.technet.com/b/sfu/archive/2011/05/25/scripts-to-populate-the-unix-attributes-when-migrating-from-sfu-3-5-to-rfc-2307-schema.aspx

Meanwhile, so that we can see what you what you actually have, can you
post the DN of one of your domain users?

HTH
Steve

[Björn JACKE]

Hi Denis,

On 2014-01-20 at 11:25 +0100 Denis Cardon sent off:

> on a server running samba4 with sssd for nsswitch mapping, I
> realized recently that on windows workstation in the "folder
> propery/security tab", users are mapped as "Unix user\userlogin"
> instead of "DOMAINNAME\userlogin".

first question I need to ask: which mode do you run samba in? Are you running
Samba in a AD server mode (samba binary) or do you run Samba in classic mode
(nmbd/smbd binary)?

If you run Samba in AD server mode, the best option is currently to use
only the really needed fileserver functionality, that means usually you should
not have other shares than the sysvol/netlogon share. Also using winbind in AD
server mode is not neccessary at all, you will have numeric UIDs on the server
but that is okay. You also should not use a Windows AD server as a file/print
server. Set up a member server to do the other file serving tasks.

If you run Samba in classic mode, then running it along with Winbind is the
only supported option for a member server.

On a member server where the source of the AD users is any different NSS source
than nss_winbind you have to configure the idmap nss backend. Theoretically
this would also be required if you would use sssd.

Because I read the sssd recommendations so often on the list recently - once
more: sssd is NOT the right thing for Samba member server setups.

Björn

[steve]

On Wed, 2014-01-22 at 22:04 +0100, Björn JACKE wrote:
> Hi Denis,
>
> On 2014-01-20 at 11:25 +0100 Denis Cardon sent off:
> > on a server running samba4 with sssd for nsswitch mapping, I
> > realized recently that on windows workstation in the "folder
> > propery/security tab", users are mapped as "Unix user\userlogin"
> > instead of "DOMAINNAME\userlogin".
>
> first question I need to ask: which mode do you run samba in? Are you running
> Samba in a AD server mode (samba binary) or do you run Samba in classic mode
> (nmbd/smbd binary)?
>
> If you run Samba in AD server mode, the best option is currently to use
> only the really needed fileserver functionality, that means usually you should
> not have other shares than the sysvol/netlogon share. Also using winbind in AD
> server mode is not neccessary at all, you will have numeric UIDs on the server
> but that is okay. You also should not use a Windows AD server as a file/print
> server. Set up a member server to do the other file serving tasks.
>
> If you run Samba in classic mode, then running it along with Winbind is the
> only supported option for a member server.

sssd, nss-ldapd and nss ldap are also supported (and recommended)
alternatives to winbind. Indeed, on the DC winbind does not work for all
of rfc2307 as offered out of the box with the former.

>
> On a member server where the source of the AD users is any different NSS source
> than nss_winbind you have to configure the idmap nss backend. Theoretically
> this would also be required if you would use sssd.

No idmap mapping has to be configured for sssd. There is a single
configuration file which most of us here have little if any difficulty
with. Indeed, there is a (albeit rather outdated) howto for sssd in the
samba wiki. Similarly for nss-ldapd.

>
> Because I read the sssd recommendations so often on the list recently - once
> more: sssd is NOT the right thing for Samba member server setups.
>

sssd is perfect for samba4 member server setups, not least for its
superb and modern AD backend designed around the Samba4 libraries.

Just my €0.02
Cheers,
Steve

[Márcio Merlone]

Em 22-01-2014 19:04, Björn JACKE escreveu:
> On 2014-01-20 at 11:25 +0100 Denis Cardon sent off:
>> on a server running samba4 with sssd for nsswitch mapping, I
>> realized recently that on windows workstation in the "folder
>> propery/security tab", users are mapped as "Unix user\userlogin"
>> instead of "DOMAINNAME\userlogin".

> (...)

> Because I read the sssd recommendations so often on the list recently - once
> more: sssd is NOT the right thing for Samba member server setups.

Scary. Why you say so? Any rationale?

--
*Marcio Merlone*
TI - Administrador de redes

*A1 Engenharia - Unidade Corporativa*
Fone: +55 41 3616-3797
Cel: +55 41 9689-0036

http://www.a1.ind.br/ <http://www.a1.ind.br>

[steve]

On Thu, 2014-01-23 at 08:14 -0200, Márcio Merlone wrote:
> Em 22-01-2014 19:04, Björn JACKE escreveu:
> > On 2014-01-20 at 11:25 +0100 Denis Cardon sent off:
> >> on a server running samba4 with sssd for nsswitch mapping, I
> >> realized recently that on windows workstation in the "folder
> >> propery/security tab", users are mapped as "Unix user\userlogin"
> >> instead of "DOMAINNAME\userlogin".
> > (...)
> > Because I read the sssd recommendations so often on the list recently - once
> > more: sssd is NOT the right thing for Samba member server setups.
>
> Scary. Why you say so? Any rationale?

+1
With sssd including a first class AD backend built around the samba4
libraries themselves, I too would would like to know why 'sssd in NOT
the right thing'. As a hands on user with very limited resources, who
has to maintain a domain with 600 adoslescents throwing everything they
can at it, I'd say it's the ONLY way to go;)

[Björn JACKE]

On 2014-01-23 at 08:14 -0200 Márcio Merlone sent off:

> Em 22-01-2014 19:04, Björn JACKE escreveu:
> >On 2014-01-20 at 11:25 +0100 Denis Cardon sent off:
> >>on a server running samba4 with sssd for nsswitch mapping, I
> >>realized recently that on windows workstation in the "folder
> >>propery/security tab", users are mapped as "Unix user\userlogin"
> >>instead of "DOMAINNAME\userlogin".
> >(...)
> >Because I read the sssd recommendations so often on the list recently - once
> >more: sssd is NOT the right thing for Samba member server setups.
>
> Scary. Why you say so? Any rationale?

winbind is interacting with smbd for id mapping and authentication. If you
configured it right, it will work nice, even if you can read rants on winbind
of one or two people in this list over and over again.

sssd supports user authentication for the pam stack nicely but this is not what
smbd needs. sssh also just provides a flat view on the users and groups from an
AD domain with no distinction between local acccounts or accounts from domain A
or domain B. sssh uses samba libraries but it does not play information back
to smbd like winbind does. As written before you would have to configure idmap
nss and run winbind in addition to sssd but you will still have the problems
with the flat view on the user and group name space. If someone on the list
writes that sssd in Samba member servers is supported, than this is a personal
opinion of that person but this is the opposite what the samba developers tell
you.

The problem that Denis descibed in the beginning of this thread are a result of
such a sssd/smbd misconfiguration. If you see any recommendation about sssd in
combination with smbd member server setups in the wiki, please let me know, so
we can correct it.

Cheers
Björn

[Rowland Penny]

On 24/01/14 15:51, Björn JACKE wrote:
> On 2014-01-23 at 08:14 -0200 Márcio Merlone sent off:
>> Em 22-01-2014 19:04, Björn JACKE escreveu:
>>> On 2014-01-20 at 11:25 +0100 Denis Cardon sent off:
>>>> on a server running samba4 with sssd for nsswitch mapping, I
>>>> realized recently that on windows workstation in the "folder
>>>> propery/security tab", users are mapped as "Unix user\userlogin"
>>>> instead of "DOMAINNAME\userlogin".
>>> (...)
>>> Because I read the sssd recommendations so often on the list recently - once
>>> more: sssd is NOT the right thing for Samba member server setups.
>> Scary. Why you say so? Any rationale?
> winbind is interacting with smbd for id mapping and authentication. If you
> configured it right, it will work nice, even if you can read rants on winbind
> of one or two people in this list over and over again.

I agree if you configure winbind right it works, problem is too many
people get it wrong, because it kept changing and is just too complex

>
> sssd supports user authentication for the pam stack nicely but this is not what
> smbd needs. sssh also just provides a flat view on the users and groups from an
> AD domain with no distinction between local acccounts or accounts from domain A
> or domain B. sssh uses samba libraries but it does not play information back
> to smbd like winbind does. As written before you would have to configure idmap
> nss and run winbind in addition to sssd but you will still have the problems
> with the flat view on the user and group name space.

Just what does winbind relay back to smbd? and to get sssd to work does
not require winbind.

> If someone on the list
> writes that sssd in Samba member servers is supported, than this is a personal
> opinion of that person but this is the opposite what the samba developers tell
> you.

Just what do you mean by member servers?

>
> The problem that Denis descibed in the beginning of this thread are a result of
> such a sssd/smbd misconfiguration. If you see any recommendation about sssd in
> combination with smbd member server setups in the wiki, please let me know, so
> we can correct it.

I personally think the problem was a lack of attributes in AD rather
anything to do with either sssd or smbd, problem is Denis hasn't
reported back yet.

Rowland

> Cheers
> Björn

[Márcio Merlone]

Em 24-01-2014 13:51, Björn JACKE escreveu:
> On 2014-01-23 at 08:14 -0200 Márcio Merlone sent off:
>> Em 22-01-2014 19:04, Björn JACKE escreveu:
>>> On 2014-01-20 at 11:25 +0100 Denis Cardon sent off:
>>>> on a server running samba4 with sssd for nsswitch mapping, I
>>>> realized recently that on windows workstation in the "folder
>>>> propery/security tab", users are mapped as "Unix user\userlogin"
>>>> instead of "DOMAINNAME\userlogin".
>>> (...)
>>> Because I read the sssd recommendations so often on the list recently - once
>>> more: sssd is NOT the right thing for Samba member server setups.
>> Scary. Why you say so? Any rationale?
> winbind is interacting with smbd for id mapping and authentication. If you
> configured it right, it will work nice, even if you can read rants on winbind
> of one or two people in this list over and over again.

Winbind does not provide extended unix attributes (homedir, shell, etc)
as sssd does. Is this kind of rant you are referring to? If not, you may
add this. :)

> sssd supports user authentication for the pam stack nicely but this is not what
> smbd needs.

I understood it was the other way around: winbind needs smbd to get the
users list so the underlaying operating system (linux for instance)
knows about them. That's what I (and suppose most users) need.

> sssh also just provides a flat view on the users and groups from an
> AD domain with no distinction between local acccounts or accounts from domain A
> or domain B.

Right, so on a single-domain setup this is no problem. Check?

> sssh uses samba libraries but it does not play information back
> to smbd like winbind does.

Sorry to abuse you, can you elaborate what kind of information winbind
gives back to smbd, or point to good documentation?

> As written before you would have to configure idmap
> nss and run winbind in addition to sssd but you will still have the problems
> with the flat view on the user and group name space. If someone on the list
> writes that sssd in Samba member servers is supported, than this is a personal
> opinion of that person but this is the opposite what the samba developers tell
> you.

Link?

> The problem that Denis descibed in the beginning of this thread are a result of
> such a sssd/smbd misconfiguration. If you see any recommendation about sssd in
> combination with smbd member server setups in the wiki, please let me know, so
> we can correct it.

The picture I have in my mind: I have a samba4 AD DC with one or more
BDC to make windows users happy. I also have a mail server, proxy,
intranet and other services running on other servers that does not need
to know about windows information, just user database and
authentication. As I understand, those are member servers, with no
specific role on Windows networking, or at most, some filesystem
sharing. Does that need winbind? Seems to me that in such case sssd is
better since it provides more extensive information.

[ ]'s

[steve]

On Fri, 2014-01-24 at 16:51 +0100, Björn JACKE wrote:
> On 2014-01-23 at 08:14 -0200 Márcio Merlone sent off:
> > Em 22-01-2014 19:04, Björn JACKE escreveu:
> > >On 2014-01-20 at 11:25 +0100 Denis Cardon sent off:
> > >>on a server running samba4 with sssd for nsswitch mapping, I
> > >>realized recently that on windows workstation in the "folder
> > >>propery/security tab", users are mapped as "Unix user\userlogin"
> > >>instead of "DOMAINNAME\userlogin".
> > >(...)
> > >Because I read the sssd recommendations so often on the list recently - once
> > >more: sssd is NOT the right thing for Samba member server setups.
> >
> > Scary. Why you say so? Any rationale?
>
> winbind is interacting with smbd for id mapping and authentication. If you
> configured it right, it will work nice, even if you can read rants on winbind
> of one or two people in this list over and over again.

Winbind and sssd do exactly the same job. Choose whichever one you feel
happy with.

>
> sssd supports user authentication for the pam stack nicely but this is not what
> smbd needs.

winbind also needs to be included in your pam configuration. smbd works
perfectly on a member server with both nss and pam controlled by sssd.

> sssh also just provides a flat view on the users and groups from an
> AD domain with no distinction between local acccounts or accounts from domain A
> or domain B. sssh uses samba libraries but it does not play information back
> to smbd like winbind does. As written before you would have to configure idmap
> nss and run winbind in addition to sssd but you will still have the problems
> with the flat view on the user and group name space.

sssd does not need winbind running. You must NOT run winbindd together
with sssd. sssd is a substitute for winbindd. Use one or the other.

> If someone on the list
> writes that sssd in Samba member servers is supported, than this is a personal
> opinion of that person but this is the opposite what the samba developers tell
> you.
>

I've no idea what the personal opinions of the Samba developers are but
many of us here support sssd with Samba and certainly the sssd
developers support it fully. Of course, we mere samba list members
support it and shall continue to do so. We also help out with winbind
configurations too, especially on member servers.

> The problem that Denis descibed in the beginning of this thread are a result of
> such a sssd/smbd misconfiguration. If you see any recommendation about sssd in
> combination with smbd member server setups in the wiki, please let me know, so
> we can correct it.
>

I believe the OP had problems because he had not included rfc2307
attributes in the DN of his users and groups.

Cheers,
Steve

> Cheers
> Björn

[Björn JACKE]

On 2014-01-26 at 12:40 +0100 steve sent off:

> Winbind and sssd do exactly the same job. Choose whichever one you feel
> happy with.

read the previous mails, sssd and winbind do not do the same job, especially
not in smbd file/print server setups.

> > sssd supports user authentication for the pam stack nicely but this is not what
> > smbd needs.
>
> winbind also needs to be included in your pam configuration. smbd works
> perfectly on a member server with both nss and pam controlled by sssd.

you are talking about completely different setups here. A smbd
file/print server does not use pam at all.

> sssd does not need winbind running. You must NOT run winbindd together
> with sssd. sssd is a substitute for winbindd. Use one or the other.

nobody said that sssd needs winbind. *smbd* needs winbind to get the idmapping
with domain users right.

[Björn JACKE]

On 2014-01-24 at 16:47 +0000 Rowland Penny sent off:

> >winbind is interacting with smbd for id mapping and authentication. If you
> >configured it right, it will work nice, even if you can read rants on winbind
> >of one or two people in this list over and over again.
> I agree if you configure winbind right it works, problem is too many
> people get it wrong, because it kept changing and is just too
> complex

it's true that the winbind parameters changed some because the initial way to
configure the idmapping was not flexible enough and also a bit confusing. I
think since Samba 3.6 the parameters have been stable and straight forward to
configure. If you read the release notes and the man pages you should have no
problem to set it up properly.

> >sssd supports user authentication for the pam stack nicely but this is not what
> >smbd needs. sssh also just provides a flat view on the users and groups from an
> >AD domain with no distinction between local acccounts or accounts from domain A
> >or domain B. sssh uses samba libraries but it does not play information back
> >to smbd like winbind does. As written before you would have to configure idmap
> >nss and run winbind in addition to sssd but you will still have the problems
> >with the flat view on the user and group name space.
>
> Just what does winbind relay back to smbd? and to get sssd to work
> does not require winbind.

smbd checks if winbind is running and winbind acts as a authentication proxy
for smbd in that case. Winbind is also able to handle local groups correctly.
Without winbind smbd just sees a flat hierarchie of unix users and
those will also not be represented to connecting clients with the
correct domain sid, unless you run winbind additionally with idmap nss,
as I've written before.

> > If someone on the list
> >writes that sssd in Samba member servers is supported, than this is a personal
> >opinion of that person but this is the opposite what the samba developers tell
> >you.
> Just what do you mean by member servers?

any file/print server running smbd.

> >The problem that Denis descibed in the beginning of this thread are a result of
> >such a sssd/smbd misconfiguration. If you see any recommendation about sssd in
> >combination with smbd member server setups in the wiki, please let me know, so
> >we can correct it.
> I personally think the problem was a lack of attributes in AD rather
> anything to do with either sssd or smbd, problem is Denis hasn't
> reported back yet.

it's most likely the lack of winbind, see above.

[Björn JACKE]

On 2014-01-24 at 15:20 -0200 Márcio Merlone sent off:

> Em 24-01-2014 13:51, Björn JACKE escreveu:
> >On 2014-01-23 at 08:14 -0200 Márcio Merlone sent off:
> >>Em 22-01-2014 19:04, Björn JACKE escreveu:
> >>>On 2014-01-20 at 11:25 +0100 Denis Cardon sent off:
> >>>>on a server running samba4 with sssd for nsswitch mapping, I
> >>>>realized recently that on windows workstation in the "folder
> >>>>propery/security tab", users are mapped as "Unix user\userlogin"
> >>>>instead of "DOMAINNAME\userlogin".
> >>>(...)
> >>>Because I read the sssd recommendations so often on the list recently - once
> >>>more: sssd is NOT the right thing for Samba member server setups.
> >>Scary. Why you say so? Any rationale?
> >winbind is interacting with smbd for id mapping and authentication. If you
> >configured it right, it will work nice, even if you can read rants on winbind
> >of one or two people in this list over and over again.
> Winbind does not provide extended unix attributes (homedir, shell,
> etc) as sssd does. Is this kind of rant you are referring to? If
> not, you may add this. :)

actually yes. Unfortunately I didn't see your previous posts on this list where
you false advised the use of sssd instead of winbind before. It's also not
true, that winbind does not provide the unix attributes like shell or homedir
to the nsswitch layer. Please read the smb.conf man page and also the wiki
carefully. You will find the parameter winbind nss info then.

> I understood it was the other way around: winbind needs smbd to get
> the users list so the underlaying operating system (linux for
> instance) knows about them. That's what I (and suppose most users)
> need.

this is another misunderstanding. winbind does not need smbd, the other way
round is more correct.

> >sssh also just provides a flat view on the users and groups from an
> >AD domain with no distinction between local acccounts or accounts from domain A
> >or domain B.
> Right, so on a single-domain setup this is no problem. Check?

you may be lucky but even with a single domain you my run into problems with
the flat view on the users and with name clashes with local users. And with
sssd and without winbind and idmap nss you won't really have domain users on
your system but a copy of the domain users locally on the server.

> > sssh uses samba libraries but it does not play information back
> >to smbd like winbind does.
> Sorry to abuse you, can you elaborate what kind of information
> winbind gives back to smbd, or point to good documentation?

see above

> >As written before you would have to configure idmap
> >nss and run winbind in addition to sssd but you will still have the problems
> >with the flat view on the user and group name space. If someone on the list
> >writes that sssd in Samba member servers is supported, than this is a personal
> >opinion of that person but this is the opposite what the samba developers tell
> >you.
> Link?

if unfortunately nobody from the team corrected the false advice of using sssd
on samba member servers, then take my mails as reference if you want to
have a referrence :-)

> >The problem that Denis descibed in the beginning of this thread are a result of
> >such a sssd/smbd misconfiguration. If you see any recommendation about sssd in
> >combination with smbd member server setups in the wiki, please let me know, so
> >we can correct it.
> The picture I have in my mind: I have a samba4 AD DC with one or
> more BDC to make windows users happy.

there is no such thing like a BDC if you run active directory

> I also have a mail server,
> proxy, intranet and other services running on other servers that
> does not need to know about windows information, just user database
> and authentication.

for pure authentication you don't need winbind but you cannnot mix up all cases
together. There are use cases where sssd actualy is a good option but
in the member server cases that we are talking about in this thread it
is not.

> As I understand, those are member servers, with
> no specific role on Windows networking, or at most, some filesystem
> sharing. Does that need winbind? Seems to me that in such case sssd
> is better since it provides more extensive information.

actually winbind provides the same information and even better. sssd is
currently better in offline authentication functionality I think.

Björn

[Rowland Penny]

On 27/01/14 13:29, Björn JACKE wrote:
> On 2014-01-24 at 16:47 +0000 Rowland Penny sent off:
>>> winbind is interacting with smbd for id mapping and authentication. If you
>>> configured it right, it will work nice, even if you can read rants on winbind
>>> of one or two people in this list over and over again.
>> I agree if you configure winbind right it works, problem is too many
>> people get it wrong, because it kept changing and is just too
>> complex
> it's true that the winbind parameters changed some because the initial way to
> configure the idmapping was not flexible enough and also a bit confusing. I
> think since Samba 3.6 the parameters have been stable and straight forward to
> configure. If you read the release notes and the man pages you should have no
> problem to set it up properly.

In which case why do so many people get it wrong?

Well you must be wrong there, It works for me and I do not use winbind
at all.

[Rowland Penny]

Just where do you get your info from???

You can run smbd without winbind even being installed, but just what are
you going to with winbind if smbd is not installed.

>
>>> sssh also just provides a flat view on the users and groups from an
>>> AD domain with no distinction between local acccounts or accounts from domain A
>>> or domain B.
>> Right, so on a single-domain setup this is no problem. Check?
> you may be lucky but even with a single domain you my run into problems with
> the flat view on the users and with name clashes with local users. And with
> sssd and without winbind and idmap nss you won't really have domain users on
> your system but a copy of the domain users locally on the server.
>

Yes you are right, you cannot have the same username locally and in AD,
but this would still be the case if you use sssd or winbind.
Could you please explain just what you mean by 'flat view' and how
pulling RFC attributes with winbind differs from pulling them with sssd?

>>> sssh uses samba libraries but it does not play information back
>>> to smbd like winbind does.
>> Sorry to abuse you, can you elaborate what kind of information
>> winbind gives back to smbd, or point to good documentation?
> see above

No, you didn't answer the question, will you please answer it.

>
>
>>> As written before you would have to configure idmap
>>> nss and run winbind in addition to sssd but you will still have the problems
>>> with the flat view on the user and group name space. If someone on the list
>>> writes that sssd in Samba member servers is supported, than this is a personal
>>> opinion of that person but this is the opposite what the samba developers tell
>>> you.
>> Link?

link???

> if unfortunately nobody from the team corrected the false advice of using sssd
> on samba member servers, then take my mails as reference if you want to
> have a referrence :-)
>

Why? you just seem to spouting 'do not use sssd' without giving good
reasons why not.

>>> The problem that Denis descibed in the beginning of this thread are a result of
>>> such a sssd/smbd misconfiguration. If you see any recommendation about sssd in
>>> combination with smbd member server setups in the wiki, please let me know, so
>>> we can correct it.
>> The picture I have in my mind: I have a samba4 AD DC with one or
>> more BDC to make windows users happy.
> there is no such thing like a BDC if you run active directory

Yes there is every DC is also a BDC.

>
>
>> I also have a mail server,
>> proxy, intranet and other services running on other servers that
>> does not need to know about windows information, just user database
>> and authentication.
> for pure authentication you don't need winbind but you cannnot mix up all cases
> together. There are use cases where sssd actualy is a good option but
> in the member server cases that we are talking about in this thread it
> is not.

Why not, please give reasons why not.

>
>> As I understand, those are member servers, with
>> no specific role on Windows networking, or at most, some filesystem
>> sharing. Does that need winbind? Seems to me that in such case sssd
>> is better since it provides more extensive information.
> actually winbind provides the same information and even better. sssd is
> currently better in offline authentication functionality I think.

This is probably the only thing that you have got right, you do not have
to touch the PAM stack to get it working.

Rowland

[Rowland Penny]

On 27/01/14 13:50, Björn JACKE wrote:
> On 2014-01-26 at 12:40 +0100 steve sent off:
>> Winbind and sssd do exactly the same job. Choose whichever one you feel
>> happy with.
> read the previous mails, sssd and winbind do not do the same job, especially
> not in smbd file/print server setups.

Could you please explain just how winbind differs from sssd as you seem
to know the differences, also could you explain your definition of a smb
file/print server???

>
>
>>> sssd supports user authentication for the pam stack nicely but this is not what
>>> smbd needs.
>> winbind also needs to be included in your pam configuration. smbd works
>> perfectly on a member server with both nss and pam controlled by sssd.
> you are talking about completely different setups here. A smbd
> file/print server does not use pam at all.

So how does smbd get its authentication then in an AD domain?

>
>> sssd does not need winbind running. You must NOT run winbindd together
>> with sssd. sssd is a substitute for winbindd. Use one or the other.
> nobody said that sssd needs winbind. *smbd* needs winbind to get the idmapping
> with domain users right.

Ah, I think I see a chink of light here, idmapping! mapping a unix group
to a windows group, so you are inferring that you must use winbind for
this to happen.

Rowland

[Rowland Penny]

On 27/01/14 14:30, Volker Lendecke wrote:

> On Mon, Jan 27, 2014 at 02:43:52PM +0100, Björn JACKE wrote:
>>>> As written before you would have to configure idmap
>>>> nss and run winbind in addition to sssd but you will still have the problems
>>>> with the flat view on the user and group name space. If someone on the list
>>>> writes that sssd in Samba member servers is supported, than this is a personal
>>>> opinion of that person but this is the opposite what the samba developers tell
>>>> you.
>>> Link?
>> if unfortunately nobody from the team corrected the false advice of using sssd
>> on samba member servers, then take my mails as reference if you want to
>> have a referrence :-)

> Just a confirmation from my side here. You might go with
> sssd for the end-user workstation case for some reason, but
> please use winbind for the file server case. winbind does
> the workstation case well also, so the main reason for sssd
> is the IPA/LDAP backend flexibility in the workstation case.
>
> With best regards,
>
> Volker Lendecke
>
I am sorry Volker, but just saying don't use sssd for a file server is
not good enough, you must give good reasons why. From my experience,
telling somebody 'do not do this', without explaining why, is a recipe
for disaster.

Just what does winbind do that sssd doesn't?

Rowland

[Volker Lendecke]

On Mon, Jan 27, 2014 at 02:43:52PM +0100, Björn JACKE wrote:

> > >As written before you would have to configure idmap
> > >nss and run winbind in addition to sssd but you will still have the problems
> > >with the flat view on the user and group name space. If someone on the list
> > >writes that sssd in Samba member servers is supported, than this is a personal
> > >opinion of that person but this is the opposite what the samba developers tell
> > >you.
> > Link?
>
> if unfortunately nobody from the team corrected the false advice of using sssd
> on samba member servers, then take my mails as reference if you want to
> have a referrence :-)

Just a confirmation from my side here. You might go with
sssd for the end-user workstation case for some reason, but
please use winbind for the file server case. winbind does
the workstation case well also, so the main reason for sssd
is the IPA/LDAP backend flexibility in the workstation case.

With best regards,

Volker Lendecke

--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kon...@sernet.de

[Volker Lendecke]

On Mon, Jan 27, 2014 at 02:26:17PM +0000, Rowland Penny wrote:
> >you are talking about completely different setups here. A smbd
> >file/print server does not use pam at all.
>
> So how does smbd get its authentication then in an AD domain?

Look at "wbinfo -a". This exactly simulates what smbd is
doing. Forward the authentication credentials to AD.
Alternatively, if kerberos is used, smbd and winbind
communicate via the netsamlogon_cache.tdb. smbd puts the
windows authorization information into that file, winbind
then retrieves it from there when nss information is being
asked for. I'm not sure sssd does that the same way.

Volker

--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kon...@sernet.de

[Michael Adam]

Hi Rowland,

Let's put it differently:

Question:
What is winbindd that sssd is not?

Answer:
Winbindd is the part of the samba software suite
that is developed with samba, and has the responsibilty
of doing authentication (e.g. against AD) and id-mapping
for smbd. As such it is the component recommended by the
samba developers to use (e.g.) in adomain-member-setup
along with smbd.

sssd, on the other hand, is not developed by the samba team.
It is a 3rd party software that can take on similar roles
as winbindd in some scenarios. As such it is of course not
recommended by the samba developers, even though you might
get it to work.

Does this make it more clear?
This is actually the main point the samba developers are
trying to make.

Getting more technical again now:

Winbindd does the authentication against AD and retreival of the
user and group infos from a AD domain the windows way, and
tries to map the infos as closely and windows-like as possible,
in particular with information about nested groups, etc.

sssd on the other hand side, I don't know well enough. But
as far as I am aware, sssd coming from the FreeIPA/LDAP world
uses ldap and direct kerberos auth where possible intead of
windows native methods which leads to certain tradeoffs. Some
info is simply not accessible that way, or presented incorrectly.

Cheers - Michael

[Volker Lendecke]

On Mon, Jan 27, 2014 at 02:37:04PM +0000, Rowland Penny wrote:
> I am sorry Volker, but just saying don't use sssd for a file server
> is not good enough, you must give good reasons why. From my
> experience, telling somebody 'do not do this', without explaining
> why, is a recipe for disaster.
>
> Just what does winbind do that sssd doesn't?

While I can not fully speak for sssd, I know that winbind
does many things which are entirely not obvious to a AD
client. For example DC lookup is pretty complex, winbind is
site aware and prefers local DCs. winbind is pretty up to
date with the latest Microsoft RPC security negotiation
things and is being updated as they come in. winbind is very
flexible with idmapping and goes a long way to properly
cache idmappings with smbd via gencache for good
performance. winbind is at this moment being improved
significantly to much better deal with machine password
changes and potentially slow AD replication of those
changes.

None of this is rocket science and sssd can implement all of
this itself for sure. In particular as one of the initial
authors of sssd is Simo Sorce, Samba Team Member, it is
entirely possible that Simo translates all winbind
achievements into sssd features. Maybe the current sssd
authors can better comment on the few points I made above.
It is just a lot of work that the Samba Team members put
into the RPC client infrastructure that winbind uses, and I
would be very surprised if sssd uses that 1:1.

I just want to say that AD membership can be pretty complex,
and winbind is rather up to date with all the subtleties.

With best regards,

Volker Lendecke

--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kon...@sernet.de

[Rowland Penny]

Thanks Volker (and Michael) this makes it a bit clearer, I understand
that it probably is better to use winbind instead of sssd, it is just
that winbind is such a pain to set up correctly. Don't get me wrong,but
don't all the posts about setting winbind up tell you anything, you
might think it is easy, but anything is easy when you know how.

I personally think that what is required is the winbind backend with the
sssd front end stuck on it ;-)

I thought that sssd were working on making their ad backend work like
winbind, so I think that I will go and ask them what they think.

Rowland

[Márcio Merlone]

Em 27-01-2014 11:43, Björn JACKE escreveu:
>> Winbind does not provide extended unix attributes (homedir, shell,
>> etc) as sssd does. Is this kind of rant you are referring to? If not,
>> you may add this. :)
> actually yes. Unfortunately I didn't see your previous posts on this list where
> you false advised the use of sssd instead of winbind before.

Me? Noooo. I am not in position to advice anything other than "replace
your windows server for a samba server". I am looking for advice, not
the other way around.

> It's also not
> true, that winbind does not provide the unix attributes like shell or homedir
> to the nsswitch layer. Please read the smb.conf man page and also the wiki
> carefully. You will find the parameter winbind nss info then.

Ok. So I read:
http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/winbind.html
and
http://www.samba.org/samba/docs/man/manpages/smb.conf.5.html

In short: winbind does not provide unix attributes like shell or homedir
to the nsswitch layer *as defined on their AD database attributes*. It
provides those as defined on a template, which may not satisfy all
admins - users don't care about it :)

I believe that the confusion on this thread and advantage of sssd over
winbind are the lack of "template homedir" and "template shell" parameters.
I'll explain: if you provision your AD DC with rfc2307 attributes for
some users, they are ignored by winbind - except uid and gid - and
templates used instead. So, if I have '/home/users/%n' as homedir for
all users, but only one must have '/home/ftp/ftpuser', winbind will see
it as '/home/user/ftpuser' and not what's defined on AD database.

I understand that AD is a Windows-centric service, not meant to manage
users on a POSIX environment, but since it does, it should do it wright.

>> As I understand, those are member servers, with
>> no specific role on Windows networking, or at most, some filesystem
>> sharing. Does that need winbind? Seems to me that in such case sssd
>> is better since it provides more extensive information.
> actually winbind provides the same information and even better. sssd is
> currently better in offline authentication functionality I think.

"Better" is way too subjective and personal. It is worse for me given
the above.

--
*Marcio Merlone*
TI - Administrador de redes

*A1 Engenharia - Unidade Corporativa*
Fone: +55 41 3616-3797
Cel: +55 41 9689-0036

http://www.a1.ind.br/ <http://www.a1.ind.br>

[Volker Lendecke]

Have you tried playing with the "winbind nss info"
parameter?

Volker

--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kon...@sernet.de

[Rowland Penny]

On 27/01/14 15:31, Márcio Merlone wrote:
> Em 27-01-2014 11:43, Björn JACKE escreveu:
>>> Winbind does not provide extended unix attributes (homedir, shell,
>>> etc) as sssd does. Is this kind of rant you are referring to? If
>>> not, you may add this. :)
>> actually yes. Unfortunately I didn't see your previous posts on this
>> list where
>> you false advised the use of sssd instead of winbind before.
> Me? Noooo. I am not in position to advice anything other than "replace
> your windows server for a samba server". I am looking for advice, not
> the other way around.
>
>> It's also not
>> true, that winbind does not provide the unix attributes like shell or
>> homedir
>> to the nsswitch layer. Please read the smb.conf man page and also the
>> wiki
>> carefully. You will find the parameter winbind nss info then.
> Ok. So I read:
> http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/winbind.html
> and
> http://www.samba.org/samba/docs/man/manpages/smb.conf.5.html

Please don't bother with the first page you quoted, it is mostly out of
date and relates to version 3.5, the second page is also slightly out of
date (for instance, at one point it mentions SWAT, this has now been
removed).

>
> In short: winbind does not provide unix attributes like shell or
> homedir to the nsswitch layer *as defined on their AD database
> attributes*. It provides those as defined on a template, which may not
> satisfy all admins - users don't care about it :)

I believe that here you are referring to winbind on the samba 4 AD
server, this is built into the samba daemon and does not work like the
separate winbind daemon. The main problem is the one that you have
mentioned but it is actually worse than you think, you cannot use place
holders in the templates i.e. if you try to use /home/%u in the
homedirectory template, all your users will get the literal home
directory of /home/%u.

>
> I believe that the confusion on this thread and advantage of sssd over
> winbind are the lack of "template homedir" and "template shell"
> parameters.
> I'll explain: if you provision your AD DC with rfc2307 attributes for
> some users, they are ignored by winbind - except uid and gid - and
> templates used instead. So, if I have '/home/users/%n' as homedir for
> all users, but only one must have '/home/ftp/ftpuser', winbind will
> see it as '/home/user/ftpuser' and not what's defined on AD database.
>
> I understand that AD is a Windows-centric service, not meant to manage
> users on a POSIX environment, but since it does, it should do it wright.
>
>

Yes AD is windows-centric, well it would be, after all it came from
windows ;-)
But, windows came up with SFU (this seems to have been re-named several
times) and I personally think that is the way to go, put all the linux
info into the RFC2307 attributes and use something to pull these. The
easiest way (note I do not say the best way) at the moment seems to be
to use sssd.

Rowland

>>> As I understand, those are member servers, with
>>> no specific role on Windows networking, or at most, some filesystem
>>> sharing. Does that need winbind? Seems to me that in such case sssd
>>> is better since it provides more extensive information.
>> actually winbind provides the same information and even better. sssd is
>> currently better in offline authentication functionality I think.
> "Better" is way too subjective and personal. It is worse for me given
> the above.
>
>

--

[Volker Lendecke]

On Mon, Jan 27, 2014 at 04:13:24PM +0000, Rowland Penny wrote:
> Yes AD is windows-centric, well it would be, after all it came from
> windows ;-)
> But, windows came up with SFU (this seems to have been re-named
> several times) and I personally think that is the way to go, put all
> the linux info into the RFC2307 attributes and use something to pull
> these. The easiest way (note I do not say the best way) at the
> moment seems to be to use sssd.

If all you want is make use of RFC2307, I'd recommend plain
nss_ldap. Around for ages.

Volker

--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kon...@sernet.de

[Jeremy Allison]

On Mon, Jan 27, 2014 at 04:14:17PM +0100, Michael Adam wrote:
> Question:
> What is winbindd that sssd is not?
>
> Answer:
> Winbindd is the part of the samba software suite
> that is developed with samba, and has the responsibilty
> of doing authentication (e.g. against AD) and id-mapping
> for smbd. As such it is the component recommended by the
> samba developers to use (e.g.) in adomain-member-setup
> along with smbd.
>
> sssd, on the other hand, is not developed by the samba team.
> It is a 3rd party software that can take on similar roles
> as winbindd in some scenarios. As such it is of course not
> recommended by the samba developers, even though you might
> get it to work.

I think "not recommended" might be a bit strong. "Not
tested with in our default builds.." would be a better
statement :-).

I think the sssd developers test with Samba (at least
I hope so :-).

Jeremy.

[Jeremy Allison]

On Mon, Jan 27, 2014 at 02:16:55PM +0000, Rowland Penny wrote:
>
> You can run smbd without winbind even being installed, but just what
> are you going to with winbind if smbd is not installed.

Provide single-sign-on with offline capability to a Linux
workstation in a Microsoft-AD environment ?

I say this because I got sent to Paris (*) a long time ago
to fix a winbind bug at a customer who was doing precisely
that :-). I think Guenther later got sent to the same customer
to fix a follow-on issue :-).

Of course this was before sssd had been created, and
I don't know the sssd code at all (although I greatly
respect Simo and the Red Hat Team that created it)
but winbind is perfectly capable in this scenario.

Cheers,

Jeremy.

(*) It was at such short notice and over a weekend
that I made them pay for a business class flight,
so it all worked out in the end :-).

[Rowland Penny]

On 27/01/14 16:53, Jeremy Allison wrote:
> On Mon, Jan 27, 2014 at 02:16:55PM +0000, Rowland Penny wrote:
>> You can run smbd without winbind even being installed, but just what
>> are you going to with winbind if smbd is not installed.
> Provide single-sign-on with offline capability to a Linux
> workstation in a Microsoft-AD environment ?
>
> I say this because I got sent to Paris (*) a long time ago
> to fix a winbind bug at a customer who was doing precisely
> that :-). I think Guenther later got sent to the same customer
> to fix a follow-on issue :-).
>
> Of course this was before sssd had been created, and
> I don't know the sssd code at all (although I greatly
> respect Simo and the Red Hat Team that created it)
> but winbind is perfectly capable in this scenario.
>

After asking the question on the sssd mailing list, Simo reckons that he
will have most of the code in place to replace winbind with sssd, as he
put it, by the end of spring (this year, northern hemisphere)

Rowland

[Jeremy Allison]

On Mon, Jan 27, 2014 at 05:04:00PM +0000, Rowland Penny wrote:
> >
> After asking the question on the sssd mailing list, Simo reckons
> that he will have most of the code in place to replace winbind with
> sssd, as he put it, by the end of spring (this year, northern
> hemisphere)

Well I'd never bet against Simo :-). But having 2 functional
mapping daemons to chose from won't hurt !

Cheers,

Jeremy.

[steve]

On Mon, 2014-01-27 at 15:39 +0100, Volker Lendecke wrote:
> On Mon, Jan 27, 2014 at 02:26:17PM +0000, Rowland Penny wrote:
> > >you are talking about completely different setups here. A smbd
> > >file/print server does not use pam at all.
> >
> > So how does smbd get its authentication then in an AD domain?
>
> Look at "wbinfo -a". This exactly simulates what smbd is
> doing. Forward the authentication credentials to AD.
> Alternatively, if kerberos is used, smbd and winbind
> communicate via the netsamlogon_cache.tdb. smbd puts the
> windows authorization information into that file, winbind
> then retrieves it from there when nss information is being
> asked for. I'm not sure sssd does that the same way.
>
> Volker
>

Well, thanks. But no thanks. That's not enough to convince us to even
think about winbind as a substitute for sssd on our 600 user 80 machine
domain, especially since winbind on the DC simply does not work.
Thanks again. Please could you give real hands on reasons that those of
us who are not developers would understand?

What you are saying is very worrying for us. In 8 months of production
with Samba4 and sssd throughout the domain we have never had the
slightest problem with the latter. Are we ever likely to see what you
are mentioning as an error which would bring us to a standstill or slow
us down? That sssd does not do something in the same way? If not, could
you please tell us how we could force the error? We would then consider
switching to winbind.

Cheers and thanks for your help.
Steve

[Volker Lendecke]

This very much depends on your environment and user/group
structure. If your environment is such that sssd can do what
you want, feel free to use it.

Volker

--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kon...@sernet.de

[Rowland Penny]

Thank you very much for giving me your permission to use sssd, I didn't
actually know I needed it, or is this your way of saying 'for most
people sssd will do what is required, without the complexity of winbind'

Rowland

[Jeremy Allison]

On Mon, Jan 27, 2014 at 08:24:05PM +0000, Rowland Penny wrote:
> Thank you very much for giving me your permission to use sssd, I
> didn't actually know I needed it, or is this your way of saying 'for
> most people sssd will do what is required, without the complexity of
> winbind'

Rowland, a word of advice. Attitudes like that don't
help on the lists, really they don't. If you don't
like winbind and prefer sssd, then fine, I'm glad
that works for you.

But turning up on the Samba lists and repeatedly
complaining about a component you're not using
isn't positive for anyone.

Imagine if someone turned up on the sssd lists
and started complaining and suggesting winbind
as a solution. That would be just as inappropriate
(I'm assuming no one *is* actually doing that
of course :-).

You're being "that" guy. Don't be "that" guy :-).

Jeremy.

[Rowland Penny]

On 27/01/14 20:36, Jeremy Allison wrote:
> On Mon, Jan 27, 2014 at 08:24:05PM +0000, Rowland Penny wrote:
>> Thank you very much for giving me your permission to use sssd, I
>> didn't actually know I needed it, or is this your way of saying 'for
>> most people sssd will do what is required, without the complexity of
>> winbind'
> Rowland, a word of advice. Attitudes like that don't
> help on the lists, really they don't. If you don't
> like winbind and prefer sssd, then fine, I'm glad
> that works for you.
>
> But turning up on the Samba lists and repeatedly
> complaining about a component you're not using
> isn't positive for anyone.
>
> Imagine if someone turned up on the sssd lists
> and started complaining and suggesting winbind
> as a solution. That would be just as inappropriate
> (I'm assuming no one *is* actually doing that
> of course :-).
>
> You're being "that" guy. Don't be "that" guy :-).
>
> Jeremy.

Look Jeremy, I definitely don't want to be 'that guy' but when someone
comes on here and virtual tries to order people not to use sssd because
it will not work and does not give a good reason why not, then he is
being 'that guy'.

Then someone else posted 'If your environment is such that sssd can do
what you want, feel free to use it.' I am sorry to say, I just saw red.
Let me be blunt, because I am a blunt northerner, I just read that as
condescending and I will not be talked down too and if anybody doesn't
like that, then tough.

I have nothing against winbind, I just think that it is hard to set up
and sssd is easier to use, but that is my opinion and anybody can take
it or leave it.

I am just a user, I cannot write code and have great respect for those
that do, but I personally will not be told that I cannot have my own
opinion.

Rowland

[Michael Adam]

On 2014-01-27 at 08:55 -0800, Jeremy Allison wrote:
> On Mon, Jan 27, 2014 at 04:14:17PM +0100, Michael Adam wrote:
> > Question:
> > What is winbindd that sssd is not?
> >
> > Answer:
> > Winbindd is the part of the samba software suite
> > that is developed with samba, and has the responsibilty
> > of doing authentication (e.g. against AD) and id-mapping
> > for smbd. As such it is the component recommended by the
> > samba developers to use (e.g.) in adomain-member-setup
> > along with smbd.
> >
> > sssd, on the other hand, is not developed by the samba team.
> > It is a 3rd party software that can take on similar roles
> > as winbindd in some scenarios. As such it is of course not
> > recommended by the samba developers, even though you might
> > get it to work.
>
> I think "not recommended" might be a bit strong. "Not
> tested with in our default builds.." would be a better
> statement :-).

No. I don't see why samba should recommend to use sssd
instead of winbindd. Why would the samba team develop
a major piece of software but recommend to use a third
party piece of software instead? That would make no sense
at all to me. I am also not aware of any official samba document
recommending to use sssd instead of winbindd. So this is
my very definition of "samba does not to use sssd". :-)

(Of course those sssd developers who happen to be samba
developers as well might recommend sssd, but probably
not with their "samba hat" on..)

Cheers - Michael

[Michael Adam]

On 2014-01-27 at 15:33 +0000, Rowland Penny wrote:
>
> Thanks Volker (and Michael) this makes it a bit clearer, I
> understand that it probably is better to use winbind instead of
> sssd, it is just that winbind is such a pain to set up correctly.
> Don't get me wrong,but don't all the posts about setting winbind up
> tell you anything, you might think it is easy, but anything is easy
> when you know how.

The manual pages smb.conf, idmap_tdb, idmap_rid, idmap_autorid,
idmap_ad ... contain all information that is needed.

It should not be exaggeratedly hard to set it up correctly
if you follow those docs (in a version matching your code).

I admit that there are things that could be improved,
for instance the condifigurability of "nss info", but
that can be done.

Cheers - Michael

[Michael Adam]

Hey Rowland,

Sorry, but no:

It is rather that the samba developers start to get sick
of some of "those guys" coming back over and over again,
bashing winbindd and spreading on the mailing list that
sssd is the preferred solution.

And nobody is "ordering" anybody to use winbindd, but please
remember that this is a samba support list and winbindd is the
samba core component that is designed and indended to be used by
default on a domain member server, so the recommendation
to use winbindd and not sssd should not come as a surprise...

You have also been given quite a few technical reasons
why winbind is the way to go (for some of us here ;-).

> Then someone else posted 'If your environment is such that sssd can
> do what you want, feel free to use it.' I am sorry to say, I just
> saw red.

Of course this was a sarcastic reply by someone who already
saw red... ;-)

Cheers - Michael

[Jeremy Allison]

On Mon, Jan 27, 2014 at 08:58:33PM +0000, Rowland Penny wrote:

> Look Jeremy, I definitely don't want to be 'that guy' but when

Then let's stop it here please !

[steve]

On Mon, 2014-01-27 at 17:18 +0100, Volker Lendecke wrote:
> On Mon, Jan 27, 2014 at 04:13:24PM +0000, Rowland Penny wrote:
> > Yes AD is windows-centric, well it would be, after all it came from
> > windows ;-)
> > But, windows came up with SFU (this seems to have been re-named
> > several times) and I personally think that is the way to go, put all
> > the linux info into the RFC2307 attributes and use something to pull
> > these. The easiest way (note I do not say the best way) at the
> > moment seems to be to use sssd.
>
> If all you want is make use of RFC2307, I'd recommend plain
> nss_ldap. Around for ages.
>

Hi
A poor recommendation. That's not we want at all. We don't live in the
dark ages. We want AD compatibility. And we want it fast, furious,
reliable and easy to configure. All at the same time. That's why we
don't use, dare I say it. . .

Thanks.
Steve

[steve]

On behalf of many satisfied domain users over here in third world Spain,
may I also extend my gratitude in having permission to use sssd. I too
did not know that I needed it.
Steve

[steve]

On Mon, 2014-01-27 at 20:50 +0100, Volker Lendecke wrote:
> On Mon, Jan 27, 2014 at 06:56:51PM +0100, steve wrote:
> >
> > What you are saying is very worrying for us. In 8 months of production
> > with Samba4 and sssd throughout the domain we have never had the
> > slightest problem with the latter. Are we ever likely to see what you
> > are mentioning as an error which would bring us to a standstill or slow
> > us down? That sssd does not do something in the same way? If not, could
> > you please tell us how we could force the error? We would then consider
> > switching to winbind.
>
> This very much depends on your environment and user/group
> structure.
>

600 users, 2 DC's, 1 poor old overworked slow Linux file server with 60
Linux clients and 20 windows client all in one domain. There are around
30 groups. We've been in production for 8 months without any major
outage.

We need to remain so. How would we check the error under these
conditions?

Cheers,
Steve

[Paul R. Ganci]

On 01/27/2014 09:13 AM, Rowland Penny wrote:
>
> I believe that here you are referring to winbind on the samba 4 AD
> server, this is built into the samba daemon and does not work like the
> separate winbind daemon. The main problem is the one that you have
> mentioned but it is actually worse than you think, you cannot use
> place holders in the templates i.e. if you try to use /home/%u in the
> homedirectory template, all your users will get the literal home
> directory of /home/%u.

This statement is not strictly true. On the AD server you can use
%WORKGROUP% and %ACCOUNTNAME%. Hence /home/%ACCOUNTNAME% will work in a
homedirectory template. I have my own AD server setup using this
smb.conf directive:

template homedir = /home/%ACCOUNTNAME%

which works just fine.

--
Paul (ga...@nurdog.com)

[steve]

On Mon, 2014-01-27 at 09:10 -0800, Jeremy Allison wrote:
> On Mon, Jan 27, 2014 at 05:04:00PM +0000, Rowland Penny wrote:
> > >
> > After asking the question on the sssd mailing list, Simo reckons
> > that he will have most of the code in place to replace winbind with
> > sssd, as he put it, by the end of spring (this year, northern
> > hemisphere)
>
> Well I'd never bet against Simo :-). But having 2 functional
> mapping daemons to chose from won't hurt !
>
> Cheers,
>
> Jeremy.

Thank you. Choice. Very, very much in the spirit of open source.
Steve

[steve]

On Mon, 2014-01-27 at 21:53 +0100, Michael Adam wrote:
> On 2014-01-27 at 08:55 -0800, Jeremy Allison wrote:
> > On Mon, Jan 27, 2014 at 04:14:17PM +0100, Michael Adam wrote:
> > > Question:
> > > What is winbindd that sssd is not?
> > >
> > > Answer:
> > > Winbindd is the part of the samba software suite
> > > that is developed with samba, and has the responsibilty
> > > of doing authentication (e.g. against AD) and id-mapping
> > > for smbd. As such it is the component recommended by the
> > > samba developers to use (e.g.) in adomain-member-setup
> > > along with smbd.
> > >
> > > sssd, on the other hand, is not developed by the samba team.
> > > It is a 3rd party software that can take on similar roles
> > > as winbindd in some scenarios. As such it is of course not
> > > recommended by the samba developers, even though you might
> > > get it to work.
> >
> > I think "not recommended" might be a bit strong. "Not
> > tested with in our default builds.." would be a better
> > statement :-).
>
> No. I don't see why samba should recommend to use sssd
> instead of winbindd.

I have 2 DC's. winbindd doesn't work. I need something that does.
Steve

[L.P.H. van Belle]

I would like to use winbind, but..

when i look here.
http://wiki.samba.org/index.php/Samba4/Winbind
there are so little real life examples.

I adviced before we need a configuration matrix with some real life examples.
This wil give advantages for everybody, developer, installer, maintainer..
Why, we then have a more the same setup.
Easier to bugfix for the users/developpers.
Easier to install and/upgrade.

I'm pro use-ing only the distro packages because of all of the upgrade and security fixed advantages.
It's not allowed in my company to have compiling software on production servers.
Yes, i know here we are a bit off, but i dont care about that, thats what you preffer yourself..
also, im also in to leaving the samba DC, only as DC ( and dns slave in my case )
and on every DC you dont need winbind, which fixes lots of "winbind" ( and/or sssd problems )
just install a domain member and put "winbind/sssd" ,whatever, on it, what you need.

so comming back on the winbind thingy, when i look on the wiki i m really missing
some options what in which case we put in smb.conf, and yes maybe it doesnt belong there because we have manuals.
But not every body knows everything and/or know what it means, so thats why im pro real life examples.

i only see 1 thing on the wiki, about what to put in the smb.conf

template shell = /bin/bash

really, .. thats it, everybody know how hard it is to setup something for the first time.
why do we lots of miscofigurations, yes, because nobody really reads the manual, AND understands it.

Just a suggestion, how about, the people here, post there config and setup ( and anonymized it.. )
Just a thought..
like..

Im having a mixed domain.
windows DNS/DHCP AD DC master. server 2008R2 in 2003 AD mode.
2 Samba4 DC servers with bind as backend, running debian wheezy.
Im using sernet 4.1.3 and debian samba packages recompiled 4.1.3 from sid.

No user logins in on the samba DC and because of that i dont need winbind nss_ldap/nss-switch of sssd settings.
I only use the netlogon/sysvol shares on these servers. only 1 linux account logins on on these servers.

I have setup my DC like this, its just the install after the join i only added the printing part,
This is because i didnt like the CUPS errors messages in my logs.

My samba DC config, very clean.
[global]
workgroup = ROTTERDAM
realm = rotterdam.bazuin.nl
netbios name = WS005-S4DC-001
server role = active directory domain controller
server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbind, ntp_signd, kcc, dnsupdate

#---- disable printing completely
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes


So lets put a lots of examples here and put a bit of explation with it.
from there we can put nice configs together and put it on the wiki as a base setup from where you can start.

Greetz, and... ow , and lets be nice to one another, the world already as bad as it is.
I like the samba crew, so lets all be nice to them, the deserve it and lets respect them.


Louis

[Björn JACKE]

Hi Louis,

On 2014-01-28 at 09:46 +0100 L.P.H. van Belle sent off:

> when i look here.
> http://wiki.samba.org/index.php/Samba4/Winbind
> there are so little real life examples.

for a Domain Controller there is a generic rule of thumb: a DC is a DC is a
DC. Same rule of thumb for Windows and for Samba servers here by the way :-)

Seriously: On a Samba 4 DC you can use winbind but winbind is not needed at
all. If you follow the rule of thumb that you have no other services except for
the DC functionality on that machine, then you can just leave the UIDs from
Samba unresolved and not plug winbind into nss or pam. You will see the UIDs
only on the sysvol/netlogon share in the filesystem anyway.

All other functionality like file/print/whatever you should put on a different
(non DC) machine and there you will have the winbind(3) configuration where you
will also find a lot of examples for.

Cheers
Björn

[Márcio Merlone]

Em 27-01-2014 13:53, Volker Lendecke escreveu:
> On Mon, Jan 27, 2014 at 01:31:05PM -0200, Márcio Merlone wrote:
>> I'll explain: if you provision your AD DC with rfc2307 attributes
>> for some users, they are ignored by winbind - except uid and gid -
>> and templates used instead. So, if I have '/home/users/%n' as
>> homedir for all users, but only one must have '/home/ftp/ftpuser',
>> winbind will see it as '/home/user/ftpuser' and not what's defined
>> on AD database.
> Have you tried playing with the "winbind nss info"
> parameter?

So I did it, no luck. Samba 4.1.4, sernet packages. winbind nss info =
sfu made no diff:

root@trusty:/home/dados# getent passwd marcio.merlone
A1\marcio.merlone:*:1014:20313:Márcio Vogel Merlone dos
Santos:/home/A1/marcio.merlone:/bin/false
root@trusty:/home/dados#

Shell and homedir should read:
A1\marcio.merlone:*:1014:20313:Márcio Vogel Merlone dos
Santos:/home/usuarios/marcio.merlone:/bin/bash

I'm probably missing something on smb.conf:

[global]
workgroup = A1
realm = ad.a1.ind.br
netbios name = TRUSTY

server role = active directory domain controller

server services = rpc, nbt, wrepl, ldap, cldap, kdc, drepl,
winbind, ntp_signd, kcc, dnsupdate, smb
dcerpc endpoint servers = epmapper, wkssvc, rpcecho, samr,
netlogon, lsarpc, spoolss, drsuapi, dssetup, unixinfo, browser,
eventlog6, backupkey, dnsserver, winreg, srvsvc
idmap_ldb:use rfc2307 = yes
winbind nss info = sfu
winbind enum users = yes
winbind enum groups = yes
winbind offline logon = true
idmap config * : backend = ad
idmap config * : range = 1000-999999

[netlogon]
path = /var/lib/samba/sysvol/ad.a1.ind.br/scripts
read only = No

[sysvol]
path = /var/lib/samba/sysvol
read only = No

Regards,

--
*Marcio Merlone*
TI - Administrador de redes

*A1 Engenharia - Unidade Corporativa*
Fone: +55 41 3616-3797
Cel: +55 41 9689-0036

http://www.a1.ind.br/ <http://www.a1.ind.br>

[Björn JACKE]

On 2014-01-29 at 14:53 -0200 Márcio Merlone sent off:

> So I did it, no luck. Samba 4.1.4, sernet packages. winbind nss info
> = sfu made no diff:
>
> root@trusty:/home/dados# getent passwd marcio.merlone
> A1\marcio.merlone:*:1014:20313:Márcio Vogel Merlone dos
> Santos:/home/A1/marcio.merlone:/bin/false
> root@trusty:/home/dados#
>
> Shell and homedir should read:
> A1\marcio.merlone:*:1014:20313:Márcio Vogel Merlone dos
> Santos:/home/usuarios/marcio.merlone:/bin/bash
>
> I'm probably missing something on smb.conf:

something more generic ...

> server role = active directory domain controller

remember the golden rule of thumb: a dc is a dc is a dc. no winbind needed and
no user logins here. In one of the next samba versions it is planned to merge
the winbind 3 and the winbind 4, then you will be able to use all the features
of the winbind 3. you can set "idmap_ldb:use rfc2307 = yes" on the samba 4 DC
though. And before you shout out loud, yes, this is undocumented, see bug 9840.
Documentation patches are welcome :-)

But please follow the golden dc rule. the winbind nss info parameter will work
nice if you use it like we suggested, on a member server with the "classic"
winbind.

Björn

--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen

☎ +49-551-370000-0, ℻ +49-551-370000-9

AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen

[Márcio Merlone]

Em 29-01-2014 18:41, Björn JACKE escreveu:
> On 2014-01-29 at 14:53 -0200 Márcio Merlone sent off:

>> I'm probably missing something on smb.conf:
> something more generic ...
>
>> server role = active directory domain controller

> But please follow the golden dc rule. the winbind nss info parameter will work
> nice if you use it like we suggested, on a member server with the "classic"
> winbind.

Oops. Sorry, overlooked this. That is meant to be a member server,
somehow this ended up on smb.conf. A saci (1) may have done that :)

(1) http://en.wikipedia.org/wiki/Saci_(Brazilian_folklore)

--
*Marcio Merlone*
TI - Administrador de redes

*A1 Engenharia - Unidade Corporativa*
Fone: +55 41 3616-3797
Cel: +55 41 9689-0036

http://www.a1.ind.br/ <http://www.a1.ind.br>

[Márcio Merlone]

Em 29-01-2014 18:41, Björn JACKE escreveu:

> On 2014-01-29 at 14:53 -0200 Márcio Merlone sent off:

>> server role = active directory domain controller
> remember the golden rule of thumb: a dc is a dc is a dc. no winbind needed and
> no user logins here.

I'm confused. You probably mean "no shell login for AD users here",
right? What if I want to use my AD user to ssh into de DC? Shall I
create a /etc/passwd user for that? Is there any tech limit or is this
just a best practice?

If I can bring my AD users to the unix floor by whatever mean, I'd like
to select which ones are allowed by defining their shell as /bin/bash,
opposed to mortals, which get /bin/false. That implies on "winbind nss
info = sfu" (if goind the winbind way) so I can define its login shell
on AD and have this available to nss. That did not work on DC (disregard
my last post citing a member server).

I'm still figuring out the paradigms I'll have to break. On my
samba3+OpenLDAP env, I have a unix user database (OpenLDAP) that is
"converted" as a windows database by samba. On samba4 I have the other
way around, a windows user database (AD) that is read by a unix env. The
former is very mature and complete for the unix env, while the latter,
well, I'll have to get used to. :)

I think the question can be simplified to: on _the_ DC, what is the best
approach to bring my AD users down to the shell and home defined on
their SFU attributes?
A side question: if the DC is also the main file server for my windows
network doesn't that also requires winbind - opposed to "no winbind needed"?

Thanks for your time, best regards.

--
*Marcio Merlone*
TI - Administrador de redes

*A1 Engenharia - Unidade Corporativa*
Fone: +55 41 3616-3797
Cel: +55 41 9689-0036

http://www.a1.ind.br/ <http://www.a1.ind.br>

[Björn JACKE]

Hi Márcio,
On 2014-01-30 at 10:51 -0200 Márcio Merlone sent off:

> I'm confused. You probably mean "no shell login for AD users here",
> right? What if I want to use my AD user to ssh into de DC? Shall I
> create a /etc/passwd user for that? Is there any tech limit or is
> this just a best practice?

if you follow the dc is a dc is a dc rule then your users don't log in via ssh,
so simple :-). only your DC admins log on via local accoungts then.
This is the best practice actually. If you want to enable shell logins do that
on a different machine. Of course you can also ignore the best practice rule
and enable winbind4. But you know about the limits.

> If I can bring my AD users to the unix floor by whatever mean, I'd
> like to select which ones are allowed by defining their shell as
> /bin/bash, opposed to mortals, which get /bin/false. That implies on
> "winbind nss info = sfu" (if goind the winbind way) so I can define
> its login shell on AD and have this available to nss. That did not
> work on DC (disregard my last post citing a member server).

have a look at the available options for that parameter in the smb.conf man
page. Remember this is for the "classic" winbind which is not yet merged with
the "AD winbind".

> I'm still figuring out the paradigms I'll have to break. On my
> samba3+OpenLDAP env, I have a unix user database (OpenLDAP) that is
> "converted" as a windows database by samba. On samba4 I have the
> other way around, a windows user database (AD) that is read by a
> unix env. The former is very mature and complete for the unix env,
> while the latter, well, I'll have to get used to. :)

:-)

> I think the question can be simplified to: on _the_ DC, what is the
> best approach to bring my AD users down to the shell and home
> defined on their SFU attributes?

see above

> A side question: if the DC is also the main file server for my
> windows network doesn't that also requires winbind - opposed to "no
> winbind needed"?

it is still not *required*. But it's much nicer for you to see which files
belong to which users on the shell. But again: you ignore all the advices if
you do this, so don't complain too much about the the problems you have with a
DC plus fileserver on one machine setup.

Cheers

Björn
--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
☎ +49-551-370000-0, ℻ +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen