openldap-technical

openldap-technical@openldap.org

13 participants
9794 discussions

Re: Re: Can't add "same" mail attribute with different cases.
by Quanah Gibson-Mount 21 Nov '16

21 Nov '16

--On Thursday, November 17, 2016 11:27 PM +0100 Patrick Zacharias <LittleFighter19(a)web.de> wrote: > The gerrit devs (if I recall correctly) argued that this behavior is > intentional as due to the standard, mails can be case sensitive and get > to different recipients. I would stop using a product written by developers who are so clearly clueless. Zero part of the internet is going to work with them if they treat email as case specific. I would in fact point to rfc1274, which SPECIFICALLY notes that the "mail" attribute is NOT case sensitive. 9.3.3. RFC 822 Mailbox The RFC822 Mailbox attribute type specifies an electronic mailbox attribute following the syntax specified in RFC 822. Note that this attribute should not be used for greybook or other non-Internet order mailboxes. rfc822Mailbox ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreIA5StringSyntax (SIZE (1 .. ub-rfc822-mailbox)) ::= {pilotAttributeType 3} I also suggest reading RFC822, section 3.4.7: 3.4.7. CASE INDEPENDENCE Except as noted, alphabetic strings may be represented in any combination of upper and lower case. The only syntactic units August 13, 1982 - 14 - RFC #822 Standard for ARPA Internet Text Messages which requires preservation of case information are: - text - qtext - dtext - ctext - quoted-pair - local-part, except "Postmaster" When matching any other syntactic unit, case is to be ignored. For example, the field-names "From", "FROM", "from", and even "FroM" are semantically equal and should all be treated ident- ically. > Now I'd like to know if it possible to modify the scheme that way so that > mail works case sensitive (because that's also what the standard says). No. > Or if there is a way to force the creation of entries with the "same" > value No. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Sync question
by Quanah Gibson-Mount 21 Nov '16

21 Nov '16

--On Friday, November 18, 2016 4:49 PM +0000 "Singley, Norman" <Norman.Singley(a)mso.umt.edu> wrote: > My question regards synchronization. We are using > "refreshandpersist" for syncrepl. For the hour or so it takes to do > the migration, users will be changing Passwords – that should be the > only oldap changes made in that time. Will the password changes that get > written to the two existing nodes sync over to the third node when we > bring it back up, or will they be lost and we would be out of sync? The third node should "catch up" with the other masters. I will assume you're running the current OpenLDAP release (2.4.44). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: reusing transactions in LMDB
by Howard Chu 21 Nov '16

21 Nov '16

Tim Uckun wrote: > Also I noticed that every call to mdb_txn_id returns 1 even for different > transactions. Is this normal? http://lmdb.tech/doc/group__internal.html#gadc82bb5e2127ae99ac0c5fe12b955f25 -- -- 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: Alias in LDAP tree
by Quanah Gibson-Mount 21 Nov '16

21 Nov '16

--On Sunday, November 20, 2016 9:19 PM +0300 Bogdan Rudas <brudas(a)exadel.com> wrote: > > > > Hello all! > > I have base prefix like 'dc=company,dc=com' and want to replace it with > 'dc=newcompany,dc=biz'. I can't change base prefix everywhere at once due > to application release cycle, change management policy and so on. > It is hard to confirm that all our LDAP clients have aliases > dereferencing enabled and handles it right way. Are there any kind of > 'request rewrite' or 'transparent proxy' options? > > Thank you. Hi, This <http://www.openldap.org/software/man.cgi?query=slapo-rwm&sektion=5&apropos=…> perhaps? Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Re: Can't add "same" mail attribute with different cases.
by Quanah Gibson-Mount 21 Nov '16

21 Nov '16

--On Monday, November 21, 2016 9:50 AM -0800 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Thursday, November 17, 2016 11:27 PM +0100 Patrick Zacharias > <LittleFighter19(a)web.de> wrote: > >> The gerrit devs (if I recall correctly) argued that this behavior is >> intentional as due to the standard, mails can be case sensitive and get >> to different recipients. > > I would stop using a product written by developers who are so clearly > clueless. Zero part of the internet is going to work with them if they > treat email as case specific. (And yes, I understand technically they're correct). But in practice, virtually no one implements this way, because enforcing this simply won't work with the majority of the world. And for LDAP, it's specifically defined as case-insensitive. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: OpenLDAP ACL causing error code 49
by Quanah Gibson-Mount 21 Nov '16

21 Nov '16

--On Monday, November 21, 2016 6:41 PM +0100 Michael Ströder <michael(a)stroeder.com> wrote: > Matty wrote: >> I am testing some OpenLDAP ACLs and stumbled on a weird issue. My >> configuration has the following ACL defined: >> >> access to * >> by users read >> by peername.ip=1.2.3.4 read >> by * none > ^^^^ > You probably want "auth" in this last <who> clause. > > Ciao, Michael. > or: by anonymous auth by * none may be closer. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

OpenLDAP ACL causing error code 49
by Matty 21 Nov '16

21 Nov '16

I am testing some OpenLDAP ACLs and stumbled on a weird issue. My configuration has the following ACL defined: access to * by users read by peername.ip=1.2.3.4 read by * none When I run the following ldapsearch I get an "Invalid credentials (49)" error: $ ldapsearch -b 'dc=foo,dc=com' -x -h ldap1 -W -D 'uid=bingo,ou=users,dc=foo,dc=com' '(objectClass=*)' Enabling the ACL loglevel produces the following: Nov 16 09:50:02 tulip slapd[17803]: conn=33003 op=0 BIND dn="uid=bingo,ou=users,dc=foo,dc=com" method=128 Nov 16 09:50:02 tulip slapd[17803]: => acl_get: [2] attr userPassword Nov 16 09:50:02 tulip slapd[17803]: => acl_mask: access to entry "uid=bingo,ou=users,dc=foo,dc=com", attr "userPassword" requested Nov 16 09:50:02 tulip slapd[17803]: => acl_mask: to value by "", (=0) Nov 16 09:50:02 tulip slapd[17803]: <= check a_dn_pat: users Nov 16 09:42:24 tulip slapd[17803]: <= check a_peername_path: 1.2.3.4 Nov 16 09:42:24 tulip slapd[17803]: <= check a_dn_pat: * Nov 16 09:42:24 tulip slapd[17803]: <= acl_mask: [5] applying none(=0) (stop) Nov 16 09:42:24 tulip slapd[17803]: <= acl_mask: [5] mask: none(=0) Nov 16 09:42:24 tulip slapd[17803]: => slap_access_allowed: auth access denied by none(=0) Nov 16 09:42:24 tulip slapd[17803]: => access_allowed: no more rules Does anyone happen to know why "acl_mask: to value by" shows "" instead of the dn of the user passed to the "-D" option? Wireshark shows the binddn and password being passed to the directory server so the "" doesn't make a ton of sense. If I add the following ACL to force anonymous users to auth the search completes without issue: access to attrs=userPassword by self write by anonymous auth by users none There must be some subtle item I'm missing here. Thanks, - Ryan

2 1

reusing transactions in LMDB
by Tim Uckun 21 Nov '16

21 Nov '16

Another question regarding my wrapper for lmdb. The comments say it's possible to reuse read only transactions but says nothing about reusing the read write transactions. Does this mean every write operation needs a fresh transaction? Is there any downsides to not implementing the reuse functions for the wrapper? I figure the use case is quite limited and frankly I would have to manage all the transaction pointers to make sure they were being used property. Also I noticed that every call to mdb_txn_id returns 1 even for different transactions. Is this normal? Thanks.

1 0

Repairing a lmdb database
by Tim Uckun 21 Nov '16

21 Nov '16

Hi All. I am writing a wrapper for Lmdb for the Crystal language. During the process of writing my code started hanging when attempting to open a transaction. At first I thought I was calling the C functions wrong but it turned out to be some sort of a corruption in the database itself. I deleted the database directory and the code started working fine again. At this point all my code did was to open an environment, set some parameters (max readers and such) and some flags (specifically NO_TLS). I had not attempted to open a database yet as I need a transaction to open a database. I am a little worried that the database caused a hang like this but I will go forward and continue to write the wrapper and see if it happens again. Does anybody have any clues as to why the environment could have corrupted like this? What do I do if it happens again? Thanks.

1 0

Alias in LDAP tree
by Bogdan Rudas 20 Nov '16

20 Nov '16

Hello all! I have base prefix like 'dc=company,dc=com' and want to replace it with 'dc=newcompany,dc=biz'. I can't change base prefix everywhere at once due to application release cycle, change management policy and so on. It is hard to confirm that all our LDAP clients have aliases dereferencing enabled and handles it right way. Are there any kind of 'request rewrite' or 'transparent proxy' options? Thank you. -- Bogdan Rudas Head of Minsk IT Support Department Exadel Inc. http://www.exadel.com/ E-mail: brudas(a)exadel.com Skype ID: bogdan.rudas -- CONFIDENTIALITY NOTICE: This email and files attached to it are confidential. If you are not the intended recipient you are hereby notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical