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 brendan kearney

Late ti the thread, so forgive the stupid question, but why arent you using SASL and forgoing all the OpenSSL vs MozNSS kerfuffle? If you have OpenLDAP and SSSD going on, surely Kerberos is something you are able to setup. On Sep 29, 2017 2:20 AM, "Michael Wandel" <m.wandel(a)t-online.de> wrote: > On 28.09.2017 21:41, Robert Heller wrote: > > Will these spit out useful error messages? If I just get "TLS > Negotiation > > failure" it is not going to be helpful. > > > > You can make it a little bit more verbose with the option "-d -1" > > It is only a suggestion, but can you test the parameter > > TLS_REQCERT allow > > in your /etc/openldap/ldap.conf > > This ist not a good option for production systems, but it seems you come > in trouble with your certificates. > > You have to set your > > TLS_CACERT > xor > TLS_CACERTDIR > > correctly in your /etc/openldap/slapd.conf to work stressless with your > ssl/tls. > > best regards > Michael > > > 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. > >> > >> --Quanah > >> > >> -- > >> > >> Quanah Gibson-Mount > >> Product Architect > >> Symas Corporation > >> Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > >> <http://www.symas.com> > >> > >> > > > > > -- > Michael Wandel > Braakstraße 43 > 33647 Bielefeld > >

7 years, 1 month

Re: OpenLDAP self-signed certificates issue

by Vijay Ganesan

Thanks Ryan and Udai. Don't really have to use ldaps. I understand now that the documentation <https://help.ubuntu.com/12.04/serverguide/openldap-server.html#openldap-tls> is for StartTLS an can use that. LDAPTLS_CACERT=/etc/ssl/certs/vijay_slapd_cert.pem ldapwhoami -H ldap://localhost -x -ZZ gives: *ldap_start_tls: Connect error (-11)* * additional info: A TLS packet with unexpected length was received.* with '-d1' I get the following which looks like it can connect but subsequent communication fails: ldap_url_parse_ext(ldap://localhost) ldap_create ldap_url_parse_ext(ldap://localhost:389/??base) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 127.0.0.1:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x7f2c70eef160 msgid 1 wait4msg ld 0x7f2c70eef160 msgid 1 (infinite timeout) wait4msg continue ld 0x7f2c70eef160 msgid 1 all 1 ** ld 0x7f2c70eef160 Connections: * host: localhost port: 389 (default) refcnt: 2 status: Connected last used: Mon Sep 8 07:56:01 2014 ** ld 0x7f2c70eef160 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x7f2c70eef160 request count 1 (abandoned 0) ** ld 0x7f2c70eef160 Response Queue: Empty ld 0x7f2c70eef160 response count 0 ldap_chkResponseList ld 0x7f2c70eef160 msgid 1 all 1 ldap_chkResponseList returns ld 0x7f2c70eef160 NULL ldap_int_select read1msg: ld 0x7f2c70eef160 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x7f2c70eef160 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x7f2c70eef160 0 new referrals read1msg: mark request completed, ld 0x7f2c70eef160 msgid 1 request done: ld 0x7f2c70eef160 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree TLS: can't connect: A TLS packet with unexpected length was received.. ldap_err2string ldap_start_tls: Connect error (-11) additional info: A TLS packet with unexpected length was received. ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 3 ldap_free_connection: actually freed On Mon, Sep 8, 2014 at 7:13 AM, Ryan Tandy <ryan(a)nardis.ca> wrote: > On 07/09/14 10:28 PM, Vijay Ganesan wrote: > >> But I can't seem to connect using ldaps://localhost:636 using Apache >> Directory Studio client. I get a "Error while opening connection - >> Cannot connect on the server: Connection refused" error. >> I can connect fine using ldap://localhost:389. >> > > Like Udai wrote, ldaps is deprecated, and if possible you should use > STARTTLS on the LDAP port (389) instead. But if you really need ldaps, then > edit /etc/default/slapd, add ldaps:/// to the SLAPD_SERVICES line, and > restart slapd. > > What diagnostics can be run to figure out if TLS is working correctly? >> > > LDAPTLS_CACERT=/path/to/ca.pem ldapwhoami -H ldap://server -x -ZZ > > Add '-d1' to see some debugging information, including more detailed info > from the TLS library. > -- - Vijay

10 years, 2 months

Re: new entry lost on multi-master setup (two scenarios)

by Jose Ildefonso Camargo Tolosa

Ok, then... either:I'm missing something obvious, or no one have any idea on this... Should I create a bug report based on my findings here? Thanks! Ildefonso Camargo On Tue, Apr 19, 2011 at 2:12 PM, Jose Ildefonso Camargo Tolosa <ildefonso.camargo(a)gmail.com> wrote: > Greetings, > > Any comments on this? can anybody help me verify this possible bug? > > Ildefonso. > > On Sun, Apr 17, 2011 at 2:24 PM, Jose Ildefonso Camargo Tolosa > <ildefonso.camargo(a)gmail.com> wrote: >> Greetings, >> >> At first, I was going to create a bug report, but decided to send to >> list first. I tried this with both: 2.4.23 (Debian package), and >> 2.4.25, compiled from source, bdb 4.8. >> >> After a couple of entries just disappeared on one multi-master setup I >> had, I decided to further investigate, and found this (there are two >> cases, for the same procedure): >> >> 1. Configure two LDAP servers in multi-master setup. >> 2. Make sure they replicate correctly (off course). >> 3. Shutdown one of the two ldap servers. >> 4. Create a new entry (say, ou1) on the LDAP server that is left up. >> 5. Shutdown the last LDAP server. >> 6. Start the *other* LDAP server, the one where you didn't create the entry. >> 7. Create another entry, say: ou2, so that both servers has a new >> entry, that is *not* on the other server. >> 8. Shutdown the LDAP server (both servers down now). >> 9. Start both LDAP servers. >> >> Result (case 1): one of the two newly created entries is missing on >> *one* of the servers, and only one of the entries is missing on the >> other server. >> >> Result (case 2): one entry is missing on *both* servers. >> >> Both servers has NTP, and has the same timezone (ie, time is synchronized). >> >> I'm *not* replicating cn=config (I shouldn't, because I have different >> SSL certificates on each server). Now, more details: >> >> slapd with -d 16384 gives me this on the server that misses both >> entries, on this server I created the entry dn >> ou=ou2,dc=st-andes,dc=com (and the server decided to delete it!, and, >> for some reason, it didn't detected the new ou1 entry created on the >> other server): >> >> http://www.st-andes.com/openldap/case1/log-server2-case1.txt >> >> The other server (the one that kept one entry and lost the other), on >> this server I created the entry ou=ou1,dc=st-andes,dc=com, and it says >> it was changed by peer.....: >> >> http://www.st-andes.com/openldap/case1/log-server1-case1.txt >> >> Now, I'm seeing here that it is using 000 server id... but on the >> cn=config.ldif I have: >> >> olcServerID: 1 ldap://ldap.ildetech.com:389/ >> olcServerID: 2 ldap://ldap2.ildetech.com:389/ >> >> And the syncrepl: >> >> olcSyncRepl: rid=001 provider=ldap://ldap.ildetech.com:389 >> binddn="cn=admin,dc=st-andes,dc=com" bindmethod=simple >> credentials="secret" searchbase="dc=st-andes,dc=com" >> type=refreshAndPersist retry="3 5 5 +" timeout=7 starttls=critical >> olcSyncRepl: rid=002 provider=ldap://ldap2.ildetech.com:389 >> binddn="cn=admin,dc=st-andes,dc=com" bindmethod=simple >> credentials="secret" searchbase="dc=st-andes,dc=com" >> type=refreshAndPersist retry="3 5 5 +" timeout=7 starttls=critical >> olcMirrorMode: TRUE >> >> And, as you can see on the command line, I have the URL specified on >> the -h parameter, but it seems to be ignoring it!. Or, should I >> specify the *whole* urls that I put on the -h parameter? >> (ldap://ldap2.ildetech.com:389 ldap://127.0.0.1:389/ ldaps:/// >> ldapi:///) >> >> So, I decided to change the config: >> >> On server 1 (kirara): >> >> olcServerID: 1 >> >> and >> >> olcSyncRepl: rid=002 provider=ldap://ldap2.ildetech.com:389 >> binddn="cn=admin,dc=st-andes,dc=com" bindmethod=simple >> credentials="secret" searchbase="dc=st-andes,dc=com" >> type=refreshAndPersist retry="3 5 5 +" timeout=7 starttls=critical >> olcMirrorMode: TRUE >> >> On server 2 (happy): >> >> olcServerID: 2 >> >> and >> >> olcSyncRepl: rid=002 provider=ldap://ldap2.ildetech.com:389 >> binddn="cn=admin,dc=st-andes,dc=com" bindmethod=simple >> credentials="secret" searchbase="dc=st-andes,dc=com" >> type=refreshAndPersist retry="3 5 5 +" timeout=7 starttls=critical >> olcMirrorMode: TRUE >> >> With this new setup, and following the same procedure, I get one >> missing entry on *both* servers (at least servers gets to a consistent >> state), but I still have a missing entry. The logs for this setup: >> >> Server 2 (ID 2, where I created entry: ou2 while the other server was >> down), this server decided, wrongly, to delete entry ou2: >> >> http://www.st-andes.com/openldap/case2/log-server2-case2.txt >> >> And the other server (where I created ou1): >> >> http://www.st-andes.com/openldap/case2/log-server1-case2.txt >> >> This one never saw the other entry, ou2. >> >> For both cases, the syncprov module was with default configuration: >> >> dn: olcOverlay={0}syncprov >> objectClass: olcOverlayConfig >> objectClass: olcSyncProvConfig >> olcOverlay: {0}syncprov >> structuralObjectClass: olcSyncProvConfig >> entryUUID: 24354488-e5bf-102f-9e6a-ad3cba95f7f1 >> creatorsName: cn=config >> createTimestamp: 20110318152128Z >> entryCSN: 20110318152128.935227Z#000000#000#000000 >> modifiersName: cn=config >> modifyTimestamp: 20110318152128Z >> >> What do you think? >> >> Thanks in advance! >> >> Ildefonso Camargo >> >

13 years, 6 months

OpenLDAP syncrepl over SSL

by Tony Davis

Hi, I wonder if anyone can help me with a question I have regarding an openldap setup on Redhat / Centos 5.8 using openldap-2.3.43. I am trying to setup replication, I have set this up using the simple bind method, which stores a password for the replication in the config. (This works) but I wondered if there was a way to have this replication take place using ssl certificates without the need to store the unhashed password in the slapd.conf? Is this possible? or do I still have to specify a replication user and pass, but all the auth takes place over ssl? This is my current config for replication: syncrepl rid=001 provider=ldap://master01.tld type=refreshAndPersist interval=00:00:05:00 retry="5 5 300 +" searchbase="dc=tld" attrs="*,+" bindmethod=sasl saslmech=EXTERNAL tls_cert=/etc/master02.tld.pem tls_key=/etc/master02.tld.key tls_cacert=/etc/openldap/cacerts/ca.pem tls_reqcert=demand starttls=yes mirrormode on updateref ldap://master01.tld but in the replication log i get the following: Jul 31 11:06:18 master02 slapd[6958]: do_syncrep1: rid 001 ldap_sasl_interactive_bind_s failed (7) Jul 31 11:06:18 master02 slapd[6958]: do_syncrepl: rid 001 retrying (3 retries left) Jul 31 11:06:18 master02 slapd[6958]: daemon: activity on 1 descriptor Jul 31 11:06:18 master02 slapd[6958]: daemon: activity on:

11 years, 3 months

RE: [EXTERNAL] Re: back-ldap and ldaps not working

by Quanah Gibson-Mount

--On Friday, July 07, 2017 8:10 PM +0000 Jon C Kidder <jckidder(a)aep.com> wrote: > I've removed the starttls=no syntax and the line now reads. > > olcDbStartTLS: ldaps > tls_cacert="/appl/openldap/etc/openldap/tls/cacerts.cer " > tls_reqcert=demand tls_crlcheck=none > > I have verified the change propagated to the configuration directory and > restarted the instance. I saw no errors during configuration parsing in > the log. I am still seeing this error when the chain overlay tries to > follow the referral but no complaints when syncrepl connects. I'm not sure how you do this with cn=config. With slapd.conf, it would be done via using "chain-tls" and not "tls", as per the man page: There are very few chain overlay specific directives; however, directives related to the instances of the ldap backend that may be implicitly instantiated by the overlay may assume a special meaning when used in conjunction with this overlay. They are described in slapd-ldap(5), and they also need to be prefixed by chain-. It may be worthwhile to set up a slapd.conf where "chain-tls" is specified, and see what happens with that on conversion. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

7 years, 4 months

Re: Strange TLS issue while upgrading from openldap 2.3 to 2.4

by Quanah Gibson-Mount

--On Wednesday, June 27, 2012 3:31 PM +0200 Guillaume Rousse <guillomovitch(a)gmail.com> wrote: > Sorry, I'm not a Zimbra admin, and I may have been confusing in my > explanations. The problem occurs with Zimbra acting as an LDAP client > against an external LDAP server, performing a bind operation for > authenticating users, with the following behaviour: > > Zimbra against on openldap 2.3.x server, with TLS on port 389: OK > Zimbra against on openldap 2.4.x server, on port 636: OK > Zimbra against on openldap 2.4.x server, with TLS on port 389: 30s delay Ok, so what you are saying is: You upgraded your OS to CentOS6 You use external auth The external auth from CentOS6 to your own LDAP server shows a 30 second delay on closing. That sounds like a bug in Java/JNDI. I did see some 30 second issues with RHEL6, but it was with initiating a connection, not closing it. You can see more about that at <https://stomp.colorado.edu/blog/blog/2011/06/29/on-rhel-6-ssh-dns-firewalls…> I would note that JNDI behavior varies based on startTLS vs SSL on port 636 as well. --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

12 years, 4 months

memberOf data in new replica servers 2.4.31

by Todd Stein

Hi, I have a provider server and five consumer servers, all of which have the memberOf overlay configured: overlay memberof memberof-group-oc groupOfUniqueNames memberof-member-ad uniqueMember memberof-refint true memberof-dangling ignore syncrepl rid=005 provider=ldap://<server>:389 type=refreshAndPersist interval=00:00:05:00 retry="60 10 600 +" searchbase="dc=<removed>,dc=<removed>" filter="(objectClass=*)" scope=sub attrs="*" schemachecking=off starttls=no bindmethod=simple binddn="cn=replica,dc=<removed>,dc=<removed>" credentials=<removed> When I bring a new replica online, it appears that entries are replicated in the order that they were created on the provider server which produces many "memberof_value_modify failed err=32" messages in the log, and incomplete memberOf data. To get around this, I wrote a script which empties all groups prior to replication, and then recreates the memberships after the initial replication. This seems to work, but is hardly ideal. Is there a "more correct" way of replicating memberOf values without manipulating my provider each time I bring up a new consumer? Thank you very much, Todd

12 years, 4 months

Error, ldap_start_tls failed (-11)

by arun.sasi1＠wipro.com

Hello Team, I have an issue with OpenLDAP TLS based replication Getting below error slap_client_connect: URI=ldap://gb0135embldap01.emb.slb.com Error, ldap_start_tls failed (-11) Sep 13 16:13:34 ae0043app05 slapd[2582]: do_syncrepl: rid=365 rc -11 retrying I have openLDAP in Ubuntu 9.04 version 2.4.19 then I thought to updgrade it and first I upgraded on my consumer openldap server which I migrated to Ubuntu 12.04 and version 2.4.28. I have created the certificate for my consumer from existing server. but when I go for TLS based replication, the database is not syncing and it is synching when remove starttls=no Any idea why this is causing Thanks & Regards, Arun Sasi Venmalassery ------------------------------------------------------------------------------------------------------------------------------------- Sr. Engineer - Server Management (UNIX), Wipro Ltd (Dubai) |Mob: +971 566489491 | E: arun.sasi1(a)wipro.com<mailto:koresh.dash@wipro.com> Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

12 years, 2 months

OpenLDAP + Kerberos on FreeBSD 7.2, close to working but not quite

by Allan

Hello, I've been reading around on OpenLDAP + Kerberos (FreeBSD 7.2) for authentication/authorization. I'm a bit confused on how to get it all working but I've gotten far enough that I can run getent passwd test.user and it pulls down the information from ldap (ran as root and non-root user). I can also successfully get a ticket with kinit from various users. Where I run into problems, is actually getting services to use GSSAPI. I am currently using nss_ldap and pam_ldap to authenticate during ssh login, if there's a better alternative please let me know. Here's the setup I've got: Services -> FQDN -> IP ldap/kdc -> frisbee.crazy.lan -> 192.168.1.5 ssh -> cake.crazy.lan -> 192.168.1.6 Running kinit: ============================================================== cake# kinit ldapadm ldapadm(a)CRAZY.LAN's Password: kinit: NOTICE: ticket renewable lifetime is 1 week cake# klist Credentials cache: FILE:/tmp/krb5cc_0 Principal: ldapadm(a)CRAZY.LAN Issued Expires Principal Aug 9 17:45:41 Aug 10 03:45:41 krbtgt/CRAZY.LAN(a)CRAZY.LAN ============================================================== Here's what I run to authenticate with SSH: ============================================================== cr4z3d@Allan-PC:~$ ssh -v -oGSSAPIAuthentication=yes -oGSSAPIDelegateCredentials=yes test.user(a)cake.crazy.lan OpenSSH_5.1p1 Debian-5ubuntu1, OpenSSL 0.9.8g 19 Oct 2007 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to cake.crazy.lan [192.168.1.6] port 22. debug1: Connection established. debug1: identity file /home/cr4z3d/.ssh/identity type -1 debug1: identity file /home/cr4z3d/.ssh/id_rsa type 1 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: identity file /home/cr4z3d/.ssh/id_dsa type 2 debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024 debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 FreeBSD-20080901 debug1: match: OpenSSH_5.1p1 FreeBSD-20080901 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5ubuntu1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'cake.crazy.lan' is known and matches the DSA host key. debug1: Found key in /home/cr4z3d/.ssh/known_hosts:47 debug1: ssh_dss_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received ============================================================== I've tried different options in /usr/local/etc/ldap.conf for pam_ldap/nss_ldap (the conf files are symlinked). The first one is with SASL turned on and the second with out. ============================================================== #define the ldap server's fqdn host frisbee.crazy.lan # define the base search pattern base dc=crazy,dc=lan # define the uri uri ldap://frisbee.crazy.lan # use starttls ssl start_tls # use sasl for all authentications use_sasl on # SASL authorization ID sasl_auth_id host/cake.crazy.lan #check the server's cert tls_checkpeer yes # full path to CA's cert tls_cacertfile /usr/local/etc/openldap/certs/cacert.pem # enable debug #debug 9 ============================================================== Here is the logs from the ldap server: ============================================================== Aug 9 17:47:21 frisbee slapd[86935]: conn=15 fd=11 ACCEPT from IP= 192.168.1.6:56955 (IP=0.0.0.0:389) Aug 9 17:47:21 frisbee slapd[86935]: conn=15 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Aug 9 17:47:21 frisbee slapd[86935]: conn=15 op=0 STARTTLS Aug 9 17:47:21 frisbee slapd[86935]: conn=15 op=0 RESULT oid= err=0 text= Aug 9 17:47:21 frisbee slapd[86935]: conn=15 fd=11 TLS established tls_ssf=256 ssf=256 Aug 9 17:47:21 frisbee slapd[86935]: conn=15 op=1 BIND dn="" method=163 Aug 9 17:47:21 frisbee slapd[86935]: SASL [conn=15] Failure: Couldn't find mech GSSAPI Aug 9 17:47:21 frisbee slapd[86935]: conn=15 op=1 RESULT tag=97 err=7 text=SASL(-4): no mechanism available: Couldn't find mech GSSAPI Aug 9 17:47:21 frisbee slapd[86935]: conn=15 op=2 UNBIND Aug 9 17:47:21 frisbee slapd[86935]: conn=15 fd=11 closed ============================================================== This is where I get a bit confused, it tells me that there's no mechanism for GSSAPI.. So I try changing to no SASL options in the configuration file: ============================================================== #define the ldap server's fqdn host frisbee.crazy.lan # define the base search pattern base dc=crazy,dc=lan # define the uri uri ldap://frisbee.crazy.lan # use starttls ssl start_tls #check the server's cert tls_checkpeer yes # full path to CA's cert tls_cacertfile /usr/local/etc/openldap/certs/cacert.pem # enable debug #debug 9 ============================================================== This leads to the following in the ldap logs when trying to SSH in: ============================================================== Aug 9 18:16:57 frisbee slapd[86935]: conn=87 fd=11 ACCEPT from IP= 192.168.1.6:63817 (IP=0.0.0.0:389) Aug 9 18:16:57 frisbee slapd[86935]: conn=87 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Aug 9 18:16:57 frisbee slapd[86935]: conn=87 op=0 STARTTLS Aug 9 18:16:57 frisbee slapd[86935]: conn=87 op=0 RESULT oid= err=0 text= Aug 9 18:16:57 frisbee slapd[86935]: conn=87 fd=11 TLS established tls_ssf=256 ssf=256 Aug 9 18:16:57 frisbee slapd[86935]: conn=87 op=1 BIND dn="" method=128 Aug 9 18:16:57 frisbee slapd[86935]: conn=87 op=1 RESULT tag=97 err=0 text= Aug 9 18:16:57 frisbee slapd[86935]: conn=87 op=2 SRCH base="dc=crazy,dc=lan" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=test.user))" Aug 9 18:16:57 frisbee slapd[86935]: conn=87 op=2 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass shadowLastChange shadowMax shadowExpire Aug 9 18:16:57 frisbee slapd[86935]: <= bdb_equality_candidates: (uid) not indexed Aug 9 18:16:57 frisbee slapd[86935]: conn=87 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= Aug 9 18:16:57 frisbee slapd[86935]: conn=87 op=3 SRCH base="dc=crazy,dc=lan" scope=2 deref=0 filter="(&(objectClass=posixGroup))" Aug 9 18:16:57 frisbee slapd[86935]: conn=87 op=3 SRCH attr=cn userPassword memberUid uniqueMember gidNumber Aug 9 18:16:57 frisbee slapd[86935]: conn=87 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= Aug 9 18:16:57 frisbee slapd[86935]: conn=87 op=4 SRCH base="dc=crazy,dc=lan" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=test.user))" Aug 9 18:16:57 frisbee slapd[86935]: conn=87 op=4 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass shadowLastChange shadowMax shadowExpire Aug 9 18:16:57 frisbee slapd[86935]: <= bdb_equality_candidates: (uid) not indexed Aug 9 18:16:57 frisbee slapd[86935]: conn=87 op=4 SEARCH RESULT tag=101 err=0 nentries=1 text= ============================================================== It just keeps asking for my password and outputs the following in auth.log on the ssh server: ============================================================== Aug 9 18:36:42 cake sshd[63643]: pam_ldap: error trying to bind as user "uid=test.user,ou=people,dc=crazy,dc=lan" (Server is unwilling to perform) Aug 9 18:36:42 cake sshd[63640]: error: PAM: authentication error for test.user from 192.168.1.119 Aug 9 18:36:42 cake sshd[63644]: nss_ldap: reconnected to LDAP server ldap://frisbee.crazy.lan after 1 attempt ============================================================== So while root I tried su test.user and was surprised to see that had worked. I was able to run commands as test.user souch as touch file, but if I tried whoami it just sat there until I broke the command with ctrl+c. On the ldap server I had the following in the logs: ============================================================== Aug 9 18:49:29 frisbee slapd[86935]: conn=150 fd=15 ACCEPT from IP= 192.168.1.6:60126 (IP=0.0.0.0:389) Aug 9 18:49:29 frisbee slapd[86935]: conn=150 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Aug 9 18:49:29 frisbee slapd[86935]: conn=150 op=0 STARTTLS Aug 9 18:49:29 frisbee slapd[86935]: conn=150 op=0 RESULT oid= err=0 text= Aug 9 18:49:29 frisbee slapd[86935]: conn=150 fd=15 closed (TLS negotiation failure) Aug 9 18:49:29 frisbee slapd[86935]: conn=151 fd=15 ACCEPT from IP= 192.168.1.6:60601 (IP=0.0.0.0:389) Aug 9 18:49:29 frisbee slapd[86935]: conn=151 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Aug 9 18:49:29 frisbee slapd[86935]: conn=151 op=0 STARTTLS Aug 9 18:49:29 frisbee slapd[86935]: conn=151 op=0 RESULT oid= err=0 text= Aug 9 18:49:29 frisbee slapd[86935]: conn=151 fd=15 closed (TLS negotiation failure) Aug 9 18:49:29 frisbee slapd[86935]: conn=152 fd=15 ACCEPT from IP= 192.168.1.6:50915 (IP=0.0.0.0:389) Aug 9 18:49:29 frisbee slapd[86935]: conn=152 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Aug 9 18:49:29 frisbee slapd[86935]: conn=152 op=0 STARTTLS Aug 9 18:49:29 frisbee slapd[86935]: conn=152 op=0 RESULT oid= err=0 text= Aug 9 18:49:29 frisbee slapd[86935]: conn=152 fd=15 closed (TLS negotiation failure) ============================================================== There seems to be something wrong with the TLS negotiation, but I've ensured that the CN for my key is frisbee.crazy.lan. I Set the CA's cert CN to allanfeid.com (i own the domain) At this point I'm unsure where to go to continue troubleshooting and getting this to work. I'm just trying to get a solid Single Sign-on solution using kerberos, ldap, and sasl for a learning experience. If there is a more appropriate way of acheiving this, I'm open to suggestions. Here's my ldap and slapd configuration files: (server) frisbee# cat /usr/local/etc/openldap/ldap.conf ============================================================== TLS_CACERT /usr/local/etc/openldap/certs/CA/cacert.pem ============================================================== (client) cake# cat /usr/local/etc/openldap/ldap.conf ============================================================== # path to CA's cert TLS_CACERT /usr/local/etc/openldap/certs/cacert.pem # define base to our search BASE dc=crazy,dc=lan # define uri to openldap URI ldap://frisbee.crazy.lan ============================================================== (server) frisbee# cat /usr/local/etc/openldap/slapd.conf note: i removed a lot of comments to save space ============================================================== include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/duaconf.schema include /usr/local/etc/openldap/schema/dyngroup.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/krb5-kdc.schema pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args # SSL/TLS cipher order preference TLSCipherSuite HIGH # Full path to CA cert file TLSCACertificateFile /usr/local/etc/openldap/certs/CA/cacert.pem # Full path to server's TLS cert TLSCertificateFile /usr/local/etc/openldap/certs/private/slapdcert.pem # Full path to server's TLS key TLSCertificateKeyFile /usr/local/etc/openldap/certs/private/slapdkey.pem # Password hashing mechanism password-hash {SSHA} # log level loglevel 256 # refuse simple binds disallow bind_simple ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=crazy,dc=lan" directory /var/db/openldap-data # Indices to maintain index default eq,pres index objectClass eq index cn,sn,givenname,mail eq,pres,sub # ACL Definitions authz-policy from authz-regexp uid=(.*),cn=crazy.lan,cn=GSSAPI,cn=auth uid=$1,ou=people,dc=crazy,dc=lan # SASL hostname sasl-host frisbee.crazy.lan access to * by dn="uid=ldapadm,cn=gssapi,cn=auth" write by * read access to * by * read ==============================================================

15 years, 3 months

Re: SASL EXTERNAL, sasldb2 and authz-regexp

by 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" >> >> after restarting both servers I do get the error: >> >> <==slap_sasl2dn: Converted SASL name to <nothing> >> SASL [conn=0] Error: unable to open Berkeley db /etc/sasldb2: No such >> file or directory > > [...] > > I don't see a configuration for client certs, as an example I provide > my slapd.conf > > syncrepl rid=042 > provider=ldap://rubin.avci.de > sizelimit=unlimited > bindmethod=sasl > saslmech=external > starttls=yes > tls_cert=/etc/openldap/certs/replicator.pem > tls_key=/etc/openldap/certs/replicator-key.pem > tls_cacert=/etc/openldap/certs/avciCA.pem > tls_reqcert=demand > searchbase="o=avci,c=de" > scope=sub > [...] Hi Dieter, it looks like I still have some misunderstanding of where to set some options after following my manual.... Maybe your book is better ;-) I added the tls_* options to my consumer slapd.conf and started both servers again. Now I still get messages on the provider which confuse me, in particular the line "Converted SASL name to <nothing>" do_sasl_bind: dn (cn=replicator,dc=filmakademie,dc=de) mech EXTERNAL ==>slap_sasl2dn: converting SASL name email=webmaster(a)filmakademie.de,cn=ldap2.filmakademie.de,ou=it officenet,o=filmakademie baden-wuerttemberg gmbh,l=ludwigbsburg,st=baden-wuerttemberg,c=de to a DN slap_authz_regexp: converting SASL name email=webmaster(a)filmakademie.de,cn=ldap2.filmakademie.de,ou=it officenet,o=filmakademie baden-wuerttemberg gmbh,l=ludwigbsburg,st=baden-wuerttemberg,c=de <==slap_sasl2dn: Converted SASL name to <nothing> SASL Authorize [conn=0]: proxy authorization allowed authzDN="" send_ldap_sasl: err=0 len=-1 do_bind: SASL/EXTERNAL bind: 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" sasl_ssf=0 Any suggestions? Thanks for your response, /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

14 years, 7 months

openldap-technical search results for query "starttls"