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" <[email protected]> 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, [email protected] 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"<[email protected]> > > 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: [email protected] > >> 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: [email protected] > 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 >
