Search results for "starttls" - openldap-technical

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation

by Douglas Duckworth

SSSD should be configured to bind TLS with ldap:389 not ldaps:636. Increase SSSD log verbosity to get more information. I have also found that slapd logging can help determine bind issues. How does one estalish their own CA that's trusted by other Root CA's? Perhaps try disabling verification of the chain then see if bind happens. On Sep 28, 2017 9:14 PM, "Robert Heller" <heller(a)deepsoft.com> wrote: > At Thu, 28 Sep 2017 16:08:42 -0700 Quanah Gibson-Mount <quanah(a)symas.com> > wrote: > > > > > --On Thursday, September 28, 2017 7:28 PM -0400 Robert Heller > > <heller(a)deepsoft.com> wrote: > > > > > At Thu, 28 Sep 2017 12:29:19 -0700 Quanah Gibson-Mount < > quanah(a)symas.com> > > > wrote: > > > > > >> > > >> --On Thursday, September 28, 2017 3:34 PM -0400 Robert Heller > > >> <heller(a)deepsoft.com> wrote: > > >> > > >> > > >> > Slapd is reporting TLS Negotiation failure when SSSD tries to > connect > > >> > to it. For both port 389 (ldap:///) and 636 (ldaps:///). So I > guess > > >> > something is wrong with slapd's TLS configuration -- it is failing > to > > >> > do TLS Negotiation, either it is just not doing it or it is doing > it > > >> > wrong (somehow). Unless SSSD is not configured properly. > > >> > > >> You need to start with the following: > > >> > > >> >> ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w > > >> > > >> to test startTLS > > >> > > >> and > > >> > > >> ldapwhoami -x -H ldaps://myhost:636 -D binddn -w > > >> > > >> to test without startTLS > > >> > > >> If you can get those to work, then you can move on to SSSD. > > > > > > [heller@c764guest ~]$ ldapwhoami -x -ZZ -H ldap://c764guest:389 -D > > > cn=Manager,dc=deepsoft,dc=com -W ldap_start_tls: Connect error (-11) > > > additional info: TLS error -8157:Certificate extension not > found. > > > > This may be of help: > > <https://urldefense.proofpoint.com/v2/url?u=https- > 3A__serverfault.com_questions_640910_my-2Dcertificate- > 2Ddoesnt-2Dwork-2Don-2Dall-2Dmachines&d=DwIBAg&c= > lb62iw4YL4RFalcE2hQUQealT9-RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e- > CbhH6xUjnRkaqPFUS2wTJ2cw&m=fNmr-KFWiEhP0yGMfSAsdSa6NOnIS_lb6cSsPujmQZ8&s= > h0ZJ27HydY4c7iw8uXd-1iadz94M-ZzNGL7KMfOsi2w&e=> > > > > > [heller@c764guest ~]$ ldapwhoami -x -H ldaps://c764guest:636 -D > > > cn=Manager,dc=deepsoft,dc=com -W Enter LDAP Password: > > > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) > > > > This may mean slapd isn't listening on port 636 (With no -d -1 info, hard > > to know for sure). It may also simply be a different manifistation of > the > > error above. > > I added a -d option (picked 10), and discovered that it wanted the full > name > as specificed in the certificate. That fixed ldapwhoami and I put that in > ldap.conf, smb.conf, and in sssd.conf, but sssd is still not behaving > (samba > is though, mostly -- it might also be having issues since sssd is not > working)... > > > > > --Quanah > > > > > > -- > > > > Quanah Gibson-Mount > > Product Architect > > Symas Corporation > > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > > <https://urldefense.proofpoint.com/v2/url?u=http- > 3A__www.symas.com&d=DwIBAg&c=lb62iw4YL4RFalcE2hQUQealT9- > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m= > fNmr-KFWiEhP0yGMfSAsdSa6NOnIS_lb6cSsPujmQZ8&s=4Jyip- > C583CeHTI2N1wXllUKzrjwwvY9tqyl3tZVq8w&e=> > > > > > > -- > Robert Heller -- 978-544-6933 > Deepwoods Software -- Custom Software Services > https://urldefense.proofpoint.com/v2/url?u=http-3A__www. > deepsoft.com_&d=DwIBAg&c=lb62iw4YL4RFalcE2hQUQealT9- > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m= > fNmr-KFWiEhP0yGMfSAsdSa6NOnIS_lb6cSsPujmQZ8&s=hf9o7fTr6iLSDpsS6xK6nGDWhZo- > N7aXcKoRAXfrPUE&e= -- Linux Administration Services > heller(a)deepsoft.com -- Webhosting Services > > >

7 years, 8 months

Re: Replication issues with openldap 2.5

by 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(a)breezeline.com <jsutherland1(a)breezeline.com> On Wed, Jan 1, 2025 at 12:52 PM Shawn McKinney <smckinney(a)symas.com> wrote: > > > On Dec 31, 2024, at 9:08 AM, Ulises Gonzalez Horta < > ugonzalezhorta(a)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: TLS replication/SALS bindmethod

by Michael Ströder

Darouichi, Aziz wrote: > I configured Muti-master replication, everything worked fine till I hashed > rootpw to confirm to a hardcoded password in Oracle. > I configured OpenLDAP servers to us SALS. This is my configuration. > provider=ldap://xxx.xxx.xxx:389 > bindmethod=sasl > saslmech=external > starttls=yes > tls_cert=/etc/pki/tls/certs/slapd.pem > tls_key=/etc/pki/tls/private/ldap.pem > tls_cacert=/etc/pki/tls/certs/ca-bundle.crt > tls_reqcert=demand > binddn="cn=ldap,dc=establishment,dc=edu" > credentials={SSHA}2vNffW+5hEolqIykgH9tCpxq9jTTVSSu > searchbase="dc=establishment,dc=edu" > schemachecking=on > type=refreshAndPersist > retry="60 +" I don't understand why you use bindmethod=sasl saslmech=external and binddn="cn=ldap,dc=establishment,dc=edu" credentials={SSHA}2vNffW+5hEolqIykgH9tCpxq9jTTVSSu together. Anyway you have to provide the clear-text password here since the consumer is a LDAP client. > when I run ldapsearch against servers I get response from both machines. > ldapsearch -H ldap://server.establishment.edu -D > "cn=ldap,dc=establishment,dc=edu" -w "PASSWORD" -x -b "dc=establishment > ,dc=edu" "(objectclass=*)" uid. > This what I get in the logs: > May 23 09:37:01 ldap1 slapd[1559]: slap_client_connect: > URI=ldap://xxx.xxx.edu:389 ldap_sasl_interactive_bind_s failed (-6) > May 23 09:37:01 ldap1 slapd[1559]: do_syncrepl: rid=002 rc -6 retrying > May 23 09:37:58 ldap1 slapd[1559]: conn=5220 op=0 do_extended: unsupported > operation "1.3.6.1.4.1.1466.20037" > May 23 09:38:01 ldap1 slapd[1559]: slap_client_connect: > URI=ldap://xxx.xxx.edu:389 Warning, ldap_start_tls failed (2) > May 23 09:38:01 ldap1 slapd[1559]: slap_client_connect: > URI=ldap://xxx.xxx.edu:389 ldap_sasl_interactive_bind_s failed (-6) > May 23 09:38:01 ldap1 slapd[1559]: do_syncrepl: rid=002 rc -6 retrying This basically means that TLS is not properly configured at the provider. Ciao, Michael.

14 years

Re: TLS issue with SLES11

by pradyumna dash

Hi, I want to achieve ldaps, that means all the communication should use 636 port, i have changed the parameters in the /etc/openldap/sysconfig file, but no luck. Regards, Pradyumna On Sat, Aug 27, 2011 at 12:11 PM, Benjamin Griese <der.darude(a)gmail.com>wrote: > Hello, > > I don't clearly understand what you're trying to achieve? > > There are two possible ways to do encrypted connections: > - with StartTLS via Port 389 (ldap:// - non-encrypted connections are still > possible, if onfigured in your slapd config) > - with SSL/TLS via 639 (ldaps://) > > You can disable/enable each way in your /etc/sysconfig/openldap file. > > Please read this: http://www.openldap.org/faq/data/cache/185.html > > Bye, Benjamin > > On Sat, Aug 27, 2011 at 12:00, pradyumna dash <neomatrixgem(a)gmail.com>wrote: > >> List, >> >> It would be great if someone can share doc on TLS with OpenLDAP >> configuration on SLES 11, I tried all the possible ways to make it happen >> but no luck. >> >> I tried with both yast2 and by CA.pl and openssl commands, but no luck, >> When i do netstat .lnap |grep ldap it shows both 636 and 389 port listtening >> to the >> hostname, When i check the logs it shows the destination port its showing >> is 389. >> >> But when i try ldapsearch -x -H ldaps://hostname, its also showing me the >> ldap contents, dont know whats wrong, I also tried to open >> /etc/sysconfig/openldap >> and assigned the LDAP service to run on 127.0.0.1, but if i do so then its >> not able to get the server. >> >> Please help. >> >> Regards, >> Neo >> > > > > -- > 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 > >

13 years, 9 months

Re: slapo-pcache seems broken in openldap-2.4.31

by Howard Chu

Tio Teath wrote: > I'm trying to set up slapo-pcache using cn=config, and this is my settings: > > dn: olcDatabase={1}ldap,cn=config > objectClass: olcConfig > objectClass: olcDatabaseConfig > objectClass: olcLDAPConfig > objectClass: top > olcDatabase: {1}ldap > olcRootDN: cn=admin,cn=config > olcAccess: {0}to * by * read > olcDbACLBind: bindmethod=simple binddn="ou=group,dc=remote" > credentials="password" tls_cacert="/etc/ssl/certs/ca-certificates.crt" > starttls=yes > olcDbURI: ldap://remote.host > olcSuffix: dc=remote > > dn: olcOverlay={0}pcache,olcDatabase={1}ldap,cn=config > objectClass: olcPcacheConfig > objectClass: olcOverlayConfig > objectClass: olcConfig > objectClass: top > olcOverlay: {0}pcache > olcPcache: hdb 10000 1 50 100 > olcPcacheAttrset: 0 member > olcPcacheTemplate: "(objectClass=)" 0 3600 > > dn: olcDatabase={0}hdb,olcOverlay={0}pcache,olcDatabase={1}ldap,cn=config > objectClass: olcPcacheDatabase > objectClass: olcHdbConfig > objectClass: olcDatabaseConfig > objectClass: olcConfig > objectClass: top > olcDatabase: {0}hdb > olcDbDirectory: /var/lib/ldap/cache > olcDbIndex: objectClass eq > olcDbIndex: pcacheQueryid eq > > But each time I'm trying to run > ldapsearch -b"cn=test2,ou=group,dc=remote" '(objectClass=*)' member > I'm getting QUERY NOT ANSWERABLE/QUERY NOT CACHEABLE errors in the log. That's correct, since your search query doesn't match your template. Your search uses '(objectclass=*)' which is a Presence filter. Your template only supports Equality (and Substring) filters. Your template needs to be "(objectclass=*)" to support Presence filters. > > Besides, it is impossible to modify attributes > olcPcacheTemplate/olcPcacheAttrset: > modify/add: olcPcacheTemplate: no equality matching rule This is definitely a bug, please submit this to the ITS. Thanks. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

12 years, 6 months

Re: SSL replication deadlocks slapd

by Chad Scott

Definitely not an entropy problem. I see "ACCEPT" in the logs, but nothing else. I hadn't realized RedHat was so damn behind. I'm going to generate a custom package with the latest version and see if the problem goes away. On Wed, Sep 25, 2013 at 2:21 PM, Dan White <dwhite(a)olp.net> wrote: > On 09/25/13 13:43 -0700, Chad Scott wrote: > >> I'm having a lot of trouble with replication when using SSL. If I >> configure >> everything exactly the same without SSL, it works flawlessly. The instant >> I >> try to encrypt traffic, one or both servers will deadlock, even after >> restart. >> > > Does slapd still respond? If so, verify that your entropy is not being > depleted for your ssl connections. I believe by default openssl uses > /dev/random which can block. Check /proc/sys/kernel/random/** > entropy_avail. > > > I'm configuring according to the instructions at >> http://www.openldap.org/doc/**admin24/replication.html#N-Way<http://www.openldap.org/doc/admin24/replication.html#N-Way>Multi-Master, >> except using ldaps:// instead of ldap://. >> >> In cn=config, I've setup: >> olcTLSCACertificateFile: /etc/openldap/certs/** >> Operations_CA_Certificate.pem >> olcTLSCertificateFile: /etc/openldap/certs/ldap.pem >> olcTLSCertificateKeyFile: /etc/openldap/certs/ldap.key >> >> I've also tried using STARTTLS over ldap:// and it seems to make no >> difference. >> >> Permissions are right and I can connect via SSL from clients without >> issue. >> >> I'm completely stumped as to what might be going on. Has anyone seen this >> before? >> >> This is running on Scientific Linux 6 with the following packages: >> openldap-2.4.23-32.el6_4.x86_**64 >> openldap-clients-2.4.23-32.**el6_4.x86_64 >> openldap-servers-2.4.23-32.**el6_4.x86_64 >> > > -- > Dan White >

11 years, 8 months

OpenLDAP Replication Issue

by Tony S. Wu

We have 5 servers running OpenLDAP, 001 - 005. Server is CentOS 6.4, LDAP version is openldap-servers-2.4.23-32.el6_4.1.x86_64, current replication topology is: 001 <=> 002 001 <=> 003 001 <=> 004 001 <=> 005 001 is where the phpLDAPAdmin GUI is running on. 002 - 005 are behind a load balancer, 001 is never directly accessed from clients. I understand this makes 001 the single point of failure in terms of replication, but we would like to fix the current issues before exploring more changes. The issue we are running is intermittent failure in replication. Replication is configured as multi-way master with mirror mode, it always works from 001 to the rest, but sometimes fails the other direction. This is particularly bad when user changes password and it doesn't get replicated to back to 001, and when that happens it doesn't get replicated to the rest of the other servers. In the log we see the following error messages sometimes, but when replication fails sometimes there is no log: Error Log: Jan 21 10:56:42 001 slapd[27161]: do_syncrepl: rid=004 rc -2 retrying (4 retries left) Another issue is failure on slapd service. On each of the server we have a cronjob running that basically dumps the database using slapcat once an hour. However once every 2 weeks or so we would find slapd dead right around the same time slapcat was run. There is no obvious error in ldap log, system log, or dmesg. According to the documentation it is safe to run slapcat while slapd is running, is this not true? Below is the replication section of the configuration on 001 and 004. If someone could advise on this it would be very much appreciated. moduleload syncprov.la serverid 1 cachesize 50000 idlcachesize 50000 syncrepl rid=002 provider=ldap://002.server.com binddn="uid=replication,ou=Services,dc=server,dc=com" bindmethod=simple credentials=******** searchbase="dc=server,dc=com" type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 5" timeout=1 starttls=yes tls_reqcert=never * repeat for 003, 004, and 005 * mirrormode true overlay syncprov syncprov-checkpoint 1000 60 syncprov-sessionlog 100 index entryCSN,entryUUID eq

10 years, 4 months

Re: SASL EXTERNAL, sasldb2 and authz-regexp

by Götz Reinicke - IT-Koordinator

Oliver Liebel schrieb: > Am 14.04.2010 09:36, schrieb Götz Reinicke - IT-Koordinator: >> Dieter Kluenter schrieb: >> >>> Götz Reinicke - IT-Koordinator<goetz.reinicke(a)filmakademie.de> writes: >>> >>> >>>> Hi folks, >>>> >>> [...] >>> >>>> My consumer server should bind to the provider using sasl with the >>>> saslmech external. (Red Hat 5.x, cyrus-sasl-2.1.22, openldap-2.3.43-3 ) >>>> >>>> I'v changed the slapd.conf files on both servers: >>>> >>>> consumer: >>>> >>>> syncrepl ... >>>> bindmethod=sasl >>>> saslmech=EXTERNAL >>>> starttls=yes >>>> >>>> provider: >>>> >>>> authz-regexp >>>> "dn=email=webmaster(a)filmakademie.de,cn=ldap2.filmakademie.de,ou=it >>>> officenet,o=filmakademie baden-wuerttemberg >>>> gmbh,l=ludwigbsburg,st=baden-wuerttemberg,c=de" >>>> "cn=replicator,dc=filmakademie,dc=de" >>>> > from first sight, looks like wrong authz-regexp: > dn=email= .... Thats right AND I had a linebrake between both values. After changing both everything works like I thougt it should. Regards, Götz -- Götz Reinicke IT-Koordinator Tel. +49 7141 969 420 Fax +49 7141 969 55 420 E-Mail goetz.reinicke(a)filmakademie.de Filmakademie Baden-Württemberg GmbH Akademiehof 10 71638 Ludwigsburg www.filmakademie.de Eintragung Amtsgericht Stuttgart HRB 205016 Vorsitzende des Aufsichtsrats: Prof. Dr. Claudia Hübner Geschäftsführer: Prof. Thomas Schadt

15 years, 2 months

Replication issue? Data is different between master and consumer with same entryCSNs

by Dave Steiner

I've been noticing various data discrepancies between our LDAP master and LDAP consumers. We are running OpenLDAP v2.4.44. We have two masters running "mirromode TRUE" and all updates go through a VIP that points to the first one unless it's not available (doesn't happen very often except for during patches and restarts). We have 13 consumers that replicate through that same VIP. Here's an example of our syncrepl for a client: syncrepl rid=221 type=refreshAndPersist schemachecking=on provider="ldap://ldapmastervip.rutgers.edu/" bindmethod=sasl saslmech=EXTERNAL starttls=yes tls_reqcert=demand tls_protocol_min="3.1" searchbase="dc=rutgers,dc=edu" attrs="*,+" retry="10 10 20 +" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog network-timeout=30 keepalive=180:3:60 I check the contextCSN attributes on all the instances every day and they are all in sync (except during any major changes, of course). But I occasionally notice discrepancies in the data.... even though the contextCSNs and entryCSNs are the same. For example (note hostnames have been changed): $ ldapsearch ... -H ldap://ldapmaster.rutgers.edu uid=XXXX postalAddress createTimestamp modifyTimestamp entryCSN dn: uid=XXXX,ou=People,dc=rutgers,dc=edu createTimestamp: 20121220100700Z postalAddress: Business And Science Bldg$227 Penn Street$Camden, NJ 081021656 entryCSN: 20180505002024.083133Z#000000#001#000000 modifyTimestamp: 20180505002024Z $ ldapsearch ... -H ldap://ldapconsumer3.rutgers.edu uid=XXXX postalAddress createTimestamp modifyTimestamp entryCSN dn: uid=XXXX,ou=People,dc=rutgers,dc=edu createTimestamp: 20121220100700Z postalAddress: BUSINESS AND SCIENCE BLDG$227 PENN STREET$CAMDEN, NJ 081021656 entryCSN: 20180505002024.083133Z#000000#001#000000 modifyTimestamp: 20180505002024Z So I'm trying to figure out why this happens (config issue, bug, ???) and second, if I can't use the contextCSN to report that everything is fine, what else can I do besides trying to compare ldif dumps. thanks, ds -- Dave Steiner steiner(a)rutgers.edu IdM, Enterprise Application Services ASB101; 848.445.5433 Rutgers University, Office of Information Technology

6 years, 9 months

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

by John Tobin

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

13 years, 6 months

openldap-technical search results for query "starttls"