Re: allow to pass on "undefined" filters in meta

[Charles Bueche]

Hi all,

I had exactly the same problem last June. Pierangelo Masarati helped me
understanding the problem. He even provided the code for a contrib
module to solve this issue. You can search the list for the subject
"back_meta does not like my LDAP_MATCHING_RULE_IN_CHAIN filter".

I have "packed" all of it into a github repo at
https://github.com/cbueche/openldap-passthru and announced it to the
list on 6.6.2014. It would be nice if the maintainer take it over to the
official openldap tarball within contrib/slapd-modules/mr_passthru/ so
future needs are "officially" covered. I think the
LDAP_MATCHING_RULE_IN_CHAIN filters will find their use for many other
people.

Markus: I can help you for the implementation if needed. Feel free to
provide for more functionality.

Regs,
Charles

On 23.10.14 08:17, markus.st...@t-systems.com wrote:
> Hi Howard,
>
> have you had a chance to look into this?
> We're a bit desperate over here, short of alternative solutions.
>
> Regards
> Markus
>
>> -Original Message-
>> From: Storm, Markus
>> Sent: Thursday, September 18, 2014 8:44 AM
>> To: 'Howard Chu'; openldap-technical@openldap.org
>> Subject: AW: allow to pass on "undefined" filters in meta
>>
>>> -Ursprüngliche Nachricht-
>>> Von: Howard Chu [mailto:h...@symas.com]
>>> Gesendet: Mittwoch, 17. September 2014 18:17
>>> An: Storm, Markus; openldap-technical@openldap.org
>>> Betreff: Re: allow to pass on "undefined" filters in meta
>>>
>>> markus.st...@t-systems.com wrote:
 Hi
 I've run into a problem trying to deploy back-meta in front of an
 Active Directory target.
>>> What is the exact filter you are trying to use?
>> a filter such as
>>
>> (&(objectclass=user)
>> (|(memberOf:1.2.840.113556.1.4.1941:=CN=GRP_AAA_ADM,OU=Groups,OU=AAA,OU=Se
>> rvers,DC=lab,DC=net)
>> (memberOf:1.2.840.113556.1.4.1941:=CN=GRP_BBB_ADM,OU=Groups,OU=AAA,OU=Serv
>> ers,DC=lab,DC=net)))
>>
>> The problem is with the matching rule to be used :1.2.840.113556.1.4.1941:
>> That translates into LDAP_MATCHING_RULE_IN_CHAIN which makes the server
>> recursively check for nested group membership. That's a feature in AD but
>> not supported in OpenLDAP (or at least not by simply specifying that matching
>> rule, and to rework the query is no option).
>>
 I believe that to resolve it, I need to get a new option implemented.
 I need to issue a request through a back-meta proxy . That query
 happens to contain a matching rule which is not implemented in
 OpenLDAP so slapd does not know to evaluate the query. The target
>>> that
 the query will ultimately be passed on to (an Active Directory) does
>>> know to process the query, though.
 OpenLDAP, however, considers the filter to be "undefined" and thus
 on relaying the request to the AD target, back-meta replaces a
 portion
>>> of
 the original query with a "(?=undefined)" filter as documented in
>>> e.g.
 slapd-meta manpage "noundeffilter" option.
 But I need the original query to be passed on. It's in fact a
 _valid_ LDAP request, just OpenLDAP happens to be unable to parse it.
 But at least in my setup,  slapd does not have to do _/anything/_
 about the query other than to pass it on, so I find it inacceptable
 that it replaces the query just because it doesn't understand it.
 Please, can you add an option switch to the code to allow for
 passing on original queries *without* replacing undefined portions ?
 I have not found any other solution to my problem. I tried to make
 OpenLDAP aware of the undefined portion by adding the matching rule
>>> to
 the schema but I failed. Seems that would need to be planted into
 the code, and not being a programmer, that's not as easy as it is
 with expanding the schema by some new attributes.
 Also, while of course any parser/feature enhancement will always be
 appreciated,  I would think that to implement the matching rule is
>>> not
 the best way of fixing things: I believe there will always be
 situations where OpenLDAP cannot parse the input while another LDAP
>>> server can.
 For a proof of concept, I hacked servers/slapd/back-meta/map.c
>>> (around
 line 581as of 2.4.39) and  but  - again, I'm not a programmer - I
>>> feel
 incapable of turning this into a full-blown patch free of side
 effects, also I want the modification to become available to anyone.
 So I'm hoping for you to implement the switch mentioned above, maybe
 as a third possible setting for the "noundeffilter" option.
 Thanks a lot in advance,
 best regards
 Markus Storm

Re: [PATCH] Fix OpenLDAP build when using LibreSSL

[Howard Chu]

Xin Li wrote:

Hi,

A FreeBSD user have proposed the patch below to solve OpenLDAP compile
issue when using LibreSSL, which I think would be good to share with
upstream.


This was already reported

http://www.openldap.org/its/index.cgi/Incoming?id=7978


The patch can be found at:

https://svnweb.freebsd.org/ports/head/net/openldap24-server/files/patch-des?revision=372499&view=co

The patch was created by "Spil Oss " so credit
should go to the submitter:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194841


Patches belong in the ITS, not the -technical mailing list.

--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

[PATCH] Fix OpenLDAP build when using LibreSSL

[Xin Li]

Hi,

A FreeBSD user have proposed the patch below to solve OpenLDAP compile
issue when using LibreSSL, which I think would be good to share with
upstream.

The patch can be found at:

https://svnweb.freebsd.org/ports/head/net/openldap24-server/files/patch-des?revision=372499&view=co

The patch was created by "Spil Oss " so credit
should go to the submitter:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194841

Cheers,

--- libraries/liblutil/passwd.c.orig2014-09-19 03:48:49.0 +0200
+++ libraries/liblutil/passwd.c 2014-11-05 19:57:10.807555025 +0100
@@ -38,11 +38,11 @@
 #  include 


-typedef des_cblock des_key;
-typedef des_cblock des_data_block;
-typedef des_key_schedule des_context;
-#define des_failed(encrypted) 0
-#define des_finish(key, schedule)
+typedef DES_cblock DES_key;
+typedef DES_cblock DES_data_block;
+typedef DES_key_schedule DES_context;
+#define DES_failed(encrypted) 0
+#define DES_finish(key, schedule)

 #elif defined(HAVE_MOZNSS)
 /*
@@ -53,9 +53,9 @@
 */
 #define PROTYPES_H 1
 #  include 
-typedef PK11SymKey *des_key;
-typedef unsigned char des_data_block[8];
-typedef PK11Context *des_context[1];
+typedef PK11SymKey *DES_key;
+typedef unsigned char DES_data_block[8];
+typedef PK11Context *DES_context[1];
 #define DES_ENCRYPT CKA_ENCRYPT

 #endif
@@ -664,10 +664,10 @@
  * abstract away setting the parity.
  */
 static void
-des_set_key_and_parity( des_key *key, unsigned char *keyData)
+DES_set_key_and_parity( DES_key *key, unsigned char *keyData)
 {
 memcpy(key, keyData, 8);
-des_set_odd_parity( key );
+DES_set_odd_parity( key );
 }


@@ -677,7 +677,7 @@
  * implement MozNSS wrappers for the openSSL calls
  */
 static void
-des_set_key_and_parity( des_key *key, unsigned char *keyData)
+DES_set_key_and_parity( DES_key *key, unsigned char *keyData)
 {
 SECItem keyDataItem;
 PK11SlotInfo *slot;
@@ -699,7 +699,7 @@
 }

 static void
-des_set_key_unchecked( des_key *key, des_context ctxt )
+DES_set_key_unchecked( DES_key *key, DES_context ctxt )
 {
 ctxt[0] = NULL;

@@ -712,37 +712,37 @@
 }

 static void
-des_ecb_encrypt( des_data_block *plain, des_data_block *encrypted,
-   des_context ctxt, int op)
+DES_ecb_encrypt( DES_data_block *plain, DES_data_block *encrypted,
+   DES_context ctxt, int op)
 {
 SECStatus rv;
 int size;

 if (ctxt[0] == NULL) {
/* need to fail here...  */
-   memset(encrypted, 0, sizeof(des_data_block));
+   memset(encrypted, 0, sizeof(DES_data_block));
return;
 }
 rv = PK11_CipherOp(ctxt[0], (unsigned char *)&encrypted[0],
-   &size, sizeof(des_data_block),
-   (unsigned char *)&plain[0], sizeof(des_data_block));
+   &size, sizeof(DES_data_block),
+   (unsigned char *)&plain[0], sizeof(DES_data_block));
 if (rv != SECSuccess) {
/* signal failure */
-   memset(encrypted, 0, sizeof(des_data_block));
+   memset(encrypted, 0, sizeof(DES_data_block));
return;
 }
 return;
 }

 static int
-des_failed(des_data_block *encrypted)
+DES_failed(DES_data_block *encrypted)
 {
-   static const des_data_block zero = { 0 };
+   static const DES_data_block zero = { 0 };
return memcmp(encrypted, zero, sizeof(zero)) == 0;
 }

 static void
-des_finish(des_key *key, des_context ctxt)
+DES_finish(DES_key *key, DES_context ctxt)
 {
  if (*key) {
PK11_FreeSymKey(*key);
@@ -817,7 +817,7 @@

 static void lmPasswd_to_key(
const char *lmPasswd,
-   des_key *key)
+   DES_key *key)
 {
const unsigned char *lpw = (const unsigned char *) lmPasswd;
unsigned char k[8];
@@ -832,7 +832,7 @@
k[6] = ((lpw[5] & 0x3F) << 2) | (lpw[6] >> 6);
k[7] = ((lpw[6] & 0x7F) << 1);

-   des_set_key_and_parity( key, k );
+   DES_set_key_and_parity( key, k );
 }  

 static int chk_lanman(
@@ -843,10 +843,10 @@
 {
ber_len_t i;
char UcasePassword[15];
-   des_key key;
-   des_context schedule;
-   des_data_block StdText = "KGS!@#$%";
-   des_data_block PasswordHash1, PasswordHash2;
+   DES_key key;
+   DES_context schedule;
+   DES_data_block StdText = "KGS!@#$%";
+   DES_data_block PasswordHash1, PasswordHash2;
char PasswordHash[33], storedPasswordHash[33];

for( i=0; ibv_len; i++) {
@@ -864,21 +864,21 @@
ldap_pvt_str2upper( UcasePassword );

lmPasswd_to_key( UcasePassword, &key );
-   des_set_key_unchecked( &key, schedule );
-   des_ecb_encrypt( &StdText, &PasswordHash1, schedule , DES_ENCRYPT );
+   DES_set_key_unchecked( &key, &schedule );
+   DES_ecb_encrypt( &StdText, &PasswordHash1, &schedule , DES_ENCRYPT );

-   if (des_failed(&PasswordHash1)) {
+   if (DES_failed(&PasswordHash1)) {
return LUTIL_PASSWD_ERR;
}

lmPasswd_to_key( &Uca

Re: adding VLV support to OpenLDAP 2.4.31

[Quanah Gibson-Mount]

--On November 12, 2014 at 6:23:53 PM +0100 Marc Patermann 
 wrote:




You can change the exported config or post it here, if you have not
before. This may tell you/us how to authorize to slapd with ldapadd to
modify the config online.


Ubuntu already documents how to authorize to the config db, and I already 
provided a URL to the Ubuntu documentation.  Here's the link again:




which clearly provides an example of how to bind to the root database via 
ldapsearch (which can logically be extended to ldapmodify, ldapadd, etc).


--Quanah



--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

Re: adding VLV support to OpenLDAP 2.4.31

[Marc Patermann]

Igor,

Igor Shmukler schrieb (12.11.2014 11:36 Uhr):

I am guess making wild guesses...
Could it be that I need to adjust the below line:
dn: olcOverlay=sssvlv,olcDatabase={1}bdb,cn=config

Should I perhaps replace cn=config with dc=nodomain or something else?

No.

With slapd.d config instead of "old" slapd.conf, you now have (at least) 
two databases in slapd:

* you config database - which is always at cn=config - and
* your "data" database - which base that is under is totally up to you.

You can export the config with slapcat command, cn=config is propably 
the first database, so you use "-n 0".

(You should backup the other databases as well.)
You can change the exported config or post it here, if you have not 
before. This may tell you/us how to authorize to slapd with ldapadd to 
modify the config online.
You could import the cn=config database back with slapadd offline, but 
you might have to delete the existing database first. ldapadd is a bit 
more difficult to use but safer.


(This may have been a lot easier to explain with slapd.conf, but the 
times are changing ...)


Marc

LDAP auth is failing when I disconnect and re-connect AD server

[Adarsha S]

Hi All,

I've a setup where I've installed openldap-2.4.25 on debian machine to
access windows 2003 AD server.
my radius server use the libraire of openldap-2.4.25.

Along with this i'm using samba to join the AD domain and bring up winbindd.

The senario is this way.

After I've started my radius server, winbindd process autherthication works
fine.
Now I disconnect my AD server for a while.Try to authenticate. It fails.
This is a valid senario.

But after I re-connect my AD server still the authentication says invalid
users.

I would like to know how to debug this issue as i'm not able to get logs
also.

Thanks in Advance,
Adarsha

Re: adding VLV support to OpenLDAP 2.4.31

[Igor Shmukler]

Hi Andrew,

I definitely could not care less which backend database is used. I
only asked about this to get VLV working. Currently, it does not.
I need to get on with my job, which is programming and not *nix
administration. Until Virtual List View working, I cannot do that.

Sincerely,

Igor Shmukler

On Wed, Nov 12, 2014 at 1:11 PM, Andrew Findlay
 wrote:
> On Wed, Nov 12, 2014 at 12:41:46PM +0200, Igor Shmukler wrote:
>
>> I am also curious about another part of the olcDatabase parameter.
>> How do I know whether to use bdb or hdb? I don't care either way of
>> course. I just need my test server to work, so I could proceed with my
>> main duty - programming.
>
> For a test server it probably does not matter which database you use
> unless you need to load large amounts of data, or do unusual things
> like rename whole subtrees (bdb cannot do that).
>
> For a production server using current OpenLDAP code, mdb is the first
> choice. If you are forced to use older software then hdb may be safer.
>
> Andrew
> --
> ---
> | From Andrew Findlay, Skills 1st Ltd |
> | Consultant in large-scale systems, networks, and directory services |
> | http://www.skills-1st.co.uk/+44 1628 782565 |
> ---

Re: adding VLV support to OpenLDAP 2.4.31

[Andrew Findlay]

On Wed, Nov 12, 2014 at 12:41:46PM +0200, Igor Shmukler wrote:

> I am also curious about another part of the olcDatabase parameter.
> How do I know whether to use bdb or hdb? I don't care either way of
> course. I just need my test server to work, so I could proceed with my
> main duty - programming.

For a test server it probably does not matter which database you use
unless you need to load large amounts of data, or do unusual things
like rename whole subtrees (bdb cannot do that).

For a production server using current OpenLDAP code, mdb is the first
choice. If you are forced to use older software then hdb may be safer.

Andrew
-- 
---
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/+44 1628 782565 |
---

Re: adding VLV support to OpenLDAP 2.4.31

[Igor Shmukler]

Hello,

I am also curious about another part of the olcDatabase parameter.
How do I know whether to use bdb or hdb? I don't care either way of
course. I just need my test server to work, so I could proceed with my
main duty - programming.

Sincerely,

Igor Shmukler


On Wed, Nov 12, 2014 at 12:36 PM, Igor Shmukler  wrote:
> Chris,
>
> I am guess making wild guesses...
> Could it be that I need to adjust the below line:
> dn: olcOverlay=sssvlv,olcDatabase={1}bdb,cn=config
>
> Should I perhaps replace cn=config with dc=nodomain or something else?
>
> Thank you,
>
> Igor Shmukler
>
>
> On Wed, Nov 12, 2014 at 12:30 PM, Igor Shmukler  
> wrote:
>> Hello Chris,
>>
>> Yes, I am now sure that slapd.d is being used. Last night, Andrew
>> explained how this can be checked.
>>
>> Sincerely,
>>
>> Igor Shmukler
>>
>> On Wed, Nov 12, 2014 at 12:28 PM, Chris Card  wrote:
>>>
 vq@vq-HVM-domU:~$ ldapsearch -x -w Vq0106%% -D "cn=admin,dc=nodomain"
 -b cn=config
 # extended LDIF
 #
 # LDAPv3
 # base  with scope subtree
 # filter: (objectclass=*)
 # requesting: ALL
 #

 # search result
 search: 2
 result: 32 No such object

 # numResponses: 1

 vq@vq-HVM-domU:~$ cat /usr/share/slapd/sssvlv.ldif
 dn: olcOverlay=sssvlv,olcDatabase={1}bdb,cn=config
 objectClass: olcSssVlvConfig
 olcOverlay: sssvlv
 olcSssVlvMax: 10
 olcSssVlvMaxKeys: 5

 In order to actually get the search working, I use base dc=nodomain

 It is not my choice. I inherited the server and the configuration. Nor
 do I know much about OpenLDAP configuration. I am a programmer and my
 job is [among other things] hacking the client piece. Unfortunately,
 there is nobody else [better] qualified to configure the server.
 Hence, I am filling in for an administrator.

 The "ldapsearch -x -w SECRET -D "cn=admin,dc=nodomain" -b dc=nodomain"
 version works fine and I do in fact get results.

>>> Are you sure that slapd is using the slapd.d configuration, rather than the 
>>> old-style slapd.conf?
>>> If slapd.d is being used, then slapd should be running with -F 
>>> /slap.d, if not then it will be
>>> running with -f /slapd.conf.
>>>
>>> Chris

Re: adding VLV support to OpenLDAP 2.4.31

[Igor Shmukler]

Chris,

I am guess making wild guesses...
Could it be that I need to adjust the below line:
dn: olcOverlay=sssvlv,olcDatabase={1}bdb,cn=config

Should I perhaps replace cn=config with dc=nodomain or something else?

Thank you,

Igor Shmukler


On Wed, Nov 12, 2014 at 12:30 PM, Igor Shmukler  wrote:
> Hello Chris,
>
> Yes, I am now sure that slapd.d is being used. Last night, Andrew
> explained how this can be checked.
>
> Sincerely,
>
> Igor Shmukler
>
> On Wed, Nov 12, 2014 at 12:28 PM, Chris Card  wrote:
>>
>>> vq@vq-HVM-domU:~$ ldapsearch -x -w Vq0106%% -D "cn=admin,dc=nodomain"
>>> -b cn=config
>>> # extended LDIF
>>> #
>>> # LDAPv3
>>> # base  with scope subtree
>>> # filter: (objectclass=*)
>>> # requesting: ALL
>>> #
>>>
>>> # search result
>>> search: 2
>>> result: 32 No such object
>>>
>>> # numResponses: 1
>>>
>>> vq@vq-HVM-domU:~$ cat /usr/share/slapd/sssvlv.ldif
>>> dn: olcOverlay=sssvlv,olcDatabase={1}bdb,cn=config
>>> objectClass: olcSssVlvConfig
>>> olcOverlay: sssvlv
>>> olcSssVlvMax: 10
>>> olcSssVlvMaxKeys: 5
>>>
>>> In order to actually get the search working, I use base dc=nodomain
>>>
>>> It is not my choice. I inherited the server and the configuration. Nor
>>> do I know much about OpenLDAP configuration. I am a programmer and my
>>> job is [among other things] hacking the client piece. Unfortunately,
>>> there is nobody else [better] qualified to configure the server.
>>> Hence, I am filling in for an administrator.
>>>
>>> The "ldapsearch -x -w SECRET -D "cn=admin,dc=nodomain" -b dc=nodomain"
>>> version works fine and I do in fact get results.
>>>
>> Are you sure that slapd is using the slapd.d configuration, rather than the 
>> old-style slapd.conf?
>> If slapd.d is being used, then slapd should be running with -F /slap.d, 
>> if not then it will be
>> running with -f /slapd.conf.
>>
>> Chris

Re: adding VLV support to OpenLDAP 2.4.31

[Igor Shmukler]

Hello Chris,

Yes, I am now sure that slapd.d is being used. Last night, Andrew
explained how this can be checked.

Sincerely,

Igor Shmukler

On Wed, Nov 12, 2014 at 12:28 PM, Chris Card  wrote:
>
>> vq@vq-HVM-domU:~$ ldapsearch -x -w Vq0106%% -D "cn=admin,dc=nodomain"
>> -b cn=config
>> # extended LDIF
>> #
>> # LDAPv3
>> # base  with scope subtree
>> # filter: (objectclass=*)
>> # requesting: ALL
>> #
>>
>> # search result
>> search: 2
>> result: 32 No such object
>>
>> # numResponses: 1
>>
>> vq@vq-HVM-domU:~$ cat /usr/share/slapd/sssvlv.ldif
>> dn: olcOverlay=sssvlv,olcDatabase={1}bdb,cn=config
>> objectClass: olcSssVlvConfig
>> olcOverlay: sssvlv
>> olcSssVlvMax: 10
>> olcSssVlvMaxKeys: 5
>>
>> In order to actually get the search working, I use base dc=nodomain
>>
>> It is not my choice. I inherited the server and the configuration. Nor
>> do I know much about OpenLDAP configuration. I am a programmer and my
>> job is [among other things] hacking the client piece. Unfortunately,
>> there is nobody else [better] qualified to configure the server.
>> Hence, I am filling in for an administrator.
>>
>> The "ldapsearch -x -w SECRET -D "cn=admin,dc=nodomain" -b dc=nodomain"
>> version works fine and I do in fact get results.
>>
> Are you sure that slapd is using the slapd.d configuration, rather than the 
> old-style slapd.conf?
> If slapd.d is being used, then slapd should be running with -F /slap.d, 
> if not then it will be
> running with -f /slapd.conf.
>
> Chris

RE: adding VLV support to OpenLDAP 2.4.31

[Chris Card]

> vq@vq-HVM-domU:~$ ldapsearch -x -w Vq0106%% -D "cn=admin,dc=nodomain"
> -b cn=config
> # extended LDIF
> #
> # LDAPv3
> # base  with scope subtree
> # filter: (objectclass=*)
> # requesting: ALL
> #
>
> # search result
> search: 2
> result: 32 No such object
>
> # numResponses: 1
>
> vq@vq-HVM-domU:~$ cat /usr/share/slapd/sssvlv.ldif
> dn: olcOverlay=sssvlv,olcDatabase={1}bdb,cn=config
> objectClass: olcSssVlvConfig
> olcOverlay: sssvlv
> olcSssVlvMax: 10
> olcSssVlvMaxKeys: 5
>
> In order to actually get the search working, I use base dc=nodomain
>
> It is not my choice. I inherited the server and the configuration. Nor
> do I know much about OpenLDAP configuration. I am a programmer and my
> job is [among other things] hacking the client piece. Unfortunately,
> there is nobody else [better] qualified to configure the server.
> Hence, I am filling in for an administrator.
>
> The "ldapsearch -x -w SECRET -D "cn=admin,dc=nodomain" -b dc=nodomain"
> version works fine and I do in fact get results.
>
Are you sure that slapd is using the slapd.d configuration, rather than the 
old-style slapd.conf?
If slapd.d is being used, then slapd should be running with -F /slap.d, if 
not then it will be 
running with -f /slapd.conf.

Chris 

Re: adding VLV support to OpenLDAP 2.4.31

[Igor Shmukler]

Hi Chris,

vq@vq-HVM-domU:~$ ldapsearch -x -w Vq0106%% -D "cn=admin,dc=nodomain"
-b cn=config
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object

# numResponses: 1

vq@vq-HVM-domU:~$ cat /usr/share/slapd/sssvlv.ldif
dn: olcOverlay=sssvlv,olcDatabase={1}bdb,cn=config
objectClass: olcSssVlvConfig
olcOverlay: sssvlv
olcSssVlvMax: 10
olcSssVlvMaxKeys: 5

In order to actually get the search working, I use base dc=nodomain

It is not my choice. I inherited the server and the configuration. Nor
do I know much about OpenLDAP configuration. I am a programmer and my
job is [among other things] hacking the client piece. Unfortunately,
there is nobody else [better] qualified to configure the server.
Hence, I am filling in for an administrator.

The "ldapsearch -x -w SECRET -D "cn=admin,dc=nodomain" -b dc=nodomain"
version works fine and I do in fact get results.

Sincerely,

Igor Shmukler

On Wed, Nov 12, 2014 at 11:47 AM, Chris Card  wrote:
>
>
>
>> Hi Chris,
>>
>> Sorry to bother you again.
>>
>>> ldapadd -x -w  -D cn=config -f 
>>
>> -D cn=config was giving me an authentication error. I used
>> credentials, which work for ldapsearch and got a syntax error.
>>
>> vq@vq-HVM-domU:~$ ldapadd -x -w SECRET -D "cn=admin, dc=nodomain" -f
>> /usr/share/slapd/sssvlv.ldif
>> ldap_add: Invalid syntax (21)
>> additional info: objectClass: value #0 invalid per syntax
>>
> Is cn=admin,dc=nodomain the rootdn for the cn=config directory?
>
> Does
>
> ldapsearch -x -w SECRET -D "cn=admin,dc=nodomain" -b cn=config
>
> work?
>
> What are the contents of sssvlv.ldif? (it's possible I made a typo, it was 
> untested)
>
> Chris
>
>

Re: adding VLV support to OpenLDAP 2.4.31

[Andrew Findlay]

On Wed, Nov 12, 2014 at 01:02:36AM +0200, Igor Shmukler wrote:

> Interestingly, lsof does have the following entry:
> slapd   13310 openldap  memREG  202,126872 409681
> /usr/lib/ldap/sssvlv-2.4.so.2.8.3
> 
> Hence, it seems that sssvlv is loaded. At the same time, ldapsearch is
> telling me "VLV control requires server side sort control"

It would appear that the sssvlv *module* has loaded, but you still have to 
apply the overlay to the database that you want it to work on.

> Does this mean like Quanah said that my OpenLDAP from Ubuntu server is broken?

Not necessarily. Many people on this list dislike the way that some
of the major Linux distros build OpenLDAP and the old versions of
OpenLDAP that they use, so the default setup tends to get described as
'broken'. Quanah was also referring to the fact that you had hand-edited
a file under /etc/ldap/slapd.d/cn=config - that is a very risky thing
to do and you may have caused problems that way.

In this case I think it more likely that you just need to add the overlay
to the database.

On Wed, Nov 12, 2014 at 08:38:14AM +, Chris Card wrote:

> Date: Wed, 12 Nov 2014 08:38:14 +
> From: Chris Card 
> 
> dn: olcOverlay=sssvlv,olcDatabase={1}bdb,cn=config
> objectClass: olcSssVlvConfig
> olcOverlay: sssvlv
> olcSssVlvMax: 10
> olcSssVlvMaxKeys: 5
> 
> something like 
> 
> ldapadd -x -w  -D cn=config -f 

As Chris says, ldapadd (or slapadd if the server is down) is the right
way to modify a config of this type. The exact LDIF required will
depend on your database setup: Chris has assumed that you want the
overlay on the first non-config database and that it is a bdb.
If your setup is different then the DN will have to change.

Note also that bdb is deprecated. If you continue to use the binaries
shipped with Ubuntu then you should at least consider swapping to hdb.
Ideally you should build the latest OpenLDAP from source and use mdb.
Changing to a different database type requires dumping all data to LDIF
text files and re-loading it in the new database, so this is not something
to be undertaken until you are more familiar with OpenLDAP.

Andrew
-- 
---
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/+44 1628 782565 |
---

Re: adding VLV support to OpenLDAP 2.4.31

[Igor Shmukler]

Hi Chris,

Sorry to bother you again.

> ldapadd -x -w  -D cn=config -f 

-D cn=config was giving me an authentication error. I used
credentials, which work for ldapsearch and got a syntax error.

vq@vq-HVM-domU:~$ ldapadd -x -w SECRET -D "cn=admin, dc=nodomain" -f
/usr/share/slapd/sssvlv.ldif
ldap_add: Invalid syntax (21)
additional info: objectClass: value #0 invalid per syntax

Please advise.

Thank you,

Igor Shmukler

RE: adding VLV support to OpenLDAP 2.4.31

[Chris Card]

> It is clear from the man slapo-sssvlv(5) page that when slapd.conf is
> being used, the options should appear after the overlay directive.
> Even I got this. Where those options should go when cn=config is used?
> I do not understand it from the man page. Is this something to be
> specified using ldapmodify?

 You need to use ldapadd with ldif like this:

 dn: olcOverlay=sssvlv,olcDatabase={1}bdb,cn=config
 objectClass: olcSssVlvConfig
 olcOverlay: sssvlv
 olcSssVlvMax: 10
 olcSssVlvMaxKeys: 5

 something like

 ldapadd -x -w  -D cn=config -f 

>>>
>>> Thank you Chris,
>>>
>>> This is exactly what I needed.
>>> Should I put the leif file into the
>>> /etc/ldap/slapd.d/cn=config/cn=schema directory or
>>> /etc/ldap/slapd.d/cn\=config/ directory? What is the recommended
>>> place?
>>> [I see that -D is to specify binddn, yet I am not sure whether LDIF
>>> should go there. Sorry for being stupid.]
>>>
>> Don't update anything under /etc/ldap/slapd.d/cn\=config by hand!
>>
>> The configuration is held in an LDAP directory with suffix cn=config, and
>> you add stuff to it in exactly the same way as any other LDAP directory,
>> using ldapadd, ldapmodify etc.
>>
>> The fact that you can see files under /etc/ldap/slapd.d/cn=config is just
>> an artifact of the implementation of the cn=config db in openldap, and I 
>> believe
>> it is planned to change the implementation in the future.
>>
>
> Where should I put the ldif file, then?
>
It doesn't matter where, it's just a source file. The ldapadd utility will send 
the ldif to the LDAP server, and the LDAP server
will update the cn=config directory.

Chris 

Re: adding VLV support to OpenLDAP 2.4.31

[Igor Shmukler]

Where should I put the ldif file, then?

On Wed, Nov 12, 2014 at 10:53 AM, Chris Card  wrote:
>
>
>
>>
>> On Wed, Nov 12, 2014 at 10:38 AM, Chris Card  wrote:
>>>
 It is clear from the man slapo-sssvlv(5) page that when slapd.conf is
 being used, the options should appear after the overlay directive.
 Even I got this. Where those options should go when cn=config is used?
 I do not understand it from the man page. Is this something to be
 specified using ldapmodify?
>>>
>>> You need to use ldapadd with ldif like this:
>>>
>>> dn: olcOverlay=sssvlv,olcDatabase={1}bdb,cn=config
>>> objectClass: olcSssVlvConfig
>>> olcOverlay: sssvlv
>>> olcSssVlvMax: 10
>>> olcSssVlvMaxKeys: 5
>>>
>>> something like
>>>
>>> ldapadd -x -w  -D cn=config -f 
>>>
>>
>> Thank you Chris,
>>
>> This is exactly what I needed.
>> Should I put the leif file into the
>> /etc/ldap/slapd.d/cn=config/cn=schema directory or
>> /etc/ldap/slapd.d/cn\=config/ directory? What is the recommended
>> place?
>> [I see that -D is to specify binddn, yet I am not sure whether LDIF
>> should go there. Sorry for being stupid.]
>>
> Don't update anything under /etc/ldap/slapd.d/cn\=config by hand!
>
> The configuration is held in an LDAP directory with suffix cn=config, and
> you add stuff to it in exactly the same way as any other LDAP directory,
> using ldapadd, ldapmodify etc.
>
> The fact that you can see files under /etc/ldap/slapd.d/cn=config is just
> an artifact of the implementation of the cn=config db in openldap, and I 
> believe
> it is planned to change the implementation in the future.
>
> Chris
>
>

RE: adding VLV support to OpenLDAP 2.4.31

[Chris Card]

>
> On Wed, Nov 12, 2014 at 10:38 AM, Chris Card  wrote:
>>
>>> It is clear from the man slapo-sssvlv(5) page that when slapd.conf is
>>> being used, the options should appear after the overlay directive.
>>> Even I got this. Where those options should go when cn=config is used?
>>> I do not understand it from the man page. Is this something to be
>>> specified using ldapmodify?
>>
>> You need to use ldapadd with ldif like this:
>>
>> dn: olcOverlay=sssvlv,olcDatabase={1}bdb,cn=config
>> objectClass: olcSssVlvConfig
>> olcOverlay: sssvlv
>> olcSssVlvMax: 10
>> olcSssVlvMaxKeys: 5
>>
>> something like
>>
>> ldapadd -x -w  -D cn=config -f 
>>
>
> Thank you Chris,
>
> This is exactly what I needed.
> Should I put the leif file into the
> /etc/ldap/slapd.d/cn=config/cn=schema directory or
> /etc/ldap/slapd.d/cn\=config/ directory? What is the recommended
> place?
> [I see that -D is to specify binddn, yet I am not sure whether LDIF
> should go there. Sorry for being stupid.]
>
Don't update anything under /etc/ldap/slapd.d/cn\=config by hand!

The configuration is held in an LDAP directory with suffix cn=config, and
you add stuff to it in exactly the same way as any other LDAP directory, 
using ldapadd, ldapmodify etc.

The fact that you can see files under /etc/ldap/slapd.d/cn=config is just
an artifact of the implementation of the cn=config db in openldap, and I believe
it is planned to change the implementation in the future.

Chris

  

Re: adding VLV support to OpenLDAP 2.4.31

[Igor Shmukler]

Thank you Chris,

This is exactly what I needed.
Should I put the leif file into the
/etc/ldap/slapd.d/cn=config/cn=schema directory or
/etc/ldap/slapd.d/cn\=config/ directory? What is the recommended
place?
[I see that -D is to specify binddn, yet I am not sure whether LDIF
should go there. Sorry for being stupid.]

Sincerely,

Igor Shmukler

On Wed, Nov 12, 2014 at 10:38 AM, Chris Card  wrote:
> Hi Igor
>
>> It is clear from the man slapo-sssvlv(5) page that when slapd.conf is
>> being used, the options should appear after the overlay directive.
>> Even I got this. Where those options should go when cn=config is used?
>> I do not understand it from the man page. Is this something to be
>> specified using ldapmodify?
>
> You need to use ldapadd with ldif like this:
>
> dn: olcOverlay=sssvlv,olcDatabase={1}bdb,cn=config
> objectClass: olcSssVlvConfig
> olcOverlay: sssvlv
> olcSssVlvMax: 10
> olcSssVlvMaxKeys: 5
>
> something like
>
> ldapadd -x -w  -D cn=config -f 
>
> Chris

RE: adding VLV support to OpenLDAP 2.4.31

[Chris Card]

Hi Igor

> It is clear from the man slapo-sssvlv(5) page that when slapd.conf is
> being used, the options should appear after the overlay directive.
> Even I got this. Where those options should go when cn=config is used?
> I do not understand it from the man page. Is this something to be
> specified using ldapmodify?

You need to use ldapadd with ldif like this:

dn: olcOverlay=sssvlv,olcDatabase={1}bdb,cn=config
objectClass: olcSssVlvConfig
olcOverlay: sssvlv
olcSssVlvMax: 10
olcSssVlvMaxKeys: 5

something like 

ldapadd -x -w  -D cn=config -f 

Chris