Search results for "starttls" - openldap-technical

Re: ppolicy overlay - not seeming to function?

by Howard Chu

John Cooter wrote: > So, before I ask my question, here are my referenced objects, from a "slapcat -n 0": > dn: olcDatabase={2}hdb,cn=config > objectClass: olcDatabaseConfig > objectClass: olcHdbConfig > olcDatabase: {2}hdb > olcDbDirectory: /var/lib/ldap > olcDbIndex: objectClass eq,pres > olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub > structuralObjectClass: olcHdbConfig > entryUUID: eb941fcc-bef3-1036-9d74-0d6e032eb747 > creatorsName: cn=config > createTimestamp: 20170426174545Z > olcAccess: {0}to dn.base="" by self write by dn="cn=ldapadmin,dc=XXXXXXX > ,dc=net" write by * read > olcAccess: {1}to * by self write by dn="cn=ldapadmin,dc=XXXXXXX,dc=net" w > rite by * read > olcAccess: {2}to dn.subtree="ou=mail,ou=hosting,dc=XXXXXXX,dc=net" attrs= > userPassword,UseAppPassword,children,entry,objectClass,cn,sn,uid by self w > rite by dn="cn=ldapadmin,dc=XXXXXXX,dc=net" write by * auth by * read > olcSuffix: dc=XXXXXXXX,dc=net > olcRootDN: cn=ldapadmin,dc=XXXXXXX,dc=net > olcRootPW:: e1NTSEF9K2p6YnhXL0xQTDJKZFFIZitac3l6RzVXaEN3UEhQUkc= > entryCSN: 20170508155547.001404Z#000000#000#000000 > modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > modifyTimestamp: 20170508155547Z > > dn: olcOverlay={0}ppolicy,olcDatabase={2}hdb,cn=config > objectClass: olcOverlayConfig > objectClass: olcPPolicyConfig > olcOverlay: {0}ppolicy > olcPPolicyDefault: cn=passwordDefault,ou=policies,dc=XXXXXXX,dc=net > olcPPolicyHashCleartext: FALSE > olcPPolicyUseLockout: FALSE > olcPPolicyForwardUpdates: FALSE > structuralObjectClass: olcPPolicyConfig > > the passwordDefaul policy exists in the correct location, and appears to apply to all user objects BUT > > when I change a user object to a value that either violates the base policy (say, has only 4 characters instead of 5 or more), or would not conform to the check_password.so function, as established by various outside sources, it does not give me an error of any kind, and instead, writes the password to the DB and writes the following to the log: Reread the slapo-ppolicy(5) manpage. You're making modifications using the rootDN, which is documented to ignore any configured policies. > May 10 11:00:05 ldapv slapd[1984]: conn=1007 op=0 EXT oid=1.3.6.1.4.1.1466.20037 > May 10 11:00:05 ldapv slapd[1984]: conn=1007 op=0 STARTTLS > May 10 11:00:05 ldapv slapd[1984]: conn=1007 op=0 RESULT oid= err=0 text= > May 10 11:00:06 ldapv slapd[1984]: conn=1007 fd=11 TLS established tls_ssf=256 ssf=256 > May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=1 BIND dn="cn=ldapadmin,dc=XXXXXXX,dc=net" method=128 > May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=1 BIND dn="cn=ldapadmin,dc=XXXXXXX,dc=net" mech=SIMPLE ssf=0 > May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=1 RESULT tag=97 err=0 text= > May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=2 MOD dn="uid=USER,cn=TESTDOMAIN.com,ou=domain,ou=mail,ou=hosting,dc=XXXXXXX,dc=net" > May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=2 MOD attr=userPassword > May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=2 RESULT tag=103 err=0 text= > > And the entry, as referenced by phpLDAPadmin, appears to correspond to the "bad" password. How can I go about confirming that the password policy is being enforced? Bind as a regular user identity instead of the rootDN when making a change. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

8 years, 1 month

Re: fedora and openldap

by Rich Megginson

On 04/12/2011 01:14 PM, Judith Flo Gaya wrote: > Hello Quanah, > > > On 4/12/11 7:28 PM, Quanah Gibson-Mount wrote: >> --On Tuesday, April 12, 2011 7:10 PM +0200 Judith Flo >> Gaya<jflo(a)imppc.org> >> wrote: >>> ( I installed a newer version of openldap in my server as the RH6 >>> uses an >>> old one, I compiled it with tls and openssl) >>> >>> From the client I do : >>> ldapsearch -x -ZZ -d1 -h curri0.imppc.local:636 >> This is a startTLS request. You are using LDAPS. This will never work. >> >> Try >> >> ldapsearch -x -H ldaps://curri0.imppc.local:636/ > > It doesn't work either, still complains about not being able to > contact the server. > But now I see a different error: > > ldapsearch -x -H ldaps://curri0.imppc.local:636 -d1 > ldap_url_parse_ext(ldaps://curri0.imppc.local:636) > ldap_create > ldap_url_parse_ext(ldaps://curri0.imppc.local:636/??base) > ldap_sasl_bind > ldap_send_initial_request > ldap_new_connection 1 1 0 > ldap_int_open_connection > ldap_connect_to_host: TCP curri0.imppc.local:636 > ldap_new_socket: 3 > ldap_prepare_socket: 3 > ldap_connect_to_host: Trying 172.19.5.13:636 > ldap_pvt_connect: fd: 3 tm: -1 async: 0 > TLS: could not initialize moznss using security dir > /etc/openldap/cacerts - error -8174:Unknown code ___f 18. > TLS: could not add the certificate (null) - error -8192:Unknown code > ___f 0. > TLS: error: connect - force handshake failure -1 - error -8054:Unknown > code ___f 138 > TLS: can't connect: . > ldap_err2string > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) If you are using /usr/bin/ldapsearch on Fedora 14 and later, it is linked with Mozilla NSS instead of openssl. But openldap with moznss works the same as it does with openssl. Do you have your CA cert on the client machine? If so, did you specify it in /etc/openldap/ldap.conf or ~/.ldaprc? If not, you can also specify it on the command line like this: LDAPTLS_CACERT=/path/to/ca_cert.pem ldapsearch -x -H ldaps://curri0.imppc.local:636/ See http://www.openldap.org/faq/data/cache/1514.html for information about how to use Mozilla NSS. > > > and this is what the server says: > slap_listener_activate(8): > >>> slap_listener(ldaps://curri0.imppc.local:636) > connection_get(12): got connid=1008 > connection_read(12): checking for input on id=1008 > TLS trace: SSL_accept:before/accept initialization > TLS trace: SSL_accept:SSLv3 read client hello A > TLS trace: SSL_accept:SSLv3 write server hello A > TLS trace: SSL_accept:SSLv3 write certificate A > TLS trace: SSL_accept:SSLv3 write server done A > TLS trace: SSL_accept:SSLv3 flush data > TLS trace: SSL_accept:error in SSLv3 read client certificate A > TLS trace: SSL_accept:error in SSLv3 read client certificate A > connection_get(12): got connid=1008 > connection_read(12): checking for input on id=1008 > TLS trace: SSL3 alert read:fatal:bad certificate > TLS trace: SSL_accept:failed in SSLv3 read client certificate A > TLS: can't accept: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 > alert bad certificate. > connection_read(12): TLS accept failure error=-1 id=1008, closing > connection_close: conn=1008 sd=12 > > any clue? the error on the client side seems to indicate that the > client is trying to use the nss from the mozilla but I never meant to > this, openssl is installed. > Thanks a lot for your help. > j >> instead. >> >> --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 >

14 years, 1 month

Re: Problem getting monitor backend and syncrepl overlay to work

by Benjamin Griese

Hi david, i'm not sure about that, by havn't figured out why the credentials have to be in cleartext, but that was only possibility I got syncrepl working since I tried it with SSHA or MD5 prefixes. Did you tried that in cleartext? just my two bucks and a half benjamin On Wed, Mar 10, 2010 at 10:01, DeMoNs(a)web.de <DeMoNs(a)web.de> wrote: > Hi all, > > i have a problem getting openldap to run monitor backend AND syncrepl > overlay. > i'm running freebsd-7.2-release-p6 in combination with > openldap-server-2.4.19 with sasl support compiled in. > > i use the following slapd config: > > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > include /usr/local/etc/openldap/schema/nis.schema > include /usr/local/etc/openldap/schema/inetorgperson.schema > include /usr/local/etc/openldap/schema/misc.schema > include /usr/local/etc/openldap/schema/ldapns.schema > include /usr/local/etc/openldap/schema/radius.schema > > pidfile /var/run/openldap/slapd.pid > argsfile /var/run/openldap/slapd.args > logfile /var/log/slapd.log > > password-hash {SSHA} > modulepath /usr/local/libexec/openldap > moduleload back_bdb > moduleload back_monitor > > access to dn.base="" by * read > access to dn.base="cn=Subschema" by * read > access to * > by ssf=128 dn="cn=admin,dc=example,dc=de" write > by dn="cn=admin,dc=example,dc=de" peername.ip=127.0.0.1 write > by ssf=96 dn="cn=nssadmin,dc=example,dc=de" read > by dn="cn=nssadmin,dc=example,dc=de" peername.ip=127.0.0.1 read > by anonymous auth > by * none > access to attrs=userPassword > by self write > by anonymous auth > by * none > > database bdb > suffix "dc=example,dc=de" > rootdn "dc=example,dc=de" > directory /var/db/openldap-data > index objectClass,entryCSN,entryUUID eq > index uid pres,eq,sub > index memberUID eq > index uidNumber,gidNumber eq > index host eq > > database monitor > rootdn "cn=monitoring,cn=Monitor" > rootpw monitoring > > access to dn.subtree="cn=Monitor" > by dn="cn=nssadmin,dc=example,dc=de" > by * none > > syncrepl rid=041 > provider=ldap://ldap-master.example.de > type=refreshOnly > interval=00:00:35:00 > searchbase="dc=example,dc=de" > schemachecking=off > bindmethod=simple > starttls=yes > binddn="cn=syncuser,dc=example,dc=de" > credentials="strongsecretpassword" > > TLSCertificateFile /usr/local/etc/openldap/ssl/ldap-crt.pem > TLSCertificateKeyFile /usr/local/etc/openldap/ssl/ldap-key.pem > TLSCACertificateFile /usr/local/etc/openldap/ssl/cacert.pem > > loglevel 256 > > now, when i run slaptest i receive following error: > > /usr/local/etc/openldap/slapd.conf: line 59: database monitor does not > support operations required for syncrepl > slaptest: bad configuration file! > > Line 59 corresponds to the credentials option in the synrepl statement. > i can't figure out whats wrong, so if anyone can point me in the right > direction that would be really helpful. > > thanks in advance, > david > -- 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, 3 months

Re: Replication issues with openldap 2.5 {resolved}

by Ulises Gonzalez Horta

Thank you very much to all that read this thread, but especially to those replied and provided any guidance, I/We fixed the issue, the problem was caused by this default ACL {0}to attrs=userPassword by self write by anonymous auth by * none It default "stop" was avoiding that my replication user read the userPassword attribute for other users, hence the attribute was not being replicated, and for some reason if that attribute is not present and you try to authenticate a user then slapd does not produce too many logs, it only returns error 49. Thank you all and happy new year Ulises Gonzalez Horta Lead Linux Engineer C: 786 450 2970/ 240 727 6267 E: ugonzalezhorta(a)breezeline.com <jsutherland1(a)breezeline.com> On Thu, Jan 2, 2025 at 11:59 AM Stefan Kania <stefan(a)kania-online.de> wrote: > Did you test the access to the attribute with slapacl? "slapacl -D > dn=search-user,ou=users... -b cn=object-to-check,ou=.... userPassword" > > > Am 02.01.25 um 15:37 schrieb Ulises Gonzalez Horta: > > Hi Shawn > > > > After closely inspecting both/all entries with slapcat on each of the > > servers I confirmed that all the user entries are being replicated - > > except- for the userPassword one. > > So it looks like we found the issue. > > > > Question is how to fix it, why is it not replicating the userPassword > > attribute? > > > > I have removed my filter entry from my olcSyncrepl, now it looks like > this > > > > olcSyncrepl: {0}rid=100 provider=ldap://master:389 type=refr > > eshOnly interval=00:00:05:00 retry="300 +" > > searchbase="dc=metrocast,dc=net" t > > imelimit=unlimited sizelimit=unlimited bindmethod=simple > > binddn="cn=repl,ou=boxes,dc=metrocast,dc=net" credentials="aaa" starttls > > =critical tls_cacertdir="/etc/ldap/certs" > > > > But still not replicating the userPassword attribute, any clue?? > > > > Thanks in advance > > > > > > > > Ulises Gonzalez Horta > > > > Lead Linux Engineer > > > > C: 786 450 2970/ 240 727 6267 > > > > E:ugonzalezhorta@breezeline.com <mailto:jsutherland1@breezeline.com> > > > > > > > > On Wed, Jan 1, 2025 at 12:52 PM Shawn McKinney <smckinney(a)symas.com > > <mailto:smckinney@symas.com>> wrote: > > > > > > > On Dec 31, 2024, at 9:08 AM, Ulises Gonzalez Horta > > <ugonzalezhorta(a)breezeline.com > > <mailto:ugonzalezhorta@breezeline.com>> wrote: > > > > > > Hi and happy new year. > > > > > > I was checking to see if a bad acl could be the cause here, after > > enabling all logs including -1 level, I still did not get anything > > useful on syslog. > > > > > > So I went this route > > > I get my slave server, removed the config for oldSyncRepl and > > olcUpdateref, stopped slapd, removed the database, and loaded a > > backup, then started slapd, then attempted the queries and it > > worked fine > > > > Hello, > > > > Have you tried slapcat on that entry on both instances, comparing > > the results to ensure they match? > > > > Also, are password policies enabled? > > > > Your earlier question about which log level for ACL's: > > > > man slapd.conf > > > > … > > > > 128 (0x80 ACL) access control list processing > > > > — > > Shawn >

5 months, 1 week

RE: [EXT] Re: Replication issues with openldap 2.5 {resolved}

by Windl, Ulrich

Hi! Makes me wonder: How much does a “no UserPassword – cannot authenticate” error message cost, and how much time will it save? 😉 Kind regards, Ulrich From: Ulises Gonzalez Horta <ugonzalezhorta(a)breezeline.com> Sent: Thursday, January 2, 2025 6:57 PM To: Stefan Kania <stefan(a)kania-online.de> Cc: openldap-technical(a)openldap.org Subject: [EXT] Re: Replication issues with openldap 2.5 {resolved} Thank you very much to all that read this thread, but especially to those replied and provided any guidance, I/We fixed the issue, the problem was caused by this default ACL {0}to attrs=userPassword by self write by anonymous auth by * none It default "stop" was avoiding that my replication user read the userPassword attribute for other users, hence the attribute was not being replicated, and for some reason if that attribute is not present and you try to authenticate a user then slapd does not produce too many logs, it only returns error 49. Thank you all and happy new year Ulises Gonzalez Horta Lead Linux Engineer C: 786 450 2970/ 240 727 6267 E: ugonzalezhorta(a)breezeline.com<mailto:jsutherland1@breezeline.com> On Thu, Jan 2, 2025 at 11:59 AM Stefan Kania <stefan(a)kania-online.de<mailto:stefan@kania-online.de>> wrote: Did you test the access to the attribute with slapacl? "slapacl -D dn=search-user,ou=users... -b cn=object-to-check,ou=.... userPassword" Am 02.01.25 um 15:37 schrieb Ulises Gonzalez Horta: > Hi Shawn > > After closely inspecting both/all entries with slapcat on each of the > servers I confirmed that all the user entries are being replicated - > except- for the userPassword one. > So it looks like we found the issue. > > Question is how to fix it, why is it not replicating the userPassword > attribute? > > I have removed my filter entry from my olcSyncrepl, now it looks like this > > olcSyncrepl: {0}rid=100 provider=ldap://master:389 type=refr > eshOnly interval=00:00:05:00 retry="300 +" > searchbase="dc=metrocast,dc=net" t > imelimit=unlimited sizelimit=unlimited bindmethod=simple > binddn="cn=repl,ou=boxes,dc=metrocast,dc=net" credentials="aaa" starttls > =critical tls_cacertdir="/etc/ldap/certs" > > But still not replicating the userPassword attribute, any clue?? > > Thanks in advance > > > > Ulises Gonzalez Horta > > Lead Linux Engineer > > C: 786 450 2970/ 240 727 6267 > > E:ugonzalezhorta@breezeline.com<mailto:E%3Augonzalezhorta@breezeline.com> <mailto:jsutherland1@breezeline.com<mailto:jsutherland1@breezeline.com>> > > > > On Wed, Jan 1, 2025 at 12:52 PM Shawn McKinney <smckinney(a)symas.com<mailto:smckinney@symas.com> > <mailto:smckinney@symas.com<mailto:smckinney@symas.com>>> wrote: > > > > On Dec 31, 2024, at 9:08 AM, Ulises Gonzalez Horta > <ugonzalezhorta(a)breezeline.com<mailto:ugonzalezhorta@breezeline.com> > <mailto:ugonzalezhorta@breezeline.com<mailto:ugonzalezhorta@breezeline.com>>> wrote: > > > > Hi and happy new year. > > > > I was checking to see if a bad acl could be the cause here, after > enabling all logs including -1 level, I still did not get anything > useful on syslog. > > > > So I went this route > > I get my slave server, removed the config for oldSyncRepl and > olcUpdateref, stopped slapd, removed the database, and loaded a > backup, then started slapd, then attempted the queries and it > worked fine > > Hello, > > Have you tried slapcat on that entry on both instances, comparing > the results to ensure they match? > > Also, are password policies enabled? > > Your earlier question about which log level for ACL's: > > man slapd.conf > > … > > 128 (0x80 ACL) access control list processing > > — > Shawn

5 months, 1 week

RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)

by Quanah Gibson-Mount

For this testing call, we particularly need folks to test OpenLDAP with startTLS/LDAPS when compiled against OpenSSL (both pre 1.1 series and with the 1.1 series). There is currenly nothing in the test suite that covers encrypted connections (Although it's on my todo list). To build against OpenSSL 1.1 may also require cyrus-sasl HEAD out of the cyrus-sasl GIT repository, depending on your build options as the current cyrus-sasl release does not support the OpenSSL 1.1 series. It can be found at <https://github.com/cyrusimap/cyrus-sasl>. If you build with GSSAPI and use Heimdal, you will also need the Heimdal 7.1.0 or later release (as that is where OpenSSL 1.1 support was added). It can be obtained from <http://h5l.org/>. Also new with this release is the ability to run "make its" in the tests/ directory. This will run a specific set of tests around past bugs to ensure there are no regressions. While I've tested this with modular openldap builds, it has not been tested with the modules and backends built into slapd, so there could be some issues in that scenario. Generally, get the code for RE24: <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…> Configure & build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its run through the regression suite. Thanks! OpenLDAP 2.4.45 Engineering Added slapd support for OpenSSL 1.1.0 series (ITS#8353, ITS#8533) Fixed libldap handling of Diffie-Hellman parameters (ITS#7506) Fixed libldap GnuTLS use after free (ITS#8385) Fixed slapd sasl SEGV rebind in same session (ITS#8568) Fixed slapd syncrepl filter handling (ITS#8413) Fixed slapd syncrepl infinite looping mods with delta-sync MMR (ITS#8432) Fixed slapd callback struct so older modules without writewait should function. Custom modules may need to be updated for sc_writewait callback (ITS#8435) Fixed slapd-mdb so it passes ITS6794 regression test (ITS#6794) Fixed slapd-meta uninitialized diagnostic message (ITS#8442) Fixed slapo-accesslog to honor pauses during purge for cn=config update (ITS#8423) Fixed slapo-relay to correctly initialize sc_writewait (ITS#8428) Build Environment Added test065 for proxyauthz (ITS#8571) Fix test008 to be portable (ITS#8414) Fix its4336 regression test (ITS#8534) Fix its4337 regression test (ITS#8535) Fix regression tests to execute on all backends (ITS#8539) Contrib Added slapo-autogroup(5) man page (ITS#8569) Added passwd missing conversion scripts for apr1 (ITS#6826) Fixed contrib modules where the writewait callback was not correctly initialized (ITS#8435) Fixed smbk5pwd to build with newer OpenSSL releases (ITS#8525) Documentation admin24 fixed tls_cipher_suite bindconf option (ITS#8099) admin24 fixed typo cn=config to be slapd.d (ITS#8449) Fixed slapd-config(5), slapd.conf(5) clarification on interval keyword for refreshAndPersist (ITS#8538) Fixed slapo-ppolicy(5) to clearly note rootdn requirement (ITS#8565) Fixed various minor grammar issues in the man pages (ITS#8544) LMDB 0.9.20 Release Engineering Fix mdb_load with escaped plaintext (ITS#8558) Fix mdb_cursor_last / mdb_put interaction (ITS#8557) LMDB 0.9.19 Release (2016/12/28) Fix mdb_env_cwalk cursor init (ITS#8424) Fix robust mutexes on Solaris 10/11 (ITS#8339) Tweak Win32 error message buffer Fix MDB_GET_BOTH on non-dup record (ITS#8393) Optimize mdb_drop Fix xcursors after mdb_cursor_del (ITS#8406) Fix MDB_NEXT_DUP after mdb_cursor_del (ITS#8412) Fix mdb_cursor_put resetting C_EOF (ITS#8489) Fix mdb_env_copyfd2 to return EPIPE on SIGPIPE (ITS#8504) Fix mdb_env_copy with empty DB (ITS#8209) Fix behaviors with fork (ITS#8505) Fix mdb_dbi_open with mainDB cursors (ITS#8542) Fix robust mutexes on kFreeBSD (ITS#8554) Fix utf8_to_utf16 error checks (ITS#7992) Fix F_NOCACHE on MacOS, error is non-fatal (ITS#7682) Build Make shared lib suffix overridable (ITS#8481) Documentation Cleanup doxygen nits Note reserved vs actual mem/disk usage --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

8 years, 4 months

RE: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)

by Quanah Gibson-Mount

--On Thursday, February 02, 2017 1:01 PM -0800 "Paul B. Henson" <henson(a)acm.org> wrote: >> From: Quanah Gibson-Mount >> Subject: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20) >> >> For this testing call, we particularly need folks to test OpenLDAP with >> startTLS/LDAPS when compiled against OpenSSL (both pre 1.1 series and >> with the 1.1 series). > > Compiled successfully with Gentoo linux and openSSL 1.02j/cyrus-sasl > 2.1.26, configured as: > > --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu > --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share > --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking > --disable-silent-rules --libdir=/usr/lib64 > --libexecdir=/usr/lib64/openldap --disable-static --enable-ldap > --enable-slapd --enable-bdb --enable-hdb --enable-dnssrv=mod > --enable-ldap=mod --enable-mdb=mod --enable-meta=mod --enable-monitor=mod > --enable-null=mod --enable-passwd=mod > --enable-relay=mod --enable-shell=mod --enable-sock=mod --disable-perl > --disable-sql --disable-crypt --disable-slp --disable-lmpasswd > --enable-syslog --enable-aci --enable-cleartext --enable-modules > --enable-rewrite --enable-rlookups --enable-slapi --enable-syncprov=yes > --enable-overlays=mod --enable-ipv6 --with-cyrus-sasl --enable-spasswd > --disable-wrappers --with-tls=openssl --enable-dynamic --enable-local > --enable-proctitle --enable-shared > > make test completed successfully, is there any particular way to verify > all the tests were okay? Does the make itself fail if any of the tests > do, I did not see a summary at the end. make its was not as happy: "make test" will do a single pass through the entire test suite, for each backend. Unfortunately, that does not always catch issues. For example, the issue Dieter reported against HEAD with test061 only happens to me occassionaly. To help with that, there is the abilty to run the test suite in a loop, for a given backend. Like: quanah@ub16:~/openldap-2.4.45RC/tests$ ./run -l 500 -b mdb test061 Will run test061 500 times, using back-mdb as the backend. Instead of a specific test, one can do "all" to run everything through a loop X times. >>>>>> Starting its4326 ... > running defines.sh > Running slapadd to build slapd database... > Starting slapd on TCP/IP port 9011... > Using ldapsearch to check that slapd is running... > Starting proxy slapd on TCP/IP port 9012... > Using ldapsearch to check that proxy slapd is running... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > ldapsearch failed (255)! > ./data/regressions/its4326/its4326: line 93: kill: (28780) - No such > process >>>>>> ./data/regressions/its4326/its4326 failed (exit 255) Interesting... it may be worthwhile to look in the testrun directory and see why slapd failed to launch. I'll see if I can reproduce it as well. > I see the fix for ITS8432 is included in this release (yay); I was > wondering if you've had any luck tracking down the underlying issue > behind ITS8444? So far I still haven't seen any corruption or operational > issues from it, but the rampant noise in the logs and errors being > generated are quite disconcerting :). Plus they will potentially mask any > errors that are actually indicative of a real problem. I've not been able to reproduce it. There's a regression test I wrote for it included in the RE24 source, but it's never really triggered for me. Please feel free to look it over and see if I've missed anything obvious in my reproduction attempts. :) You can execute it directly with ./run -b mdb its8444 --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

8 years, 4 months

Re: Security between server and client nodes.

by Raffael Sahli

On 11/30/2011 01:48 PM, Jayavant Patil wrote: > > > >>On 11/30/2011 08:01 AM, Jayavant Patil wrote: > >> > >> > >> On Tue, Nov 29, 2011 at 6:26 PM, Jayavant Patil > >> <jayavant.patil82(a)gmail.com <mailto:jayavant.patil82@gmail.com> > <mailto:jayavant.patil82@gmail.com > <mailto:jayavant.patil82@gmail.com>>> wrote: > >> > >> > >> >>Mon, 28 Nov 2011 11:25:16 +0100 Raffael Sahli > >> <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com> > <mailto:public@raffaelsahli.com <mailto:public@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? > >> > >On Wed, 30 Nov 2011 08:38:32 +0100 Raffael Sahli > <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>> wrote: > >Yes, that's exactly the rule I wrote above. > > >access to filter=(objectClass= > >simpleSecurityObject) > > by self read > > by * none > > > >Maybe you have to change the objectClass to posixAccount, or both or > >whatever.... > > >access to > >filter=(|(objectClass=simpleSecurityObject)(objectClass=posixAccount)) > > by self read > > by * none > > > >Just add this rule before the global rule "access to *" > > > >>ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b > >>"ou=People,dc=abc,dc=com" "uid=ldap_7" > > >And if you search like this with bind "admin dn", you will see every > >object.... > >You have to bind with user ldap_6 and not with root > But anyway client user knows the admin dn and rootbindpassword. So, > with this he will look into all directory information to which he is > not supposed to do. > e.g. ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -w cluster > > So, how to avoid this? > Why client user knows the admin dn and pw???????? > > > -- > > Thanks & Regards, > Jayavant Ningoji Patil > Engineer: System Software > Computational Research Laboratories Ltd. > Pune-411 004. > Maharashtra, India. > +91 9923536030. > -- Raffael Sahli public(a)raffaelsahli.com

13 years, 6 months

Re: client server connection to LDAP/Kerberos

by Dan White

On 02/01/13 10:08 +1100, Asmaa Ahmed wrote: >Hello, > >I recently added Kerberos authentication to my LDAP server, and I am trying >to connect the other servers to it. >I have a server running Davical shared calendar, and I hope to get it >working with my LDAP server again after Kerberos integration. > >Here is my configuration which was working before the integration and my >source is >"http://wiki.davical.org/w/Configuration/LDAP#Kerberos_Authentication" > > $c->authenticate_hook['config'] = array( > 'host' => 'ldap.domain.com', //host name of your LDAP Server > 'port' => '389', //port >// 'bindDN' => 'cn=admin,dc=domain,dc=com', //DN to bind request >// to this server (if required) >// 'passDN' => 'password', //Password of request bind > 'baseDNUsers' => 'ou=People,dc=domain,dc=com', //where to look for >valid user > 'filterUsers' => 'objectClass=*', //filter which must validate a user >according to RFC4515, i.e. surrounded by brackets > 'protocolVersion' => 3, // important for simple auth (no sasl) >// 'startTLS' => true, // securing your LDAP connection > 'i_use_mode_kerberos' => "i_know_what_i_am_doing", > >My slapd error logs: >Jan 31 23:40:00 ldap slapd[1059]: conn=1273 fd=43 ACCEPT from >IP=203.28.247.193:56887 (IP=0.0.0.0:389) >Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=0 BIND dn="" method=128 >Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=0 RESULT tag=97 err=0 text= >Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=1 SRCH >base="ou=People,dc=domain,dc=com" scope=2 deref=0 filter="(objectClass=*)" >Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=1 SRCH attr=uid >modifyTimestamp cn mail >Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=1 SEARCH RESULT tag=101 >err=32 nentries=0 text= >Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=2 UNBIND > >My OLC configuration: >root@ldap:/var/log# ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config >"(|(cn=config)(olcDatabase={1}hdb))" >dn: cn=config >objectClass: olcGlobal >cn: config >olcArgsFile: /var/run/slapd/slapd.args >olcAuthzRegexp: {0}uid=([^,]+),cn=domain.com,cn=gssapi,cn=auth uid=$1 > ,ou=people,dc=domain,dc=com >olcLogLevel: stats >olcPidFile: /var/run/slapd/slapd.pid >olcSaslRealm: DOMAIN.COM >olcToolThreads: 1 > >dn: olcDatabase={1}hdb,cn=config >objectClass: olcDatabaseConfig >objectClass: olcHdbConfig >olcDatabase: {1}hdb >olcDbDirectory: /var/lib/ldap >olcSuffix: dc=domain,dc=com >olcAccess: {0}to attrs=userPassword,shadowLastChange by anonymous auth by * >no > ne >olcAccess: {1}to dn.subtree="ou=krb5,dc=domain,dc=com" by dn="c > n=adm-srv,ou=krb5,domain,dc=com" write by dn="cn=kdc-srv,ou > =krb5,domain,dc=com" read by * none >olcAccess: {2}to attrs=loginShell,gecos by self write by users read by * >none >olcAccess: {3}to dn.base="" by * read >olcAccess: {4}to * by users read by * none >olcLastMod: TRUE >olcRootDN: uid=admin,ou=people,domain,dc=com > > >Any suggestion to fix the binding and get my search working again with >kerberos authentication ? > >Thanks. Can you reproduce this problem with ldapsearch and/or ldapwhoami (-Y GSSAPI) on the server which is running davical? -- Dan White

12 years, 4 months

Re: Syncrepl N-Way multimaster replication - Configuration issue on Rhel6

by coma

Hello Ulrich, thank you very much for your prompt reply. Sorry, it was a copy/paste error, i've added the port in the URI but it made no difference whatever I do (test other port, test with default port...), error "read_config: no serverID / URL match found." was always present. But today i've solved the issue by upgrading my servers and reboot them, but for the moment i' don't understand what was exactly the cause, maybe a conflict on name resolution, error messages in debug mode point in this direction (getaddrinfo() failed even the host is existing and resolved by DNS). About my second issue, it was a stupid mistake from my part, slapd was listening only on localhost due to an entry in /etc/hosts (i added my server name as alias of 127.0.0.1). Thanks you again, Regards, 2014-11-28 8:42 GMT+01:00 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de>: > >>> coma <coma.inf(a)gmail.com> schrieb am 27.11.2014 um 17:18 in Nachricht > <CABnSCoknUmvmY_eJPac9mDqsWcja57b8W_1gT09VFZv0=ncFpA(a)mail.gmail.com>: > > 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 > > Why didn't you add the port to your URI? You should have known that with a > non-default port at least your URI won't match your server's configuration. > Same for ldap: vs ldaps: I guess. > > > > > 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. > > How do your certificates look like? > > > Regards, > Ulrich > > > > > Can you please help me on this? > > > > Thanks in advance, > > > >

10 years, 6 months

openldap-technical search results for query "starttls"