[OpenIndiana-discuss] AD Authentication and Samba 4 Active Directory

[Jim Klimov]

17 сентября 2014 г. 16:37:02 CEST, Andrew Martin <amartin at xes-inc.com> пишет:
>----- Original Message -----
>> From: "Marc Jakob" <marc at planet-sun.net>
>> To: "Discussion list for OpenIndiana"
><openindiana-discuss at openindiana.org>
>> Sent: Wednesday, September 17, 2014 6:10:01 AM
>> Subject: Re: [OpenIndiana-discuss] AD Authentication and Samba 4
>Active	Directory
>> 
>> Hi Andrew,
>> 
>> did you put the following in nsswitch.conf:
>> 
>> passwd:     files ad
>> group:      files ad
>> 
>> having joined to my samba4 AD controller ssh login works using putty
>and
>> GSSAPI login (Kerberos token from AD login) using my windows user
>name -
>> which has to exist in passwd or you use ldap client bindings to
>retrieve
>> shell and so on.
>
>Hi Marc,
>
>Yes, I have my nsswitch.conf configured as follows:
>passwd:     files ldap
>group:      files ldap
>
>
>getent passwd <user-in-ad> returns the expected information:
>aduser:x:10000:10004:aduser:/home/aduser:/bin/sh
>
>Moreover, I added the exact lines to /etc/pam.conf as detailed here:
>http://wiki.openindiana.org/oi/Kerberos+and+LDAP#KerberosandLDAP-PAM
>
>When running an sshd instance in debug mode, I am still denied:
>debug2: input_userauth_request: try method keyboard-interactive
>debug1: keyboard-interactive devs
>debug2: Starting PAM service sshd-kbdint for method
>keyboard-interactive
>debug2: Calling pam_authenticate()
>debug2: PAM echo off prompt: Password:
>debug2: Nesting dispatch_run loop
>debug1: got 1 responses
>debug2: Nested dispatch_run loop exited
>debug1: PAM conv function returns PAM_SUCCESS
>Keyboard-interactive (PAM) userauth failed[9] while authenticating:
>Authentication failed
>
>What else should I try?
>
>Thanks,
>
>Andrew
>
>_______________________________________________
>openindiana-discuss mailing list
>openindiana-discuss at openindiana.org
>http://openindiana.org/mailman/listinfo/openindiana-discuss

Disclaimer: i did not integrate like this, but there is a literal discrepancy here: Andrew's snipped does not include "ad" which might be the module responsible for gssapi login processing i might guess.

Try
passwd: files ldap ad
group: files ldap ad

And see if it helps? Maybe in some other order like 'files ad ldap', etc. Google for modifiers like [NOTFOUND=continue] which might also help unite disparate userbases.

HTH, Jim
--
Typos courtesy of K-9 Mail on my Samsung Android