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

Tue Jun 26 18:48:57 GMT 2007

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