openldap-technical

openldap-technical@openldap.org

18 participants
9897 discussions

Re: Extensible filters and ordering searches: filtering shadowExpire by range?
by Côme Chilliet 19 Jun '19

19 Jun '19

Le mardi 18 juin 2019, 12:36:56 CEST Quanah Gibson-Mount a écrit : > > So, there is no way to filter on shadowExpire values which are less than > > today's timestamp? > > shadowExpire is defined as an integer type, not as a timestamp, so no. > > > It sounds crazy that such basic needs are not covered by LDAP protocol, > > have I missed something? > > It's not clear to me what this has to do with the LDAP protocol. The > definition of the "expire" field from /etc/shadow is: > > Expire : days since Jan 1, 1970 that account is disabled i.e. an absolute > date specifying when the login may no longer be used. > > So it's an integer (just as the RFC defines it). I would imagine you could > write something that converts a current timestamp into the number of days, > etc, and then perform a search. Yeah this is what I was calling timestamp sorry, getting the integer for today is easy, but it seems there is no way for writing a search filter with greater-than or lesser-than for this attribute. It has to do with the LDAP protocol that LDAP lets schema define attributes in ways that forbid substring and range filters. We should be able to use extensible filters for these, and specify which ordering or substring rule we want to see used. And if attributes using integer syntax were to default to integerOrdering when not specified, that would seem more sane. Côme

2 1

Extensible filters and substring searches
by Côme Chilliet 18 Jun '19

18 Jun '19

Hello, I’m trying to understand if it is possible or not to do a substring search on an attribute which does not specify a substring matching rule. I was expecting to be able to use an extensible filter and specify the sub matching rule to use, but it does not seem to work ldapsearch says "ldap_search_ext: Bad search filter (-7)" as soon as the filter contains an asterisk. And indeed reading https://tools.ietf.org/html/rfc4515 it does look like extensible filter does not allow asterisk, but it is surprising to me. Is there really no way to do an extensible search on a substring? I found some examples on the web of such filters, like here: http://www.zytrax.com/books/ldap/apa/search.html They give these examples: > # override SUBSTR match with case sensitive match > sn:caseExactSubstringMatch:=*S* # only finds Smith > # functionally same as above using OID > sn:2.5.13.7:=*S* But these do not work if I try them in ldapsearch I get bad search filter. Côme

3 7

Uniqueness across multiple attributes
by Stefan Schmidt 17 Jun '19

17 Jun '19

Hello, is it possible define a unique constraint across attributes? We have a mail field and a mailAlias field and would like to assure that if a mail address exists either in mail or mailAlias it cannot be added again to either field, meaning mail addresses are unique in the complete tree. We are using OpenLDAP 2.4 and currently we use the following LDIF to load the unique module and assure that the mail attribute is unique: dn: cn=module,cn=config cn: module objectclass: olcModuleList objectclass: top olcmoduleload: unique olcmodulepath: /usr/lib/ldap dn: olcOverlay=unique,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: {0}unique olcUniqueAttribute: mail Which LDIF would I use to assure uniqueness across mail and mailAlias? Cheers, Stefan Schmidt

4 5

Re: No olcBackend module loaded.
by Igor Sousa 13 Jun '19

13 Jun '19

Hi Quanah, Thank you for your answer. My boss has asked me for a tutorial due our new installation that we'll do. Then we'll update our production environment to latest version of distribution and openldap. I've used, in my test, hdb backend because I've used default installation from yum package management. Then I'll change it to mdb in my tutorial and new installation. (I've seen, after you explanation, that OpenLDAP documentation says hdb is deprecated.) About "olcBackend", I've understand, after your explanation, that is normal it there isn't in CentOS. Best regards and thank you so much, -- Igor Sousa

2 2

How to correctly import schemas?
by Jens Bürger 13 Jun '19

13 Jun '19

Dear people of OpenLDAP, I have a Univention Corporate Server (UCS) running at a local site, with a well-populated LDAP. I have a VM on the Internet, providing some web services. I’d like to just clone the LDAP data from the local UCS machine to the VM regularly. While copying the database is a no-brainer (scp & ssh-key), I currently fail at importing the UCS-specific LDAP schemas into the LDAP of the VM. The schema conversion created a {0}core.ldif as starting point. Importing this into openldap failed because I have not the right to modification to core (of course). Any hints? Kind regards, Jens

4 9

authentication failure
by Adam Weremczuk 12 Jun '19

12 Jun '19

Hi all, I'm trying to make pfSense talk to Samba AD LDAP through "bind credentials to resolve distinguished names" option. I have 2 accounts which, as far as I can tell, look identical from AD perspective. One of them successfully connects (Samba logs): [2019/06/12 14:34:41.517364, 3] ../lib/ldb-samba/ldb_wrap.c:325(ldb_wrap_connect) ldb_wrap open of secrets.ldb [2019/06/12 14:34:41.520731, 3] ../source4/auth/ntlm/auth.c:271(auth_check_password_send) auth_check_password_send: Checking password for unmapped user [MATRIX_SCIENCE]\[account1]@[(null)] auth_check_password_send: mapped user is: [MATRIX_SCIENCE]\[account1]@[(null)] [2019/06/12 14:34:41.521510, 4] ../source4/auth/sam.c:183(authsam_account_ok) authsam_account_ok: Checking SMB password for user account1 The other one fails: [2019/06/12 15:09:56.215000, 3] ../lib/ldb-samba/ldb_wrap.c:325(ldb_wrap_connect) ldb_wrap open of secrets.ldb [2019/06/12 15:09:56.217871, 3] ../source4/smbd/service_stream.c:66(stream_terminate_connection) Terminating connection - 'ldapsrv_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED' [2019/06/12 15:09:56.217941, 3] ../source4/smbd/process_single.c:114(single_terminate) single_terminate: reason[ldapsrv_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED] Any idea what the second account is missing? The difference must be restricted to what's replicated between domain controllers as the behavior is identical against the primary and secondary one. Thanks, Adam

1 0

No olcBackend module loaded.
by Igor Sousa 10 Jun '19

10 Jun '19

Hi everyone, I've been creating a tutorial for my company for documented "How to install and configure OpenLDAP" for our needs. Currently, we've had a OpenLDAP server on Debian 8 and OpenLDAP 2.4.40 on the production server. My boss has asked me for a tutorial of OpenLDAP on CentOS7. I've agreed with him (distribution is only a shell to Kernel Linux). Them I've created a tutorial for this request, BUT I've noticed a strange thing before enable memberOf module: my new installations doesn't have any module loaded, including backend module. Then, my questions are: 1 - Is this a normal? 2 - How to enable back_hdb module? OBS1: I've installed from package management YUM: *yum install openldap*. OBS2: Database of new installations is hdb. -- Igor Sousa

2 1

Replication issues with delta-syncrepl, MMR and memberOf overlay on 2.4.47
by Mark Cairney 06 Jun '19

06 Jun '19

Hi, We currently run a multi-master setup where all 4 of our servers replicate from each other via delta-syncrepl but all our writes are directed at a selected "master" server. I've noticed recently that we are suffering sync issues and this coincides with us upgrading from 2.4.46 with a patch for ITS8843 to 2.4.47. On a "consumer" I'm seeing log entries like this: Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: slap_graduate_commit _csn: removing 0xa1da880 20190605063503.192377Z#000000#003#000000 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: syncrepl_message_to_ op: rid=034 be_modify cn=STUUG,ou=affiliations,ou=grouper2,dc=authorise,dc=ed,dc =ac,dc=uk (0) Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: slap_queue_csn: queu eing 0x1e963c40 20190605063503.289350Z#000000#003#000000 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: syncrepl_message_to_ op: rid=035 tid b7ae2700 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: do_syncrep2: rid=034 cookie=rid=034,sid=003,csn=20190605063503.289350Z#000000#003#000000 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: syncrepl_null_callba ck : error code 0x14 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: slap_graduate_commit_csn: removing 0x1e963c40 20190605063503.289350Z#000000#003#000000 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: syncrepl_message_to_op: rid=035 be_modify cn=PRPHDOPMIH3F_3,ou=PRPHDOPMIH3F,ou=pos,ou=grouper2,dc=authorise,dc=ed,dc=ac,dc=uk (20) Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: do_syncrep2: rid=035 delta-sync lost sync on (reqStart=20190605063503.000020Z,cn=accesslog), switching to REFRESH Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: slap_queue_csn: queueing 0x1d0f8100 20190605063503.289350Z#000000#003#000000 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: syncrepl_message_to_op: rid=034 tid bacef700 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: syncrepl_null_callback : error code 0x14 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: slap_graduate_commit_csn: removing 0x1d0f8100 20190605063503.289350Z#000000#003#000000 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: syncrepl_message_to_op: rid=034 be_modify cn=PRPHDOPMIH3F_3,ou=PRPHDOPMIH3F,ou=pos,ou=grouper2,dc=authorise,dc=ed,dc=ac,dc=uk (20) Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: do_syncrep2: rid=034 delta-sync lost sync on (reqStart=20190605063503.000414Z,cn=accesslog), switching to REFRESH Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: slap_queue_csn: queueing 0x1b5c87c0 20190605063503.289350Z#000000#003#000000 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: syncrepl_message_to_op: rid=036 tid b62df700 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: syncrepl_null_callback : error code 0x14 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: slap_graduate_commit_csn: removing 0x1b5c87c0 20190605063503.289350Z#000000#003#000000 Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: syncrepl_message_to_op: rid=036 be_modify cn=PRPHDOPMIH3F_3,ou=PRPHDOPMIH3F,ou=pos,ou=grouper2,dc=authorise,dc=ed,dc=ac,dc=uk (20) Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: do_syncrep2: rid=036 delta-sync lost sync on (reqStart=20190605063503.000361Z,cn=accesslog), switching to REFRESH Then a number of SYNC_ID_SET messages: Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: do_syncrep2: rid=035 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: do_syncrep2: rid=034 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: do_syncrep2: rid=036 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: do_syncrep2: rid=035 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: do_syncrep2: rid=034 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: do_syncrep2: rid=036 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Jun 5 07:35:03 cauth04.authorise.is.ed.ac.uk slapd[18267]: do_syncrep2: rid=035 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Before finally a whole bunch of: Jun 5 07:35:20 cauth04.authorise.is.ed.ac.uk slapd[18267]: nonpresent_callback: rid=035 present UUID 8573adfa-71c7-4a9c-ab64-54d6c7f51e25, dn dc=authorise,dc=ed,dc=ac,dc=uk Jun 5 07:35:20 cauth04.authorise.is.ed.ac.uk slapd[18267]: nonpresent_callback: rid=035 present UUID 555bdc68-06ee-443c-9b33-6c8355c0a00d, dn ou=is,dc=authorise,dc=ed,dc=ac,dc=uk Jun 5 07:35:20 cauth04.authorise.is.ed.ac.uk slapd[18267]: nonpresent_callback: rid=035 present UUID 8749c8a0-0b06-4dc0-b1bd-ca85f3077603, dn ou=hss,dc=authorise,dc=ed,dc=ac,dc=uk Jun 5 07:35:20 cauth04.authorise.is.ed.ac.uk slapd[18267]: nonpresent_callback: rid=035 present UUID 5d59b0fd-68f1-44b7-a2af-f4aec00c7857, dn ou=mvm,dc=authorise,dc=ed,dc=ac,dc=uk Jun 5 07:35:20 cauth04.authorise.is.ed.ac.uk slapd[18267]: nonpresent_callback: rid=035 present UUID d75a41f2-a279-4cf2-a8e6-033c6821b6b2, dn ou=sce,dc=authorise,dc=ed,dc=ac,dc=uk (At which point CPU usage on journald and rsyslog understandably go through the roof). There is a (possibly self-inflicted) point of pain where we have an exattrs=memberOf in our syncrepl config to work around another replication issue so this means that any user objects which are REFRESH'ed end up losing all their group memberships. I'm mitigating this at present by periodically dumping the data from the "master" and re-generating the databases on the "consumers" but this is more of a sticking plaster approach. Are there any known bugs/ regressions with delta-syncrepl in 2.4.47? One idea I've had is to go to a true single-master config by setting the current consumers to be read-only and having a single olcSyncrepl clause for the master on these 3 servers. My config from one of the consumers is listed below although the master config is identical bar the olcSyncrepl lines and olcSaslHost value. I've redacted the schema and olcAccess entries and the root password: If there's any obvious deficiencies in my config too that would be good to know. Kind regards, Mark dn: cn=config objectClass: olcGlobal cn: config olcConfigFile: slapd.conf olcConfigDir: slapd.d olcArgsFile: /opt/openldap/var/run/slapd.args olcAttributeOptions: lang- olcAuthzPolicy: none olcAuthzRegexp: {0}"^uid=([^,/@]+)/ldapauth(@(((TEST\.)?EASE)|INF).ED.AC.UK)?,cn=(((TEST\.)?EASE)|INF).ED.AC.UK,cn=GSSAPI,cn=auth$" "uid=$1,ou=people,ou=central,dc=authorise,dc=ed,dc=ac,dc=uk" olcAuthzRegexp: {1}"^uid=(host|ldap)/([^/]+).authorise.is.ed.ac.uk,cn=EASE.ED.AC.UK,cn=GSSAPI,cn=auth$" "uid=replicator.authorise.is.ed.ac.uk,ou=people,ou=central,dc=authorise,dc=ed,dc=ac,dc=uk" olcAuthzRegexp: {2}"^uid=([^,/@]+)(@(((TEST\.)?EASE)|INF).ED.AC.UK)?,cn=(((TEST\.)?EASE)|INF).ED.AC.UK,cn=GSSAPI,cn=auth$" "uid=$1,ou=people,ou=central,dc=authorise,dc=ed,dc=ac,dc=uk" olcConcurrency: 0 olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 0 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexIntLen: 4 olcLocalSSF: 71 olcLogFile: /opt/openldap/var/log/openldap-debug.log olcLogLevel: stats olcLogLevel: sync olcPidFile: /opt/openldap/var/run/slapd.pid olcReadOnly: FALSE olcSaslHost: cauth04.authorise.is.ed.ac.uk olcSaslRealm: EASE.ED.AC.UK olcSaslSecProps: noplain,noanonymous olcSecurity: ssf=1 olcSecurity: update_ssf=112 olcSecurity: simple_bind=64 olcServerID: 3 ldaps://cauth01.authorise.is.ed.ac.uk/ olcServerID: 4 ldaps://cauth02.authorise.is.ed.ac.uk/ olcServerID: 5 ldaps://cauth03.authorise.is.ed.ac.uk/ olcServerID: 6 ldaps://cauth04.authorise.is.ed.ac.uk/ olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 12 olcTLSCACertificateFile: /opt/openldap/certs/quovadis.bundle olcTLSCertificateFile: /opt/openldap/certs/authorise.is.ed.ac.uk-QUOVADIS.crt olcTLSCertificateKeyFile: /opt/openldap/certs/authorise.is.ed.ac.uk-QUOVADIS.key olcTLSCipherSuite: HIGH:MEDIUM:+SSLv3:+SSLv2:+TLSv1:+AES256-SHA:!EXPORT olcTLSCRLCheck: none olcTLSVerifyClient: never olcTLSProtocolMin: 3.1 olcToolThreads: 2 olcWriteTimeout: 900 dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 2 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSecurity: ssf=1 olcSecurity: update_ssf=112 olcSecurity: simple_bind=64 olcSyncUseSubentry: FALSE olcMonitoring: FALSE olcSortVals: member olcSortVals: eduniServiceCode dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.regex="^uid=replicator\.authorise\.is\.ed\.ac\.uk,ou=people,ou=central,dc=authorise,dc=ed,dc=ac,dc=uk$" read by * none olcAddContentAcl: TRUE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=Manager,cn=config olcRootPW:: ************************* olcSyncUseSubentry: FALSE olcMonitoring: FALSE dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /opt/openldap/var/openldap-data/authorise olcSuffix: dc=authorise,dc=ed,dc=ac,dc=uk olcAccess: ************* olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 1 olcReadOnly: FALSE olcRootDN: cn=Manager,dc=authorise,dc=ed,dc=ac,dc=uk olcRootPW:: ********************* olcSecurity: ssf=1 olcSecurity: update_ssf=112 olcSecurity: simple_bind=64 olcSizeLimit: unlimited olcSyncUseSubentry: FALSE olcTimeLimit: unlimited olcMirrorMode: TRUE olcMonitoring: TRUE olcDbCheckpoint: 1024 10 olcDbEnvFlags: writemap olcDbEnvFlags: nometasync olcDbNoSync: FALSE olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: uidNumber pres,eq olcDbIndex: gidNumber pres,eq olcDbIndex: eduniType eq olcDbIndex: gecos pres,eq,sub olcDbIndex: eduniCategory eq olcDbIndex: mail pres,eq,sub olcDbIndex: eduniSchoolCode eq olcDbIndex: eduniIDStatus eq olcDbIndex: eduniCollegeCode eq olcDbIndex: eduniUnitCode eq olcDbIndex: eduniOrgCode eq olcDbIndex: eduniLibraryBarcode pres,eq olcDbIndex: eduniServiceCode pres,eq olcDbIndex: krbName pres,eq olcDbIndex: eduPersonAffiliation pres,eq olcDbIndex: eduPersonPrimaryAffiliation eq olcDbIndex: eduPersonPrincipalName eq olcDbIndex: eduPersonEntitlement pres,eq olcDbIndex: eduPersonTargetedID eq olcDbIndex: eduPersonScopedAffiliation pres,eq olcDbIndex: userPassword eq olcDbIndex: eduniIdmsId pres,eq olcDbIndex: sn pres,eq,sub olcDbIndex: memberUid eq olcDbIndex: uniqueMember pres,eq olcDbIndex: autoMountKey eq olcDbIndex: eduniOrganisation pres,eq,sub olcDbIndex: description pres,eq,sub olcDbIndex: eduniTitle pres,eq olcDbIndex: title pres,eq,sub olcDbIndex: eduniCardNumber pres,eq olcDbIndex: eduniRefNo pres,eq olcDbIndex: givenName pres,eq,sub olcDbIndex: member eq olcDbIndex: eduniYearOfStudy pres,eq olcDbIndex: yubiKeyId pres,eq olcDbIndex: nisMapName eq olcDbIndex: memberOf eq olcDbIndex: proxyAddresses pres,eq,sub olcDbMaxReaders: 96 olcDbMaxSize: 32212254720 olcDbMode: 0600 olcDbSearchStack: 16 olcSyncrepl: {0}rid=34 provider=ldaps://cauth01.authorise.is.ed.ac.uk/ realm=EASE.ED.AC.UK bindmethod=sasl saslmech=gssapi authcid="replicator.authorise.is.ed.ac.uk(a)EASE.ED.AC.UK" searchbase="dc=authorise,dc=ed,dc=ac,dc=uk" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" tls_reqcert=never timeout=1 keepalive=300:12:5 syncdata=accesslog exattrs="memberOf" olcSyncrepl: {1}rid=35 provider=ldaps://cauth02.authorise.is.ed.ac.uk/ realm=EASE.ED.AC.UK bindmethod=sasl saslmech=gssapi authcid="replicator.authorise.is.ed.ac.uk(a)EASE.ED.AC.UK" searchbase="dc=authorise,dc=ed,dc=ac,dc=uk" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" tls_reqcert=never timeout=1 keepalive=300:12:5 syncdata=accesslog exattrs="memberOf" olcSyncrepl: {2}rid=36 provider=ldaps://cauth03.authorise.is.ed.ac.uk/ realm=EASE.ED.AC.UK bindmethod=sasl saslmech=gssapi authcid="replicator.authorise.is.ed.ac.uk(a)EASE.ED.AC.UK" searchbase="dc=authorise,dc=ed,dc=ac,dc=uk" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" tls_reqcert=never timeout=1 keepalive=300:12:5 syncdata=accesslog exattrs="memberOf" entryCSN: 20190528133331.277387Z#000000#006#000000 dn: olcOverlay={0}dynlist,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcDynamicList olcOverlay: {0}dynlist olcDlAttrSet: {0}groupOfURLs memberURL dn: olcOverlay={1}memberof,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcMemberOf olcOverlay: {1}memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfNames olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf dn: olcOverlay={2}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top objectClass: olcSyncProvConfig olcOverlay: {2}syncprov dn: olcOverlay={3}accesslog,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {3}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 02+00:00 00+04:00 olcAccessLogSuccess: TRUE dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /opt/openldap/var/openldap-data/accesslog olcSuffix: cn=accesslog olcAccess: {0}to * by dn.exact="uid=replicator.authorise.is.ed.ac.uk,ou=people,ou=central,dc=authorise,dc=ed,dc=ac,dc=uk" write by dn="cn=Manager,dc=authorise,dc=ed,dc=ac,dc=uk" write olcLimits: {0}dn.exact="uid=replicator.authorise.is.ed.ac.uk,ou=people,ou=central,dc=authorise,dc=ed,dc=ac,dc=uk" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited olcLimits: {1}dn.exact="cn=Manager,dc=authorise,dc=ed,dc=ac,dc=uk" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited olcRootDN: cn=Manager,cn=accesslog olcRootPW:: ******************************** olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart,reqDN olcDbMaxReaders: 96 olcDbMaxSize: 32212254720 olcDbMode: 0600 olcDbSearchStack: 16 dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE dn: olcDatabase={3}monitor,cn=config objectClass: olcMonitorConfig objectClass: olcDatabaseConfig objectClass: olcConfig objectClass: top olcDatabase: {3}monitor olcAccess: {0}to dn.subtree="cn=monitor" by dn.exact="cn=Manager,cn=config" write by * none -- /**************************** Mark Cairney ITI Enterprise Services Information Services University of Edinburgh Tel: 0131 650 6565 Email: Mark.Cairney(a)ed.ac.uk PGP: 0x435A9621 *******************************/ The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

4 6

Re: Adding an Entry Outside the DIT
by A. Yuesuen 06 Jun '19

06 Jun '19

I believe it is outside from the main DIT because the differents suffix. and i saw this documentation: https://wiki.zimbra.com/wiki/Zimbra_Directory_Service_(LDAP) at the second Picture there are two DIT. I solved my problem by building a second Database with the wanted Suffix by adding this ldif: dn: olcDatabase={2}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /var/lib/ldap/<NEWDIR> olcSuffix: <new root DN> olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=Manager,<new root DN>" write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by dn="cn=Manager,dc=<new root DN>" write by * read olcLastMod: TRUE olcRootDN: cn=Manager,<new root DN> olcRootPW: <manager password> Am Mi., 5. Juni 2019 um 19:32 Uhr schrieb Quanah Gibson-Mount < quanah(a)symas.com>: > --On Wednesday, June 05, 2019 10:18 AM +0200 "A. Yuesuen" > <ayuesuen93(a)gmail.com> wrote: > > > I have to work with a Shadow Server of my Company Ldap Server. And they > > are using for the authentication the Entry with the DN > > uid=zimbra,cn=admins,cn=zimbra but have the Suffic dn: dc=company,dc=com. > > How i can add a User with the dn uid=zimbra,cn=admins,cn=zimbra when > > the suffix ends with dn: dc=company,dc=com. > > > > Is there a way to add a Entry outside the DIT? > > What makes you believe it is outside of the DIT? Zimbra deployments use > "" > as the suffix for the database. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

2 1

LDIF import fails
by Adam Weremczuk 05 Jun '19

05 Jun '19

Hi all, I exported from LDAP version 2.4.31 (samba AD 4.0.9) as below: C:\Windows\system32>ldifde -f export.ldf -s samba.matrixscience.co.uk Connecting to "samba.matrixscience.co.uk" Logging in as current user using SSPI Exporting directory to file export.ldf Searching for entries... Writing out entries............................................................. ................................................................................ ................................................................................ ................................................................................ ................................................................................ ........................................................................ 453 entries exported The command has completed successfully When I import to 2.4.44 through php LDAP admin logging in as cn=admin,dc=matrixscience,dc=co,dc=uk the import fails on every line. It's full of 0x11 and 0x15 errors. 2 examples below: Could not add the object to the LDAP server. LDAP said: Undefined attribute type Error number: 0x11 (LDAP_UNDEFINED_TYPE) Description: The attribute type specified is invalid. LDIF text import Could not add object cn=testuser,CN=Users,DC=matrixscience,DC=co,DC=uk LDAP said: Undefined attribute type Error number: 0x11 (LDAP_UNDEFINED_TYPE) Description: The attribute type specified is invalid. Could not add the object to the LDAP server. LDAP said: Invalid syntax Error number: 0x15 (LDAP_INVALID_SYNTAX) Description: An invalid attribute value was specified. LDIF text import Could not add object cn=Domain Controllers,CN=Users,DC=matrixscience,DC=co,DC=uk LDAP said: Invalid syntax Error number: 0x15 (LDAP_INVALID_SYNTAX) Description: An invalid attribute value was specified. Am I doing something fundamentally wrong? Regards, Adam Weremczuk

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