openldap-technical

openldap-technical@openldap.org

9897 discussions

new attribute
by Alexander Schwarz 16 Mar '18

16 Mar '18

Hello, I tried to create a new objectclass and a new attribute to develop scripts to use against an ActiveDirectory. objectlass=user attribute=sAMAccountName I have a new test.schema: attributetype ( 1.2.840.113556.1.4.221 NAME 'sAMAccountName' EQUALITY caseIgnoreMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE ) objectclass ( 1.2.840.113556.1.5.9 NAME 'user' DESC 'a user' SUP inetOrgPerson STRUCTURAL MUST ( cn ) MAY ( sAMAccountName ) ) This is included in slapd.conf: include ./schema/core.schema include ./schema/cosine.schema include ./schema/nis.schema include ./schema/inetorgperson.schema include ./schema/openldap.schema include ./schema/pmi.schema include ./schema/ppolicy.schema include ./schema/dyngroup.schema include ./schema/test.schema I tried to modify a dummy user after restart ldap. modify.ldif: dn: cn=test test,ou=Benutzer,ou=Netzwerk,dc=network,dc=de changetype: modify add: sAMAccountName sAMAccountName: test I used the ldapmodify tool: ldapmodify -a -x -D "cn=admin,dc=network,dc=de" -w passwd -H ldap:// -f d:\modify.ldif Eintrag cn=test test,ou=Benutzer,ou=Netzwerk,dc=network,dc=de wird geändert ldap_modify: Objektklassenverletzung ldap_modify: Zusätzliche Info: attribute 'sAMAccountName' not allowed Can someone explain to me where is the mistake? Regards, Alex

3 2

cannot fetch base DNS from replica
by Eugene M. Zheganin 08 Mar '18

08 Mar '18

Hi, previously I succeeded several times on setting up the replication, but this time I'm stuck. The only difference is that now the database is in mdb (since bdb is obsoleted). ldapsearch is able to fetch all the entries from both hosts (I've tried the replication with mirrormode and without it - same result), the numResponses: 189 is both times, but on "replica" (doesn't matter whether the mirrormode is on or off) the Apache Directory Studio is not able to browse the tree, because it says "cannot fetch Base DNs" (so it is only showing the Roor DSE), thus I'm sure there's something wrong. here are my configs (I've skipped the accesslog and ppolicy overlays since their configuration seems not to be the problem): Host A ==== serverID 1 database mdb suffix "dc=playkey,dc=net" rootdn "cn=webmaster,dc=playkey,dc=net" rootpw {SSHA}XXXXXXXXXXXXXXXXXXXXXXXX directory /var/db/openldap-data overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncrepl rid=001 provider=ldap://foobar1:389 type=refreshAndPersist interval=00:00:10:00 retry="60 10 300 +" filter="(objectClass=*)" searchbase="dc=playkey,dc=net" attrs="*,+" schemachecking=off bindmethod=simple binddn="uid=proxyagent,ou=accounts,ou=enaza,dc=playkey,dc=net" credentials=ghjcnbvtyzvjzk.,jdm mirrormode on Host B ==== serverID 2 database mdb suffix "dc=playkey,dc=net" rootdn "cn=webmaster,dc=playkey,dc=net" rootpw {SSHA}XXXXXXXXXXXXXXXXXXXXXXXXXX directory /var/db/openldap-data overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncrepl rid=001 provider=ldap://foobar2:389 type=refreshAndPersist interval=00:00:10:00 retry="60 10 300 +" filter="(objectClass=*)" searchbase="dc=playkey,dc=net" attrs="*,+" schemachecking=off bindmethod=simple binddn="uid=proxyagent,ou=accounts,ou=enaza,dc=playkey,dc=net" credentials=ghjcnbvtyzvjzk.,jdm mirrormode on So, how do I investigate what's wrong with base DNs on teh host B ? Thanks. Eugene.

2 1

dynamic config replication
by Gerard Ranke 07 Mar '18

07 Mar '18

Hello list, Openldap 2.4.45 here, on 1 producer and 4 consumers. ( I'll attach relevant parts of the configuration at the end of this message. ) Following the scripts from test059, I configured the producer to serve up a cn=config backend for the consumers. This seems to work nicely at first: When you start a consumer from a minimal config, it loads the producers schemafiles and the cn=config, and replication of the main database is fine. Also, when fi. changing the loglevel on the producers cn=config,cn=slave, the consumers pick up this change in their cn=config. However, when I modify an olcAccess line on the producers cn=config,cn=slave database, I get these errors on the consumer: slapd[26324]: syncrepl_message_to_entry: rid=002 DN: olcDatabase={1}mdb,cn=config,cn=slave, UUID: 7cff5ef6-90b1-1037-9d95-6dfd3149c2dc slapd[26324]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) slapd[26324]: syncrepl_entry: rid=002 inserted UUID 7cff5ef6-90b1-1037-9d95-6dfd3149c2dc slapd[26324]: syncrepl_entry: rid=002 be_search (0) slapd[26324]: syncrepl_entry: rid=002 olcDatabase={1}mdb,cn=config slapd[26324]: null_callback : error code 0x43 slapd[26324]: syncrepl_entry: rid=002 be_modify olcDatabase={1}mdb,cn=config (67) slapd[26324]: syncrepl_entry: rid=002 be_modify failed (67) slapd[26324]: do_syncrepl: rid=002 rc 67 retrying >From the error code ox43, it seems that the replication is somehow trying to change the rdn, olcDatabase{1}mdb, on the consumer, which makes no sense to me. >From the producer, cn=config,cn=slave: ( This is identical to the consumer's cn=config ) dn: cn=config,cn=slave objectClass: olcGlobal objectClass: olcConfig objectClass: top cn: slaveconfig cn: config olcArgsFile: /var/run/slapd/slapd.args olcAttributeOptions: lang- olcAuthzPolicy: none olcConcurrency: 0 olcConfigDir: slapd.d/ olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 0 olcIndexIntLen: 4 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcLocalSSF: 71 olcLogFile: none olcLogLevel: none olcPidFile: /var/run/slapd/slapd.pid olcReadOnly: FALSE olcSaslSecProps: noplain,noanonymous olcSizeLimit: 20000 olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 16 olcTLSCACertificatePath: /etc/ssl/certs olcTLSCertificateFile: /etc/ssl/certs/hkuwildcardcacert.cert olcTLSCertificateKeyFile: /etc/ssl/private/hkuwildcardcacert.key olcTLSCRLCheck: none olcTLSVerifyClient: never olcToolThreads: 2 I'll leave the rest PM, except for: dn: olcDatabase={0}config,cn=config,cn=slave objectClass: olcDatabaseConfig objectClass: olcConfig objectClass: top olcDatabase: {0}config olcRootDN: cn=root,cn=config olcRootPW: xxxxxxxxxxxxxx olcSyncrepl: {0}rid=002 provider=ldap://xxx.xx.xx bindmethod=simple binddn="cn=config,cn=slave" credentials="xxxx" tls_cert="/etc/ssl/certs/xxx.cert" tls_key="/etc/ssl/private/xxx.key" tls_cacertdir="/etc/ssl/certs" tls_reqcert=demand tls_crlcheck=none searchbase="cn=config,cn=slave" schemachecking=off type=refreshAndPersist retry="5 5 10 +" suffixmassage="cn=config" olcSyncUseSubentry: FALSE This is identical to the consumers olcDatabase={0}config,cn=config entry. Hopefully somebody can point me in the right direction! Many thanks in advance, gerard

3 4

RE24 testing call (2.4.46) LMDB RE0.9 testing call (0.9.22)
by Quanah Gibson-Mount 28 Feb '18

28 Feb '18

This is expected to be the final testing call for 2.4.45, with an anticipated release, depending on feedback, during the week of 2018/03/12. For this release the primary focus was addressing replication issues found in OpenLDAP, affecting both syncrepl and delta-syncrepl, whether as provider/consumer or MMR-based configurations. Generally, get the code for RE24: <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…> Configure & build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its run through the regression suite. Thanks! OpenLDAP 2.4.46 Engineering Fixed libldap connection delete callbacks when TLS fails to start (ITS#8717) Fixed libldap to not reuse tls_session if TLS hostname check fails (ITS#7373) Fixed libldap cross-compiling with OpenSSL 1.1 (ITS#8687) Fixed libldap OpenSSL 1.1.1 compatibility with BIO_method (ITS#8791) Fixed libldap MozNSS CA certificate hash matching (ITS#7374) Fixed libldap MozNSS with PEM certs when also using an NSS cert db (ITS#7389) Fixed libldap MozNSS initialization (ITS#8484) Fixed libldap GnuTLS with GNUTLS_E_AGAIN (ITS#8650) Fixed libldap memory leak with cancel operations (ITS#8782) Fixed slapd Eventlog registry key creation on 64-bit Windows (ITS#8705) Fixed slapd to maintain SSF across SASL binds (ITS#8796) Fixed slapd syncrepl deadlock when updating cookie (ITS#8752) Fixed slapd syncrepl callback to always be last in the stack (ITS#8752) Fixed slapd telephoneNumberNormalize when the value is spaces and hyphens (ITS#8778) Fixed slapd CSN queue processing (ITS#8801) Fixed slapd-ldap TLS connection timeout with high latency connections (ITS#8720) Fixed slapd-ldap to ignore unknown schema when omit-unknown-schema is set (ITS#7520) Fixed slapd-mdb with an optimization for long lived read transactions (ITS#8226) Fixed slapd-meta assert when olcDbRewrite is modified (ITS#8404) Fixed slapd-sock with LDAP_MOD_INCREMENT operations (ITS#8692) Fixed slapo-accesslog cleanup to only occur on failed operations (ITS#8752) Fixed slapo-dds entryTTL to actually decrease as per RFC 2589 (ITS#7100) Fixed slapo-syncprov memory leak with delete operations (ITS#8690) Fixed slapo-syncprov to not clear pending operation when checkpointing (ITS#8444) Fixed slapo-syncprov to correctly record contextCSN values in the accesslog (ITS#8100) Fixed slapo-syncprov not to log checkpoints to accesslog db (ITS#8607) Fixed slapo-syncprov to process changes from this SID on REFRESH (ITS#8800) Fixed slapo-syncprov session log parsing to not block other operations (ITS#8486) Build Environment Fixed Windows build with newer MINGW version (ITS#8697) Fixed compiler warnings and removed unused variables (ITS#8578) Contrib Fixed ldapc++ Control structure (ITS#8583) Documentation Delete stub manpage for back-ldbm (ITS#8713) Fixed ldap_bind(3) to mention the LDAP_SASL_SIMPLE mechanism (ITS#8121) Fixed slapd-config(5) typo for olcTLSCipherSuite (ITS#8715) Fixed slapo-syncprov(5) indexing requirements (ITS#5048) LMDB 0.9.22 Engineering Fix regression with new db from 0.9.19 (ITS#8760) Fix liblmdb to build on Solaris (ITS#8612) Fix delete behavior with DUPSORT DB (ITS#8622) Fix mdb_cursor_get/mdb_cursor_del behavior (ITS#8722) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

LMDB: EIO/MDB_INVALID and use of pwrite/pread
by opensource＠gmx-topmail.de 28 Feb '18

28 Feb '18

1 0

Acl on a replicated tree: unable to bind as user
by Giuseppe Civitella 27 Feb '18

27 Feb '18

Hi all, I've got a master / slave replica setup. I did use this tutorial to set up the replica: https://wiki.debian.org/LDAP/OpenLDAPSetup My ldap tree is something like: Root -> o=(first level local branch), o=(first level replicated branch). The local branch is just a cut and paste of the replicated branch. On the slave server I can use the replicated branch to authenticate against a Radius server. On the master server I realized I cannot let web users authenticate against the replicated branch. If I try to bind as a user from the replicated branch, on both the master and the slave, I get: ldapwhoami -H ldap://localhost -D "uid=gcivitella,ou=users,o=isiline,dc=who,dc=is" -W Enter LDAP Password: ldap_bind: Invalid credentials (49) On the master, on the local branch, I get: ldapwhoami -H ldap://localhost -D "cn=gcivitella,ou=users,o=area51,dc=who,dc=is" -W Enter LDAP Password: dn:cn=gcivitella,ou=users,o=area51,dc=who,dc=is I did try to configure the acl on the server to disallow anonymous bind. And, once found this problem, I did try to create a bind user (uid=read_only) able to read the replicated branch, userPassword attrs included. Unfortunately this did not solve the problem. My acl on the master are: dn: olcDatabase={1}mdb objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=who,dc=is olcAccess: {0}to dn.subtree="o=isiline,dc=who,dc=is" by dn="uid=read_only,ou =binds,dc=who,dc=is" read olcAccess: {1}to dn.subtree="o=isiline,dc=who,dc=is" by dn="uid=isi_replica, ou=binds,dc=who,dc=is" read olcAccess: {2}to attrs=userPassword by self write by anonymous auth by * non e olcAccess: {3}to attrs=shadowLastChange by self write by * read olcAccess: {4}to * by users read I'm quite new to this kind of setup, is this something to be expected? Is there a way to bind directly on the replicated branch? Regards, Giuseppe

2 1

LMDB: Delete data after MDB_MAP_FULL
by opensource＠gmx-topmail.de 26 Feb '18

26 Feb '18

2 1

Re: Syncrepl and multipe values
by Quanah Gibson-Mount 24 Feb '18

24 Feb '18

--On Friday, January 06, 2017 6:50 PM +0000 Matheus Eduardo Bonifacio Morais <matheus_morais(a)sicredi.com.br> wrote: > > > > Issue 8559 opened. > > > > I'm trying to work on a patch but I'm not sure if the best solution is to > fix accesslog to avoid duplicated values or if the sample LDIF (in its > description) should result in a constraint violation. What do you think? The accesslog should never write an operation that can't be replicated. If the MOD is a valid LDAP operation (which I think it is), then it should be accepted at the frontend. The issue may be more in delta-syncrepl's handling of the write op than anything else. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 3

consumer abort with chain overlay
by Michael Wandel 24 Feb '18

24 Feb '18

hallo , i'm not sure if I it is a configuration failure or a openldap error. I have tested this with centos 7 , original RPM, SLES12SP3 and the ltb-project binäries. Every enviroment failed. this is a setup consumer / provider with chain overlay and proxyauth. a minimized slapd.conf global section ... authz-policy to overlay chain chain-uri "ldap://ldap1.example.test" chain-rebind-as-user FALSE chain-idassert-bind bindmethod="simple" binddn="cn=chainadmin,dc=example,dc=test" credentials="secret" mode=legacy flags=override chain-return-error TRUE ... the java code snipplet which makes a connection and then switch the proxyauth and make a password change. --- try { LDAPConnection connection = openLDAPConnection(); BindRequest bindRequest = new SimpleBindRequest(modDN, oldPwd, new DraftBeheraLDAPPasswordPolicy10RequestControl()); BindResult bindResult = connection.bind(bindRequest); DraftBeheraLDAPPasswordPolicy10ResponseControl pwpResponse = DraftBeheraLDAPPasswordPolicy10ResponseControl.get(bindResult); DraftBeheraLDAPPasswordPolicy10WarningType warningType = pwpResponse.getWarningType(); System.out.println("Bind Result " + bindResult.toString()); System.out.println("PwdResponse " + pwpResponse.toString()); connection.close(); connection = openLDAPConnection(); Control[] controls = { new ProxiedAuthorizationV2RequestControl("dn:" + modDN) }; PasswordModifyExtendedRequest passwordModifyRequest = new PasswordModifyExtendedRequest(modDN, oldPwd, newPwd, controls); PasswordModifyExtendedResult passwordModifyResult = (PasswordModifyExtendedResult) connection .processExtendedOperation(passwordModifyRequest); System.out.println("passwordModifyResult " + passwordModifyResult.toString()); connection.close(); connection = openLDAPConnection(); bindRequest = new SimpleBindRequest(modDN, newPwd, new DraftBeheraLDAPPasswordPolicy10RequestControl()); bindResult = connection.bind(bindRequest); pwpResponse = DraftBeheraLDAPPasswordPolicy10ResponseControl.get(bindResult); warningType = pwpResponse.getWarningType(); System.out.println("Bind Result " + bindResult.toString()); System.out.println("PwdResponse " + pwpResponse.toString()); } the gdb output of the crash is here: 5a8c6d3d conn=1001 op=1 RESULT oid= err=123 text=not authorized to assume identity *** Error in `/usr/local/openldap/libexec/slapd': munmap_chunk(): invalid pointer: 0x00007f2b14100986 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x7ada4)[0x7f2d8a9d7da4] /usr/local/openldap/libexec/slapd(ldap_back_controls_free+0xc1)[0x5181a1] /usr/local/openldap/libexec/slapd[0x522ba8] /usr/local/openldap/libexec/slapd[0x51a959] /usr/local/openldap/libexec/slapd[0x51c193] /usr/local/openldap/libexec/slapd[0x4a5118] /usr/local/openldap/libexec/slapd[0x44f286] /usr/local/openldap/libexec/slapd[0x44f787] /usr/local/openldap/libexec/slapd(slap_send_ldap_extended+0xc0)[0x450880] /usr/local/openldap/libexec/slapd(fe_extended+0xba)[0x46f26a] /usr/local/openldap/libexec/slapd(overlay_op_walk+0x92)[0x4a5c42] /usr/local/openldap/libexec/slapd[0x4a5d7e] /usr/local/openldap/libexec/slapd(do_extended+0x24e)[0x46efbe] /usr/local/openldap/libexec/slapd[0x4407ee] /usr/local/openldap/libexec/slapd[0x440aca] /usr/local/openldap/libexec/slapd[0x590769] /lib64/libpthread.so.0(+0x7dc5)[0x7f2d8be00dc5] /lib64/libc.so.6(clone+0x6d)[0x7f2d8aa5473d] ======= Memory map: ======== 00400000-00683000 r-xp 00000000 fd:00 68054818 /usr/local/openldap/libexec/slapd 00882000-00883000 r--p 00282000 fd:00 68054818 /usr/local/openldap/libexec/slapd 00883000-00893000 rw-p 00283000 fd:00 68054818 /usr/local/openldap/libexec/slapd 00893000-00939000 rw-p 00000000 00:00 0 022d2000-02768000 rw-p 00000000 00:00 0 [heap] 7f2b14000000-7f2b1411f000 rw-p 00000000 00:00 0 7f2b1411f000-7f2b18000000 ---p 00000000 00:00 0 7f2b1afff000-7f2b1c000000 rw-p 00000000 00:00 0 7f2b1c000000-7f2b1c021000 rw-p 00000000 00:00 0 7f2b1c021000-7f2b20000000 ---p 00000000 00:00 0 7f2b20000000-7f2b20117000 rw-p 00000000 00:00 0 7f2b20117000-7f2b24000000 ---p 00000000 00:00 0 7f2b24000000-7f2b24021000 rw-p 00000000 00:00 0 I'm not sure if it is a known bug or misconfiguration. If someone wants the java testprogram i'll can send it per pm or give a download link. best regards Michael -- Michael Wandel Braakstraße 43 33647 Bielefeld

2 1

contextCSN not found on consumer!
by Sam Culley 24 Feb '18

24 Feb '18

I have recently set up a provider/consumer using OpenLDAP 2.4.40, everything appears to be working. Changes made on the provider are replicated to the consumer but when querying the contextCSN I am only able to retrieve results for the provider. [root@prod-mail-ldap-master ~]# ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base -b dc=domain,dc=cp, contextCSN dn: dc=domain,dc=com contextCSN: 20180222075803.816626Z#000000#000#000000 [root@prod-mail-ldap-slave-1 ~]# ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base -b dc=domain,dc=cp, contextCSN dn: dc=domain,dc=com As you can see from the command outputs above when running the same commands on both provider/consumer only the provider returns the contextCSN. Why is this happening, what do I need to do to retrieve the contextCSN from the consumer? Regards, Sam

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical