Search results for "starttls" - openldap-technical

Re: replica of schema info

by Francesco Malvezzi

> The correct way to enable replication after cn=config already exists is > with ldapmodify: > > dn: olcDatabase={0}config,cn=config > changetype: modify > add: olcSyncRepl > > >> It does work to add olcSyncrepl to olcDatabase={0}config,cn=config with >> a filter like: >> olcSyncrepl: {0}rid=001 provider=... binddn=... bindmethod=simple >> search base="cn=schema,cn=config" filter="(!(cn=core))" >> >> but then the whole olcDatabase={0}config,cn=config becomes a shadow >> context and I'm unable to ldapmodify anything (olcLoglevel for example). >> >> What am I missing? > > You need to set up all rids in your modify operation, each listing > provider with their own URI. Optionally, you could even have different > credentials pointing in different directions - nothing prevents this. > For n-way replication, you need to perform the same modification to n > sides. Otherwise your replicas will be read-only as you have seen. This > is the same for any database, not just n0. Go back and enable CRL > checking after you are sure that it works, if using TLS. > > Example, change the macros to suit your setup and apply this same ldif > to each of your replicas: > > dn: olcDatabase={0}config,cn=config > changetype: modify > add: olcSyncRepl > olcSyncrepl: rid=001 > provider=%%LDAP_URI_1%% > bindmethod=simple > timeout=0 > network-timeout=0 > binddn="%%CONFIG_ROOT_DN%%" > credentials="%%CONFIG_ROOT_PW%%" > keepalive=0:0:0 > starttls=critical > tls_cert="%%LDAP_SERVER%%/ssl/cert.pem" > tls_key="%%LDAP_SERVER%%/ssl/key.pem" > tls_cacert="%%CA_CHAIN_SERVERS%%" > tls_reqcert=demand > tls_crlcheck=none > filter="(objectclass=*)" > searchbase="cn=config" > scope=sub > attrs="*,+" > schemachecking=off > type=refreshAndPersist > retry="60 +" > olcSyncrepl: rid=002 > provider=%%LDAP_URI_2%% > bindmethod=simple > timeout=0 > network-timeout=0 > binddn="%%CONFIG_ROOT_DN%%" > credentials="%%CONFIG_ROOT_PW%%" > keepalive=0:0:0 > starttls=critical > tls_cert="%%LDAP_SERVER%%/ssl/cert.pem" > tls_key="%%LDAP_SERVER%%/ssl/key.pem" > tls_cacert="%%CA_CHAIN_SERVERS%%" > tls_reqcert=demand > tls_crlcheck=none > filter="(objectclass=*)" > searchbase="cn=config" > scope=sub > attrs="*,+" > schemachecking=off > type=refreshAndPersist > retry="60 +" > - > add: olcMirrorMode > olcMirrorMode: TRUE > Thank you for answering so quick. If I understand correctly, this is a n-way multi master layout for the whole cn=config. Does it mean if I ldapmodify the olcLogLevel on a replica, it will be modified on all other peers as well? So it's not what I was looking for. I was looking for a way to replicate (master -> slave) a sub-portion of the cn=config, namely the cn=schema,cn=config. BTW, olcMirrorMode turns out to be very powerful. In a master slave setup, allows me to ldapmodify slave without incurring in the "err=53 text=shadow context; no update referral". Am I allowed to insert a olcMirrorMode in a slave while using master slave setup? Or am I just exploiting a grey-zone configuration? I am scared to mark as 'mirror' a slave server. It looks wrong. If instead is correct, my problem is solved. thank you, Francesco

11 years, 1 month

slapd-meta

by Fr3ddie

Hello to the list, I'm trying to configure the slapd-meta OpenLDAP backend on an online cn=config configuration with no luck. Slapd version is 2.4.39 (the maximum I can achieve on the target machines building from vanilla source). The documentation is clear but too concise for me so I will try to explain what I'm trying to do to see if there is anybody that can help me. Currently I have 3 slapd servers that share a common root for the DIT, i.e.: dc=loc1,dc=root dc=loc2,dc=root dc=loc3,dc=root What I would like to achieve is to obtain a fourth server that contains the previous trees, along with its own tree, i.e. a server that contains: dc=loc0,dc=root (locally hosted data) dc=loc1,dc=root (coming from the first server, chasing referrals) dc=loc2,dc=root (coming from the second server, chasing referrals) dc=loc3,dc=root (coming from the third server, chasing referrals) this way, all the clients connecting to this server will be able to retrieve data also from the other three remote servers. As far as I understood, I only need to configure the "loc0" server to access the other three servers and get the data to serve to clients. I have already configured the fourth server with its local DIT and this is the configuration: # cat 'cn=config.ldif' dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcPidFile: /var/run/slapd/slapd.pid structuralObjectClass: olcGlobal creatorsName: cn=config olcServerID: 1 olcThreads: 32 olcToolThreads: 8 olcRequires: LDAPv3 olcConnMaxPendingAuth: 100 olcTLSCACertificateFile: /etc/ssl/certs/my_ca_cert.pem olcTLSCertificateFile: /etc/ssl/certs/this-host_x509_cert.pem olcTLSCertificateKeyFile: /etc/ssl/private/this-host_x509_key.key olcTLSVerifyClient: try olcTimeLimit: 600 olcLogLevel: stats2 sync [...] # cat 'cn=module{0}.ldif' dn: cn=module{0} objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_hdb olcModuleLoad: {1}syncprov olcModuleLoad: {2}accesslog structuralObjectClass: olcModuleList [...] Schema files are the following: cn={0}core.ldif cn={1}cosine.ldif cn={2}nis.ldif cn={3}inetorgperson.ldif cn={4}dyngroup.ldif cn={5}kerberos.ldif # cat 'olcDatabase={1}hdb.ldif' dn: olcDatabase={1}hdb objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=loc0,dc=root olcAccess: {0}to attrs=userPassword,shadowLastChange,krbPrincipalKey by dn="cn =admin,dc=loc0,dc=root" write by anonymous auth by self write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by dn="cn=admin,dc=loc0,dc=root" write by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=loc0,dc=root olcRootPW:: xxxxxxxxxxxxxxxxxxxx olcDbCacheSize: 10000 olcDbCheckpoint: 512 10 olcDbConfig: {0}set_cachesize 0 524288000 1 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbConfig: {4}set_flags DB_LOG_AUTOREMOVE olcDbIDLcacheSize: 30000 olcDbIndex: default pres,eq [...] structuralObjectClass: olcHdbConfig olcSyncrepl: {0}rid=0 provider=ldap://second-host.loc0.root bindmethod=s imple binddn="cn=admin,dc=loc0,dc=root" credentials=xxxxxx searchbase="dc=loc0,dc=root" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObj ect)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syn cdata=accesslog starttls=yes olcMirrorMode: TRUE [...] On top of this DB I have the "syncprov" and the "accesslog" overlays configured (these are two servers in "MirrorMode", configured following the OpenLDAP admin documentation). I believe this DB is the ones containing the actual "loc0" DIT data... Then I have the accesslog DB for the replica (with the syncprov overlay on top): # cat 'olcDatabase={2}hdb.ldif' dn: olcDatabase={2}hdb objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcRootDN: cn=admin,dc=loc0,dc=root olcDbConfig: {0}set_cachesize 0 524288000 1 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbConfig: {4}set_flags DB_LOG_AUTOREMOVE olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart [...] On top of this environment I start loading the needed modules with this LDIF file: version: 1 dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: back_ldap - add: olcModuleLoad olcModuleLoad: back_meta - add: olcModuleLoad olcModuleLoad: rwm and it seems I'm able to load the new modules without errors into the configuration, thus I obtain: # cat 'cn=module{0}.ldif' dn: cn=module{0} structuralObjectClass: olcModuleList objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_hdb olcModuleLoad: {1}syncprov olcModuleLoad: {2}accesslog olcModuleLoad: {3}back_ldap olcModuleLoad: {4}back_meta olcModuleLoad: {5}rwm [...] Now I try to load the slapd-meta directives into a new database using this LDIF: version: 1 dn: olcDatabase={3}meta,cn=config objectClass: olcDatabaseConfig objectClass: olcMetaConfig olcDatabase: {3}meta olcSuffix: dc=root olcDbURI: "ldap://server-loc1.loc1.root/dc=loc1,dc=root" olcDbIdAssertBind: bindmethod=simple binddn="cn=admin,dc=loc1,dc=root" credentials=xxxxxx starttls=yes tls_reqcert=demand olcDbURI: "ldap://server-loc2.loc2.root/dc=loc2,dc=root" olcDbIdAssertBind: bindmethod=simple binddn="cn=admin,dc=loc2,dc=root" credentials=xxxxxx starttls=yes tls_reqcert=demand olcDbURI: "ldap://server-loc3.loc3.root/dc=loc3,dc=root" olcDbIdAssertBind: bindmethod=simple binddn="cn=admin,dc=loc3,dc=root" credentials=xxxxxx starttls=yes tls_reqcert=demand but I obtain an error that sticks me trying various combinations without success: # ldapadd -Y EXTERNAL -H ldapi:/// -f slapd-META-DB-CREATION.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "olcDatabase={3}meta,cn=config" ldap_add: Object class violation (65) additional info: attribute 'olcDbURI' not allowed and: # tail /var/log/openldap/slapd.log Nov 9 19:47:17 server01 slapd[32392]: conn=1025 op=2 ENTRY dn="dc=loc0,dc=root" Nov 9 19:47:29 server01 slapd[32392]: conn=1052 op=2 INTERM oid=1.3.6.1.4.1.4203.1.9.1.4 Nov 9 19:49:47 server01 slapd[32392]: conn=1327 op=2 ENTRY dn="dc=loc0,dc=root" Nov 9 19:52:17 server01 slapd[32392]: conn=1628 op=2 ENTRY dn="dc=loc0,dc=root" Nov 9 19:54:46 server01 slapd[32392]: conn=1929 op=2 ENTRY dn="dc=loc0,dc=root" Nov 9 19:57:07 server01 slapd[32392]: Entry (olcDatabase={3}meta,cn=config), attribute 'olcDbURI' not allowed Into the slapd-meta documentation the "URI" directive is mentioned but the "DbURI" seems to raise a "better error", in fact if I try to modify the above LDIF file using "URI" I obtain: SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "olcDatabase={3}meta,cn=config" ldap_add: Undefined attribute type (17) additional info: olcUri: attribute type undefined Moreover, it is not stated into the slapd-meta docs that the slapd-ldap backend is needed by slapd-meta but, anyway, I think its needed because if I try to load the slapd-meta alone it raises an error (I don't remember exactly which one). At this point I'm stuck to this error and I wasn't able to find any hint on the web to solve this :( The examples I was able to find were related with the static slapd.conf configuration, I counldn't find any "full" configuration example using the cn=config. I'm wondering if I should create a "cn=root" actual DB first and then link the sub-DITs to it, or, maybe, add some other overlay... I really can't understand how it should work :( Can please anybody help me? Thank you very much

9 years, 7 months

Can't contact LDAP server

by Mark

I have a 2-way multi-master setup on srv1.foo.com (EDT) and srv2.foo.com (PDT). For about 2hrs this morning srv2 was syslog'ing "Can't contact LDAP server" while it was in a replication conversation with srv1: Sep 9 05:29:45 srv2 slapd[9413]: do_syncrep2: rid=001 (-1) Can't contact LDAP server Sep 9 05:29:45 srv2 slapd[9413]: do_syncrepl: rid=001 rc -1 retrying Sep 9 05:30:00 srv2 slapd[9413]: do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Sep 9 05:30:01 srv2 last message repeated 34 times Sep 9 05:30:01 srv2 slapd[9413]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Sep 9 05:30:01 srv2 slapd[9413]: syncrepl_entry: rid=001 be_search (0) Sep 9 05:30:01 srv2 slapd[9413]: syncrepl_entry: rid=001 ... Sep 9 05:30:01 srv2 slapd[9413]: syncprov_matchops: skipping original sid 003 Sep 9 05:30:01 srv2 slapd[9413]: syncprov_matchops: skipping original sid 003 Sep 9 05:30:01 srv2 slapd[9413]: syncrepl_entry: rid=001 be_modify ... (0) Sep 9 05:30:01 srv2 slapd[9413]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Sep 9 05:30:01 srv2 slapd[9413]: syncrepl_entry: rid=001 be_search (0) Sep 9 05:30:01 srv2 slapd[9413]: syncrepl_entry: rid=001 ... Sep 9 05:30:01 srv2 slapd[9413]: syncprov_matchops: skipping original sid 003 Sep 9 05:30:01 srv2 slapd[9413]: syncprov_matchops: skipping original sid 003 Sep 9 05:30:01 srv2 slapd[9413]: syncrepl_entry: rid=001 be_modify ... (0 ... Sep 9 05:30:29 srv2 slapd[9413]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Sep 9 05:30:29 srv2 slapd[9413]: syncrepl_entry: rid=001 be_search (0) Sep 9 05:30:29 srv2 slapd[9413]: syncrepl_entry: rid=001 ... Sep 9 05:30:29 srv2 slapd[9413]: syncprov_matchops: skipping original sid 003 Sep 9 05:30:29 srv2 slapd[9413]: syncprov_matchops: skipping original sid 003 Sep 9 05:30:29 srv2 slapd[9413]: syncrepl_entry: rid=001 be_modify ... (0) Sep 9 05:30:29 srv2 slapd[9413]: do_syncrep2: rid=001 (-1) Can't contact LDAP server Sep 9 05:30:29 srv2 slapd[9413]: do_syncrepl: rid=001 rc -1 retrying Sep 9 05:30:45 srv2 slapd[9413]: do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Sep 9 05:30:45 srv2 last message repeated 34 times Sep 9 05:30:45 srv2 slapd[9413]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Sep 9 05:30:45 srv2 slapd[9413]: syncrepl_entry: rid=001 be_search (0) Sep 9 05:30:45 srv2 slapd[9413]: syncrepl_entry: rid=001 ... Sep 9 05:30:45 srv2 slapd[9413]: syncprov_matchops: skipping original sid 003 Sep 9 05:30:45 srv2 slapd[9413]: syncprov_matchops: skipping original sid 003 Sep 9 05:30:45 srv2 slapd[9413]: syncrepl_entry: rid=001 be_modify ... (0) ... During that time no errors or closes were logged in the srv2 syslog. I tried bouncing each slapd, but the issue continued. After about 2hrs it stopped occurring. My question is: What would cause the "Can't contact LDAP server message"? The srv1 side doesn't log any error or log that the connection was closed. The text "Can't contact" would seem to imply that the error occurred during a connection attempt, but these errors seemed to occur during a active conversation. Does the srv2 side notice an read or write error on the socket and abandon the connection? I've been looking through the code trying to determine what causes that error message. Does it happen on a single read/write error? Does it retry a few times? I hate to just say "Must be a network error" without some due diligence. My env: RHEL 5.5 OpenLDAP 2.4.25 BerkeleyDB 4.8.40 OpenSSL 1.0.0d Cyrus SASL 2.1.23 2-way Multi-master ==================== #srv1 slapd.conf -> slapd.d include /appl/openldap/etc/schema/core.schema include /appl/openldap/etc/schema/cosine.schema include /appl/openldap/etc/schema/nis.schema include /appl/openldap/etc/schema/inetorgperson.schema include /appl/openldap/etc/schema/foo.com.schema argsfile /appl/openldap/var/run/slapd.args pidfile /appl/openldap/var/run/slapd.pid threads 16 tool-threads 4 idletimeout 300 writetimeout 5 reverse-lookup off timelimit time.soft=30 time.hard=300 sizelimit size.soft=500 size.hard=1000 password-hash {SSHA} loglevel stats sync serverid 1 ldap://srv1.foo.com:10806 modulepath /appl/openldap/libexec moduleload back_monitor.la moduleload back_hdb.la moduleload syncprov.la database config rootdn cn=manager,dc=foo,dc=com database monitor rootdn cn=manager,dc=foo,dc=com database hdb rootdn cn=manager,dc=foo,dc=com suffix dc=foo,dc=com directory /appl/openldap/var/data/dc=foo,dc=com cachesize 1000 idlcachesize 3000 cachefree 5 checkpoint 128 15 index objectClass eq index entryCSN eq index entryUUID eq syncrepl rid=001 provider=ldap://srv1.foo.com:10806 type=refreshAndPersist retry="15 +" bindmethod=simple binddn="cn=replicator,dc=foo,dc=com" credentials="secret" searchbase="dc=foo,dc=com" starttls=no schemachecking=off syncrepl rid=002 provider=ldap://srv2.foo.com:10806 type=refreshAndPersist retry="15 +" bindmethod=simple binddn="cn=replicator,dc=foo,dc=com" credentials="secret" searchbase="dc=foo,dc=com" starttls=no schemachecking=off mirrormode TRUE overlay syncprov syncprov-checkpoint 50 10 syncprov-sessionlog 100 limits dn.exact="cn=replicator,dc=foo,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited ==================== #srv2 slapd.conf -> slapd.d include /appl/openldap/etc/schema/core.schema include /appl/openldap/etc/schema/cosine.schema include /appl/openldap/etc/schema/nis.schema include /appl/openldap/etc/schema/inetorgperson.schema include /appl/openldap/etc/schema/foo.com.schema argsfile /appl/openldap/var/run/slapd.args pidfile /appl/openldap/var/run/slapd.pid threads 16 tool-threads 4 idletimeout 300 writetimeout 5 reverse-lookup off timelimit time.soft=30 time.hard=300 sizelimit size.soft=500 size.hard=1000 password-hash {SSHA} loglevel stats sync serverid 2 ldap://srv2.foo.com:10806 modulepath /appl/openldap/libexec moduleload back_monitor.la moduleload back_hdb.la moduleload syncprov.la database config rootdn cn=manager,dc=foo,dc=com database monitor rootdn cn=manager,dc=foo,dc=com database hdb rootdn cn=manager,dc=foo,dc=com suffix dc=foo,dc=com directory /appl/openldap/var/data/dc=foo,dc=com cachesize 1000 idlcachesize 3000 cachefree 5 checkpoint 128 15 index objectClass eq index entryCSN eq index entryUUID eq syncrepl rid=001 provider=ldap://srv1.foo.com:10806 type=refreshAndPersist retry="15 +" bindmethod=simple binddn="cn=replicator,dc=foo,dc=com" credentials="secret" searchbase="dc=foo,dc=com" starttls=no schemachecking=off syncrepl rid=002 provider=ldap://srv2.foo.com:10806 type=refreshAndPersist retry="15 +" bindmethod=simple binddn="cn=replicator,dc=foo,dc=com" credentials="secret" searchbase="dc=foo,dc=com" starttls=no schemachecking=off mirrormode TRUE overlay syncprov syncprov-checkpoint 50 10 syncprov-sessionlog 100 limits dn.exact="cn=replicator,dc=foo,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited

13 years, 9 months

RE: [EXT] Re: RE: ldap proxy

by Windl, Ulrich

Actually I would not trust any software that sends passwords unencrypted over the wire today (maybe localhost connections excepted). Do you have specific reasons not to use an encrypted connection? It's non-obvious what you actually want to do. Maybe an X-Y-problem (https://en.wikipedia.org/wiki/XY_problem)? Kind regards, Ulrich Windl > -----Original Message----- > From: Fred N <fred750164(a)gmail.com> > Sent: Thursday, May 1, 2025 11:20 PM > To: openldap-technical(a)openldap.org > Subject: [EXT] Re: RE: ldap proxy > > Hello, > > I’m trying to set up an OpenLDAP architecture where a client connects to a > proxy using an unencrypted connection with a simple bind (e.g., via > ldapsearch), and the proxy then connects securely to a backend LDAP server > using TLS client certificate authentication via SASL EXTERNAL. > > Here is what I’m aiming for: > • The client uses simple bind over ldap:// to connect to the > proxy. > • The proxy should ignore the client’s bind credentials and use > its own certificate to connect to the backend via ldaps:// or ldap+starttls:// > using SASL EXTERNAL. > • The backend uses authz-regexp rules to map the proxy’s > certificate DN to a local identity, which is authorized to perform the search on > behalf of the client. > > I’ve tested this setup with OpenLDAP versions 2.4, 2.5, and 2.6 but have not > been able to make it work. > > I gave a configuration in my first message and I tried several configurations > but I always come back to this one when I read the docs or look at the forums > > Regards

1 month, 1 week

Re: In case ldap_install_tls fails, should we call ldap_unbind_ext?

by sbose＠redhat.com

Howard Chu wrote: > Simon Pichugin wrote: > > Hello, > > I have a question regarding libldap function ldap_install_tls(). > > > > If it fails, is it the right thing to call ldap_unbind_ext() after that? > Probably. > > > If we call it, does it mean that ldap_install_tls() made a bind? > > > No. > > > Or do we call ldap_install_tls() on the connection that is already > > bound? > That's not the usual way to do things, no. Most likely you should be using > ldap_start_tls() instead. > > > Sorry if the information is available somewhere, but I missed to find > > it. > Most likely ldap_install_tls() should never have been released as a public > API. You can't use it correctly without coordinating with the server, which > ldap_start_tls() already does. I suggest you forget that this function exists. Hi, thanks for the recommendation. We are currently using ldap_install_tls() after calling ldap_init_fd() with a file-descriptor connected to port 636 and a ldaps uri. Can ldap_start_tls() but used in this case as well? I had the assumption that sending the StartTLS exop at this state might confuse the server? Thanks for your help. bye, Sumit > > > The only thing I found is that OpenLDAP server > > calls ldap_unbind_ext() in case of failure but maybe I miss something... > > > > https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/ba... > > > The code you reference is inside an #ifdef block whose comments state that > the feature is unimplemented. > > So again, don't use this function. > > > > Thank you, > > Simon

4 years, 6 months

RE: Issues with resetting user password

by CLARKE, ED C

Hello Quanah, Thank you very much, I will try that and let you know on Monday, I really appreciate it. Have a great weekend all. Thanks, Ed -----Original Message----- From: Quanah Gibson-Mount <quanah(a)symas.com> Sent: Friday, September 18, 2020 4:46 PM To: CLARKE, ED C <ec4397(a)att.com>; openldap-technical(a)openldap.org Subject: RE: Issues with resetting user password --On Friday, September 18, 2020 2:42 PM -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > Nothing you've provided shows any attempt to connect to the ldap > server using an SIMPLE BIND with the user DN > "uid=foxdiv,ou=People,dc=att,dc=com" and a password. As an example, the correct way to test the user password change went through would be something like: ldapwhoami -x -H ldap://ldap.example.com:389/ -D uid=foxdiv,ou=People,dc=att,dc=com -W If slapd is running on ldaps, adjust the URI accordingly. If it's on port 389 but requires startTLS, add the -ZZ option, etc. You will be prompted for the password for the LDAP user. If the operation succeeds, then the password was correctly updated in LDAP. It sounds as though you may be attempting *nix <-> ldap integration, but that hasn't been specified. Regardless, the above ldapwhoami command is the next step in confirming whether or not the password was correctly changed and accepted on the user side. If that works, and you're attempting the *nix<->ldap integration and *that* is not working, it would imply that the integration is not configured correctly. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.symas.com&d=DwICAg&… >

4 years, 9 months

Re: syncrepl does not work as expected

by Scott Classen

Hello Kumar, What does the entire olcSyncrepl entry look like on your consumer? There are many options as you can see from the documentation: 5.2.5.8. olcSyncrepl <> olcSyncrepl: rid=<replica ID> provider=ldap[s]://<hostname>[:port] [type=refreshOnly|refreshAndPersist] [interval=dd:hh:mm:ss] [retry=[<retry interval> <# of retries>]+] searchbase=<base DN> [filter=<filter str>] [scope=sub|one|base] [attrs=<attr list>] [attrsonly] [sizelimit=<limit>] [timelimit=<limit>] [schemachecking=on|off] [bindmethod=simple|sasl] [binddn=<DN>] [saslmech=<mech>] [authcid=<identity>] [authzid=<identity>] [credentials=<passwd>] [realm=<realm>] [secprops=<properties>] [starttls=yes|critical] [tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>] [tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand] [tls_cipher_suite=<ciphers>] [tls_crlcheck=none|peer|all] [logbase=<base DN>] [logfilter=<filter str>] [syncdata=default|accesslog|changelog] And unless I missed it in one of your previous responses, I really don’t know the full set of olcSyncrepl parameters you have specified. Scott > On Jun 16, 2020, at 7:31 AM, Kumar Rahul <rahul2002mit(a)gmail.com> wrote: > > Hi Quanah > > Please let me know if you need more information. > > Thanks > Rahul

4 years, 12 months

syncprov_db_open: invalid config, lastmod must be enabled

by Angel L. Mateo

Hi, I'm trying to configure chain overlay in a ldap replica consumer. My final purpose is that if this node receives an update, it directly tries to make it in the provider node, instead of returning the referrral. Is that possible? I think so... But I have a problem with the configuration. My config is ... moduleload back_ldap moduleload syncprov ... database hdb suffix dc=<mysuffix> ... overlay syncprov syncrepl rid=31 provider="ldap://<provider>" binddn="<replica user dn>" bindmethod=simple credentials=<password> searchbase="dc=<mysuffix>" type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 +" timeout=1 overlay chain chain-max-depth 1 chain-return-error true chain-uri ldap://<provider> chain-rebind-as-user yes chain-idassert-bind bindmethod=simple binddn=<replica user dn> credentials=<password> starttls=no mode="self" But when I test configuration with slaptest, I get: root@canis32:/etc/ldap# slaptest -f /etc/ldap/slapd.conf syncprov_db_open: invalid config, lastmod must be enabled backend_startup_one (type=hdb, suffix="<mysuffix>"): bi_db_open failed! (-1) slap_startup failed (test would succeed using the -u switch) and I can't run slapd. Any idea? I'm running slapd 2.4.21 (ubuntu lucid package) -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información _o) y las Comunicaciones Aplicadas (ATICA) / \\ http://www.um.es/atica _(___V Tfo: 868887590 Fax: 868888337

13 years, 5 months

TLS replication/SALS bindmethod

by Darouichi, Aziz

Hi, I configured Muti-master replication, everything worked fine till I hashed rootpw to confirm to a hardcoded password in Oracle. I configured OpenLDAP servers to us SALS. This is my configuration. provider=ldap://xxx.xxx.xxx:389 bindmethod=sasl saslmech=external starttls=yes tls_cert=/etc/pki/tls/certs/slapd.pem tls_key=/etc/pki/tls/private/ldap.pem tls_cacert=/etc/pki/tls/certs/ca-bundle.crt tls_reqcert=demand binddn="cn=ldap,dc=establishment,dc=edu" credentials={SSHA}2vNffW+5hEolqIykgH9tCpxq9jTTVSSu searchbase="dc=establishment,dc=edu" schemachecking=on type=refreshAndPersist retry="60 +" when I run ldapsearch against servers I get response from both machines. ldapsearch -H ldap://server.establishment.edu -D "cn=ldap,dc=establishment,dc=edu" -w "PASSWORD" -x -b "dc=establishment ,dc=edu" "(objectclass=*)" uid. This what I get in the logs: May 23 09:37:01 ldap1 slapd[1559]: slap_client_connect: URI=ldap://xxx.xxx.edu:389 ldap_sasl_interactive_bind_s failed (-6) May 23 09:37:01 ldap1 slapd[1559]: do_syncrepl: rid=002 rc -6 retrying May 23 09:37:58 ldap1 slapd[1559]: conn=5220 op=0 do_extended: unsupported operation "1.3.6.1.4.1.1466.20037" May 23 09:38:01 ldap1 slapd[1559]: slap_client_connect: URI=ldap://xxx.xxx.edu:389 Warning, ldap_start_tls failed (2) May 23 09:38:01 ldap1 slapd[1559]: slap_client_connect: URI=ldap://xxx.xxx.edu:389 ldap_sasl_interactive_bind_s failed (-6) May 23 09:38:01 ldap1 slapd[1559]: do_syncrepl: rid=002 rc -6 retrying Thanks

14 years

Re: connection problem with ldapmodify -Y EXTERNAL -H ldapi:///

by Dan White

On 03/10/11 21:43 +0200, Andreas Rudat wrote: >Am 03.10.2011 20:51, schrieb Dan White: >>On 03/10/11 19:41 +0200, Andreas Rudat wrote: >>>tls_cert >>>tls_key >> >>My mail client may have corrupted this part of your configuration. You'll >>of course need valid entries here. >> >These options are defaults in my conf. With some comments, after >installing the slapd package You'll need to create a (client) certificate and populate those two values, or otherwise find a way to specify them while performing your ldapsearch command. I don't see how you will will be able to obtain SASL EXTERNAL over STARTTLS otherwise. >>And again, you'll need to properly configure >>TLSVerifyClient/olcTLSVerifyClient in your OpenLDAP server config. >> >So I added this to cn=config: > >|*|add: olcTLSCACertificateFile >olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem >- >add: olcTLSCertificateFile >olcTLSCertificateFile: /etc/ssl/certs/ldap01_slapd_cert.pem >- >add: olcTLSCertificateKeyFile >olcTLSCertificateKeyFile: /etc/ssl/private/ldap01_slapd_key.pem|* > >I think, thats what you meant? ... and olcTLSVerifyClient. >When properly configured, your list of supportedSASLMechanisms should >>include 'EXTERNAL'. >> >>For reference, see the manpages for ldap.conf and slapd-config (or >>slapd.conf), and see the OpenLDAP Administrator's Guide. I'd recommend depending a lot less on the howto you are reading, and a lot more on the above documentation. -- Dan White

13 years, 8 months

openldap-technical search results for query "starttls"