Search results for "starttls" - openldap-technical

Re: LDAP Crafted Search Request Access Allowed

by Net Warrior

Hi Andrew, I've got some updates. 1 ) Added tls_reqcert demand to the client side 2 ) Configured a user to bind instead of anonymous binddn cn=ldapuser,Ou=Users,dc=server,dc=com bindpwd :$6$oZ8qYohy$lU0sYJXInOO1ISO4WKgzeuDyyFh9a 3 ) Added olcTLSVerifyClient:demand to server side: Now as I can see this is good, the TLS is established with a strong security factor of 256. Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 fd=252 ACCEPT from IP=X.X.X.X:58387 (IP=0.0.0.0:389) Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 op=0 STARTTLS Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 op=0 RESULT oid= err=0 text= Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 fd=252 TLS established tls_ssf=256 ssf=256 The user configured to bind from the client side Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 op=1 BIND dn="cn=ldapuser,ou=Users,dc=server,dc=com" method=128 Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 op=1 BIND dn="cn=ldapuser,ou=Users,dc=server,dc=com" mech=SIMPLE ssf=0 My user id used to login to the server: Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 op=3 BIND dn="cn=My Username,ou=Users,dc=serverdc=com" method=128 Object added to server: dn: olcDatabase={2}bdb,cn=config changetype:modify add: olcTLSVerifyClient:demand Still I did not corrected my ACL but I do not see olcTLSVerifyClient:demand reflected on my configuration with slapcat -n0 I only see the this: olcTLSCACertificateFile: /etc/openldap/certs/cert.pem olcTLSCertificateKeyFile: /etc/openldap/certs/private.key olcTLSCertificateFile: /etc/openldap/certs/cert.pem Did I do something wrong? Thanks for your time and support Regards 2014-10-29 14:51 GMT-03:00 Net Warrior <netwarrior863(a)gmail.com>: > Ok, thank you very much, I'm gonna review the configuration and follow > your advice. > > Best regards. > > 2014-10-29 13:43 GMT-03:00 Andrew Findlay <andrew.findlay(a)skills-1st.co.uk > >: > > On Wed, Oct 29, 2014 at 08:19:03AM -0300, Net Warrior wrote: >> >> > 200 Servers and 20 users >> >> OK - that means that you will not have problems with the default >> limits on result-set size (500 entries). >> >> > >I hope you don't really bind with the ROOTDN account! >> > NO! and I have a user to test the configuration but I do not use it >> to bind >> > purposes, but I could if I knew how to configure it. >> >> As you have quite a lot of servers and a policy of hiding all data >> from anonymous users, I would suggest having more than one LDAP-client >> account. Either create one per client server, or one per group of similar >> servers. >> >> I would suggest putting the client accounts in a dedicated part of the >> LDAP tree, so it might look like this: >> >> ou=Users,dc=server,dc=com POSIX user accounts >> ou=Groups,dc=server,dc=com POSIX groups >> ou=Clients,dc=server,dc=com Client machine accounts >> >> You need to get all your client machines to bind with their account DN >> and password before you start changing ACLs. Config file entries will look >> something like this: >> >> binddn cn=server1,ou=Clients,dc=server,dc=com >> bindpw SomeLongAndSecurePassword >> >> > >You should also add: >> > >tls_reqcert demand >> > >and you may want to consider restricting the connection to high-grade >> ciphers >> > e.g.: >> > >tls_ciphers HIGH:MEDIUM:@STRENGTH >> > >> > Both, client and server side right? >> >> Yes, but the keyword for slapd.conf is TLSCipherSuite >> and for ldap.conf it is TLS_CIPHER_SUITE >> >> Once you have *all* the clients using TLS and binding with their client >> account and password, you can start on ACLs. If your logging includes >> the 'stats' category (256) you will be able to see TLS setup and bind >> in the logs, e.g.: >> >> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 fd=26 ACCEPT from >> IP=[::1]:43386 (IP=[::]:389) >> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=0 EXT >> oid=1.3.6.1.4.1.1466.20037 >> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=0 STARTTLS >> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=0 RESULT oid= err=0 >> text= >> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 fd=26 TLS established >> tls_ssf=128 ssf=128 >> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=1 BIND >> dn="cn=client234,ou=Clients,dc=server,dc=com" method=128 >> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=1 BIND >> dn="cn=client234,ou=Clients,dc=server,dc=com" mech=SIMPLE ssf=0 >> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=1 RESULT tag=97 >> err=0 text= >> >> After all that, the ACLs turn out to be really simple! Something like this >> will probably be close to what you need for the main database: >> >> access to attrs="userPassword" >> by self =w >> by * auth >> >> access to * by users read >> >> access to * by * none >> >> If you have a replica server then you will need to add an ACL giving read >> access >> to all attributes. This should go right at the top of the list, and will >> look something >> like this: >> >> access to * by dn.exact="cn=replicator,ou=Clients,dc=server,dc=com" read >> >> If you are using the Monitor database then you should probably protect it >> like this: >> >> access to dn.subtree="cn=Monitor" >> by users read >> by * none >> >> And to make sure that critical stuff like the root DSE and the schema can >> be >> read by everyone, add this to the global section of the config: >> >> access to * by * read >> >> >> 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 | >> ----------------------------------------------------------------------- >> > >

10 years

RE: difference between /etc/ldap.conf /etc/openldap/ldap.conf

by GanGan

yes I have On Wed, 29 Oct 2008 12:19:56 -0400, Lynn York <lyork(a)inetu.net> wrote: > You also should check the sshd_config and make sure you have "UsePAM yes" > in > the config > > -----Original Message----- > From: GanGan [mailto:gangan@zalteam.com] > Sent: Wednesday, October 29, 2008 12:03 PM > To: Lynn York > Cc: Hallvard B Furuseth; Openldap technical > Subject: RE: difference between /etc/ldap.conf /etc/openldap/ldap.conf > > > > I did not touch so I do not think it comes from this files > > > > On Wed, 29 Oct 2008 11:55:29 -0400, Lynn York <lyork(a)inetu.net> wrote: >> Make sure have configured PAM properly. Here is an example of a >> system-auth-ac file that I use that works properly: >> >> [ /etc/pam.d/system-auth-ac ] >> #%PAM-1.0 >> # This file is auto-generated. >> # User changes will be destroyed the next time authconfig is run. >> auth required pam_env.so >> auth sufficient pam_unix.so nullok try_first_pass >> auth sufficient pam_ldap.so use_first_pass >> auth required pam_deny.so >> >> account required pam_unix.so broken_shadow >> account sufficient pam_localuser.so >> account sufficient pam_succeed_if.so uid < 500 quiet >> account [default=bad success=ok user_unknown=ignore] pam_ldap.so >> account required pam_permit.so >> >> password requisite pam_cracklib.so try_first_pass retry=3 >> password sufficient pam_unix.so md5 shadow nullok try_first_pass >> use_authtok >> password sufficient pam_ldap.so use_authtok >> password required pam_deny.so >> >> session optional pam_keyinit.so revoke >> session required pam_limits.so >> session [success=1 default=ignore] pam_succeed_if.so service in > crond > >> quiet use_uid >> session required pam_unix.so >> session optional pam_ldap.so >> [ end /etc/pam.d/system-auth-ac ] >> >> >> -----Original Message----- >> From: openldap-technical-bounces+lyork=inetu.net(a)openldap.org >> [mailto:openldap-technical-bounces+lyork=inetu.net@openldap.org] On > Behalf >> Of >> GanGan >> Sent: Wednesday, October 29, 2008 11:28 AM >> To: Hallvard B Furuseth >> Cc: Openldap technical >> Subject: Re: difference between /etc/ldap.conf /etc/openldap/ldap.conf >> >> >> thank you >> >> I have a problem with my users authentication. >> >> getent passwd >> gives me my 4 users ldap >> >> [...] >> >> videl:x:503:1000:videl:/home/videl:/bin/bash >> azerty:x:501:1000:azerty:/home/azerty:/bin/bash >> wizz:x:515:1000:wizz:/home/wizz:/bin/bash >> shen:x:509:1000:shen:/home/shen:/bin/bash >> >> but impossible to connect. >> >> [root@clitest3 /]# ssh videl(a)srvtest3.test.org >> videl(a)srvtest3.test.org's password: >> Permission denied, please try again. >> videl(a)srvtest3.test.org's password: >> Permission denied, please try again. >> videl(a)srvtest3.test.org's password: >> Permission denied (publickey,password). >> >> log ldap server (srvtest3): >> >> Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 fd=14 ACCEPT from >> IP=127.0.0.1:40706 (IP=0.0.0.0:389) >> Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=0 STARTTLS >> Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 fd=14 TLS established >> tls_ssf=256 ssf=256 >> Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=0 RESULT oid= err=0 > text= >> Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=1 BIND dn="" method=128 >> Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=1 RESULT tag=97 err=0 >> text= >> Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=2 SRCH >> base="ou=user,dc=midian,dc=org" scope=2 deref=0 >> filter="(&(objectClass=posixAccount)(uid=videl))" >> Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=2 SRCH attr=uid >> userPassword uidNumber gidNumber cn homeDirectory loginShell gecos >> description objectClass >> Oct 29 16:25:41 srvtest3 slapd[1947]: conn=19 op=2 SEARCH RESULT tag=101 >> err=0 nentries=0 text= >> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=19 op=3 SRCH >> base="ou=user,dc=midian,dc=org" scope=2 deref=0 >> filter="(&(objectClass=posixAccount)(uid=videl))" >> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=19 op=3 SRCH attr=uid >> userPassword uidNumber gidNumber cn homeDirectory loginShell gecos >> description objectClass >> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=19 op=3 SEARCH RESULT tag=101 >> err=0 nentries=0 text= >> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 fd=17 ACCEPT from >> IP=127.0.0.1:40707 (IP=0.0.0.0:389) >> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 op=0 STARTTLS >> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 op=0 RESULT oid= err=0 > text= >> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 fd=17 TLS established >> tls_ssf=256 ssf=256 >> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 op=1 BIND dn="" method=128 >> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 op=1 RESULT tag=97 err=0 >> text= >> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 op=2 SRCH >> base="ou=user,dc=midian,dc=org" scope=2 deref=0 >> filter="(&(host=srvtest3.test.org)(uid=videl))" >> Oct 29 16:25:45 srvtest3 slapd[1947]: <= bdb_equality_candidates: (host) >> index_param failed (18) >> Oct 29 16:25:45 srvtest3 slapd[1947]: conn=20 op=2 SEARCH RESULT tag=101 >> err=0 nentries=0 text= >> >> I do not understand why it is not working. :( >> any idea ? > -- > - GanGan - > www.system-linux.eu merci pour le clique sur la pub :p -- - GanGan - www.system-linux.eu merci pour le clique sur la pub :p

16 years

Re: delta-synrepl consumer randomly delete objects

by Raffael Sahli

On 20.10.2016 09:19, Raffael Sahli wrote: > Hi > > What can lead a consumer to "randomly" delete ~50% of all objects in his database? > I have this problem now for ~1-2months and on 3 different master/slave groups. > > The consumer starts to delete objects (but those are all present on the master): > > Oct 19 17:16:22 ldap-slave002.xxx slapd[8554]: do_syncrep2: rid=999 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > Oct 19 17:16:22 ldap-slave002.xxx slapd[8554]: do_syncrep2: rid=999 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 9c802b18-7c2c-1033-9f25-2d4a65066d19, dn uid=jasmin.mans,ou=none,o=dd,dc=xxx,dc=xxx > Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 650ada00-e996-1035-80ac-a173474274df, dn uid=jasmine.suddr,ou=none,o=dd,dc=xxx,dc=xxx > Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID ec5c9aa4-7c2c-1033-9fa4-2d4a65066d19, dn uid=jonas.beffrnn,ou=none,o=dd,dc=xxx,dc=xxx > Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 7461d22e-e996-1035-80f6-a173474274df, dn uid=juerg.klegegeli,ou=none,o=dd,dc=xxx,dc=xxx > Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 758c744c-e996-1035-8100-a173474274df, dn uid=julia.sxgegegea,ou=none,o=dd,dc=xxx,dc=xxx > Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 47e4f6b4-7c2d-1033-8015-2d4a65066d19, dn uid=karin.vivwvwe,ou=none,o=dd,dc=xxx,dc=xxx > Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 8d26a4f2-7c2d-1033-807b-2d4a65066d19, dn uid=larissa.fewfewf,ou=none,o=dd,dc=xxx,dc=xxx > Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 98310aa4-7c2d-1033-808b-2d4a65066d19, dn uid=laura.cfwfew,ou=none,o=dd,dc=xxx,dc=xxx > > syncrepl config: > olcSyncrepl: {0}rid=999 provider=ldap://ldap-master002.xxx.xxx:389 bindmethod=simple timeout=0 network-timeout=10 binddn="uid=replicator,ou=system,o=de,dc=xxx,dc=xxx" > credentials="pass" keepalive=0:0:0 starttls=yes tls_cacert="/etc/ssl/certs/SwissSign_Silver_CA_-_G2.pem" tls_reqcert=allow filter="(objectClass=*)" searchbase="dc=xxx,dc=xxx" scope=sub attrs="*,+" > syncdata="accesslog" logbase="cn=accesslog_xxx" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=off type=refreshOnly interval="00:00:01:00" retry="10 5 60 +" > > > Misconfiguration? (We've been running this configuration for years...) > > > Workaround is to remove the whole mdb database and restart slapd to let it resync. > I've found some posts with a similar problem but those are all related to pre 2.4.21, we're running slapd 2.4.44. > > > Cheers > Ideas? (Most of the time slapd removes now ~99% of all objects) -- Raffael Sahli

8 years, 1 month

Re: Syncrepl over TLS for mirrormode

by Marco Schirrmeister

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 and one for 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, nor with 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, 2 months

Issue renewing my TLSCertificateFile(s)

by Olivier

Hi everyone Question : are there some limitations (key size, encryption algorithm, etc.) for certificates used by openldap to manage TLS connexions ? See below why I ask : I have used the following configuration in my slapd servers for quite a while without any problem : olcTLSCACertificateFile: /etc/openldap/cacerts/CA.crt olcTLSCertificateFile: /etc/openldap/cacerts/server.crt olcTLSCertificateKeyFile: /etc/openldap/cacerts/server.key olcTLSCipherSuite: HIGH olcTLSVerifyClient: allow See for example my configuration for syncrepl (see: tls_reqcert=demand) : olcSyncrepl: {0}rid=411 provider=ldap://ldap1.example.fr bindmethod=sasl sizelimit=unlimited timeout=0 network-timeout=0 saslmech=external type =refreshAndPersist retry="5 +" starttls=yes tls_cacert=/etc/openldap/cacer ts/CA.crt tls_cert=/etc/openldap/cacerts/replicator.crt tls_key=/etc/openldap /cacerts/replicator.key scope=sub schemachecking=on keepalive=0:0:0 fil ter="(objectclass=*)" searchbase="dc=example,dc=fr" tls_reqcert=demand -> I have used this for couple of years on my multimastered ldap servers, and until yesterday that worked perfectly : replication was working properly and clients talked with the servers using TLS without any problem. But I since my certicates were too weak (see this : sha1, 512 bit) : $ openssl x509 -text -in server.crt Certificate: Data: Version: 1 (0x0) Serial Number: 13998752034197585248 (0xc2458ece791fbd60) Signature Algorithm: sha1WithRSAEncryption Issuer: C=fr, ST=IDF, L=Town, O=example, OU=IT, CN=ldap/emailAddress=ldap(a)example.fr Validity Not Before: Dec 29 15:41:56 2011 GMT Not After : Jul 29 15:41:56 2021 GMT Subject: C=fr, ST=IDF, L=Town, O=example, OU=IT,CN= ldap1.example.fr/emailAddress=ldap(a)example.fr Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (512 bit) I have renewed them using the same self signed authority to validate them, and of course using exactly the same subject. My new certificate look like this : $ openssl x509 -text -in server.crt (see this : sha2, 4096 bit) : Certificate: Data: Version: 1 (0x0) Serial Number: 10208063777793278590 (0x8daa53ebd7e6827e) Signature Algorithm: sha256WithRSAEncryption Issuer: C=fr, ST=IDF, L=Town, O=example, OU=IT, CN=ldap/emailAddress=ldap(a)example.fr Validity Not Before: Jul 22 15:24:50 2015 GMT Not After : Feb 19 15:24:50 2025 GMT Subject: C=fr, ST=IDF, L=Town, O=example, OU=IT,CN= ldap1.example.fr/emailAddress=ldap(a)example.fr Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) Modulus: I installed my new certificate on ldap1 without changing the configuration, and restarting the server here is what I get on ldap4 logs (loglevel = sync ) : $ tail -f /var/log/ldap.log ... Jul 22 17:31:10 ldap4 slapd[53489]: slap_client_connect: URI=ldap:// ldap1.example.fr Warning, ldap_start_tls failed (-11) Jul 22 17:31:10 ldap4 slapd[53489]: slap_client_connect: URI=ldap:// ldap1.example.fr ldap_sasl_interactive_bind_s failed (-2) Jul 22 17:31:10 ldap4 slapd[53489]: do_syncrepl: rid=432 rc -2 retrying Jul 22 17:31:15 ldap4 slapd[53489]: slap_client_connect: URI=ldap://ldap1.example.fr Warning, ldap_start_tls failed (-11) Jul 22 17:31:15 ldap4 slapd[53489]: slap_client_connect: URI=ldap:// ldap1.example.fr ldap_sasl_interactive_bind_s failed (-6) Jul 22 17:31:15 ldap4-mrs slapd[53489]: do_syncrepl: rid=432 rc -6 retrying When reinstalling the previous certificates and restarting ldap1 the server I see this appearing in ldap4 logs : ... Jul 22 17:31:20 ldap4-mrs slapd[53489]: do_syncrep2: rid=432 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Question : are there some limitations (key size, encryption algorithm, etc.) for certificates used by openldap to manage TLS connexions ? Does openldap tls connections work with certificates sha 256 With RSA Encryption using a 4096 public key length ? May be I missed something ? (note : I use openssl to manage my certificates) Thanks for any help. --- Olivier

9 years, 4 months

Re: LDAP Crafted Search Request Access Allowed

by Andrew Findlay

On Wed, Oct 29, 2014 at 08:19:03AM -0300, Net Warrior wrote: > 200 Servers and 20 users OK - that means that you will not have problems with the default limits on result-set size (500 entries). > >I hope you don't really bind with the ROOTDN account! > NO! and I have a user to test the configuration but I do not use it to bind > purposes, but I could if I knew how to configure it. As you have quite a lot of servers and a policy of hiding all data from anonymous users, I would suggest having more than one LDAP-client account. Either create one per client server, or one per group of similar servers. I would suggest putting the client accounts in a dedicated part of the LDAP tree, so it might look like this: ou=Users,dc=server,dc=com POSIX user accounts ou=Groups,dc=server,dc=com POSIX groups ou=Clients,dc=server,dc=com Client machine accounts You need to get all your client machines to bind with their account DN and password before you start changing ACLs. Config file entries will look something like this: binddn cn=server1,ou=Clients,dc=server,dc=com bindpw SomeLongAndSecurePassword > >You should also add: > >tls_reqcert demand > >and you may want to consider restricting the connection to high-grade ciphers > e.g.: > >tls_ciphers HIGH:MEDIUM:@STRENGTH > > Both, client and server side right? Yes, but the keyword for slapd.conf is TLSCipherSuite and for ldap.conf it is TLS_CIPHER_SUITE Once you have *all* the clients using TLS and binding with their client account and password, you can start on ACLs. If your logging includes the 'stats' category (256) you will be able to see TLS setup and bind in the logs, e.g.: Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 fd=26 ACCEPT from IP=[::1]:43386 (IP=[::]:389) Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=0 STARTTLS Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=0 RESULT oid= err=0 text= Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 fd=26 TLS established tls_ssf=128 ssf=128 Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=1 BIND dn="cn=client234,ou=Clients,dc=server,dc=com" method=128 Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=1 BIND dn="cn=client234,ou=Clients,dc=server,dc=com" mech=SIMPLE ssf=0 Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=1 RESULT tag=97 err=0 text= After all that, the ACLs turn out to be really simple! Something like this will probably be close to what you need for the main database: access to attrs="userPassword" by self =w by * auth access to * by users read access to * by * none If you have a replica server then you will need to add an ACL giving read access to all attributes. This should go right at the top of the list, and will look something like this: access to * by dn.exact="cn=replicator,ou=Clients,dc=server,dc=com" read If you are using the Monitor database then you should probably protect it like this: access to dn.subtree="cn=Monitor" by users read by * none And to make sure that critical stuff like the root DSE and the schema can be read by everyone, add this to the global section of the config: access to * by * read 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 | -----------------------------------------------------------------------

10 years

Re: RE: OpenLDAP 2.3.4 TLS negotiation failure

by Tian Zhiying

Hi Chris： I have to regenerate the CA, and make sure that the hostname and common name match(ldap.server.com), the following is the command output: [root(a)ldap.server.com ~]# echo | openssl s_client -connect ldap.server.com:636 -showcerts -state -CAfile /etc/openldap/cacerts/cacert.pem CONNECTED(00000003) SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL_connect:SSLv3 read server hello A depth=1 /C=CN/ST=BJ/O=TS/OU=IT/CN=ldap.server.com/emailAddress=tianzy(a)server.com verify return:1 depth=0 /C=CN/ST=BJ/L=BJ/O=TS/OU=IT/CN=ldap.server.com/emailAddress=tianzy(a)server.com verify return:1 SSL_connect:SSLv3 read server certificate A SSL_connect:SSLv3 read server certificate request A SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client certificate A SSL_connect:SSLv3 write client key exchange A SSL_connect:SSLv3 write change cipher spec A SSL_connect:SSLv3 write finished A SSL_connect:SSLv3 flush data SSL_connect:SSLv3 read finished A On LDAP Server run the command: "ldapsearch -x -H ldap://ldap.server.com -ZZ" is ok, I think CA is no problem now. But on my client , it also ouput "ldap_start_tls: Connect error (-11) " LDAP Server log file output: Oct 24 11:41:41 auth slapd[14371]: conn=49 fd=14 ACCEPT from IP=192.168.9.9:46226 (IP=0.0.0.0:389) Oct 24 11:41:41 auth slapd[14371]: conn=49 op=0 STARTTLS Oct 24 11:41:41 auth slapd[14371]: conn=49 op=0 RESULT oid= err=0 text= Oct 24 11:41:41 auth slapd[14371]: conn=49 fd=14 closed (TLS negotiation failure) Tian Zhiying From: Chris Jacobs Date: 2013-10-23 22:18 To: tianzy1225; DieterKlünter; openldap-technical Subject: RE: Re: OpenLDAP 2.3.4 TLS negotiation failure Inline... > -----Original Message----- > From: openldap-technical-bounces(a)OpenLDAP.org [mailto:openldap- > technical-bounces(a)OpenLDAP.org] On Behalf Of Tian Zhiying > Sent: Wednesday, October 23, 2013 2:59 AM > To: DieterKlünter; openldap-technical > Subject: Re: Re: OpenLDAP 2.3.4 TLS negotiation failure > > Hi Dieter： > > Thanks for your quick reply. > I have changed 'TLS_REQCERT try' and check the commonName of the host > certificate, the common name is LDAP Server hostname "auth.server.com", > the following is the query results: > [root@auth cacerts]# openssl s_client -connect localhost:636 -showcerts - > state -CAfile /etc/openldap/cacerts/cacert.pem > CONNECTED(00000003) > SSL_connect:before/connect initialization > SSL_connect:SSLv2/v3 write client hello A > SSL_connect:SSLv3 read server hello A > depth=0 /C=CN/ST=BJ/L=BJ/O=TS/OU=IT/CN=auth.server.com/emailAddres > s=tianzy(a)server.com > verify error:num=18:self signed certificate > verify return:1 Here is your problem. The host does not trust the SSL cert. The 'CAfile' you've pointed the openssl command (and the real clients guessing by the path) isn't the CA chain for that SSL cert. We also use an internal CA that our hosts don't trust globally. Same command and output for me: [root(a)ldapmaster1.[snip] ~]# echo | openssl s_client -connect ldapmaster1.[snip]:636 -showcerts -state -CAfile /etc/openldap/cacerts/cacert.pem CONNECTED(00000003) SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL_connect:SSLv3 read server hello A depth=2 C = US, O = [snip], OU = PKI, CN = [snip] Internal Root CA verify return:1 depth=1 C = US, O = [snip], OU = PKI, CN = [snip] Internal Issuing CA 01 verify return:1 depth=0 C = US, ST = WA, L = Seattle, O = [snip], CN = ldap-vip. [snip], emailAddress = [snip] verify return:1 SSL_connect:SSLv3 read server certificate A SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client key exchange A SSL_connect:SSLv3 write change cipher spec A SSL_connect:SSLv3 write finished A SSL_connect:SSLv3 flush data SSL_connect:SSLv3 read finished A The command then continues to dump the cert, and the chain certs, as expected. You must put the entire CA chain from the Root CA to the signing/subordinate CA that signed this SSL cert (if applicable) in x509/PEM format in your 'CAfile' - assuming the Root CA isn't trusted server wide already. Then try again. Also, make sure to use the name specified in your SSL cert when connecting/testing - mess with your local hosts file if needed. - chris > depth=0 /C=CN/ST=BJ/L=BJ/O=TS/OU=IT/CN=auth.server.com/emailAddres > s=tianzy(a)server.com > verify return:1 > SSL_connect:SSLv3 read server certificate A > SSL_connect:SSLv3 read server certificate request A > SSL_connect:SSLv3 read server done A > SSL_connect:SSLv3 write client certificate A > SSL_connect:SSLv3 write client key exchange A > SSL_connect:SSLv3 write change cipher spec A > SSL_connect:SSLv3 write finished A > SSL_connect:SSLv3 flush data > SSL_connect:SSLv3 read finished A > > Now, the /etc/openldap/ldap.conf file: > URI ldap://ldap.server.com/ > BASE dc=server,dc=com > TLS_CACERT /etc/openldap/cacerts/cacert.pem > #SSL ON > TLS_REQCERT try > > But, run "#ldapsearch -x -H ldap://ldap.server.com -ZZ" , I also get the > following error: > [root@client cacerts]# ldapsearch -x -H ldap://ldap.server.com -ZZ > ldap_start_tls: Connect error (-11) > > ________________________________________ > Tian Zhiying > > From: DieterKlünter > Date: 2013-10-23 17:35 > To: openldap-technical > CC: tianzy1225 > Subject: Re: OpenLDAP 2.3.4 TLS negotiation failure > Am Wed, 23 Oct 2013 16:47:25 +0800 > schrieb "Tian Zhiying" <tianzy1225(a)thundersoft.com>: > > > Hi > > > > On the LDAP Server , I run following command is ok: > > #ldapsearch -x -H ldap://ldap.server.com -ZZ > > #ldapsearch -x -H ldap://ldap.server.com > > > > But on my client , I run "#ldapsearch -x -H ldap://ldap.server.com", > > is ok; Run "#ldapsearch -x -H ldap://ldap.server.com -ZZ" , I get the > > following error: [root@client cacerts]# ldapsearch -x -H > > ldap://ldap.server.com -ZZ ldap_start_tls: Connect error (-11) > > > > On LDAP Server log file, I get the following error messages: > > Oct 23 16:41:25 auth slapd[4213]: conn=206 fd=24 ACCEPT from > > IP=192.168.9.9:45648 (IP=0.0.0.0:389) Oct 23 16:41:25 auth > > slapd[4213]: conn=206 op=0 STARTTLS Oct 23 16:41:25 auth slapd[4213]: > > conn=206 op=0 RESULT oid= err=0 text= Oct 23 16:41:25 auth > > slapd[4213]: conn=206 fd=24 closed (TLS negotiation failure) > > > > My client ldap configuration: > > /etc/openldap/ldap.conf file: > > URI ldap://ldap.server.com/ > > BASE dc=server,dc=com > > TLS_CACERT /etc/openldap/cacerts/ca.crt > > SSL ON > > TLS_REQCERT demand > > Set 'TLS_REQCERT try' and check the commonName of the host > certificate. > SSL ON is not an openldap configuration parameter. > The /etc/ldap.conf file is not a openldap client configuration file, > but of nss_ldap. > > > /etc/ldap.conf file: > > BASE dc=server,dc=com > > URI ldap://ldap.server.com > > SSL ON > > TLS_CACERT /etc/openldap/cacert/ca.crt > > TLS_REQCERT demand > > > > Any suggestion what cause TLS negotiation failure? > > -Dieter > > -- > Dieter Klünter | Systemberatung > http://dkluenter.de > GPG Key ID:DA147B05 > 53°37'09,95"N > 10°08'02,42"E This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.

11 years, 1 month

Consumer replication 0 entries fetched - CSN problem?

by Josh Nielsen

Hello all, Last year I switched from the slapd.conf to the OLC style config for OpenLDAP and transitionally tested it by making the OLC server a replication slave to the older LDAP server configured with slapd.conf. Now I've disabled replication from that old server and am making the OLC server (LDAP01 - version 2.4.23) the new master and threw up a new VM called LDAP02 (2.4.23) to become the new sync replication slave/consumer. Though I'm using multiple guides of varying detail the simplest setup steps basically followed this article: http://gagravarr.livejournal.com/145679.html. I followed the same steps I thought I did for LDAP01, but despite the fact that I see LDAP02 bind and try to fetch entries for replication nothing is being fetched. The problem description is almost identical to this person's issue: http://www.openldap.org/lists/openldap-software/200911/msg00017.html (with "nentries=0" in the replication log messages, but plenty of entries found with an ldapsearch manually). Though I think my setup situation is different than that person's, and they were exporting using slapcat/slapadd (which I did for converting my existing slapd.conf config to LDAP01 last year, but this time I merely setup LDAP02 from scratch as a cn=config OLC server to begin with), one of the follow-up responses to that email thread said this: "The only correct usage of -w is when you have an LDIF produced by slapcat on a database that was not being used with replication before, and so is missing the contextCSN. But all the other operational attributes (entryUUID and entryCSN in particular) are present and valid." This made me wonder if the problem I'm seeing is because LDAP02 (or LDAP01?) is somehow missing a contextCSN. I am seeing no "cookie" messages associated with replication in my log. Some of my config is below as well as the log messages I am seeing on LDAP01 (edited domain & password). I did notice off-the-bat though that I am missing an "olcDbIndex: entryUUID pres,eq" entry on LDAP02 where I have it on LDAP01. Is that a crucial setting for replication? Lastly, I deleted the database files in /var/lib/ldap/ on LDAP02 and restarted slapd once I had configured "olcSyncRepl" on LDAP02 to ensure that I was starting from scratch. ------- LDAP01's log entry for LDAP02's attempted connection looks like this: Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 fd=359 ACCEPT from IP=192.168.21.60:46198 (IP=0.0.0.0:389) Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=0 STARTTLS Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=0 RESULT oid= err=0 text= Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 fd=359 TLS established tls_ssf=256 ssf=256 Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=1 BIND dn="cn=root,dc=myerslab,dc=haib,dc=org" method=128 Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=1 BIND dn="cn=root,dc=myerslab,dc=haib,dc=org" mech=SIMPLE ssf=0 Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=1 RESULT tag=97 err=0 text= Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=2 SRCH base="dc=myerslab,dc=haib,dc=org" scope=2 deref=0 filter="(objectClass=*)" Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=2 SRCH attr=* + Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text= Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=3 UNBIND Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 fd=359 closed ------- LDAP02's /etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif: dn: olcDatabase={1}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcSuffix: dc=mydomain,dc=org olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=admin,dc=mydomain,dc=org olcRootPW:: olcSyncUseSubentry: FALSE olcMonitoring: TRUE olcDbDirectory: /var/lib/ldap olcDbCacheSize: 50000 olcDbCheckpoint: 10240 720 olcSyncrepl: {0}rid=001 provider=ldap://ldap01.mydomain.org bindmethod=si mple timeout=1 network-timeout=0 binddn="cn=root,dc=mydomain,dc=org" credentials="ld4p3650" keepalive=0:0:0 starttls=yes filter="(objectclass=*)" s earchbase="dc=mydomain,dc=org" scope=sub schemachecking=off type=refr eshOnly interval=00:00:00:10 retry="5 5 300 5" tls_cacert=/etc/openldap/certs/rootCA.cert olcUpdateRef: ldap://ldap01.mydomain.org olcMirrorMode: TRUE olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 0 olcDbIndex: objectClass pres,eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: uidNumber pres,eq olcDbIndex: gidNumber pres,eq olcDbIndex: mail pres,eq,sub olcDbIndex: ou pres,eq,sub olcDbIndex: loginShell pres,eq olcDbIndex: sn pres,eq,sub olcDbIndex: givenName pres,eq,sub olcDbIndex: memberUid pres,eq,sub olcDbIndex: nisMapName pres,eq,sub olcDbIndex: nisMapEntry pres,eq,sub olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 structuralObjectClass: olcBdbConfig entryUUID: 31e2c8b0-c0ec-1033-8c20-43a6f59853d5 creatorsName: cn=config createTimestamp: 20140825214036Z entryCSN: 20140912164223.814325Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20140912164223Z ------- LDAP01's /etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif: dn: olcDatabase={1}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcSuffix: dc=mydomain,dc=org olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * no ne olcAccess: {1}to * by anonymous read olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=admin,dc=mydomain,dc=org olcRootPW:: olcSyncUseSubentry: FALSE olcMirrorMode: TRUE olcMonitoring: TRUE olcDbDirectory: /var/lib/ldap olcDbCacheSize: 50000 olcDbCheckpoint: 10240 720 olcDbConfig: {0}# $OpenLDAP: pkg/ldap/servers/slapd/DB_CONFIG,v 1.3.2.4 2007/1 2/18 11:53:27 ghenry Exp $ olcDbConfig: {1}# Example DB_CONFIG file for use with slapd(8) BDB/HDB databas es. olcDbConfig: {2}# olcDbConfig: {3}# See the Oracle Berkeley DB documentation olcDbConfig: {4}# <http://www.oracle.com/technology/documentation/berkeley-d b/db/ref/env/db_config.html> olcDbConfig: {5}# for detail description of DB_CONFIG syntax and semantics. olcDbConfig: {6}# olcDbConfig: {7}# Hints can also be found in the OpenLDAP Software FAQ olcDbConfig:: ezh9Iwk8aHR0cDovL3d3dy5vcGVubGRhcC5vcmcvZmFxL2luZGV4LmNnaT9maWxl PTI+ olcDbConfig: {9}# in particular: olcDbConfig: {10}# <http://www.openldap.org/faq/index.cgi?file=1075> olcDbConfig: {11} olcDbConfig: {12}# Note: most DB_CONFIG settings will take effect only upon re building olcDbConfig: {13}# the DB environment. olcDbConfig: {14} olcDbConfig: {15}# one 0.25 GB cache olcDbConfig: {16}set_cachesize 0 268435456 1 olcDbConfig: {17} olcDbConfig: {18}# Data Directory olcDbConfig: {19}#set_data_dir db olcDbConfig: {20} olcDbConfig: {21}# Transaction Log settings olcDbConfig: {22}set_lg_regionmax 262144 olcDbConfig: {23}set_lg_bsize 2097152 olcDbConfig: {24}#set_lg_dir logs olcDbConfig: {25} olcDbConfig: {26}# Note: special DB_CONFIG flags are no longer needed for "qui ck" olcDbConfig:: ezI3fSMgc2xhcGFkZCg4KSBvciBzbGFwaW5kZXgoOCkgYWNjZXNzIChzZWUgdGhl aXIgLXEgb3B0aW9uKS4g olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 0 olcDbIndex: objectClass pres,eq olcDbIndex: entryUUID pres,eq olcDbIndex: entryCSN pres,eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: uidNumber pres,eq olcDbIndex: gidNumber pres,eq olcDbIndex: ou pres,eq,sub olcDbIndex: mail pres,eq,sub olcDbIndex: memberUid pres,eq,sub olcDbIndex: sn pres,eq,sub olcDbIndex: loginShell pres,eq olcDbIndex: givenName pres,eq,sub olcDbIndex: nisMapName pres,eq,sub olcDbIndex: nisMapEntry pres,eq,sub olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 structuralObjectClass: olcBdbConfig entryUUID: 727d260c-cc5c-1032-89cf-2fc7acd5ca31 creatorsName: cn=config createTimestamp: 20131018161654Z entryCSN: 20140915195740.431843Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20140915195740Z ------ Thanks, Josh Nielsen

10 years, 2 months

Re: Openldap 2.3 syncrepl filter problem

by Jonathan Clarke

Hi, On 25/06/2009 15:56, Lanfeust troy wrote: > Hi list, > > In configuration of provider and consumer server with syncrepl is > possible to modify the replication filter for add new user in replica. > > In fisrt time the replica is : > > syncrepl rid=123 > provider=ldap://rh-test3.kvm.rla:389 > type=refreshOnly > interval=00:00:01:00 > retry="30 10 600 20" > searchbase="dc=local" > filter="(|(objectClass=sambaGroupMapping)(uid=user1))" > scope=sub > schemachecking=off > bindmethod=simple > binddn="uid=syncrepl,ou=sysusers,dc=local" > credentials=pwdsyncrepl > # BEGIN Session TLS > starttls="critical" > tls_cacert=__CACERTFILE__ > # End Session TLS Be careful of this syntax. Every line beginning with white space is considered a continuation of the previous line. So when this configuration file is read, it appears as one long line starting with syncrepl... and anything after a "#" is a comment. So your tls options are not being used, here. > When start the replica server it doing an ldapsearch and retrieve my > data in replica. > > So now we modify the filter as the following : > filter="(|(objectClass=sambaGroupMapping)(uid=user1)(uid=user2))" > > Now when the replica doing the ldapsearch request it do with the new > filter but returning numentrie to 0 > like this in the log of master LDAP server: > > Jun 24 22:40:40 rh-test3 slapd[28012]: conn=83 op=1 BIND > dn="uid=syncrepl,ou=sysusers,dc=local" mech=SIMPLE ssf=0 > Jun 24 22:40:40 rh-test3 slapd[28012]: conn=83 op=1 RESULT tag=97 err=0 > text= > Jun 24 22:40:40 rh-test3 slapd[28012]: conn=83 op=2 SRCH base="dc=local" > scope=2 deref=0 > filter="(|(objectClass=sambaGroupMapping)(uid=user1)(uid=user2))" > Jun 24 22:40:40 rh-test3 slapd[28012]: conn=83 op=2 SRCH attr=* + > Jun 24 22:40:40 rh-test3 slapd[28012]: conn=83 op=2 SEARCH RESULT > tag=101 err=0 *nentries=0* text= > > And when i do ldapsearch manually : > > ldapsearch -x -b dc=local -H ldap://rh-test3.kvm.rla > "(|(objectClass=sambaGroupMapping)(uid=user1)(uid=user2))" > > Jun 24 23:40:38 rh-test3 slapd[28012]: conn=133 op=1 BIND dn="" method=128 > Jun 24 23:40:38 rh-test3 slapd[28012]: conn=133 op=1 RESULT tag=97 err=0 > text= > Jun 24 23:40:38 rh-test3 slapd[28012]: conn=133 op=2 SRCH > base="dc=local" scope=2 deref=0 > filter="(|(objectClass=sambaGroupMapping)(uid=user1)(uid=user2))" > Jun 24 23:40:38 rh-test3 slapd[28012]: conn=133 op=2 SEARCH RESULT > tag=101 err=0 *nentries=13* text= > > > I don't understand why my new user is not sync !! The reason for this is that syncrepl is state-based. This means that when you restart your replica server, it only queries the master for changes since the last know replication. If the object uid=user2 had been changed since then, it would have been replicated. If you change your syncrepl configuration, you should reset this status by launching slapd with "-c rid=123". This will cause it to start syncrepl from scratch, and will replicate all entries. Regards, Jonathan -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org --------------------------------------------------------------

15 years, 4 months

Re: Syncrepl over TLS for mirrormode

by Chris Jacobs

Apologies for taking a while (and top posting - blackberry). 1)I setup the mirror-mode servers behind a VIP (named ldapmaster1 & 2). VIP hosted on an F5 BigIP - which doesn't load balance StartTLS - which was fine by us - all 389 connections are insecure and all 686 (?) are secure. 2) I created a cert via a CA trusted on all my client machines with: 2.A) Subject: ldap-vip.[domain] 2.B) subjectAltName(s): ldapmaster1.[domain], ldapmaster2.[domain], ldap-vip.[domain] (Subject included in alt name list as some clients - like firefox - ignore the subject if alt names exist - dumb IMNSHO.) Then the servers use the same cert to sync w/ each other as the clients use to connect to the VIP (or if needed, directly to the ldapmaster servers). The subjectAltName part of a cert is the 'tricky' part I think you're missing knowledge of. A wildcard cert works too, but then it'd be valid for any host *.[domain]. Not the most secure setup. - 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: Daniel Qian <daniel(a)up247solution.com> To: Chris Jacobs Cc: 'openldap-technical(a)openldap.org' <openldap-technical(a)openldap.org> Sent: Fri Aug 26 13:35:10 2011 Subject: Re: Syncrepl over TLS for mirrormode 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<mailto:chris.jacobs@apollogrp.edu> ________________________________ From: openldap-technical-bounces(a)OpenLDAP.org<mailto:openldap-technical-bounces@OpenLDAP.org> <openldap-technical-bounces(a)OpenLDAP.org><mailto:openldap-technical-bounces@OpenLDAP.org> To: openldap-technical(a)openldap.org<mailto:openldap-technical@openldap.org> <openldap-technical(a)openldap.org><mailto:openldap-technical@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, nor with 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. ________________________________ 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, 2 months

openldap-technical search results for query "starttls"