Q: UNKNOWN attributeDescription "AUDITCONTEXT" inserted.
by Ulrich Windl
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
2 years, 8 months
Question about OpenLDAP and rwm overlay
by Vandenburgh, Steve Y
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.
3 years, 2 months
RE: ldapsearch utility
by Peter Sui
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
3 years, 2 months
ldapwhoami translate sasl-name to dn
by Stefan Kania
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
3 years, 2 months
ldap_bind: Invalid credentials at LDAPADD step in the QuickStart Guide
by Dunne, Kenneth
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
3 years, 2 months
add new scheme to existing ldap
by SHarbich＠t-online.de
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
3 years, 3 months
Re: back-meta with overlapping DN spaces; bind operation does not find applicable target [Active Directory merge]
by Heiko Wundram
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.
3 years, 3 months
LMDB encryption support?
by Jens Alfke
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
3 years, 3 months
Postgres and Attributes
by Mark Murawski
Hi!
Attachments:
www.kobaz.net/misc/slapd.zip
www.kobaz.net/misc/ldap.sql
www.kobaz.net/misc/attributes.png
Disclaimer: Let me first start out saying that this isn't my first run
around the block. I understand that this is experimental and I accept
the risks and issues that might come with back-sql.
I started with the backend examples located in:
servers/slapd/back-sql/rdbms_depend/pgsql
... and then started adding support for things like organizationUnit
that are not included in the test db
Attached is my ldap postgres database.
Attached is my ldap /etc/ldap/slapd
I'm aware that passwords/etc are in there, but it's not a big deal. It's
just testing stuff on an internal system.
The issue I'm having:
- Attributes are not coming back when requesting ldap information or
doing ldap search (Screenshot)
Also noted is that the sample inetOrgPerson entries do not show any
attributes like surname, despite them being stored in the postgres
database in what looks like the correct format (exactly the same as the
test db import)
-- The organizationUnit has been added like this:
1-users-ou.ldif
-----
dn: ou=users,dc=directory, dc=pbx, dc=local
ou: users
description: holds users of the directory
objectClass: organizationalUnit
-----
ldapadd -x -D "cn=admin,dc=directory, dc=pbx, dc=local" -w 'asdf' -v -f
1-users-ou.ldif
Despite having specified 'description', this has not been added to the
database as shown in the export. The organizational_unit table looks
like this:
id | ou | description
----+----+-------------
1 | |
Looking at the postgres query logs, slapd has made no attempt whatsoever
to set the description field, despite this field being mapped in the
attributes as shown in the export. Also here for quick reference:
Table: ldap_attr_mappings
-[ RECORD 16 ]+
id | 20
oc_map_id | 5
name | description
sel_expr | organizational_unit.description
sel_expr_u |
from_tbls | organizational_unit
join_where |
add_proc | UPDATE organizational_unit SET description=? WHERE id=?
delete_proc | SELECT 1 FROM organizational_unit WHERE ou = ? AND ID=?
param_order | 3
expect_return | 0
Can someone shed some light on what's wrong here?
3 years, 3 months
