Possible to authenticate Samba via Kerberos but without domain-join?

Question

With a Kerberos config file...

[realms]
  DOMAIN.COM = {
    kdc = dc1.domain.com
    admin_server = dc1.domain.com
  }

...it is possible for Linux to talk to Active Directory for password validation without necessarily being an AD domain member:

$ kinit jdoe
Password for jdoe@DOMAIN.COM:
$ klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: jdoe@DOMAIN.COM

Valid starting     Expires            Service principal
01/12/15 15:36:16  01/13/15 01:36:25  krbtgt/DOMAIN.COM@DOMAIN.COM
        renew until 01/19/15 15:36:16

At this point, you can use PAM to define local Linux users in /etc/passwd, yet have their TTY sessions authenticated via Active Directory. Authn via krb5 is done as a per-login context:

auth        sufficient    pam_krb5.so use_first_pass

But if krb5 is already implemented as part of the PAM global defaults, why isn't Samba also picking it up? I see /etc/pam.d/samba does an include of the Kerberized password-auth file, but no joy when accessing an SMB volume. (Debug logs indicate a failed-to-get-SID error, which is very "you are not part of the domain".)

My underlying question is: can a similar krb5 authn centralization be done under Samba as it was for Shell, without all that extra overhead/complexity of domain membership? I need to have Samba services implemented on a group of NIS-clustered systems, but don't want to have different TDBSAM back-ends on each system leading to SMB password confusion. Using Kerberos as my authenticator would be great. However, I still want to define authorization/access via local Linux account and not open up Samba access to all domain users as would be the case with domain-join, winbind DC emulation, or full-fledged AD server.

Alternatively: is there a better centralized back-end authn option for Samba in a Linux cluster? I looked at CTDB, but it seemed to be geared towards mediating shared-storage rather than central authn with disparate volumes...

Answer 1

Samba means different things to different people. To some, it is a way to implement LanMan-style networking without tithing to Microsoft, using WinBind to provide pseudo Domain Controller services without actually running a Windows Server. This is perhaps why ‘drookie’ made the comment “Seems like you have AD running but for some reason you don't want to use it. Why using samba then anyway?”. Why? Because I’m using Samba mainly for the basic CIFS support. All that extra WinBind/ADS home-dir and cached DC data cruft is something I didn’t really want. I was looking for Linux to still define authorization & access, not open it up to all domain users. But for the users that are allowed, use Kerberos authentication. (Samba – especially Samba4 – is heading towards full Active Directory emulation of Linux nodes in a Windows AD domain, all the way down to inheritance of SID/GUID, OU membership, etc. Their goal is to have no need to create Linux local accounts because Samba will create them on-the-fly based on AD profiles. Overkill for my needs.)

Since I was looking to Samba primarily for the CIFS functionality, I was hoping that AD could be used only for the authentication part via the Kerberos calls (as I have already implemented for SSH). If I didn’t need domain-join to have Kerberos work at the TTY/SSH level, did I really need it for Samba+Kerberos? Unfortunately, the answer is YES. But despite that, I was still able to accomplish my goal of AD/Kerberos authn without turning the Linux host into a PDC/BDC or deferring all authz control to ADS mode. What I have works, and this is my interpretation of why:

Basic Kerberos works at the PAM/TTY level because the user is typing their password interactively, fed directly into the krb5 library; when running in context of the user doing the request, no domain-join is needed. However, in the case of authenticating CIFS shares, the Windows client has already encrypted the password that the user typed, so by the time Samba gets it, it is the NTLMv2 hash. This is probably why the O’Reilly “Hornbill book” says “the auth PAM module lines are ignored completely” by Samba. In this case, Samba must contact the AD server securely to retrieve credential details to know for sure if the user/password is correct. For this reason, a domain-join is needed. In essence, the domain-joined Samba is acting as a Kerberos proxy to contact AD and verify the client credentials.

I found that even with a required domain-join, there is no need to run a local WinBind daemon or turn the Linux host into a full AD server. Here is what I did in the Samba4 config file:

security = ADS 
passdb backend = tdbsam

realm = DOMAIN.COM 
password server = * 
encrypt passwords = yes 
lanman auth = no 
ntlm auth = no                    # NTLMv2
kerberos method = system keytab 
username map = /etc/samba/smbusers 
guest account = nfsnobody 
map to guest = Bad User 
obey pam restrictions = yes

It’s probably more significant to point out what I did not do:

• winbind directives are omitted from the smb.conf config file
• the winbind service is not enabled/running (to cache AD data as if it were a DC)
• winbind was not added to /etc/nsswitch.conf (to use the domain as a valid local-user source)
• winbind and mkhomedir are not added to /etc/pam.d/system-auth (to allow domain users to login and create accounts on-the-fly)

The bare minimum is that a domain-join is required to enable the Kerberos lookup relative to local-user access:

# net ads join -U Administrator
# net ads keytab create

However, no services are enabled that would turn the Linux host into a card-carrying access-authorizing PDC/BDC or ADS substitute. I am using Samba+Kerberos strictly for local user validation and nothing more.

Answer 2

You can run samba on top of the NIS, in this case the user database will be synchronized by it, and without joining the domain you will have a bunch of standalone samba servers. This would also mean that you will have to manually add domain users or at least their passwords on each server. This probably isn't what you want.

You can also experiment with using AD LDAP as the ldap backend for samba users, without joining the domain.

So there's plenty of options, but to be honest, I don't understand your point. Seems like you have AD running but for some reason you don't want to use it. Why using samba then anyway.