[Samba] Can't get single sign on to work after joining linux to an AD domain

[Justin Ehrlichman]

Hi all,

I am trying to join PClinuxOS 2007 to an Active Directory domain, I was 
able to get it to join following a guide  off of Linux Magazine's 
website. I can't post the URL because you need to be registered to view 
the article so I have taken the liberty of copying and pasting the 
article at the end of this message. Anyways what is happening is while I 
was able to get linux to "join" the domain, I am still unable to sign 
onto the linux box with one of the domain user accounts.  When I do an 
wbinfo -g I am able to see all the domain groups. I am also able to view 
all the users using the -u switch. We are running Windows Server 2003 
R2, I would post log files but I am not exactly sure where or what to 
look for.
Here is the copy of the article as promised:

/Listing One: smb.conf options for Winbind

workgroup= MYWG

security= Domain

encrypt passwords= Yes

password server= 192.168.1.1

winbind use default domain= Yes

idmap uid= 2000-25000

idmap gid= 2000-25000

template shell= /bin/bash

template homedir= /home/% U

The first four lines in Listing One are fairly straightforward, and 
might appear on any Samba server on the network. They set the 
workgroup/domain name, tell Samba to use domain-level security, enable 
encrypted passwords, and specify the password server system (that is, 
the domain controller). The remaining lines in this listing set 
Winbind-specific options.

*The idmap uid and idmap gid options set the range of UID and GID 
numbers that Winbind (its NSS components, specifically) may assign. 
These UID and GID values should not be used by local users, but you can 
change them from the values set in Listing One, if you like. These 
options are necessary because NT domain controllers don't maintain 
Linux-style UID and GID numbers, so Winbind must make these values up 
itself.

*The template shell and template homedir options set the default shell 
and home directory. The %U in the latter option stands in for the 
username. As with idmap uid and idmap gid, these options are necessary 
because NT domain controllers don't maintain the information.

While you've now told your Linux system how to find the domain 
controller and manage accounts, you must still join the domain --- that 
is, notify the domain controller about the new member. This can be done 
using the net command:
# net join member --U adminuser

When you type this command, adminuser is the username of an 
administrative user on the domain controller. On Windows systems, this 
is likely to be Administrator. On domain controllers that use Linux and 
Samba, it could be something else, so check your domain controller 
configuration. Samba domain controllers may also need a machine trust 
account that's been prepared on the domain controller itself. (Samba 
domain controller configuration is well beyond the scope of this article.)

Running the Daemon

At this point, you can start running the Winbind daemon, winbindd:
# /usr/sbin/winbindd --i

This command runs the daemon and (because of the --i option) sends log 
information to standard output rather than to a log file. Launching the 
daemon in this way works well for testing, but in the long term, you're 
better off putting this command (without the --i option) in a startup 
script. In fact, if you installed Winbind from a Linux package, it 
should have come with a System V- like startup script to start Winbind, 
so look for such a script and use your distribution's System V package 
management utilities (such as chkconfig or rc-update) to activate it in 
your default runlevel.

The Winbind daemon manages the actual connection to the domain 
controller. PAM and NSS then consult this daemon to do their jobs. You 
can check basic operations using the wbinfo command. The --t option 
causes this program to check the basic connection of Winbind to the 
domain controller. It should return a message like this:
$ wbinfo --t
checking the trust secret via RPC calls
succeeded

You can also use the --u option to obtain a list of accounts managed by 
the domain controller. If one or both of these calls fail, review your 
configuration and consult your log files for clues about what's going wrong.

Configuring PAM

PAM is controlled through files in /etc/pam.d/. For the most part, these 
files control how specific programs interact with PAM.

For instance, /etc/pam.d/login tells the login program how to use PAM. 
These configurations vary greatly from one distribution to another, but 
they all consist of a series of stacks --- auth, account, session, and 
password. Each stack consists of one or more lines that begin with the 
relevant keyword. Each stack manages a particular sub-task, such as 
authentication (auth) or verifying account accessibility (account).

Modifying a PAM configuration to include a new authentication tool, such 
as Winbind, is a matter of adding lines to one or more of the auth and 
account stacks, and possibly modifying other lines. Listing Two shows a 
typical PAM configuration file with Winbind support added. New lines or 
amendments to existing lines are highlighted in bold.
Listing Two: A typical PAM configuration file with Winbind support
auth requisite pam_securetty.so
auth requisite pam_nologin.so
auth required pam_env.so
B
auth required pam_unix.so nullok B
account requisite pam_time.so
B
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 min=6 max=255 md5

This configuration adds lines to the auth and account stacks, inserting 
a call to pam_winbind.so just before a call to pam_unix.so. These calls 
are marked as sufficient, meaning that if Winbind gives its OK, 
subsequent modules need not succeed. This is very important when 
combining multiple authentication tools, such as Winbind and pam_unix.so 
(which is the standard tool that validates users against /etc/passwd and 
/etc/shadow).

Other modules called in these stacks don't actually verify passwords; 
instead, they perform additional checks, such as verifying that root 
isn't logging in via telnet. You might optionally want to add another 
line to the end of the session stack:
session required pam_mkhomedir.so
skel=/etc/skel umask=0027

(This line has been split for publication purposes, and should be 
recombined into a single line if you add it.) This automatically creates 
a home directory for the user if one doesn't exist. This can be handy if 
you want users to be able to log into the Linux system without your 
having to manually create home directories for them.

On some distributions, you must change the PAM configuration files for 
all of the services that you want to use Winbind. For instance, if you 
want to use domain accounts for text-mode console logins, logins via the 
GNOME Display Manager (GDM), for X screensaver password prompts, and for 
POP mail retrieval, you would have to modify the login, gdm, 
xscreensaver, and pop files in /etc/pam.d/. This can be tedious, so some 
distributions use a module called pam_stack.so instead of pam_unix.so. 
The pam_stack.so module calls an entire stack of PAM modules itself, as 
specified in the file defined by the service= option to this module 
(typically /etc/pam.d/system-auth). The end result is that, if your 
system uses pam_stack.so, you can probably modify system-auth rather 
than all of the other files. This can be a great time-saver, but if you 
want to use Winbind for some services but not others, you'll still have 
to modify the individual files.

One service requires a special note: passwd. This service (and its 
/etc/pam.d/passwd configuration file) controls how the passwd command 
interacts with PAM. For a Winbind configuration, it's probably best to 
leave this configuration alone. Users can then use the passwd command to 
change their local passwords (if they exist), and use smbpasswd to 
change their passwords on the domain controller. Alternatively, if you 
add a call to pam_winbind.so to the password stack, then the passwd 
command changes the password on the domain controller.

If a server or other program is running, you may need to restart it 
before you can use any new authentication tools you've defined in PAM. 
In the case of many login tools, logging in and then logging out again 
does the trick. You may need to restart some servers via their startup 
scripts, though.

Configuring NSS

At this point, your system should be able to use the NT domain 
controller for authenticating users; however, they must still have 
accounts defined locally, in /etc/passwd and /etc/shadow. Thus, 
implementing this system isn't likely to save a lot of effort.

The final step is to link NSS to Winbind. You can do this by editing the 
/etc/nsswitch.conf file. Look for two lines in this file that begin with 
passwd and group, and add the string winbind to these lines. These two 
lines are ordinarily separated by one called shadow, but you don't 
modify that line. The result might look something like this:
passwd: files winbind
shadow: files
group: files winbind

Some distributions use other options instead of or in addition to files; 
compat is one popular alternative. The key is to add winbind to the 
passwd and shadow lines, rather than use precisely the configuration 
shown here.

When you're done with this, NSS will use both its original configuration 
and Winbind for the purposes for which /etc/passwd and /etc/shadow are 
normally used. This will enable you to use your normal Linux-only local 
accounts and groups, such as root and any users you want to define 
locally, without the help of the domain controller.

While you're modifying /etc/nsswitch.conf, you might want to change one 
other line: hosts. This line tells the system what tools to use to 
resolve hostnames. If you add wins to this line, Linux will use NetBIOS 
name resolution methods in addition to any other methods (such as 
/etc/hosts and DNS). The order of items on this line defines the order 
Linux uses.

For instance, you might end up with a line like this:
hosts: files wins dns

This configuration isn't strictly necessary, and it requires its own 
library (libnss_wins.so, installed much like libnss_winbind.so, as 
described earlier). Still, it can be handy if your system is running on 
a network that uses NetBIOS names locally and you don't want to maintain 
all your local names in /etc/hosts or run a local DNS server.

You needn't restart anything to have NSS begin using the new 
configuration you've specified in /etc/nsswitch.conf. You may want to 
check that the NSS portion of the configuration is working by using 
getent. This command returns information on user and group database 
entries. In particular, typing getent passwd returns user information, 
and getent group returns group information. On Linux systems with 
default configurations, these commands' outputs are similar to what 
you'd get by typing cat /etc/passwd or cat /etc/group. On a system with 
a working Winbind NSS configuration, you should see the contents of 
these files plus accounts maintained by the NT domain controller. If you 
don't see these accounts, review your configuration and consult your log 
files (on both the Linux system and the domain controller) for clues.

Testing the Configuration

At this point, everything should be working, and you should have tested 
the Winbind and NSS subsystems. To test PAM and everything else, you 
should try an ordinary login using a domain account --- that is, one 
that's defined on the domain controller but not on the local system. You 
can do this via whatever login methods you chose to configure in PAM, 
and in fact you should test all of these login methods, to be sure 
there's not a problem with some of them but not others.

Be sure to test both valid and invalid logins, that is, correct 
usernames and passwords, correct usernames and incorrect passwords, and 
incorrect usernames. Some configurations will enable anybody to log in, 
using correct or incorrect passwords. Presumably that's not what you 
want to do! You should also test your local accounts while you're at it 
--- some types of configurations will disable those accounts, but you 
should leave them enabled. If nothing else, root should be defined 
locally, not via the domain controller.

Roderick W. Smith is the author or co-author of over a dozen books, 
including Linux in a Windows World and The Definitive Guide to Samba 3. 
He can be reached at rodsmith at rodsbooks.com.
/
-- 

Justin Ehrlichman

Computer Technician

Online Stores Inc.

724-925-5600 ext 610

Justin.ehrlichman at onlinestores.com 
<mailto:Justin.ehrlichman at onlinestores.com>

www.onlinestores.com