openldap-technical

openldap-technical@openldap.org

7 participants
9864 discussions

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

Locker killed to resolve a deadlock
by Jorgen Lundman 22 Sep '17

22 Sep '17

openldap-2.4.36 db-4.8.30.NC Solaris-10u11 Hello list, We've been running those LDAP versions for years and we have been pretty pleased with it. But then "they" went and added an automated test script, that adds some records every 10 mins, confirms they are replicated all the way to the frontends, then deletes the records. This has started to cause trouble, in the last month or so. The errors are: Sep 22 06:08:26 vmx02 slapd[14039]: [ID 960831 local4.debug] => bdb_idl_delete_key: c_get failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30994) Sep 22 06:13:37 vmx02 last message repeated 36 times Sep 22 06:13:44 vmx02 slapd[14039]: [ID 960831 local4.debug] => bdb_idl_delete_key: c_get failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30994) Sep 22 06:20:17 vmx02 last message repeated 39 times Until we restart slapd. Setup is: prov (1 writer) -> ldapmaster -> ldapslave(s) -> frontend(s) -> ldapslave(s) -> frontend(s) -> frontend(s) The problem happens the most on frontend servers, but occasionally on ldapslaves, and twice now on ldapmaster. So we don't think it is syncrepl related. One answer would be to stop the 10min "ldap sync test" script of course, but it would be nice to solve the actual problem. slapd.conf, on slaves/frontend look like: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/company-schema/qmail.schema include /usr/local/etc/openldap/company-schema/local.schema include /usr/local/etc/openldap/company-schema/RADIUS-LDAPv3.schema include /usr/local/etc/openldap/company-schema/AmavisdLDAP.schema include /usr/local/etc/openldap/company-schema/analyse.schema include /usr/local/etc/openldap/company-schema/formail.schema include /usr/local/etc/openldap/company-schema/filter.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args loglevel sync database monitor access to dn.subtree="cn=Monitor" by dn="cn=admin,dc=company,dc=jp" read by * none database bdb suffix "dc=company,dc=jp" rootdn "cn=admin,dc=company,dc=jp" lastmod on checkpoint 128 15 overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 cachesize 10000 idlcachesize 15000 directory /usr/local/var/openldap-data index objectClass eq index uid eq index uidNumber eq index mail eq index mailAlternateAddress pres,eq index deliveryMode eq index accountStatus eq index gecos eq index radiusGroupName eq index o pres,eq index entryCSN,entryUUID eq dbconfig set_lk_detect DB_LOCK_DEFAULT dbconfig set_lg_max 52428800 dbconfig set_cachesize 0 67108864 1 dbconfig set_flags db_log_autoremove dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 syncrepl rid=345 provider=ldap://ldapslave01 type=refreshAndPersist interval=00:00:00:30 searchbase="dc=company,dc=jp" filter="(objectClass=*)" attrs="*,+" scope=sub schemachecking=off bindmethod=simple binddn="uid=replicate,o=companyserver.jp,ou=admin,dc=company,dc=jp" credentials="<secret>" retry="60 10 300 +" updateref ldap://ldapmaster01 -- Jorgen Lundman | <lundman(a)lundman.net> Unix Administrator | +81 (0)90-5578-8500 Shibuya-ku, Tokyo | Japan

1 0

Re: slapd: null_callback : error code 0x14
by Quanah Gibson-Mount 22 Sep '17

22 Sep '17

--On Tuesday, September 19, 2017 7:40 PM -0700 "Paul B. Henson" <henson(a)acm.org> wrote: > Hmm. I only have one active master, and it's the only server receiving > updates. Let me try including some more detail on an error from this > morning. > > So here's the error on the replica: > > Sep 19 03:56:19 coeus slapd[43551]: null_callback : error code 0x14 > Sep 19 03:56:19 coeus slapd[43551]: syncrepl_message_to_op: rid=003 > be_modify uid=egr44503,ou=group,dc=cpp,dc=edu (20) Well, my first question is, do you see these changes to this group entry in the log from your other rid as well? I.e., if it is being applied twice, you should see each modification logged twice. Usually with sync logging, you have lines noting what the CSN is that's being processed as well. There's not enough log information here to act on. :) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 2

Re: olcPasswordHash per database
by Howard Chu 21 Sep '17

21 Sep '17

Nikos Voutsinas wrote: > Hello, > > We need for a specific database (olcDatabase) to force an SHA password hash, > while keeping the default hashing scheme for the rest of them (the SSHA). > However it seems that olcPasswordHash is not allowed with-in an olcDatabase > object. > > What's the suggested method to overwrite the default password hash for a > specific db? Not currently supported. You're welcome to submit a patch to implement this. In the meantime, you can run a separate slapd instance, and tie it back in to the first slapd using back-ldap. Overall it's probably a bad idea though. If you have anything outside of slapd depending on the specific password hash mechanism, you're doing something wrong. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical