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: [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 -- 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.
pgpBlAE9uhJXk.pgp
Description: PGP signature
-- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
