samba - Jun 2016 - Samba 4 AD member server authentication issues, domain vs. ads security

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?

On 22/06/16 17:11, Eric Shell wrote:
> 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?
Then you haven't visited the Samba wiki, see here:

https://wiki.samba.org/index.php/Setup_Samba_as_an_AD_Domain_Member

As for the lack of kerberos tickets, if your machines are joined to an 
AD domain, they should have kerberos tickets.

Can you tell us what OS you are using and can you also post your 
smb.conf files

Rowland

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

2016-06-22 18:11 GMT+02:00 Eric Shell <eshell at ucsc.edu>:
> 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?
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>

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.