Ok. Will try it. My userPrincipalName is set to <lotsanumbers&gt;(a)FEDIDCARD.GOV whereas my Kerberos principal is bnordgren(a)DS.FS.FED.US. I suspect this has something to do with two factor authentication. Thanks, Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

Attached. Log contains sssd restart as well as a single login attempt. All I see is "success". Thanks! Changed that too. But for the current test case, I'm using ldap for authentication. Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

I had this problem. Thanks to the SSSD guessing the realm, you can set your ldap_user_principal to the following, and it will append the @realm. ldap_user_principal = sAMAccountName Also, IMO, ignore the suggestions in that link, use the AD provider. Ditch the bind account. id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad Use msktutil to join the pc to the AD domain, or create the krb5.keytab file on your domain controller and move it to the pc running fedora, if you do that, be sure to tell selinux to accept the foreign file. Chris On Wed, Jan 29, 2014 at 3:18 PM, Nordgren, Bryce L -FS <bnordgren(a)fs.fed.us&gt;wrote: -- Intelligence is a matter of opinion.

On Wed, Jan 29, 2014 at 11:14:01PM +0000, Nordgren, Bryce L -FS wrote: Right, so the backend was able to find the user, that's good. Do you still see that the user was not found in the NSS log? Any chance the username as stored in AD could differ in case only from bnordgren? In general I would suggest using case_sensitive=false with AD. Please note that the cache should be removed after flipping the case_sensitive option.

On Thu, Jan 30, 2014 at 01:03:35AM -0800, Chris Gray wrote: With recent enough distributions, I would definitely recommend using realmd for enrollment.

Sorry for the delay. Currently, I'm working around by using nfs3 with sec=sys, making a local account in a password file, and manually matching the UID to the one in AD. I'd like to make the real solution (NFSv4 sec=krb5) work tho. This don't scale too good. :) The NSS log is reporting "User [bnordgren] does not exist in domain [default]! (negative cache)" I set "case_sensitive=false", restarted sssd, did "sss_cache -E" and tried again with same results. The ldap bind succeeded. The ldap search also succeeded (both are the bnordgren user) and returned user attributes. The NSS log reports that I do not exist. (err msg above). Case sensitive=false seems to squash the names (usernames and group names) to lower case. Does it also set some sort of flag on the ldap query to request case insensitive matches? Some groups have uppercase letters. One thing which may be relevant is that our AD does not have gidNumber in it. Not on the user objects and not on the group objects either. Two questions: 1] I note that the group query includes (&(gidNumber=*)(!(gidNumber=0))). How do I turn that off? It will never find any groups that way. 2] Could sssd be silently failing to produce a user entry for me because some attributes are missing in AD? I did turn id_mapping on, so I'd hope that make uidNumber and gidNumber optional. (see snippet below:) ldap_id_mapping = true ldap_idmap_range_min = 20000 ldap_idmap_range_max = 1999999 ldap_idmap_range_size = 20000 Thanks for your help! Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

On Sun, Feb 02, 2014 at 01:30:50AM +0000, Nordgren, Bryce L -FS wrote: I would recommend to remove the cache completely after changing the case sensitivity. It *should* work even w/o wiping out the cache as we use the original name as the RDN in the cache, but since you're still testing the configuration, it might be better to start clean. Normally LDAP searches are case insensitive. Ah, I know what's going on...it's a bug that was fixed in master already: https://fedorahosted.org/sssd/ticket/2172 but not yet released in a tarball. We are finishing with the 1.11.5 release, though, it should be out this week. What I would suggest, though (and what I should have probably suggested from the start) would be using the AD backend: id_provider=ad The AD backend is not hit by this bug. It should work more or less with the defaults, see the sssd-ad man page, but if you had to fine-tune the LDAP parameters (like the ones you used below), that would work, too, as the AD provider is a wrapper around the LDAP provider and uses much of the same code.

On Mon, Feb 17, 2014 at 01:18:36AM +0000, Nordgren, Bryce L -FS wrote: I think this is because the keytab is missing. I think we should do a better job reporting the reason for the failure. Yes, unfortunately you need an account with privileges to join the domain in order to use realmd. The AD provider is more or less a wrapper around LDAP and Kerberos back ends with defaults tailored for AD and leveraging some AD-specific features. The only 'assumption' it makes is the presence of a keytab to use GSSAPI for authenticated searches. However, the keytab doesn't have to be retrieved from the Linux machine itself, the AD admin could also create it on the Windows side and transfer the keytab to the Linux box. The release is in progress, I expect the tarball to be released during today. But please note that AD doesn't allow unauthenticated connections anyway. You'll have to either use a keytab as described above or use bind DN and bind password using ldap_default_bind_dn and ldap_default_authtok. Or ask your AD administrator to allow anonymous binds on the AD side, which is not the default. Yes, use can specify the principal you'd like to use with ldap_sasl_authid. If ldap_sasl_authid is not specified, sssd would try to find the principal in the keytab in any of the most commonly used forms (host$@realm, host/hostname@realm, ...)