Samba authentication using a windows domain controller

_os_ · 07-22-2009, 04:32 AM

Hello all,

I've been asked to look into a problem with a client's samba server. The server is to be accessed over the network by Windows machines, and the server is to authenticate the users using a Windows domain controller. I've happily used Samba many times before but this is new territory.

I did some testing at the client's location and upon restarting Samba I get errors in log.nmbd similar to this:

Code:

[2009/07/21 09:57:21,  0] nmbd/nmbd_nameregister.c:register_name_response(129)
  register_name_response: server at IP 10.0.2.53 rejected our name registration of FUSED<00> IP 10.0.2.22 with error code 6.
[2009/07/21 09:57:21,  0] nmbd/nmbd_mynames.c:my_name_register_failed(35)
  my_name_register_failed: Failed to register my name FUSED<00> on subnet 10.0.2.22.
[2009/07/21 09:57:21,  0] nmbd/nmbd_namelistdb.c:standard_fail_register(307)
  standard_fail_register: Failed to register/refresh name FUSED<00> on subnet 10.0.2.22

One strange part of the error is the IP 10.0.2.53 which is another Domain Controller but some the specified in smb.conf as shown below.

The smb.conf looks like this:

Code:

[global]
        security = domain
        netbios name = FUSED
        realm = FUSED
        password server = 10.0.2.54
        workgroup = fused
        idmap uid = 5000-10000000
        idmap gid = 5000-10000000
        winbind separator = +
;       winbind enum users = no
;       winbind enum groups = no
        winbind use default domain = yes
;       template homedir = /home/%d/%u
        template shell = /bin/bash
;       client use spnego = yes
        domain master = no
;       server string = samba 3.2.3
;       encrypt passwords = yes
;       guest ok = yes
;       guest account = nobody

[user01]
        comment = Test User
        path = /home/FUSED/user01
        writeable = yes
        browseable = yes
        guest ok = yes

I also found an old smb.conf within /etc/samba which doesn't seem to fail like the existing file, but it doesn't work either. The old config looks like this:

Code:

[global]
security = ads
password server = 10.0.2.54
   workgroup = FUSED
   server string = %h server (Samba, Ubuntu)
   dns proxy = no
   log file = /var/log/samba/log.%m
   max log size = 1000
   panic action = /usr/share/samba/panic-action %d
   encrypt passwords = true
   passdb backend = tdbsam
   obey pam restrictions = yes
   unix password sync = yes
   passwd program = /usr/bin/passwd %u
   passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
   pam password change = yes
   map to guest = bad user
   idmap uid = 10000-20000
   idmap gid = 10000-20000
   winbind enum users = yes
   winbind enum groups = yes
   template homedir = /home/%D/%U
   template shell = /bin/bash
   client use spnego = yes
   client ntlmv2 auth = yes
   encrypt passwords = yes
   winbind use default domain = yes
   restrict anonymous = 2
   winbind refresh tickets = yes
   usershare allow guests = yes

And this gives this in log.nmbd:

Code:

[2009/07/21 16:00:40,  0] nmbd/nmbd_become_lmb.c:become_local_master_stage2(395)
  *****
  Samba name server SAMBABOX is now a local master browser for workgroup FUSED on subnet 10.0.2.22
  
  *****

Just to clarify, the IPs are these:

10.0.2.54 = Domain Controller
10.0.2.53 = Another Domain Controller
10.0.2.20 = Samba server
10.0.2.22 = Windows machine trying to access Samba

I'm also trying to create a test bed in the office of a similar environment to try and help understand what's happening and where it might be failing but then there's the hurdle of not having the experience of setting up a domain controller in Windows before.

I have followed online documentation to create a domain server but I'm currently unsure if it's setup or working correctly. The only consistency currently being that on the Samba server I'm testing with is producing similar errors to those at the client but I'm thinking this is due to that the Domain Controller is probably configured incorrectly.

Thanks in advance.

OS

PresGas · 07-22-2009, 08:46 AM

Active Directory and Samba really like to use DNS when possible and fully qualified domain names. I looks like the server is actually joined to the domain as well, so unless you had the samba server leave the domain before replacing the smb.conf files, I don't think that would work well.

I have a good deal of links regarding this and will pass it on to get you started reading up:
http://delicious.com/PresGas/activedirectory-samba

A good starter is, though is the bottom link there from the WONDERFUL Carla Schroder:
http://www.enterprisenetworkingplane...le.php/3487081

The bottom line is that if there are two domain controllers there they both need to be accounted for somehow in the smb.conf file. You should know if they are both master/slave controllers or if they are separate domains and then if they have some kind of trust relationship.

Keep posting after looking this over to tell us if you are still having problems or if you fixed it!

_os_ · 08-05-2009, 02:22 AM

Hi PresGas, thanks for the reply & apologies for not replying sooner. I've only just managed to get back onto this task so I'll be visiting the client today and trying a few things out. The links you've provided have given me a number of things to try.

I shall report my findings.

Thanks again.

OS

jschiwal · 08-05-2009, 02:41 AM

I'd also recommend installing the samba-doc package at home for the books, Samba 3 by Example and Samba 3 HOWTO & Reference. These are the official Samba 3 books you can find in the book store. The latest edition of "Using Samba" includes information about Active Directory and suggests which Window's tools work best to manage the Samba server.

_os_ · 08-05-2009, 05:50 AM

Well I've just gotten back, still not working as of yet. I did however find out a few more things.

Kerberos5 is already installed and configured, the krb5.conf file looks like this:

Code:

[libdefaults]
        dns_lookup_realm = true
        dns_lookup_kdc = true
        krb4_config = /etc/krb.conf
        krb4_realms = /etc/krb.realms
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true
        v4_instance_resolve = false
        v4_name_convert = {
                host = {
                        rcmd = host
                        ftp = ftp
                }
                plain = {
                        something = something-else
                }
        }
        fcc-mit-ticketflags = true
        default_tgs_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
        default_tkt_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
        preferred_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
        default_realm = CORP.COMPANY.CO.UK

# The following krb5.conf variables are only for MIT Kerberos.

# The following encryption type specification will be used by MIT Kerberos
# if uncommented.  In general, the defaults in the MIT Kerberos code are
# correct and overriding these specifications only serves to disable new
# encryption types as they are added, creating interoperability problems.
#
# Thie only time when you might need to uncomment these lines and change
# the enctypes is if you have local software that will break on ticket
# caches containing ticket encryption types it doesn't know about (such as
# old versions of Sun Java).

#       default_tgs_enctypes = des3-hmac-sha1
#       default_tkt_enctypes = des3-hmac-sha1
#       permitted_enctypes = des3-hmac-sha1


# The following libdefaults parameters are only for Heimdal Kerberos.

[realms]
        CORP.COMPANY.CO.UK = {
        auth_to_local = RULE:[1:$0\$1](^CORP\.COMPANY\.CO\.UK\\.*)s/^CORP\.COMPANY\.CO\.UK/FUSED/
        auth_to_local = RULE:[1:$0\$1](^COMPANYRESTORE\.LOCAL\\.*)s/^COMPANYRESTORE\.LOCAL/COMPANYRESTORE/
        auth_to_local = RULE:[1:$0\$1](^(NULL)\\.*)s/^(NULL)/DMZ1/
        auth_to_local = DEFAULT
        }

[domain_realm]
        .corp.company.co.uk = CORP.COMPANY.CO.UK
        corp.company.co.uk = CORP.COMPANY.CO.UK

[login]
        krb4_convert = true
        krb4_get_tickets = false
[appdefaults]
        pam = {
   mappings = FUSED\\(.*) $1@CORP.COMPANY.CO.UK
   forwardable = true
   validate = true
        }
        httpd = {
   mappings = FUSED\\(.*) $1@CORP.COMPANY.CO.UK
   reverse_mappings = (.*)@CORP\.COMPANY\.CO\.UK FUSED\$1
        }

An account was made with active domain permissions but upon trying to authenticate with kinit I received an error:

Code:

kinit testuser@CORP.COMPANY.CO.UK

kinit(v5): No credentials cache found when initializing cache

I also tried using klist:

Code:

klist -f

klist: No credentials cache found (ticket cache FILE:)

Kerberos 4 ticket cache: /tmp/tkt1000
klist: You have no tickets cached

I was a bit mythed as to why the result included 'Kerberos 4' details.

I shall have to be doing a lot of reading up before my next visit