Search results for "starttls" - openldap-technical

ssf Security Question

by Kaya Saman

Hi, I am a little confused with this. Basically I have a client connecting to the database, a DECT IP phone base station which doesn't support STARTLS and my slapd config has settings for clients to use certificates to connect. What would be the best way to set this up so that the DECT IP client only accesses the particular place that it needs to, the AddressBook section but then other clients will need to use STARTTLS for everything else?? Currently I am looking at: https://www.openldap.org/doc/admin24/security.html https://www.openldap.org/doc/admin24/access-control.html and have currently put this in my slapd.conf: #Removed the Global? security clause #security ssf=128 #Added generic ACL for all access to require ssf of 128 access to * by ssf=128 self write by ssf=128 anonymous auth by ssf=128 users read #Added ACL for open access to AddressBook in Read and Search only mode access to dn.children="ou=AddressBook,dc=domain,dc=com" by * search by * read Is this correct or do I need to engage the "security" Global section too? Though the documentation suggests otherwise: "For fine-grained control, SSFs may be used in access controls. See theAccess Control <https://www.openldap.org/doc/admin24/access-control.html>section for more information." Thanks. Kaya

7 years

RE: Openldap server with TLS not working

by Axel Grosse

Hi ben, thanks for the comment. agree with you on TLS usage should be perferred but the client that is connecting is only capable of LDAPS ... he has not implemented TLS Client jet . But can you please take a look to the error I am facing openssl s_client -connect 192.168.30.169:389 -showcerts -CAfile ./ssl/VordelCA.crt CONNECTED(00000003) 710:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188: any idea what can cause this ? AXEL GROSSE Principal Solution Architect, Sales Solution Center, Axway P: +61-405-995-768 828 Pacific Highway Gordon, 2072 NSW agrosse(a)axway.com http://www.axway.com -----Original Message----- From: openldap-technical-bounces(a)OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of btb Sent: Wednesday, 2 October 2013 10:57 PM To: openldap-technical(a)openldap.org Subject: Re: Openldap server with TLS not working On 2013.10.02 07.29, Axel Grosse wrote: > when I test on the server itself .. > openssl s_client -connect 192.168.30.169:389 -showcerts -CAfile > ./ssl/VordelCA.crt > CONNECTED(00000003) > 710:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188: ldaps [port 636] is deprecated. use starttls with the standard port [389]. to test, just use ldapsearch [see the reference to -Z in the man page] -ben

11 years, 1 month

RE: Syncrepl and mmr

by Borresen, John - 0442 - MITLL

Checking my production servers, which is only using Delta-syncrepl Those servers are using SSL3 over port 636, and the olcSyncrepl has "starttls=no" and using the "tls_certdir" Thanks in advance John -----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Friday, January 31, 2014 1:26 PM To: Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org Subject: RE: Syncrepl and mmr --On Friday, January 31, 2014 1:20 PM -0500 "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu> wrote: > Thanks, Quanah > > Not sure what you meant by " Well, it may not have been this issue, > but it definite would become an issue then." > > Was what I did a good thing or not? Curious minds want to know. <lol> The lack of read permissions for the replication user would absolutely be an issue at some point. ;) > MM Server1: ># ldapsearch -H ldap://mm-server1.example.ldap -d 256 -x -D # >cn=admin,cn=config -W -ZZ -b olcDatabase=\{1\}bdb,cn=config >olcSyncrepl What CA cert is your ldapsearch command using? --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

10 years, 9 months

Re: Ppolicy issues

by Buchan Milne

On Wednesday 20 February 2008 17:10:00 Bryan Payne wrote: > Thank you for your help. I added the pwdPolicySubentry to a user to no > avail. I did find this in the logfile though: > > Feb 20 09:01:13 ldapserver slapd[6709]: conn=95289 op=4 SEARCH RESULT > tag=101 err=50 nentries=0 text=Operations are restricted to > bind/unbind/abandon/StartTLS/modify password > > So it looks like it's trying to do something but cannot. While I'm > concerned about password strength, I'm more concerned (at this point) > with just having the machine prompt for a password change. Well, what do you mean by "the machine" ? It looks like the password has expired, but if you're expecting a prompt for a password change, that's a client side issue. So, what is the client in this case? Recent versions of pam_ldap support ppolicy (IIRC including the one shipped with RHEL4), but you didn't say which client this is. Also, you said accounts get locked, but users can still log in? This sounds like you might not actually be using pam_ldap for authentication, but the pam_unix->nss_ldap (NIS replacement and nothing more) method, which won't see anything relating to ppolicy. Regards, Buchan

16 years, 8 months

MirrorMode sync only happening in one direction

by Daniel Qian

The problem direction has the same syncrepl configuration as the working one except for the rid and provider name: olcSyncrepl: {0} rid=102 provider="ldap://server2.prod:389/" type=refreshAndPersist retry="60 30 300 +" keepalive=1200:10:3 searchbase="dc=mydomain,dc=com" bindmethod=simple binddn="cn=replica,dc=mydomain,dc=com" credentials=xxxxxx starttls=critical tls_cacert="/etc/pki/CA/cacert.pem" On the consumer side I am seeing these messages: Sep 22 22:02:02 ldaprov1 slapd[15466]: do_syncrep2: rid=102 got search entry without Sync State control Sep 22 22:02:02 ldaprov1 slapd[15466]: do_syncrepl: rid=102 rc -1 retrying (29 retries left) and on the provider side I am seeing these: Sep 22 18:02:36 localhost slapd[20718]: conn=1071 fd=21 ACCEPT from IP=10.10.2.103:35671 (IP=0.0.0.0:389) Sep 22 18:02:36 localhost slapd[20718]: conn=1071 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Sep 22 18:02:36 localhost slapd[20718]: conn=1071 op=0 STARTTLS Sep 22 18:02:36 localhost slapd[20718]: conn=1071 op=0 RESULT oid= err=0 text= Sep 22 18:02:36 localhost slapd[20718]: conn=1071 fd=21 TLS established tls_ssf=256 ssf=256 Sep 22 18:02:36 localhost slapd[20718]: conn=1071 op=1 BIND dn="cn=replica,dc=mydomain,dc=com" method=128 Sep 22 18:02:36 localhost slapd[20718]: conn=1071 op=1 BIND dn="cn=replica,dc=mydomain,dc=com" mech=SIMPLE ssf=0 Sep 22 18:02:36 localhost slapd[20718]: conn=1071 op=1 RESULT tag=97 err=0 text= Sep 22 18:02:36 localhost slapd[20718]: conn=1071 op=2 SRCH base="dc=mydomain,dc=com" scope=2 deref=0 filter="(objectClass=*)" Sep 22 18:02:36 localhost slapd[20718]: conn=1071 op=2 SRCH attr=* + Sep 22 18:02:36 localhost slapd[20718]: conn=1071 op=2 SEARCH RESULT tag=101 err=0 nentries=22 text= Sep 22 18:02:36 localhost slapd[20718]: conn=1071 op=3 UNBIND Sep 22 18:02:36 localhost slapd[20718]: conn=1071 fd=21 closed Sep 22 18:02:36 localhost slapd[20718]: connection_read(21): no connection! Sep 22 18:02:36 localhost slapd[20718]: connection_read(21): no connection! Sep 22 18:03:37 localhost slapd[20718]: conn=1072 fd=21 ACCEPT from IP=10.10.2.103:35672 (IP=0.0.0.0:389) Sep 22 18:03:37 localhost slapd[20718]: conn=1072 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Sep 22 18:03:37 localhost slapd[20718]: conn=1072 op=0 STARTTLS Sep 22 18:03:37 localhost slapd[20718]: conn=1072 op=0 RESULT oid= err=0 text= Sep 22 18:03:37 localhost slapd[20718]: conn=1072 fd=21 TLS established tls_ssf=256 ssf=256 Sep 22 18:03:37 localhost slapd[20718]: conn=1072 op=1 BIND dn="cn=replica,dc=mydomain,dc=com" method=128 Sep 22 18:03:37 localhost slapd[20718]: conn=1072 op=1 BIND dn="cn=replica,dc=mydomain,dc=com" mech=SIMPLE ssf=0 Sep 22 18:03:37 localhost slapd[20718]: conn=1072 op=1 RESULT tag=97 err=0 text= Sep 22 18:03:37 localhost slapd[20718]: conn=1072 op=2 SRCH base="dc=mydomain,dc=com" scope=2 deref=0 filter="(objectClass=*)" Sep 22 18:03:37 localhost slapd[20718]: conn=1072 op=2 SRCH attr=* + Sep 22 18:03:37 localhost slapd[20718]: conn=1072 op=2 SEARCH RESULT tag=101 err=0 nentries=22 text= Sep 22 18:03:37 localhost slapd[20718]: conn=1072 op=3 UNBIND Sep 22 18:03:37 localhost slapd[20718]: conn=1072 fd=21 closed Sep 22 18:03:37 localhost slapd[20718]: connection_read(21): no connection! Sep 22 18:03:37 localhost slapd[20718]: connection_read(21): no connection! The sync connection is supposed to be persistent but it keeps closing down and reconnecting. Anyone know what could be the reason? Thanks, Daniel

13 years, 1 month

Re: cn=config chaining

by Jancewicz, Russell

It was modified from the generation of slapd-chain2.conf which also didn't work (I was working off the assumption that the overlay needed to be on olcDatabase={1}frontend) This is the slapd-chain2.conf file I am using (modified slightly) The only differences between this and the unmodified slapd-chain2.conf is the directory and the addition of chain-tls and chain-idassert-authzFrom to the "overlay chain" section. I'm generating my config with it with $ slaptest -f slapd-chain2.conf -F ./slapd.d-test/ """ include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/nis.schema database hdb directory /srv/ldap/example.com/ suffix "dc=example,dc=com" rootdn "cn=admin,dc=example,dc=com" rootpw secret overlay chain chain-uri ldap://master.example.com chain-idassert-bind bindmethod=simple binddn="dc=example,dc=com" credentials=secret mode=self chain-tls start chain-idassert-authzFrom "*" """ The resulting cn=config doesn't generate objects on the olcDatabase={1}frontend database but rather the two following objects are generated within olcOverlay={0}chain,olcDatabase={1}hdb,cn=config olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config """ # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 f3da9a85 dn: olcDatabase={0}ldap objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbStartTLS: none starttls=no olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 structuralObjectClass: olcLDAPConfig entryUUID: df7b759c-bb09-1032-82c9-adb6d4ef9266 creatorsName: cn=config createTimestamp: 20130926151258Z entryCSN: 20130926151258.900907Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130926151258Z """ olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config """ # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 b7a21479 dn: olcDatabase={1}ldap objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {1}ldap olcDbURI: "ldap://master.example.com" olcDbStartTLS: start starttls=no olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindm ethod=simple timeout=0 network-timeout=0 binddn="dc=example,dc=com" credentials ="secret" keepalive =0:0:0 olcDbIDAssertAuthzFrom: * olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 structuralObjectClass: olcLDAPConfig entryUUID: df7b7c90-bb09-1032-82ca-adb6d4ef9266 creatorsName: cn=config createTimestamp: 20130926151258Z entryCSN: 20130926151258.900907Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130926151258Z """ The changes to relocate these objects to the olcDatabase{-1}fontend was in response to the things I had read online. -Russell J. Jancewicz University of Connecticut On 2013-09-26 13:02, "Quanah Gibson-Mount" <quanah(a)zimbra.com> wrote: >--On Thursday, September 26, 2013 4:02 PM +0000 "Jancewicz, Russell" ><russell.jancewicz(a)uconn.edu> wrote: > > >> dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config >> objectClass: olcOverlayConfig >> objectClass: olcChainConfig >> olcOverlay: {0}chain >> olcChainCacheURI: FALSE >> olcChainMaxReferralDepth: 1 >> olcChainReturnError: FALSE >> >> >> dn: >> olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config >> objectClass: olcLDAPConfig >> objectClass: olcChainDatabase >> olcDatabase: ldap >> olcDbURI: "ldap://master.example.com" >> olcDbStartTLS: start starttls=no >> olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical >> bindmethod=simple timeout=0 network-timeout=0 >> binddn="cn=admin,dc=example,dc=com" credentials="<SECRET>" >> keepalive=0:0:0 >> olcDbIDAssertAuthzFrom: * >> olcDbRebindAsUser: FALSE >> olcDbChaseReferrals: TRUE >> olcDbTFSupport: no >> olcDbProxyWhoAmI: FALSE >> olcDbProtocolVersion: 3 >> olcDbSingleConn: FALSE >> olcDbCancel: abandon >> olcDbUseTemporaryConn: FALSE >> olcDbConnectionPoolMax: 16 >> olcDbSessionTrackingRequest: FALSE >> olcDbNoRefs: FALSE >> olcDbNoUndefFilter: FALSE >> olcDbOnErr: continue >> olcDbKeepalive: 0:0:0 > >This is not a valid conversion of slapd-chain2.conf from the test suite. >How did you arrive at this config? > >--Quanah > >-- > >Quanah Gibson-Mount >Lead Engineer >Zimbra Software, LLC >-------------------- >Zimbra :: the leader in open source messaging and collaboration

11 years, 1 month

Re: ldapdelete recursive (-r) with syncrepl

by Frank Crow

OpenLDAP 2.4.40 Syncrepl configuration: olcSyncUseSubentry: FALSE > olcSyncrepl: {0}rid=101 provider=ldap://server1 searchbase="o=xxx,dc=yyy, > dc=zzz" type=refreshOnly bindmethod=sasl saslmech=EXTERNAL > tls_cert=/etc/openldap/certs/xxxxx.crt > tls_key=/etc/openldap/certs/xxxxx.key > tls_cacert=/etc/openldap/certs/cacert.pem interval=00:00:00:10 > retry="5 10 10 10 30 +" timeout=1 starttls=critical > olcSyncrepl: {1}rid=102 provider=ldap://server2 > searchbase="o=xxx,dc=yyyy, > dc=zzz" type=refreshOnly bindmethod=sasl saslmech=EXTERNAL > tls_cert=/etc/openldap/certs/ldapadmin.crt > tls_key=/etc/openldap/certs/xxxxx.key > tls_cacert=/etc/openldap/certs/cacert.pem interval=00:00:00:10 > retry="5 10 10 10 30 +" timeout=1 starttls=critical > olcMirrorMode: TRUE BTW, I just tried addinging: dn: olcOverly={3}syncprov,olcDatabase={2},cn=config > changetype: modify > replace: olcSpCheckpoint > olcSpCheckpoint: 1024 > - > add: olcSpSessionlog > olcSpSessionlog: 1024 > - > add: olcSpReloadhint > olcSpReloadhint: TRUE And that seemed to fix it! Maybe it was just the checkpoint being "1 1" that was messing it up? Or maybe I needed the session log. I realize that this is the deprecated approach. I probably put in cn=changelog instead if there's a good reason to do so. -Frank On Tue, Apr 12, 2016 at 6:26 PM, Frank Crow <fjcrow2008(a)gmail.com> wrote: > OK, if I do a backup with slapcat, I still would want to wipe the existing > contents of the DIT first, right? > > Also, I just tried doing a list of deleted uid entries using "ldapdelete > -ZZ -f /file.ldif" and although the command did not complain, not all of > the entries in the file.ldif were deleted from all replicas. I really > think there is something wrong with my configuration! I suppose that I'll > try cn=changelog next. > > Thanks, > Frank > > > On Tue, Apr 12, 2016 at 5:47 PM, Michael Ströder <michael(a)stroeder.com> > wrote: > >> Frank Crow wrote: >> > I'm trying to create backup and restore scripts using LDAP command line >> > tools. >> >> For various reasons backup and restore should be done with command-line >> tools >> slapcat and slapadd which operate directly on the database files. >> >> And yes, with recent backend modules like back-mdb and back-hdb you can >> do hot >> backup while slapd is running. >> >> Of course, before a restore you have to stop slapd and remove the DB >> files. >> After using slapadd you should check whether ownership/permissions are >> still >> correct. >> >> Ciao, Michael. >> >> > > > -- > Frank > -- Frank

8 years, 7 months

RE: problem with ldap backend

by Alex Samad - Yieldbroker

Hi Just wondering if the features is supposed to work ? Am I delving into experimental code ? Alex > -----Original Message----- > From: Alex Samad - Yieldbroker > Sent: Thursday, 29 March 2012 9:28 AM > To: openldap-technical(a)openldap.org > Subject: RE: problem with ldap backend > > Hi > > I have progressed a little bit further > > I have stopped using olcdbaclbind and started to use > > olcDbIDAssertAuthzFrom: "*" > olcDbIDAssertBind: bindmethod=none authzId="CN=ad > readonly,OU=Services ,DC= xyz,DC=com" credentials="secret" starttls=no > > > but I get this > > text: 000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform this > ope ration a successful bind must be completed on the connection., data 0, > v1db1 > > > I am able to ldapsearch with these credentials, I also tried change > bindmethod to simple, but same error > > How do I turn on debug for the ldap backend ? > > Any one have any ideas on how to make this work ? > > > Alex > > > > -----Original Message----- > > From: openldap-technical-bounces(a)OpenLDAP.org > > [mailto:openldap-technical- bounces(a)OpenLDAP.org] On Behalf Of Alex > > Samad - Yieldbroker > > Sent: Wednesday, 28 March 2012 1:58 PM > > To: openldap-technical(a)openldap.org > > Subject: problem with ldap backend > > > > Hi > > > > I am trying to setup a connection from openldap to MS AD > > > > I am using this > > > > dn: olcDatabase={3}ldap > > objectClass: olcDatabaseConfig > > objectClass: olcLDAPConfig > > olcDatabase: {3}ldap > > olcSuffix: dc=xyz,dc=com > > olcAccess: {0}to dn.base="" by * read > > olcAccess: {1}to dn.base="cn=Subschema" by * read > > olcAccess: {2}to * by self write by users read by anonymous auth > > olcReadOnly: TRUE > > olcRootDN: > gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > > olcSizeLimit: 500 > > olcDbURI: "ldap://dc101. xyz.com ldap://dc201. xyz.com" > > olcDbRebindAsUser: TRUE > > olcDbChaseReferrals: TRUE > > > > > > This works fine when I pass a bind DN. > > > > I would like to convert this to allow anon access to ldap, which does > > a user bind to MS AD so I added this > > > > > > olcdbaclbind: bindmethod=simple binddn="CN=ad readonly,OU= xyz,DC= > > xyz,DC=com" credentials="secret" starttls=no > > > > but it is not working, I can not make a anon search request, they > > retrieve any thing frome the MSAD ldap server. > > > > Thanks > > > > > > > >

12 years, 7 months

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

by 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. 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? 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. 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 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? Is there someone I can work with?] Sincerely tob There are a number of comments but the real statements are: Uri ldap://192.168.0.10/ Base dc=dark,dc=net Scope sub Ssl start_tls

12 years, 10 months

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

by Robert Heller

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://serverfault.com/questions/640910/my-certificate-doesnt-work-on-all-…> > > > [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: > <http://www.symas.com> > > -- Robert Heller -- 978-544-6933 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services heller(a)deepsoft.com -- Webhosting Services

7 years, 1 month

openldap-technical search results for query "starttls"