3

Due to various reasons, we are looking to migrate our file servers from OS X Server 10.9 over to a true Samba implementation running on Ubuntu 14.04LTS. We have Ubuntu up and running with Samba installed, and even have PAM setup to authenticate users against our Apple OpenDirectory server.

However, getting Samba to authenticate users the way we want is proving to be quite challenging. It appears we have two choices. Option 1 is to simply have Samba delegate this to the already functional PAM subsystem; Option 2 is to use Samba's built-in support for LDAP and Kerberos. The out-of-box configuration in Ubuntu seems to favor option 1, and indeed seems like that would be the simplest setup to manage long-term. (Option 2 requires a ton more configuration including modification to the Apple schema, which I understand is not a good idea in practice.)

So, that all being said, I intend to try to get option 1 to work, (which it almost does). Currently, the PAM authentication against OD already works. I can ssh and log in as OD users on the system all day long. However, what isn't good, is that the user has to do this first before Samba will recognize them as a UNIX user. In other words, until the user successfully connects via SSH at least once, Samba will not recognize their credentials. Furthermore, I don't believe that Samba is seeing the OD groups because trying to limit connectivity to certain shares based on the group names is not working either.

Once the user has logged in one time using SSH, (or when trying to use a standard local user account) Samba accepts their name and password forevermore. Until that happens, it simply rejects them.

The smb.conf file contains these relevant entries:

server role = standalone server
obey pam restrictions = yes
passdb backend = tdbsam
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
guest account = nobody
map to guest = bad user

nsswitch.conf contains these relevant entries:

passwd:         compat ldap
group:          compat ldap
shadow:         compat ldap

.

Seems like there must be a simple fix or work-around to this behavior somehow. Using commands like "getent", "id", "groups", and "passwd" are correctly returning the results and behaviors that I expect. Only smbd seems to have something extra that it needs.

I have had no luck in finding the best way to go about this, and have already spent several days pouring over documentation, web sites, O'Reilly books and experimenting with both scenarios. I've also read through this similar post here. Has anyone been down this road before? Any help is greatly appreciated, including wise UNIX anecdotes and/or moral support.

Thanks!

  • I also ran across this blog post (blog.kamilkisiel.net/blog/2008/06/30/…) and apparently this behavior also happens on Windows servers using pGina to bind to LDAP. Users must first log in to the windows system before it can authenticate the user for file sharing. – quickthyme Nov 14 '14 at 20:51
  • Well, I can't seem to find any help on this whatsoever, anywhere. Which tells me that we must be the only people left in the world using OpenDirectory. – quickthyme Nov 20 '14 at 19:43
  • Does PAM on the samba server require credentials to login or does it use a kerberos ticket granted by the OD when the user logs into their mac? If PAM does not require any sort of interactive login process could you create a login script that creates a ssh connection and immediately terminates it on login behind the scenes? Otherwise maybe a Automator script that the user runs to accomplish the same thing. It would be an extra step but it could be a GUI and branded with your company logo instead of a "scary" terminal window. Im just speculating here. I have not tried this. – digitaladdictions Apr 21 '15 at 19:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.