[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

(LONG) SOLVED (Mostly): Samba, PAM, Authentication off an NT Domain

Some months ago I asked the list how to get a Linux box to validate users off an NT Domain. Yuri got me real close, and for the record, I'm posting what worked for me in more detail.



A university setting, with computer labs where students sit down at a PC running Windows and log in using their personal NT Domain login account. We have two domains: ACU (for staff/faculty), and ACU-ACADEMIC (for students). ACU is the primary domain; phoebe is the PDC for that domain.

I wanted to have dual-boot machines (Win2K/XP and Debian), and let the students log into either OS with their NT Domain accounts. I was pretty sure it was possible, but in two and a half years of on-again/off-again attempts, had never been successful.

I found two or three helpful pages on the web, but none solved my problem. The only link I currently have is: http://ftp.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html. "man winbindd" was also quite helpful.


There are three broad areas of setup that have to be accomplished: Samba, Winbind, and PAM. Strictly speaking, winbind is a part of the samba suite, but I consider them separate components, which makes troubleshooting easier.

First, we start with a normal install of Debian Woody.


Then we need to get Samba configured. "apt-get install samba samba-common smbclient smbfs". I'm not sure which of these pieces are necessary and which aren't, but they're what I have installed on my working machine.

Then edit /etc/samba/smb.conf. I simplified mine so that I can see it better and remove any unneeded complications. Here's what mine looks like:

  workgroup = ACU
  server string = %h server
  security = domain
  encrypt passwords = true
  password server = phoebe
  log file = /var/log/samba/log.%m
  max log size = 1000
  socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
  os level = 18
  local master = No
  dns proxy = no

Notice that the workgroup line needs to be set to your NT Domain name. For me, this could be "ACU" or "ACU-ACADEMIC". I chose "ACU" since it gives me access to both domains, whereas if I had used "ACU-ACADEMIC" I would have been limited to access in the ACU-ACADEMIC domain, because of the trust relationships set up between the two by our NT Domain sys administrators.

Also, some of the documentation I've seen has the line "password server = *", but if I remember correctly, I had no success with that until I changed it to point specifically to our Primary Domain Controller (PDC), phoebe.

Then you'll need to restart samba ("/etc/init.d/samba restart"), after which you should be able to mount some domain share. For example, in your home directory create a directory named netShare or something similar ("mkdir netShare"). Then mount your domain share with a command like "smbmount //servername/sharename netShare". If your Linux username is different than your NT username, you'll need to specify that with a command like "smbmount //servername/sharename -o username=myNTaccountName".

If you then can see the shared files in your netShare directory, you've successfully set up Samba.


Now we need to set up winbind. This service allows your machine to "see" the users and groups on your NT Domain. Before installing winbind, run the command "gentent group" and/or "getent passwd". These commands should basically list the information in your local /etc/group and/or /etc/passwd files. After installing winbind, these commands should also list the same sort of information from your NT Domain.

"apt-get install winbind"

Now add the following lines to the end of the simplified /etc/samba/smb.conf file I listed above:

  winbind uid = 10000-20000
  winbind gid = 10000-20000
  template shell = /bin/bash
  winbind separator = +
  template homedir = /home/%D/%U

We'll also need to tell the system to look first at the local files (/etc/passwd and /etc/group), and then to the NT Domain whenever it's looking for account information. This is done in the /etc/nsswitch.conf file. Here's mine:

passwd:         files winbind compat
group:          files winbind compat
shadow:         winbind compat

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Probably the only difference you'll see from the default file in Woody is the changes to the first three lines.

Then restart winbind (/etc/init.d/winbindd restart).

You'll then need to add this machine to the NT Domain. Between Woody and Sid, there's a major change in Samba. The older command to do this is "smbpasswd -j <DOMAINNAME> -U <DOMAINADMINACCOUNT>". For me, this command was "smbpasswd -j ACU -U Administrator"; I was then prompted for the domain Administrator's password, and then got a message saying that the machine had been added to the domain. The newer command is "net rpc join -U <DOMAINADMINACCOUNT>". I haven't had success yet with the Sid version, but will probably try in the next day or two.

Now run the "getent group" command and you should see info from your NT domain appear as well as the local group info.

Notice that my subject of this email is "Solved (Mostly)". I haven't gotten the home directory stuff figured out yet. When a user logs in, the error is generated that the home directory doesn't exist and that / will be used as the home directory. Hopefully I can get that solved in the next day or two.


Wow. This was the difficult part. Before you start, make a backup of your "/etc/pam.d/login" file, and never log out of a root-accessible account after making changes to this file without testing them first, or you could lock yourself out of your machine.

First, a short PAM tutorial.

In the old days, the "login" program that allowed you to login to a system had to know how to ask your name and password, and then where to look to see if that was a valid name and password, and what to do if it was or if it wasn't, and etc etc etc. The problem with this information being hardcoded into the login program (or any other similar type program), is that it wasn't very flexible, and if something happened externally, like the location of the username/password database changed, the login program had to be rewritten to accomodate that change.

Nowadays, the login program doesn't need to know all that. The login program knows it's supposed to ask for a username/password, and if everything is copacetic, let the user in. But it asks PAM to take care of the menial details.

PAM does this for lots of apps, not just the login app. It does it for ftp logins, and ssh logins, and password change routines, and database access, and etc etc. PAM knows what to do for what app because of its configuration files that the sysadmin has set up.

The old configuration file for PAM was /etc/pam.conf. However, since that's the old method, we don't care about it and will just ignore it. (Your fresh Woody install has the file, but it's all commented out probably.)

The new configuration method is separate files for each app in the /etc/pam.d directory. Since we're interested in the basic login procedure, and not the ssh login, etc, we'll only be tinkering with the /etc/pam.d/login file.

Again, make a backup of this file. Now.

There are a lot of comments in this file, but they got in the way of me "seeing" the file, so I've removed all the comments, which results in the following:

auth       requisite  pam_securetty.so
auth       requisite   pam_nologin.so
auth       required   pam_env.so
auth       required   pam_unix.so nullok
account    required   pam_unix.so
session    required   pam_unix.so
session    optional   pam_lastlog.so
session    optional   pam_motd.so
session    optional   pam_mail.so standard noenv
password   required   pam_unix.so nullok obscure min=4 max=8

As you can see, it's actually a pretty simple file.

There are four basic "module-types": auth, account, session, and password. And there are four basic "control flags": required, requisite, sufficient, and optional. The third field ties these things into library files, found in /lib/security, followed by any options that need to be passed to the library files.

When the login process is initiated, it needs to authenticate the user (who are you? what's your password? what is the air-speed velocity of an unladen swallow?). There are several tests involved in this authentication. Some of the tests are handled by the "pam_securetty.so" library; some are handled by the "pam_nologin.so" library, and so on.

The "requisite" flag means that the test must be successfully passed. If the test is not passed, the applicant fails, and further processing of the file ceases. We toss the poor guy over the bridge immediately into the Gorge of Eternal Peril.

The "required" flag also means that the test must be successfully passed. The difference from "requisite" is that if the test is not passed, the applicant will eventually fail, but we're going to continue processing the rest of the tests in the file before tossing the poor guy over the bridge.

A "sufficient" flag means that if the test is passed, the applicant passes. No need for further questions. Just let the guy cross the bridge successfully.

An "optional" flag means that the Keeper of the Bridge of Death doesn't care whether the applicant passes the tests or not. The Keeper has to perform the tests and report the answers to the proper authorities, but the Keeper doesn't care one way or the other if the applicant passes the tests or not, and doesn't reward or punish the applicant. It's kind of like those math tests you took at the beginning of your senior year in high school; it's not for a grade, we just want to see what you remember from last year's math classes.

So, looking at the above file, the first thing that happens is that pam_securetty.so does its tests. If any of its tests fail, the whole process returns a big fat "FAILURE" to the login process, and further processing of the login file stops. However, if all of its tests pass, it puts a checkmark next to the "PASSED" checkbox and turns further processing on to the next test giver.

The next test giver is pam_nologin.so. Since its flag is "requisite", it behaves like pam_securetty.so did.

BTW, if you want to see pam_nologin.so in action, create the file "/etc/nologin", with contents something like "Sorry; the sysadmin has disabled all non-root logins. Please try later" and then try logging into another VT as a normal user. To restore normal logins, just delete (or rename) the /etc/nologin file.

Then comes the required tests. If one of these tests fail, the whole process returns a big fat "FAILURE" to the login process, but instead of stopping the testing procedures, PAM still continues to process the rest of the file.

After all the authentication tests are run, then the session tests begin. The session tests do such things as setting up audit trails and mounting home directories.

Then come the password tests. I didn't quite wrap my brain around this set. Perhaps you can get more out of a "man pam".

The tests are not performed in order by the type necessarily; they're performed by the order in which they appear within the file. It's just a coincidence that they're grouped that way in the above listing.

_End of Tutorial_:

_Changes to PAM_:

To make PAM check the NT Domain for authenticating users instead of just the local files, we need to change some stuff in the /etc/pam.d/login file. Here's my new file, along with some comments:

# These two tests must pass.
auth       required   pam_securetty.so
auth       required   pam_nologin.so

# If this test passes, user is an NT Domain user and is valid. Exit
# the process with a "PASS".
auth	   sufficient pam_winbind.so

# If the above test failed, check to see if the user is a valid local
# user. (Don't ask for the password again.)
auth       required   pam_env.so
auth       required   pam_unix.so nullok use_first_pass

account    sufficient   pam_winbind.so
account    required   pam_unix.so

session    required   pam_unix.so
session    optional   pam_lastlog.so
session    optional   pam_motd.so
session    optional   pam_mail.so standard noenv
password   required   pam_unix.so nullok obscure min=4 max=8

You'll notice that the only changes are the addition of the two lines referencing pam_winbind.so and the addition of the "use_first_pass" option to one line. Without this option, if the pam_windbind.so auth line fails, the user is prompted a second time for his password. Try it to see for yourself.

_The Smoke Test_:

Now it's time to see if it all works.

Switch to a different VT and try to log in locally as you've been doing. It should work.

Now log out, and try logging in as a domain user. Because of the "winbind separator" line in /etc/samba/smb.conf, you'll need to log in like so:

login: acu+westk
password: <password>

If all went well, you've gotten access! Yea!

Now to get the home directory stuff fixed.


Reply to: