openldap-technical

openldap-technical@openldap.org

9 participants
9902 discussions

basic ldap functions
by Friedrich Locke 28 Sep '15

28 Sep '15

Hi folks! i would like to implement a simple interface ldap to connect my client programs to the sever ldap machine in my job. I would like to implement only the necessary in order to my client app to handle ldap. My listing of function goes below: 0. Connecting, disconnecting, authenticating ldap_connect, ldap_open, ldap_bind and ldap_unbind. 1. Searching and retrieving entries ldap_search, ldap_first_entry and ldap_next_entry. 2. Manipulating entries ldap_add, ldap_modify, ldap_modrdn, ldap_delete and ldap_compare. What are the RFC for this function (of course i will implement in ANSI C) ? How to organize data to be sent to the ldap server ? How to decode the data from the ldap server ? etc ..... Thanks a lot for your time and cooperation. Best regards, Fried.

3 2

Net::LDAPapi syncrepl working only intermittently in 2.4.42
by Nat Sincheler 28 Sep '15

28 Sep '15

I have Perl script that implements a syncrepl listener using the listen_for_changes method from Net::LDAPapi (3.0.3). The listener works well with OpenLDAP 2.4.40 but I am having trouble getting it to work consistently with 2.4.42. The code looks something like this: # $LDAP is bound using GSSAPI my $msgid = $LDAP->listen_for_changes( -basedn => "cn=accesslog", -scope => LDAP_SCOPE_SUBTREE, -filter => "objectclass=*", -cookie => "/var/run/sync.cookie"); while (1) { my @entries; while (@entries = $LDAP->next_changed_entries($msgid, 0, -1))) { ... } Most of the time (but not _all_ of the time) the listener fails to pick up any entries from the accesslog and I see these messages in my logs: 2015-09-09T08:32:20.926931-07:00 ldap-jessie0 slapd[631]: conn=1161 op=4 SEARCH RESULT tag=101 err=2 nentries=0 text=Sync control : mode decoding error 2015-09-09T08:32:20.927211-07:00 ldap-jessie0 slapd[631]: conn=1161 op=4 do_search: get_ctrls failed (Fuller log output included below). I know that the credentials can read the access log as I run a simple search against cn=accesslog before the list_for_changes just to be sure the issue is not related to my credentials. What does "Sync control : mode decoding error" mean? Any suggestions on next steps for troubleshooting? #################################################################### 2015-09-09T08:32:20.902032-07:00 ldap-jessie0 slapd[631]: conn=1161 fd=14 ACCEPT from IP=171.67.214.66:39646 (IP=0.0.0.0:389) 2015-09-09T08:32:20.902108-07:00 ldap-jessie0 slapd[631]: conn=1161 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" 2015-09-09T08:32:20.902207-07:00 ldap-jessie0 slapd[631]: conn=1161 op=0 SRCH attr=supportedSASLMechanisms 2015-09-09T08:32:20.902262-07:00 ldap-jessie0 slapd[631]: conn=1161 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= 2015-09-09T08:32:20.910842-07:00 ldap-jessie0 slapd[631]: conn=1161 op=1 BIND dn="" method=163 2015-09-09T08:32:20.914261-07:00 ldap-jessie0 slapd[631]: conn=1161 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: mech EXTERNAL is too weak 2015-09-09T08:32:20.917754-07:00 ldap-jessie0 slapd[631]: conn=1161 op=2 BIND dn="" method=163 2015-09-09T08:32:20.917798-07:00 ldap-jessie0 slapd[631]: conn=1161 op=2 RESULT tag=97 err=14 text=SASL(0): successful result: mech EXTERNAL is too weak 2015-09-09T08:32:20.918060-07:00 ldap-jessie0 slapd[631]: conn=1161 op=3 BIND dn="" method=163 2015-09-09T08:32:20.918102-07:00 ldap-jessie0 slapd[631]: conn=1161 op=3 BIND authcid="service/ldap-jessie0(a)stanford.edu" authzid="service/ldap-jessie0(a)stanford.edu" 2015-09-09T08:32:20.918188-07:00 ldap-jessie0 slapd[631]: conn=1161 op=3 BIND dn="cn=ldap-jessie0,cn=service,cn=applications,dc=stanford,dc=edu" mech=GSSAPI sasl_ssf=56 ssf=56 2015-09-09T08:32:20.918240-07:00 ldap-jessie0 slapd[631]: conn=1161 op=3 RESULT tag=97 err=0 text= 2015-09-09T08:32:20.926931-07:00 ldap-jessie0 slapd[631]: conn=1161 op=4 SEARCH RESULT tag=101 err=2 nentries=0 text=Sync control : mode decoding error 2015-09-09T08:32:20.927211-07:00 ldap-jessie0 slapd[631]: conn=1161 op=4 do_search: get_ctrls failed

3 5

unique contraint bypassed by java modify (and correctly enforced by pytho/ldapmodify)
by Alessandro Dentella 28 Sep '15

28 Sep '15

Hi, i have been stryggling with a unique contraint that i being constrantly bypassed by a java script. I setup the ldap server and unique layer and I virified that the uniquened on a field is correctly enforce using ldapmodify, ldapvi, python and one more widget tool. There is a java program I have not written (I don't know java) that constantly bypasses the constraint and I can't really understand how it can. It seems to perform the same operation I do: given an existing item, change mail field. What can it be that is different from one and the other situation? All programs connect with simple authentication + tls. Thanks for any possible hints sandro *:-) PS: I thought to bypass this problem switching to back-sql + PostgreSQL so that I openned up to other problems, subject of a separate email...

5 6

OS X Yosemite clients
by oldap＠mountainlake.k12.mn.us 25 Sep '15

25 Sep '15

I am not able to authenticate users on OS X Yosemite (10.10.5) using OpenLDAP on a Linux server running slapd 2.4.40. This has worked with other versions (10.9, 10.7, etc) going back a very long time. The logs and other tests (such as "id user") show that it is successfully accessing the LDAP data. It just won't authenticate with the password. Has anyone successfully transitioned from OS 10.9 to 10.10 Yosemite with respect to authenticating off of OpenLDAP? What is the best forum for me to start digging into this problem? -- Jon

1 0

back-sql: trasnlating examples from slapd.cong to slapd.d
by Alessandro Dentella 24 Sep '15

24 Sep '15

Hi, I'm trying to configure slapd with back-sql (specifically postgresql backend). All documents I found (Postgresq LDAP Howto seems to be more complete) are related to old configuration that use slapd.conf while I need to use the news slapd.d dynamic one. I can't understand how I should add the entry in the configuration. What I currenty tried is: dn: olcDatabase={1}sql,cn=config objectClass: olcDatabaseConfig objectClass: olcSqlConfig olcSuffix: dc=vega,dc=com olcDatabase: sql olcDbName: mytest But when I run ldapmify I get the error: root@argo-jessie:~# ldapmodify -x -D cn=admin,cn=config -W -f ,ldapvi-argo-jessie-7228.ldif Enter LDAP Password: adding new entry "olcDatabase={1}sql,cn=config" ldap_add: Other (e.g., implementation specific) error (80) additional info: <olcSuffix> failed startup And at 254 debugLevel I get: Sep 23 16:34:18 localhost slapd[5650]: olcSuffix: value #0: <olcSuffix> failed startup (dc=vega,dc=com)! Sep 23 16:34:18 localhost slapd[5650]: send_ldap_result: err=80 matched="" text="<olcSuffix> failed startup" I'm making the test on Debian Jessie with slapd versione 2.4.40 sandro *:-) I opended a question on serverfault: http://serverfault.com/questions/724329/slapd-configuration-for-back-sql-ho… -- Sandro Dentella *:-) http://www.reteisi.org Soluzioni libere per le scuole http://sqlkit.argolinux.org SQLkit home page - PyGTK/python/sqlalchemy

2 1

ACLs whont work
by Fischer, Johannes 23 Sep '15

23 Sep '15

Hi @all, I struggle with the ACLs, I whant a special account to check the username and PW of the entries on the LDAP-server. Therefore I’ve written the following in the slapd.conf file: access to attrs=userPassword by dn="cn=authenticate,dc=vfk,dc=ldap,dc=com" write by self write by anonymous none access to * by * write by anonymous none But I can’t authenticate to the LDAP server, does somebody know why? Greetings John

4 4

Translucent overlay search fails with TLS "cannot find private key for certificate"
by Ernie Kovak 22 Sep '15

22 Sep '15

Hello - I'm running openldap 2.4.39 on centos 7, using the translucent overlay and moznss for connections to the backend Active Directory server. When I issue a search request for users in the backend directory I get no results and a "server not available" error - see the debug output below. The same slapd.conf configuration, but on centos 5.10 and using OpenSSL, works correctly. So, I imagine it's related to moznss. I've verified (firewall logs) that openldap successfully connects to the backend on startup, but not when the search request is submitted. It looks like it's trying to use client-authenticated TLS, even though the backend is not set up for that?? Any ideas? Thanks! Ernie =============================================================================================== slapd.conf =============================================================================================== include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/we_person_and_npe.schema pidfile /var/run/openldap/slapd.pid loglevel stats #loglevel -1 #loglevel trace conns filter stats # Path to dynamic modules: modulepath /usr/lib64/openldap moduleload back_mdb moduleload back_ldap moduleload translucent moduleload accesslog moduleload auditlog moduleload valsort moduleload ppolicy moduleload memberof # TLS server certs (TLS client config is in ldap.conf) #TLSCACertificateFile /opt/acme/global/certs/ca/ca.pem #TLSCertificateFile /opt/acme/global/certs/server-cert.pem #TLSCertificateKeyFile /opt/acme/global/certs/server-key.pem # not working in our docker container since openldap is linked against NSS and not OpenSSL #TLSCipherSuite TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL:!SSLv2 # path of the directory containing the NSS certificate and key database files TLSCACertificatePath /opt/acme/local/certs/nssdb/ # specifies the name of the certificate to use TLSCertificateFile server # name of a file that contains the password for the key for the certificate specified with TLSCertificateFile TLSCertificateKeyFile /opt/acme/local/certs/.nss_tmp_pwd (contains clear text pasword for keystore and server cert private key) access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to attrs=clearance,citizenship,sciControl by dn="cn=npe-user-mgmt,ou=NPEs,ou=Native,dc=acme,dc=com" write by dn="cn=npe-sts,ou=NPEs,ou=Native,dc=acme,dc=com" read access to attrs=gimmeeOrg,gimmeeRegion,gimmeeTopic,gimmeeIsAICP,gimmeeGroup,gimmeeProject,gimmeeProjectGroup by dn="cn=npe-user-mgmt,ou=NPEs,ou=Native,dc=acme,dc=com" write by dn="cn=npe-sts,ou=NPEs,ou=Native,dc=acme,dc=com" read access to attrs=UUID by dn="cn=npe-user-mgmt,ou=NPEs,ou=Native,dc=acme,dc=com" write by users read access to attrs=userPassword by dn="cn=npe-user-mgmt,ou=NPEs,ou=Native,dc=acme,dc=com" write by self write by anonymous auth access to attrs=currentLoginDate,lastLoginDate,lastFailedLoginDate,currentLoginIpAddr,lastLoginIpAddr,lastFailedLoginIpAddr by dn="cn=npe-user-mgmt,ou=NPEs,ou=Native,dc=acme,dc=com" write by dn="cn=npe-openid,ou=NPEs,ou=Native,dc=acme,dc=com" write by users read access to * by dn="cn=npe-user-mgmt,ou=NPEs,ou=Native,dc=acme,dc=com" write by users read by anonymous auth ####################################################################### # Database for Native accounts (NPEs and users) ####################################################################### database mdb suffix "ou=Native,dc=acme,dc=com" rootdn "cn=weAdmin,dc=acme,dc=com" directory "/opt/acme/global/data/openldap/db/native-user-db" subordinate index objectClass eq,pres index ou,cn,mail,surname eq,pres,sub index clearance,scicontrol eq,pres,sub index citizenship eq,pres,sub password-hash {SSHA} # Apply password policy overlay to Native accounts, with a default policy. overlay ppolicy ppolicy_default "cn=default,ou=Policies,ou=Native,dc=acme,dc=com" ppolicy_use_lockout ppolicy_hash_cleartext ####################################################################### # Database for additional attributes for enterprise accounts. ####################################################################### database mdb suffix "dc=acme,dc=com" rootdn "cn=weAdmin,dc=acme,dc=com" rootpw {SSHA}73M5MnfH97O8KAN8anAbneD2wf0C6VSg directory "/opt/acme/global/data/openldap/db/enterprise-user-db" index objectClass eq,pres index ou,cn,mail,surname eq,pres,sub index clearance,scicontrol eq,pres,sub index citizenship eq,pres,sub ####################################################################### # Translucent LDAP proxy to Active Directory ####################################################################### overlay translucent uri "ldaps://atlas.acme.com:636" chase-referrals no idassert-bind bindmethod=simple binddn="cn=devadmin,ou=Users,ou=System Accounts,ou=Acme,dc=acme,dc=com" credentials="******" mode=none tls_cacert=/opt/acme/global/certs/ca/gd-class2-root-2.pem tls_reqcert=demand # Attributes to be searched for in local database. Only the classes that # apply to proxied accounts are candidates for translucent_local: # local wePerson attributes: translucent_local objectClass translucent_local UUID,accountStatus translucent_local rank,grade,position,command,agency translucent_local DSN translucent_local weGrp,weOrg translucent_local clearance,citizenship,scicontrol # wePerson attributes pulled from remote directory: translucent_remote objectClass translucent_remote cn,givenName,sn,mail,o,mobile translucent_remote displayName,sAMAccountName,userPrincipalName =============================================================================================== >From output when setting SLAPD_OPTIONS="-d 65535" =============================================================================================== <snip> loads slapd.conf 55f854a6 config_build_entry: "olcDatabase={2}mdb" 55f854a6 config_build_entry: "olcOverlay={0}translucent" 55f854a6 ==> translucent_cfadd 55f854a6 config_build_entry: "olcDatabase={0}ldap" 55f854a6 config_build_entry: "olcOverlay={1}glue" 55f854a6 backend_startup_one: starting "ou=Native,dc=acme,dc=com" 55f854a6 mdb_db_open: "ou=Native,dc=acme,dc=com" 55f854a6 mdb_db_open: database "ou=Native,dc=acme,dc=com": dbenv_open(/opt/acme/global/data/openldap/db/native-user-db). 55f854a6 mdb_monitor_db_open: monitoring disabled; configure monitor database to enable 55f854a6 backend_startup_one: starting "dc=acme,dc=com" 55f854a6 mdb_db_open: "dc=acme,dc=com" 55f854a6 mdb_db_open: database "dc=acme,dc=com": dbenv_open(/opt/acme/global/data/openldap/db/enterprise-user-db). 55f854a6 ==> translucent_db_open 55f854a6 backend_startup_one: starting "dc=acme,dc=com" 55f854a6 ldap_back_db_open: URI=ldaps://atlas.acme.com:636 55f854a6 ldap_back_monitor_db_open: monitoring disabled; configure monitor database to enable 55f854a6 slapd starting <snip> 55f876ea ==> translucent_search: <dc=acme,dc=com> (sAMAccountName=admin) ldap_create ldap_url_parse_ext(ldaps://atlas.acme.com:636) 55f876ea =>ldap_back_getconn: conn=1000 op=1: lc=0x7f3e581a9950 inserted refcnt=1 rc=0 ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP atlas.acme.com:636 55f876ea daemon: activity on 1 descriptor 55f876ea daemon: activity on:55f876ea 55f876ea daemon: epoll: listen=6 active_threads=0 tvp=NULL 55f876ea daemon: epoll: listen=7 active_threads=0 tvp=NULL ldap_new_socket: 17 ldap_prepare_socket: 17 ldap_connect_to_host: Trying 172.12.3.45:636 ldap_pvt_connect: fd: 17 tm: -1 async: 0 attempting to connect: connect success TLS: certdb config: configDir='/opt/acme/local/certs/nssdb/' tokenDescription='ldap(1)' certPrefix='' keyPrefix='' flags=readOnly TLS: using moznss security dir /opt/acme/local/certs/nssdb/ prefix . TLS: loaded CA certificate file /opt/acme/global/certs/ca/gd-class2-root-2.pem. TLS: certificate 'server' successfully loaded from moznss database. TLS: no unlocked certificate for certificate 'CN=mv22.acme.com ,OU=Development,O=Acme,L=Denver,ST=Colorado,C=US'. TLS: cannot find private key for certificate 'CN=mv22.acme.com,OU=Development,O=Acme,L=Denver,ST=Colorado,C=US' (error -12285: Unable to find the certificate or key necessary for authentication.) TLS: error: unable to set up client certificate authentication for certificate named CN=mv22.acme.com ,OU=Development,O=Acme,L=Denver,ST=Colorado,C=US TLS: error: unable to set up client certificate authentication using 'CN= mv22.acme.com,OU=Development,O=Acme,L=Denver,ST=Colorado,C=US' TLS: error: could not initialize moznss security context - error -12285:Unable to find the certificate or key necessary for authentication. TLS: can't create ssl handle. 55f876ea send_ldap_result: conn=1000 op=1 p=3 55f876ea send_ldap_result: err=52 matched="" text="Proxy operation retry failed"

1 2

funny error
by Fischer, Johannes 22 Sep '15

22 Sep '15

Hi, I’ve just had some funny moments with openldap. I had some bad written code (from my self ☺) where I’ve tried to set a description (2.5.4.13) attribute with an empty string (“”). The result was a error massage: description: value #0 invalid per syntax the best Thing about that is, that the Spring security framework interpreted the error for a following Boolean attribute. This is only for your amusement and to help other with similar problems Greetings John

2 1

seg faults with slapd and libc?
by jason cafarelli 19 Sep '15

19 Sep '15

Hello, centos 6.5 with a basic slapd setup; internal LDAP and proxy to external LDAP Getting segaults every 6 hours or so when I let QA on system and generate some typical user load. All 32 threads halt; ldapsearch stops responding. Typically no logs; last one dropped this: ie: Sep 18 07:47:58 maryann2 kernel: slapd[53754]: segfault at 7f3083ffff98 ip 00007f3104cc3532 sp 00007f30a5ff9660 error 6 in libc-2.12.so [7f3104c4a000+18b000] Should i just sledgehammer a yum update and get off centos 6.5? *Jason K Cafarelli* Desk: (508) 637-5705 (primary) Mobile: (508) 215-9712 jason.cae(a)gmail.com

2 2

HDB compared with LMDB
by Philip Colmer 17 Sep '15

17 Sep '15

We're currently using OpenLDAP 2.4.38 on our production server using HDB as the database type. I wanted to upgrade to the latest version and take advantage of LMDB as the database type so I've built a second server and transferred the data. Before making that server the production server, we're running performance comparisons, using ldclt[1] as a stress test tool. I don't know if anyone else has got any experience of using this tool; the output we're getting when running the tool doesn't show significant differences in performance, but I'm not sure if it is just the test type we're running or the fact that, actually, we shouldn't be expecting significant differences ... I've included the output below. I've removed the details of our servers from the command line. Can someone who has made a transition from HDB to LMDB give an indication of whether or not we should see a performance difference on LDAP queries and, if yes, by what sort of factor? If you are familiar with ldclt, should we be running different tests to get a better insight into how the two servers compare? Thanks. Philip [1] http://docs.oracle.com/cd/E19957-01/816-6400-10/ldclt.html 2.4.38 with HDB: ldclt -f uid=testXXXXX -e esearch,random -r0 -R99999 -I 32 ldclt version 4.23 ldclt[1979]: Starting at Thu Sep 17 11:28:51 2015 ldclt[1979]: Average rate: 109.70/thr ( 109.70/sec), total: 1097 ldclt[1979]: Average rate: 114.80/thr ( 114.80/sec), total: 1148 ldclt[1979]: Average rate: 115.00/thr ( 115.00/sec), total: 1150 ldclt[1979]: Average rate: 111.90/thr ( 111.90/sec), total: 1119 ldclt[1979]: Average rate: 115.20/thr ( 115.20/sec), total: 1152 ldclt[1979]: Average rate: 114.80/thr ( 114.80/sec), total: 1148 ldclt[1979]: Average rate: 113.70/thr ( 113.70/sec), total: 1137 ldclt[1979]: Average rate: 111.20/thr ( 111.20/sec), total: 1112 ldclt[1979]: Average rate: 114.80/thr ( 114.80/sec), total: 1148 ldclt[1979]: Global average rate: 1021.10/thr (113.46/sec), total: 10211 2.4.41 with MDB: ldclt -f uid=testXXXXX -e esearch,random -r0 -R99999 -I 32 ldclt version 4.23 ldclt[1967]: Starting at Thu Sep 17 11:26:55 2015 ldclt[1967]: Average rate: 109.70/thr ( 109.70/sec), total: 1097 ldclt[1967]: Average rate: 111.00/thr ( 111.00/sec), total: 1110 ldclt[1967]: Average rate: 112.20/thr ( 112.20/sec), total: 1122 ldclt[1967]: Average rate: 113.00/thr ( 113.00/sec), total: 1130 ldclt[1967]: Average rate: 112.70/thr ( 112.70/sec), total: 1127 ldclt[1967]: Average rate: 112.50/thr ( 112.50/sec), total: 1125 ldclt[1967]: Average rate: 113.00/thr ( 113.00/sec), total: 1130 ldclt[1967]: Average rate: 112.80/thr ( 112.80/sec), total: 1128 ldclt[1967]: Average rate: 112.30/thr ( 112.30/sec), total: 1123 ldclt[1967]: Average rate: 112.90/thr ( 112.90/sec), total: 1129 ldclt[1967]: Global average rate: 1122.10/thr (112.21/sec), total: 11221

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical