openldap-technical

openldap-technical@openldap.org

14 participants
9796 discussions

RE: Problem using ldapsearch across forests with trust
by Quanah Gibson-Mount 16 Apr '20

16 Apr '20

--On Thursday, April 16, 2020 2:10 PM +0000 "Kleber S. Carvalho" <kleber.s.carvalho(a)avanade.com> wrote: > First, we performed a valid test by performing authentication and a > simple query directly to the minca.com domain, with the command: > > ldapsearch -H 'LDAP: //minca.com: 3268' -D 'cn = Administrator, cn = > users, dc = minca, dc = with' -w Avanade @ 2020! -b 'cn = users, dc = > minca, dc = com' > > However, when performing this procedure and authenticating the user > minca(a)minca.com in the child.klabs.com domain using the ldapsearch tool, > the result was an error according to file > 7_openldaperror_indirectaccess.JPG stating invalid credentials. Expected I would think, if using a simple bind. > However, a .net application was created to perform this same function and > it worked, as per file 9_dotNetApp_success.JPG. AD is not LDAP. > Finally, the conclusion we are reaching is that the openldap tool does > not work directly between forests, but only on the same tree. We would > like to know if this understanding is correct or if this is really a bug > in the tool. AD is not LDAP. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

rootdn & password policy
by Hannah Chenh 15 Apr '20

15 Apr '20

Hello, I have a question related to rootdn and password policy. I understand that the rootdn can bypass all restrictions. We have a requirement to bypass a password policy for the admin user. Is there a way to create the admin user so that this user can have the same privilege as rootdn and I don't need to bind as rootdn in my application? Currently I have granted the following to the admin_user: === dn: olcDatabase={2}hdb,cn=config changetype: modify add: olcAccess olcAccess: {0}to attrs=userPassword by self write by anonymous auth by dn.base="cn=Manager,dc=abcdomain,dc=com" write by dn.base="uid=admin_user,ou=Service Accounts,dc=abcdomain,dc=com" write by * none olcAccess: {1}to * by self write by dn.base="cn=Manager,dc=abcdomain,dc=com" write by dn.base="uid=admin_user,ou=Service Accounts,dc=abcdomain,dc=com" write by * read === Any help would be appreciated. Thanks, Hannah

5 7

Class-of-service type of feature in OpenLDAP?
by Nick Folino 15 Apr '20

15 Apr '20

I'm moving from ODSEE to OpenLDAP and need to replace our current method of assigning password policies. We're using class-of-service. Is there any way to replicate this in OpenLDAP? Basically I want to assign a virtual attribute (pwdpolicysubentry) based on the value of another attribute (objectclass). For example users with objectclass: x would have pwdpolicysubentry:x and users with objectclass: y would have pwdpolicysubentry:y Thanks, Nick

1 0

Re: [EXT] Re: Clarification of LMDB transaction behaviour
by Ulrich Windl 15 Apr '20

15 Apr '20

On 4/9/20 7:33 PM, Howard Chu wrote: [...] > Tracking the existence of transactions in a language binding is almost certainly a wrong thing > to do, completely unnecessary. MHO: Actually as you must either abort or commit any transaction, any long-running application would need to keep track of active transactions. Complex control flows may need such. How does LMDB react if you try to abort a committed transaction, or trying to commit an aborted transaction (the other two cases should be idempontent, hopefully)? Such tings could happen easily if the application does not track the state of active transactions. >> >> Thanks in advance, >> >> -- >> Dorian Taylor >> Make things. Make sense. >> https://doriantaylor.com >> > >

2 1

Re: Read only Replica
by Marc Franquesa 12 Apr '20

12 Apr '20

What I like most of this list is that I always learnt (or remember) something in few posts. About the ServerID>0: Sure, didn't realized that and makes total sense, as ServerID is used to generate CSN changes, so if ServerID=0 then is not writting CSNs -> not a provider. About my setup and needs: At the end I'm going to deploy a N-way multimaster, but while testing just wanted to ensure no "accidental" writes reach the new 'tested' member. You solved perfectly all my concerns Thanks much Missatge de Quanah Gibson-Mount <quanah(a)symas.com> del dia dj., 9 d’abr. 2020 a les 17:31: > > > --On Thursday, April 9, 2020 6:19 PM +0200 Michael Ströder > <michael(a)stroeder.com> wrote: > >> a) syncprov (and possibly accesslog), no serverID >1, and no syncrepl > >> statement, it is a standalone provider > > > > should be: serverID > 0 <=> serverID >= 1 > > > >> b) syncprov (and possibly accesslog), serverID > 1, and a syncrepl > >> statement, it is a multimaster node > > > > should be: serverID > 0 <=> serverID >= 1 > > Correct, thanks. :) > > > Isn't mirrormode true not also needed for MMR? > > Ah right, thanks. :) > > >> I'm not really clear what you mean by "read only" in any of these cases. > >> If you want an LDAP server that accepts no writes at all, then you > >> shouldn't configure replication, as any writes that occur on the > >> provider will then occur on the consumer, and additionally set the > >> readonly configuration parameter to TRUE. > > > > He probably wants to implement a 2-tier replication topology where > > applications/systems access pure consumer replicas which do not accept > > write operations from normal clients but only the modifications > > retrieved via syncrepl from providers. > > (At least that's how Æ-DIR is designed. ;-) > > Yeah, that's my guess too, but their statements make that hard to > determine. ;) > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 1

Clarification of LMDB transaction behaviour
by Dorian Taylor (Lists) 10 Apr '20

10 Apr '20

Re-re-sending this because it appears twice not to have initially made it through: I have recently taken up stewardship of the Ruby binding for LMDB. It did not take me long to find problems in its design pertaining to concurrent transactions in a multithreaded environment. I would like to fix these problems but I am afraid I still have a few questions after carefully reading the LMDB documentation. First, I would like to confirm my understanding that there may be only one active read-write transaction per environment, irrespective of processes and/or threads attached, although this transaction may be nested. This raises some subsidiary questions: 1) The documentation states specifically that *read-write* transactions may be nested, but what about read-only? 2) Must (read-only) transactions always be in a single hierarchy per thread or can there be many “roots” at once? 3) Given that the relevant LMDB structs appear not to discriminate between transaction types, are there consequences for opening, e.g., a read-write transaction subordinate to a read-only one? The reason why I ask is that the current (inherited) design of the binding keeps a hash table of transactions keyed by thread, and does not distinguish between read-write and read-only, and affords only a single “root” transaction per thread (whether read-write or read-only). I don’t need the memory leaks, double-frees, deadlocks and other bad behaviour to infer that this structure is probably wrong. Based on what I can glean from the LMDB documentation, is that I probably want to separate the read-write and read-only transactions, make the former a singleton (since there can only be one read-write transaction per environment), artificially flatten the latter (since it probably isn’t meaningful to nest a read-only transaction anyway) and then wrap the transaction code so it does the right thing. What I suppose I’m looking for here is confirmation that my assumptions are correct. Thanks in advance, -- Dorian Taylor Make things. Make sense. https://doriantaylor.com

3 5

Read only Replica
by Marc Franquesa 09 Apr '20

09 Apr '20

I wrongly supposed that a LDAP server configured with replication (sycnrepl) and not using syncprov modules (so is only a consumer and not a provider) would automatically behave as a Read-ONLY replica as it will sync from other servers specified on the syncrepl settings but will not be providing deltas thru syncprov module. However I tested the following scenario (N-way multimatseer with one 'Readreplica') - Servers A and B with syncprov enabled (so they are providers) - Servers A and B both sync (syncprel) to the other (so they are consumers) - Added server C syncrepl to A and B, *BUT not loading syncprov*. So is a consumer only, (ReadReplica)? However I verified that I can make changes to C and they got stored into C. (Not replicated to A/B as they don't sync with C). - So how I got C behave like a true ReadOnly replica (denying writes)? - If I have to set some settings, note that I'm also replicating olcConfig tree cn=config, so how I got this setting applied only to one server? Thanks for any hints or explation on my doubts.

4 5

Can syncrepl do both database and acl?
by xuhua.lin＠gmail.com 08 Apr '20

08 Apr '20

In a simple provider-consumer setup, I added syncprov to both config (config, cn=config) and the database (mdb,cn=config) on the provider, added syncrepl respectively on the consumer. The initial replication seems working, entries added to provider will show up at consumer until an acl rule added into provider. When I check the consumer, the syncrepl directive in the (mdb, cn=config) is removed. I guess it's trying to replicate producer's config since there is no syncrel on the provider (I also see syncprov added to consumer). This defeats the purpose of database replication. Is this expected behavior? Did I miss anything? (In master-master setup, every server is replicating everything for each other.) Thanks, Xuhua

3 2

Re: [EXT] Slapd unexpectedly shutdown
by Kevin Olbrich 08 Apr '20

08 Apr '20

Am Di., 7. Apr. 2020 um 23:18 Uhr schrieb Quanah Gibson-Mount <quanah(a)symas.com>: > > > > --On Tuesday, April 7, 2020 11:36 PM +0200 Kevin Olbrich <ko(a)sv01.de> wrote: > > > Def. ANOM_ABEND: Triggered when a processes ends abnormally (with a > > signal that could cause a core dump, if enabled). > > > > Looks like it's actually crashing but I don't think it's because of > > "slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1" > > as I can see multiple lines before the crash. > > > > Is it possible that Slapd crashed if it tries to proxy data to a node > > while it shuts down? Maybe a special case when bind was successful but > > query failes? > > Hi Kevin, > > What OpenLDAP Release are you running? I ask, because there was a fix that > went into OpenLDAP 2.4.49 specifically for a crasher with back-ldap and > controls: > > <https://bugs.openldap.org/show_bug.cgi?id=9076> > > Regards, > Quanah > My version is 2.4.49+dfsg-2~bpo10+1 (buster-backports). Should be in there I think. I've now included ppolicy.schema to solve the issue. Tomorrow I will try if the issue is still present. Thanks for your input! Regards Kevin > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com>

3 3

Re: [EXT] Slapd unexpectedly shutdown
by Quanah Gibson-Mount 07 Apr '20

07 Apr '20

--On Tuesday, April 7, 2020 11:36 PM +0200 Kevin Olbrich <ko(a)sv01.de> wrote: > Def. ANOM_ABEND: Triggered when a processes ends abnormally (with a > signal that could cause a core dump, if enabled). > > Looks like it's actually crashing but I don't think it's because of > "slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1" > as I can see multiple lines before the crash. > > Is it possible that Slapd crashed if it tries to proxy data to a node > while it shuts down? Maybe a special case when bind was successful but > query failes? Hi Kevin, What OpenLDAP Release are you running? I ask, because there was a fix that went into OpenLDAP 2.4.49 specifically for a crasher with back-ldap and controls: <https://bugs.openldap.org/show_bug.cgi?id=9076> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

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