openldap-technical March 2014

openldap-technical@openldap.org

89 participants
101 discussions

RE: TLS QUESTION
by Borresen, John - 0442 - MITLL 11 Mar '14

11 Mar '14

Vielen Danke Dieter; Originally my command to create the client.pem was: grep -A 100 CERTIFICATE cacert.pem > client.pem Then I scp'd that out to the clients. That worked when doing SSL on port 636 (and not wild-card certificates), but it is not working now on TLS over 389 to mm-server1 and mm-server3 with wild-card certs. The cacert.pem and client.pem is on each client. Doing further reading...the client.pem since it was built off the cacert.pem (the server certificate) it should work. Should I use the cacert.pem or the servercrt.pem to create the client.pem? Thanks, John -----Original Message----- From: Dieter Klünter [mailto:dieter@dkluenter.de] Sent: Monday, March 10, 2014 2:41 PM To: Borresen, John - 0442 - MITLL Subject: Re: TLS QUESTION Am Mon, 10 Mar 2014 13:33:53 -0400 schrieb "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu>: > Thanks Dieter... > > As I stated I saw Howard Chu's response to an individual in 2005 with > a similar issue and he stated then, " For the slapd server you use the > corresponding TLSCACertificateFile directive. You must use these > configuration directives if you want to accept a self-signed cert." > > I did add the olcTLSCACertificateFile attribute (just forgot to list > it in my original post). Was not certain at the time if the > "olcTLSCertificateFile" should be removed so I did not remove it. > So, before I do remove it, the attribute should be > "olcTLSCACertificateFile" instead of "olcTLSCertificateFile" (and this > should be removed), correct? > > The CA directories on all three servers look like this: > > # ll > total 28 > lrwxrwxrwx 1 root root 10 Jan 24 11:44 600f07a1.0 -> cacert.pem --> > client hash -rw-r--r-- 1 ldap ldap 5136 Jan 17 12:15 cacert.pem --> > Self-signed certificate -rw-r--r-- 1 ldap ldap 1090 Jan 17 12:07 > cert.csr --> Certificate Signing Request -rw-r--r-- 1 ldap ldap 1757 > Jan 17 12:23 client.pem --> Client Certificate PEM -rw-r--r-- 1 ldap > ldap 0 Jan 14 16:20 index.txt drwxr-xr-x 2 ldap ldap 4096 Jan 14 > 16:18 newcerts (empty) drwxr-xr-x 2 ldap ldap 4096 Jan 17 12:06 > private --> server private key directory (cakey.pem) -rw-r--r-- 1 > ldap ldap 3 Jan 17 11:59 serial > This may sound like a dumb question... > > I created the client.pem from the cacert.pem (as indicated on > openssl.org) then copied that to each client. Is there a step I > missed in there? Yes, you have to create a client certificate for each host, while the Common Name must match the FQDN of this host. my blog entry may be of help: https://sys4.de/de/blog/2013/08/20/how-create-and-administer-x509-certifica… -Dieter > If so, where? > > Thanks in advance > > John > -----Original Message----- > From: openldap-technical-bounces(a)OpenLDAP.org > [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Dieter > Klünter Sent: Monday, March 10, 2014 12:58 PM To: > openldap-technical(a)openldap.org Subject: Re: TLS QUESTION > > Am Mon, 10 Mar 2014 11:18:14 -0400 > schrieb "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu>: > > > All, > > > > > > > > My set up consists of three servers each syncing with each other. > > The host names are: > > > > 1) mm-server1.example.ldap > > > > 2) mm-server2.example.ldap > > > > 3) mm-server3.example.ldap > > > > > > > > Utilizing TLSv1, on all three I have: > > > > olcTLSCertificateFile: > > /usr/local/openldap/etc/openldap/CA/cacert.pem > > this should be opcTLSCAcertificateFile > > > > > olcTLSCertificateKeyFile: > > /usr/local/openldap/etc/openldap/CA/private/cakey.pem > > you are misssing the host certificate, something like > olcTLSCertificateFile /usr/local/openldap/etc/openldap/CA/host.pem > > > > > olcTLSCipherSuite: HIGH:MEDIUM+TLSv1+SSLv3 > > > > > > > > Configured with self-signed wild-card certs, originally configured > > (using openssl 0.9.8) on mm-server2 and exported to the other > > servers. > > > > > > > > When running ldapmodify, ldapsearch, etc with a "-Z", and openssl > > s_client on mm-server1 or mm-server3 or any client pointing back to > > mm-server1 or 3, I receive the following error: > > > > > > > > TLS certificate verification: Error, self signed certificate > > > > TLS: can't connect: error:14090086:SSL > > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self > > signed certificate). > > > > ldap_start_tls: Connect error (-11) > > > > additional info: error:14090086:SSL > > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self > > signed certificate) > > > > > > > > Running any of those to mm-server2, it works with no such error. > > > > > > > > I am guessing, that since the certs were created on mm-server2, > > originally, that is why it works this way. Also, guessing I missed > > a step somewhere. > > > > > > > > I read online a post from 2005 with a good explanation of > > self-signed from Howard Chu about a similar problem. > > > > > > > > What is the best procedure for creating wild-card certs and sharing > > those out to other servers? The procedure that was used was from > > openssl.org so it was not a fly-by-night weblog. > > > > > > > > What did I miss (besides: a lot)? > > > > > > > > Thanks in advance, > > > > > > > > > > > > John D. Borresen (Dave) > > > > Linux/Unix Systems Administrator > > > > MIT Lincoln Laboratory > > > > Surveillance Systems Group > > > > 244 Wood St > > > > Lexington, MA 02420 > > > > Ph: (781) 981-1609 > > > > Email: john.borresen(a)ll.mit.edu > > > > > > > > > > -- > Dieter Klünter | Systemberatung > http://sys4.de > GPG Key ID: E9ED159B > 53°37'09,95"N > 10°08'02,42"E > -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

2 1

Re: RE : Re: ppolicy not verifying password length (not active !!)
by saurabh ohri 11 Mar '14

11 Mar '14

Thanks David, Self Service Password Also please suggest if the entry for TLS cert need to be made at /etc/ldap.conf or /etc/openldap/ldap.conf or /usr/local/openldap/etc/openldap/ldap.conf(This is the default one with ltb openldap) and can I put file name with publickey.pem. Please suggest with the parameter as default suggest in doc not working. Regards Sam On Tuesday, 11 March 2014 3:58 PM, David Coutadeur <dcoutadeur(a)linagora.com> wrote: Password policy overlay is available by default in the main openldap ltb package. Just use it via the configuration. No need to load the module. You could also need the check-password addon for the ppolicy overlay, available in a separate rpm: openldap-ltb-check-password David -------- Message d'origine -------- De : saurabh ohri Date :11/03/2014 05:49 (GMT+01:00) A : Quanah Gibson-Mount ,Patrick Laimbock ,openldap-technical(a)openldap.org Objet : Re: ppolicy not verifying password length (not active !!) Hi quanah/Patrick, I installed openldap ltb project on a new server as mentioned and following are the list of packages which are currently present but still cannot see ppolicy.la in my system, [root@xxx-xxx-xxx ~]# rpm -qa|grep openldap openldap-ltb-debuginfo-2.4.39-2.el6.x86_64 openldap-clients-2.4.23-34.el6_5.1.x86_64 openldap-2.4.23-34.el6_5.1.x86_64 openldap-ltb-check-password-1.1-8.el6.x86_64 openldap-ltb-2.4.39-2.el6.x86_64 openldap-ltb-contrib-overlays-2.4.39-2.el6.x86_64 Please suggest. Is that i am doing something wrong? Regards Sam On Tuesday, 11 March 2014 10:07 AM, saurabh ohri <sam_ohri(a)yahoo.co.in> wrote: Thanks Quanah for the reply. Does that mean that i need to rebuild the openldap server or just download the ppolicy.la for 2.4.39 version. I installed openldap-ltb-2.4.39-2.el6.x86_64 on rhel6.5. Please suggest. Regards Saurabh 9818925959 On Tuesday, 11 March 2014 12:59 AM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: --On Monday, March 10, 2014 4:22 PM +0800 saurabh ohri <sam_ohri(a)yahoo.co.in> wrote: > > > Thanks Patrick. It helped me to very much extend but again getting stuck > in pushing password policy on openldap. I got stuck in 2.4.23 and > upgraded to 2.4.39. But still it is an issue. > > Not able to found ppolicy.la in my system but copied the same from > previous version. Hope that id not effecting. That is not ok. You need to build ppolicy with your 2.4.39 build, and use that verison of the module. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

ppolicy not verifying password length (not active !!)
by Rodrigo Coutinho 10 Mar '14

10 Mar '14

Hi, I've installed the ppolicy overlay (static), included the shema, loaded the policy to the directory and define it as the default policy. However, to check the policy I've changed a user's password, below the minimum length specified by the policy, and no error was issued. I've used ldappasswd and Apache Directory Studio to change it and none issued no error. Although I did it with the root user, I suppose the policy should issue an error just the same, because I was changing another user's password. What am I missing, here ? Thank you in advance A transmiss�o de mensagens por e-mail n�o � absolutamente segura ou livre de erros. A mensagem pode ser intercetada, alterada, perdida, destru�da, chegar ao destinat�rio com atraso, ou mesmo com v�rus, n�o obstante o IFAP utilizar software anti-v�rus. Esta mensagem, incluindo eventuais ficheiros anexos, pode conter informa��o confidencial ou privilegiada e destina-se a uso exclusivo dos seus destinat�rios. Se n�o for o destinat�rio pretendido, informamos que a recebeu por engano, pelo que, qualquer utiliza��o, distribui��o, reencaminhamento ou outra forma de revela��o a terceiros, impress�o ou c�pia s�o expressamente proibidos. Se recebeu esta mensagem por engano, por favor contacte imediatamente o remetente por e-mail, e apague de imediato a mensagem do seu sistema inform�tico. O IFAP declina qualquer responsabilidade por erros ou omiss�es na presente mensagem e eventuais consequ�ncias, que resultem das situa��es referidas.

8 20

TLS QUESTION
by Borresen, John - 0442 - MITLL 10 Mar '14

10 Mar '14

All, My set up consists of three servers each syncing with each other. The host names are: 1) mm-server1.example.ldap 2) mm-server2.example.ldap 3) mm-server3.example.ldap Utilizing TLSv1, on all three I have: olcTLSCertificateFile: /usr/local/openldap/etc/openldap/CA/cacert.pem olcTLSCertificateKeyFile: /usr/local/openldap/etc/openldap/CA/private/cakey.pem olcTLSCipherSuite: HIGH:MEDIUM+TLSv1+SSLv3 Configured with self-signed wild-card certs, originally configured (using openssl 0.9.8) on mm-server2 and exported to the other servers. When running ldapmodify, ldapsearch, etc with a "-Z", and openssl s_client on mm-server1 or mm-server3 or any client pointing back to mm-server1 or 3, I receive the following error: TLS certificate verification: Error, self signed certificate TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self signed certificate). ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self signed certificate) Running any of those to mm-server2, it works with no such error. I am guessing, that since the certs were created on mm-server2, originally, that is why it works this way. Also, guessing I missed a step somewhere. I read online a post from 2005 with a good explanation of self-signed from Howard Chu about a similar problem. What is the best procedure for creating wild-card certs and sharing those out to other servers? The procedure that was used was from openssl.org so it was not a fly-by-night weblog. What did I miss (besides: a lot)? Thanks in advance, John D. Borresen (Dave) Linux/Unix Systems Administrator MIT Lincoln Laboratory Surveillance Systems Group 244 Wood St Lexington, MA 02420 Ph: (781) 981-1609 Email: john.borresen(a)ll.mit.edu

2 2

user can't login via LDAP
by Tim Dunphy 09 Mar '14

09 Mar '14

Hey all, I'm trying to get down to the bottom of a slight mystery we're having. We have a situation where some account stored in LDAP (using openldap) can log into some hosts but not others using their LDAP account information. To demonstrate, I take one of the users who is trying to login and verify that he does not have a local account on the target computer: [root@monitor:~] #grep spencer /etc/passwd [root@monitor:~] # [root@monitor:~] #id spencer id: spencer: No such user But the user should have the ability to login via their LDAP account: [root@monitor:~] #getent passwd | grep spencer spencer :*:10002:5000:Spencer Brown :/home/spencer:/bin/bash But when I attempt to log into the host using his password (this is a test account and I know the password) I get permission denied: [me@home:~/creds] #ssh spencer(a)monitor.jokefire.com spencer(a)monitor.jokefire.com's password: Permission denied, please try again. spencer(a)monitor.jokefire.com's password: Permission denied, please try again. spencer(a)monitor.jokefire.com's password: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password). And in the 'secure' log file on the host I'm trying to log into I see the following: Mar 9 10:43:02 monitor sshd[23137]: Invalid user spencer from xx.xx.xx.xx Mar 9 10:43:02 monitor sshd[23138]: input_userauth_request: invalid user spencer Mar 9 10:43:06 monitor sshd[23137]: pam_unix(sshd:auth): check pass; user unknown Mar 9 10:43:06 monitor sshd[23137]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost= ool-182e9727.dyn.optonline.net Mar 9 10:43:06 monitor sshd[23137]: pam_succeed_if(sshd:auth): error retrieving information about user spencer Mar 9 10:43:08 monitor sshd[23137]: Failed password for invalid user spencer from xx.xx.xx.xx port 59017 ssh2 Mar 9 10:43:11 monitor sshd[23137]: pam_unix(sshd:auth): check pass; user unknown Mar 9 10:43:11 monitor sshd[23137]: pam_succeed_if(sshd:auth): error retrieving information about user spencer Mar 9 10:43:13 monitor sshd[23137]: Failed password for invalid user spencer from xx.xx.xx.xx port 59017 ssh2 Mar 9 10:43:14 monitor sshd[23496]: Connection closed by xx.xx.xx.xx Mar 9 10:43:15 monitor sshd[23137]: pam_unix(sshd:auth): check pass; user unknown Mar 9 10:43:15 monitor sshd[23137]: pam_succeed_if(sshd:auth): error retrieving information about user spencer Mar 9 10:43:17 monitor sshd[23137]: Failed password for invalid user spencer from xx.xx.xx.xx port 59017 ssh2 Mar 9 10:43:17 monitor sshd[23138]: Connection closed by xx.xx.xx.xx Mar 9 10:43:17 monitor sshd[23137]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=ool-182e9727.dyn.optonline.net Mar 9 10:43:20 monitor sshd[23717]: Connection closed by xx.xx.xx.xx Yet if I try logging in with another test account on the same host that denied 'spencer' I am able to. The other account I'm testing with is called 'leo': [walkiriasoares@wal-mac:~/creds] #ssh leo(a)monitor.jokefire.com leo(a)monitor.jokefire.com's password: Last login: Sun Mar 9 10:32:52 2014 from ool-xxxx.dyn.optonline.net ,--,------,--. ,--. ,--. ,--. ,--. | | .---| `.' |,---.,--,--,,-' '-`--,-' '-.,---.,--.--. ,--. | | `--,| |'.'| | .-. | '-. .-,--'-. .-| .-. | .--' | '-' | |` | | | ' '-' | || | | | | | | | ' '-' | | `-----'`--' `--' `--'`---'`--''--' `--' `--' `--' `---'`--' [leo@monitor ~]$ And I am able to verify that 'leo' does not have a local account: [root@monitor:~] #grep leo /etc/passwd [root@monitor:~] # However I can get a unix id on this account: [root@monitor:~] #id leo uid=10005(leo) gid=5000(admins) groups=5000(admins) And getent also shows that he is has an account: [root@monitor:~] #getent passwd | grep leo leo:*:10005:5000:Leo Demo :/home/leo:/bin/bash However if I shift gears and try to log into the Ldap server itself (using the same passwords), I can with both accounts. [me@home:~] #ssh -qt spencer(a)ldap01.example.com spencer(a)ldap01.example.com's password: Welcome to Ubuntu 12.04.3 LTS (GNU/Linux 3.2.0-54-virtual x86_64) [me@home~] #ssh -qt leo(a)ldap01.example.com leo(a)ldap01.example.com's password: Welcome to Ubuntu 12.04.3 LTS (GNU/Linux 3.2.0-54-virtual x86_64) Again I can verify that neither account is local to the ldap server: [root@ldap01:~] #egrep "(spencer|leo)" /etc/passwd [root@ldap01:~] # Here's what my nsswitch looks like on the monitoring host (where spencer can't login but leo can): [root@monitor:~] #grep -v "#" /etc/nsswitch.conf passwd: files sss shadow: files sss group: files sss hosts: files dns bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files sss netgroup: files sss publickey: nisplus automount: files ldap aliases: files nisplus And here is the /etc/pam.d/password-auth-ac file: [root@monitor:~] #grep -v "#" /etc/pam.d/password-auth-ac 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_sss.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_sss.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_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so And here's the /etc/pam.d/system-auth-ac on the target host: [root@monitor:~] #grep -v "#" /etc/pam.d/system-auth-ac 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_sss.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_sss.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_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so I'm just wondering if there might be a problem in the config or what I can possibly do to nail down the source of the problem. Thanks Tim -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B

2 1

Works with ldapsearch, but can't get it to work with ldap_search_ext_s()
by Werner - Google 09 Mar '14

09 Mar '14

Hi, Trying to get a ldapclient to authenticate against it, but having a difficult time trying to figure out what i'm doing wrong. Would appreciate any tip/help pointing me in the correct direction. Company has a Microsoft Active Directory structure, like domain.com region_a users john.doe marcus.zap servers ... ... region_b users magaly.frap roger.smith ... servers ... ... Testing with ldapsearch, it works fine, returning the entry of john.doe, if i do a: >$ ldapsearch -v -h ldap_srv -p 389 -s sub -z 2 -l 15 -D auth_dn -w pass_dn -b "DC=domain,DC=com" "(sAMAccountName=john.doe)" sAMAccountName :: for info >$ldapsearch -VV ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.28 (Jul 4 2013 21:48:28) $ root(a)b1026.apple.com: /private/var/tmp/OpenLDAP/OpenLDAP-208.5~1/clients/tools (LDAP library: OpenLDAP 20428) ========= But with a simple code (extract bellow), on the same machine as the ldapsearch above, i'm unable to make it work. .... struct timeval timeOut = {15,0}; /* 15 second connection timeout */ char *attrs[] = {"sAMAccountName", NULL}; if ( (ld = ldap_init( "ldap_srv", 389 )) == NULL ) { return( 1 ); /* error */ } /* Bind with credentials to the LDAP server. */ rc = ldap_simple_bind_s( ld, auth_dn, pass_dn ); if ( rc != LDAP_SUCCESS ) { return( 1 ); /* error */ } /* Search for the entry. */ fprintf(stderr, "ldap_simple_bind_s(): Entering...\n"); rc = ldap_search_ext_s( ld, "DC=domain,DC=com", LDAP_SCOPE_SUBTREE, "(sAMAccountName=john.doe)", NULL, 0, NULL, NULL, &timeOut, 2, &result ); fprintf(stderr, "ldap_simple_bind_s(): after. rc=%d...\n", rc); ... ... :::::: The ldap_init(), ldap_simple_bind_s(), both work correctly. The call to: ldap_search_ext_s( ld, "DC=domain,DC=com", .... does never come back from the function call, i have waited for more than one hour. I never get the 2nd fprintf(...) Another point, should the ldap_search_ext_s() not return with an error after the defined "timeOut" (in my case 15 seconds) ? But, if i change the 2nd parameter (base dn) from: "DC=domain,DC=com" to "OU=region_a,DC=domain,DC=com", it works fine, returning the entry for john.doe in a few seconds. As i need to check users inside all of the "regions", i can't have the OU=region on the base search, because if i use it with OU=region_a,dc=domain,dc=com i'm not able to find the users from region_b, as expected :) Any tips to help me figure out what i'm doing wrong? Thanks werner

3 4

How get more detailed error information than the provided by ldap_err2string?
by Werner - Google 09 Mar '14

09 Mar '14

Hi, I've the sample code bellow, and when i intentionally put the wrong credentials, i get from "ldap_err2string( rc ) the error message: "Invalid credentials". But monitoring network traffic with wireshark, i can see that on the bindResponse packet that returns from the server, i also get a more detailed message. In my/this test case, "errorMessage: 80090308: LdapErr: DSID-0C0903AA, comment: AcceptSecurityContext error, data 525, v1772" attached is also an image of the wireshark showing what i mean. Question is, is there a way i could retrieve this more detailed message? Thanks in advance for any help Regards. --- sample code: if ( (ld = (LDAP *)ldap_init( pHostName, iPortNum )) == NULL ) { perror( "ldap_init failed. Reason?:" ); exit ( 1 ); } if ( (rc=ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION, &version)) != LDAP_SUCCESS ){ fprintf( stderr, "ldap_set_option(LDAP_OPT_PROTOCOL_VERSION): %s\n", ldap_err2string( rc ) ); exit( 1 ); } if ( (rc=ldap_set_option(ld, LDAP_OPT_REFERRALS, LDAP_OPT_OFF)) != LDAP_SUCCESS){ fprintf( stderr, "ldap_set_option(LDAP_OPT_REFERRALS): %s\n", ldap_err2string( rc )); exit( 1 ); } rc = ldap_simple_bind_s( ld, "auth_dn", "auth_pw" ); if ( rc != LDAP_SUCCESS ) { fprintf( stderr, "ldap_simple_bind_s() Failed: %s [%d]\n", ldap_err2string(rc), rc); ldap_unbind_s(ld); /* try unbind the failed connection anyway */ exit ( 1 ); }

4 6

Context around DNS resolution
by Joshua Schaeffer 09 Mar '14

09 Mar '14

I setup LDAPS (yes, will be switching to ldap + StartTLS) and ran intosomething odd and I'm really just looking for a bit of context. Everything is working correctlyand I'm able to authenticate clients to the ldap server, however when I runthe following ldapsearch I get an error: jschaeffer@zipmaster07:~$ ldapsearch -LLL -v -D cn=admin,dc=harmonywave,dc=com -W -H ldaps://baneling -b uid=jschaeffer,ou=People,dc=harmonywave,dc=com ldap_initialize( ldaps://baneling:636/??base ) Enter LDAP Password: ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) And from the debug output: 531c7c0a ber_get_next on fd 12 failed errno=0 (Success) 531c7c0a conn=1000 op=1 do_unbind 531c7c0a connection_close: conn=1000 sd=12 531c7c18 slap_listener_activate(6): 531c7c18 >>> slap_listener(ldaps:///) 531c7c18 connection_get(12): got connid=1001 531c7c18 connection_read(12): checking for input on id=1001 531c7c18 connection_get(12): got connid=1001 531c7c18 connection_read(12): checking for input on id=1001 531c7c18 connection_read(12): unable to get TLS client DN, error=49 id=1001 531c7c18 connection_get(12): got connid=1001 531c7c18 connection_read(12): checking for input on id=1001 ber_get_next 531c7c18 ber_get_next on fd 12 failed errno=0 (Success) 531c7c18 connection_close: conn=1001 sd=12 If I use the FQDN for the URI then everything works fine and I get results. I know DNS is working correctly, I can ping the server name and it returns the FQDN and reverse DNS resolution also works. The hostname and hostname -f commands work correctly on both client and server. Was it never intended for ldap commands to resolve server names to their FQDN? I'm also assuming that ldap + StartTLS would show the same behavior.

2 1

ldapdelete failing
by Tim Dunphy 08 Mar '14

08 Mar '14

Hello, I'm trying to delete an entry in my ldap database. But when issuing this command I am getting an error: [root@ldap01:~/ldap] #ldapdelete -v -x 'dn: uid=spencer,ou=People,dc=example,dc=com' -D cn=admin,dc=example,dc=com -W ldap_initialize( <DEFAULT> ) Enter LDAP Password: deleting entry "dn: uid=spencer,ou=People,dc=example,dc=com" ldap_delete: Invalid DN syntax (34) additional info: invalid DN I find it strange to be getting an 'invalid dn' error as the dn I'm using in the delete command was pulled straight form an ldapsearch: root@ldap01:~/ldap] #ldapsearch -x -LLL -b dc=example,dc=com 'uid=spencer' dn dn: uid=spencer,ou=People,dc=example,dc=com It was a straight copy paste, so I am unsure of why I might be getting this error. Could I please get some help on the syntax I'll need to get the command to work properly? Thank you, Tim -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B

2 2

Client doesn't send certificate for LDAPS
by Joshua Schaeffer 08 Mar '14

08 Mar '14

I'm in the process of setting up my slapd server to operate over LDAPS and having trouble when using a CA certificate (being my own certificate authority). I've been able to setup LDAPS when using a self-signed server certificate: root@baneling:~# slapcat -H ldap:///cn=config??base dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcLogLevel: none olcPidFile: /var/run/slapd/slapd.pid olcToolThreads: 1 structuralObjectClass: olcGlobal entryUUID: 0e827846-3926-1033-9f74-632898b715c9 creatorsName: cn=config createTimestamp: 20140306025210Z olcTLSCertificateFile: /etc/ssl/certs/ldap.harmonywave.com.crt olcTLSCertificateKeyFile: /etc/ssl/private/ldap.harmonywave.com.key olcTLSCipherSuite: SECURE256 olcTLSVerifyClient: never entryCSN: 20140308131751.026022Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20140308131751Z This works fine and I'm able to authenticate clients. However if I use a CA certificate (again, being my own CA) to sign my server certificate and then change olcTLSVerifyClient to demand and add olcTLSCACertificateFile then I can no longer authenticate. I've installed my CA certificate on the client machine and pointed both ldap.conf and nslcd.conf to the CA certificate. However I get the following when debugging: root@baneling:~# slapd -d conns -h ldaps:/// 531b1cef @(#) $OpenLDAP: slapd (Apr 23 2013 12:16:04) $ root@lupin:/tmp/buildd/openldap-2.4.31/debian/build/servers/slapd 531b1cf0 slapd starting 531b1cf0 daemon: added 3r listener=(nil) 531b1cf0 daemon: added 6r listener=0x7fe2d98326e0 531b1cf0 daemon: added 7r listener=0x7fe2d98327c0 531b1cf0 daemon: epoll: listen=6 active_threads=0 tvp=zero 531b1cf0 daemon: epoll: listen=7 active_threads=0 tvp=zero 531b1cf0 daemon: activity on 1 descriptor 531b1cf0 daemon: activity on:531b1cf0 531b1cf0 daemon: epoll: listen=6 active_threads=0 tvp=zero 531b1cf0 daemon: epoll: listen=7 active_threads=0 tvp=zero 531b1cf4 daemon: activity on 1 descriptor 531b1cf4 daemon: activity on:531b1cf4 531b1cf4 daemon: epoll: listen=6 busy 531b1cf4 daemon: epoll: listen=7 active_threads=0 tvp=zero 531b1cf4 daemon: activity on 1 descriptor 531b1cf4 daemon: activity on:531b1cf4 531b1cf4 daemon: epoll: listen=6 active_threads=0 tvp=zero 531b1cf4 daemon: epoll: listen=7 active_threads=0 tvp=zero 531b1cf4 daemon: listen=6, new connection on 12 531b1cf4 daemon: added 12r (active) listener=(nil) 531b1cf4 daemon: activity on 1 descriptor 531b1cf4 daemon: activity on:531b1cf4 12r531b1cf4 531b1cf4 daemon: read active on 12 531b1cf4 daemon: epoll: listen=6 active_threads=0 tvp=zero 531b1cf4 daemon: epoll: listen=7 active_threads=0 tvp=zero 531b1cf4 daemon: activity on 1 descriptor 531b1cf4 daemon: activity on:531b1cf4 531b1cf4 daemon: epoll: listen=6 active_threads=0 tvp=zero 531b1cf4 daemon: epoll: listen=7 active_threads=0 tvp=zero 531b1cf4 daemon: activity on 1 descriptor 531b1cf4 daemon: activity on:531b1cf4 531b1cf4 daemon: epoll: listen=6 active_threads=0 tvp=zero 531b1cf4 daemon: epoll: listen=7 active_threads=0 tvp=zero 531b1cf4 daemon: activity on 1 descriptor 531b1cf4 daemon: activity on:531b1cf4 12r531b1cf4 531b1cf4 daemon: read active on 12 531b1cf4 daemon: epoll: listen=6 active_threads=0 tvp=zero 531b1cf4 daemon: epoll: listen=7 active_threads=0 tvp=zero TLS: can't accept: The peer did not send any certificate.. 531b1cf4 connection_closing: readying conn=1000 sd=12 for close 531b1cf4 daemon: removing 12 531b1cf4 daemon: activity on 1 descriptor 531b1cf4 daemon: activity on:531b1cf4 Why would the client not send the certificate if I've pointed TLS_CACERT in ldap.confand tls_cacertfile to that cert? Maybe I'm misunderstanding the basic concepts here, I am pretty new to a lot of this. I'm using OpenLDAP 2.4.31, Debian 7, and GnuTLS. Yes, I'm aware of its recent critical security bug and the warnings against it from this group (http://www.openldap.org/lists/openldap-devel/200802/msg00072.html). Thanks, Joshua

3 3

← Newer
1
...
5
6
7
8
9
10
11
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical March 2014