Configure LDAP client in FC13

[hmg22]

BS"D

We have several FC machines (from 6 to 12) that use an OpenLDAP server running on Centos 5.4 for authentication. I have now tried setting up a FC13 workstation. I notice that the authentication GUI has changed and wants me to use Kerberos or a TLS enabled server.
Is there a way to get FC13 to behave like FC12 in this respect. Or (less desirable) what changes do I have to make to the server to accommodate FC13?

The workstation knows who the users are, but will not authenticate if they try and log in.

There is a thread about this from bkedelen
http://forums.fedoraforum.org/showth...+can%27t+login

but it didn't work for me

Thanks for any help

HMG

[smr54]

Try authconfig-tui. RedHat and Fedora keep changing LDAP with undocumented, or poorly documented changes--for example, the update to RHEL 5.5 broke LDAP with TLS or SSL.

You don't give enough information about what's broken. Does the server use TLS or SSL or nothing? You shouldn't have to make changes in the server.

I have a page that covers this at http://home.roadrunner.com/~computertaijutsu/ldap.html (See the part about configuring the client.). I use it on F14 (and used it on F13) with TLS, have used it with SSL, and also just plain old LDAP. (Hrrm, could that be called POLDAP?)

[hmg22]

BS"D

Thanks for your response. I have started to look at your page. In the meantime, in response to your query, the server does not use TLS or SSL. The client knows how to get to ~anyuser, and if I log in as root, and do

su - anyuser

I get to their home directory. But they can't log in from the login window.

[smr54]

Ok, then try using authconfig-tui, which definitely does give the option to just use ldap, without tls or ssl. You might try doing ldapsearch from the client, on occasion, the error messages will be useful, though they often aren't.

Out of the links I list on my page, you can look at the linuxhomenetworking one, which gives a few tests, I believe. /var/log/messages on the server may also give some clues.

[hmg22]

BS"D

I've tried the authconfig-tui, according to the settings described in your OpenLDAP page.

It seems to have configured nsswitch.conf to use sss


passwd: files sss
shadow: files sss
group: files sss

and, of course, started sssd.

Does not work.

The post I mentioned earlier suggested not using sss, and replacing the "sss" entries with "ldap" and shutting down sss. Also didn't work.

I guess I can always reinstall using FC12.....

[smr54]

Well, that's pretty weird. It seems as if something's buggy there--running F14 now, so don't have an F13 to check, but that's what I used in F13 as well. I never used sss, regardless of whether I used TLS, SSL, or plain authentication.

To be honest, not even sure what sss is--when I did all my ldap research, a couple of years ago, I didn't see mention of it.. The LDAP server I use is running CentOS 5.5., configured pretty much according to my page, with and without TLS.

---------- Post added at 11:54 AM GMT ---------- Previous post was at 10:51 AM GMT ----------

You might try, if able, to run debugging on the server. Stop slapd (assuming that's practical) and restart it from command line with a -d option. (See man slapd.conf for a relatively poorly written explanation of debug options). I think that -d 256 will log everything to terminal, so then you can see what's going on on the server. Looking at man(5) slapd.conf implies that running -d -1 (that's the numeral one, not a lower case L) might log everything, but doesn't explicitly say so.

[jpollard]

sss is a security framework. It is supposed to be able to use LDAP.

see http://fedoraproject.org/wiki/Features/SSSD

[smr54]

Ah, looks good in theory. Which always reminds me of the old Buffy episode, where, hiding in Buffy's house, Xander says something like, "Ok, we're safe here," and evil Angel, sitting on the roof says, "Works in theory," and pulls him through the Window.

[hmg22]

BS"D

Well, I'm garnering a bit more information:

In the man page for sssd-ldap, there is the statement:


If you want to authenticate against an LDAP server then TLS/SSL is required. sssd does not support authentication over an unencrypted channel. If the LDAP server is used only as an identify provider, an encrypted channel is not needed.


So that explains why the workstation can identify the users, but not log them in. So one possibility is: can I modify the LDAP server to allow both TLS connections, and maintain the current non-TLS/SSL clients?

Or, as I asked earlier, can we disable sssd on the client, and use what FC12 uses in its place. The thread I quoted before seemed to suggest that this was possible, but I got an error message about not being able to connect to the authentication daemon. Perhaps I needed to manually start some other service instead of sssd.

Thanks for all the advice given so far....

HMG

[smr54]

Interesting. Thank you for the update, I'd best add that to my page.

Interesting that I wasn't hit by it when I set up F14. I always test unencrypted before setting up TLS, and didn't have a problem.
On the other hand, never saw sssd in nsswitch.conf, but I do some of the setup by hand, so that might be why I avoided it.

[hmg22]

BS"D

Ok, problem solved.

Basically, the solution is that given by bkedelen, but I had to make all the changes manually.

I'm not sure why it didn't work the first time, but it might have to do with the following line in
/etc/ldap.conf:


# OpenLDAP SSL options
# Require and verify server certificate (yes/no)
# Default is to use libldap's default behavior, which can be configured in
# /etc/openldap/ldap.conf using the TLS_REQCERT setting. The default for
# OpenLDAP 2.0 and earlier is "no", for 2.1 and later is "yes".
tls_checkpeer no

So the default appears to be "yes", which I was not aware of. I have set this to "no" and in concert with the other changes below, users can now log in.

Next I modified the nsswitch.conf to have

passwd: files ldap
shadow: files ldap
group: files ldap

and then I went to the /etc/pam.d/system-auth file, where I changed all occurrences of pam_sss.so to pam_ldap.so (4 changes). I then did the same in /etc/pam.d/password-auth (3 changes).

I also stopped sssd (but I'm not sure that is necessary).

Thanks smr for your very useful page.

[smr54]

And thank you for the useful information--I've added it to my page.

Interestingly enough, there was another problem with F13, where one had to manually add TLS_REQCERT yes to use it with TLS or SSL.

So, in a nutshell, they broke expected LDAP behavior, and if it's mentioned, it's well hidden as a feature. There is nothing on the project page about how it will change past behavior.

Many thanks for this, I suspect it will help others in the future.