(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.
Kent
============
_Situation:_
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.
_Solution:_
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.
_Samba:_
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:
[global]
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.
_Winbind_:
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.
_PAM_:
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.
Kent
Reply to: