openldap-technical June 2019

openldap-technical@openldap.org

25 participants
22 discussions

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

Adding an Entry Outside the DIT
by A. Yuesuen 05 Jun '19

05 Jun '19

Hello, 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? best wishes Ajdar

2 1

SHA-2 and other hashes
by Norman Gray 03 Jun '19

03 Jun '19

Greetings. I've been doing some reading on password hashes, in OpenLDAP and elsewhere. It's slightly harder to find explicit details about this, than I expected, and some of what I learned was unexpected to me, though probably familiar to many on this list. In the expectation I'm not the only naive one, I'd like to log these on-list, with a broad query about whether I'm understanding things correctly. There are very good discussions at [1] and [2]. SHA-256/SHA-512 on OpenLDAP doesn't mean the same as what is nominally the same hash function in glibc. In OpenLDAP, the MD5 and SHA-whatever hash of a password is the result of hashing the password plus salt -- ie, pretty much what I expected -- but in glibc's crypt(3), the $5$ and $6$ hashes are the result of an unspecified number of rounds of such hashing (the $1$/MD5 glibc hash does appear to be compatible with OpenLDAP {SMD5}, though). (Quite possibly everyone else in the world already knew this, but I didn't!) While the glibc $5$ and $6$ hashes are therefore, in principle, somewhat resistant to brute-forcing, the OpenLDAP ones are not, and so should be managed as confidential data. MD5 _isn't_ significantly worse than plain SHA-whatever for password hashing, since its discovered defects with respect to collisions are not a problem for this application (it's still resistant to 'preimages'). However both are unsafe for secure password storage, simply because they're too fast (by design), and MD5 is unusable simply because 'everyone knows MD5 is broken', so it would require tedious explanation. Thus it would seem that the SHA-2 support optionally available in the OpenLDAP distribution (in contrib/slapd-modules/passwd/sha2) doesn't actually benefit me much, over and above the MD5 and SHA-1 support available by default. However PBKDF2 (available in contrib/slapd-modules/passwd/pbkdf2) would be usable immediately, though this appears to be not the best such function available. So the two options for password storage seem to be * use {SSHA} and -- as [3] stresses -- protect password attributes as if they were clear text; or * one way or another use a hash-stretching algorithm such as bcrypt (though [4] -- *sigh*) or scrypt [5] (maybe the best option?) or PBKDF2 * (and don't worry about having to protect password attributes?). Is that about right? Is there a consensus OpenLDAP best practice here? Best wishes, Norman [1] https://crackstation.net/hashing-security.htm [2] https://security.stackexchange.com/questions/211/how-to-securely-hash-passw… [3] https://openldap.org/doc/admin24/security.html [4] https://github.com/wclarie/openldap-bcrypt/issues/1 [5] https://github.com/Tarsnap/scrypt -- Norman Gray : https://nxg.me.uk

5 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical June 2019