[Date Prev][Date Next]
Re: fedora and openldap
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
--disablefingerprint --disablewinbind --disablewins --disablesssd
--disablesssdauth --disablenis --enablecache --enablelocauthorize
--disablemd5 --passalgo=sha512 --updateall
The pam.d files look ok:
# cat /etc/pam.d/system-auth
# 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
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: conn=1019 fd=12 ACCEPT from
Apr 14 18:54:34 curri0 slapd: conn=1019 fd=12 TLS established
Apr 14 18:54:34 curri0 slapd: conn=1019 op=0 EXT
Apr 14 18:54:34 curri0 slapd: conn=1019 op=0 STARTTLS
Apr 14 18:54:34 curri0 slapd: conn=1019 op=0 RESULT oid= err=1
text=TLS already started
Apr 14 18:54:34 curri0 slapd: conn=1019 op=1 UNBIND
Apr 14 18:54:34 curri0 slapd: conn=1019 fd=12 closed
Aparently is ok but the id is not known
Thanks a lot!
On 04/14/2011 05:44 PM, Judith Flo Gaya wrote:
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
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.
Judith Flo Gaya
Systems Administrator IMPPC
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,