openldap-technical February 2015

openldap-technical@openldap.org

66 participants
63 discussions

Can't get certificates installed on new server
by Philip Colmer 26 Feb '15

26 Feb '15

I'm getting a generic error 80 when I try to use ldapmodify to configure my LDAP server to use a SSL certificate. Here is the LDIF I'm using: dn: cn=config changetype: modify add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/gd_bundle-g2-g1.pem - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/private/wildcard.linaro.org.key - add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/certs/wildcard.linaro.org.crt and the command: ldapmodify -v -x -H ldapi:/// -f certinfo.ldif -D cn=admin,cn=config -W Running logging at the highest level doesn't seem to give me much to go on ... Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: daemon: epoll: listen=9 active_threads=0 tvp=NULL Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: daemon: epoll: listen=10 active_threads=0 tvp=NULL Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: daemon: epoll: listen=11 active_threads=0 tvp=NULL Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: conn=1001 op=1 do_modify Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: conn=1001 op=1 do_modify: dn (cn=config) Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: >>> dnPrettyNormal: <cn=config> Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: <<< dnPrettyNormal: <cn=config>, <cn=config> Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: conn=1001 op=1 modifications: Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: #011add: olcTLSCACertificateFile Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: #011#011one value, length 34 Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: #011add: olcTLSCertificateFile Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: #011#011one value, length 40 Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: #011add: olcTLSCertificateKeyFile Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: #011#011one value, length 38 Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: conn=1001 op=1 MOD dn="cn=config" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: conn=1001 op=1 MOD attr=olcTLSCACertificateFile olcTLSCertificateFile olcTLSCertificateKeyFile Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: <= acl_access_allowed: granted to database root Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_required entry (cn=config), objectClass "olcGlobal" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "objectClass" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "cn" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcConfigFile" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcConfigDir" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcArgsFile" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcAttributeOptions" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcAuthzPolicy" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcConcurrency" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcConnMaxPending" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcConnMaxPendingAuth" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcGentleHUP" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcIdleTimeout" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcIndexSubstrIfMaxLen" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcIndexSubstrIfMinLen" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcIndexSubstrAnyLen" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcIndexSubstrAnyStep" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcIndexIntLen" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcListenerThreads" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcLocalSSF" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcLogLevel" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcPidFile" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcReadOnly" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcReverseLookup" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcSaslSecProps" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcSockbufMaxIncoming" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcSockbufMaxIncomingAuth" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcThreads" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcTLSVerifyClient" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcTLSProtocolMin" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcToolThreads" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcWriteTimeout" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "structuralObjectClass" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "entryUUID" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "creatorsName" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "createTimestamp" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcTLSCACertificateFile" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcTLSCertificateFile" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "olcTLSCertificateKeyFile" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "entryCSN" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "modifiersName" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: oc_check_allowed type "modifyTimestamp" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: send_ldap_result: conn=1001 op=1 p=3 Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: send_ldap_result: err=80 matched="" text="" Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: send_ldap_response: msgid=2 tag=103 err=80 Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: conn=1001 op=1 RESULT tag=103 err=80 text= Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: daemon: activity on 1 descriptor Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: daemon: activity on: Feb 25 14:03:08 ip-10-166-134-219 slapd[1651]: 14r I've checked that the user that slapd is running under can read the three files. Any suggestions or clarification on what I've overlooked? Thanks. Regards Philip

4 4

LMDB set range to return less than or equal key
by Victor Baybekov 25 Feb '15

25 Feb '15

Hi! In my use case I have found that MDB_SET_RANGE and MDB_GET_BOTH_RANGE queries are much more useful, in 90+% cases, when they return less than or equal key, not greater or equal. I have tested a quick implementation of "get less or equal", and it is c.50% slower in memory. I must say that if someone told me, before I learned about LMDB, that even with 50% less than original performance such numbers are possible, I would not believe - both are millions ops per seconds in my isolated in-memory microbenchmark. But still, such queries are building blocks of N operations that could require non-linear (N^x, x > 1) number of queries and I am interested if I could easily speed this up closer to the built-in MDB_SET_RANGE. The C code is in this gist <https://gist.github.com/buybackoff/59dabc70fa5ec8351bbe#file-mdb_cursor_get…>. I call it from C# via P/Invoke, the test code is here <https://gist.github.com/buybackoff/59dabc70fa5ec8351bbe#file-c-test-via-pin…>. I made sure that only C methods are different, all other code is the same in C#. But even with the P/Invoke overhead the difference is visible. My naive approach is to use MDB_SET_RANGE as the first step and, if the key from this query is not equal to the requested key, to call MOVE_PREV. Other than an additional call to MOVE_PREV, it requires allocation of a copy of the original key, because MDB_SET_RANGE overwrites it and I haven't found a better way to compare the requested key with the key returned after MDB_SET_RANGE. My experience with C (without # or ++) is 4 days less than 2 month, LMDB was the major reason I started, so my code could be really stupid... If it is not, are there other options? E.g. to recompile LMDB for "less or equal" as default behavior. I have tried to change this code inside `mdb_node_search`: if (rc *>* 0) { /* Found entry is *less than* the key. */ i*++*; /* Skip to get the *smallest entry larger than* key. */ if (!IS_LEAF2(mp)) node = NODEPTR(mp, i); } to this code: if (rc *<* 0) { /* Found entry is greater than the key. */ i*--*; /* Skip to get the *largest entry smaller than* key. */ if (!IS_LEAF2(mp)) node = NODEPTR(mp, i); } but it fails badly. Is "greater or equal" approach deeply rooted in the design of LMDB, or I have missed just a small number of other places and it is feasible to change the behavior globally? If that is possible, I would like to do so and to use my current approach for "greater or equal" instead. I cannot test this quickly on a larger-that-RAM data set (because I struggle with my 128Gb laptop drive). But as far as I understand, in most cases MDB_SET_RANGE will load the page with a previous key in RAM - usually this is the same page or one that has been touched during the search? So in the on-disk scenario the incremental MOVE_PREV will be negligible and I should not worry about that? Is there another, completely different and better, way to perform "less than or equal" query? Thanks! Victor

2 1

SSL CA Certificate issue ../../CA/newcerts: No such file or directory
by jeevan kc 24 Feb '15

24 Feb '15

Hi all I'm having trouble with the generation of CA. Please see the error at the bottom and I'd appreciate any help to fix the issue. [root@lap00551]# mkdir /var/myca/[root@lap00551]cd/var/myca[root@lap00551 myca]# /usr/local/openssl.1.0.0d/misc/CA.sh -newcaCA certificate filename (or enter to create) Making CA certificate ...Generating a 1024 bit RSA private key.............++++++........................++++++writing new private key to './demoCA/private/./cakey.pem'Enter PEM pass phrase:Verifying - Enter PEM pass phrase:-----You are about to be asked to enter information that will be incorporatedinto your certificate request.What you are about to enter is what is called a Distinguished Name or a DN.There are quite a few fields but you can leave some blankFor some fields there will be a default value,If you enter '.', the field will be left blank.-----Country Name (2 letter code) [GB]:USState or Province Name (full name) [Berkshire]:****Locality Name (eg, city) [Newbury]:****Organization Name (eg, company) [My Company Ltd]:****Organizational Unit Name (eg, section) []:DISCommon Name (eg, your name or your server's hostname) []:lap00551.****Email Address []:**** Please enter the following 'extra' attributesto be sent with your certificate requestA challenge password []:****An optional company name []:****Using configuration from /etc/pki/tls/openssl.cnfEnter pass phrase for ./demoCA/private/./cakey.pem:I am unable to access the ../../CA/newcerts directory../../CA/newcerts: No such file or directory Regards,Jeevan

2 2

SSL CA Certificate issue ../../CA/newcerts: No such file or directory
by jeevan kc 24 Feb '15

24 Feb '15

1 0

create new user with same UID and GID
by Fabián M Sales 23 Feb '15

23 Feb '15

I am creating users in LDAP and I assign different UID and GUI. For example. uid = _16661_ (user1) gid = _16664_ (user1) groups = _16664_ (user1) I need that when the user is created is created with the same UID and GID for user created. as I do this? I would love for it to be so: uid = _16664_ (user1) gid = _16664_ (user1) groups = _16664_ (user1) Thanks in advance -- Firma Institucional *Fabián* *M. Sales *Soporte Técnico & I.T.I Linux *DonWeb * La Actitud Es Todo www.DonWeb.com ------------------------------------------------------------------------ Nota de confidencialidad: Este mensaje y archivos adjuntos al mismo son confidenciales, de uso exclusivo para el destinatario del mismo. La divulgación y/o uso del mismo sin autorización por parte de DonWeb.com queda prohibida. DonWeb.com no se hace responsable del mensaje por la falsificación y/o alteración del mismo. De no ser Ud el destinatario del mismo y lo ha recibido por error, por favor, notifique al remitente y elim?elo de su sistema. Confidentiality Note: This message and any attachments (the message) are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited by DonWeb.com. DonWeb.com shall not be liable for the message if altered or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender Nota de Confidencialidade: Esta mensagem e seus eventuais anexos podem conter dados confidenciais ou privilegiados. Se você os recebeu por engano ou não é um dos destinatários aos quais ela foi endereçada, por favor destrua-a e a todos os seus eventuais anexos ou copias realizadas, imediatamente. É proibida a retenção, distribuição, divulgação ou utilização de quaisquer informações aqui contidas. Por favor, informenos sobre o recebimento indevido desta mensagem, retornando-a para o autor.

7 8

root dn password: which one is the reference?
by Jephte Clain 23 Feb '15

23 Feb '15

hello, I have an ldap server with rootdn cn=admin,dc=domain,dc=tld and password set in cn=config (this is openldap 2.4.40 on debian squeeze) I have also the ldap objet cn=admin,dc=domain,dc=tld in the database, with a *different* password both password seem to authenticate. is this expected? This used NOT to work (I don't remember but I think it was on an old version using slapd.conf). I have always considered the password defined in cn=config to be the last resort password, in case the database is corrupted. but when the database is active, I expect the password in the database to be the reference. Being able to regularly change the root dn password looks like a good thing to me. Obviously I'm wrong :-) Out of curiosity, when did this change, if ever? TIA. with best regards, -- Jephté Clain Direction des Systèmes d'Information et des Usages Numériques - 2IG Tél. 0262 93 86 31 Fax. 0262 93 81 06

2 2

cross DIT/TLD rootdn - or allow a foreign rootdn
by lejeczek 22 Feb '15

22 Feb '15

hi everybody I'm just looking at the surface and still have lots to read/lean, but I thought this one should be easy to achieve/set up. Having multiple top level domains I wanted to allow rootdn from other domain (say B) to have similar access rights to rootdn of home domain (say A) and i put this into config of A domain to * by dn="cn=manger,dc=B,dc=topdom" manage but I get infamous: Insufficient access (50) additional info: no write access to parent Is possible what I try to do, does LDAP allow, i prepared for such a scenario? If yes can I get some light shed on what I got wrong or did not get at all. many thanks.

2 2

porting an old bdb wrapper to lmdb - any tips/docs?
by Paul DeBruicker 22 Feb '15

22 Feb '15

Hi - I'm going to port a Smalltalk BerkeleyDB wrapper that was created in 2002 to LMDB. Are there any docs that might help me get my bearings? I've found the ones in the LMDB source code/doxygen site. Thanks Paul

1 0

replica from a to b
by Desfosses, Francois 20 Feb '15

20 Feb '15

Hello World! First of all, I'm not very familiar with LDAP slapd.d config style, well neither with slapd.conf! (I took those server from the old sysadmin, so I'm still in the learning process.) I've been banging my head on the walls for the past 2 days with this, and I can't make it work. I have a server, up and running, and working. (Inside amazon aws) I cloned that server, and started it, working just fine. Then I went on this; https://documentation.fusiondirectory.org/en/documentation/replication_syncr epl Executed that stuff on the first/primary/provider, as mentioned on that page. I'm not even sure it's working but, LDAP is still working as well as sssd. So nothing seems broken. (using Centos 6.6 x86_64) I went on the cloned/secondary/consumer and executed that part mentioned above. But I can't make the LDIF working, I'm getting errors. As I am looking at my /etc/openldap/slapd.d/cn=config/ folder, I see that I have all the files EXCEPT the olcDatabase={1}bdb.ldif, this leads me to think that there is no DB, and therefore, I cannot create or use the creation portion of the replica. Now I am confused. What should be my next step? Create from scratch a new openldap empty DB? Or just duplicate via RSYNC the primary info including the /var/lib/ldap folder ? Or, maybe that site I was looking up brought me in the wrong direction and there might be a better place that explain how to set up a replica with the slapd.d configuration style ? Best regards Francois D.

4 4

LMDB: comparison contexts, lifetimes, composite keys
by Lauri Alanko 19 Feb '15

19 Feb '15

Hello. I have some non-OpenLDAP-related LMDB questions and suggestions. I hope this is the correct list for them. If not, please point to a better venue. It seems that MDB_cmp_func is a plain binary function without a context parameter. This makes it impossible to tune a comparison operation at runtime (without libffi magic, anyway). In particular, it makes it difficult to create bindings for the set_compare operation in other languages. Funnily enough MDB_rel_func _does_ have a context pointer, even though it is not used yet. So would it be feasible to add a similarly contextful version of the comparison function? (Arguably these two could share the context pointer, it could just be mdb_dbi_set_userctx.) Although the documentation in lmdb.h is generally good, it's a bit wishy-washy when it comes to lifetimes of data. The mdb_get documentation only says: "The memory pointed to by the returned values is owned by the database". My understanding is that the pointers to the key/data pair retrieved from the database are valid for the duration of the current transaction. After the transaction is over, the page in which the key/data pair was located may be reclaimed for other uses. If this is correct, could it be reflected in the documentation a bit more explicitly? The current behavior is a bit inconsistent, though, in that depending on the operation, mdb_cursor_get may or may not update the `key` argument to point to the key in the database. It would be much clearer if after the call it _always_ pointed to the key in the database, even for operations (like MDB_SET_KEY) where the value of the key would be the same as the input argument. Finally, what is the recommended way of dealing with composite keys? Suppose I want to look up a value associated to a pair of keys (say, a directory id and a filename). There are several ways of doing this: * Encode the pair (key1, key2) into a single key, use that normally. * Use MDB_DUPSORT, encode each (key2, value) as data for a duplicate key key1. Make sure the encoding is such that the data are sorted by key2. Then use MDB_GET_BOTH_RANGE to look up the nearest entry for a given (key1, key2) pair and check it actually has the correct key2. * Create a named database for each key1, store its name as the data for key1. Store normal (key2, value) pairs in the named database, Each of these has its problems. The first is somewhat wasteful, especially if, say, key1 is long and often repeated. The second is what I use, but it feels a bit kludgy: I'm supposed to use a key-value store yet I still have to manually decode and encode key-value pairs to and from their constituents. The third has lots of overhead if there are very few entries for a given key1, and it requires us to manually manage the lifetimes of the named databases. My understanding is that MDB_DUPSORT internally does something close to the third option (but with optimizations to avoid wasting pages for just a few entries), but just using empty data items in the key-specific subdatabase. Would it then be feasible to add direct support for composite keys by allowing non-empty data there? Thanks, Lauri Alanko la(a)iki.fi

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical February 2015