Search results for "starttls" - openldap-technical

Re: Syncrepl over TLS for mirrormode

by Daniel Qian

Our clients are mainly nss_ldap connecting with starttls so looks like our best bet is either wildcard cert or SubjectAltName. SubjectAltName seems a bit more complicated to do, as in openssl I will have to edit the openssl.cnf file and add all the hostnames and recreate the CSR. We use a local CA here for signing all the certificates used in protected communications. Thanks, Daniel On 11-08-27 3:45 PM, Marco Schirrmeister wrote: > To avoid all this name problems and to keep things simple I use a > wildcard certificate. > > This cert is also used on the real servers and on the load balancer. > > The clients talk only the a load balancer. Where I have 2 ip > addresses. One for ldapwrite.domain.com <http://ldapwrite.domain.com> > and one for ldapread.domain.com <http://ldapread.domain.com> > The load balancer terminates the ssl connection for port 636 and > creates a new session to the backend server. > > The reason that I have also the wildcard cert also on the backend > servers is for secure connections over 389. > The load balancer doesn't speak the ldap protocol, so if a client is > doing a starttls he would get the cert from the real server. > > If 389 is not needed, then I think 1 or 2 certs on a load balancer > would be enough. > The replication works also with self-signed certs if configured correctly. > > > -- > Marco > > > > On Aug 26, 2011, at 10:35 PM, Daniel Qian wrote: > >> Still not sure how you did it. Are you saying you set the same >> certificate in slapd and played with DNS to make it look like only >> one server(URL) to everyone? >> >> Thanks, >> Daniel >> >> On 11-08-26 4:03 PM, Chris Jacobs wrote: >>> What I did: >>> * setup servers behind VIP >>> * obtain cert with primary name of vip DNS w/ secondary names of the >>> servers. >>> >>> That way, the servers can sync/tryst each other via the same cert >>> used by clients. >>> >>> Note: some clients (lookin at you Firefox) won't use the primary >>> name if subjectaltname exists - so include primary name in the alt >>> names JIC. >>> >>> - chris >>> >>> Chris Jacobs, Systems Administrator, Technology Services Group >>> Apollo Group | Apollo Marketing and Product Development� |� >>> Aptimus, Inc. >>> 2001 6th Ave� |� Suite 3200� |� Seattle, WA 98121 >>> direct 206.839.8245� |� cell 206.601.3256� |� fax 206.839.8106 >>> email chris.jacobs(a)apollogrp.edu >>> >>> ------------------------------------------------------------------------ >>> *From*: openldap-technical-bounces(a)OpenLDAP.org >>> <openldap-technical-bounces(a)OpenLDAP.org> >>> *To*: openldap-technical(a)openldap.org <openldap-technical(a)openldap.org> >>> *Sent*: Fri Aug 26 12:49:04 2011 >>> *Subject*: Syncrepl over TLS for mirrormode >>> >>> From the openldap website the two nodes have to use different URLs >>> like below: >>> >>> syncrepl rid=001 >>> provider=ldap://ldap-sid2.example.com >>> bindmethod=simple >>> binddn="cn=mirrormode,dc=example,dc=com" >>> credentials=mirrormode >>> searchbase="dc=example,dc=com" >>> schemachecking=on >>> type=refreshAndPersist >>> retry="60 +" >>> and >>> syncrepl rid=001 >>> provider=ldap://ldap-sid1.example.com >>> bindmethod=simple >>> binddn="cn=mirrormode,dc=example,dc=com" >>> credentials=mirrormode >>> searchbase="dc=example,dc=com" >>> schemachecking=on >>> type=refreshAndPersist >>> retry="60 +" >>> >>> I can set two different certificates so that TLS is fine for sync >>> between the two nodes. However we will have regular Ldap client >>> access these two nodes behind a loadbalancer over TLS too. Obviously >>> the client can't connect with ldap-sid2.example.com >>> <http://ldap-sid2.example.com>, nor with ldap-sid1.example.com >>> <http://ldap-sid1.example.com>. So what is the solution to this >>> scenario? Setup a pool of consumers with same hostname? >>> >>> Thanks, >>> Daniel >>> >>> ------------------------------------------------------------------------ >>> This message is private and confidential. If you have received it in >>> error, please notify the sender and remove it from your system. >>> >> >

13 years, 9 months

data import very slow for data migration

by anil beniwal

Hi We are having 4 million users to migrate, all data exported from oracle to multiple ldif files. Imported 1 million till now, took almost 28 hours. and openldap-data dir of about 28G. openldap version 2.4.33 bdb version 5.1.29 RHEL 6.3 RAM 8G 4 cpu , system is a VM. Currently running slapadd output + /apps/openldap/sbin/slapadd -q -c -w -f /apps/openldap/etc/openldap/slapd.conf -l /root/User9.ldif bdb_monitor_db_open: monitoring disabled; configure monitor database to enable . 2.27% eta 21h31m elapsed 29m57s spd 1.6 k/s str2entry: invalid value for attributeType postalAddress #0 (syntax 1.3.6.1.4.1.1466.115.121.1.41) slapadd: could not parse entry (line=394416) * 2.81% eta 19h59m elapsed 34m40s spd 10.1 k/s Its seems to be taking weeks go import whole data. is there any tool or any other approach which we can use to make it fast,Or we are going with wrong configuration. Or we have to switch to ODS or RHDS Top output top - 10:26:04 up 21 days, 6:51, 3 users, load average: 2.13, 2.06, 1.79 Tasks: 153 total, 2 running, 151 sleeping, 0 stopped, 0 zombie Cpu0 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 3.0%us, 0.3%sy, 0.0%ni, 0.0%id, 96.6%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 9095980k total, 8956852k used, 139128k free, 31452k buffers Swap: 6291448k total, 21300k used, 6270148k free, 7431012k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27877 ldap 20 0 4855m 539m 284m S 99.8 6.1 1807:28 slapd 21130 root 20 0 5267m 3.8g 3.0g R 4.3 43.6 0:59.27 slapadd DB_CONFIG set_cachesize 0 4294967295 0 set_lg_regionmax 2048576 set_lg_max 20485760 set_lg_bsize 2097152 set_lk_max_locks 10000 set_lk_max_objects 5000 set_lk_max_lockers 5000 slapd.conf include /apps/openldap/etc/openldap/schema/core.schema include /apps/openldap/etc/openldap/schema/cosine.schema include /apps/openldap/etc/openldap/schema/nis.schema include /apps/openldap/etc/openldap/schema/inetorgperson.schema include /apps/openldap/etc/openldap/schema/openldap.schema include /apps/openldap/etc/openldap/schema/dyngroup.schema include /apps/openldap/etc/openldap/schema/ppolicy.schema include /apps/openldap/etc/openldap/schema/channelIdentifier.schema include /apps/openldap/etc/openldap/schema/platform.schema include /apps/openldap/etc/openldap/schema/extendedProfileKey.schema include /apps/openldap/etc/openldap/schema/extendedProfileValue.schema include /apps/openldap/etc/openldap/schema/behaviorKey.schema include /apps/openldap/etc/openldap/schema/behaviorValue.schema include /apps/openldap/etc/openldap/schema/questionAnswer.schema include /apps/openldap/etc/openldap/schema/extendedTop.schema include /apps/openldap/etc/openldap/schema/counter.schema pidfile /apps/openldap/var/run/slapd.pid argsfile /apps/openldap/var/run/slapd.args logfile /apps/logs/ldap loglevel 16640 database bdb suffix "dc=example,dc=com" access to attrs=userPassword by self write by anonymous auth by * break access to * by group/groupOfUniqueNames/uniqueMember.exact="cn=VWrite,ou=businessUsersGroup,dc=example,dc=com" manage by group/groupOfUniqueNames/uniqueMember.exact="cn=VRead,ou=businessUsersGroup,dc=example,dc=com" read by * break access to * by self write by anonymous auth by * read rootdn "cn=Manager,dc=example,dc=com" rootpw {SSHA}dXDFSQeFjSofJ3TAzYf8DrDSYWY ################## SSL ########################################## # TLSCipherSuite HIGH:MEDIUM:+SSLv3 TLSCACertificateFile /apps/openldap/etc/openldap/cacerts/cacert.pem TLSCertificateFile /apps/openldap/etc/openldap/cacerts/dam01.crt TLSCertificateKeyFile /apps/openldap/etc/openldap/cacerts/dam01.key # #################################################################### ####ache Entries ##### cachesize 900000 #idlcachesize 900000 lastmod on checkpoint 128 15 concurrency 100 index entryCSN eq index entryUUID eq index mail,uid,postalCode,smail,channelType,channelValue,answer,behavName,objectclass,tokenID,type eq index givenName,sn,city,question,behavValue,cn,extName sub index displayName approx # Replication Configuration overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 serverid 1 syncrepl rid=111 provider=ldap://s01.com binddn="cn=Manager,dc=example,dc=com" bindmethod=simple starttls=yes tls_reqcert=allow schemachecking=off credentials=G00gle# searchbase="dc=example,dc=com" type=refreshAndPersist retry="5 5 300 +" interval=00:00:00:10 syncrepl rid=222 provider=ldap://m04.com binddn="cn=Manager,dc=example,dc=com" bindmethod=simple starttls=yes tls_reqcert=allow schemachecking=off credentials=G00gle# searchbase="dc=example,dc=com" type=refreshAndPersist retry="5 5 300 +" interval=00:00:00:10 ###### mirrormode TRUE directory /apps/openldap/var/openldap-data overlay unique unique_attributes mail overlay ppolicy ppolicy_default "cn=default,ou=pwdPolicy,dc=example,dc=com" ppolicy_use_lockout -- Please let me know in case you need further details. Thanks&Regards Anil Beniwal +919891695048

12 years, 5 months

Re: proxy ldap (back_ldap) with group ACL? [SOLVED]

by brent s.

On 2/7/20 19:42, brent s. wrote: > Hey, all! (SNIP) > > I get the error: > > > > Feb 08 00:32:19 foo slapd[17600]: => acl_mask: access to entry > "ou=groupname,dc=domain,dc=com", attr "entry" requested > Feb 08 00:32:19 foo slapd[17600]: => acl_mask: to all values by > "cn=username,dc=domain,dc=net", (=0) > Feb 08 00:32:19 foo slapd[17600]: <= check a_group_pat: > cn=groupadmins,ou=groups,dc=domain,dc=net > Feb 08 00:32:19 foo slapd[17600]: =>ldap_back_getconn: conn > 0x7f7700009ef0 fetched refcnt=1. > Feb 08 00:32:19 foo slapd[17600]: Error: ldap_back_is_proxy_authz > returned 0, misconfigured URI? (SNIP) > I'm fairly certain this is PEBKAC, but I'm unclear what's going on. Do I > need to reference the group in the ACL explicitly with the LDAP URI > prefixed or something? > Update: this was indeed a PEBKAC. I'm not sure which exactly caused it, but it is now working after: 1.) I added an appropriate TLS_CACERT to /etc/openldap/ldap.conf (is this redundant with OLC? See #2 below) on the proxy and the target server. 2.) I changed cn=config?olcTLSCACertificateFile to match the value of #1 on the proxy and target server. 3.) The olcDatabase={3}ldap,cn=config entry now reads as such: dn: olcDatabase={3}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {3}ldap olcDbIDAssertBind: bindmethod=simple binddn="cn=proxyUser,dc=domain,dc=net" credentials=somePasswordHere starttls=critical tls_protocol_min=1.2 olcDbProtocolVersion: 3 olcDbProxyWhoAmI: TRUE olcDbRebindAsUser: TRUE olcDbSessionTrackingRequest: TRUE olcDbStartTLS: propagate olcDbURI: ldap://bar.domain.tld olcReadOnly: TRUE olcSuffix: dc=domain,dc=net I can now both auth successfully as a bind DN located on dc=domain,dc=net to dc=domain,dc=com AND use group-based ACL rules on dc=domain,dc=com based on groups found on dc=domain,dc=net (after appropriate ACL rules for reading those groups' membership were created on dc=domain,dc=net for cn=proxyUser,dc=domain,dc=net). Sorry for the noise! -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info

5 years, 4 months

RE: TLS replication/SALS bindmethod

by Darouichi, Aziz

If I moved either entries service fails to start. -----Original Message----- From: Michael Ströder [mailto:michael@stroeder.com] Sent: Monday, May 23, 2011 10:15 AM To: Darouichi, Aziz Cc: openldap-technical(a)openldap.org Subject: Re: TLS replication/SALS bindmethod Darouichi, Aziz wrote: > 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 +" I don't understand why you use bindmethod=sasl saslmech=external and binddn="cn=ldap,dc=establishment,dc=edu" credentials={SSHA}2vNffW+5hEolqIykgH9tCpxq9jTTVSSu together. Anyway you have to provide the clear-text password here since the consumer is a LDAP client. > 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 This basically means that TLS is not properly configured at the provider. Ciao, Michael.

14 years

Re: Syncrepl can't start ssl session because of refused 'client' certificate

by Quanah Gibson-Mount

--On Monday, July 11, 2011 6:44 PM +0200 Thibault Le Meur <Thibault.LeMeur(a)supelec.fr> wrote: > Le 11/07/2011 18:29, Rich Megginson a écrit : >> I think what is happening is that the syncrepl crypto context is >> "inheriting" from the main server crypto context. > Yes, this looks like this. > >> You want it to "inherit" the CA certificate from the main crypto >> context but not the server certificate. > > Not necessarily. When linked to openssl, openldap used to use the > /etc/openldap/ldap.conf file to read the client-side SSL configuration. > >> Please open an ITS for this. I'll have to figure out how this was >> working in openssl. > Done: ITS#6994 Actually syncrepl has its own configuration now for SSL/TLS. olcSyncrepl: rid=<replica ID> provider=ldap[s]://<hostname>[:port] searchbase=<base DN> [type=refreshOnly|refreshAndPersist] [interval=dd:hh:mm:ss] [retry=[<retry interval> <# of retries>]+] [filter=<filter str>] [scope=sub|one|base|subord] [attrs=<attr list>] [exattrs=<attr list>] [attrsonly] [sizelimit=<limit>] [timelimit=<limit>] [schemachecking=on|off] [network-timeout=<seconds>] [timeout=<seconds>] [bindmethod=simple|sasl] [binddn=<dn>] [saslmech=<mech>] [authcid=<identity>] [authzid=<identity>] [credentials=<passwd>] [realm=<realm>] [secprops=<properties>] [keepalive=<idle>:<probes>:<interval>] [starttls=yes|critical] [tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>] [tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand] [tls_ciphersuite=<ciphers>] [tls_crlcheck=none|peer|all] [suffixmassage=<real DN>] [logbase=<base DN>] [logfilter=<filter str>] [syncdata=default|accesslog|changelog] Note the tls_cacertdir, etc., options. --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

13 years, 11 months

syncrepl mirrormode with SSL/TLS issues

by Houston Ray

I am attempting to move my sycrepl with mirrormode configuration over to TLS using LDAPS (not starttls) and running into problems. Multimaster setup (2 servers) behind a VIP both RHEL 6.3 Openldap 2.4.23-26 still running the old slapd.conf method (apologies) There are 3 separate certificates ldap.mycompany.net, server01.mycompany.net, and server02.mycompany.net The primary certificate is used for running slapd, and the individual server certs are intended to allow syncrepl over ssl. My configurations for syncrepl/mirrormode are down below. I had success with non-ssl syncrepl/mirrormode. It worked great actually. Now I am attempting to get syncrepl/mirrormode working with SSL. What I observe is whichever slapd instance is the last to startup is the one that becomes a "Master" as if I was in a producer/consumer setup. Errors I am seeing are slapd[11995]: conn=1003 fd=13 ACCEPT from IP=<server1_IP>:56368 (IP= 0.0.0.0:636) slapd[11995]: connection_read(13): TLS accept failure error=-1 id=1003, closing slapd[11485]: slap_client_connect: URI=ldaps://server01.mycompany.netDN="cn=Admin,dc=mycompany,dc=net" ldap_sasl_bind_s failed (-1) slapd[11485]: do_syncrepl: rid=001 rc -1 retrying Server 1 configuration ************************* # Server1 synchronization settings serverID 1 syncrepl rid=002 provider=ldaps://server02.mycompany.net binddn="cn=Admin,dc=mycompany,dc=net" bindmethod=simple credentials=secret tls_cert=/etc/openldap/certs/server02.mycompany.net.pem tls_cacert=/etc/openldap/certs/Verisignbundle.crt tls_key=/etc/openldap/certs/server02.mycompany.net.key tls_reqcert=allow searchbase="dc=mycompany,dc=net" type=refreshAndPersist retry="5 5 300 +" timelimit=5 attrs="*,+" interval=00:00:05:00 schemachecking=off mirrormode on # Server1 synchronization overlay overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 # Server1 end ************************************************************************************************** Server 2 configuration ********************************* # Server2 syncronization settings serverID 2 syncrepl rid=001 provider=ldaps://server01.mycompany.net binddn="cn=Admin,dc=mycompany,dc=net" bindmethod=simple credentials=secret tls_cert=/etc/openldap/certs/server01.mycompany.net.pem tls_cacert=/etc/openldap/certs/Verisignbundle.crt tls_key=/etc/openldap/certs/server01.mycompany.net.key tls_reqcert=allow searchbase="dc=mycompany,dc=net" type=refreshAndPersist retry="5 5 300 +" timelimit=5 attrs="*,+" interval=00:00:05:00 schemachecking=off mirrormode on # Server02 synchronization overlay overlay syncprov syncprov-checkpoint 100 10 # Server2 end ************************************************************************************************** any help is greatly appreciated

12 years, 5 months

Re: OpenLDAP syncrepl over SSL

by Patrick Lists

On 07/31/2013 12:36 PM, Tony Davis wrote: > Hi, > > I wonder if anyone can help me with a question I have regarding an > openldap setup on Redhat / Centos 5.8 using openldap-2.3.43. > > I am trying to setup replication, I have set this up using the simple > bind method, which stores a password for the replication in the config. > (This works) but I wondered if there was a way to have this replication > take place using ssl certificates without the need to store the unhashed > password in the slapd.conf? Is this possible? or do I still have to > specify a replication user and pass, but all the auth takes place over ssl? > > This is my current config for replication: > > syncrepl rid=001 > provider=ldap://master01.tld > type=refreshAndPersist > interval=00:00:05:00 > retry="5 5 300 +" > searchbase="dc=tld" > attrs="*,+" > bindmethod=sasl > saslmech=EXTERNAL > tls_cert=/etc/master02.tld.pem > tls_key=/etc/master02.tld.key > tls_cacert=/etc/openldap/cacerts/ca.pem > tls_reqcert=demand > starttls=yes > > mirrormode on > updateref ldap://master01.tld > > > but in the replication log i get the following: > > Jul 31 11:06:18 master02 slapd[6958]: do_syncrep1: rid 001 > ldap_sasl_interactive_bind_s failed (7) > Jul 31 11:06:18 master02 slapd[6958]: do_syncrepl: rid 001 retrying > (3 retries left) > Jul 31 11:06:18 master02 slapd[6958]: daemon: activity on 1 descriptor > Jul 31 11:06:18 master02 slapd[6958]: daemon: activity on: I'm struggling with a similar problem (see message "N-Way Multi-Master TLS problem" from a few hours ago) so I'm afraid I don't have an answer for you. This FAQ entry might help: http://www.openldap.org/faq/data/cache/1504.html One tip: usually the developers/experienced folks on this list will advise you to upgrade your OpenLDAP version to the latest version using packages available from http://ltb-project.org or build the latest OpenLDAP from source against OpenSSL (not gnuTLS). Between 2.3.43 and the latest 2.4.35 version many syncrepl bugs have been fixed so maybe start with that. If you find a solution I would appreciate it if you could update the thread. It might provide a pointer how to solve my problem. Regards, Patrick

11 years, 10 months

Re: ssf Security Question

by William Brown

On Tue, 2017-11-14 at 20:56 +0000, Kaya Saman wrote: > Hi, > > > I am a little confused with this. Basically I have a client > connecting > to the database, a DECT IP phone base station which doesn't support > STARTLS and my slapd config has settings for clients to use > certificates > to connect. > > > What would be the best way to set this up so that the DECT IP client > only accesses the particular place that it needs to, the AddressBook > section but then other clients will need to use STARTTLS for > everything > else?? > > > Currently I am looking at: > > https://www.openldap.org/doc/admin24/security.html > > > https://www.openldap.org/doc/admin24/access-control.html > > > and have currently put this in my slapd.conf: > > > #Removed the Global? security clause > > #security ssf=128 > > > #Added generic ACL for all access to require ssf of 128 > > access to * > by ssf=128 self write > by ssf=128 anonymous auth > by ssf=128 users read > > > #Added ACL for open access to AddressBook in Read and Search only > mode > > access to dn.children="ou=AddressBook,dc=domain,dc=com" > by * search > by * read > > > Is this correct or do I need to engage the "security" Global section > too? > > > Though the documentation suggests otherwise: "For fine-grained > control, > SSFs may be used in access controls. See theAccess Control > <https://www.openldap.org/doc/admin24/access-control.html>section > for > more information." > > Hey mate, Just want to point out there are some security risks with ssf settings. I have documented these here: https://fy.blackhats.net.au/blog/html/2016/11/23/the_minssf_trap.html This is a flaw in the ldap protocol and can never be resolved without breaking the standard. The issue is that by the time the ssf check is done, you have already cleartexted sensitive material. I would advise that you use LDAPS with TLS instead, or provide suitable access control over your network segments to prevent these issues. Relying on SSF can allow data leaks from misconfigured clients. Hope that helps, -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane

7 years, 6 months

Re: Strange TLS issue while upgrading from openldap 2.3 to 2.4

by Guillaume Rousse

Le 28/06/2012 01:41, Quanah Gibson-Mount a écrit : > --On Wednesday, June 27, 2012 3:31 PM +0200 Guillaume Rousse > <guillomovitch(a)gmail.com> wrote: > >> Sorry, I'm not a Zimbra admin, and I may have been confusing in my >> explanations. The problem occurs with Zimbra acting as an LDAP client >> against an external LDAP server, performing a bind operation for >> authenticating users, with the following behaviour: >> >> Zimbra against on openldap 2.3.x server, with TLS on port 389: OK >> Zimbra against on openldap 2.4.x server, on port 636: OK >> Zimbra against on openldap 2.4.x server, with TLS on port 389: 30s delay > > Ok, so what you are saying is: > > You upgraded your OS to CentOS6 > > You use external auth > > The external auth from CentOS6 to your own LDAP server shows a 30 second > delay on closing. Almost :) I upgraded the OS of the machine running the LDAP server, the zimbra server didn't change. So, that's the external auth from a RHEL 5.8 system running Zimbra 7, against a Centos 6.2 system running OpenLDAP 2.4.24. > That sounds like a bug in Java/JNDI. I did see some 30 second issues > with RHEL6, but it was with initiating a connection, not closing it. Indeed. I don't see why either the ldap server or the ldap client would need to perform any DNS query once the connection has been accepted, and the TLS negociation was successful. > You can see more about that at > <https://stomp.colorado.edu/blog/blog/2011/06/29/on-rhel-6-ssh-dns-firewalls…> > > > I would note that JNDI behavior varies based on startTLS vs SSL on port > 636 as well. Interesting. We tried the workaround, on both side (openldap server, then zimbra server), without any behaviour change. The only thing I'm unsure, tough, is about the moment where a change in resolver configuration has an effect. As the resolver is technicaly a part of the glibc, and can never get reloaded, I guess it uses the file timestamp to detect file modification and reload it immediatly. Also, I'll try to find some other example of java-based applications acting as LDAP client, in our environement -- BOFH excuse #443: Zombie processes detected, machine is haunted.

12 years, 11 months

syncrepl with accesslog not replicating

by Dieter Klünter

Hi, I am facing a problem with OpenLDAP-2.4.23. That is I am trying to setup a delta replication based on accesslog. Although the accesslog database contains new entries and the log database is successfully read, no replication ever takes place, while a setup without accesslog replicates successfully. An excerpt from the systemlogs: slapd[19170]: conn=1050 fd=20 ACCEPT from IP=192.168.0.8:41487 (IP=0.0.0.0:389) slapd[19170]: conn=1050 op=0 EXT oid=1.3.6.1.4.1.1466.20037 slapd[19170]: conn=1050 op=0 STARTTLS slapd[19170]: conn=1050 op=0 RESULT oid= err=0 text= slapd[19170]: conn=1050 fd=20 TLS established tls_ssf=256 ssf=256 slapd[19170]: conn=1050 op=1 BIND dn="" method=163 slapd[19170]: conn=1050 op=1 BIND authcid="cn=replicator,o=avci,c=de" authzid="cn=replicator,o=avci,c=de" slapd[19170]: conn=1050 op=1 BIND dn="cn=replicator,o=avci,c=de" mech=EXTERNAL sasl_ssf=0 ssf=256 slapd[19170]: conn=1050 op=1 RESULT tag=97 err=0 text= slapd[19170]: conn=1050 op=2 SRCH base="cn=log" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" slapd[19170]: conn=1050 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN slapd[19170]: conn=1050 op=2 SEARCH RESULT tag=101 err=0 nentries=7 text= slapd[19170]: conn=1050 op=3 UNBIND slapd[19170]: conn=1050 fd=20 closed A ldapsearch -Y EXTERNAL -ZZ -H ldap://localhost -b cn=log -s one "(&(objectClass=auditWriteObject)(reqResult=0))" provides the expected results, an example # 20101129144212.000003Z, log dn: reqStart=20101129144212.000003Z,cn=log objectClass: auditModify reqStart: 20101129144212.000003Z reqEnd: 20101129144212.000004Z reqType: modify reqSession: 1007 reqAuthzID: cn=admanager,o=avci,c=de reqControls: {0}{2.16.840.1.113730.3.4.18 controlValue "646O3K636O3N61646N616O 616765722M6P3N617663692M633N6465"} reqDN:: Y249U2Now6RmZXIgV29sZmdhbmcsb3U9YWRyZXNzYnVjaCxvPWF2Y2ksYz1kZQ== reqResult: 0 reqMod: sn:- Wolfgang reqMod: sn:+ Schaefer reqMod: entryCSN:= 20101129144212.353910Z#000000#000#000000 reqMod: modifiersName:= cn=admanager,o=avci,c=de reqMod: modifyTimestamp:= 20101129144212Z The relevant config files can be found here: Provider slapd.conf: http://pastebin.de/12273 Consumer slapd.conf: http://pastebin.de/12275 -Dieter -- Dieter Kl�nter | Systemberatung sip: 7770535(a)sipgate.de http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6

14 years, 6 months

openldap-technical search results for query "starttls"