openldap-technical December 2019

openldap-technical@openldap.org

18 participants
22 discussions

Problem with "force user to password reset at first login
by Rajagopal Rc 30 Oct '23

30 Oct '23

Hi, I am trying to force users to change their password at first login or after password reset by administrator. Tried following: 1)Password policy 'pwdMustChange TRUE' doesn't seems to be working as non of the users get prompt to change their password at first login. 2) used the 'pwdReset TRUE' attribute in users attributes, and it won't prompt to change the password and didn't allow to login i observe below messages in log "slapd[12684]: connection restricted to password changing only slapd[12684]: send_ldap_result: err=50 matched="" text="Operations are restricted to bind/unbind/abandon/StartTLS/modify password" slapd[12684]: conn=1053 op=1 SEARCH RESULT tag=101 err=50 nentries=0 text=Operations are restricted to bind/unbind/abandon/StartTLS/modify password" Please help me configure the option to force all users to change their password at first login or after pwd reset by administrator. Thanks & Regards Raj Tata Consultancy Services Mailto: rajagopal.rc(a)tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you

5 9

Q: UNKNOWN attributeDescription "AUDITCONTEXT" inserted.
by Ulrich Windl 22 Jul '20

22 Jul '20

Hi! After systemd tearing down one of our LDAP servers I noticed the following message when the server was restarted: slapd[10525]: UNKNOWN attributeDescription "AUDITCONTEXT" inserted. The next line logged was: slapd[10525]: olcServerID: value #1: SID=0x002 (listener=ldap://...:389) (the server is that of SLES12 SP4, 2.4.41 from opensuse-buildservice) The server is one of three MM servers that all have the same configuration and the same version. The schema knows in olcAttributeTypes (olcSchemaConfig): ( 1.3.6.1.4.1.4203.666.11.5.1.30 NAME 'auditContext' DESC 'DN of auditContainer' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) What I'l like to know: Is there any thing I could fix in the configuration to make the message go away, or is it some software issue in slapd? Regards, Ulrich

4 10

Question about OpenLDAP and rwm overlay
by Vandenburgh, Steve Y 17 Jan '20

17 Jan '20

I'm attempting to use OpenLDAP as a proxy to an Active Directory domain. Using the ldap backend, I'm able to configure the proxy and that configuration seems to be working well. But account entries are frequently moved from ou to ou in a domain and Microsoft permits the bind DN to be a userPrincipalName attribute value of the entry instead of the full DN of the account; this features avoids having to make many bind DN application configuration changes. With just the ldap backend configured, OpenLDAP rejects the userPrincipalName (UPN) bind DN as an invalid DN. To work around this error, I was trying to see if I could use the rwm overlay to detect the UPN and convert to the actual domain entry DN using an attribute map. If I use the form mail=UPN the map works as expected; however, if I only provide the UPN as the bind DN, OpenLDAP still rejects it as an invalid DN. I suspect that the rwm overlay manipulations to not take effect until after the bind DN syntax is checked. I wanted to confirm my suspicion and see if any one else has been able to get a UPN-based bind to work through OpenLDAP. For reference my slapd.conf configuration is below: ### Schema includes ########################################################### include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema ## Module paths ############################################################## modulepath /usr/lib64/openldap/ moduleload rwm # Main settings ############################################################### loglevel 8 sizelimit unlimited idletimeout 600 writetimeout 30 allow bind_v2 pidfile /var/openldap/mycompany/var/slapd.pid argsfile /var/openldap/mycompany/var/slapd.args logfile /var/openldap/mycompany/logs/access TLSCertificateFile /var/openldap/mycompany/certs/Server.pem TLSCertificateKeyFile /var/openldap/mycompany/certs/Server.key TLSCACertificateFile /var/openldap/mycompany/certs/ServerCA.pem ### Rewrite rules ############################################################# # Bind with UPN instead of full DN: we first need # an ldap map that turns attributes into a DN (the # argument used when invoking the map is appended to # the URI and acts as the filter portion) overlay rwm rwm-suffixMassage "" "dc=mycompany,dc=com" rwm-rewriteMap ldap attr2dn "ldaps://mycompany.com/ou=Domain%20Users,dc=mycompany,dc=com?dn?sub" bindwhen=now version=3 binddn="CN=mybindacct,ou=Domain Users,DC=mycompany,DC=com" credentials=****** # Then we need to detect UPN DN # note that the rule in case of match stops rewriting # In case we are mapping virtual # to real naming contexts, we also need to rewrite # regular DNs, because the definition of a bindDN # rewrite context overrides the default definition. rwm-rewriteContext bindDN rwm-rewriteRule "^[^=,]+(a)mycompany.com$" "mail=$0" ":" rwm-rewriteRule "^mail=[^,]+(a)mycompany.com$" "${attr2dn($0)}" ":@" ### Database definition (Proxy to AD) ######################################### database ldap readonly yes protocol-version 3 rebind-as-user uri "ldaps://mycompany.com" suffix "dc=mycompany,dc=com" Thanks, Steve Vandenburgh This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.

6 9

RE: ldapsearch utility
by Peter Sui 06 Jan '20

06 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

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 19 Dec '19

19 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

LMDB encryption support?
by Jens Alfke 13 Dec '19

13 Dec '19

I'm evaluating LMDB, and one feature we consider important is file-level encryption. The memory-mapped, zero-copy nature of LMDB would seem to be incompatible with encryption, but there is a tantalizing post from Howard Chu two years ago: > • To: "OpenLDAP-devel(a)openldap.org" <OpenLDAP-devel(a)openldap.org> > • Subject: LMDB encryption support > • From: Howard Chu <hyc(a)symas.com> > • Date: Thu, 10 Aug 2017 16:55:57 +0100 > > I've recently added support for page-level encryption to LMDB 1.x using user-supplied callbacks: ( https://www.openldap.org/lists/openldap-devel/201708/msg00002.html <https://www.openldap.org/lists/openldap-devel/201708/msg00002.html> ) However, the API shown in the email is not present in mainline LMDB (0.9.24), nor can I find it in a branch in the Git repository. Was this an abandoned experiment? Or is it only available with a commercial license (as is SQLite's encryption extension?) (Whether or not this feature still exists, I'm curious about how it was implemented. It seems like it would either require some kind of kernel-level support for hooking into the VM pager to rewrite pages after they're faulted in, or else not using memory-mapping at all and going with a page-cache a la SQLite.) Thanks, —Jens

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical December 2019