openldap-technical

openldap-technical@openldap.org

13 participants
9906 discussions

Quick newbie pointer - unauth ldap* commands as root on ldap master
by Tim Watts 19 Sep '11

19 Sep '11

Hi, Sorry - this will sound really dumb... For people who aren't very LDAP savvy, what the cleanest way to rig an LDAP server that I have root access to to: allow unprompted ldap* commands (eg ldapmodify). GoSA has got confused creating a user and I need to manually force some ldif files with minor changes through... MIT Kerberos has a kdamin.local command that does not care about authentication because it has direct access to the database files. Is there something similar for OpenLDAP? This is a files based ldap server, not using SQL. I have located an ldap.secret file but am having trouble authenticating with its content. I'm fairly confused because LDAP appears to have many many ways to handle authentication... Many thanks, Tim -- Tim Watts Personal Blog: http://www.dionic.net/tim/

2 4

Fwd: Re: pcache crashes server
by turbo＠bayour.com 19 Sep '11

19 Sep '11

[My reply should have gone to the list - using a new webclient at work] -------- Original Message -------- Subject: Re: pcache crashes server Date: Mon, 19 Sep 2011 12:09:37 +0200 From: Pierangelo Masarati <masarati(a)aero.polimi.it> To: turbo(a)bayour.com On 09/19/2011 11:39 AM, turbo(a)bayour.com wrote: > On Mon, 19 Sep 2011 10:57:53 +0200, Pierangelo Masarati wrote: >> On 09/19/2011 09:48 AM, turbo(a)bayour.com wrote: >>> I'm trying to use pcache on my server, but it crashes every time it >>> gets a >>> 'QUERY CACHABLE'... >>> >>> See my config in my other thread... >> >> What other thread? Please, always provide a link to the archives, to >> help others help you. > > http://www.openldap.org/lists/openldap-technical/201109/msg00160.html I know, maybe others don't. You should reply to the list. I already gave all the advice I could. p. >>> So it gets the value from the AD, transmogrifying it using rwm and >>> sends >>> the reply to the >>> client. But when getting to the pcache overlay, it crashes... >> >> The root cause is likely rwm. This won't fix at least until 2.5, for >> reasons explained in ITSes involving slapo-rwm. Please decouple the >> two overlays, at the cost of adding an intermediate proxy. > > Where you thinking of ITS#6166 here (it was referenced in ITS#6997) > or > some other ITS? >

1 2

Re: open LDAP + TLS/SSL bind Failed.
by arun.sasi1＠wipro.com 19 Sep '11

19 Sep '11

Daniel, Please perform the below steps to create certificate... $ /usr/lib/ssl/misc/CA.pl -newreq $ /usr/lib/ssl/misc/CA.pl -signreq $ openssl rsa < newkey.pem > clearkey.pem then $ sudo cp cacert.pem /usr/share/ca-certificates/Domain.crt Then, edit the /etc/ca-certificates.conf file, and add Domain.crt at the end of the file. Finally, run update-ca-certificates: $ sudo update-ca-certificates Updating certificates in /etc/ssl/certs....done. Thanks, -Arun Message: 9 Date: Sun, 18 Sep 2011 22:59:51 -0400 From: Daniel Qian <daniel(a)up247solution.com> To: openldap-technical(a)openldap.org Subject: Re: open LDAP + TLS/SSL bind Failed. Message-ID: <4E76B027.9020800(a)up247solution.com> Content-Type: text/plain; charset="utf-8"; Format="flowed" On 11-09-16 3:57 AM, vijay s sheelavantar wrote: > Hi, > I am trying to configure LDAP Client/server on 2 Fedora-10 linux machines. > > I have installed and configured openldap-2.4.26 server on one machine > and pam_ldap-186, nss_ldap-265 on the other machines. > > I have created the TLS certificates using following command on the server. > > openssl req -newkey rsa:1024 -x509 -nodes -out \ server.pem -keyout > server.pem -days 3650 > > and I have created the client.pem by copying CERTIFICATE portion of > the server.pem. > > When my client try to connect to the server I get following errors. > > *TLS trace: SSL3 alert read:fatal:unknown CA > TLS trace: SSL_accept:failed in SSLv3 read client certificate A > TLS: can't accept: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 > alert unknown ca. > connection_read(12): TLS accept failure error=-1 id=1012, closing > connection_closing: readying conn=1012 sd=12 for close > connection_close: conn=1012 sd=12 > daemon: removing 12 > conn=1012 fd=12 closed (TLS negotiation failure) > * > My Configurations are as follows. > > slapd.conf > > access to attrs=userPassword > by self write > by anonymous auth > by * none > > access to * > by * read > > #TLS Certificate section > TLSCipherSuite HIGH:MEDIUM:+SSLv2:+SSLv3:RSA > TLSCACertificateFile /etc/openldap/cacerts/server.pem > TLSCertificateFile /etc/openldap/cacerts/server.pem > TLSCertificateKeyFile /etc/openldap/cacerts/server.pem > TLSVerifyClient allow > > and client side ldap.conf > > base dc=samsung,dc=com > uri ldaps://10.254.204.181/ > TLS_CACERT /etc/openldap/cacerts/client.pem > pam_password md5 > > nsswitch.conf > > passwd: files ldap > shadow: files ldap > group: files ldap > > netgroup: files ldap > automount: files ldap > > I am not getting why it is saying Unknown ca. even though the > certificate is created on server machine itself. > > Kindly help me to solve this problem. > <http://sigads.rediff.com/RealMedia/ads/click_nx.ads/www.rediffmail.com/ signatureline.htm@Middle?> > Treat yourself at a restaurant, spa, resort and much more with *Rediff > Deal ho jaye! > <http://track.rediff.com/click?url=___http://dealhojaye.rediff.com?sc_ci d=mailsignature___&cmp=signature&lnk=rediffmailsignature&newservice=deal s>* you may try this cd /etc/openldap/cacerts/ ln -s client.pem `openssl x509 -noout -hash -in client.pem`.0

1 0

Re: open LDAP + TLS/SSL bind Failed.
by vijay s sheelavantar 19 Sep '11

19 Sep '11

Thank you very much Buchan. I have changed the certificate creation method. Now I created the certificates using CA.sh of openssl.I followed the instruction given in the below link to create the certificates. http://octaldream.com/~scottm/talks/ssl/opensslca.html 1. At the server side now i am able to do ldapsearch and ldapadd, as i have chenged the /usr/local/etc/openldap/ldap.conf on server to remove IP address. I have made necessary changes in /etc/hosts file also. BASE    dc=samsung,dc=comURI     ldaps://localhost.localdomain/TLS_CACERT      /etc/pki/CA/cacert.pemTLS_CACERTDIR   /etc/pki/CA/ 2.slapd.conf details for TLS are as follows TLSCipherSuite          HIGH:MEDIUM:+SSLv2:+SSLv3:RSATLSCACertificatePath    /etc/pki/CA/TLSCACertificateFile    /etc/pki/CA/cacert.pemTLSCertificateFile      /etc/pki/tls/misc/newcert.pemTLSCertificateKeyFile   /etc/pki/tls/misc/newkey.pemTLSVerifyClient         allow 3. I have copied the "cacert.pem" which is CA and "newcert.pem" which my server certificate to the client machine. I have copied these files to /etc/openldap/cacerts directory on client machine. and I have made the following configuration changes to "/etc/ldap.conf" file at the client side. base dc=samsung,dc=comuri ldaps://localhost.localdomain/tls_cacertfile  /etc/openldap/cacerts/cacert.pemtls_cert /etc/openldap/cacerts/newcert.pempam_password md5nss_map_attribute gecos description When the "TLSVerifyClient  allow" is specified in slapd.conf, I am able to login to the client machine properly, authentication is succesful. but when "TLSVerifyClient  demand" and when I try to login to the client machine the authentication is failing. I am getting the following error at the server side. TLS trace: SSL3 alert write:fatal:handshake failureTLS trace: SSL_accept:error in SSLv3 read client certificate BTLS: can't accept: error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate.connection_read(12): TLS accept failure error=-1 id=1005, closingconnection_closing: readying conn=1005 sd=12 for closeconnection_close: conn=1005 sd=12daemon: activity on 1 descriptordaemon: activity on:daemon: removing 12conn=1005 fd=12 closed (TLS negotiation failure) please let me know where i am making mistake? how can i correct this and make it work properly? Thanks & Regards,Vijay S.

1 0

pcache crashes server
by turbo＠bayour.com 19 Sep '11

19 Sep '11

I'm trying to use pcache on my server, but it crashes every time it gets a 'QUERY CACHABLE'... See my config in my other thread... This is a localy compiled OpenLDAP v2.4.26 with localy compiled Berkeley DB v5.1.25 on a CentOS v5.6 (Final). ----- s n i p ----- [...] => access_allowed: read access granted by read(=rscxd) conn=1000 op=1 ENTRY dn="uid=kpxb140,ou=people,dc=seml,dc=company,dc=tld" ber_flush2: 80 bytes to sd 17 0000: 30 4e 02 01 02 64 49 04 33 75 69 64 3d 6b 70 78 0N...dI.3uid=kpx 0010: 62 31 34 30 2c 6f 75 3d 50 65 6f 70 6c 65 2c 64 b140,ou=People,d 0020: 63 3d 73 65 6d 6c 2c 64 63 3d 00 00 00 00 00 00 c=seml,dc=xxxxxx 0030: 65 6e 65 63 61 2c 64 63 3d 6e 65 74 30 12 30 10 xxxxx,dc=net0.0. 0040: 00 00 00 00 00 31 09 04 07 6b 70 78 62 31 34 30 ..uid1...kpxb140 ldap_write: want=80, written=80 0000: 30 4e 02 01 02 64 49 04 33 75 69 64 3d 6b 70 78 0N...dI.3uid=kpx 0010: 62 31 34 30 2c 6f 75 3d 50 65 6f 70 6c 65 2c 64 b140,ou=People,d 0020: 63 3d 73 65 6d 6c 2c 64 63 3d 00 00 00 00 00 00 c=seml,dc=xxxxxx 0030: 00 00 00 00 00 2c 64 63 3d 6e 65 74 30 12 30 10 xxxxx,dc=net0.0. 0040: 04 03 75 69 64 31 09 04 07 6b 70 78 62 31 34 30 ..uid1...kpxb140 <= send_search_entry: conn 1000 exit. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x41001940 (LWP 16414)] 0x00002aaaad0919c9 in pcache_op_cleanup (op=0x89ad40, rs=0x41000c10) at pcache.c:2369 2369 Attribute *a = rs->sr_entry->e_attrs; (gdb) bt #0 0x00002aaaad0919c9 in pcache_op_cleanup (op=0x89ad40, rs=0x41000c10) at pcache.c:2369 #1 0x000000000043f797 in ?? () #2 0x0000000000441a7a in slap_send_search_entry () #3 0x00002aaaaca0d9fe in ldap_back_search (op=0x89ad40, rs=0x41000c10) at search.c:361 #4 0x0000000000494722 in overlay_op_walk () #5 0x0000000000494c87 in ?? () #6 0x0000000000432f09 in fe_op_search () #7 0x0000000000433715 in do_search () #8 0x0000000000430c65 in ?? () #9 0x000000000043123f in ?? () #10 0x00002aaaaaac1f38 in ldap_int_thread_pool_wrapper (xpool=0x79d1d0) at tpool.c:685 #11 0x000000397c80673d in start_thread () from /lib64/libpthread.so.0 #12 0x000000397bcd40cd in clone () from /lib64/libc.so.6 ----- s n i p ----- ----- s n i p ----- [kpxb140@semldx00135 LDAPv3]$ alias ldapsearch.local alias ldapsearch.local='/usr/local/turbo/bin/ldapsearch -LLL -x -h localhost -b dc=company,dc=tld' [kpxb140@semldx00135 LDAPv3]$ ldapsearch.local 'uid=kpxb140' uid dn: uid=kpxb140,ou=People,dc=org1,dc=company,dc=tld uid: kpxb140 ldap_result: Can't contact LDAP server (-1) ----- s n i p ----- So it gets the value from the AD, transmogrifying it using rwm and sends the reply to the client. But when getting to the pcache overlay, it crashes...

2 1

Rename DN ?
by Tim Watts 18 Sep '11

18 Sep '11

Hi folks, Quick question if I may: Is it possible to rename a DN, eg this LDIF file: dn: cn=Fred,ou=people,dc=example,dc=com changetype: modify replace: dn dn: cn=Fred,ou=people,ou=external,dc=example,dc=com I tried that, and ldapmodify does not seem to like it :( Many thanks, Tim -- Tim Watts Personal Blog: http://www.dionic.net/tim/

3 3

open LDAP + TLS/SSL bind Failed.
by vijay s sheelavantar 18 Sep '11

18 Sep '11

Hi, I am trying to configure LDAP Client/server on 2 Fedora-10 linux machines. I have installed and configured openldap-2.4.26 server on one machine and pam_ldap-186, nss_ldap-265 on the other machines. I have created the TLS certificates using following command on the server. openssl req -newkey rsa:1024 -x509 -nodes -out \ server.pem -keyout server.pem -days 3650 and I have created the client.pem by copying CERTIFICATE portion of the server.pem. When my client try to connect to the server I get following errors. TLS trace: SSL3 alert read:fatal:unknown CA TLS trace: SSL_accept:failed in SSLv3 read client certificate A TLS: can't accept: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca. connection_read(12): TLS accept failure error=-1 id=1012, closing connection_closing: readying conn=1012 sd=12 for close connection_close: conn=1012 sd=12 daemon: removing 12 conn=1012 fd=12 closed (TLS negotiation failure) My Configurations are as follows. slapd.conf access to attrs=userPassword by self write by anonymous auth by * none access to * by * read #TLS Certificate section TLSCipherSuite HIGH:MEDIUM:+SSLv2:+SSLv3:RSA TLSCACertificateFile /etc/openldap/cacerts/server.pem TLSCertificateFile /etc/openldap/cacerts/server.pem TLSCertificateKeyFile /etc/openldap/cacerts/server.pem TLSVerifyClient allow and client side ldap.conf  base dc=samsung,dc=com uri ldaps://10.254.204.181/ TLS_CACERT /etc/openldap/cacerts/client.pem pam_password md5 nsswitch.conf passwd: files ldap shadow: files ldap group: files ldap netgroup: files ldap automount: files ldap I am not getting why it is saying Unknown ca. even though the certificate is created on server machine itself. Kindly help me to solve this problem.

4 3

Re: SASL and non-cleartext passwords storage
by Julien Vehent 18 Sep '11

18 Sep '11

On 18.09.2011 14:36, Jacobus brogly.decap wrote: > No, encrypting passwords over the wire is somthing TOTALLY different > and > seperate from how they are stored on disk (in case you want to > migrate or > export) > Dont solve 2 different problems at the same time,..I recommend you > read > chapter 2 of IBM redbook on LDAP. > My apologies for not being clear. Let me go back to the initial problem. I have postfix, cyrus-imapd and openldap installed on a debian. I do not care about protecting passwords over the wire because I already use ldaps for all communications with slapd. postfix and cyrus-imapd both use ldapdb plugins to verify users against slapd. ldapdb is configured to authenticate postfix and cyrus-imap with their own private users, and then a proxy authorization is performed to take the identify of the real users. ex: postfix uses the user "postfixldap" and once authenticated, takes the identity of user "julien" +--------+ +----------+ |postfix | | cyrus | +--------+ +--------+-+ | | proxy | |proxy ldapdb ldapdb | +-----------+ |user "cyrusldap" user | | slapd | | +------->user=julien<--------+ "postfixldap" | | +-----------+ This method is nice because it avoid having an additional software in between postfix and cyrus (pam-ldap or saslauthd). But the problem is that ldapdb requires to use DIGEST-MD5 and therefore to store the passwords in cleartext in the directory. I'm looking for a solution to avoid storing the messages in cleartext. Is it possible while still using ldapdb in postfix and cyrus-imap ? Julien

2 1

Re: SASL and non-cleartext passwords storage
by Julien Vehent 18 Sep '11

18 Sep '11

On 18.09.2011 12:30, Jacobus brogly.decap wrote: > Sure, just choose "a schema" there are many hashes to choose from > SHA1-SHA2, MD5 etc...you can look it up in the admin guide on the > openldap.org [2] website...setting it up is really trivial! How is this going to work with proxy authorization ? the ldapdb auxprop plugin in postfix doesn't work with hash passwords. Should I go back to using saslauthd ? > 2011/9/18 Julien Vehent > >> Hi List, >> >> I'm working on a setup where postfix and cyrus-imap do proxy >> authorization against openldap (my setup is here http://1nw.eu/!cD >> [1] >> ). I love this solution, it's a lot more elegant that using >> saslauthd. >> But I'm concerned about passwords stored in cleartext, as required >> by >> DIGEST-MD5. >> >> I know of the many ways to protect the data stored in openldap (file >> system encryption, etc...), but if somebody gets a root access, >> passwords will be disclosed, and I want to prevent that. >> >> My question is: Is there a way to use hashed passwords with sasl and >> proxy authorization ? >> >> Thanks, >> Julien Links: ------ [1] http://1nw.eu/!cD [2] http://openldap.org [3] mailto:julien@linuxwall.info

1 0

SASL and non-cleartext passwords storage
by Julien Vehent 18 Sep '11

18 Sep '11

Hi List, I'm working on a setup where postfix and cyrus-imap do proxy authorization against openldap (my setup is here http://1nw.eu/!cD ). I love this solution, it's a lot more elegant that using saslauthd. But I'm concerned about passwords stored in cleartext, as required by DIGEST-MD5. I know of the many ways to protect the data stored in openldap (file system encryption, etc...), but if somebody gets a root access, passwords will be disclosed, and I want to prevent that. My question is: Is there a way to use hashed passwords with sasl and proxy authorization ? Thanks, Julien

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical