openldap-technical

openldap-technical@openldap.org

21 participants
9787 discussions

Unable to connect to 636 secure port using LDAP library
by BANDANI MAHARANA 15 Aug '22

15 Aug '22

Hi Team, I am trying to connect to an Active directory server using 636 port for secure connection. I am using the openldap library to establish the connection. Implementation is completed for insecure connection using 389 port. Below is the code snippet I am using to establish the connection with ldap server in 636 port. LDAP * ldap_handler; int return_value = ldap_initialize(ldap_handler, "ldaps:// TestServer.mylab.com:636"); //server url if (return_value == LDAP_SUCCESS) { cout<<"LDAP initialized successfully"; // this is successful for me } else { cout<<"LDAP initialization failed"; } int return_value = ldap_set_option(*ldap_handler, LDAP_OPT_PROTOCOL_VERSION, LDAP_VERSION3); if(return_value == LDAP_SUCCESS) { cout<<"success"; // this is successful for me } else { cout<<"failed"; } const char * CACERT_FILE_PATH = "certificate/mylab-TESTSERVER-CA.cer"; //certificate path int return_value1 = ldap_set_option(*ldap_handler, LDAP_OPT_X_TLS_CACERTFILE, CACERT_FILE_PATH); if (return_value1 == LDAP_SUCCESS) { } else { // its failing here with error -1, and error string "Can't contact to LDAP server" } int return_value = ldap_simple_bind_s(*ldap_handler, "mylab\administrator", ""pwd@1234"); if (return_value == LDAP_SUCCESS) { //success } else { // its failing here with error -1, and error string "Can't contact to LDAP server" } I have verified the same thing is working when connecting to 389 port. Could you please suggest how to make this work for secure ldap connection over ssl? Please provide some examples or references. It will be helpful for me. Thanks & Regards, Bandani

3 4

LDAP Failure: {'desc': "Can't contact LDAP server}
by Shaheena Kazi 08 Aug '22

08 Aug '22

Hello, I am using Debian 11. Openldap : 2.4.57+dfsg-3+deb11u1 python3-ldap : 3.2.0-4+b3 python3-ldap3: 2.8.1-1 TLS - 1.3 Openssl - 1.1.1n-0+deb11u3 I am try to set a new connect and then import files using below commands: ldapcon = ldap.initialize('ldap://localhost') ldapcon.set_option(ldap.OPT_PROTOCOL_VERSION, ldap.VERSION3) ldapcon.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, ldap.OPT_X_TLS_NEVER) ldapcon.set_option(ldap.OPT_X_TLS_NEWCTX, 0) dn_to_add = 'cn=test.user,ou=people,dc=framework,dc=protegrity,dc=com' modlist_to_add = [('uid', [b'test.user']), ('objectclass', [b'inetOrgPerson', b'posixAccount', b'top']), ('uidnumber', [b'1003']), ('gidnumber', [b'100']), ('homedirectory', [b'/home/test.user']), ('userpassword', [b'qwer1234']), ('givenname', [b'test']), ('sn', [b'user']), ('displayname', [b'test user']), ('loginshell', [b'/usr/local/sbin/manager']), ('cn', [b'test.user']), ('description', [b'testing']), ('pwdreset', [b'TRUE'])] ********* But when I run this - ldapcon.add_s(dn_to_add, modlist_to_add) The slapd service crashes and I get below error LDAP Failure: {'desc': "Can't contact LDAP server} ldap.CONFIDENTIALITY_REQUIRED: {'desc': 'Confidentiality required', 'info': 'TLS confidentiality required'} Can u guys help me here as in what am I missing on and why the add_s is causing my slapd to crash Regards, Shaheena K

2 1

symas pacakages on Debian
by Ulf Volmer 05 Aug '22

05 Aug '22

Hello, I'm running symas OpenLDA on Debian 11. Today we got an upgrade, which make the server unable to start: apt show symas-openldap-server Package: symas-openldap-server Version: 2.6.3-1bullseye1 sudo systemctl status slapd ● symas-openldap-server.service - Symas OpenLDAP Server Daemon Loaded: loaded (/etc/systemd/system/symas-openldap-server.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/symas-openldap-server.service.d └─override.conf /run/systemd/system/service.d └─zzz-lxc-service.conf Active: failed (Result: exit-code) since Fri 2022-08-05 13:20:57 CEST; 8min ago Docs: man:slapd man:slapd-config man:slapd-mdb Process: 536 ExecStart=/opt/symas/lib/slapd -d 0 -h ${SLAPD_URLS} $SLAPD_OPTIONS (code=exited, status=254) Main PID: 536 (code=exited, status=254) CPU: 13ms Aug 05 13:20:57 ldap3.lan.u-v.de systemd[1]: Starting Symas OpenLDAP Server Daemon... Aug 05 13:20:57 ldap3.lan.u-v.de slapd[536]: ldap_int_sasl_init: SASL library version mismatch: expected 2.1.28, got 2.1.27 Aug 05 13:20:57 ldap3.lan.u-v.de systemd[1]: symas-openldap-server.service: Main process exited, code=exited, status=254/n/a Aug 05 13:20:57 ldap3.lan.u-v.de systemd[1]: symas-openldap-server.service: Failed with result 'exit-code'. Aug 05 13:20:57 ldap3.lan.u-v.de systemd[1]: Failed to start Symas OpenLDAP Server Daemon. dpkg -l|grep sasl ii gsasl-common 1.10.0-4+deb11u1 all GNU SASL platform independent files ii libgsasl7:amd64 1.10.0-4+deb11u1 amd64 GNU SASL library ii libsasl2-2:amd64 2.1.27+dfsg-2.1+deb11u1 amd64 Cyrus SASL - authentication abstraction library ii libsasl2-modules:amd64 2.1.27+dfsg-2.1+deb11u1 amd64 Cyrus SASL - pluggable authentication modules ii libsasl2-modules-db:amd64 2.1.27+dfsg-2.1+deb11u1 amd64 Cyrus SASL - pluggable authentication modules (DB) ii libsasl2-modules-gssapi-mit:amd64 2.1.27+dfsg-2.1+deb11u1 amd64 Cyrus SASL - pluggable authentication modules (GSSAPI) rc sasl2-bin 2.1.27+dfsg-2.1+deb11u1 amd64 Cyrus SASL - administration programs for SASL users database ii symas-cyrus-sasl-lib 2.1.27-4bullseye1 amd64 Cyrus-SASL Libraries Any help is appreciated. Best regards Ulf

3 3

OpenLDAP on Debian 11: missing TLS ciphers?
by Jochen Keutel 03 Aug '22

03 Aug '22

Hello, we installed the standard OpenLDAP package on Debian 11. Checking the TLS ciphers offered by the server we could see that all six Camellia ciphers are gone (128 and 256, for TLS 1.0, 1.1, 1.2) compared with the standard OpenLDAP package on Debian 9. Is this special to the Debian package? Or: Has Gnutls changed something? We did run into this issue because some special devices (e.G. Cisco Prime Collaboration Assurance) cannot connect to the new OpenLDAP server. The server logfile states: TLS handshake: negotiation failure. It's not yet clear whether they really can "speak" only Camellia ... Regards Jochen.

5 7

Severe Performance Problems with dynlist on OpenLDAP 2.5+
by Bradley T Gill 02 Aug '22

02 Aug '22

We have been struggling with an upgrade of OpenLDAP 2.4.x to any version after 2.5. Our upgrade process was installing the binaries, removing our ppolicy schema and doing a slapcat of the old database and a slapadd to the new version. After doing so, response time shows a noticeable delay using an ldapsearch, the header on the response will pause long enough to read it before we get the result. This delay is causing the server to hang during heavy use and eventually crash. Through a lot of trouble shooting / trial and error, I have found that the cause is our dynlist definitions/usage. When they are removed, response time goes back to normal and there is a memory leak that stops. I can add the pertinent parts of the cn=config if needed. The question for now is has anyone else seen and hopefully resolved this issue or just know what changed for dynlist in 2.5 that might be effecting us? Thanks, Bradley Gill CISSP, CCSP

2 1

OpenLDAP 2.6 is holding connections open
by Bradley T Gill 02 Aug '22

02 Aug '22

All, I have been struggling with upgrading OpenLDAP from 2.4 to 2.5/2.6 for some time. We have finally found that we needed to rebuild the schema from scratch and re-add our customizations. The database is now running much better with one lingering problem. Our Established connections just continues to grow until we run out of resources. Below is our cn=config (minus some unrelated info). This is on the same server as where the previous version was running, so changes are openldap and openssl versions. Any insights as to what might be causing the ESTABLISHED connections to continually grow would be very appreciated. # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 422b88f4 dn: cn=config objectClass: olcGlobal cn: config olcAttributeOptions: lang- olcConcurrency: 0 olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 0 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexHash64: FALSE olcIndexIntLen: 4 olcListenerThreads: 1 olcLocalSSF: 71 olcLogLevel: 256 olcLogFileOnly: FALSE olcMaxFilterDepth: 1000 olcReadOnly: FALSE olcSaslAuxpropsDontUseCopyIgnore: FALSE olcSaslSecProps: noplain,noanonymous olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 16 olcThreadQueues: 1 olcTLSCRLCheck: none olcTLSVerifyClient: never olcTLSProtocolMin: 0.0 olcToolThreads: 1 structuralObjectClass: olcGlobal creatorsName: cn=config createTimestamp: 20220726200129Z olcAuthzPolicy: any olcWriteTimeout: 30 olcSizeLimit: size.soft=unlimited size.hard=unlimited size.unchecked=unlimited size.pr=1000 size.prtotal=unlimited

3 5

SASL GSSAPI Channel Binding testing
by Andreas Hasenack 26 Jul '22

26 Jul '22

Hello, openldap 2.5.12 cyrus-sasl 2.1.28 + sasl channel binding patch[1] + gss-spnego maxssf=0 patch[2] openldap linked with gnutls libsasl2-modules-gssapi-mit I'm currently testing the patches[1][2] for sasl channel binding over GSSAPI + ssl/tls connection, and was wondering if I could get openldap to reject ldaps connections without sasl channel binding. Currently it seems to always accept it, but I can't be sure CB was even checked by the server by looking at logs (even with -d -1). I got windows 2016 AD to reject ldaps connections without CB over gssapi and gss-spnego, so the client part of openldap (ldapwhoami specifically) seems ok. I looked at test 077[3] and it runs the server with this configuration: dn: cn=config changetype: modify replace: olcSaslCBinding olcSaslCBinding: ${acb} Where `${acb}` loops over the 3 valid values of "none" "tls-unique" "tls-endpoint". Then a simple connection with ldapwhoami is attempted, also looping -o SASL_CBINDING=$icb over those values. I have seen the comment in that test script that it looks like tls-unique is broken when used with gnutls[4], and also a comment about MIT failing in another case[5]. When trying it manually, though, I could never get the client connection to be refused by the server. Before digging in deeper, let me just ask if my understanding is correct: - server configured with: dn: cn=config changetype: modify replace: olcSaslCBinding olcSaslCBinding: tls-endpoint - client connecting to that server over ldaps://, with GSSAPI, and with -o SASL_CBINDING=none Should that client be rejected? Sample run: $ sudo ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b cn=config '(olcSaslCBinding=*)' olcSaslCBinding SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: cn=config olcSaslCBinding: tls-endpoint $ ldapwhoami -Y GSSAPI -H ldaps://k-slapd.lxd -o SASL_CBINDING=none SASL/GSSAPI authentication started SASL username: ubuntu@VMS SASL SSF: 256 SASL data security layer installed. dn:uid=ubuntu,cn=gssapi,cn=auth And the server logs (olcLogLevel: stats): Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 fd=14 ACCEPT from IP=10.0.100.36:33800 (IP=0.0.0.0:636) Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 fd=14 TLS established tls_ssf=256 ssf=256 tls_proto=TLS1.3 tls_cipher=AES-256-GCM Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=0 BIND dn="" method=163 Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=0 RESULT tag=97 err=14 qtime=0.000011 etime=0.002447 text=SASL(0): successful result: Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=1 BIND dn="" method=163 Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=1 RESULT tag=97 err=14 qtime=0.000012 etime=0.000069 text=SASL(0): successful result: Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=2 BIND dn="" method=163 Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=2 BIND authcid="ubuntu" authzid="ubuntu" Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=2 BIND dn="uid=ubuntu,cn=gssapi,cn=auth" mech=GSSAPI bind_ssf=256 ssf=256 Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=2 RESULT tag=97 err=0 qtime=0.000012 etime=0.000109 text= Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=3 EXT oid=1.3.6.1.4.1.4203.1.11.3 Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=3 WHOAMI Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=3 RESULT oid= err=0 qtime=0.000016 etime=0.000087 text= Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=4 UNBIND Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 fd=14 closed 1. https://github.com/cyrusimap/cyrus-sasl/commit/975edbb69070eba6b035f08776de… 2. https://github.com/cyrusimap/cyrus-sasl/pull/603/commits 3. https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5/test… 4. https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5/test… 5. https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5/test…

2 3

help ldap_sasl_bind_s failed (-1)
by mohammad jamshidi 17 Jul '22

17 Jul '22

HiI have configured the openldap multimaster based on this guide: https://kifarunix.com/setup-openldap-master-master-replication-on-centos-8/ but the replication between two servers doesn't work. and I get these errors: on server1: slap_client_connect: URI=ldaps://ldapmaster02.kifarunix-demo.com DN="cn=admin,dc=ldapmaster,dc=kifarunix-demo,dc=com" ldap_sasl_bind_s failed (-1) on server 2:slap_client_connect: URI=ldaps://ldapmaster01.kifarunix-demo.com DN="cn=admin,dc=ldapmaster,dc=kifarunix-demo,dc=com" ldap_sasl_bind_s failed (-1). I didn't receive any reply from the article writer.what is wrong in the guide? Regards

1 0

Re: Pass-through
by Stéphane Veyret 14 Jul '22

14 Jul '22

> Ok, you may need to run slapd under debug mode (-1) and then try binding as > one of the users with userPassword set to the {SASL}username@realm value > to see what it's doing. Is this what I did in my first post (https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/…, the log is at the end of the message) or is there some missing information ? By the way, I don’t know why GMail is starting a new thread each time I answer to you… :-/

1 0

Re: Pass-through
by Stéphane Veyret 14 Jul '22

14 Jul '22

Le lun. 11 juil. 2022 à 17:22, Quanah Gibson-Mount <quanah(a)fast-mail.org> a écrit : > Do the logs from saslauthd show that LDAP is actually forwarding the > requests to it? No, I have nothing at saslauthd side, except the starting logs : # saslauthd -d -a kerberos5 saslauthd[31345] :num_procs : 5 saslauthd[31345] :mech_option: NULL saslauthd[31345] :run_path : /run/saslauthd saslauthd[31345] :auth_mech : kerberos5 saslauthd[31345] :using accept lock file: /run/saslauthd/mux.accept saslauthd[31345] :master pid is: 0 saslauthd[31345] :listening on socket: /run/saslauthd/mux saslauthd[31345] :using process model saslauthd[31345] :forked child: 31346 saslauthd[31346] :acquired accept lock saslauthd[31345] :forked child: 31347 saslauthd[31345] :forked child: 31348 saslauthd[31345] :forked child: 31349 -- Bien cordialement, / Plej kore, Stéphane Veyret

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical