[15.04.2013 01:06] [lynn]:
On 14/04/13 17:15, Werner Flamme wrote:
[14.04.2013 14:01] [Anton Aylward]:
lynn said the following on 04/14/2013 04:19 AM:
I believe that the enumerate line should allow me list all domain users too. Is it possible to get all the objects listed always with getent under sssd?
/etc/nsswitch.conf passwd: compat sss group: compat sss This isn't my area of expertise so this is just a guess. Isn't there a 'necessary and sufficnet' thing here? You've listed 'compat' first, so isn't a query going to try local frst? You don't have a qualifier on that to say what happens on failure.
Do you really want local to have priority over sss? Do you want the priotity to be this absolute and unqualified?
* maybe there needs to be a "[NOTFOUND=continue]" qualifier * maybe 'compat' isn't the right thing to use there
This isn't my area of expertise so this is just a guess. The mentioned entries in /etc/nsswitch.conf are made by YaST. And yes, you might really "want local to have priority over sss", and if it is simply because of the local root user...
In YaST, you also have a checkbox whether you want to list entities or not. For me, checking the box made no differencies, I never had remote users appearing on "getent passwd".
Hovever, "getent passwd $remoteusername" worked as usual.
When I changed "compat sss" to "compat ldap", I got the long list (> 2k users). So this should not be an issue with "compat", but related to "sss".I'
I removed sssd from my box, and configured everything manually (for ldap) as I did before. Authentication against LDAP never worked with sssd, with or without enabled TLS. And I did not read about a working sssd against a (remote) LDAP server yet.
Regards, Werner Hi everyone Thanks for the input and ideas. I'm getting closer by the post. In fact it's just about there. Your notes about local users are valid and indeed it makes sense on the client to reverse the order of nsswitch to specify sss before compat (or files, I can't see any difference between specifying either files or compat) as the only local user ever to log in on the clients is root. Everything else comes from AD ldap.
@Werner. I don't think tls has anything to do with authentication (but tell me otherwise). Isn't it just scrambling the signal over the network?
No, it shouldn't. Yes, it is. :-) In 12.2, it was a hassle to convince sssd to work without TLS, but that might be related to YaST's interface.
Maybe you were using an old version of sssd? What is old? I use the version from 12.3 distro repo. Before, I used the version from 12.2, and did not see any positive changes.
A self signed certificate? Yes and no. Our corporate CA is certified by "Deutsche Telekom Root CA 2", which is known in most Browsers (and TB).
It works more or less out of the box with AD. I agree that authentication by a user DN and plain text password in a 0600 protected file is a bit like going back in time but with the sssd shipped with 12.3, you can use GSSAPI for access to LDAP. The advantage is that the keytab you need is created when you join the AD domain. The Kerberos module looks after the rest. Our only remaining gripe is that only single users or groups can be pulled with getent; getent passwd returns nothing except /etc/passwd but getent passwd lynn2 returns the single entry for the lynn2 object.
I have to use our (Sun One) LDAP server instead of the AD LDAP - company policy :-\ At least, the LDAP server allows binds with the name and password of the authenticating user, and does not require any fixed authentication account.
So, not exactly what we want, but something we can live with. I'll take this over to the Fedora/sssd list and report back here if there are any developments.
Good luck :-) Werner -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org