So we've been trying to get SSSD working with AD on RHEL 6 for about a week now. we've been trying to following http://www.redhat.com/resourcelibrar...tive-directory

We can get configuration number 6.4 kerboros/ldap working just fine and SSH with that, but we want option 6.3 SSSD/kerboros/ldap for the caching features.

When 6.3 option is enabled, we can do a ldapsearch just fine with
ldapsearch -Y GSSAPI -N "(sAMAccountName=username)"

It's when we try to SSH on the server is when we are unable to get it to work. We do ssh -vvvv username@servername and get a permission denied when we do the password

In /var/log/messages we get:
GSSAPI Error: Unspecified GSS failure. Minor code may prove more information (Matching credential not found)

In /var/log/secure, we get:
Invalid user username from ipaddress
input_userauth_request: invalid user username
pam_unix(sshd:auth): check pass; user unknown
pam_unix(sshd:auth: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=servername
pam_succeed_if(sshd:auth): error retriving information about user username
Failed password for invalid user username from ipaddress port portid SSH2

Here is the /var/sssd/sssd.conf file:
[sssd]
services = nss, pam
config_file_version = 2
debug_level = 9
domains = default

[nss]

[pam]

[domain/default]
enumerate = false
id_provider = ldap
chpass_provider = krb5
ldap_uri = ldap://ldapservername.domain.domain.domain
ldap_search_base = dc=domain,dc=domain,dc=domain
ldap_user_search_base = dc=domain,dc=domain,dc=domain
ldap_group_search_base = dc=domain,dc=domain,dc=domain
ldap_id_use_start_tls = true
ldap_schema = rfc2307bis
ldap_sasl_mech = GSSAPI
ldap_force_upper_case_realm = true
ldap_krb5_keytab = /etc/krb5.keytab
ldap_sasl_authid = host/servername.domain.domain.domain@DOMAIN.DOMAIN.DOMAIN

auth_provider = krb5
cache_credentials = true
krb5_realm = DOMAIN.DOMAIN.DOMAIN
krb5_server = ldapservername.DOMAIN.DOMAIN.DOMAIN
krb5_ccachedir = /tmp
krb5_auth_timeout = 15

ldap_user_object_class = user
ldap_user_modify_timestamp = whenChanged
ldap_user_home_directory = unixHomeDirectory
ldap_user_princical = userPrincipalName
ldap_user_name = sAMAccountName
ldap_user_shell = loginShell
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber
ldap_group_object_class = group
ldap_group_modify_timestamp = whenChanged
ldap_group_name = sAMAccountName
ldap_group_gid_number = gidNumber

krb5_kpasswd = ldapservername.domain.domain.domain

access_provider = ldap
ldap_access_order = expire
ldap_account_expire_policy = ad
ldap_tls_cacertdir = /etc/openldap/cacerts
ldap_disable_referrals = true

[sudo]

[autofs]

[ssh]

I've tried changing around access_provider to simple or permit and it didn't work. I tried added ladp_access_filter to allow my id and it didn't work. I modified the sssd.conf file based on another one I found at zews.org/rhel6-active-directory

Here is the password_auth file:
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 required pam_deny.so

account required pam_unix.so broken_shadow
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so

password requisite pam_cracklib.so try_first_pass retry_3 type=
password sufficient pam_unix.so shadow nullok try_first_pass use_authtok
password sufficient pam_sss.so use_authtok
password required pam_deny.so

session optional pam_keyinit.so revoke
session required pam_limits.so
session optional pam_oddjob_mkhomedir.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_sss.so

nsswitch.conf has the following:
passwd: files sss
shadow: files sss
group: files sss


At a loss right now on what configuration we are doing wrong that works with option 6.3. We have a working key tab for kerboros. We know we can see AD with ldapsearch. We just can't get it to work with SSSD and SSH.

Oh and we use SSSD 1.8.0-32 which comes in RHEL 6.3

Hi,

I have what looks like exactly the same issue, so if you find the fix please post it!

Thanks

Jerry

Hi,

I am also facing the same issue. user in AD not detected from linux inspite of all the right configuration.
Looks like I am not able to bind to the AD,

Regards

GTK

Could you add 'debug_level = 9' to the [domain/default] section and restart SSSD?

Then attempt to log in and copy the contents of /var/log/sssd/ldap_child.log or /var/log/sssd/krb5_child.log (whichever appears to show errors) in here.

The message
GSSAPI Error: Unspecified GSS failure. Minor code may prove more information (Matching credential not found)

suggests to me that the user you're logging in as probably has an incorrect value for the krbPrincipalName attribute in LDAP. If this attribute exists on the user, we will attempt to do the kinit using its value as the principal. Otherwise, we fall back to guessing that '<username>@<krb5_realm>' will probably work.

The other possibility is that you're hitting a case-sensitivity issue. When working with AD on SSSD 1.8.0 and later it's best to set 'case_sensitive = false' in the [domain/default] section as well. (Note, changing this attribute requires deleting /var/lib/sss/db/cache_default.ldb or it doesn't take effect).

I hope that gives you enough information to start with. Also, if you want access to a wider set of SSSD experts, consider subscribing to https://lists.fedorahosted.org/mailm...nfo/sssd-users

I added debug to domain/default. I added case_sensitive = false as well and deleted the cache_default.ldb. krb5_child.log gives me nothing. But ldap_child.log gives me the following:
[unpack_buffer] (0x1000): total buffer size 94
[unpack_buffer] (0x1000): realm_str size: 15
[unpack_buffer] (0x1000): got realm_str: DOMAIN.DOMAIN.DOMAIN
[unpack_buffer] (0x1000): princ_str size: 47
[unpack_buffer] (0x1000): got princ_str: host/server.domain.domain.domain@DOMAIN.DOMAIN.DOMAIN
[unpack_buffer] (0x1000): keytab_name size = 16
[unpack_buffer] (0x1000): got keytab_name: /etc/krb5.keytab
[unpack_buffer] (0x1000): lifetime: 86400
[ldap_child_get_tgt_sync] (0x0100): Principal name is: [host/server.domain.domain.domain@DOMAIN.DOMAIN.DOMAIN]

That's it. The AD side sees that we are doing the query and doesn't see anything on their end in terms of errors and such.

I have a URL that gave me a fix but I can't post it here just yet.

Try setting krb5_canonicalize = false in the domain section of your sssd.conf and see if that fixes the issue for you. It did for me though I'm not sure of the ramifications of running with this configuration at this point.

---------- Post added 11-08-12 at 03:58 PM ----------

Now that I've posted a message I think I can post a url. Here is a patch and a deep description of what I appear to be seeing: http://www.digipedia.pl/usenet/thread/19253/9413/

I did some more testing last night, removing "ldap_force_upper_case_realm = true" also worked.

Neither commenting out ldap_force_upper_case_realm or krb5_canonicalize = false worked.

We did manage to get it working through a workaround, but it is not a proper solution for us. We basically commented out ldap_sasl_mech GSSAPI and its keytab file and add a ldap_default_bind_dn to one of my coworkers username and password. That made it bind to AD with a user instead of GSSAPI. SSH worked then just fine. However, we don't want to keep using his username and password on all our servers so we want to still try for GSSAPI. In the end, we may just create a basic id for this that has no access to anything, but can authenticate with AD. Not the best way to go about it though.

What would cause GSSAPI issues with SSSD? bad keyfile? or is it just not working with 1.8.0-32 and we need to upgrade that version? Just weird that GSSAPI works fine with ldapsearch, but not sssd.

That worked at home but at work I needed the "ldap_force_upper_case_realm = true" option at my work test domain but not on my home domain... I'm not sure what that's about.

If the keytab file were bad I would expect ldapsearch to not work. Everything really indicates that the service principal isn't canonicalized properly. Try setting debug level = 0x0FF0 in the domain section of sssd.conf and see if you can find the service principal used from the ldap_child.log. Remember case is VERY important.

No new information in ldap_child.log. Didn't show the service principal unless it is one of the line that I posted above. I did a klist and the service principal that is default is the same as in ldap_sasl_authid.

Actually, I accidentally had TLS on and that caused some other errors. but canonicalize = false worked!!!!

We are going to do a full rebuild and make sure we have this written all done for production sometime next week. Thank you very much for your help!