Have you tried to use the "tls_reqcert never" directive in nslcd.conf (may not apply in your case ?). I wouldn't run this way, just for troubleshooting. Also, in nslcd.conf did I see that you changed "ssl start_tls" to something else. We use "ssl start_tls" in our RH6 boxes. Also, in nslcd.conf we found success using these directives for RH6 (RH5 uses "nss_base_passwd" type directives):
scope one base group ou=Group,o=example.com base passwd ou=People,o=example.com base shadow ou=People,o=example.com
Finally, I'm sure you checked it but with the error below, you should verify you do not have "uri ldaps://ldap.server.com/" (trailing slash important) in any of your client config files since you are using start_tls..
On Fri, 15 Apr 2011 11:23 +0200, "Judith Flo Gaya" jflo@imppc.org wrote:
Hello ldap,
In fact in my authconfig instruction I have --enableforcelegacy, but this only works on my f14 clients, rh refuses to accept this option, but I already set the forcelegacy=yes in my /etc/sysconfig/authconfig. At the very beginning sssd was a little crazy... but I have learnt to get rid of it.
How do you set your authconfig system? right now is the only missing part of the puzzle ;(
On 04/14/2011 07:40 PM, ldap@mm.st wrote:
I came in late on this thread, so disregard if this has already been said or is not applicable. Also, we use standard RH packages, so if you are building your own, this may not be any use to you.
We have a few RH6 boxes authenticating against our ldap servers. It's been awhile, but in addition to the CA certs being copied to the clients and the correct perms assigned we had come success enabling legacy mode in RH6 when running authconfig to set up the box. If I recall, in legacy mode sssd does not run and it uses a more RH5 way of authenticating clients. Unfortunately, I don't have a RH6 box in front of me, but you can edit /etc/sysconfig/authconfig to set legacy mode. Then run your authconfig command to set up the box. Also, look at /etc/pam_ldap.conf if you decide to try to authenticate in this manner. The settings in there are like they were in /etc/ldap.conf, RH5. Your system-auth file looks like ours does as far as I can remember.
Just something else you may want to try if you haven't already.
On Thu, 14 Apr 2011 18:55 +0200, "Judith Flo Gaya"jflo@imppc.org wrote:
Hello,
After doing all you suggest with the pki keys I'm stuck in the very same place, the system is able to do ldapsearch but all user auth is not working, I do this in order to configure the auth in the clients # authconfig --disablecachecreds --enableldaps --enableldapauth --ldapserver=ldaps://server.fdqn --ldapbasedn=dc=linux,dc=imppc,dc=org --disablefingerprint --disablewinbind --disablewins --disablesssd --disablesssdauth --disablenis --enablecache --enablelocauthorize --disablemd5 --passalgo=sha512 --updateall
The pam.d files look ok:
# cat /etc/pam.d/system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. 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_ldap.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_ldap.so account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_ldap.so
This is the message in ldap server when I do id<ldap_user> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 ACCEPT from IP=[::1]:36208 (IP=[::]:636) Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 TLS established tls_ssf=256 ssf=256 Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 EXT oid=1">oid=1.3.6.1.4.1.1466.20037 Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 STARTTLS Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 RESULT oid= err=1 text=TLS already started Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=1 UNBIND Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 closed
Aparently is ok but the id is not known Any ideas? Thanks a lot! j
On 04/14/2011 05:44 PM, Judith Flo Gaya wrote:
Hello Aaron,
On 04/13/2011 09:07 PM, Aaron Richton wrote:
On Wed, 13 Apr 2011, Judith Flo Gaya wrote:
I see, I also have those files that you mention... I created my own CA as lots of tutorials explain.. Then I transmitted it to the clients and used it in the ldap.conf file. Do you suggest me to send those to the server and use them instead of the ones I generated with openssl?
Well, you'll need the CA on the client to match the CA that signed the server's certificate. In other words...if you generated your own CA for both the client and the server, trust issues would be completely expected...
I don't know if I understood you or I didn't make myself clear on that point. I created a CA in the server and the copied the file to the client, is that wrong?
What's your server?
OpenLDAP software is on both sides of the equation; it's just that some clients are NSS, some clients are OpenSSL, some clients are GnuTLS, while ALL servers are OpenSSL.
I was talking about the operating system, for some reason I think that having red hat (with openldap compiled using openssl) and clients with fedora (openldap compiled against moznss) created my problems. Now that you said that this is your case (I think) then it may be something related to... I don't know what.
Well my final problem were not ldapsearch but the user autenticacion. The ldapsaerch showed the whole ldap definitions but if I try to ssh with an ldap user to the machine, I get some TLS negotiation problem ;( That's when I was told that the problem may be caused by the implementation of the ldap client (with moznss support).
Well, when troubleshooting, it's often easiest to look with a narrow scope. Using OpenLDAP software, such as ldapsearch(1) and ldapwhoami(1), will probably offer a better debugging platform than an ssh implementation? One step at a time...
Yes, I totally agree, that's why I setup my own openldap installation and only care about ldapsearch working, then when ldapsearch finally worked, then I start looking at the user auth part, changing passw, etc.. as this part wasn't working and it appear to be a moznss problem, I got stuck... until you arrived, I will try what you suggest about using the pki certs instead of the openssl ones..
Thanks a lot for the suggestion, hope this finally fix the issue. j
-- Judith Flo Gaya Systems Administrator IMPPC e-mail: jflo@imppc.org Tel (+34) 93 554-3079 Fax (+34) 93 465-1472
Institut de Medicina Predictiva i Personalitzada del Càncer Crta Can Ruti, Camí de les Escoles s/n 08916 Badalona, Barcelona, Spain http://www.imppc.org
-- Judith Flo Gaya Systems Administrator IMPPC e-mail: jflo@imppc.org Tel (+34) 93 554-3079 Fax (+34) 93 465-1472
Institut de Medicina Predictiva i Personalitzada del Càncer Crta Can Ruti, Camí de les Escoles s/n 08916 Badalona, Barcelona, Spain http://www.imppc.org