[Samba] Samba 4 AD member server authentication issues, domain vs. ads security

[Eric Shell]

I have an environment with two separate AD instances which each have both a
samba 3 and samba 4 file server joined to them. Last week, we began to
experience authentication failures in both domains on the samba 4 file
servers. After a lot of experimenting, we found that changing the security
setting from domain to ads resolved the problem for the samba 4 servers.

However, the samba 3 servers are still configured with security = domain
and are continuing to authenticate users without issue. Also, due to the
fact that ads requires a kerberos ticket, there are some clients that can
no longer authenticate because they are not able to acquire tickets from
the AD kerberos realms.

I have a few questions that I've so far been unable to answer:

1. What happened to break authentication for the samba 4 servers last
week, was it some kind of Microsoft patch perhaps? Why weren't the samba 3
servers affected by whatever changed?

2. Is there an "ideal" configuration for a samba file server as a member
of an AD domain? From what I've read, ads is the preferred security
method. If we should continue using ads, how do we best handle clients
that will not have kerberos tickets?

[mathias dufresne]

Hi Eric,

No idea I didn't touched a Samba 3 for years but you should mentioned what
are the version you are using, for your domains (and also if they are NT4
or AD, even if it looks like they are NT4, can't really be sure) and your
file servers.

That would certainly help people around who know (largely) better than me
smb.conf and its history ;)

Cheers,

mathias

Post by Eric Shell
I have an environment with two separate AD instances which each have both a
samba 3 and samba 4 file server joined to them. Last week, we began to
experience authentication failures in both domains on the samba 4 file
servers. After a lot of experimenting, we found that changing the security
setting from domain to ads resolved the problem for the samba 4 servers.
However, the samba 3 servers are still configured with security = domain
and are continuing to authenticate users without issue. Also, due to the
fact that ads requires a kerberos ticket, there are some clients that can
no longer authenticate because they are not able to acquire tickets from
the AD kerberos realms.
1. What happened to break authentication for the samba 4 servers last
week, was it some kind of Microsoft patch perhaps? Why weren't the samba 3
servers affected by whatever changed?
2. Is there an "ideal" configuration for a samba file server as a member
of an AD domain? From what I've read, ads is the preferred security
method. If we should continue using ads, how do we best handle clients
that will not have kerberos tickets?
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

[Eric Shell]

Thanks for the quick replies.

One domain is at Windows Server 2008 functional level, and the other is
Windows Server 2012 R2. The samba 4 servers are running 4.2.10 and the
samba 3 servers are running 3.6.23, both from rpms available from either
the CentOS 6 or 7 repos (samba 4 on CentOS 7, samba 3 on CentOS 6).

Here's the smb.conf used on the two samba 4 servers:

[global]

workgroup = BSOE
server string = SAMBA-01
netbios name = SAMBA-01
realm = ad.soe.ucsc.edu
security = ads
log file = /var/log/samba.log
log level = 2
browseable = yes
read only = no
local master = no
load printers = no
preserve case = yes
case sensitive = yes
wins support = no
passdb backend = tdbsam
printing = bsd
printcap name = /dev/null
disable spoolss = yes
client ldap sasl wrapping = sign
short preserve case = yes
nt acl support = no
wide links = no
unix extensions = no
strict locking = no
kernel change notify = no

include = /etc/samba/shares.conf


Rowland, I changed the security option based on the example on that page of
the wiki but I didn't perform the winbind portion because I wasn't sure
whether it was necessary or wise. The issue with some clients not having
kerberos tickets is that we have some systems that are not integrated with
AD and have been using password authentication thus far. If possible, we
would like to continue to be able to use password authentication for
clients that aren't part of the domains since some of them will not/can not
be joined.

[Eric Shell]

I should add that the samba.log file was logging NT_STATUS_NO_LOGON_SERVERS
errors when authentication attempts were failing. Workstations in the
domains were still able to authenticate, however, and I verified that the
DNS records were still correct. The SRV records were all in place and the
domain controllers' host names were resolving.

Post by Eric Shell
Thanks for the quick replies.
One domain is at Windows Server 2008 functional level, and the other is
Windows Server 2012 R2. The samba 4 servers are running 4.2.10 and the
samba 3 servers are running 3.6.23, both from rpms available from either
the CentOS 6 or 7 repos (samba 4 on CentOS 7, samba 3 on CentOS 6).
[global]

workgroup = BSOE
server string = SAMBA-01
netbios name = SAMBA-01
realm = ad.soe.ucsc.edu
security = ads
log file = /var/log/samba.log
log level = 2
browseable = yes
read only = no
local master = no
load printers = no
preserve case = yes
case sensitive = yes
wins support = no
passdb backend = tdbsam
printing = bsd
printcap name = /dev/null
disable spoolss = yes
client ldap sasl wrapping = sign
short preserve case = yes
nt acl support = no
wide links = no
unix extensions = no
strict locking = no
kernel change notify = no

include = /etc/samba/shares.conf
Rowland, I changed the security option based on the example on that page
of the wiki but I didn't perform the winbind portion because I wasn't sure
whether it was necessary or wise. The issue with some clients not having
kerberos tickets is that we have some systems that are not integrated with
AD and have been using password authentication thus far. If possible, we
would like to continue to be able to use password authentication for
clients that aren't part of the domains since some of them will not/can not
be joined.