openldap-technical

openldap-technical@openldap.org

18 participants
9897 discussions

Openldap 2.4.40-13.el7 on CentOS 7 and SSL/TLS
by Robert Heller 22 Sep '17

22 Sep '17

What is the *correct* way to set up Openldap to use SSL/TLS? The documentation is somewhat confusing. My cn=config.ldif file looks like this: dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/openldap/slapd.args olcPidFile: /var/run/openldap/slapd.pid olcTLSCACertificatePath: /etc/openldap/certs olcTLSCACertificateFile: /etc/openldap/certs/ca_cert.pem olcTLSCertificateFile: /etc/openldap/certs/c764guest.cert olcTLSCertificateKeyFile: /etc/openldap/certs/privkey.pem structuralObjectClass: olcGlobal entryUUID: 7e6a3298-30da-1037-9c4f-458bcc6c0ce0 creatorsName: cn=config createTimestamp: 20170918163057Z entryCSN: 20170918163057.597791Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20170918163057Z in /etc/openldap/certs are these files: [root@c764guest heller]# ls -l /etc/openldap/certs total 104 -rw-r--r--. 1 root root 5137 Sep 22 14:42 c764guest.cert -rw-r--r--. 1 root root 1074 Sep 22 14:37 c764guest.csr -rw-r--r--. 1 root root 1696 Sep 22 14:18 ca-cert.pem -rw-r--r--. 1 root root 65536 Sep 18 12:30 cert8.db -rw-r--r--. 1 root root 16384 Sep 18 12:30 key3.db -r--r-----. 1 root ldap 45 Jan 10 2016 password -rw-r--r--. 1 root root 1834 Sep 22 14:37 privkey.pem -rw-r--r--. 1 root root 16384 Jan 10 2016 secmod.db /etc/sysconfig/slapd contains: # OpenLDAP server configuration # see 'man slapd' for additional information # Where the server will run (-h option) # - ldapi:/// is required for on-the-fly configuration using client tools # (use SASL with EXTERNAL mechanism for authentication) # - default: ldapi:/// ldap:/// # - example: ldapi:/// ldap://127.0.0.1/ ldap://10.0.0.1:1389/ ldaps:/// SLAPD_URLS="ldapi:/// ldap://127.0.0.1/ ldap://192.168.250.98/ ldaps:///" # Any custom options #SLAPD_OPTIONS="-s 128" # Keytab location for GSSAPI Kerberos authentication #KRB5_KTNAME="FILE:/etc/openldap/ldap.keytab" /etc/openldap/ldap.conf contains: # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. BASE dc=deepsoft,dc=com URI ldaps://192.168.250.98/ TLS_CACERT /etc/openldap/certs/ca-cert.pem TLS_CACERTDIR /etc/openldap/certs TLS_REQCERT demand #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never TLS_CACERTDIR /etc/openldap/cacerts # Turning this off breaks GSSAPI used with krb5 when rdns = false SASL_NOCANON on But now when I try to do a ldapsearch I get: [heller@c764guest ~]$ ldapsearch -x ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) even though: [root@c764guest heller]# netstat -a|grep ldap tcp 0 0 0.0.0.0:ldaps 0.0.0.0:* LISTEN tcp 0 0 c764guest.deepsoft:ldap 0.0.0.0:* LISTEN tcp 0 0 localhost:ldap 0.0.0.0:* LISTEN tcp 0 0 c764guest.deepsof:33302 c764guest.deepsoft:ldap ESTABLISHED tcp 0 0 c764guest.deepsoft:ldap c764guest.deepsof:33302 ESTABLISHED tcp6 0 0 [::]:ldaps [::]:* LISTEN Is this correct? I am not sure if I should be using ldaps:/// or not. And I am not sure what the proper "magic" to get TLS working is. -- Robert Heller -- 978-544-6933 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services heller(a)deepsoft.com -- Webhosting Services

2 1

Re: Getting ldappasswd and PAM in the same page under CentOS 7
by Quanah Gibson-Mount 22 Sep '17

22 Sep '17

--On Friday, September 22, 2017 10:45 AM -0400 Robert Heller <heller(a)deepsoft.com> wrote: > Operation 11 *seems* to be fetching the uid, using self, which has write > access, which implies read access, which seems to work just fine, using > ldapsearch from the command line: > > [heller@c764guest ~]$ ldapsearch -D > uid=test2user,ou=People,dc=deepsoft,dc=com -W -LLL '(uid=test2user)' uid > Enter LDAP Password: > dn: uid=test2user,ou=People,dc=deepsoft,dc=com > uid: test2user Is PAM actually bound as uid=testuser2, or is it bound as anonymous or some other DN? I can't tell from the little snippet of log that was in this thread. So yes, it works for you using ldapsearch when you bind as uid=test2user, but is that what pam is using? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Getting ldappasswd and PAM in the same page under CentOS 7
by Robert Heller 22 Sep '17

22 Sep '17

I am having a hard time setting a user password using ldap (OpenLDAP 2.4.40-13.el7) on a CentOS 7 system. I have installed OpenLDAP 2.4.40-13.el7 (stock CentOS 7 server and client), nss-pam-ldapd (0.8.13-8.el7) and used authconfig to enable ldap. I have created a user in the ldap database, and getent works just fine -- the uid and gid are seen, etc. But I cannot set the user's password in a way that works for su (and presumably login/slogin, etc.). I am using ldappasswd to set the user's password. I am thinking that PAM and ldappasswd are using *different* oneway encryption methods and I am guessing I need to update a configuration somewhere (either for pam, sssd, or nslcd), but I am not finding it. -- Robert Heller -- 978-544-6933 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services heller(a)deepsoft.com -- Webhosting Services

5 13

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 22 Sep '17

22 Sep '17

--On Friday, September 22, 2017 8:38 AM -0400 Frank Swasey <Frank.Swasey(a)uvm.edu> wrote: > My take away from this lengthy discussion is the following: > > 1) cn=config is not ready for "make; make test; make install" level of > upgrade. Until it is, it is not usable in a production environment. I've been doing binary upgrades on deployments using cn=config for years (Since 2011 or so), with servers all across the globe. However, I didn't use ppolicy in my configurations. The real issue with ppolicy is that it shouldn't be shipping with a separate schema, and instead it should have its configuration schema fully internalized. I've already made a note to that that needs to be fixed for OpenLDAP 2.5 so it doesn't occur again. Outside of that, I'm not aware of it being deficient in comparison to slapd.conf, and I'm quite aware of numerous ways in which it is substantially better. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 22 Sep '17

22 Sep '17

--On Friday, September 22, 2017 10:47 AM -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > The current ITS system is already scheduled for replacement. The current > OpenLDAP infrastructure is already being migrated *being migrated (one server complete, one underway as time allows). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 22 Sep '17

22 Sep '17

--On Wednesday, September 20, 2017 6:40 PM +0200 Ondřej Kuzník <ondra(a)mistotebe.net> wrote: > In terms of that, some of us would like to have a different bug tracking > system, if it supports attaching patches to it I guess that's something > you'd find a bit more welcoming. The current ITS system is already scheduled for replacement. The current OpenLDAP infrastructure is already being migrated (The old git-master server was migrated earlier this year). The larger issue with migrating the other piece of infrastructure is it is a mess to detangle. It's a rather old debian box that still has freeBSD binaries on it from when it was migrated from freeBSD to debian, and the current software setup is... interesting. ;) So as a part of migrating it to the new server, I'm redoing the configurations and documenting everything as I go along. It's rather time consuming. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Proper Way To Securely Bind With LDAP Server
by Douglas Duckworth 22 Sep '17

22 Sep '17

Hi As I have read the StartTLS extended operation seems to be preferred over SSL: http://www.openldap.org/faq/data/cache/605.html Therefore* I have always* used -ZZ with ldap://URI to bind to my server. Eg: ldapsearch -ZZ -b base -H ldap://server -D uid=admin,ou=users,base -W cn=search I thought this would thus encrypt my password by encapsulating the TCP 389 connection with TLS encryption. However, to my severe dismay, I can see my password in "-d3" debug output, using the above command, as well as when dropping the -ZZ and using ldaps:// Can you please provide guidance? ldap_url_parse_ext(ldap://ldap.server.domain) ldap_create ldap_url_parse_ext(ldap://ldap.server.domain: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 ldap.server.domain:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying LDAP_SERVER:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success 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_write: want=31, written=31 0000: 30 1d 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 0....w...1.3.6.1 0010: 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .4.1.1466.20037 ldap_result ld 0xdea060 msgid 1 wait4msg ld 0xdea060 msgid 1 (infinite timeout) wait4msg continue ld 0xdea060 msgid 1 all 1 ** ld 0xdea060 Connections: * host: ldap.server.domain port: 389 (default) refcnt: 2 status: Connected last used: Fri Sep 22 10:23:35 2017 TLS certificate verification: subject: CN=ldap.server.domain,OU=BLAH,issuer: CN=InCommon RSA Server CA,OU=InCommon,O=Internet2,L=Ann Arbor,ST=MI,C=US, cipher: *AES-256*, *security level: high*, secret key bits: 256, total key bits: 256, cache hits: 0, cache misses: 0, cache not reusable: 0 Enter LDAP Password: <-- I Enter Password The server logs show: Sep 22 10:27:41 server slapd[21471]: conn=131126 op=1 BIND dn="admin" method=128 Sep 22 10:27:41 server slapd[21471]: conn=131126 op=1 BIND dn="admin" mech=SIMPLE ssf=0 The password then appears in -d3 output after I authenticate. However, I do not see the password in tcpdump using a full packet capture on both the client and ldap server. As expected I do see the password in tcpdump when dropping the -ZZ and using -x for simple bind. So in summary seeing credentials when using -ZZ and -d3 should not bring concern as they're encrypted over the wire. So I guess can you explain how "-d3" works? Thanks, Douglas Duckworth, MSc, LFCS HPC System Administrator Scientific Computing Unit Physiology and Biophysics Weill Cornell Medicine E: doug(a)med.cornell.edu O: 212-746-6305 F: 212-746-8690

1 0

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 22 Sep '17

22 Sep '17

--On Friday, September 15, 2017 12:24 PM -0700 Ryan Tandy <ryan(a)nardis.ca> wrote: > There was some talk, either in IRC or on -devel, of creating a way for > cn=config to reference schema files (possibly LDIF) on disk rather than > importing them into the config database. I think that would be an > improvement. Importing schemas into cn=config is cool - especially if you > want to replicate the config - but I'm not sure it's a good default. Since ordering is mandatory, it would be nice if you could just do something like: olcSchemaFile: {0}include: file://$ABS_SCHEMADIR/core.ldif olcSchemaFile: {1}include: file://$ABS_SCHEMADIR/cosine.ldif olcSchemaFile: {2}include: file://$ABS_SCHEMADIR/inetorgperson.ldif etc. Then you could change the schema files on disk, and cn=config would just load them in when it started. It'd certainly make the behavior analagous to slapd.conf, and allow for easier rollback/testing. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 2

Re: Olc deployment vs slapd.conf based deployment
by Howard Chu 22 Sep '17

22 Sep '17

Frank Swasey wrote: > My take away from this lengthy discussion is the following: > > 1) cn=config is not ready for "make; make test; make install" level of > upgrade. Until it is, it is not usable in a production environment. Nobody is denying that more work needs to be done. Where did you ever get that impression? > 2) As usual, the OpenLDAP developers are saying "my way or the highway". This is totally ignorant and off base. Crazy suggestions like "OpenLDAP should change its license to suit my needs" are completely ludicrous. Nobody within the OpenLDAP Project has the authority to do that. There's no *my way* here, there's simply reality vs delusion. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Olc deployment vs slapd.conf based deployment
by Howard Chu 22 Sep '17

22 Sep '17

Radovan Semancik wrote: > Hi, > > On 09/18/2017 02:44 PM, Howard Chu wrote: >> These perennial arguments keep coming up. If you want things to improve, >> contribute. Anyone can write a manpage. Hardly anyone ever does. Everyone >> sits back and moans while waiting for someone else to fix things for them. >> That's not what open source projects and communities are about. > > I would ... if this was a wiki, or github-like pull request and if there was > an example of how a good result should look like. But it does not make sense > for me to spend few hours just figuring out how to contribute documentation > fix. So you're still saying, it's fine for other people to put in the hours to produce something you benefit from, but it's too much trouble for you to contribute in return. And in the meantime, it's perfectly OK for you to sit back and complain that things haven't been fixed. Got it. If that's the way everybody feels then we can all just shut off the lights and go home now. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

4 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical