[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: fedora and openldap
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
>