samba - Mar 2010 - [PLUG] Ongoing saga with Samba and AD

Ben Love had this to say:
> * Mike Leone wrote on [2010-03-27 22:02:38 -0400]:
>> I tried to log on as "DACRIB+administrator" at the physical
console. I
>> was prompted twice for my password (dunno if that's because my
password
>> has a "!" in it or not). Then it starts to login. I see the
motd. I see
>> it say that it was trying to create a home directory for administrator 
>> in "/home/DACRIB/administrator" - which is exactly what it
should do.
>>
>> Then I am immediately logged out, and returned to a new login prompt.
No
>> other messages on the console, nothing.
> 
> This sounds like a problem with PAM configuration.  I've definitely had
> PAM ask for my password multiple times when I set up things like
> pam_mount and so on.  
I have an idea that it tries to look up the user as local, and fails. 
And then asks again, to authenticate remotely. Maybe one of those 
"use_first_pass" options will help? Or re-ordering the local vs
winbind
lines?
> PAM is probably also responsible for the immediate
> logout.  The /etc/pam.d/common-* files are the most likely culprits.
> (You may also have an /etc/pam.d/login file, but that usually just links
> to the common-* files.)
> 
> Congratualations on getting this far!  You're nearly there.
Almost, almost ...

Here's the auth.log (I added "debug=yes" to pam_winbind.conf, and 
"krb5_auth=yes") on a failed login:

am_unix(login:auth): authentication failure; logname=DACRIB+ldap-proxy 
uid=0 euid=0 tty=/dev/tty1 ruser= rhost=  user=DACRIB+ldap-proxy
pam_winbind(login:auth): [pamh: 0x89f63b8] ENTER: pam_sm_authenticate 
(flags: 0x0000)
pam_winbind(login:auth): getting password (0x00000181)
pam_winbind(login:auth): Verify user 'DACRIB+ldap-proxy'
pam_winbind(login:auth): PAM config: krb5_ccache_type 'FILE'
pam_winbind(login:auth): enabling krb5 login flag
pam_winbind(login:auth): enabling request for a FILE krb5 ccache
pam_winbind(login:auth): request wbcLogonUser succeeded
pam_winbind(login:auth): user 'DACRIB+ldap-proxy' granted access
pam_winbind(login:auth): request returned KRB5CCNAME: FILE:/tmp/krb5cc_10006
pam_winbind(login:auth): Returned user was 'DACRIB+ldap-proxy'
pam_winbind(login:auth): [pamh: 0x89f63b8] LEAVE: pam_sm_authenticate 
returning 0 (PAM_SUCCESS)
pam_unix(login:session): session opened for user DACRIB+ldap-proxy by 
DACRIB+ldap-proxy(uid=0)
pam_winbind(login:setcred): [pamh: 0x89f63b8] ENTER: pam_sm_setcred 
(flags: 0x0002)
pam_winbind(login:setcred): PAM_ESTABLISH_CRED not implemented
pam_winbind(login:setcred): [pamh: 0x89f63b8] LEAVE: pam_sm_setcred 
returning 0 (PAM_SUCCESS)
pam_unix(login:session): session closed for user DACRIB+ldap-proxy

Looks like it *should* be working - it's using kerberos, as I told 
winbind to do; I see "request wbcLogonUser succeeded". I see
"granted
access". Then I see the session closed. :-(

I suppose this means that tomorrow, I concentrate on the 
"common-ssession" parts of /etc/pam.d

>>>> What is the output of `getent passwd $user` ?  I wonder if your
>>>> shell is
>>>> not set to an sh variant.
>>> # getent passwd DACRIB+ldap-proxy
>>> DACRIB+ldap-proxy:*:10006:10012:LDAP Proxy:/home/DACRIB:/bin/false
>>>
>>> I suppose it's that "/bin/false" that's doing it?
How can I change
>>> that, only for my AD domain users? My local Linux users show 
>>> "/bin/bash".
>>
>> So, your logins are successful.  The shell just exits immediately and
>> the user logs out!  It looks like you need "template shell =
/bin/bash"
>> in your smb.conf file.  (At least that's what Google tells me.)
> 
> And it just told me the same. And that works! I was able to login. 
> WooHoo! :-)
> 
> DACRIB+ldap-proxy at workhorse:~$ pwd
> /home/DACRIB/ldap-proxy
> DACRIB+ldap-proxy at workhorse:~$
> 
> So huge progress! 
> 
> Later, I will try other things like login scripts and such. Maybe I will 
>  try to change the smb.conf to not require the domain name; that would 
> be much cleaner. I just left it that way, to make sure the local users 
> and domain users stood out visually from each other. I'm sure there are
> other things to play with. Good practice and knowledge (maybe) for use 
> at work. 
 >
> Thanks everyone for the help.