Samba-AD HowTo Was: RE: [Samba] Can't get single sign on to work after joining linux toan AD domain

Wed Jun 27 03:34:10 GMT 2007

I am the author of Samba3-ByExample - so I'll take the bait.

On Tuesday 26 June 2007 20:25, Address for list subcriptions wrote:
> 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 

OK. That suprises me greatly. The second edition - chapter 7, section 7.3.4 
deal specifically with that. What makes you think it does not?

> 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?

You offer to help fix this is most appreciated. Please send me your patches.

> 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.

If nothing else, it will help you to articulate your problem so that we can 
understand what may be missing from the current documentation.

> 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  ;)

Yuck! What a sordid choice! Not even OpenOffice? ;-)

> 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?

I thought I did.

- John T.

> 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: samba-bounces+lists=rmt.com.au at lists.samba.org
> [mailto:samba-bounces+lists=rmt.com.au at lists.samba.org]On Behalf Of
> Henrik Zagerholm
> Sent: Wednesday, 27 June 2007 2:49 AM
> To: Justin Ehrlichman
> Cc: samba at lists.samba.org
> 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 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
> >
> > --
> > 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

-- 
John H Terpstra
Samba-Team Member
Phone: +1 (650) 580-8668

Author:
The Official Samba-3 HOWTO & Reference Guide, 2 Ed., ISBN: 0131882228
Samba-3 by Example, 2 Ed., ISBN: 0131882221X
Hardening Linux, ISBN: 0072254971
Other books in production.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba/attachments/20070626/5aaa4e6e/attachment.bin