If you've been following the thread, "URGENT! Windows Server 2003 SP2
broke samba", I would certainly welcome cookbook instructions. For
once I get the current release of Samba built, "the quickest way is too
slow" to get it implemented and back on the air. -Charles
-----Original Message-----
From: Address for list subcriptions <[EMAIL PROTECTED]>
To: Henrik Zagerholm <[EMAIL PROTECTED]>; Justin Ehrlichman
<[EMAIL PROTECTED]>
Cc: [email protected]
Sent: Tue, 26 Jun 2007 9:25 pm
Subject: Samba-AD HowTo Was: RE: [Samba] Can't get single sign on to
work after joining linux toan AD domain
Hi all,
i've just gone through a fairly long and involved troubleshooting
process trying
to do something similar to the problem described below and just as a
general
observation, the documentation available for joining a Samba Server to
an AD
domain tends to be disjointed and difficult to find. The Samba By
Example
doesn't really mention Samba in an AD network at all and the Official
HOWTO is
useful but somewhat limited. Is there an effort underway to bring this
all
together in an AD HOWTO at all?
i would be happy to lend my ignorance to any efforts in that direction
as a pair
of eyes with very little Samba knowledge behind them (i'm a Windows
Admin by
trade). i considered attempting to write it myself but i'm not sure
that my
experience would be sufficient to make a decent job of it.
Perhaps someone from the Samba team could comment, or contact me
regarding
producing an AD integrated Samba HOWTO. As i said, i'm happy to
provide what
assistance i can or if required, to make the attempt on my own at least
to get a
first draft together. i'll warn you though, my drafts may be in MS
Word format
;)
Finally, if i'm missing some critical URL and the doco i'm after is
just sitting
there waiting for me to find it, would someone please point it out?
Please?
Cheers,
m.
Michael Cleghorn
System & Network Administrator
Risk Management Technologies
5 Ventnor Avenue
West Perth WA 6005
AUSTRALIA
Tel: +61 8 9322 1711
Fax: +61 8 9322 1794
Web: www.rmt.com.au
Please Note: The contents of this e-mail transmission are intended
solely for
the named recipients and may be confidential, privileged, or otherwise
protected
from disclosure in the public interest. The use, reproduction,
disclosure, or
distribution of the contents of this e-mail transmission by any person
other
than the named recipients is expressly prohibited. If you are not a
named
recipient please notify the sender immediately.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Henrik Zagerholm
Sent: Wednesday, 27 June 2007 2:49 AM
To: Justin Ehrlichman
Cc: [email protected]
Subject: Re: [Samba] Can't get single sign on to work after joining
linux toan AD domain
First of all that guide is faulty as you need security = ADS and not
Domain.
I think you should look at the Samba By Example or the official How-
To on samba.org
If you then have problems/questions please post them here.
Cheers,
henrik
26 jun 2007 kl. 18:54 skrev 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 [EMAIL PROTECTED]
/
--
Justin Ehrlichman
Computer Technician
Online Stores Inc.
724-925-5600 ext 610
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
www.onlinestores.com
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
________________________________________________________________________
Check Out the new free AIM(R) Mail -- Unlimited storage and
industry-leading spam and email virus protection.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
