Search results for "starttls" - openldap-technical

lloadd Proxied Authorization Denied (123)

by Stefan Kania

I now took the example configuration and changed it to my settings: --------------------- TLSCertificateFile /opt/symas/etc/openldap/example-net-cert.pem TLSCertificateKeyFile /opt/symas/etc/openldap/example-net-key.pem TLSCACertificateFile /opt/symas/etc/openldap/cacert.pem pidfile /var/symas/run/slapd.pid argsfile /var/symas/run/slapd.args loglevel 256 modulepath /opt/symas/lib/openldap moduleload lloadd.la backend lload listen "ldap://:1389 ldaps://:1636" feature proxyauthz TLSShareSlapdCTX true bindconf bindmethod=simple network-timeout=5 tls_cacert="/opt/symas/etc/openldap/cacert.pem" tls_cert="/opt/symas/etc/openldap/example-net-cert.pem" tls_key="/opt/symas//etc/openldap/example-net-key.pem" binddn=uid=lloadd,ou=users,dc=example,dc=net credentials=geheim tier roundrobin backend-server uri=ldaps://ldap01.example.net starttls=critical retry=5000 max-pending-ops=50 conn-max-pending=10 numconns=10 bindconns=5 backend-server uri=ldaps://ldap02.example.net starttls=critical retry=5000 max-pending-ops=50 conn-max-pending=10 numconns=10 bindconns=5 database monitor --------------------- The bind-user exists in the database of the backend-server. If i start the loadbalancer I can see that the connection are established. -------ldap01----------- Dez 14 21:07:12 ldap01 slapd[550]: conn=1380 fd=46 ACCEPT from IP=192.168.56.40:38674 (IP=0.0.0.0:636) Dez 14 21:07:12 ldap01 slapd[550]: conn=1380 fd=46 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384 Dez 14 21:07:12 ldap01 slapd[550]: conn=1380 op=0 BIND dn="uid=lloadd,ou=users,dc=example,dc=net" method=128 Dez 14 21:07:12 ldap01 slapd[550]: conn=1380 op=0 BIND dn="uid=lloadd,ou=users,dc=example,dc=net" mech=SIMPLE bind_ssf=0 ssf=256 ------------------------ I see the same massages on ldap02, so that's ok The I do a search from a different machine: ------------- root@ldap03:~# ldapsearch -x -D uid=repl-user,ou=users,dc=example,dc=net -w geheim -H ldaps://loadbalancer.example.net:1636 -LLL Proxied Authorization Denied (123) Additional information: not authorized to assume identity ------------ The uid=repl-user has read permission to all objects and attributes. On ldap01 I see: ---------ldap01------------- Dez 14 21:09:13 ldap01 slapd[550]: conn=1371 op=0 BIND dn="uid=repl-user,ou=users,dc=example,dc=net" method=128 Dez 14 21:09:13 ldap01 slapd[550]: conn=1371 op=0 BIND dn="uid=repl-user,ou=users,dc=example,dc=net" mech=SIMPLE bind_ssf=0 ssf=256 Dez 14 21:09:13 ldap01 slapd[550]: conn=1371 op=0 RESULT tag=97 err=0 qtime=0.000033 etime=0.015255 text= ----------------------------- on ldap02 --------ldap02---------- Dez 14 21:09:13 ldap02 slapd[300]: conn=1306 op=1 SEARCH RESULT tag=101 err=123 qtime=0.000044 etime=0.000235 nentries=0 text=not authorized to assume identity Dez 14 21:09:13 ldap02 slapd[300]: conn=1306 op=1 do_search: get_ctrls failed ------------------------ Why do I get different log-entries on the backend-server? And what did I forgot? When I do a ldapsearch with uid=lloadd I get: ------------------- root@ldap03:~# ldapsearch -x -D uid=lloadd,ou=users,dc=example,dc=net -w geheim -H ldaps://loadbalancer.example.net:1636 -LLL dn: dc=example,dc=net objectClass: domain objectClass: dcObject dc: example ------------------- That's the only object the user has permissions to read. log from ldap01 -------------------- Dez 14 21:14:04 ldap01 slapd[550]: conn=1381 op=0 BIND dn="uid=lloadd,ou=users,dc=example,dc=net" method=128 Dez 14 21:14:04 ldap01 slapd[550]: conn=1381 op=0 BIND dn="uid=lloadd,ou=users,dc=example,dc=net" mech=SIMPLE bind_ssf=0 ssf=256 Dez 14 21:14:04 ldap01 slapd[550]: conn=1381 op=0 RESULT tag=97 err=0 qtime=0.000021 etime=0.008984 text= -------------------- and log from ldap02 -------------------- Dez 14 21:14:04 ldap02 slapd[300]: conn=1308 op=1 SRCH base="dc=example,dc=net" scope=2 deref=0 filter="(objectClass=*)" Dez 14 21:14:04 ldap02 slapd[300]: conn=1308 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000022 etime=0.002048 nentries=1 text= -------------------- That's also ok, I think . The final version should be that the binduser uid=lloadd will not see anything. So what's the point I'm missing to get proxyauthz work correctly?

2 years, 6 months

Re: Ldap problems in paradise, working with suse 12.1 miles stone 5

by Ralf Haferkamp

Am Mittwoch 21 Dezember 2011, 15:00:24 schrieb John Tobin: > Dear Ralf, > > Hi, I hope you are still here before the holidays, I would appreciate > your advice and counsel. > I have Suse 12.1 up, mile stone 5. It works well. The final 12.1 release is out since almost 6 weeks, you should really update to that. > I have installed and used ldap 2.4.26. > It is also working with nss_ldap code. > I am having some trouble on 2 counts. > First I tried to get start_tls, and / or ldaps to work in that > environment. I have not gotten tls to work. Was this tested at all in > SUSE? yes > TLS is critical to some success in the university lab I am > running over here. > I have posted the problem to the open ldap crew, and have heard nothing > from anyone for solving the problem, or even assistance in how to > debug it, or understand the failure I get.....[this is from nss_ldap] > > >> 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 > > In the middle of this mess Chris wood mentioned this would be easier, > and may well work under nslcd. While nslcd certainly has some advantanges compared to nss_ldap, I can't imagine why switching to nscld would make the base SSL/TLS setup easier. Does ldapsearch with TLS work for you? Please test as a non-root user. If it doesn't work adding the "-d -1" option might give you a hint why it is not able to connect. Also check the permissions of the CA certificate, everybody needs read access to them. The server-cert and server-key as to be readable by the user as which slapd is running. Are you running AppArmor, then make sure that your current profile doesn't block read access to the relevant files. As you didn't give much details about your configuration I can only give you those general hints. If you think you hit a bug in openSUSE, feel free to open a bug report (with all your relevant configuration files and log files) at bugzilla.novell.com. > OK. > I installed nslcd.... I have the lastest I believe: > 0.7.13-7.3 > > I setup nslcd.conf to the best of my ability. > With just a : > Uri ldap://192.168.0.10/ > Base dc=dark,dc=net > Scope sub > > It works fine. For user jtobin [is only in ldap server] I get a login > > But in a similar fashion to nss_ldap, when I turn on ssl start_tls > And add to the nslcd.conf above: > > Ssl start_tls > Tls_reqcert allow > Tls_cacertfile /var/lib/ldap/cacert.pem > Tls_cert /var/lib/ldap/server.crt > Tls_key /var/lib/ldap/server.key Hm, do you really want to do SSL/TLS client authentication? Otherwise those tls_cert and tls_key settings are unneeded for nss_ldap/nslcd. > It fails.... I get: user jtobin does not exist > > But worse... I get nothing in the /var/log/localmessages file for > debugging. > > Certificates were created using www.opeldap.org/faq/data/cache/185.html > Which to my knowledge is the referenced site for openldap > The certificate is a self signed cert. > Most of my testing at the moment is local.... Client and slapd server > are on the same machine, so same certificate file for tls_cacertfile, > tls_cert, tls_key, though I have tested on remote clients with the > same results. > > I see your name on a number of the nslcd doc and email. > Help me out here.... How can I get this working / debugged? > Who would have some of the information I need? > Who would be interested in helping me to get this working. > > So far all I have gotten is a number of messages from interested > parties asking me if I have gotten to work yet... > Drop me aline with some advice as to how to get this resolved, or if > it is probably not a short term > Priority for anyone, tell me that. I will find a different strategy for > securing my lab ldap client and server machines. > > [is getting this to work a priority at SUSE? It works for me (and many others), so it is very likely a configuration issue on your side. If it wouldn't work in general this would certainly a priority for the openSUSE community to fix it. regards, Ralf

13 years, 5 months

Re: ldapi without TLS and ldap with TLS?

by Philip Guenther

On Mon, 18 Feb 2013, Patrick Lists wrote: > On 02/18/2013 07:16 AM, Philip Guenther wrote: > > On Mon, 18 Feb 2013, Patrick Lists wrote: > > > I'm tying achieve the following with OpenLDAP RE24 from last week: > > > > > > Connections on ldapi:/// are plain text and ldap connections require > > > TLS with client cert auth. > > > > Perhaps it would be help if you started by answering, at least for > > yourself, what problem you're trying to solve. For example, "prevent > > passwords from being sent on physical networks in the clear or under a > > symmetric cipher of fewer than 256bits" > > The problem is that there is an application (running on the same box as > the LDAP server) which does not support client certificate > authentication yet it needs read-only access to the LDAP server. That's the situation, but that's not a problem unless you have some sort of security requirement. So, what's the security requirement? I can imagine it being something like: "We need to protect corporate data in LDAP from being modified or even accessed by untrusted resources. The next question is then of course why do you want to require TLS w/client certs and not just "must bind with a password, with TLS to protect the passwords", which is much more common? The answer might be something like: "Because some of the applications cannot be configured to bind non-anonymously but they all (except for that one) _can_ be configured to always use StartTLS and provide a client certificate, we want to require that all ldap:// connections use the StartTLS operation with a client cert before performing any LDAP operations that access or modify data. (That's a complete guess and probably not your real reason. Client certs are just another form of secret which are, IMO, a bigger pain to generate and manage.) > I tried to figure out how to allow the app and clients access to > localhost without TLS and the rest with TLS + client cert auth using > what seems the only example in existence: > > # first, make sure TLS or localhost > access to * > by tls_ssf=1 none break > by peername.ip="127.0.0.1" none break > by * none > > # "real" ACL(s) go here > > But that did not work and the why this should work (assuming the example > is correct) eludes me, with the guide and man pages being of little help > as I'm no software developer nor do I have Einstein's brainpower :-) Well, for starters, the peername.ip="127.0.0.1" clause does *NOT* match ldapi:// connections. It matches ldap://127.0.0.1/ and ldaps://127.0.0.1/ connections. > > > I thought I could do that with: > > ... > > > olcLocalSSF: 0 <--- > > > > So, you've told slapd that ldapi:// connections are to be treated as > > completely insecure, like ldap:// conections without TLS. That doesn't > > seem to match your intention. > > It does. Insecure socket access for the app which does not support > client cert auth and TLS+client cert auth for access via ldap/ldaps. In what way is an ldapi:// connection insecure? It's a UNIX domain socket for which the data never goes over a physical net and that therefore cannot be snooped. That's *MORE* secure than a TCP connection secured with TLS! You can even authenticate it via the uid and gid of the process that opened the connection! Anyway, if you want to permit only a) read-only ldapi:// connections and b) ldap:// connections using TLS w/client certs then *I think* you can do that with three options in the config: # require clients that clients that do TLS provide a client cert olcTLSVerifyClient: demand # treat ldapi:// connections as at least as secure as a 256bit cipher olcLocalSSF: 256 # require connections to be at least as secure as a 256bit cipher to do # anything at all (the "ssf=256") clause, and specifically require that # they be using TLS (and not just ldapi) with 256bit cipher to do updates olcSecurity: ssf=256 update_tls=256 But I haven't tested it. > > To quote slapd-config(5): > > olcSecurity: <factors> > > Specify a set of security strength factors (separated by > > white > > space) to require (see olcSaslSecprops's minssf option for a > > description of security strength factors). The directive may > > be > > specified globally and/or per-database. > > ... > > tls=<n> specifies the TLS security strength factor. > > > > So, this tells slapd to require *ALL* connections, regardless of how they > > connect, to use SSL/TLS with an SSF of at least 256. That clearly doesn't > > match your intention. > > Thank you for that explanation. It would have been nice if that section > mentioned that it applies to *all* connections with no exceptions and no > matter what else I might have configured. At least I learned something :-) Yes, an unconditional "require blah" should be taken to be unconditional. Philip Guenther

12 years, 3 months

Re: Replication and acl: moddn operation problem.

by Konstantin Menshikov

On 25.05.2012 17:56, Konstantin Menshikov wrote: > Hi. > > I have replication setup . > Full replication of o=company, but user for replication (uid=replica,ou=users,o=company) is limited by ACL. > > Master configuration: > > access to dn.subtree="ou=users,o=company" attrs=userPassword > by anonymous auth > > access to dn.base="o=company" > by dn.exact="uid=replica,ou=users,o=company" read > > access to dn.subtree="ou=dev,o=company" > by dn.exact="uid=replica,ou=users,o=company" read > > ####################################################################### > # BDB database definitions > ####################################################################### > > database hdb > suffix "o=company" > rootdn "cn=ldapadm,o=company" > rootpw password > directory /var/db/openldap-data/o=company > > overlay syncprov > > > Slave configuration: > ####################################################################### > # BDB database definitions > ####################################################################### > > database hdb > suffix "o=company" > rootdn "cn=ldapadm,o=company" > rootpw password > directory /var/db/openldap-data/o=company > > syncrepl rid=001 > provider=ldap://ro1.devel.ldap.company.ru:389 > type=refreshAndPersist > retry="5 10 300 +" > searchbase="o=company" > scope=sub > schemachecking=off > starttls=critical > bindmethod=simple > tls_reqcert=never > binddn="uid=replica,ou=users,o=company" > credentials="password" > > > Replication works. > > When i move object in forbidden by ACL subtree, then no information about this modification goes to the replica server > e.g. operation on master server: > > dn: ou=groups2,ou=dev,o=company > changetype: moddn > newrdn: ou=groups2 > deleteoldrdn: 1 > newsuperior: ou=corp,o=company > > This object is not deleted and contextCSN is not updated on the replica. > > Is it expected behavior or not? > > -- > Konstantin Menshikov > somebody? anybody? -- Konstantin Menshikov

13 years

Re: syncprov_db_open: invalid config, lastmod must be enabled

by Dieter Klünter

Am Mon, 16 Jan 2012 11:03:25 +0100 schrieb "Angel L. Mateo" <amateo(a)um.es>: > Hi, > > I'm trying to configure chain overlay in a ldap replica > consumer. My final purpose is that if this node receives an update, > it directly tries to make it in the provider node, instead of > returning the referrral. Is that possible? I think so... > > But I have a problem with the configuration. My config is > > ... > moduleload back_ldap > moduleload syncprov > ... > database hdb > suffix dc=<mysuffix> > ... > overlay syncprov > > syncrepl rid=31 > provider="ldap://<provider>" > binddn="<replica user dn>" > bindmethod=simple > credentials=<password> > searchbase="dc=<mysuffix>" > type=refreshAndPersist > interval=00:00:00:10 > retry="5 5 300 +" > timeout=1 > > overlay chain > chain-max-depth 1 > chain-return-error true > > chain-uri ldap://<provider> > chain-rebind-as-user yes > chain-idassert-bind bindmethod=simple > binddn=<replica user dn> > credentials=<password> > starttls=no > mode="self" > > But when I test configuration with slaptest, I get: > > root@canis32:/etc/ldap# slaptest -f /etc/ldap/slapd.conf > syncprov_db_open: invalid config, lastmod must be enabled > backend_startup_one (type=hdb, suffix="<mysuffix>"): bi_db_open > failed! (-1) slap_startup failed (test would succeed using the -u > switch) > > and I can't run slapd. Any idea? > > I'm running slapd 2.4.21 (ubuntu lucid package) > The chain overlay has to be configured in the global part, prior to any database declaration. -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:DA147B05 53°37'09,95"N 10°08'02,42"E

13 years, 5 months

AW: AW: syncrepl connection / reconnect

by Thorsten Mueller

Jap, changing the order did not really help. When calling netstat, I see the connection is still ESTABLISHED, even if the second machine is switched off. May be I need to wait for the tcp_keepalive_timeout. I would expect the slapd somehow recognizes the loss of the connection to the second slapd. -----Ursprüngliche Nachricht----- Von: openldap-technical-bounces+thorsten.mueller=aachen.utimaco.de(a)OpenLDAP.org [mailto:openldap-technical-bounces+thorsten.mueller=aachen.utimaco.de@OpenLDAP.org] Im Auftrag von Dieter Kluenter Gesendet: Freitag, 26. März 2010 15:40 An: openldap-technical(a)openldap.org Betreff: Re: AW: syncrepl connection / reconnect "Dieter Kluenter" <dieter(a)dkluenter.de> writes: > Thorsten Mueller <Thorsten.Mueller(a)aachen.utimaco.de> writes: > >> Here you are, the config of the second machine is identical, apart from the >> different provider > > [...] >> 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 > > [...] > > order matters, syncrepl has to be declared within a database > specification, modules are loaded last, after all database specific > configuration parameters. Sorry my bad, this should read ..overlays are loaded last... -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:8EF7B6C6 53°37'09,95"N 10°08'02,42"E

15 years, 2 months

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

by Janne Peltonen

Hi! On Tue, Jan 22, 2019 at 04:46:14PM +0200, Janne Peltonen wrote: > > Regardless, you should at the least update to the latest RHEL7 version from > > RH to see if it offers any relief from the issue you are encountering. There > > are also alternatives to the RH build that you can use on RH, such as: > > Yeah, we're looking to that already. Should've probably done that the first > thing, before asking on the list. Oh well. We had a look at this, but still ended up having some Start TLS failed errors on the proxy. We were able to create them on a server with no other load, if we hit 200 simultaneous ldaps connections binding as the same user. 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) Best, Janne / Helsinki Uni -- Janne Peltonen <janne.peltonen(a)helsinki.fi> PGP Key ID: 0x9CFAC88B Consider membership of the Hospitality Club (http://www.hospitalityclub.org)

6 years, 4 months

3rd try : Bug ? ldap_start_tls_s successful even after removing ca certificate from ca cert dir

by SOMA SEKHAR

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

10 years, 9 months

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

by Lynn York

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 ?

16 years, 7 months

Problems using StartTls with openldap-2.4.31

by Andrei Cipu

Hi all, I'm using openldap-2.4.31 compiled with gnutls25 on Rapsbmc (pre-compiled by the distribution) and I'm trying to make ldap+StartTls work with ldapsearch (simple ldap:// works like a charm). After hitting the issue described at [1] , I've decided to use a self-signed CA cert generated with certtool, as described in [2]. This allowed me to establish the TLS connection. However, the client still sends the bind in clear text, then the server closes the connection. The slapd.conf file is below (comments stripped; the client has the same CACert and cipher suites): > include /etc/ldap/schema/core.schema > include /etc/ldap/schema/cosine.schema > include /etc/ldap/schema/nis.schema > include /etc/ldap/schema/inetorgperson.schema > include /etc/ldap/schema/samba.schema > > pidfile /var/run/slapd/slapd.pid > > argsfile /var/run/slapd/slapd.args > > loglevel -1 > > modulepath /usr/lib/ldap > moduleload back_hdb > > sizelimit 500 > > tool-threads 1 > > TLSCACertificateFile /etc/ldap/certs/selfsign/ca-cert.pem > TLSCertificateKeyFile /etc/ldap/certs/selfsign/key.pem > TLSCertificateFile /etc/ldap/certs/selfsign/cert.pem > TLSCipherSuite NONE:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0:+COMP-ALL:+AES-256-CBC:+CAMELLIA-256-CBC:+RSA:+SHA1:+SHA256 > TLSVerifyClient never The client output: > root@argyle:/home/pi# ldapsearch -x -H ldap://127.0.0.1 -Z -b 'dc=strainu,dc=ro' -Dcn=admin,dc=strainu,dc=ro -w bla > ldap_start_tls: Connect error (-11) > additional info: (unknown error code) > ldap_result: Can't contact LDAP server (-1) And finally the server output: > root@argyle:/etc/ldap# /usr/sbin/slapd -g openldap -u openldap -f /etc/ldap/slapd.conf -d -1 > 53923fb1 @(#) $OpenLDAP: slapd (Apr 24 2013 17:35:25) $ buildd@build07.raspbian.lan:/build/openldap-nxJLrU/openldap-2.4.31/debian/build/servers/slapd > ldap_pvt_gethostbyname_a: host=argyle, r=0 > 53923fb1 daemon_init: <null> > 53923fb1 daemon_init: listen on ldap:/// > 53923fb1 daemon_init: 1 listeners to open... > ldap_url_parse_ext(ldap:///) > 53923fb1 daemon: listener initialized ldap:/// > 53923fb1 daemon_init: 2 listeners opened > ldap_create > 53923fb1 slapd init: initiated server. > > [...] > > 53923ffe connection_read(12): unable to get TLS client DN, error=49 id=1000 > 53923ffe conn=1000 fd=12 TLS established tls_ssf=256 ssf=256 > 53923ffe daemon: activity on 1 descriptor > 53923ffe daemon: activity on:53923ffe > 53923ffe daemon: epoll: listen=6 active_threads=0 tvp=zero > 53923ffe daemon: epoll: listen=7 active_threads=0 tvp=zero > 53923ffe daemon: activity on 1 descriptor > 53923ffe daemon: activity on:53923ffe 12r53923ffe > 53923ffe daemon: read active on 12 > 53923ffe connection_get(12) > 53923ffe connection_get(12): got connid=1000 > 53923ffe connection_read(12): checking for input on id=1000 > ber_get_next > tls_read: want=5, got=5 > 0000: 30 33 02 01 02 03... > ldap_read: want=8 error=Success > 53923ffe ber_get_next on fd 12 failed errno=0 (Success) > 53923ffe connection_read(12): input error=-2 id=1000, closing. > 53923ffe connection_closing: readying conn=1000 sd=12 for close > 53923ffe connection_close: conn=1000 sd=12 > 53923ffe daemon: removing 12 > tls_write: want=53, written=53 > 0000: 15 03 03 00 30 c2 bb c0 ae 12 fa 04 27 45 11 6e ....0.......'E.n > 0010: d7 08 20 97 49 59 0b 35 c5 77 2d b5 65 a0 97 a4 .. .IY.5.w-.e... > 0020: b0 3a eb aa b1 e7 71 8b 3e 0c 73 60 e3 9b 66 8c .:....q.>.s`..f. > 0030: f8 94 e0 c6 50 ....P > 53923ffe daemon: epoll: listen=6 active_threads=0 tvp=zero > 53923ffe daemon: epoll: listen=7 active_threads=0 tvp=zero > 53923ffe daemon: activity on 1 descriptor > 53923ffe daemon: activity on:53923ffe > 53923ffe daemon: epoll: listen=6 active_threads=0 tvp=zero > 53923ffe daemon: epoll: listen=7 active_threads=0 tvp=zero > 53923ffe conn=1000 fd=12 closed (connection lost) As you can see, the server declares the TLS established, then tries to read something, receives 5 bytes which indicates the ldap protocol (I believe), then comes the part I can't decode: > ldap_read: want=8 error=Success > 53923ffe ber_get_next on fd 12 failed errno=0 (Success) > 53923ffe connection_read(12): input error=-2 id=1000, closing. What's with the "failed errno=0" and why does the server close the connection? What should I change in the config to make it work? If you need any more information I'll provide it - I selected the part that seemed relevant to me. Thank a lot for any ideas, Andrei [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737921#25 [2] http://www.gnutls.org/manual/html_node/certtool-Invocation.html

11 years

openldap-technical search results for query "starttls"