samba - Aug 2020 - Using SSSD + AD with Samba seems to require Winbind be running

Hi all,

Configuration information right off the bat:
      Debian Buster 10.5 and Samba 2:4.9.5+dfsg-5+deb10u1.

Testparm is at the bottom


I'm running into some interesting behavior on a server I've configured
to
use SSSD to bind to the AD domain. I've successfully bound using "net
ads"
and can get tickets and so on, and have samba configured to use kerberos
through sssd. nsswitch has been configured to use sssd and not winbind as
well.
The tricky thing is, though local users work fine winbind has to be running
in order for AD authentication to work, even though I believe I have
configured samba to not use winbind at all. If winbind is not running, a
"NT_STATUS_NO_LOGON_SERVER" error is generated when it fails to
connect to
winbind's local socket. This is only resolved by starting winbind, in which
case auth moves along without issue. I was under the impression that my
current configuration obviates the need for winbind, but I could very well
be wrong.

For any AD usage, is it required for winbind to be running even if the
configuration doesn't use it? If not, what in my confguration needs to be
changed so that winbind is no longer required?

As always, thanks for your time and consideration,

Christian

Testparm output:
[global]
client signing = if_required
disable spoolss = Yes
dns proxy = No
kerberos method = secrets and keytab
load printers = No
local master = No
log file = /var/log/samba/clients/%m.log
logging = syslog at 0 file
max log size = 100
max stat cache size = 65536
max xmit = 1048676
name resolve order = host wins bcast
ntlm auth = ntlmv1-permitted
printcap name = /dev/null
realm = FOOBAR.COM
security = ADS
template homedir = /home/%U
workgroup = FOOBAR
idmap config foolab:range = 10000-9999999999
idmap config foolab:schema_mode = rfc2307
idmap config foolab:backend = ad
idmap config * : range = 3000-7999
idmap config * : backend = tdb
include = /etc/samba/smb-shares.conf
printing = bsd

-- 
 <http://opendrives.com>

On 12/08/2020 03:46, Christian Kuntz via samba wrote:
> Hi all,
>
> Configuration information right off the bat:
>        Debian Buster 10.5 and Samba 2:4.9.5+dfsg-5+deb10u1.
>
> Testparm is at the bottom
>
>
> I'm running into some interesting behavior on a server I've
configured to
> use SSSD to bind to the AD domain. I've successfully bound using
"net ads"
> and can get tickets and so on, and have samba configured to use kerberos
> through sssd. nsswitch has been configured to use sssd and not winbind as
> well.
> The tricky thing is, though local users work fine winbind has to be running
> in order for AD authentication to work, even though I believe I have
> configured samba to not use winbind at all. If winbind is not running, a
> "NT_STATUS_NO_LOGON_SERVER" error is generated when it fails to
connect to
> winbind's local socket. This is only resolved by starting winbind, in
which
> case auth moves along without issue. I was under the impression that my
> current configuration obviates the need for winbind, but I could very well
> be wrong.
>
> For any AD usage, is it required for winbind to be running even if the
> configuration doesn't use it? If not, what in my confguration needs to
be
> changed so that winbind is no longer required?
>
> As always, thanks for your time and consideration,
>
> Christian
>
> Testparm output:
> [global]
> client signing = if_required
> disable spoolss = Yes
> dns proxy = No
> kerberos method = secrets and keytab
> load printers = No
> local master = No
> log file = /var/log/samba/clients/%m.log
> logging = syslog at 0 file
> max log size = 100
> max stat cache size = 65536
> max xmit = 1048676
> name resolve order = host wins bcast
> ntlm auth = ntlmv1-permitted
> printcap name = /dev/null
> realm = FOOBAR.COM
> security = ADS
> template homedir = /home/%U
> workgroup = FOOBAR
> idmap config foolab:range = 10000-9999999999
> idmap config foolab:schema_mode = rfc2307
> idmap config foolab:backend = ad
> idmap config * : range = 3000-7999
> idmap config * : backend = tdb
> include = /etc/samba/smb-shares.conf
> printing = bsd
>
You do not say which OS you are running, but the fix for your problem is 
something like 'yum remove sssd' or 'apt purge sssd'.

If you are running Samba with 'security = ADS' you must run winbind and 
if you run winbind, you cannot run sssd. They both do the same thing and 
both use versions of the winbind libs.

Rowland

On 12/08/2020 10:35, Christian Naumer wrote:
>
>> Am 12.08.2020 um 09:18 schrieb Rowland penny via samba <samba at
lists.samba.org>:
>>
>> ?On 12/08/2020 03:46, Christian Kuntz via samba wrote:
>>> Hi all,
>>>
>>> Configuration information right off the bat:
>>>        Debian Buster 10.5 and Samba 2:4.9.5+dfsg-5+deb10u1.
>>>
>>> Testparm is at the bottom
>>>
>>>
>>> I'm running into some interesting behavior on a server I've
configured to
>>> use SSSD to bind to the AD domain. I've successfully bound
using "net ads"
>>> and can get tickets and so on, and have samba configured to use
kerberos
>>> through sssd. nsswitch has been configured to use sssd and not
winbind as
>>> well.
>>> The tricky thing is, though local users work fine winbind has to be
running
>>> in order for AD authentication to work, even though I believe I
have
>>> configured samba to not use winbind at all. If winbind is not
running, a
>>> "NT_STATUS_NO_LOGON_SERVER" error is generated when it
fails to connect to
>>> winbind's local socket. This is only resolved by starting
winbind, in which
>>> case auth moves along without issue. I was under the impression
that my
>>> current configuration obviates the need for winbind, but I could
very well
>>> be wrong.
>>>
>>> For any AD usage, is it required for winbind to be running even if
the
>>> configuration doesn't use it? If not, what in my confguration
needs to be
>>> changed so that winbind is no longer required?
>>>
>>> As always, thanks for your time and consideration,
>>>
>>> Christian
>>>
>>> Testparm output:
>>> [global]
>>> client signing = if_required
>>> disable spoolss = Yes
>>> dns proxy = No
>>> kerberos method = secrets and keytab
>>> load printers = No
>>> local master = No
>>> log file = /var/log/samba/clients/%m.log
>>> logging = syslog at 0 file
>>> max log size = 100
>>> max stat cache size = 65536
>>> max xmit = 1048676
>>> name resolve order = host wins bcast
>>> ntlm auth = ntlmv1-permitted
>>> printcap name = /dev/null
>>> realm = FOOBAR.COM
>>> security = ADS
>>> template homedir = /home/%U
>>> workgroup = FOOBAR
>>> idmap config foolab:range = 10000-9999999999
>>> idmap config foolab:schema_mode = rfc2307
>>> idmap config foolab:backend = ad
>>> idmap config * : range = 3000-7999
>>> idmap config * : backend = tdb
>>> include = /etc/samba/smb-shares.conf
>>> printing = bsd
>>>
>> You do not say which OS you are running, but the fix for your problem
is something like 'yum remove sssd' or 'apt purge sssd'.
> That depends on the OS. With Centos 7 you can remove sssd. With Centos 8
pam_krb5 is not available and you then need sssd and winbind. This works good.
But coming back to the original question winbind needs to run.
>
> Regards
>
> Christian
>
This is just my opinion: it seems that RHEL does not want you to use Samba.

If you use 'security = ADS' with Samba >= 4.8.0 , then you must run 
winbind. Up until 4.8.0 , the smbd deamon could contact AD directly, 
this was removed and smbd now has to contact winbind to contact AD.

RHEL has a workaround using the 'sss' backend, but this only seems to 
work for authentication, so no shares.

So, (again in my opinion) if you want to use Samba as a fileserver, do 
not use RHEL/Centos 8

I can confirm that there is nothing stopping you from compiling pam_krb5 
from Centos 7 on Centos 8

Rowland

Any opinions stated above are just my opinion and have nothing to do 
with anyone else's opinion.

On 8/11/20 10:46 PM, Christian Kuntz via samba wrote:
> Hi all,
> 
> Configuration information right off the bat:
>        Debian Buster 10.5 and Samba 2:4.9.5+dfsg-5+deb10u1.
> 
> Testparm is at the bottom
> 
> 
> I'm running into some interesting behavior on a server I've
configured to
> use SSSD to bind to the AD domain. I've successfully bound using
"net ads"
> and can get tickets and so on, and have samba configured to use kerberos
> through sssd. nsswitch has been configured to use sssd and not winbind as
> well.
> The tricky thing is, though local users work fine winbind has to be running
> in order for AD authentication to work, even though I believe I have
> configured samba to not use winbind at all. If winbind is not running, a
> "NT_STATUS_NO_LOGON_SERVER" error is generated when it fails to
connect to
> winbind's local socket. This is only resolved by starting winbind, in
which
> case auth moves along without issue. I was under the impression that my
> current configuration obviates the need for winbind, but I could very well
> be wrong.
> 
> For any AD usage, is it required for winbind to be running even if the
> configuration doesn't use it? If not, what in my confguration needs to
be
> changed so that winbind is no longer required?
> 
> As always, thanks for your time and consideration,
If you are runnning a Samba server as a member of a domain, you need to 
start winbind. The following is a not a Samba issue since Samba and SSSD 
interactions are not part of Samba.

You can still run SSSD/realmd/adcli as your domain membership toolkit, 
but you need to start winbind if a Samba server is started on the same 
machine. Running winbind doesn't means you have to use winbind nsswitch 
module, you can still use SSSD module there and let it provide the list 
of users and groups to the system. In order to make SSSD and winbind 
users match accordingly, you have to use something like:

idmap config MYDOMAIN : range = 278000000-278999999
idmap config MYDOMAIN : backend = rid

with a range that matches the range SSSD assigns to the domain users and 
groups.

Use realmd to join the server and everything should work, Be careful 
that SSSD properly updates the machine account password, and Samba could 
be doing that too, but it doesn't with some combinations of the setting 
"kerberos method". I use

   kerberos method = secrets and keytab

Whe that setting is set, Samba doesn't try the machine password 
periodically. but as SSSD will try to do it, the Samba server stores 
password and the SSSD one are different and your Samba server start to 
have authentication problems.

You can disable SSSD machine account password renewal 
(ad_maximum_machine_account_password_age = 0) or run a cron job with 
something like:

   adcli update --add-samba-data -v --computer-password-lifetime=0 -D 
<your domain>

The --add-samba-data is a new option that exists on adcli (at least on 
RHEL/CentOS 8) but the SSSD configuration parameter 
(ad_update_samba_machine_account_password) is upstream but not yet on 
the distro version

See: https://pagure.io/SSSD/sssd/issue/3920

Hope this helps, but remember any problems with this configuration 
should be tried without using SSSD in order to know if it is a Samba 
issue of SSSD one.
> 
> Christian
> 
> Testparm output:
> [global]
> client signing = if_required
> disable spoolss = Yes
> dns proxy = No
> kerberos method = secrets and keytab
> load printers = No
> local master = No
> log file = /var/log/samba/clients/%m.log
> logging = syslog at 0 file
> max log size = 100
> max stat cache size = 65536
> max xmit = 1048676
> name resolve order = host wins bcast
> ntlm auth = ntlmv1-permitted
> printcap name = /dev/null
> realm = FOOBAR.COM
> security = ADS
> template homedir = /home/%U
> workgroup = FOOBAR
> idmap config foolab:range = 10000-9999999999
> idmap config foolab:schema_mode = rfc2307
> idmap config foolab:backend = ad
> idmap config * : range = 3000-7999
> idmap config * : backend = tdb
> include = /etc/samba/smb-shares.conf
> printing = bsd
>

On 12/08/2020 13:24, Robert Marcano via samba wrote:
> If you are runnning a Samba server as a member of a domain, you need 
> to start winbind. The following is a not a Samba issue since Samba and 
> SSSD interactions are not part of Samba.
>
> You can still run SSSD/realmd/adcli as your domain membership toolkit, 
> but you need to start winbind if a Samba server is started on the same 
> machine. Running winbind doesn't means you have to use winbind 
> nsswitch module, you can still use SSSD module there and let it 
> provide the list of users and groups to the system. In order to make 
> SSSD and winbind users match accordingly, you have to use something like:
>
> idmap config MYDOMAIN : range = 278000000-278999999
> idmap config MYDOMAIN : backend = rid
There is no reason to match the sssd ID's on a Samba domain member, also 
you shouldn't have sssd and winbind installed on the same machine, they 
both use different version of the winbind libs.
>
> Use realmd to join the server and everything should work,
Just use 'net ads join', no need for realmd.
> Be careful that SSSD properly updates the machine account password, 
> and Samba could be doing that too, but it doesn't with some 
> combinations of the setting "kerberos method". I use
>
> ? kerberos method = secrets and keytab
The kerberos method has nothing to do with updating the machine 
passwords, it just tells Samba how to verify tickets, using secrets.tdb 
and the system keytab (the one in memory) in this case.
>
> Whe that setting is set, Samba doesn't try the machine password 
> periodically. but as SSSD will try to do it, the Samba server stores 
> password and the SSSD one are different and your Samba server start to 
> have authentication problems.
If that is the case, one of them is broken and it isn't Samba
;-)
>
> You can disable SSSD machine account password renewal 
> (ad_maximum_machine_account_password_age = 0) or run a cron job with 
> something like:
>
> ? adcli update --add-samba-data -v --computer-password-lifetime=0 -D 
> <your domain>
>
> The --add-samba-data is a new option that exists on adcli (at least on 
> RHEL/CentOS 8) but the SSSD configuration parameter 
> (ad_update_samba_machine_account_password) is upstream but not yet on 
> the distro version
I do not understand why the red-hat tools are used on a Samba server, 
what is wrong with the Samba tools ?
> Hope this helps, but remember any problems with this configuration 
> should be tried without using SSSD in order to know if it is a Samba 
> issue of SSSD one.
Any sssd problems should be reported to sssd, we do not produce it, so 
we cannot fix it ;-)

Rowland

What i dont get/understand .. 

Why ? Why such setup. 
Can TP explain this? 

Just trying to understand you idea why setup like this.. 
There must be a reason? 


Greetz, 

Louis


 
> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens 
> Rowland penny via samba
> Verzonden: woensdag 12 augustus 2020 14:41
> Aan: samba at lists.samba.org
> Onderwerp: Re: [Samba] Using SSSD + AD with Samba seems to 
> require Winbind be running
> 
> On 12/08/2020 13:24, Robert Marcano via samba wrote:
> > If you are runnning a Samba server as a member of a domain, 
> you need 
> > to start winbind. The following is a not a Samba issue 
> since Samba and 
> > SSSD interactions are not part of Samba.
> >
> > You can still run SSSD/realmd/adcli as your domain 
> membership toolkit, 
> > but you need to start winbind if a Samba server is started 
> on the same 
> > machine. Running winbind doesn't means you have to use winbind 
> > nsswitch module, you can still use SSSD module there and let it 
> > provide the list of users and groups to the system. In 
> order to make 
> > SSSD and winbind users match accordingly, you have to use 
> something like:
> >
> > idmap config MYDOMAIN : range = 278000000-278999999
> > idmap config MYDOMAIN : backend = rid
> There is no reason to match the sssd ID's on a Samba domain 
> member, also 
> you shouldn't have sssd and winbind installed on the same 
> machine, they 
> both use different version of the winbind libs.
> >
> > Use realmd to join the server and everything should work,
> Just use 'net ads join', no need for realmd.
> > Be careful that SSSD properly updates the machine account password, 
> > and Samba could be doing that too, but it doesn't with some 
> > combinations of the setting "kerberos method". I use
> >
> > ? kerberos method = secrets and keytab
> The kerberos method has nothing to do with updating the machine 
> passwords, it just tells Samba how to verify tickets, using 
> secrets.tdb 
> and the system keytab (the one in memory) in this case.
> >
> > Whe that setting is set, Samba doesn't try the machine password 
> > periodically. but as SSSD will try to do it, the Samba 
> server stores 
> > password and the SSSD one are different and your Samba 
> server start to 
> > have authentication problems.
> If that is the case, one of them is broken and it isn't Samba ;-)
> >
> > You can disable SSSD machine account password renewal 
> > (ad_maximum_machine_account_password_age = 0) or run a cron 
> job with 
> > something like:
> >
> > ? adcli update --add-samba-data -v 
> --computer-password-lifetime=0 -D 
> > <your domain>
> >
> > The --add-samba-data is a new option that exists on adcli 
> (at least on 
> > RHEL/CentOS 8) but the SSSD configuration parameter 
> > (ad_update_samba_machine_account_password) is upstream but 
> not yet on 
> > the distro version
> I do not understand why the red-hat tools are used on a Samba server, 
> what is wrong with the Samba tools ?
> > Hope this helps, but remember any problems with this configuration 
> > should be tried without using SSSD in order to know if it 
> is a Samba 
> > issue of SSSD one.
> 
> Any sssd problems should be reported to sssd, we do not 
> produce it, so 
> we cannot fix it ;-)
> 
> Rowland
> 
> 
> 
> -- 
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
> 
>