openldap-technical

openldap-technical@openldap.org

14 participants
9796 discussions

Re: ldapsearch utility
by Peter Sui 07 Jan '20

07 Jan '20

Hi Quanah, Thank you for your response. I figured what you said in your response, and I have another question about the SASL. I have a ldap testing server, let's say the url is test.sample.net, and when I run the following command: ldapsearch -H ldap://test.sample.net:389 -x -b "" -s base -LLL supportedSASLMechanisms it returned: dn: supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: NTLM then I run the command: ldapsearch -H ldap://test.sample.net:389 -Y DIGEST-MD5 then it prompt: SASL/DIGEST-MD5 authentication started Please enter your password: I give a password, then it prompt: ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: no secret in database so question here, what password it asked here? since it's not asking for a DN. There could be many credentials here, will the server figure out the user by the password input? Thank you! Peter On Mon, Jan 6, 2020 at 8:17 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Tuesday, December 31, 2019 10:44 AM -0500 Peter Sui <peters(a)qnext.com> > > wrote: > > > if I run: > > ldapsearch -h ldap.forumsys.com -p 636 -b "" -s base "(objectClass=*)" > -D > > "cn=read-only-admin,dc=example,dc=com" -w password -Z > > It is not valid to combine startTLS with port 636. Also, you should > update > your options to match modern standards. > > > Example against ldaps:/// > > ldapsearch -H ldaps://ldap.forumsys.com:636 > > as opposed to > > ldapsearch -h ldap.forumsys.com -p 636 > > Example against ldap:/// > > ldapsearch -H ldap://ldap.forumsys.com:389 > > as opposed to > > ldapsearch -h ldap.forumsys.com -p 389 > > > I would note that the -Z(Z) options are for startTLS (generally against > port 389). It is not valid to mix startTLS with ldaps:// URIs. You've > not > provided any useful information about your setup, so it's not possible to > give you much help past that. > > As for your SASL question, as documented in the ldapsearch man page, you > provide the SASL Mech as a parameter to the -Y option. For example: > > ldapsearch -Y GSSAPI -H ldap://ldap.forumsys.com:389 > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 1

RE: ldapsearch utility
by Peter Sui 07 Jan '20

07 Jan '20

Hi, I'm trying to use ldapsearch to do some tests, lets say the testing ldap server host is: ldap.forumsys.com , test 1: if I run: ldapsearch -h ldap.forumsys.com -p 389 -b "" -s base "(objectClass=*)" -D "cn=read-only-admin,dc=example,dc=com" -w password it seems successful, but if I add ssl flag, like run: ldapsearch -h ldap.forumsys.com -p 389 -b "" -s base "(objectClass=*)" -D "cn=read-only-admin,dc=example,dc=com" -w password -Z I got error: ldap_start_tls: Connect error (-11) additional info: (unknown error code) ldap_result: Can't contact LDAP server (-1) if I run: ldapsearch -h ldap.forumsys.com -p 636 -b "" -s base "(objectClass=*)" -D "cn=read-only-admin,dc=example,dc=com" -w password -Z I got error: ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) so how can I do a search with ssl? test 2: this is about SASL authentication. Lets say the SASL mech is DIGEST-MD5, or EXTERNAL, or GSSAPI, what ldapsearch command should I run? I tried many, it did not work. Thanks! Peter Sui

2 1

please repost link to question "How to build OpenLDAP against specific OpenSSL install"
by Dunne, Kenneth 07 Jan '20

07 Jan '20

I found this, but get a 404 error following it: >The new OpenSSL 1.0.1e header files are located under /usr/local/include/openssl and the >libs are in /usr/local/lib64. <https://github.com/Zimbra-Community/zimbra-sources/blob/master/main/ThirdPa…> --Quanah

2 1

Issues with OpenLdap using OpenTLS
by Dunne, Kenneth 04 Jan '20

04 Jan '20

All I am able to connect to my home-built OpenSSL installation (from Dec-19 sources) on CentOS-7 without the TLS bind. I am now trying to use OpenTLS with OpenSSL, which is not currently working. From searching the internet I find this, Which indicates that maybe RH-based-unixes have unique issues with OpenTLS/OpenLdap: https://serverfault.com/questions/437546/centos-openldap-cert-trust-issues My slapd.conf now holds (as differs from the default installed slapd.conf) ... snip... ############### TLS # added per http://www.openldap.org/faq/data/cache/185.html TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt TLSCertificateFile /usr/local/etc/openldap/servercrt.pem TLSCertificateKeyFile /usr/local/etc/openldap/serverkey.pem TLSCipherSuite DES-CBC3-SHA ... snip... And my ldap.conf holds: ... snip... ############### TLS ############### TLS # added per http://www.openldap.org/faq/data/cache/185.html TLS_CACERT /etc/pki/tls/certs/ca-bundle.crt ### fails: ## TLS_CACERT /usr/local/etc/openldap/ cacert.pem URI ldaps://localhost:636 ############### TLS ... snip... .... Having added the 'cacert.pem' into the file " /etc/pki/tls/certs/ca-bundle.crt" I get farther in the authentication than using "/usr/local/etc/openldap/ cacert.pem": [root@kdunne-dev openldap]# /usr/local/bin/ldapsearch -Z -D "cn=Manager,dc=my-domain,dc=com" -d -1 ldap_create ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying ::1 636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect errno: 111 ldap_close_socket: 3 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 127.0.0.1:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success TLS trace: SSL_connect:before/connect initialization tls_write: want=289, written=289 0000: 16 03 01 01 1c 01 00 01 18 03 03 51 03 78 81 fc ...........Q.x.. 0010: 66 89 9c 91 10 b6 e9 3d f1 12 66 27 c7 f5 80 e4 f......=..f'.... 0020: fb f6 5f 9d f8 bb 37 3b 84 cb 17 00 00 ac c0 30 .._...7;.......0 0030: c0 2c c0 28 c0 24 c0 14 c0 0a 00 a5 00 a3 00 a1 .,.(.$.......... 0040: 00 9f 00 6b 00 6a 00 69 00 68 00 39 00 38 00 37 ...k.j.i.h.9.8.7 0050: 00 36 00 88 00 87 00 86 00 85 c0 32 c0 2e c0 2a .6.........2...* 0060: c0 26 c0 0f c0 05 00 9d 00 3d 00 35 00 84 c0 2f .&.......=.5.../ 0070: c0 2b c0 27 c0 23 c0 13 c0 09 00 a4 00 a2 00 a0 .+.'.#.......... 0080: 00 9e 00 67 00 40 00 3f 00 3e 00 33 00 32 00 31 ...g.@.?.>.3.2.1 0090: 00 30 00 9a 00 99 00 98 00 97 00 45 00 44 00 43 .0.........E.D.C 00a0: 00 42 c0 31 c0 2d c0 29 c0 25 c0 0e c0 04 00 9c .B.1.-.).%...... 00b0: 00 3c 00 2f 00 96 00 41 c0 12 c0 08 00 16 00 13 .<./...A........ 00c0: 00 10 00 0d c0 0d c0 03 00 0a 00 07 c0 11 c0 07 ................ 00d0: c0 0c c0 02 00 05 00 04 00 ff 01 00 00 43 00 0b .............C.. 00e0: 00 04 03 00 01 02 00 0a 00 0a 00 08 00 17 00 19 ................ 00f0: 00 18 00 16 00 23 00 00 00 0d 00 20 00 1e 06 01 .....#..... .... 0100: 06 02 06 03 05 01 05 02 05 03 04 01 04 02 04 03 ................ 0110: 03 01 03 02 03 03 02 01 02 02 02 03 00 0f 00 01 ................ 0120: 01 . TLS trace: SSL_connect:SSLv2/v3 write client hello A tls_read: want=7, got=0 TLS: can't connect: . ldap_err2string ldap_start_tls: Can't contact LDAP server (-1) ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) Additionally: I am reading the FAQ http://www.openldap.org/faq/data/cache/185.html to generate the certs but am wondering if I am correctly understanding the instruction "Remember that the Common Name for this cert should be the fully qualified domain name of the server:" If I run my ldap server as: /usr/local/libexec/slapd -F /usr/local/etc/openldap/slapd.d -h 'ldaps://127.0.0.1:636 ldap://127.0.0.1:389' -d -1 Then would the 'common name' for use in the certificate be: cn=localhost:636 Any assistance is greatly appreciated. Thanks! Ken Dunne

4 5

RE: mdb_stat() crashes under DB_STALE
by Peter Zhu (pezhu) 02 Jan '20

02 Jan '20

Hi, Quanah Thanks for your info. I am forwarding my info to the mailing-list. Cheers, Peter From: Quanah Gibson-Mount <quanah.gibsonmount(a)gmail.com> Sent: Thursday, January 2, 2020 12:18 PM To: Peter Zhu (pezhu) <pezhu(a)cisco.com> Subject: Re: mdb_stat() crashes under DB_STALE I would advise you use the correct methods for asking for assistance. I would start with the openldap-technical mailing list (https://www.openldap.org/lists/) Regards, Quanah On Mon, Dec 23, 2019 at 3:18 PM Peter Zhu (pezhu) <pezhu(a)cisco.com<mailto:pezhu@cisco.com>> wrote: Hi, Folks I am using LMDB 9.24, and have experienced the following crashes: warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. Core was generated by `/ngfw/usr/local/sf/bin/sfhassd -c /etc/sf/sfhassd.conf'. Program terminated with signal SIGSEGV, Segmentation fault. #0 mdb_node_search (mc=mc@entry=0x2b794dbf7320, key=0x560ed4785f30, exactp=exactp@entry=0x2b794dbf730c) at mdb.c:5322 5322 mdb.c: No such file or directory. [Current thread is 1 (LWP 12824)] (gdb) (gdb) bt #0 mdb_node_search (mc=mc@entry=0x2b794dbf7320, key=0x560ed4785f30, exactp=exactp@entry=0x2b794dbf730c) at mdb.c:5322 #1 0x00002b792c57c79f in mdb_page_search (mc=0x2b794dbf74e0, key=key@entry=0x0, flags=flags@entry=2) at mdb.c:5617 #2 0x00002b792c57c960 in mdb_cursor_init (mc=mc@entry=0x2b794dbf74e0, txn=txn@entry=0x2b79600332c0, dbi=dbi@entry=5, mx=mx@entry=0x2b794dbf7670) at mdb.c:7623 #3 0x00002b792c58713d in mdb_stat (txn=0x2b79600332c0, dbi=5, arg=0x2b794dbf7a10) at mdb.c:9856 #4 0x00002b792c798c17 in LMDBCache::GetMstByType (this=0x560ed4782fb0, type=SSL_CACHE_ORIG_CERT, mst=0x2b794dbf7a10, idx=CACHE_TABLE_FIFO) at lmdbCache.cpp:1408 #5 0x00002b792c7946df in LMDBCache::InsertKeyValuePair (this=0x560ed4782fb0, type=SSL_CACHE_ORIG_CERT, key=0x2b794dbf7b60, data=0x2b794dbf7d00, idx=CACHE_TABLE_FIFO, asyncWrite=0) at lmdbCache.cpp:820 #6 0x00002b792c795aae in LMDBCache::InsertFiFoKeyValue (this=0x560ed4782fb0, type=SSL_CACHE_ORIG_CERT, appKey=0x2b794dbf7d00) at lmdbCache.cpp:1007 #7 0x00002b792c795143 in LMDBCache::InsertKeyValuePair (this=0x560ed4782fb0, type=SSL_CACHE_ORIG_CERT, key=0x2b794dbf7d00, data=0x2b794dbf7cf0) at lmdbCache.cpp:907 #8 0x00002b792c7957c4 in LMDBCache::InsertKeyValuePair (this=0x560ed4782fb0, type=SSL_CACHE_ORIG_CERT, key_=0x2b7960033abe "37364826527", value=0x2b7960033ada "moredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredead"...) at lmdbCache.cpp:953 #9 0x00002b792c79a228 in lmdb_insert_to_cache (type=3, key=0x2b7960033abe "37364826527", value=0x2b7960033ada "moredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredead"...) at lmdbCacheCWrapper.cpp:38 #10 0x0000560ed2c37155 in LocalInputThread (thread_handle=thread_handle@entry=0x2b79600008c0, arg=arg@entry=0x2b7950000b40) at local.c:473 #11 0x0000560ed2c38aa2 in _threadlist_create_stub (arg=0x2b794d3f3cc0) at ThreadList.c:174 #12 0x00002b792b8243d4 in ?? () from /lib64/libpthread.so.0 #13 0x00002b792ca8791d in clone () from /lib64/libc.so.6 Can you folks let me know if you can help. Or please forward my email to Howard Chu. Thanks and have Happy Holidays. Peter

1 0

ldapwhoami translate sasl-name to dn
by Stefan Kania 24 Dec '19

24 Dec '19

Hello, I try to do the authentication in LDAP via Kerberos. The Kerberos-Database is in LDAP, no problem, I can login to the system as a normal user but when I do a "ldapwhomami" I get the following output: ----------------- u1-verw@ldapserver:~$ ldapwhoami SASL/GSSAPI authentication started SASL username: u1-verw(a)EXAMPLE.NET SASL SSF: 256 SASL data security layer installed. dn:uid=u1-verw,cn=gssapi,cn=auth ----------------- I would like to get the original DN from the user not the dn:*,cn=gssapi,cn=auth. So I put into my configuration: ----------------- olcAuthzRegexp: {0}uid=(.+),cn=gssapi,cn=auth ldap:///dc=example,dc=net??sub?(uid=$1) ----------------- But still the same. The log-output: ----------------- Dec 20 14:42:34 ldapserver slapd[493]: conn=1082 fd=37 ACCEPT from IP=192.168.56.60:59276 (IP=0.0.0.0:636) Dec 20 14:42:34 ldapserver slapd[493]: conn=1082 fd=37 TLS established tls_ssf=256 ssf=256 Dec 20 14:42:34 ldapserver ldapwhoami[1914]: GSSAPI client step 1 Dec 20 14:42:34 ldapserver ldapwhoami[1914]: GSSAPI client step 1 Dec 20 14:42:34 ldapserver slapd[493]: conn=1082 op=0 BIND dn="" method=163 Dec 20 14:42:34 ldapserver slapd[493]: conn=1082 op=0 RESULT tag=97 err=14 text=SASL(0): successful result: Dec 20 14:42:34 ldapserver ldapwhoami[1914]: GSSAPI client step 1 Dec 20 14:42:34 ldapserver slapd[493]: conn=1082 op=1 BIND dn="" method=163 Dec 20 14:42:34 ldapserver slapd[493]: conn=1082 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: Dec 20 14:42:34 ldapserver ldapwhoami[1914]: GSSAPI client step 2 Dec 20 14:42:34 ldapserver slapd[493]: conn=1082 op=2 BIND dn="" method=163 Dec 20 14:42:34 ldapserver slapd[493]: => access_allowed: auth access to "dc=example,dc=net" "entry" requested Dec 20 14:42:34 ldapserver slapd[493]: => dn: [1] Dec 20 14:42:34 ldapserver slapd[493]: => dn: [2] cn=subschema Dec 20 14:42:34 ldapserver slapd[493]: => dn: [3] dc=example,dc=net Dec 20 14:42:34 ldapserver slapd[493]: => acl_get: [3] matched Dec 20 14:42:34 ldapserver slapd[493]: => acl_get: [3] attr entry Dec 20 14:42:34 ldapserver slapd[493]: => acl_mask: access to entry "dc=example,dc=net", attr "entry" requested Dec 20 14:42:34 ldapserver slapd[493]: => acl_mask: to all values by "", (=0) Dec 20 14:42:34 ldapserver slapd[493]: <= check a_dn_pat: users Dec 20 14:42:34 ldapserver slapd[493]: <= check a_dn_pat: * Dec 20 14:42:34 ldapserver slapd[493]: <= acl_mask: [2] applying none(=0) (stop) Dec 20 14:42:34 ldapserver slapd[493]: <= acl_mask: [2] mask: none(=0) Dec 20 14:42:34 ldapserver slapd[493]: => slap_access_allowed: auth access denied by none(=0) Dec 20 14:42:34 ldapserver slapd[493]: => access_allowed: no more rules Dec 20 14:42:34 ldapserver slapd[493]: conn=1082 op=2 BIND authcid="u1-verw" authzid="u1-verw" Dec 20 14:42:34 ldapserver slapd[493]: conn=1082 op=2 BIND dn="uid=u1-verw,cn=gssapi,cn=auth" mech=GSSAPI sasl_ssf=256 ssf=256 Dec 20 14:42:34 ldapserver slapd[493]: conn=1082 op=2 RESULT tag=97 err=0 text= Dec 20 14:42:34 ldapserver slapd[493]: conn=1082 op=3 EXT oid=1.3.6.1.4.1.4203.1.11.3 Dec 20 14:42:34 ldapserver slapd[493]: conn=1082 op=3 WHOAMI Dec 20 14:42:34 ldapserver slapd[493]: conn=1082 op=3 RESULT oid= err=0 text= Dec 20 14:42:34 ldapserver slapd[493]: conn=1082 op=4 UNBIND Dec 20 14:42:34 ldapserver slapd[493]: conn=1082 fd=37 closed Dec 20 14:42:34 ldapserver ldapwhoami[1914]: DIGEST-MD5 common mech free ----------------- The output is with log-level "acl". When I add the rule: ----------------- olcAccess: {1}to * by * read ----------------- ldapwhoami is working like I expected it: ----------------- u1-verw@ldapserver:~$ ldapwhoami SASL/GSSAPI authentication started SASL username: u1-verw(a)EXAMPLE.NET SASL SSF: 256 SASL data security layer installed. dn:cn=u1 verw,ou=users,ou=verwaltung,ou=firma,dc=example,dc=net ----------------- The log is showing: ----------------- Dec 20 14:46:48 ldapserver slapd[493]: conn=1086 fd=37 ACCEPT from IP=192.168.56.60:59280 (IP=0.0.0.0:636) Dec 20 14:46:49 ldapserver slapd[493]: conn=1086 fd=37 TLS established tls_ssf=256 ssf=256 Dec 20 14:46:49 ldapserver ldapwhoami[1941]: GSSAPI client step 1 Dec 20 14:46:49 ldapserver ldapwhoami[1941]: GSSAPI client step 1 Dec 20 14:46:49 ldapserver slapd[493]: conn=1086 op=0 BIND dn="" method=163 Dec 20 14:46:49 ldapserver slapd[493]: conn=1086 op=0 RESULT tag=97 err=14 text=SASL(0): successful result: Dec 20 14:46:49 ldapserver ldapwhoami[1941]: GSSAPI client step 1 Dec 20 14:46:49 ldapserver slapd[493]: conn=1086 op=1 BIND dn="" method=163 Dec 20 14:46:49 ldapserver slapd[493]: conn=1086 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: Dec 20 14:46:49 ldapserver ldapwhoami[1941]: GSSAPI client step 2 Dec 20 14:46:49 ldapserver slapd[493]: conn=1086 op=2 BIND dn="" method=163 Dec 20 14:46:49 ldapserver slapd[493]: => access_allowed: auth access to "dc=example,dc=net" "entry" requested Dec 20 14:46:49 ldapserver slapd[493]: => dn: [1] Dec 20 14:46:49 ldapserver slapd[493]: => acl_get: [2] attr entry Dec 20 14:46:49 ldapserver slapd[493]: => acl_mask: access to entry "dc=example,dc=net", attr "entry" requested Dec 20 14:46:49 ldapserver slapd[493]: => acl_mask: to all values by "", (=0) Dec 20 14:46:49 ldapserver slapd[493]: <= check a_dn_pat: * Dec 20 14:46:49 ldapserver slapd[493]: <= acl_mask: [1] applying read(=rscxd) (stop) Dec 20 14:46:49 ldapserver slapd[493]: <= acl_mask: [1] mask: read(=rscxd) Dec 20 14:46:49 ldapserver slapd[493]: => slap_access_allowed: auth access granted by read(=rscxd) Dec 20 14:46:49 ldapserver slapd[493]: => access_allowed: auth access granted by read(=rscxd) Dec 20 14:46:49 ldapserver slapd[493]: => access_allowed: auth access to "cn=u1 Verw,ou=users,ou=Verwaltung,ou=firma,dc=example,dc=net" "uid" requested Dec 20 14:46:49 ldapserver slapd[493]: => dn: [1] Dec 20 14:46:49 ldapserver slapd[493]: => acl_get: [2] attr uid Dec 20 14:46:49 ldapserver slapd[493]: => acl_mask: access to entry "cn=u1 Verw,ou=users,ou=Verwaltung,ou=firma,dc=example,dc=net", attr "uid" requested Dec 20 14:46:49 ldapserver slapd[493]: => acl_mask: to value by "", (=0) Dec 20 14:46:49 ldapserver slapd[493]: <= check a_dn_pat: * Dec 20 14:46:49 ldapserver slapd[493]: <= acl_mask: [1] applying read(=rscxd) (stop) Dec 20 14:46:49 ldapserver slapd[493]: <= acl_mask: [1] mask: read(=rscxd) Dec 20 14:46:49 ldapserver slapd[493]: => slap_access_allowed: auth access granted by read(=rscxd) Dec 20 14:46:49 ldapserver slapd[493]: => access_allowed: auth access granted by read(=rscxd) Dec 20 14:46:49 ldapserver slapd[493]: conn=1086 op=2 BIND authcid="u1-verw" authzid="u1-verw" Dec 20 14:46:49 ldapserver slapd[493]: conn=1086 op=2 BIND dn="cn=u1 verw,ou=users,ou=verwaltung,ou=firma,dc=example,dc=net" mech=GSSAPI sasl_ssf=256 ssf=256 Dec 20 14:46:49 ldapserver slapd[493]: conn=1086 op=2 RESULT tag=97 err=0 text= Dec 20 14:46:49 ldapserver slapd[493]: conn=1086 op=3 EXT oid=1.3.6.1.4.1.4203.1.11.3 Dec 20 14:46:49 ldapserver slapd[493]: conn=1086 op=3 WHOAMI Dec 20 14:46:49 ldapserver slapd[493]: conn=1086 op=3 RESULT oid= err=0 text= Dec 20 14:46:49 ldapserver slapd[493]: conn=1086 op=4 UNBIND Dec 20 14:46:49 ldapserver slapd[493]: conn=1086 fd=37 closed Dec 20 14:46:49 ldapserver ldapwhoami[1941]: DIGEST-MD5 common mech free ----------------- So it must have something to with ACLs. I can't figure out where to set the permission to get everything working without opening my ldap for everyone. I tried a lot: ----------------- by dn.regex=authzid="(.+)" read or by dn.regex=authcid="(.+)" read or by dn.regex=uid=(.+),cn=gssapi,cn=auth read ----------------- Non of the above is working. Any hint? Stefan l

5 7

ldap_bind: Invalid credentials at LDAPADD step in the QuickStart Guide
by Dunne, Kenneth 23 Dec '19

23 Dec '19

All I am new to LDAP, reading through the quickstart guide, and the first 6 chapters of the OpenLDAP Admin Guide leaves me with being unable to add entries into LDAP. I've compiled from sources per chapter 4, and also tried the YUM installed versions of the ldap client and server on my CentOS-7, with the same result. Summarized, the steps I am performing after the build/install of both master (as of Dec-19-2019) and tag OPENLDAP_REL_ENG_2_4_48 are: sudo mkdir /usr/local/etc/openldap/slapd.d sudo chmod 777 /usr/local/etc/openldap/slapd.d sudo mkdir /usr/local/var/openldap-data sudo chmod 700 /usr/local/var/openldap-data # succeeds: using the install-provided- slapd.ldif (see below) sudo /usr/local/sbin/slapadd -n 0 -F /usr/local/etc/openldap/slapd.d -l /usr/local/etc/openldap/slapd.ldif # succeeds: sudo /usr/local/libexec/slapd -F /usr/local/etc/openldap/slapd.d # succeeds: sudo /usr/local/bin/ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts # NOTE not sudo, per the quickstart guide, FAILS with "ldap_bind: Invalid credentials (49)" /usr/local/bin/ldapadd -x -D "cn=Manager,dc=example,dc=com" -w secret -f /usr/local/etc/openldap/example.ldif Example.ldif per the quickstart guide: --------------------- dn: dc=my-example,dc=com objectclass: dcObject objectclass: organization o: Example Company dc: example dn: cn=Manager,dc=example,dc=com objectclass: organizationalRole cn: Manager slapd.ldif per the install --------------------- # # See slapd-config(5) for details on configuration options. # This file should NOT be world readable. # dn: cn=config objectClass: olcGlobal cn: config # # # Define global ACLs to disable default read access. # olcArgsFile: /usr/local/var/run/slapd.args olcPidFile: /usr/local/var/run/slapd.pid # # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #olcReferral: ldap://root.openldap.org # # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 64-bit encryption for simple bind #olcSecurity: ssf=1 update_ssf=112 simple_bind=64 # # Load dynamic backend modules: # #dn: cn=module,cn=config #objectClass: olcModuleList #cn: module #olcModulepath: /usr/local/libexec/openldap #olcModuleload: back_mdb.la #olcModuleload: back_ldap.la #olcModuleload: back_passwd.la #olcModuleload: back_shell.la dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///usr/local/etc/openldap/schema/core.ldif # Frontend settings # dn: olcDatabase=frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: frontend # # Sample global access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # #olcAccess: to dn.base="" by * read #olcAccess: to dn.base="cn=Subschema" by * read #olcAccess: to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! # ####################################################################### # LMDB database definitions ####################################################################### # dn: olcDatabase=mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcDbMaxSize: 1073741824 olcSuffix: dc=my-domain,dc=com olcRootDN: cn=Manager,dc=my-domain,dc=com # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd-config(5) for details. # Use of strong authentication encouraged. olcRootPW: secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. olcDbDirectory: /usr/local/var/openldap-data # Indices to maintain olcDbIndex: objectClass eq

2 9

birthday and maiden name are not in the standard schema
by SHarbich＠t-online.de 20 Dec '19

20 Dec '19

Hi, i need support if I want to add two attributes to my LDAP schema. Are there any ldif files? About Help I would be happy.

3 3

add new scheme to existing ldap
by SHarbich＠t-online.de 20 Dec '19

20 Dec '19

Hello, when I try to add a new scheme in the existing LDAP like this. I get the following error message: "root@dsme01:~# slapadd -v -l /tmp/ldapconvert/evolutionperson.ldif slapadd: line 1: database #1 (dc=example,dc=com) not configured to hold "cn=evolutionperson,cn=schema,cn=config"; did you mean to use database #0 (cn=config)? _#################### 100.00% eta none elapsed none fast!" Before, I created the evolutionperson.schema including all schemas as follows: "slapcat -f /tmp/ldapconvert/ldap.conf -F /tmp/ldapconvert -n0 -s "cn={19}evolutionperson,cn=schema,cn=config" > /tmp/ldapconvert/evolutionperson.ldif" The created file was adapted accordingly and only tried to add it as described above. Do I have to delete the entire LDAP database and recreate it and then reload the user-specific part? I would appreciate your support. Greetings from Stefan Harbich

2 1

Re: back-meta with overlapping DN spaces; bind operation does not find applicable target [Active Directory merge]
by Heiko Wundram 17 Dec '19

17 Dec '19

Hello list, sorry for top-posting: Outlook is a pain. Anyway, more to the point: I've experimented at bit more with this, and it seems that mode=legacy for the backend at least does/tries the search operation on the respective meta backends for finding the concrete backend that allows identity assertion of the incoming user (with properly rewritten DN), but does not authenticate that connection, i.e. tries to anonymously search on the backends to find the user object. I've not found a combination of parameters to authenticate the connection for search in meta_search_dobind_init, but from what I can tell from the source, the connection used for the initial bind should actually be authenticated with the idassert binddn and credentials (for bindmethod=simple without proxyAuthz). Apparently, it isn't. (again, the source isn't the clearest, and as there's no debugging information output by the actual functions called by meta_search_dobind_init, it's rather hard to check the actual control flow for me). I'm very hesitant to open the backends (which are active directory servers) up for anonymous accesses, which means that I'm still trying to get this to work (have two different active directory backends with different layouts unified under a single read-only proxy which allows authentication in both directories and delivers results from both). If there's anybody who has this operating successfully, I'd very much love a heads up to any configuration errors and/or problems in understanding I have to fix this. Have a pleasant day! --- Heiko. Von: openldap-technical <openldap-technical-bounces(a)openldap.org> Im Auftrag von Heiko Wundram Gesendet: Donnerstag, 12. Dezember 2019 17:58 An: openldap-technical(a)openldap.org Betreff: back-meta with overlapping DN spaces; bind operation does not find applicable target Hello list, I'm trying to get back-meta running with two backends who have distinct namespaces, but should be exposed in an overlapping DN space, and while search operations and result transformations work fine, I'm having trouble getting the bind operation to try both directories for the login (after bindDN rewrite rules have been applied). It seems that meta_search_dobind_init does not accept the DN as a candidate, unless the match is unique (either through the global URI namespace definition, or through subtree-exclude rules). Both configurations have an idassert-bind set up with mode none, and also use the pseudo-root to bind when resolving. The configuration is as follows: # Database binding to active directories # -------------------------------------- database meta suffix "<basesuffix>" protocol-version 3 norefs yes lastmod off rebind-as-user yes readonly yes # Primary database in old LDAP structure # -------------------------------------- uri "ldap://dc01/<basesuffix>" chase-referrals no default-target idassert-bind bindmethod=simple binddn="<binddn1>" credentials="<bindpw1>" mode=none subtree-exclude dn.subtree:"ou=subsubou,ou=subou,<basesuffix>" # Secondary database in new LDAP structure # ---------------------------------------- uri "ldap://dc02/ou=subou,<basesuffix>" chase-referrals no idassert-bind bindmethod=simple binddn="<binddn2>" credentials="<bindpw2>" mode=none When binding as a user under <basesuffix> and not under ou=subou, this works fine and selects the first target to authenticate the user data. When binding as a user under ou=subsubou,ou=subou, this also works fine, and selects the second target to authenticate the user; both apply the corresponding baseDN transformations that are set up for the corresponding target. The problem starts when binding as user under ou=subou: 5df270ec conn=1000 op=0 meta_back_getconn: candidates=2 conn=ANON-TLS inserted 5df270ec conn=1000 op=0 >>> meta_back_search_start[0] 5df270ec conn=1000 op=0 >>> meta_search_dobind_init[0] 5df270ec conn=1000 op=0 <<< meta_search_dobind_init[0]=0 5df270ec conn=1000 op=0 <<< meta_back_search_start[0]=0 5df270ec conn=1000 op=0 >>> meta_back_search_start[1] 5df270ec conn=1000 op=0 >>> meta_search_dobind_init[1] 5df270ec conn=1000 op=0 <<< meta_search_dobind_init[1]=0 5df270ec conn=1000 op=0 <<< meta_back_search_start[1]=0 5df270ec conn=1000 op=0 meta_back_search: ncandidates=0 cnd="**" 5df270ec conn=1000 op=0 meta_back_search: base="cn=someuser,ou=subou,<basesuffix>" scope=0: no candidate could be selected I've tried to follow meta_search_dobind_init as to which part of the code causes the candidate to be rejected, but I've not found any specific part which would cause this/make clear why both candidates aren't applicable. Setting acl-authcDN and acl-passwd for the target also shows the same behaviour. Is this a known restriction for back-meta, or am I missing some configuration? Thank you for any hints! --- Heiko.

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