Home / server / Questions / 81005
In Process
markdrayton
Asked: 2009-11-04 06:50:01 +0800 CST

Samba: AD authentication for local users

  • 772

We have a lot of Linux development servers which are generally accessed via SSH. Each developer has a local account on each box, managed by Puppet. Logins are via private keys only; there are no local passwords.

I'd like to run Samba on these boxes and authenticate against our AD domain. I don't want AD authentication for anything besides Samba -- everything else is accessed via SSH and private keys.

Here's my smb.conf:

[global]
 workgroup = DOMAIN
 server string = Samba Server Version %v
 security = ADS
 realm = DOMAIN.FQDN
 encrypt passwords = yes
 log level = 3
 log file = /var/log/samba/%U.log

[homes]
 comment = Home Directories
 browseable = no
 writable = yes

I'm pretty sure the Kerberos configuration is fine as I've joined the domain.

Relevant (ie, non-standard) nsswitch.conf lines:

passwd:     files winbind
group:      files winbind

It looks like the problem is AD UID to UNIX UID mapping. The default TDB backend will create 'virtual' UNIX accounts on demand when AD users connect but I don't want this -- I want user foo to map to the local user foo. If I add idmap uid and idmap gid lines the users authenticate okay but their accounts aren't mapped to the UNIX accounts.

Any ideas? Somoene must've done this before! I don't want to switch to using winbind and AD to provide all the account information because of the hassle with maintaining consistent UID/GIDs on all machines. We've also put a lot into the existing Puppet-controlled user configuration that we don't want to reinvent.

authentication

2 Answers

  1. Make sure the winbind service is running.

    Set up in your /etc/pam.d/samba:

    account     [default=bad success=ok user_unknown=ignore]  pam_winbind.so
account     required      pam_permit.so

password    sufficient    pam_winbind.so use_authtok
password    required      pam_deny.so
session     required      pam_limits.so

auth       required pam_nologin.so
auth sufficient pam_winbind.so use_first_pass
auth required   pam_deny.so

    Pam changes sometimes require a winbind restart. Shouldn't, but practical experience says do it anyway.

    In smb.conf you also need:

    realm = YOURKERBEROSREALMNAME
password server = the host or IP of your ADC
idmap backend = rid:DOMAIN=5000-100000000
idmap uid = 10000-10000000
idmap gid = 10000-10000000
winbind use default domain = Yes
winbind enum users = Yes
winbind enum groups = Yes

    Where DOMAIN is your workgroup or domain name and realm matches what is in your krb5.conf

    Restart samba services after the changes in smb.conf

    • 2

  2. from http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/idmapper.html#id2604553

    A Samba member of a Windows networking domain (NT4-style or ADS) can be configured to handle identity mapping in a variety of ways. The mechanism it uses depends on whether or not the winbindd daemon is used and how the winbind functionality is configured. The configuration options are briefly described here:

    Winbind is not used; users and groups are local:

    Where winbindd is not used Samba (smbd) uses the underlying UNIX/Linux mechanisms to resolve the identity of incoming network traffic. This is done using the LoginID (account name) in the session setup request and passing it to the getpwnam() system function call. This call is implemented using the name service switch (NSS) mechanism on modern UNIX/Linux systems. By saying "users and groups are local," we are implying that they are stored only on the local system, in the /etc/passwd and /etc/group respectively.

    For example, when the user BERYLIUM\WambatW tries to open a connection to a Samba server the incoming SessionSetupAndX request will make a system call to look up the user WambatW in the /etc/passwd file.

    This configuration may be used with standalone Samba servers, domain member servers (NT4 or ADS), and for a PDC that uses either an smbpasswd or a tdbsam-based Samba passdb backend.

    seems like if you just take winbind out of the equation things will be honkydorey assuming your AD users are the same as the local /etc/passwd users.

    • 1