Search results for "starttls" - openldap-technical

AW: syncrepl connection / reconnect

by Thorsten Mueller

Here you are, the config of the second machine is identical, apart from the different provider ####################################################################### # # Global settings # ####################################################################### pidfile /var/run/slapd.pid argsfile /var/run/slapd.args ucdata-path /usr/ucdata serverID 1 moduleload syncprov ################################### # Useful settings for enabling LDAPS (i.e. LDAP over SSL/TLS) access to this server ################################### TLSCACertificateFile /etc/TLS/ca-certs/trusted_CAs.pem TLSCACertificatePath /etc/TLS/links TLSCertificateFile /etc/TLS/server/server.pem TLSCertificateKeyFile /etc/TLS/server/server_key.pem TLSCipherSuite HIGH:MEDIUM:SSLv3 TLSVerifyClient try ################################### # Public LDAP schemas ################################### include /etc/schema/core.schema include /etc/schema/cosine.schema include /etc/schema/inetorgperson.schema ################################### # Gateway specific LDAP schemas ################################### include /etc/schema/database.schema loglevel 256 ################################### # Access control ################################### access to attrs=userPassword by anonymous auth by * none access to dn.subtree="dc=SpecialBranch,dc=head" by dn.base="cn=SpecialBranchUser,dc=SpecialBranch,dc=head" write by dn.base="cn=Replicator,dc=DatabaseReplication,dc=head" write by * none access to * by dn.base="cn=Replicator,dc=DatabaseReplication,dc=head" write by * none access to * by * none ####################################################################### # # Database definitions # ####################################################################### ################################### # Database for SpecialBranch ################################### database bdb suffix "dc=SpecialBranch,dc=head" subordinate rootdn "cn=admin,dc=head" directory /var/db-SpecialBranch monitoring off index objectClass eq index entryCSN eq index entryUUID eq index contextCSN eq index DatabaseAttrRuleID eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 # syncrepl directiv syncrepl rid=001 provider=ldap://192.168.120.237:388 bindmethod=simple binddn="cn=Replicator,dc=DatabaseReplication,dc=head" credentials="fdet2zS3" searchbase="dc=SpecialBranch,dc=head" starttls=critical tls_cacert=/etc/TLS/ca-certs/trusted_CAs.pem tls_cert=etc/TLS/client/client.pem tls_key=etc/TLS/client/client_key.pem schemachecking=on type=refreshAndPersist retry="5 12 60 +" mirrormode on ################################### # Database for the general configuration ################################### database bdb suffix "dc=head" rootdn "cn=admin,dc=head" rootpw "{SSHA}fO7A1sCrZzhy2IpNCvoVrQ9oRFpFY8Uj" directory /var/db-general monitoring off index objectClass eq index entryCSN eq index entryUUID eq index contextCSN eq index mail eq,sub index DatabaseAttrIssuerDN eq,sub index DatabaseAttrSubjectDN eq,sub index DatabaseAttrSerial eq index DatabaseAttrFingerprint eq,sub index DatabaseAttrKeyID eq,sub index DatabaseAttrKeySigner pres index DatabaseAttrKeyHash eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 # syncrepl directiv syncrepl rid=001 provider=ldap://192.168.120.237:388 bindmethod=simple binddn="cn=Replicator,dc=DatabaseReplication,dc=head" credentials="fdet2zS3" searchbase="dc=head" starttls=critical tls_cacert=/etc/TLS/ca-certs/trusted_CAs.pem tls_cert=etc/TLS/client/client.pem tls_key=etc/TLS/client/client_key.pem schemachecking=on type=refreshAndPersist retry="5 12 60 +" mirrormode on #eof Von: Benjamin Griese [mailto:der.darude@gmail.com] Gesendet: Freitag, 26. März 2010 10:05 An: Thorsten Mueller Cc: openldap-technical(a)openldap.org Betreff: Re: syncrepl connection / reconnect Hi Thorsten, please provide more information for example your slapd.conf / slapd.d. The more infos you give the more feedback you get. Bye. On Fri, Mar 26, 2010 at 09:40, Thorsten Mueller <Thorsten.Mueller(a)aachen.utimaco.de<mailto:Thorsten.Mueller@aachen.utimaco.de>> wrote: Hi, I am using two slapd 2.4.20 in mirror mode. Everything seem to work fine. When I shut down slapd_A, I can see the connection retries in the log of B. After restarting A everything is fine. Replication works in both directions. When I switch off the machine hosting A, B does not log anything. After starting machine A, replication only works from B to A and not from A to B. Only after restarting slapd_B the connection is reestablished and the changes are synced. I see the same behavior, if I just do a "ifconfig eth0 down". The remaining slapd seems not to recognize a loss of the network connection. Is this a bug in openldap, or a configuration issue on my side? Thanks, Thorsten -- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is to do -- Sartre | Do be do be do -- Sinatra

15 years, 2 months

ldap_sasl_interactive_bind_s failed (-2) using openldap v2.3.43 when trying to replicate via syncrepl.

by Kristian Kostecky

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi guys, I have a configuration that consists of 3 ldap servers. One is the provider and there are 2 consumers. I am using syncrepl to do the synchronization. simple and anonymous binds are totally disabled and Kerberos must be used via SASL (GSSAPI) and TLS to connect to the LDAP server. distro: centos 5.4 openldap 2.3.43 cyrus-sasl 2.1.22 Other things: - - clocks are all in sync - - hostnames all have forward and reverse mappings and all dns servers in /etc/resolv.conf respond with proper entries on the consumer and both providers. Here's the catch, the two providers are configured the same (except for hostnames/ips) and the first one works perfect. What is really frustrating is the lack of logging that is available to tell me what the problem is. I've tried loglevel -1 and it gave me even less info in regards to the SASL authentication than leaving it off. The affected consumer is giving me: Mar 31 22:41:00 ZZZ slapd[2442]: slapd starting Mar 31 22:41:02 ZZZ slapd[2442]: do_syncrep1: rid 010 ldap_sasl_interactive_bind_s failed (-2) Mar 31 22:41:02 ZZZ slapd[2442]: do_syncrepl: rid 010 quitting On the "Provider": Mar 31 17:49:54 XXX slapd[3494]: conn=212 fd=21 ACCEPT from IP=10.130.1.230:60288 (IP=0.0.0.0:389) Mar 31 17:49:54 XXX slapd[3494]: conn=212 op=0 STARTTLS Mar 31 17:49:54 XXX slapd[3494]: conn=212 op=0 RESULT oid= err=0 text= Mar 31 17:49:54 XXX slapd[3494]: conn=212 fd=21 TLS established tls_ssf=256 ssf=256 Mar 31 17:49:54 XXX slapd[3494]: conn=212 op=1 UNBIND Mar 31 17:49:54 XXX slapd[3494]: conn=212 fd=21 closed This is what's REALLY weird - from the affected/broken box, ZZZ, after I kinit, I can do an LDAP search or ldapwhoami, no problems! So, kerberos and GSSAPI via SASL is working fine. ie: ldapsearch -H ldaps://XXX/ -Y GSSAPI -> will dump the entries. or ldapwhoami -H ldaps://XXX/ -Y GSSAPI -> shows me that proper creds If I destroy the credentials, it doesn't work as would be expected. ON the working consumer, the behaviour is that I can ldapsearch and ldapwhoami properly after I kinit and when I start ldap it will authenticate properly with the provider via SASL GSSAPI and replicates the DB. If I kdestroy the credentials and start it, I get the same error that I'm struggling with on the box that doesn't work ->ldap_sasl_interactive_bind_s failed (-2) This behaviour leads me to believe that for some reason the ldap server on the box that doesn't work is having problems transmitting the kerberos credentials to the provider, whereas the ldapsearch and ldapwhoami binaries are not having problems. There are some suspicious differences between the consumer that works and the broken one. The provider and consumer that works both have TLDs that match - '.com' and the consumer whose synrepl process won't authenticate is part of the .eu TLD. However, as you can see below in the krb5.conf files, the .com and .eu TLDS are always mapped to the same authentication realm. PLUS, again, ldapsearch and ldapwhoami WORK. It's just the syncrepl process that isn't quite getting the auth right. This is the provider's pertinent configs: slapd.conf: overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 This is the consumer's pertinent configs (WORKS ON one, not on the other) slapd.conf: syncrepl rid=10 provider=ldap://xxx.XXX.com starttls=yes type=refreshOnly interval=00:00:01:00 searchbase="dc=XXX,dc=com" schemachecking=off bindmethod=sasl saslmech=GSSAPI krb5.conf [same as provider and kerb server]: [libdefaults] default_realm = BOUNCE.AAA.COM encrypt = true allow_weak_crypto = false clockskew = 600 dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 8h forwardable = no proxiable = no [realms] BOUNCE.AAA.COM = { kdc = XXX.com kdc = YYY.com kdc = ZZZ.eu admin_server = XXX.com } [domain_realm] .com = BOUNCE.AAA.COM .eu = BOUNCE.AAA.COM All help is greatly appreciated! This has been going on for days and I've already yanked out most of my hair. Thank you. Kris. PGP Key: 4CC63A18 PGP Server: pool.sks-keyservers.net -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) iEYEARECAAYFAkuzyroACgkQ2C/J5/UUQWEuUACdH/BhiZgTXFWbNMXS7Q99k8Rg VY8An3YWKcpnkxVYvZMlelkT0TIpYuAP =O9KI -----END PGP SIGNATURE-----

15 years, 2 months

Re: Ldap is up, trying to get tls working.

by Juan Miscaro

On 1 November 2011 11:53, John Tobin <jtobin(a)po-box.esu.edu> wrote: > Certificates verify. > That's a neat tool, put that information somewhere useful. > I had been trying to prove that the certificates were good for a long time. > > I changed from nscd, to nslcd by installing via yast, nss-pam-ldapd > > That wasn't too bad. > > I configured nslcd with: > > Uri ldap://nightmare.dark.net:389/ > > Base "dc=dark,dc=net" > > Ssl start_tls > Tls_req never > Tls_cacertfile /var/lib/ldap/cacert.pem > > Tls_cert /var/lib/ldap/server.pem > Tls_key /var/lib/ldap/server.key > > Ldapsearch still works .... With -ZZ > > But su - jtobin > Gets the same error message this time from kdeinit: > > nightmare:/var/log # tail -f messages |grep tls > Nov 1 11:48:11 nightmare kdeinit4: nss-ldap: do_open: do_start_tls > failed:stat=-1 > Nov 1 11:48:11 nightmare kdeinit4: nss-ldap: do_open: do_start_tls > failed:stat=-1 > > I guess I am wondering if I configured something wrong.... > Why am I seeing nss-ldap in here... > > I installed nslcd, configured it, and didn't change any thing in ldap.conf > or nsswitch.conf, should anything else be changed? > > tob > > > nighttrain:~ johntobin$ > > > > > > > > On 10/28/11 12:08 PM, "Christopher Wood" <christopher_wood(a)pobox.com> wrote: > >> Cheap advice inline. >> >> On Fri, Oct 28, 2011 at 11:44:25AM -0400, John Tobin wrote: >>> Folks, >>> >>> I have openldap up, it supports vsftpd, sshd, and 5 client linux machines >>> for remote login. >>> >>> I would like to get tls working. I would support either ldaps [port 636], >>> or the tls available on port 389, I am aware of the differences in >>> implementation, and the fact that an administrator effectively has to make >>> a decision to support one or the other in most cases. >>> >>> Currently: >>> I have slapd running configured for tls under ldap [std port 389]. >>> I am testing it on the slapd machine, with a client on the same machine. >>> I am pointing to the same cacertificate in slapd.d [cn=config.ldif] and >>> ldap.conf. >>> >>> With that in place, and the ldap.conf below: >>> nightmare:/etc # cat ldap.conf >>> >>> base dc=dark,dc=net >>> uri ldap://nightmare.dark.net >>> # scope sub >>> # binddn "cn=admin,dc=dark,dc=net" >>> # bindpw jackie >>> bind_policy soft >>> # The user ID attribute (defaults to uid) >>> pam_login_attribute uid >>> pam_lookup_policy yes >>> pam_password exop >>> nss_schema rfc2307bis >>> tls_reqcert never >>> pam_filter objectClass=posixAccount >>> ldap_version 3 >>> nss_map_attribute uniqueMember uniqueMember >>> ssl start_tls >>> tls_cacert /var/lib/ldap/cacert.pem >>> tls_cert /var/lib/server.crt >>> tls_key /var/lib/ldap/server.key >>> >>> I have run ldapsearch: >>> nightmare:/media # ldapsearch -v -x -H ldap://nightmare.dark.net:389/ -b >>> "dc=dark,dc=net" -Z >> >> Always test starttls with -ZZ, so if your starttls isn't working the >> connection will fail. >> >>> ldap_initialize( ldap://nightmare.dark.net:389/??base ) >>> filter: (objectclass=*) >>> requesting: All userApplication attributes >>> # extended LDIF >>> # >>> # LDAPv3 >>> # base <dc=dark,dc=net> with scope subtree >>> # filter: (objectclass=*) >>> # requesting: ALL >>> # >>> >>> # dark.net >>> dn: dc=dark,dc=net >>> dc: dark >>> o: dark >>> objectClass: organization >>> objectClass: dcObject >>> >>> # admin, dark.net >>> dn: cn=admin,dc=dark,dc=net >>> objectClass: organizationalRole >>> cn: admin >>> >>> # Default Policy, dark.net >>> dn: cn=Default Policy,dc=dark,dc=net >>> objectClass: namedObject >>> objectClass: pwdPolicy >>> cn: Default Policy >>> >>> # People, dark.net >>> dn: ou=People,dc=dark,dc=net >>> objectClass: organizationalUnit >>> ou: People >>> description: People is used in mapping the /etc/passwd entries >>> >>> # jtobin, People, dark.net >>> dn: uid=jtobin,ou=People,dc=dark,dc=net >>> uid: jtobin >>> cn: John C. Tobin >>> objectClass: account >>> objectClass: posixAccount >>> objectClass: top >>> objectClass: shadowAccount >>> loginShell: /bin/ksh >>> uidNumber: 5000 >>> gidNumber: 100 >>> homeDirectory: /home/jtobin >>> gecos: John C. Tobin >>> >>> # defaultDNS, dark.net >>> dn: cn=defaultDNS,dc=dark,dc=net >>> cn: defaultDNS >>> objectClass: top >>> objectClass: suseDnsConfiguration >>> suseDefaultBase: ou=DNS,dc=dark,dc=net >>> >>> # DNS, dark.net >>> dn: ou=DNS,dc=dark,dc=net >>> objectClass: top >>> objectClass: organizationalUnit >>> ou: DNS >>> >>> # search result >>> search: 3 >>> result: 0 Success >>> >>> # numResponses: 8 >>> # numEntries: 7 >>> >>> nightmare:~ # >>> ##### >>> >>> So I am assuming the ldapserver on ldap://nightmare.dark.net:389/ with tls >>> works. >>> [I looked through the message output in /var/log/message and see the >>> ³STARTTLS² and ³TLS established tls_ssf=256²] >>> I have done a number of similar ldapsearches. This appears to work >>> correctly. >>> >>> On the client machine I now do : >>> >>> nightmare:/media # su - jtobin >>> su: user jtobin does not exist >>> nightmare:/media # >>> >>> /var/log/message - output...... >>> >>> nightmare:/var/log # tail f |grep I tls >>> >>> Oct 28 11:29:01 nightmare slapd[11118]: conn=1217 op=0 STARTTLS >>> Oct 28 11:29:01 nightmare worker_nscd: nss-ldap: do_open: do_start_tls >>> failed:stat=-1 >>> Oct 28 11:29:01 nightmare slapd[11118]: connection_read(14): TLS accept >>> failure error=-1 id=1217, closing >>> Oct 28 11:29:01 nightmare slapd[11118]: conn=1217 fd=14 closed (TLS >>> negotiation failure) >>> Oct 28 11:29:01 nightmare slapd[11118]: conn=1218 op=0 STARTTLS >>> Oct 28 11:29:01 nightmare worker_nscd: nss-ldap: do_open: do_start_tls >>> failed:stat=-1 >> >> Augh. If you can stop using nscd all this will be much easier for you. I >> personally like nslcd rather than nss-ldap, but each to their own. >> >> If not, restart nscd before you start every troubleshooting round. >> >>> Oct 28 11:29:01 nightmare slapd[11118]: connection_read(14): TLS accept >>> failure error=-1 id=1218, closing >>> Oct 28 11:29:01 nightmare slapd[11118]: conn=1218 fd=14 closed (TLS >>> negotiation failure) >> >> First I would test that all the CA certs and server certs in use are >> understandable by each other. Does the server cert on the machine running >> slapd validate against the CA cert on the machine running ldapsearch? Does the >> server cert on the machine running slapd validate against the CA cert on the >> client machine? >> >> openssl verify -CAfile cacert.pem servercert.pem >> >> If the output says "ok" then the actual cert part is fine. >> >> At this point I would crank up the slapd debug level (run it in the >> foreground) and match it again your ldap client debug logs. See if you can >> reproduce the error above using a client like ldapsearch, using the same >> search parameters as the nss-ldap client would use. >> >>> [if you want more of the log, I can obviously get it, but these appear to >>> be the important parts.] >>> >>> This is probably a configuration error, or a logical / architecture >>> misunderstanding, ok, I Œm a newbie. >>> Do I have certificates incorrectly generated? [certificates were generated >>> via [1]http://www.openldap.org/faq/data/cache/185.html]. >>> What did I do wrong? >>> >>> This is running openldap 2.4.26 off of Suse 12.1 milestone 5. >> >> I'm getting a puppetized starttls working with 2.4.26/openssl on debian, but >> much the same thing. >> >>> Thanks in advance. >>> tob >>> >>> References >>> >>> Visible links >>> 1. http://www.openldap.org/faq/data/cache/185.html >> > > Did you ever get this to work? -- /jm

13 years, 6 months

Problems with syncrepl state

by Berthold Cogel

Hello, we have a cluster of LDAP servers consisting of one provider and 4 consumer. We're upgrading the os of the systems by proving an replacement system for each of the five systems. Then we stop the slapd on the system that should be replaced, dump the database with slapcat, copy it to new system, switch hostname and ip of both systems. We shut down the old and reboot the new system. Then we slapadd the database on the new system. So far so good... We started with the provider. After importing the database and starting the slapd on the new provider, we get errors for the syncrepl state on all consumer systems: "Can't get Context CSN with SID <x> from ldap+tls://localhost. Please set SID with -I option." We're using check_ldap_syncrepl_status from ltb-project with icinga2 to monitor the replication. I don't know how to fix this. When I modify an entry in the provider, it is synced to the consumer. But the status error stays. On all four consumers. I've then 'upgraded' a consumer by starting the slapd on the replacment system without any database. The system started the sync and after completion the error was gone. But syncing takes more time than importing a dump from a local file. And in a case where we have to rebuild the provider from scratch after a crash, it might be not an option to resync one consumer after the other to rebuild the complete cluster. Is there a method to fix the problem? Syncrepl configuration on the provider overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 Syncrepl configuration on the consumer syncrepl rid=<x> provider=ldap://yxz:389 binddn="cn=xxxxxxx" credentials="xxxxxxx" tls_cacertdir=/etc/pki/tls/certs tls_reqcert=demand bindmethod=simple starttls=critical searchbase="xxxxxx" type=refreshAndPersist retry="10 10 300 +" filter="(objectClass=*)" scope=sub attrs="*,+" sizelimit=unlimited timelimit=unlimited schemachecking=off Regards Berthold Cogel

4 years, 8 months

Re: TLS hostname check failure and subjectAltname extension

by Andrew Findlay

On Thu, Jan 12, 2012 at 05:31:31PM +0100, Michael Ströder wrote: > We're using self-compiled OpenLDAP 2.4.27 under RHEL 6.1 linked > against OpenSSL 1.0.0 libs shipped with RHEL. > Unfortunately we can't get StartTLS to work. It always fails: > > # /opt/xxxdir/bin/ldapsearch -x -ZZ ldap://ldap-srv01.rz.domain > ldap_start_tls: Connect error (-11) > additional info: TLS: hostname does not match CN in peer certificate > # /opt/xxxdir/bin/ldapsearch -x -ZZ ldap://ldap.domain > ldap_start_tls: Connect error (-11) > additional info: TLS: hostname does not match CN in peer certificate > > But OpenSSL lists the (IMO correct) hostnames in the server's certificate: > > ---------------------------------- snip ---------------------------------- > Subject: CN=ldap.domain,OU=xxx,O=xxx,C=DE > [..] > X509v3 Subject Alternative Name: > email:certificate@xxx.domain, > DNS:ldap.domain, > DNS:ldap-srv01.rz.domain, > DNS:ldap-srv02.rz.domain > ---------------------------------- snip ---------------------------------- > > Is the hostname check confused by the email in the first > subjectAltName sequence value? Probably not. I have just set up a test case like that and it works. All software is current versions on Debian Squeeze: @(#) $OpenLDAP: slapd 2.4.23 (Jun 15 2011 13:31:57) $ @incagijs:/home/thijs/debian/p-u/openldap-2.4.23/debian/build/servers/slapd OpenSSL 0.9.8o 01 Jun 2010 I usually find that the problem is with the client-side setup, probably not getting the right TLS_CACERT value (i.e. in your case maybe /opt/xxxdir/bin/ldapsearch is reading /opt/xxxdir/etc/openldap/ldap.conf rather than /etc/openldap/ldap.conf Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

13 years, 4 months

Re: Security between server and client nodes.

by Jayavant Patil

On Tue, Nov 29, 2011 at 6:26 PM, Jayavant Patil <jayavant.patil82(a)gmail.com>wrote: > > >>Mon, 28 Nov 2011 11:25:16 +0100 Raffael Sahli <public(a)raffaelsahli.com> > wrote: > >>Hi > > >>I think you mean SSL connection or the STARTTLS Layer...? > >>Please read the manual http://www.openldap.org/doc/admin24/tls.html > >Ok. > > >>And tree security: > >>On my server, a client user can only see his own object: > >Are you using simple authentication mechanism? > > >>Maybe create a rule like this: > >>access to filter=(objectClass= > >>simpleSecurityObject) > >> by self read > >> by * none > > >I am not getting what the ACL rule specifies. Any suggestions? > I have two users ldap_6 and ldap_7. I want to restrict a user to see his own data only. In slapd.conf, I specified the rule as follows: access to * by self write by * none But ldap_6 can see the ldap_7 user entries (or vice versa) with $ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b "ou=People,dc=abc,dc=com" "uid=ldap_7" Any suggestions? > > -- > > Thanks & Regards, > > Jayavant Ningoji Patil > Engineer: System Software > Computational Research Laboratories Ltd. > Pune-411 004. > Maharashtra, India. > +91 9923536030. > > -- Thanks & Regards, Jayavant Ningoji Patil Engineer: System Software Computational Research Laboratories Ltd. Pune-411 004. Maharashtra, India. +91 9923536030.

13 years, 6 months

Re: syncrepl not propagating changes

by Howard Chu

Mark Coetser wrote: > Hi > > current version of openldap 2.4.23-7.2 I have however built and used > 2.4.31 with the same results. > > I have a single provider that has multiple domians > > ie dc=company > dc=subdivision1,dc=company > dc=subdivision2,dc=company > > on some of the consumers, I have a single syncrepl config with the base, > so these servers have all the users and replication tends to work fine. > > olcSyncrepl: {0} > rid=00x > provider=ldaps://x.x.x.x > bindmethod=simple > binddn="cn=replica,dc=repl_config,dc=company" > credentials="xxxxx" > filter="(objectclass=*)" > searchbase="dc=company" > scope=sub > attrs="*,+" > schemachecking=off > type=refreshAndPersist > retry="5 5 300 +" > starttls=yes > tls_reqcert=never > tls_cert=/etc/ldap/ssl/ca-cert.pem > tls_key=/etc/ldap/ssl/keys/ca-key.pem > > > on some of the consumers, I have multiple syncrepl configs so that I > replicate specific subdivision data to those servers. That is not supported. You can only use multiple consumers in the same database if they are all pointing at different providers (and each of those providers uses a unique serverID). > whats happening with these consumers is that the initial sync seems to > work and some changes to the provider do make it down to the consumer > but lately most changes are NOT making it down to the consumer, when I > log sync then I am seeing that the csn is committed for the change for > the first rid but then for the next rid it logs that the csn is too old? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

12 years, 9 months

Re: Openldap for proxy AD

by Willy Ramos

Em 22/11/2013 09:21, Andrew Findlay escreveu: > On Wed, Nov 20, 2013 at 02:55:43PM -0200, Willy Ramos wrote: > >> Subject: Re: Openldap for proxy AD > Have you tried following the examples in the Admin Guide? > > http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authentica… > > There is a detailed setup and diagnosic guide there which should help you > to isolate the problem. > > Andrew Thanks Andrew, I was testing based in this Admin Guide. When I Check that the user can bind to AD: ldapsearch -x -H ldap://dc1.example.com/ \ -D cn=user,cn=Users,DC=ad,DC=example,DC=com \ -w userpassword \ -b cn=user,cn=Users,DC=ad,DC=example,DC=com \ Or with -s base \ "(objectclass=*)" Or testsaslauthd -u user -p userpassword It´s works. I was reading about and Seems don´t find the schemas of objectclass or userPassword attribute; But I could not resolve yet. See the logs Nov 22 11:57:30 mail slapd[18370]: conn=1192 fd=11 ACCEPT from IP=127.0.0.1:51698 (IP=0.0.0.0:636) Nov 22 11:57:30 mail slapd[18370]: conn=1192 fd=11 TLS established tls_ssf=256 ssf=256 Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=0 STARTTLS Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=0 RESULT oid= err=1 text=TLS already started Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=1 UNBIND Nov 22 11:57:30 mail slapd[18370]: conn=1192 fd=11 closed Thanks. -- Att. Willy R. M CDTN/System Software

11 years, 6 months

Syncrepl N-Way multimaster replication - Configuration issue on Rhel6

by coma

Hello everybody, i'm currently tring to configure N-Way multimaster replication, and i'm facing two issues with olcServerId and slapd -h options. For information: I'm running on Rhel6.6 with openldap 2.4.39-8. I'm running slapd on non-standard ports (11389 for ldap and ldap with TLS, and 11390 for ldaps) I've tried on standard ports but same issues. I've configured the replication following these two procedures: https://access.redhat.com/solutions/273533 http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master - First Issue details: When i'm adding olcServerID's on both servers, using following ldif: cat <<EOF | ldapmodify -Y EXTERNAL -H ldapi:/// dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 ldap://server1-test1.test.com olcServerID: 2 ldap://server2-test1.test.com EOF i'm no longer able to restart slapd. Error is: read_config: no serverID / URL match found. Check slapd -h arguments. To resolve it, i've tried to add the URL of my servers in correspondant /etc/sysconfig/ldapExample: SLAPD_LDAP=no SLAPD_LDAPI=yes SLAPD_LDAPS=no SLAPD_URLS="ldap://server1-test1.test.com:11389 ldaps://server1-test1.test.com:11390" But issue "Error is: read_config: no serverID / URL match found." is always present event after a server reboot and a full openldap reinstallationn. - Second issue détails (replication disabled, serverID's removed): With /etc/sysconfig/ldap configured as: SLAPD_LDAP=no SLAPD_LDAPI=yes SLAPD_LDAPS=no SLAPD_URLS="ldap://:11389 ldaps://:11390" i'm able to connect on port 11389/11390 with clear, starttls and SSL using a ldap browser or ldapsearch, But with /etc/sysconfig/ldap configured as: SLAPD_LDAP=no SLAPD_LDAPI=yes SLAPD_LDAPS=no SLAPD_URLS="ldap://server1-test1.test.com:11389 ldaps://server1-test1.test.com:11390" i'm not able to connect anymore. Can you please help me on this? Thanks in advance,

10 years, 6 months

Re: Spurious Start TLS failed errors on proxyed bind OpenLDAP 2.4.40 [possible cause found]

by Quanah Gibson-Mount

--On Monday, January 28, 2019 6:47 PM +0200 Janne Peltonen <janne.peltonen(a)helsinki.fi> wrote: > Next, we tried Unto Sten's suggestion: we confirmed that the "timeout" > variable is zero, so we go into the "else" branch he mentioned; then > instead of calling the macro in the else branch, we just directly set > tv.sec = 3 and tv.usec = 0 (a quick and dirty hack, I know). After that, > we were no longer able to get any Start TLS failed errors on the proxy, > and all proxy binds were completed succesfully. To make sure, we > downgraded the proxy again, and sure enough, the Start TLS failed > errors reappeared, or rather, we began to have some of them again. > Upgraded again, and no errors at all. > > To us, this really seems as if the root of the problem were that the > starttls timeout ends up being 0.1 seconds, which is too short if > there're any latencies in the network. What would be the correct place > to fix this? It appears to me that you should be able to say "timeout > extended=5" or something similar in a config file, but in > back-ldap/config.c the "extended" timeout option is commented out as > unimplemented. So, what would be required to implement it? > > Relevant files: > > back-ldap/bind.c (ldap_back_start_tls function, setting of tv using > LDAP_BACK_TV_SET macro) > back-ldap/back-ldap.h (defining the LDAP_BACK_TV_SET to basically set > the timeout to 0.1 s) > back-ldap/config.f (definition of timeout_table) Please file an issue report at http://www.openldap.org/its/ so this can be tracked and resolved. Thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

6 years, 4 months

openldap-technical search results for query "starttls"