Search results for "starttls" - openldap-technical

Re: how can make slave use tls to connect to master for syncrepl (solved)

by zhong ming wu

Never mind. I had to put this line in the sysrepl section of the slave starttls=yes Sorry about the noise. On Sun, May 27, 2012 at 10:29 PM, zhong ming wu <mr.z.m.wu(a)gmail.com> wrote: > Hello > > I am using version 2.4 and in the process of setting up a master/slave > pair using syncrepl. > > This is working as expected if I don't have enforce security and > confidentiality with "security ssf=128" global directive in the > master. > As soon as I turn it on, replication stops working. > > It seems that the slave consumer is not using TLS to connect to > master. However I can use 'ldapsearch' with '-ZZ' option to connect > to master from slave and get all records I want. > > On my slave machine, I also have the following directive > > TLS_CACERT /etc/pki/tls/certs/ca.crt.crl > > in ldap.conf > > Notice that without this line 'ldapXXX' commands with '-ZZ' fails from > slave to master. This confirms that at least 'ldap.conf' is in the > correct location at least as far as 'ldapXXX' commands are concerned. > > Can someone point me in the right direction? I have read many > chapters on this page > > http://www.openldap.org/doc/admin24/index.html > > Both slave and master are on centos 6.2 and openldap software is > standard centos rpm. > > Here are the log entries on the master when slave fails to bind with TLS > > May 27 22:14:53 cat slapd[2456]: conn=1000 fd=13 ACCEPT from > IP=192.168.0.2:41083 (IP=0.0.0.0:389) > May 27 22:14:53 cat slapd[2456]: conn=1000 op=0 BIND > dn="cn=root,dc=example,dc=com" method=128 > May 27 22:14:53 cat slapd[2456]: conn=1000 op=0 RESULT tag=97 err=13 > text=confidentiality required > May 27 22:14:53 cat slapd[2456]: conn=1000 op=1 UNBIND > May 27 22:14:53 cat slapd[2456]: conn=1000 fd=13 closed > > Sincerely > > Mr Wu

13 years

Problem with verifying replication state with contextCSN

by Liam Gretton

I have a single provider and a single consumer, both quite lightly loaded serving a few hundred clients between them for nss_ldap. I've been trying to monitor the replication state by comparing contextCSN on both systems, but I'm finding that on the consumer contextCSN is more often than not older than the most recent entryCSN value. I read contextCSN as so: ldapsearch -H ldap://ldapserver1.company.org -LLL -x -s base -b dc=company,dc=org contextCSN contextCSN: 20110715120001.914244Z#000000#000#000000 ldapsearch -H ldap://ldapserver2.company.org -LLL -x -s base -b dc=company,dc=org contextCSN contextCSN: 20110715085237.656585Z#000000#000#000000 Looking at the values of entryCSN for ldapserver2 (the consumer): ldapsearch + | grep entryCSN | sort -u ... entryCSN: 20110714154009.500299Z#000000#000#000000 entryCSN: 20110715085237.656585Z#000000#000#000000 entryCSN: 20110715120001.914244Z#000000#000#000000 It can be seen that the most recent entryCSN matches the contextCSN of the provider, but its own contextCSN is an entry behind (often its two or three entries old). The replication is up to date, but contextCSN on the consumer doesn't seem to be getting updated in all circumstances. The consumer is replicating using syncrepl refreshAndPersist. Here's the syncrepl configuration for the consumer: syncrepl rid=001 provider=ldap://ldapserver1.company.org type=refreshAndPersist interval=00:00:05:00 retry="60 +" searchbase="dc=company,dc=org" sizelimit=unlimited timelimit=unlimited binddn="cn=replication,ou=special users,dc=company,dc=org" bindmethod=simple credentials=password schemachecking=off starttls=critical I'm also using the memberOf overlay. I see in the list archives that this has been reported before, but I can't find a bug report to go with it: <http://www.openldap.org/cgi-bin/wilma_hiliter/openldap-technical/201103/msg…> I'm using OpenLDAP 2.4.12 on 64-bit openSUSE 11.1. I haven't been able to find time to set up a test environment with the latest OpenLDAP to see if the problem exists there. Has anybody else seen this behaviour in the latest OpenLDAP? My current workaround to monitor replication status is to modify a record created for the purpose and verify that the consumer has picked it up. -- Liam Gretton liam.gretton(a)le.ac.uk HPC Architect http://www.le.ac.uk/its IT Services Tel: +44 (0)116 2522254 University of Leicester, University Road Leicestershire LE1 7RH, United Kingdom

13 years, 11 months

LDAP proxy issue

by jason cafarelli

note: Apologize if this dupes; think i sent original out before i was approved on mailing list. A bit stuck; bear with me; somewhat of a LDAP nubbie; sure i am missing something simple, Trying to get a local server to AUTH locally to its own openldap-server and then proxy to corporate LDAP if user is not found locally. 1. Local users work 2. AUTH to local LDAP server works 3. AUTH to corporate LDAP does NOT work 4. LDAP search to corporate works when using local server (ack!?!) user = corporate LDAP account internal ldap = users - internal.com corporate ldap = people - datacenter.corporate.com note: anonymous bind is enabled on corporate. oot@ sssd]# ldapsearch -h 127.0.0.1 -x -b "uid=user,ou=people,dc=datacenter,dc=corporate,dc=com" # extended LDIF # # LDAPv3 # base <uid=user,ou=people,dc=datacenter,dc=corporate,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # user, People, datacenter.corporate.com dn: uid=user,ou=People,dc=datacenter,dc=corporate,dc=com uid: user cn: objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount shadowMax: shadowWarning: loginShell: /bin/bash uidNumber: gidNumber: homeDirectory: /home/users/user gecos: user shadowLastChange: 16461 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Setup slap.d; ####################################################################### # database definitions ####################################################################### database bdb suffix "dc=internal,dc=com" checkpoint 1024 15 rootdn "cn=adm,dc=internal,dc=com" rootpw {SSHA}aaaaa directory /var/lib/ldap # Indices to maintain for this database index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub # Replicas of this database #replogfile /var/lib/ldap/openldap-master-replog #replica host=ldap-1.example.com:389 starttls=critical # bindmethod=sasl saslmech=GSSAPI # authcId=host/ldap-master.example.com(a)EXAMPLE.COM #proxy ldap database ldap suffix "ou=People,dc=datacenter,dc=corp,dc=com" uri "ldap://1.1.1.1:389/" idassert-bind bindmethod=none ldap.conf URI ldap://127.0.0.1 BASE dc=internal,dc=com

9 years, 9 months

Re: slapd-meta and tls_reqcert=allow

by Jim Vanes

Thanks! I've looked for any ITS regarding this but failed to find anything. I'll try with a newer version. ________________________________ From: Manuel Gaupp <mgaupp(a)googlemail.com> To: Jim Vanes <jimvanes(a)yahoo.ca> Cc: OpenLDAP <openldap-technical(a)openldap.org> Sent: Friday, February 1, 2013 5:59:42 AM Subject: Re: slapd-meta and tls_reqcert=allow Jim Vanes <jimvanes(a)yahoo.ca> wrote: > I'm using OpenLDAP 2.4.23-26 from Centos 6. I seem to be hitting a configuration issue regarding slapd-meta and SSL/TLS. > > Here is my meta config: > > database meta > suffix "dc=virtual,dc=local" > rootdn "cn=root,dc=virtual,dc=local" > rootpw password > > # Local > uri ldap://localhost/dc=ds1,dc=virtual,dc=local > suffixmassage "dc=ds1,dc=virtual,dc=local" "dc=lab,dc=local" > idassert-bind bindmethod=simple binddn="cn=root,dc=lab,dc=local" credentials=password > > #Remote AD server > uri ldap://10.33.63.125:389/dc=ad1,dc=virtual,dc=local > tls start > suffixmassage "dc=ad1,dc=virtual,dc=local" "dc=mslab,dc=local" > idassert-bind bindmethod=simple binddn="CN=Sync,CN=Users,DC=lab,DC=local" credentials="Password1" starttls="yes" tls_reqcert="allow" > > It seems as though tls_reqcert="allow" is ignored for the remote AD server. If set that variable in the ldap.conf everything works fine. But shouldn't the above function as an override to the default of 'demand'? The behaviour is the same when I change the above to use SSL instead. I think you're running into an issue that I reported in September 2010. See http://www.openldap.org/lists/openldap-technical/201009/msg00073.html and http://www.openldap.org/its/index.cgi?findid=6642 According to the Release Change Log, this issue should have been fixed in release 2.4.24. So you should definitely update to a more recent release. Best regards, Manuel

12 years, 4 months

RE: openldap and MozNSS

by Rodney Simioni

-----Original Message----- From: openldap-technical-bounces(a)OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Quanah Gibson-Mount Sent: Tuesday, June 25, 2013 2:05 PM To: Rodney Simioni; openldap-technical(a)openldap.org Subject: RE: openldap and MozNSS --On Tuesday, June 25, 2013 2:01 PM -0400 Rodney Simioni <rodney.simioni(a)verio.net> wrote: > > Comment below. > -----Original Message----- > From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] > Sent: Tuesday, June 25, 2013 12:27 PM > To: Rodney Simioni; openldap-technical(a)openldap.org > Subject: RE: openldap and MozNSS > > --On Tuesday, June 25, 2013 11:40 AM -0400 Rodney Simioni > <rodney.simioni(a)verio.net> wrote: > >> I'm getting further, I went to http://ltb-project.org and downloaded >> a newer version of openldap. BTW, thank you, it's a nice site. >> >> But when I do a 'ldapsearch -d -1 -x -LLL -ZZ', I'm getting " >> unsupported extended operation" >> >> Does anybody have a clue? > > I would advise you to specifically use -H <URI> so it is clear what > you are connecting to and how. For example, -ZZ requests startTLS, > but if you are using an ldaps:// URI, that makes no sense, because > they are mutually exclusive. [[Rod's comment]] I'm using '-H', I'm > still getting 'unsupported extended operation', but thanks. My point was, show an EXACT ldapsearch command where it is not pulling in crap from a local or system ".ldaprc" or "ldap.conf" file. Until you do that, god knows what those files are setting. [[Rod's comment]] Thank you, good advice. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio Inc. makes no warranty that this email is error or virus free. Thank you.

11 years, 11 months

Re: Bug ? ldap_start_tls_s successful even after removing ca certificate from ca cert dir

by SOMA SEKHAR

Hi , Please let me know if anyone observed this behaviour . On Sat, Aug 23, 2014 at 1:08 PM, SOMA SEKHAR <somasekhar44(a)gmail.com> wrote: > link to question on stackoverflow > <http://stackoverflow.com/questions/25457034/starttls-succesful-even-after-d…> > > > I'm having trouble verifying the correct behavior of my software. Here are > the steps I am performing to verify correct operation: > > 1. I have sample code that uses openldap library and doing a start tls > to a ldap server. > 2. I have set the global option for ca cert directory and tlx context > for the first time. > 3. After that I did ldap init and ldap start tls to a server. This is > succesful as expected. > 4. I did an ldap_unbind_s > 5. I deleted the CA cert that signed the ldap server's certificate > from the ca cert directory of the client. > 6. Again did ldap_init and ldap_start_tls_s . > 7. I expected this call to fail , as I have removed the ca cert. But > what I observe is that , server sends the certificate but start_tls is > returning success. > > I am using openldap 2.4 with libssl.0.9.8 > > LDAP *ld;int desired_version=3; > if ((ld = ldap_init(<hostname>, <server_port>)) == NULL ) { > printf("ldap_init failed\n"); > exit(0);} > > ldap_set_option(ld, LDAP_OPT_PROTOCOL_VERSION, &desired_version); > ldap_set_option(NULL, LDAP_OPT_X_TLS_CTX, NULL); > ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTDIR,"<ca dir>"); > if(ldap_start_tls_s(ld, NULL, NULL) != LDAP_SUCCESS){ > printf("start tls failed.\n"); > exit(0);} > ...... <do bind and search>... > > ldap_unbind_s(ld); ... > // DELETE the CA certificate from the ca dir. // Try to do start tls again > if ((ld = ldap_init(hostname, server_port)) == NULL ) { > printf("ldap_init failed , after deleting CA\n"); > exit(0);} > // This goes fine even after deleting the CAif (ldap_start_tls_s(ld, NULL, NULL) != LDAP_SUCCESS){ > printf("start tls failed after deleting CA.\n"); > exit(0);} > > > -- > Thanks&Regards, > SomaSekhar. > > -- Thanks&Regards, SomaSekhar.

10 years, 9 months

Re: Ppolicy issues

by Bryan Payne

Thank you for your help. I added the pwdPolicySubentry to a user to no avail. I did find this in the logfile though: Feb 20 09:01:13 ldapserver slapd[6709]: conn=95289 op=4 SEARCH RESULT tag=101 err=50 nentries=0 text=Operations are restricted to bind/unbind/abandon/StartTLS/modify password So it looks like it's trying to do something but cannot. While I'm concerned about password strength, I'm more concerned (at this point) with just having the machine prompt for a password change. I'm running centos 4.6 and openldap 2.3.39. I compiled it with the following: ./configure --enable-crypt --enable-ppolicy --with-tls --prefix=/opt/openldap/ Once again, thanks for any help. Bryan Payne skrev, on 19-02-2008 22:27: I have some issues with ppolicy. It seems it recognizes expiration dates (I know this from looking in the logs, but it does not warn the user their password is expiring soon), properly locks out accounts with too many failed logins but it cannot seem to force a password change when pwdReset is set to TRUE, nor does it prevent logins when the password has expired. Any help would be greatly appreciated. I'll post the things of importance below. Please let me know if anything else would help. [root@ldapserver ~]# ldapsearch -x -LLL cn=default dn: cn=default,ou=policies,dc=example,dc=com objectClass: top objectClass: device objectClass: pwdPolicy cn: default pwdAttribute: 2.5.4.35 pwdInHistory: 6 pwdCheckQuality: 1 pwdMinLength: 8 pwdMaxFailure: 4 pwdLockout: TRUE pwdFailureCountInterval: 0 pwdMustChange: TRUE pwdSafeModify: FALSE pwdLockoutDuration: 900 pwdExpireWarning: 432000 pwdGraceAuthNLimit: 1 pwdAllowUserChange: TRUE pwdMaxAge: 7776000 From slapd.conf overlay ppolicy ppolicy_default "cn=default,ou=policies,dc=example,dc=com" ppolicy_use_lockout Most of the above looks kosher; my main site is running ppolicy on OpenLDAP 2.3.33 up to 2.3.39 Buchan rpms on Red Hat RHEL5 and all the above work. However: 1: I've found that each posixAccount has to have the operational attribute pwdPolicySubentry. Although this is an operational attribute, it is (the only?) such that is user modifiable. In this (as in many other) respects gq is indispensable as GUI. 2: I've found that extensive use has to be made of pam_ldap to get the best out of ppolicy (for example password strength). 3: It would help if you detailed OS and OL versions, so's one could know whether to contribute help or not. Bets, --Tonni -- Tony Earnshaw Email: tonni at hetnet dot nl

17 years, 3 months

deltasync replication with 2.6 not working

by Stefan Kania

Hi to all, I still experimenting with openldap 2.6 and the deltasyncrepl with four hosts. I use debian 11 and the symas packages. I set up all four hosts with the following ldif-files. Starting with the basic settings: --------------------------------------- dn: cn=config objectClass: olcGlobal cn: config olcLogLevel: sync olcLogLevel: stats olcPidFile: /var/symas/run/slapd.pid olcArgsFile: /var/symas/run/slapd.args olcToolThreads: 1 # create cn=config #dn: olcBackend={0}mdb,cn=config #objectClass: olcBackendConfig #olcBackend: {0}mdb dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /opt/symas/lib/openldap olcModuleLoad: back_mdb olcModuleLoad: back_monitor olcModuleLoad: autoca.la olcModuleLoad: otp.la olcModuleLoad: argon2.la olcModuleLoad: syncprov olcModuleLoad: back_monitor olcModuleLoad: accesslog.la include: file:///opt/symas/etc/openldap/schema/core.ldif include: file:///opt/symas/etc/openldap/schema/cosine.ldif include: file:///opt/symas/etc/openldap/schema/nis.ldif include: file:///opt/symas/etc/openldap/schema/inetorgperson.ldif include: file:///opt/symas/etc/openldap/schema/dyngroup.ldif include: file:///opt/symas/etc/openldap/schema/kerberos.openldap.ldif dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcSizeLimit: 500 olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth manage by * break olcAccess: {1}to dn="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcPasswordHash: {ARGON2} dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootDN: cn=admin,cn=config olcRootPW: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cXdlcnJ0enV6dWlvMTIz$G/l0lynf7ygdz0tG+E7S1fBibsFs/L80AUSisiGl/v4 olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth manage by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write by * break dn: olcDatabase={1}monitor,cn=config objectClass: olcDatabaseConfig olcDatabase: {1}monitor olcAccess: {0}to dn.subtree="cn=monitor" by dn.exact=cn=admin,cn=config read by dn.exact=cn=admin,dc=example,dc=net read dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcmdbConfig olcDatabase: {2}mdb olcSuffix: dc=example,dc=net olcRootDN: cn=admin,dc=example,dc=net olcRootPW: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cXdlcnJ0enV6dWlvMTIz$G/l0lynf7ygdz0tG+E7S1fBibsFs/L80AUSisiGl/v4 olcSizeLimit: unlimited olcTimeLimit: unlimited olcDbCheckpoint: 512 30 olcDbDirectory: /var/symas/openldap-data olcDbIndex: default eq olcDbIndex: objectClass olcDbIndex: entryUUID olcDbIndex: entryCSN olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: mail pres,eq,sub olcDbIndex: sn pres,eq,sub olcDbIndex: description pres,eq,sub olcDbIndex: title pres,eq,sub olcDbIndex: givenName pres,eq,sub olcDbMaxSize: 85899345920 olcAccess: {0} to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth manage by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write by dn.exact=uid=repl-user,ou=users,dc=example,dc=net read by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcAccess: {3} to attrs=userPassword by anonymous auth by self write by * none olcLimits: {0} dn.exact="uid=repl-user,ou=users,dc=example,dc=net" time=unlimited size=unlimited olcLimits: {1} dn.exact="uid=ldap-admin,ou=users,dc=example,dc=net" time=unlimited size=unlimited --------------------------------------- After all four host have the same basic settings I change the "serverId" with the following LDIF-File. My problem is the same, even when I put the serverIds into the basic setup. The reason why I split the serverId from the basic settings is because I use Ansible to configure all hosts. ------------------------- dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 ldap://ldap01.example.net olcServerID: 2 ldap://ldap02.example.net olcServerID: 3 ldap://ldap03.example.net olcServerID: 4 ldap://ldap04.example.net ------------------------- The next step is setting up the deltasync replication with the following LDIf-file: ------------------------- dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 dn: olcDatabase={3}mdb,cn=config changetype: add objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {3}mdb olcDbDirectory: /var/symas/accesslog olcSuffix: cn=accesslog olcAccess: {0}to dn.subtree="cn=accesslog" by dn.exact="uid=repl-user,ou=users,dc={first_dc}},dc=net" read by dn.exact="cn=admin,dc=example,dc=net" read olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=config olcLimits: dn.exact="cn=uid=repl-user,dc=example,dc=net" time=unlimited size=unlimited olcSizeLimit: unlimited olcTimeLimit: unlimited olcMonitoring: TRUE olcDbCheckpoint: 0 0 olcDbIndex: entryCSN eq olcDbIndex: objectClass eq olcDbIndex: reqEnd eq olcDbIndex: reqResult eq olcDbIndex: reqStart eq olcDbIndex: reqDN eq olcDbMode: 0600 olcDbSearchStack: 16 olcDbMaxsize: 85899345920 dn: olcOverlay=syncprov,olcDatabase={3}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 200 dn: olcOverlay={1}accesslog,olcDatabase={2}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {1}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogSuccess: TRUE olcAccessLogPurge: 01+00:00 00+04:00 dn: olcDatabase={2}mdb,cn=config changetype: modify replace: olcSyncrepl olcSyncrepl: rid=102 provider=ldap://ldap02.example.net bindmethod=simple timeout=0 network-timeout=0 binddn=uid=repl-user,ou=users,dc=example,dc=net credentials=secret filter="(objectclass=*)" searchbase="dc=example,dc=net" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase=cn=accesslog scope=sub schemachecking=off type=refreshAndPersist retry="60 +" syncdata=accesslog keepalive=240:10:30 starttls=yes olcSyncrepl: rid=103 provider=ldap://ldap03.example.net bindmethod=simple timeout=0 network-timeout=0 binddn=uid=repl-user,ou=users,dc=example,dc=net credentials=secret filter="(objectclass=*)" searchbase="dc=example,dc=net" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase=cn=accesslog scope=sub schemachecking=off type=refreshAndPersist retry="60 +" syncdata=accesslog keepalive=240:10:30 starttls=yes olcSyncrepl: rid=104 provider=ldap://ldap04.example.net bindmethod=simple timeout=0 network-timeout=0 binddn=uid=repl-user,ou=users,dc=example,dc=net credentials=secret filter="(objectclass=*)" searchbase="dc=example,dc=net" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase=cn=accesslog scope=sub schemachecking=off type=refreshAndPersist retry="60 +" syncdata=accesslog keepalive=240:10:30 starttls=yes - replace: olcMirrorMode olcMirrorMode: TRUE ------------------------- The olcSyncrepl is different on each host this one is from ldap01.example.net so the host is not in the list. On each other host everything is setup the same. When in Start slapd I always getting this error messsages (on server ldap1: --------------------- ez 09 15:20:56 ldap01 slapd[2406]: conn=1035 fd=18 ACCEPT from IP=192.168.56.48:56760 (IP=0.0.0.0:389) Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 op=0 STARTTLS Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 op=0 RESULT oid= err=0 qtime=0.000024 etime=0.000299 text= Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 fd=18 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384 Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 op=1 BIND dn="uid=repl-user,ou=users,dc=example,dc=net" method=128 Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 op=1 BIND dn="uid=repl-user,ou=users,dc=example,dc=net" mech=SIMPLE bind_ssf=0 ssf=256 Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 op=1 RESULT tag=97 err=0 qtime=0.000033 etime=0.026849 text= Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior reqControls entryCSN Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 op=2 syncprov_op_search: got a persistent search with a cookie=rid=101,sid=004,csn=20211208190517.239632Z#000000#001#000000 Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 op=2 syncprov_findbase: searching Dez 09 15:20:56 ldap01 slapd[2406]: findbase failed! 32 Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 op=2 SEARCH RESULT tag=101 err=32 qtime=0.000019 etime=0.000166 nentries=0 text= Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 op=3 UNBIND Dez 09 15:20:56 ldap01 slapd[2406]: conn=1035 fd=18 closed --------------------- The rid 101 is NOT configured on this host, because it's ldap01 The same configuration is working on a Debian 10 with the openldpa-packages from debian. One more thing on debian 10 I see_ ---------------------- root@hm-01:~# ss -a | grep ldap | awk '{print$1 " " $2 " " $5 " " $6}' u_str LISTEN /var/run/slapd/ldapi 13381 tcp LISTEN 0.0.0.0:ldaps 0.0.0.0:* tcp LISTEN 0.0.0.0:ldap 0.0.0.0:* tcp ESTAB 192.168.56.41:ldap 192.168.56.44:35400 tcp ESTAB 192.168.56.41:ldap 192.168.56.42:57096 tcp ESTAB 192.168.56.41:ldap 192.168.56.43:54992 tcp ESTAB 192.168.56.41:33408 192.168.56.42:ldap tcp ESTAB 192.168.56.41:50268 192.168.56.43:ldap tcp LISTEN [::]:ldaps [::]:* tcp LISTEN [::]:ldap [::]:* ---------------------- What i expected because of "refreshAndPersist" on the Debian 11 host with the symas packages I see: --------------------- root@ldap01:~# ss -a | grep ldap | awk '{print$1 " " $2 " " $5 " " $6}' u_str LISTEN /var/symas/run/ldapi 14159 tcp LISTEN 0.0.0.0:ldaps 0.0.0.0:* tcp LISTEN 0.0.0.0:ldap 0.0.0.0:* tcp LISTEN [::]:ldaps [::]:* tcp LISTEN [::]:ldap [::]:* --------------------- So there is no permanent connection, that also shows the log. Error 32 means "no such object" but which object is missing. The accesslog DB files are there. The slapd is NOT running as rootI change all the permissions and settings to run slapd as unprivileged user. I'm lost :-) Stefan

3 years, 6 months

Dovecot can't connect to openldap over starttls

by info＠gwarband.de

Hello, can anybody say something about my problem? The mails in the bottom are from my discuss with the dovecot maillist. Thanks, Tobias -------- Originalnachricht -------- Betreff: Re: Dovecot can't connect to openldap over starttls Datum: 2017-03-18 14:22 Absender: info(a)gwarband.de Empfänger: Tomas Habarta <lists+dovecot(a)tocc.cz> Kopie: dovecot(a)dovecot.org The serverlog of openldap with loglevel "any": https://gwarband.de/openldap/openldap-connect.log Note: openldap waits 1 Minute before he says "TLS negotiation failure" after the connect. and dovecot says direct "Connect error" I've also delete the TLSCipherSuite from openldap. Tobias Am 2017-03-18 14:01, schrieb Tomas Habarta: > Increase log level on server side as well to see what the server > says... > You may remove anything in TLSCipherSuite for the purpose of testing > too. > Hopefully anyone knowing OpenLDAP internals could help you analyse it > more deeply. > Tomas > On 03/18/2017 01:31 PM, info(a)gwarband.de wrote: >> I've replicate the settings from ldapsearch to dovecot but no >> success. >> To the certificate: >> Yes it's a *.crt file but I have linked the *.pem file to it and >> dovecot >> has read access to that file. >> I have enabled the debugging in dovecot and have uploaded the output: >> https://gwarband.de/openldap/dovecot-connect.log >> And the other site with ldapsearch: >> https://gwarband.de/openldap/ldapsearch-connect.log >> I'm pretty sure that there is a problem with the sslhandshaking >> between >> openldap and dovecot, but I can't find the source of the problem. >> One of the steps in the sslhandshaking is not success but in the >> debugging output I can't find any line with a hit to it. >> Tobias >> Am 2017-03-18 12:30, schrieb Tomas Habarta: >>> Well, if ldapsearch works, try to replicate its settings for dovecot >>> client. >>> It's not obvious what settings ldapsearch uses, have a look at >>> default >>> client settings in /etc/openldap/ldap.conf, there may be something >>> set a >>> slightly different way. >>> Also double check permissions for files used by dovecot, I mean >>> mainly >>> the file listed for tls_ca_cert_file as dovecot may not have an >>> access >>> for reading... >>> I cannot see anything downright bad, just posted CA cert (which is >>> ok, >>> tested) is *.crt and your config mentions *.pem but I consider it's >>> the >>> same file. >>> Finally, I would recommend to enable debug option for dovecot's >>> client >>> debug_level = -1 (which logs all available) in your >>> dovecot-ldap.conf >>> to see what the library reports and work further on that. >>> You can compare with output from ldapsearch by adding -d-1 switch to >>> it. >>> Hard to tell more at the moment. >>> >>> Tomas >>> On 03/18/2017 09:41 AM, info(a)gwarband.de wrote: >>>> Hello, >>>> I have also installed LE certs. >>>> But nothing helps, I have double-checking all certs. >>>> ldapsearch with -ZZ works see: >>>> https://gwarband.de/openldap/ldapsearch.log >>>> I have also uploaded the TLSCACertificateFile, maybe I have a >>>> failure in >>>> the merge of the two fiels: >>>> https://gwarband.de/openldap/LetsEncrypt.crt >>>> And also I have uploaded my complete openldap configuration: >>>> https://gwarband.de/openldap/openldap.conf >>>> All other components can work and communicate with my openldap >>>> server. >>>> The components are postfix, openxchange, apache (phpldapadmin). >>>> My installated software is: >>>> Debian 8 >>>> OpenLDAP 2.4.40 >>>> Dovecot 2.2.13 >>>> I hope you can find the issue. >>>> Thanks, >>>> Tobias >>>> Am 2017-03-17 22:48, schrieb Tomas Habarta: >>>>> Hi, >>>>> been running Dovecot 2.2.27 against OpenLDAP 2.4.40 normally over >>>>> the >>>>> unix socket on the same machine, but tried over inet with STARTTLS >>>>> and >>>>> it's working ok... >>>>> I would suggest double-checking key/certs setup on OpenLDAP side; >>>>> for >>>>> the test I have used LE certs, utilizing following cn=config >>>>> attributes: >>>>> olcTLSCertificateKeyFile contains private key >>>>> olcTLSCertificateFile contains certificate >>>>> olcTLSCACertificateFile contains both certs (DST Root CA X3 >>>>> and Let's Encrypt Authority X3) >>>>> and used the same CA file in Dovecot's tls_ca_cert_file >>>>> Is ldapsearch working ok (-ZZ) and only Dovecot has troubles or >>>>> ... ? >>>>> >>>>> >>>>> Hope that helps, good luck ;) >>>>> Tomas >>>>> >>>>> On 03/17/2017 04:27 PM, info(a)gwarband.de wrote: >>>>>> Hello guys, >>>>>> actually I'm trying to configure dovecot to access openldap for >>>>>> passwordcheck. >>>>>> My openldap is only allow access over "secure ldap". >>>>>> The dovecot can communicate with the openldap server but there is >>>>>> maybe >>>>>> a failure in the sslhandshake. >>>>>> Additional information you can find in the logs or in the dump >>>>>> below. >>>>>> Also I have my ldap config from dovecot in the links below. >>>>>> I have already created an bug reporting in the system of openldap >>>>>> but >>>>>> the answer was to get support from her. >>>>>> All datalinks: >>>>>> https://gwarband.de/openldap/dovecot.log >>>>>> https://gwarband.de/openldap/dovecot-ldap.conf >>>>>> https://gwarband.de/openldap/openldap.log >>>>>> https://gwarband.de/openldap/trace.dump >>>>>> The bugreportinglink from openldap: >>>>>> http://www.openldap.org/its/index.cgi/Incoming?id=8615 >>>>>> I hope you can help me. >>>>>> Regards. >>>>>> Tobias Warband

8 years, 2 months

RE: problem with ldap backend

by Alex Samad - Yieldbroker

Hi Thanks, I have also tried bind=simple, same error, I have tested the dn and the password with ldapsearch Thanks > -----Original Message----- > From: masarati(a)aero.polimi.it [mailto:masarati@aero.polimi.it] > Sent: Sunday, 1 April 2012 6:17 PM > To: Alex Samad - Yieldbroker > Cc: 'openldap-technical(a)openldap.org' > Subject: RE: problem with ldap backend > > > Hi > > > > Just wondering if the features is supposed to work ? Am I delving > > into experimental code ? > > It works as intended. The error message you receive is quite > self-explanatory: AD wants a successful bind, and you're requesting > bindmethod=none (i.e. bind with empty DN). You may want to try > bindmethod=simple > > p. > > >> -----Original Message----- > >> From: Alex Samad - Yieldbroker > >> Sent: Thursday, 29 March 2012 9:28 AM > >> To: openldap-technical(a)openldap.org > >> Subject: RE: problem with ldap backend > >> > >> Hi > >> > >> I have progressed a little bit further > >> > >> I have stopped using olcdbaclbind and started to use > >> > >> olcDbIDAssertAuthzFrom: "*" > >> olcDbIDAssertBind: bindmethod=none authzId="CN=ad > >> readonly,OU=Services ,DC= xyz,DC=com" credentials="secret" > >> starttls=no > >> > >> > >> but I get this > >> > >> text: 000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform > >> this ope ration a successful bind must be completed on the > >> connection., data 0, > >> v1db1 > >> > >> > >> I am able to ldapsearch with these credentials, I also tried change > >> bindmethod to simple, but same error > >> > >> How do I turn on debug for the ldap backend ? > >> > >> Any one have any ideas on how to make this work ? > >> > >> > >> Alex > >> > >> > >> > -----Original Message----- > >> > From: openldap-technical-bounces(a)OpenLDAP.org > >> > [mailto:openldap-technical- bounces(a)OpenLDAP.org] On Behalf Of > Alex > >> > Samad - Yieldbroker > >> > Sent: Wednesday, 28 March 2012 1:58 PM > >> > To: openldap-technical(a)openldap.org > >> > Subject: problem with ldap backend > >> > > >> > Hi > >> > > >> > I am trying to setup a connection from openldap to MS AD > >> > > >> > I am using this > >> > > >> > dn: olcDatabase={3}ldap > >> > objectClass: olcDatabaseConfig > >> > objectClass: olcLDAPConfig > >> > olcDatabase: {3}ldap > >> > olcSuffix: dc=xyz,dc=com > >> > olcAccess: {0}to dn.base="" by * read > >> > olcAccess: {1}to dn.base="cn=Subschema" by * read > >> > olcAccess: {2}to * by self write by users read by anonymous auth > >> > olcReadOnly: TRUE > >> > olcRootDN: > >> gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > >> > olcSizeLimit: 500 > >> > olcDbURI: "ldap://dc101. xyz.com ldap://dc201. xyz.com" > >> > olcDbRebindAsUser: TRUE > >> > olcDbChaseReferrals: TRUE > >> > > >> > > >> > This works fine when I pass a bind DN. > >> > > >> > I would like to convert this to allow anon access to ldap, which > >> > does a user bind to MS AD so I added this > >> > > >> > > >> > olcdbaclbind: bindmethod=simple binddn="CN=ad readonly,OU= > xyz,DC= > >> > xyz,DC=com" credentials="secret" starttls=no > >> > > >> > but it is not working, I can not make a anon search request, they > >> > retrieve any thing frome the MSAD ldap server. > >> > > >> > Thanks > >> > > >> > > >> > > >> > > > > > > > > > >

13 years, 2 months

openldap-technical search results for query "starttls"