samba - Apr 2015 - Samba 4.1 as member server, problems doing password authentication using CentOS/RedHat 7 packages

I've come across a difference I can't explain between the way Samba 
behaves on Fedora 20 (4.1.17-1.fc20) and Centos 7 (4.1.12-21.el7). I 
have a test server of each system (Fedora 20 and Centos 7), each newly 
built, fully updated, and with the same config file.  Each is joined to 
our AD domain (Windows DCs).  Some of our client systems are joined to 
the domain and use Kerberos tickets to get access. Others are not joined 
to the domain and need to supply a username/password.

Clients which are joined to the AD domain (i.e. kerberos) work fine on 
both CentOS and Fedora servers.  But if a client is not on the AD domain 
and therefore giving us a username/password pair to authenticate with, 
the service only works on the Fedora system.

On both Fedora and CentOS I see that the Samba process is contacting the 
DC with the logon information.  While Fedora gets back an appropriate 
response of logon success or logon failure, the CentOS version gets back 
one of 3 responses (I have not seen a pattern to which response we get):
NT_STATUS_LOCK_NOT_GRANTED
NT_STATUS_ACCESS_DENIED
NT_STATUS_INVALID_PARAMETER

With any of those errors, it denies the client access to the share, even 
though the correct username and password has been sent.

I dumped (using testparm -v) all of the default settings, and found that 
there were two entries with different defaults:
(CentOS):
winbindd socket directory = /run/samba/winbindd
winbind sealed pipes = Yes
(Fedora):
winbindd socket directory winbind sealed pipes = No

However, changing them on the CentOS server did not change it's behavior 
(didn't expect that it would).

Also, the CentOS version has 5 additional default-set parameters that 
don't exist in the Fedora version:
neutralize nt4 emulation = No
reject md5 servers = No
require strong key = Yes
allow nt4 crypto = No
reject md5 clients = No

I've tried changing those defaults, but did not see a change in this 
behavior. I don't see how to unset them so that they don't exist at 
all.  It may be worth noting that these seem to come from some 4.2 code, 
so it might be that RedHat has applied some 4.2 patches in the process.

My smb.conf file is pretty simple, and the same for each server:

[global]
        workgroup = [short domain name]
        server string = WCNR Samba Server Version %v
        # logs split per machine
        log file = /var/log/samba/log.%m
        # max 250KB per log file, then rotate
        max log size = 250
        security = ads
        realm = [fully qualified domain name]
        smb ports = 445
        veto files = /lost+found/
        unix extensions = No
        create mask = 0664
        directory mask = 0775
        username map script = /var/lib/samba/scripts/username_map_script


[sambatest]
   path = /export/sambatest
   writable = yes
   browseable = no


Does anyone have any idea of why username/password logons would fail on 
CentOS 7 when the rest of it seems to be working correctly?

Thanks much in advance!

-Ty!



-- 
-===========================-
    Ty Boyack
    NREL Senior IT Engineer
    Ty.Boyack at colostate.edu
    (970) 491-1186
-===========================-

Greetings, Ty! Boyack!
> I've come across a difference I can't explain between the way Samba
> behaves on Fedora 20 (4.1.17-1.fc20) and Centos 7 (4.1.12-21.el7). I 
> have a test server of each system (Fedora 20 and Centos 7), each newly 
> built, fully updated, and with the same config file.  Each is joined to 
> our AD domain (Windows DCs).  Some of our client systems are joined to 
> the domain and use Kerberos tickets to get access. Others are not joined 
> to the domain and need to supply a username/password.
> Clients which are joined to the AD domain (i.e. kerberos) work fine on 
> both CentOS and Fedora servers.  But if a client is not on the AD domain 
> and therefore giving us a username/password pair to authenticate with, 
> the service only works on the Fedora system.
> On both Fedora and CentOS I see that the Samba process is contacting the 
> DC with the logon information.  While Fedora gets back an appropriate 
> response of logon success or logon failure, the CentOS version gets back 
> one of 3 responses (I have not seen a pattern to which response we get):
> NT_STATUS_LOCK_NOT_GRANTED
> NT_STATUS_ACCESS_DENIED
> NT_STATUS_INVALID_PARAMETER
> With any of those errors, it denies the client access to the share, even 
> though the correct username and password has been sent.
> I dumped (using testparm -v) all of the default settings, and found that 
With Samba 4, I've found the output of "samba-tool testparm" to be
different
from "testparm". The former looks more trustworthy to me.
> there were two entries with different defaults:
> (CentOS):
> winbindd socket directory = /run/samba/winbindd
> winbind sealed pipes = Yes
> (Fedora):
> winbindd socket directory > winbind sealed pipes = No
> However, changing them on the CentOS server did not change it's
behavior
> (didn't expect that it would).
> Also, the CentOS version has 5 additional default-set parameters that 
> don't exist in the Fedora version:
> neutralize nt4 emulation = No
> reject md5 servers = No
> require strong key = Yes
> allow nt4 crypto = No
> reject md5 clients = No
> I've tried changing those defaults, but did not see a change in this 
> behavior. I don't see how to unset them so that they don't exist at
> all.  It may be worth noting that these seem to come from some 4.2 code, 
> so it might be that RedHat has applied some 4.2 patches in the process.
> My smb.conf file is pretty simple, and the same for each server:
> [global]
>         workgroup = [short domain name]
>         server string = WCNR Samba Server Version %v
>         # logs split per machine
>         log file = /var/log/samba/log.%m
>         # max 250KB per log file, then rotate
>         max log size = 250
>         security = ads
>         realm = [fully qualified domain name]
>         smb ports = 445
>         veto files = /lost+found/
>         unix extensions = No
>         create mask = 0664
>         directory mask = 0775
>         username map script = /var/lib/samba/scripts/username_map_script
> [sambatest]
>    path = /export/sambatest
>    writable = yes
>    browseable = no
> Does anyone have any idea of why username/password logons would fail on 
> CentOS 7 when the rest of it seems to be working correctly?
> Thanks much in advance!
Following smb.conf compare, I would compare krb5.conf, particularly the realm
name and capitalization.
Been bitten by that >.<


-- 
With best regards,
Andrey Repin
Tuesday, April 21, 2015 02:27:22

Sorry for my terrible english...

On 04/20/2015 05:30 PM, Andrey Repin wrote:
> Greetings, Ty! Boyack!
Thanks, and Hi!
> I dumped (using testparm -v) all of the default settings, and found that
> With Samba 4, I've found the output of "samba-tool testparm"
to be different
> from "testparm". The former looks more trustworthy to me.
I feel really foolish here -- but I don't see samba-tool as an installed 
binary or in any of the packages available via the repositsories we use 
for CentOS or Fedora. Is this part of the standard suite or samba
> Following smb.conf compare, I would compare krb5.conf, particularly the
realm
> name and capitalization.
> Been bitten by that >.<
>
>
Good thought.  I use 'net ads join' to join the active directory domain,
so that creates it's krb5 file on the fly in /var/lib/samba/smb_krb5.  
The contents of the files on each server is almost the same -- it is the 
same information (including capitalization -- you are right on that!) 
but the order of the KDCs is different.  I changed the order to make 
sure that is not the issue and confirmed that the behavior is the same.

I wonder if the package compilation invokes substantially different 
options for this behavior?  I don't know how to tell what configure 
options are used by the package creators.  Does anyone know if that is 
easy to discover?

Thanks,

-Ty!


-- 
-===========================-
    Ty Boyack
    NREL Senior IT Engineer
    Ty.Boyack at colostate.edu
    (970) 491-1186
-===========================-