On Wed, Oct 17, 2012 at 07:41:45PM +0000, Joshua C. Endries wrote:
I'm trying to set sssd up so that I use a local passwd file for accounts and Kerberos
for authentication, until AD is set up with the correct attributes (which will be a
while). I have Kerberos working via krb5.conf, and LDAP sort of works via ldap.conf
(except the important parts) but I will need to switch to SSSD eventually. I was hoping to
get this going now with local accounts to make things easier down the road. This is on
RHEL 5 right now. I'm hoping 6 isn't much different.
I'm having some trouble (shocker!) so my first question is: is this configuration
your configuration is not the most typical setup, but it *should* work..
That said, it's not something we typically test, so there might be
My sssd.conf is pretty basic so far:
config_file_version = 2
domains = DEFAULT
services = nss, pam
auth_provider = krb5
id_provider = proxy
proxy_lib_name = files
krb5_server = kerberos.foo.com
krb5_realm = IT.FOO.COM
These are some of the errors I'm seeing:
[sssd[pam]] [sss_dp_get_reply] (4): Got reply (3, 19, Initgroups call not supported) from
[sssd[pam]] [pam_check_user_dp_callback] (2): Unable to get information from Data
[sssd[pam]] [pam_check_user_search] (4): Requesting info for [jce54@DEFAULT]
[pam_check_user_search] (2): No matching domain found for [jce54], fail!
sshd: pam_sss(sshd:auth): received for user jce54: 10 (User not known to the
underlying authentication module)
This suggests to me that it's not talking with NSS somehow...
Yep, pam_sss claims it doesn't know the user.
Is "sss" included on the "passwd" and "group" lines of
Does "getent passwd -s sss jce54" work?
Which SSSD version are you running? The one from stock RHEL5? (I suspect
so, because of the decimal debug levels..)
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_sss.so use_first_pass
#auth sufficient pam_krb5.so use_first_pass
auth required pam_deny.so
#account sufficient pam_ldap.so
account required pam_unix.so broken_shadow
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
#account [default=bad success=ok user_unknown=ignore] pam_krb5.so
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password sufficient pam_sss.so use_authtok
#password sufficient pam_krb5.so use_authtok minimum_uid=1000
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session sufficient pam_sss.so
session required pam_unix.so
Your PAM stack looks OK to me..
I read in one of the man pages I think that sssd will append the krb5_realm to the
username if there isn't a domain there, and I'm logging in with jce54, so it
*should* I think use jce54(a)IT.FOO.COM, but doesn't appear to do anything Kerberos-wise
so maybe that's not an issue (yet).
Yep, by default the principal is constructed as user@REALM. As you said,
the issue seems to be in the Name Service Switch.
Interestingly enough, I tried the same configuration locally and I'm
getting an error as well -- but a different one.. I'll try to debug the
issue and report back.