On Sun, Feb 02, 2014 at 01:30:50AM +0000, Nordgren, Bryce L -FS wrote:
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. :)
> 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?
The NSS log is reporting "User [bnordgren] does not exist in domain [default]!
(negative cache)"
> 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.
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).
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.
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.
Normally LDAP searches are case insensitive.
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
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.
ldap_idmap_range_min = 20000
ldap_idmap_range_max = 1999999
ldap_idmap_range_size = 20000