Re: Permissive Modify and mdb
On Sat, Mar 30, 2024 at 07:24:41AM -, lesig...@cirad.fr wrote: > Hi, > > I try to modify an entry with permissive modify control. The response > is protocole error : permissiveModify control value not absent. > > I check with wireshark the request, and there was no value with the > control, but the control was marked as critical. There is a difference between no value and empty value. Can you recheck? > The problem appears with openldap 2.5.x and 2.6.x with mdb database. > It is ok with openldap 2.4.x with bdb database. This check hasn't changed since 2.4.32 (released in 2012). > So is the permissive modify control supported with mdb database in > openldap >= 2.5.x ? back-mdb does indeed handle permissive modify control. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: kerberos-cache location
On Mon, Apr 01, 2024 at 03:09:12PM +0200, Stefan Kania wrote: > I normally use Debian for OpenLDAP and Kerberos, but now I have to uses > Alamalinux 9. When I create a Ticket with kinit I'm getting: > - > u1-prod@ldapserver1 ~]$ kinit > Password for u1-p...@example.net: > [u1-prod@ldapserver1 ~]$ klist > Ticket cache: KCM:10001 > Default principal: u1-p...@example.net > - > > So the ticket cache is the KCM-daemon and not FILE: like in Debian. When I > die an ldapsearch or an ldapwhoami I'm getting > --- > [u1-prod@ldapserver1 ~]$ ldapwhoami > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind: Local error (-2) > additional info: SASL(-1): generic failure: GSSAPI Error: > Miscellaneous failure (see text) (get-principal lstat(/tmp/krb5cc_10001)) > --- > > All the ldap-commands are looking for the credential cache in FILE: and not > in KCM: > > I'm using OpenLDAP 2.6 from the repositories. > > Is there a way that the ldap-commands are using KCM:? Hi Stefan, I assume libsasl2 is linked to heimdal, which doesn't (yet?) support KCM? And on Debian you might have been using heimdal as your libkrb5, so no KCM cache used. I think until then you need to switch to FILE based credential cache in your config or rebuild libsasl2 against MIT Kerberos to get access to it. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: The unique overlay: enforcing uniqueness in the union of trees
On Tue, Feb 06, 2024 at 12:29:37PM +, Norman Gray wrote:
> Greetings.
>
> How should I use the 'unique' overlay to enforce uniqueness of an
> attribute across two trees?
>
> I'd have thought that the following would work, to enforce uniqueness
> across ou=dept1 and ou=dept2, but it doesn't seem to.
>
> dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config
> objectClass: olcOverlayConfig
> objectClass: olcUniqueConfig
> olcOverlay: unique
> olcUniqueURI: ldap:///ou=dept1,o=example?uidnumber?sub
> ldap:///ou=dept2,o=example?uidnumber?sub
>
> (and cf, slapd/overlays/unique.c:unique_new_domain).
>
> When I configure a server with this, and load two entities with the same
> uidNumber, the server doesn't object. I'm clearly misunderstanding
> something.
>
> The slapo-unique(5) manpage suggests that having two URIs juxtaposed
> like this is syntactically OK, but it doesn't make clear the
> semantics of this. I'd guessed that the above configuration would
> create a 'domain' which is the union of the two subtrees, but
> that doesn't seem to be the case.
Hi Norman,
you're right, the uniqueness domains aren't specified anywhere and the
overlay currently just runs through each URI independently. It also
checks that the entry matches the URI as well, so a DN like
"uid=u2,ou=dept1,o=example" is only checked against the first URI and
dept2 wouldn't be checked.
The next best thing I can see is if you create two URIs, one for each
dept2 and dept3 more or less like this:
ldap:///?uidnumber?sub?(|\
(entryDN:dnSubtreeMatch:=ou=dept1,o=example)
(entryDN:dnSubtreeMatch:=ou=dept2,o=example))
ldap:///?uidnumber?sub?(|\
(entryDN:dnSubtreeMatch:=ou=dept1,o=example)
(entryDN:dnSubtreeMatch:=ou=dept3,o=example))
That should trigger exactly as you need and cover the relevant parts of
the tree. Not sure it works when there's a lot of gluing going on but
worth a try.
Regards,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Accesslog requirement for sync replication
On Mon, Feb 05, 2024 at 10:51:03AM +0100, Marc Franquesa wrote: > This bring me a new question (which I think I already get replied or found > in some place but now I'm unable to find) > > On a multiple replica setup (N-way Multimaster) setup, how does the server > identify itself in the multiple olcSyncrepl attributes to avoid trying to > replicate against itself ? Hi Marc, the main mechanism is that syncrepl stanzas where provider matches one of our configured URIs are not activated. And since you need to have olcServerID URIs set up as well, that's usually it. There's also some filtering based on the serverID as transmitted in the consumer's cookie but that's only a partial reduction. Regardless, even if a server started replicating from themselves you should experience no issues/endless loops if that's what you're worried about. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Accesslog requirement for sync replication
On Mon, Jan 29, 2024 at 10:23:10AM +0100, Marc Franquesa wrote: > Hi > > I have been using replication since long time without any issues (and still > without issues), but on recent versions I got this warning on the logs: > > syncprov_setup_accesslog: couldn't get definition for attribute reqType, is > accesslog configured? Hi Marc, are you running with syncprov-reloadhint by any chance? It's just a warning that syncprov might consider using the attribute but it's not defined. I've just moved the check to syncprov-nopresent[0] which doesn't really have any uses without an accesslog DB being around. > The answer is no, I never configured accesslog (this why I'm a bit > confused, as I never used/needed on my replication setup). After reviewing > the documentation I understand that for syncrepl I should load and > configure accesslog overlay. > > Although I have some questions/concerns I haven't been able to > found/understand from the documentation and would like someone clarifies: > > * Is there any way to implement replication without accesslog? (currently I > have it but I would like to not get that warning) No need for accesslog if you're doing plain syncrepl. > * If I setup accesslog, do I need to setup a different accesslog DIT for > each target DIT I replicate? Or can a single accesslog be shared with 2 > different target DITs? Yes, for delta-MPR you need separate accesslog per DB. > I mean: I'm currently replicating both cn=config (dynamic configuration) > and the main DIT (so 2 different contexts/DITs/trees) Do I need to use a > different accesslog DIT for each one or can they share the same DIT as > accesslog ? deltasync is not all or nothing, each DB can be set up separately (and AFAIK people don't usually do deltasync for cn=config). > * Does this log DIT needs to be backup up or is simply a log which I could > get rid of in case of recovery? Unless you're using it for auditing purposes, you just have to make sure to either: - backup and restore both DBs from the same exact version - or not restore accesslog (and wipe it on main DB restore) [0]. https://git.openldap.org/openldap/openldap/-/merge_requests/677 Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: openldap-technical mailing list probe message
On Fri, Jan 19, 2024 at 02:25:56PM +0100, Ondřej Kuzník wrote: > On Fri, Jan 19, 2024 at 09:41:46AM +0100, Gregory ROCHER wrote: >> Le 19/01/2024 à 09:29, Marc a écrit : >>> Any one else getting ~20 messages? >> >> Hi, didn't count but seems related to a a difficult debian/mailman upgrade >> >> https://mastodon.social/@hyc/111779961579178487 > > Yes, turns out mailman until 3.3.1 didn't deal with bounces (at all?) > and then on upgrade decided to process all of them[0]. I think Quanah > sorted that out now, what I'm aware of is some emails not turning up in > the archives. Depending on the reason, it might be that the yesterdays > submissions will never turn up in hyperkitty (the web archive) at all. > > I've adjusted what I believe is the reason, this email should double up > as a test to make sure it has been fixed now. I know it can be pretty annoying having to deal with a slew of automated emails like that and I apologise for this incident. And archiving seems to work now. If anyone is still seeing anything untoward with our mailing list or other openldap.org services, do let me know. Unrelated to this, we have temporarily shut down CVSWeb recently, can't promise it's coming back again. Regards, Ondrej -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: openldap-technical mailing list probe message
On Fri, Jan 19, 2024 at 09:41:46AM +0100, Gregory ROCHER wrote: > Le 19/01/2024 à 09:29, Marc a écrit : >> Any one else getting ~20 messages? > > Hi, didn't count but seems related to a a difficult debian/mailman upgrade > > https://mastodon.social/@hyc/111779961579178487 Yes, turns out mailman until 3.3.1 didn't deal with bounces (at all?) and then on upgrade decided to process all of them[0]. I think Quanah sorted that out now, what I'm aware of is some emails not turning up in the archives. Depending on the reason, it might be that the yesterdays submissions will never turn up in hyperkitty (the web archive) at all. I've adjusted what I believe is the reason, this email should double up as a test to make sure it has been fixed now. [0]. https://lists.mailman3.org/archives/list/mailman-us...@mailman3.org/message/IC3LXQMANJGOVUOCVUBHIOGYZ4PA24F7/ Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: lloadd and cn=config
On Wed, Dec 06, 2023 at 08:11:52PM +0100, Stefan Kania wrote: > Hi Ondrej, > > I restarted with a new test. > Now I'm having 2 loadbalancer one is configured via cn=config and one over > slapd.conf. Both are configured exactly the same. Same binduser, same > ldap-server same everything. > For my test I started tcpdump on the loadbalancer and on the two > ldap-server. > > Starting the loadbalancer which is configured via slapd.conf I can see all > the packages on both, the ldap-servers and the loadbalancer. > > Doing the same test with the loadbalancer configured via cn=config I see > absolutely nothing, no package is send. Hi Stefan, thanks for the info, I believe I've tracked it down and filed ITS#10142, if you're able to test patches, can you give MR!663 a go? https://git.openldap.org/openldap/openldap/-/merge_requests/663 Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: lloadd and cn=config
On Mon, Dec 04, 2023 at 03:42:34PM +0100, Stefan Kania wrote: > Am 04.12.23 um 15:00 schrieb Ondřej Kuzník: >> Hi Stefan, >> are you trying to use the load balancer before it has had a chance to >> establish its own connections? > > Hi Ondrej, > > setting loglevel to "conns" on both, the ldap-servers and the loadbalancer > I'm getting no entry in the log on the two ldap-server but on the > loadbalancer I see: > --- > Dez 04 15:33:54 loadbalancer01 slapd[1519]: lload_listener: listen=14, new > connection fd=29 > Dez 04 15:33:54 loadbalancer01 slapd[1519]: lload_connection_init: connection > connid=4 allocated for socket fd=29 peername=IP=192.168.56.24:50978 > Dez 04 15:33:54 loadbalancer01 slapd[1519]: client_tls_handshake_cb: connid=4 > finished > Dez 04 15:33:54 loadbalancer01 slapd[1519]: connection_read_cb: connection > connid=4 ready to read > Dez 04 15:33:54 loadbalancer01 slapd[1519]: operation_init: received a new > operation, bind request with msgid=1 for client connid=4 > Dez 04 15:33:54 loadbalancer01 slapd[1519]: request_bind: connid=4, msgid=1 > no available connection found > Dez 04 15:33:54 loadbalancer01 slapd[1519]: connection_write_cb: considering > writing to live connid=4 what=0 > Dez 04 15:33:54 loadbalancer01 slapd[1519]: connection_write_cb: have > something to write to connection connid=4 > Dez 04 15:33:54 loadbalancer01 slapd[1519]: handle_pdus: re-enabled read > event on connid=4 > Dez 04 15:33:54 loadbalancer01 slapd[1519]: connection_read_cb: suspended > read event on connid=4 > Dez 04 15:33:54 loadbalancer01 slapd[1519]: connection_read_cb: connection > connid=4 ready to read > Dez 04 15:33:54 loadbalancer01 slapd[1519]: operation_init: received a new > operation, unbind request with msgid=2 for client connid=4 > Dez 04 15:33:54 loadbalancer01 slapd[1519]: handle_one_request: received > unbind, closing client connid=4 > Dez 04 15:33:54 loadbalancer01 slapd[1519]: client_unlink: removing client > connid=4 > Dez 04 15:33:54 loadbalancer01 slapd[1519]: connection_read_cb: suspended > read event on connid=4 > Dez 04 15:33:54 loadbalancer01 slapd[1519]: client_destroy: destroying client > connid=4 Are you saying there are really no messages at all between lloadd startup and your client connecting to it? I will say it again: lloadd does not open any connections in response to client activity, they are established as part of its operation and until you have at least one, requests will be rejected with 52 Unavailable. You want to figure out why no connections are being opened (successfully). Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: lloadd and cn=config
On Mon, Dec 04, 2023 at 02:34:57PM +0100, Stefan Kania wrote: > Hello Ondrej, > > if I get: > -- > root@loadbalancer01:~# ldapsearch -x -D > uid=repl-user,ou=users,dc=example,dc=net -W > Enter LDAP Password: > ldap_bind: Server is unavailable (52) > additional info: no connections available > -- > > The log on the loadbalancer is showing: > - > Dez 04 14:19:33 loadbalancer01 slapd[883]: operation_init: received a new > operation, bind request with msgid=1 for client connid=1 > Dez 04 14:19:33 loadbalancer01 slapd[883]: request_bind: connid=1, msgid=1 > no available connection found > Dez 04 14:19:33 loadbalancer01 slapd[883]: operation_init: received a new > operation, unbind request with msgid=2 for client connid=1 > Dez 04 14:19:33 loadbalancer01 slapd[883]: handle_one_request: received > unbind, closing client connid=1 > - > > On the ldap-server I see, nothing in the log: > > Next thing I did was ldapsearch with "-d 3" and I got: > [...] > > i first tough it could be some TLS problem but as you see TLS is ok. > > Now I checked what I see on the both ldap-servers when restarting slapd, and > I see nothing. So no connection is established for the proxy authentication > on slapd start. > > If I switch to slapd.conf it works fine on both ldap-servers. > - > Dez 04 14:27:20 provider02 slapd[501]: conn=1047 fd=21 ACCEPT from > IP=192.168.56.24:59358 (IP=0.0.0.0:636) > Dez 04 14:27:20 provider02 slapd[501]: conn=1047 fd=21 TLS established > tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384 > Dez 04 14:27:20 provider02 slapd[501]: conn=1047 op=0 BIND > dn="uid=lloadd,ou=users,dc=example,dc=net" method=128 > Dez 04 14:27:20 provider02 slapd[501]: conn=1047 op=0 BIND > dn="uid=lloadd,ou=users,dc=example,dc=net" mech=SIMPLE bind_ssf=0 ssf=256 > - > There must be something wrong with the bind configuration. Hi Stefan, are you trying to use the load balancer before it has had a chance to establish its own connections? Can you provide logs from before you start interacting with lloadd with your client to see whether it's even had a chance to establish them? Loglevel at least 'conns'. lloadd's connection management is not reactive, it has to establish (some) connections to upstreams before anything can be proxied. Until any useable connections exist, every operation that cannot be processed locally will be rejected. Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: lloadd and cn=config
On Mon, Dec 04, 2023 at 11:40:29AM +0100, Stefan Kania wrote:
> Hi to all,
>
> when I setup the loadbalancer lloadd via slapd.conf everything is working
> fine. Here my slapd.conf
> [...]
>
> As soon as I change to cn=config with the following configuration:
> [...]
>
> -
> The slapd is stating and with "ss -tlpn" I see port 1636 and 1389 as listen
> (next to 636 and 389) I git the following errormessage when I try to contect
> the ldap-server via the loadbalancer.
>
> ---
> ldap_bind: Server is unavailable (52)
> additional info: no connections available
>
> ---
>
> Did I miss sommthing? I also try to translate the working slapd.conf with
> slaptest, but the result is the same.
Hi Stefan,
the configurations certainly look equivalent, but no connections to
provider1/2 are being established ("no connections available" to use),
can you see any errors in the logs that would show why that is?
Regards,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Problem with "force user to password reset at first login
On Fri, Oct 27, 2023 at 12:21:22PM -, rolf.stenh...@direct2internet.com wrote: > This topic comes up in search without a proper answer. The solution appears > to be. > 1. Set the pwdMustChange:TRUE in policies object (dn: > cn=default,ou=Policies,dc=my,dc=com) > 2, when creating set pwdReset: TRUE after creation of > using update (ldapmodify), this will lock out the from logins > of that account (but not password changes). I would add that setting the password by a "password administrator" (in OpenLDAP since 2.5 that's an identity with "manage" access on the userPassword attribute) will set pwdReset: TRUE automatically as per the Behera ppolicy draft. > 3. Edit or create a login script to check if pwdReset is true (or some > other method) and force to change user password through ldap > Step 3 may or may not be easy to setup in your environment, for > instance a special guest login for password changes could work. > > Important is to note that you cannot login to the created using > su when pwdMustChange:TRUE is set and pwdReset: TRUE is set for > , but the user is still allowed to change the password from > another user using ldap to set password. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: pwdEndTime usage
On Wed, Oct 11, 2023 at 02:42:06PM +0300, Volodymyr Lisnyi wrote: > Hello Ondřej, > >> pwdStartTime+pwdEndTime are completely independent of pwdMaxAge. And if >> set on an account, they are meant to be managed by the password >> administrator, not OpenLDAP. > > this is very interesting, where I can read information about this to prove > okta support that okta ldap daemon must respect pwdChangedTime or pwdReset, > because pwdStartTime+pwdEndTime isn't managed by OpenLDAP security policy. Hi you should read the latest ppolicy draft[0] and ppolicy manpage[1]. Also depends what kind of service Okta is meant to provide for you. >> I can't speak for Okta and whether they even support ppolicy at all. From >> what you're describing they probably don't? > > anyway they need to somehow get the user password expiration date, but what > you post about pwdStartTime+pwdEndTime (managed by the password > administrator), seem like the only way is use pwdChangedTime user attribute > + pwdMaxAge policy attribute or rely on pwdReset. But this just additional > thoughts, which I will forward to them after confirmation that > pwdStartTime+pwdEndTime > is meant to be managed by the password administrator. > Also, password administrator related to slapd means that a human (some > script) add/remove/update pwdStartTime+pwdEndTime for each user and this > can not be done by overlay/policy or other standard slapd functional. Password administrator is defined in the draft[0]. Okta can be it, just affects how certain features are (not) triggered. To find out when a password expires, you can follow the spec[2]. The ppolicy overlay also implements the old Netscape password usability control and advertises itself as such in rootDSE, just use the control (oid 1.3.6.1.4.1.42.2.27.9.5.8) and with the right privileges you will be given feedback about the account's validity. [0]. https://datatracker.ietf.org/doc/html/draft-behera-ldap-password-policy [1]. https://openldap.org/software/man.cgi?query=slapo-ppolicy&sektion=5&apropos=0&manpath=OpenLDAP+2.5-Release [2]. https://datatracker.ietf.org/doc/html/draft-behera-ldap-password-policy-11#name-policy-decision-points Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: pwdEndTime usage
On Wed, Oct 11, 2023 at 12:41:21PM +0300, Volodymyr Lisnyi wrote:
> Hello Ondřej,
>
>> Most often you need pwdMaxAge and react to password expiry accordingly.
>
> can you then explain why I have pwdMaxAge in the policy but users don't
> have pwdStartTime+pwdEndTime, that's what I am trying to achieve, but can
> not find any way to do this for now.
Hi Volodymyr,
pwdStartTime+pwdEndTime are completely independent of pwdMaxAge. And
if set on an account, they are meant to be managed by the password
administrator, not OpenLDAP.
>> slapd doesn't ignore pwdMaxAge if a policy is in effect (check!) and
>> doesn't need to store anything except pwdChangedTime to do this[0], also
>> pwdReset is independent of pwdMaxAge and you might want to check whether
>
> Maybe I was not clear, but I say the same that pwdMaxAge is not ignored by
> slapd and pwdChangedTime changed for the user during password change, same
> as pwdReset: True set after password expires confirm this.
Not sure what you mean.
>> Okta has/should have manage permissions on userPassword attribute:
>> depending on its understanding of ppolicy, that might/not be appropriate -
>> having manage permissions on userPassword makes one "password
>> administrator" and affects ppolicy behaviour (again read man slapo-ppolicy
>> and the latest draft[1] for more information).
>
> there is no problem with Okta managing users' passwords, the problem is
> that Okta ignores pwdReset and doesn't ask users to change expired
> passwords.
They should either implement ppolicy themselves or let slapd do this
(e.g. by letting it handle Binds). Not much OpenLDAP can do if they
ignore important parts of the spec (especially those that have been
around for more than a decade).
>> Per the ppolicy drafts, a password is expired if pwdChangedTime+pwdMaxAge
>> is in the past
>
> does this mean that pwdEndTime must be used to understand user password
> expiration?
> And if yes, how I can enable it, because as I posted above I don't see any
> flags for this not in "cn=passwordDefault,ou=Policies,dc=domain,dc=net" not
> in "dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config"
I can't speak for Okta and whether they even support ppolicy at all.
>From what you're describing they probably don't?
Regards,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: pwdEndTime usage
On Tue, Oct 10, 2023 at 09:09:52PM +0300, Volodymyr Lisnyi wrote: >> In this case it might be just another attribute, which can be used for >> example for a temp. guest account. In that case, a function to add it to >> all existing users would be pointless, because it is not designed for that. > > This attribute is needed for regular accounts, we don't have guest > accounts. That is why we need it on a regular basis and also need to > propagate it to existing users. pwdStartTime+pwdEndTime are used to set explicit password validity, regardless of password changes. Most often you need pwdMaxAge and react to password expiry accordingly. >> Why do zou want to use it, does the pwdMaxAge stopped working after the >> update? > > Some time ago (not sure when) okta ldap agent started ignoring "pwdReset: > TRUE", slapd daemon doesn't ignore pwdMaxAge and correctly set "pwdReset: > TRUE" for accounts with expired passwords. Okta support tested this on > their end and asked us to add pwdEndTime to users and test if this helps. > That's why I am trying to find a way add pwdEndTime to password policy and > propagate it to the users. slapd doesn't ignore pwdMaxAge if a policy is in effect (check!) and doesn't need to store anything except pwdChangedTime to do this[0], also pwdReset is independent of pwdMaxAge and you might want to check whether Okta has/should have manage permissions on userPassword attribute: depending on its understanding of ppolicy, that might/not be appropriate - having manage permissions on userPassword makes one "password administrator" and affects ppolicy behaviour (again read man slapo-ppolicy and the latest draft[1] for more information). [0]. Per the ppolicy drafts, a password is expired if pwdChangedTime+pwdMaxAge is in the past [1]. https://datatracker.ietf.org/doc/html/draft-behera-ldap-password-policy -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: setup two DNs on one single Openldap server running on Red Hat Enterprise Linux release 8.8 (Ootpa)
On Mon, Oct 02, 2023 at 09:37:41PM +0530, Kaushal Shriyan wrote: > Thanks Ulf for the email response. Any documentation to refer to set > up multiple databases in different backends in OpenLDAP? Generally you should refer to the Administator's Guide[0], specifically chapter 5 seems appropriate. It documents cn=config (man slapd-config), see man slapd.conf for equivalent options if using slapd.conf instead. It's as easy as configuring more than one (olc)Database entry. Before you progress any further, you also want to use a more recent OpenLDAP than 2.4 which has been deprecated for years now - you mention using Symas builds already, switching to 2.5 or 2.6 is easy and documented here[1]). [0]. https://www.openldap.org/doc/admin26/guide.html [1]. https://repo.symas.com Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: regular yum symas-openldap-servers update breaks permissions on /var/symas/openldap-data
On Tue, Sep 12, 2023 at 04:44:15PM +0200, cYuSeDfZfb cYuSeDfZfb wrote: > Hi, > > We're seeing this quite consistently. > > Before updating: > [root@ldaps01 log]# ls -l > /var/symas/ drwx--. 3 ldap ldap 50 Aug 28 16:28 openldap-data > > After updating: > [root@ldaps01 log]# ls -l > /var/symas/ drwx--. 3 root root 50 Aug 28 16:28 openldap-data > > And afterwards symas-openldap-server (running as ldap:ldap) no longer > starts, since permission denied on /var/symas/openldap-data. > > Reverting the permissions back to ldap:ldap solves it. But...WHY is this > happening. > > Are we somehow encouraged to run openldap as root..? > > Why would a post-install script reset permissions on > /var/symas/openldap-data? Hi, openldap-data is owned by the package and as such you'll have to tell rpm somehow (a trigger, ...) that you don't want it to mess with it. AFAIK there's work ongoing to make the directory 711 which should sort things for you. That's unless you're putting the databases directly into /var/symas/openldap-data, we advise you create a subdirectory per DB, e.g. /var/symas/openldap-data/dc=example,dc=com or /var/symas/openldap-data/cn=accesslog. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: slapd module thread synchronization and portability. __atomic_xxx().
On Thu, Aug 17, 2023 at 01:54:01PM +1000, Sean Gallagher wrote: > Hi OpenLDAP affiliates, > > I'm working on a slapd module and have started looking at thread safety. > > I've noticed that lloadd uses __atomic_xx GCC builtins but slapd does not. > Is there are reason for this? > > Does lloadd compile and run on all the same targets that slapd does? Hi Sean, lloadd has a slightly specific design in requiring non-blocking operation on some critical paths so its memory management subsystem uses atomics to achieve a partially lock-free implementation (epoch.c). It also assumes POSIX interfaces internally (i.e. it has not been ported to Windows yet). slapd has always been extremely portable, its design does not need any of the above and as such it relies exclusively on the much more portable libldap API. You should be fine with mutexes/conditions which you get from ldap_pvt_thread.h or even better rely on the locking slapd employs already (connection_get, ...) Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Help writing a slapd plugin
On Fri, Aug 04, 2023 at 10:44:12AM +, John Scott wrote: > Hi, > > Inspired by the proprietary server at ldap.dnssek.info, I'd like to > make a slapd plugin that, when queried for a particular email address, > finds the OpenPGP keys and S/MIME certificates by doing DNS lookups > (possibly aided by DANE), and then serves them back to the requestor. > > Currently the documentation in the OpenLDAP Administrator's Guide > still needs to be written. Since not a lot of software supports DANE > right now, but a lot of programs *do* support LDAP, I think a bridge > between the two is something that could really benefit the Internet > community. Could someone steer me in the right direction on how to get > started? Hi John, seems like you want to write an overlay that intercepts search requests and for each returned entry performs the work that you're describing. Other designs are possible. You can have a look in contrib/slapd-modules or servers/slapd/overlays to see what an overlay looks like and how it is configured. valsort overlay[0] seems like the nearest one in terms of which callbacks you might have to implement and the set up needed to get up and running. [0]. https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/overlays/valsort.c Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Idea for security module: Using dnX509peerNormalize() to validate client certificates
On Thu, Aug 03, 2023 at 10:00:37AM +1000, Sean Gallagher wrote: > Looking through the code, I see that dnX509peerNormalize() is called almost > immediately after the TLS is established and that it may be handled by a > callable handler installed by the register_certificate_map_function() entry > point. This would be an ideal place to inspect the certificate. The only > problem being it that there is no way to "reject" a certificate and force > the connection to be closed. > > It may be possible to use the ssl context passed into the > dnX509peerNormalize() function to close the connection but this would not be > very clean and likely have undesirable side effects. What would be good is > if dnX509peerNormalize() could return a particular error code to signal that > the connection should be immediately closed. Calling SSL_set_shutdown(SSL_RECEIVED_SHUTDOWN) sounds like it should do the trick? Next read will fail and so you never receive data that you consider "hostile"? > I see that LDAP_INVALID_CREDENTIALS is already used to signal benign invalid > credentials. > > Maybe a new error code is required. something like > "LDAP_HOSTILE_CREDENTIALS". Right now there is no way to tell whether a failure to extract a client DN is because there isn't any or that it's invalid. Someone would have to clean all the relevant code up to make this possible. LDAP_INVALID_CREDENTIALS corresponds to the "invalidCredentials (49)" resultCode as per RFC 4511 and is used in Bind handling, we're not at Bind time yet. If you want to prevent anonymous connections from doing anything, you might want to consider writing an overlay and attaching it to a DB or even globally. > This would seem to be a generally useful thing to have in the slapd core. Is > this something the OpenLDAP project would consider doing? Touching that code would probably tie into an overhaul of the entire SASL Bind identity support (EXTERNAL and otherwise): how librewrite comes into the picture, etc. Unless there is broad consensus on how that would look and work, I don't feel like that is going to happen any time soon? So 2.7 doesn't look like it would include this kind of change. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Feature Request: slapd: expose SASL EXTERNAL identity to olcAccess rules
On Tue, Aug 01, 2023 at 09:09:43AM +1000, Sean Gallagher wrote: > 3) Finally, if the system admin wants to use the TLS layer authentication > state to subtly modify access rights, that is also allowed by the RFCs, BUT > NOT BY SLAPD. > > I find slapd's incapacity in the third case to be a bizarre inconsistency. The ACL subsystem is extensible well beyond this and I find it bizarre that you keep ignoring that. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Feature Request: slapd: expose SASL EXTERNAL identity to olcAccess rules
On Mon, Jul 31, 2023 at 03:54:14AM +, Jordan Brown wrote: > On 7/30/2023 6:15 AM, Howard Chu wrote: >> If you want an identity to be associated to the session, you perform >> a Bind operation. > > A TLS session with a client certificate is authenticated, whether or not > you do a bind. Slapd ignores that authentication information unless you > do a bind with SASL/EXTERNAL. A TLS session might be authenticated, but RFC4513 is fairly clear on Bind being used to derive the authenticated identity of an LDAP session, in the case of TLS: "If a client that has provided a suitable certificate subsequently performs a Bind operation using the SASL EXTERNAL authentication mechanism (Section 5.2.3), information in the certificate may be used by the server to identify and authenticate the client." Similar with authorization identity. It later proceeds to state that the authorization state (not identity!) can take into account other factors and is a local matter. This is where ACLs operate and what Sean's proposing to be extended. My answer is that it's wrong to force the ACL subsystem to interact with the connection's TLS/local socket/... contexts where a perfectly good way to do this exists (a Bind request). If you want to add it, a dynacl module is the way, I would personally be open to then merging such a dynacl module into contrib/ but am not volunteering to writing it. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Feature Request: slapd: expose SASL EXTERNAL identity to olcAccess rules
On Thu, Jul 27, 2023 at 10:32:08PM +1000, Sean Gallagher wrote: > My clients are very asymmetric. Each has a particular job to do, and a > particular set of operations to perform on the database. I was trying to > restrict access for each client, to just what was needed for it to perform > it's task. Then if one client is compromised, damage can be (more) > contained. > > As it stands, before a bind, all (IP) clients look the same (Apart from the > IP address) - and so all clients need "auth" access to all other clients > credentials. If any client is granted some pre-bind rights, all clients get > those same rights. One compromised client makes all clients vulnerable. This > is not necessary. slapd _knows_ the identity of each client, it's just a > matter of exposing it to the ACL rules. It's not even without precedent, the > sasl_ssf is exposed to the ACL rules before a bind, why not other properties > of the sasl state? > > Anyway, this is just a "nice to have" idea, the real-life effect this would > have on security is pretty minimal. It's just frustrating when I have to > weaken access controls to do things the "right" way.. For now, your best bet would be a dynacl module. Or you can implement your proposed functionality yourself and see if we can get it merged. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Feature Request: slapd: expose SASL EXTERNAL identity to olcAccess rules
On Thu, Jul 27, 2023 at 03:17:41PM +1000, Sean Gallagher wrote: > Hi All, > > I have devised a work-around to slapd's inability to check client names on > Client certificates and am in the process of removing a proxy (haproxy) I > had in front of my slapd server. I have however come across an annoying > compromise and I'm offering here a suggestion on how to remove it. > > In particular, with the proxy, I could write rules targeting particular > clients that worked, even before their initial "bind" operation by using the > "sockname=" pattern in the access control rules. This does not seem possible > when slapd talks directly to the clients. before the initial "bind" > operation, only the IP address is available to tell clients apart, which are > not very reliable. IP addresses are easily spoofed. > > It would be much better to use the client certificate to match against the > particular client. Currently the client ID on the certificate is passed to > the SASL layer with the sasl_setprop(...,SASL_AUTH_EXTERNAL,...) call. There > it remains until the client performs a "bind" using the SASL EXTERNAL > mechanism. At this point, the EXTERNAL client ID is used to derive a > distinguished name by filtering it through the "olcAuthzRegexp". It should > be noted that LDAP v3 does not require the client to perform such a bind > operation. Hi Sean, I'm not sure what you're trying to achieve here. Why do you want to distinguish different kinds of anonymous clients? The usual answer to this is to have ACLs that prevent them from doing anything except a Bind, during/after which they have (a proposed) identity that is part of ACL processing. If you need to distinguish different "anonymous" clients from each other and give some additional access, you might have to define your own dynacl module that lets you define arbitrary logic, pretty sure even inspecting the connection/TLS session state. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: question on include ./acls/*.conf
On Wed, Jul 19, 2023 at 11:01:23AM +0200, cYuSeDfZfb cYuSeDfZfb wrote: > Hi, > > We're wondering: is there some clever way to include any number of .conf > files that exist in a certain directory? > > Something like, in slapd.conf: > > include /opt/symas/etc/openldap/acls/*.conf > > This would allow us to simply add & remove.conf files under that directory, > and restart openldap. > > Is that way of configuring (wildcard includes) not supported..? Or are we > missing something else? > > Is there some other way of doing this..? Hi, it's not supported at the moment. AFAIK people who need it usually add/remove includes in slapd.conf programmatically with ansible/puppet or assemble the whole file that way. I am looking into adding sudoers(5) style `includedir` directive support for slapd.conf, not clear whether it will make it into 2.7 yet. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: architectural question on master-slave vs multi-master
On Thu, Jun 22, 2023 at 11:07:25AM +0200, cYuSeDfZfb cYuSeDfZfb wrote: > Hi, > > As you have already may have discovered by my many posts lately, we're busy > with our ldap environment, and migrating from openldap 2.4 (bdb/RHEL7) to > 2.5 on mbd/RHEL9. > > We've always had a duo of masters, replicating to a (READ ONLY) duo of > slaves. > > All clients are configured to talk to the slaves, through a load balancer, > and the masters pretty much only receive updates to the DIT from IdM. > > Our problem is: how to handle failed authentications (ppolicy) considering > that the slaves are read-only and the slaves is where the failed > authentications take place. > > Hence, my request for feedback: is master-slave still considered "the best > way" of doing this? And then, is there a "standard way" to handle failed > authentications on read-only slaves? > > Or perhaps... is it nowadays better to chose for a simpler multi-master (4 > hosts) LDAP setup: four identical servers, where we choose to send clients > to two specific servers (firewalled differently to handle client access) > and two others to receive updates from IdM, but use multi-master > replication so that all changes (either from IdM, or from failed > authentications) are replicated equally between all four servers. > > Seems that new approach is much simpler. > > Any feedback? What is wise? Do you need the R/O servers for performance/operational/administrative reasons? If it's a no for all of the above, just a R/W cluster is fine. Otherwise you'll have to configure ppolicy+chaining on your replicas. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Proposal to strengthen slapd EXTERNAL authentication
On Thu, Jun 15, 2023 at 08:23:07AM +1000, Sean Gallagher wrote: > I'd like to propose a new feature to substantially strengthen the existing > access controls in slapd. This follows on from comments made in the > discussion around Issue 10065. In particular Comment 17 and Comment 19. > > The objective here is to validate the credentials supplied by external > security mechanisms BEFORE the main server loop starts, and terminate the > connection if the client is not "known". > > It was noted that the olcAuthzRegexp configuration option already deals with > externally supplied Authentication ID. My idea is to build on that. Hi Sean, olcAuthzRegexp deals with Bind requests only. > Any thoughts? By the sounds of it, you want to react to a connection being established. There's already a callback for this: bi_connection_init, so you can write your own module/overlay/etc. that would quarantine it until it was set up or find another hook that is closer to that. We might have to delay calling backend_connection_init() while c_needs_tls_accept is set. Or maybe add another callback for this, any thoughts on that Howard? Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: olcAccess rule with groupOfURLs
On Fri, Jun 09, 2023 at 04:13:46PM +0200, Souji Thenria wrote: > On 08.06.2023 23:15, Quanah Gibson-Mount wrote: >>> I tried to use group=... and group.exact=... without success. >>> The Administrator's Guide [1] says that group=... assumes that the >>> objectClass is "groupOfNames", and if I use another objectClass, I >>> should use: >>> by group//= >> >> That is for static groups, not dynamic groups. > > In that case, what's the correct approach to use a dynamic group inside > an olcAccess rule? > The Administrator's Guide says that dynamic groups are supported. But > either I am blind, or both the slapo-dynlist(5) man page and the Dynamic > Lists overlay section (in the Administrator's Guide) do not include > information about ACLS. See "man 5 slapd.access", it mentions both static groups (a DN-syntax attribute) and dynamic groups (attribute derived from labeledURI) in the "by groups=..." fragment. Dynlist isn't involved in ACL processing and you do not need to load/configure it for this to happen. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: SSL timeout
On Mon, May 22, 2023 at 05:30:00PM +, Robert T Dunn wrote: > Thanks for the response, Howard. > > Even though OpenSSL has an ASYNC option, are you saying not every TLS > engine supports async, so you can't add it to LDAP? Hi Robert, AFAIK at least the private API supports async operation, since that's what lloadd (the load balancer) uses. If you're seeing blocking behaviour in lloadd that would be a bug and if you can trigger that I would like to see a bug reported on this (except for callbacks into libsasl2 which doesn't support non-blocking operation). Otherwise, maybe have a look how this is accomplished there and propose any changes to the public APIs/their implementation to do this too. Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Debugging TLS negotiation failure
On Tue, May 16, 2023 at 03:18:18PM +, Lemons, Terry wrote: > 3. Remove the existing slapd configuration: > rm /usr/local/etc/slapd.d/* > > [...] > > 5. Re-create the openldap environment, using the updated slapd.ldif > > /usr/local/sbin/slapadd -n 0 -F /usr/local/etc/slapd.d -l > /usr/local/etc/openldap/slapd.ldif > > I found use of ldapmodify to be problematic regarding authentication, > so opted to just delete the current configuration and replace it. If server is stopped, you can always use slapmodify to edit the current configuration in-place instead of a wipe/reimport. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Mapping the groupOfNames' owner attribute to members' Manager attribute
On Sun, May 07, 2023 at 12:15:14PM -, sysadm+ldap-techni...@rolep.work wrote: > Hello, > Is there any way to map the groupOfNames' owner attribute to members' > Manager attribute without external scripts? Hi, don't know your exact requirements but maybe slapo-dynlist's dynamic lists could do it? Check out the manpage and experiment. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Overly variant
On Sat, May 06, 2023 at 05:07:31PM +0200, Stefan Kania wrote:
> 2. ldif
> ---
> dn: name={1}verw-tel,olcOverlay={2}variant,olcDatabase={2}mdb,cn=config
> objectClass: olcVariantRegex
> olcVariantEntryRegex:
> cn=(.+),ou=users,ou=verwaltung,ou=firma,dc=example,dc=net
>
> dn:
> olcVariantVariantAttribute=telephonNumber,name={1}verw-tel,olcOverlay={2}variant,olcDatabase={2}mdb,cn=config
> objectClass: olcVariantAttributePattern
> olcVariantVariantAttribute: telephoneNumber
> olcVariantAlternativeAttribute: telephoneNumber
> olcVariantAlternativeEntryPattern: ou=Verwaltung,ou=firma,dc=example,dc=net
> ---
>
> ldapadd is not crashing slapd anymore, but I got this message:
>
> adding new entry
> "olcVariantVariantAttribute=telephonNumber,name={1}verw-tel,olcOverlay={2}variant,olcDatabase={2}mdb,cn=config"
> ldap_add: Naming violation (64)
> additional info: value of single-valued naming attribute
> 'olcVariantVariantAttribute' conflicts with value present in entry
>
>
> So still not working.
>
> Both olcVariantVariantAttribute uses different attributes.
>
> so what is wrong?
Note the typo "olcVariantVariantAttribute=telephonNumber" vs.
"olcVariantVariantAttribute: telephon*e*Number".
Regards,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: How to get detailed connection error information?
On Thu, Apr 13, 2023 at 11:29:34PM +, Jordan Brown wrote: > On 4/13/2023 10:36 AM, Quanah Gibson-Mount wrote: >> Those are the result codes that are provided to the client per RFC. >> Feel free to write a new RFC expanding on the result codes. > > OpenLDAP could have additional non-RFC features that would allow you to > retrieve more error information. > > There are dozens of OpenLDAP-specific options. An OpenLDAP-specific > option could retrieve additional error information. > > So the first question is "does OpenLDAP have such a thing?". It sounds > like the answer is "no". Hi Jordan, AFAIK that's correct, some of what you're asking for depends on the errno, some of it is in TLS code and very little, if anything, is currently preserved for that kind of use. A pretty comprehensive walk of the codebase might be needed to cover the lot? > In that case, please consider this to be a request for such a feature. > Diagnosing LDAP client connection problems is a significant cost; > anything that we can do to make it easier would be worthwhile. I would > be happy to participate in the design and implementation of such a feature. Given you've already considered a usecase and some of the requirements users might have on this kind of feature, you're welcome to propose one yourself. If it's ready for inclusion in 2.7, that's where it could go. We can assist where you're unsure of the codebase and eventually review. If you want to go that route, let's move the planning into -devel. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: slapd broken w/ppolicy
On Tue, Apr 04, 2023 at 02:49:01PM -0300, Paulo Ricardo Bruck wrote: > So far so good but if I insert : > pwdMaxDelay: 40 > pwdMinDelay: 4 > > But if I test with a wrong password ( yyy) I got: > root@zeus:/usr/lib/python3/dist-packages# ldapsearch -xLLLZZD > uid=pauloric,ou=users,dc=contatogs,dc=com,dc=br -w yyy |wc -l > ldap_result: Can't contact LDAP server (-1) > 0 > > my openldap stop working.Active: inactive (dead) > > What am I doing wrong Hi Paulo, you aren't doing anything wrong, this is ITS#10028 which will be fixed in 2.5.15. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Problems with syncrepl and password changes
On Thu, Mar 16, 2023 at 10:12:41AM +0100, Manolo Garcia Alvarez wrote:
> Hello.
>
> We're having some problems with replication and password changes. Let me
> explain... In our institution we are using Shibboleth to provide SSO to the
> users. The credentials are stored in OpenLDAP, but due to the high demand
> (100 auths/second) and the high volume (more than 700K users), we had to
> split it in three servers:
>
>- one is the producer, which receives all of the changes (both data and
>password changes),
>- two are the consumers, sync'd with the producer via syncrepl.
>
> The two consumers are behind a load balancer and are used to perform the
> BINDs and the user lookup.
>
> The problem that we are facing is that in some cirscunstances (maybe high
> load, high traffic?) the syncrepl lasts more than expected, and that causes
> the next situation:
>
>1. an user changes its password, the object changes its modifyTimestamp
>to T1
>2. before the syncrepl gets to replicate that change, the user tries to
>authenticate with the new password, the balancer assigns one of the
>consumers (say C1), tries to bind, but the password is not yet changed, so
>it fails recording one pwdFailureTime and updating its modifyTimestamp to
> T2
>3. when syncrepl tries to update the object in C1, T2 is older than T1
>so it refuses to change the object ("dn_callback : new entry is older
>than ours cn=X,dc=acces,dc=uoc,dc=edu ours
>20230313155537.264968Z#00#00d#00, new
>20230313155506.235663Z#00#00b#00 ")
Hi Manolo,
this sounds wrong, is the host a provider or a consumer? Plain or
deltasync? If it's a provider a.k.a. has multiprovider (formerly
mirrormode) set, you need the replication to be mutual. If it's just a
consumer, you should set up chaining so that password failures aren't
stored locally but forwarded to the provider and you won't hit this.
Regards,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: After update slapd 2.5.13->2.5.14, dynlist memberOf not working anymore
On Thu, Mar 16, 2023 at 03:22:25PM +0100, Andreas Ladanyi wrote: > Hi, > > i changed my config a bit but it doesnt work. > > i dont have a dynamic group. Yes i configured a dynamic list. We want to add > the memberOf attribute to user entries. > > We have static groups with objectclass "groupofnames" which contain the DN > of users with attribute "member=uid=name," > > The user entries contain the attribute > labeledURI=ldap:///BASE_DN?entryDN?sub?(&(objectClass=groupOfNames)(member=uid=name,..)) > > So the DNs of all the static groupofname groups which a user is a member of > should be returned by the dynlist URI expansion. > > > The dynlist modul should map the entryDNs of the expansion to memberOf and > the memberOf attribute should be delivered with the user entry output when > ldapsearch: > > dynlist-attrset labeledURIObject labeledURI memberOf:entryDN > > ldapsearch -H ldap://LDAP_Server -s sub -b BASE_DN '(|(uid=username))' > memberOf > > ldapsearch with no result. Hi, is there a reason you don't just follow what the dynlist manpage says for static groups? e.g. dynlist-attrset groupOfURLs memberURL member+memberOf@groupOfNames That way you can get rid of having to set labeledURI on each of the users as well... Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: After update slapd 2.5.13->2.5.14, dynlist memberOf not working anymore
On Mon, Mar 13, 2023 at 10:58:12AM +0100, Andreas Ladanyi wrote: > Hi, > > after upgrade from 2.5.13->2.5.14 i cant get any search result from slapd > when filtering for specific memberOf=value. If i downgrade back to slapd > 2.5.13 all is working again. > > It doesnt work with ldapsearch nor with sssd-ldap modul when filtering > entities with a specific memberOf=Value: > > ldapsearch -o ldif-wrap=no -LLL -x -ZZ -H ldap://ldap-server -b > OUR_BASE_DN '(memberOf=.)' memberOf uid > > ldapsearch shows the entities with memberOf attribute and the memberOf value > if i search without a specific memberOf value in the filter: > > ldapsearch -o ldif-wrap=no -LLL -x -ZZ -H ldap://ldap-server -b > OUR_BASE-DN memberOf > > > The dynlist config is: > > dynlist-attrset labeledURIObject labeledURI memberOf Hi Andreas, I'm pretty sure you configured a dynamic list (whose behaviour has been tightened recently) that you're using as a dynamic group. See the slapo-dynlist manpage for an example how we recommend setting this up. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Content Sync Refresh Required
On Tue, Feb 28, 2023 at 01:42:20PM +0100, Geert Hendrickx wrote: > We've had (and still have) this issue with large attributes and large > multi-valued attributes with Zimbra (see previous discussion with Quanah), > where we applied sortvals and multival. But in this scenario it's not the > case; all objects are of similar small size, with (mostly) single valued > attributes. Yet our freelist reaches 200K+ free pages during periods with > heavy updates (mostly deletes/adds), which has a measurable impact on write > performance. Hi Geert, are you sure it's the freelist and not the random access as pages become non-contiguous? The former would represent a constant decline in performance where the latter would eventually taper from high (best case) performance to regular performance you should be able to expect? Have you been able to rule that out? > For batch migrations we recently tried combining multiple updates into LDAP > transactions, which is significantly faster on a clean db, but makes the > freelist performance impact *worse* once the freelist is large enough. > Could it be because transactions require larger free pages which makes it > go through the entire freelist? Someone else needs to comment on that. >> It should be safe to include the accesslog *if* server was shut down >> cleanly and everything was flushed into both. > > Should nightly backups include the accesslog as well then? (implying we > can no longer make simple mdb_copy backups while slapd is running... > Or is it good enough to dump the accesslog *after* the main db, so it > includes the relevant AND newer accesslog data?) Disaster recovery does not need accesslog unless you need it for auditing purposes, but given you are happy to wipe it, I don't think that's the case. What you're doing here is not disaster recovery and you can't do this online. >> Do you configure persistent or in-memory sessionlog? > > in memory After you kill accesslog, you disable deltasync. Since you're also restarting, the provider has no data on how to replay anything and needs to send the list of all entries (at least their UUIDs). This is expensive and slow. Replication seems to proceed in slow leaps that cost a *lot* of processing on the provider and a fair amount of bandwidth. Isn't that what you're seeing? >> Are your accesslog entries so large that they don't fit a page? If not, >> just let the freelist be reused for the next time you have a large batch >> of updates again. That's what it's there for. And even then, accesslog >> in particular shouldn't really suffer from fragmentation as much as the >> main DB would. > > Ok. We're seeing 1M+ free pages in the accesslog after large batch jobs > and subsequent logpurge. It could be completely innocent like you say, > we just clean it up as a precaution due to the proven main db perf issue > mentioned above. We'll hold this off for now and see. As I always suggest, when you have a hypothesis, see if you can test it before you implement something in production. If you can also report here how it went, we can help you confirm/form a better one. In this case, I think performance settles and you can adjust resources to match your requirements. >> Yeah, in δ-multiprovider both main DB and accesslog (and their >> contextCSNs) are used together and should be monitored as such. > > Thanks for your advice, will revise the monitoring. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Content Sync Refresh Required
On Mon, Feb 27, 2023 at 08:12:44PM +0100, Geert Hendrickx wrote: > On Mon, Feb 27, 2023 at 19:18:38 +0100, Ondřej Kuzník wrote: >> Hi Geert, >> you didn't answer the questions whether you also monitor the accesslog's >> contextCSN? In deltasync, the combination of both is important. > > Ok, we don't. I'll take a look next time things are drifting. > > In a stable environment, the accesslog's contextCSN is identical to the > main db's contextCSN, for every SID. Hi Geert, yes, accesslog's contextCSN should always be in sync with its main DB. >> My emphasis on "incremental". Usually when contextCSN and cookie are >> found to be incompatible (missing sids from cookie, or even tighter >> constraints when configured with syncprov-sessionlog-source), it tells >> the consumer to step down from deltasync or start without a cookie. > > Ok, I assumed the consumer decides on its own if it's in sync with a given > provider, by comparing its contextCSN to the provider's, and only if it's > NOT in sync, query the provider's accesslog for delta sync from the CSN > it's currently at, if possible. Except for initial sync (no data in consumer), the consumer always tries deltasync first. Provider then proceeds accordingly or tells the consumer to fall back to plain syncrepl (the most common reason to see e-syncRefreshRequired - 4096). >>> At least for the main db, it makes a significant performance difference if >>> the accesslog gets too large. Therefor we mdb_copy -c the database from >>> time to time. We do this on one server, then distribute this mdb to other >>> servers and drop their accesslog, since it doesn't match the (imported) >>> main db anymore. But then other replica's start logging "Content Sync >>> Refresh Required" for the corresponding rid, even if no updates are coming >>> in through *that* server, so its contextCSN is static. >> >> You mean accesslog DB or accesslog freelist? Also now you're saying >> you're obliterating the whole accesslog (and compacting the mainDB), >> where previously you said you were compacting accesslog. > > We are compacting (mdb_copy -c) the main db on one server, AND throwing > away the accesslog on other servers where we import this mdb, because it > then no longer matches the local accesslog. > > Context at https://openldap.org/lists/openldap-technical/201708/msg00049.html > (although this was about a different LDAP database than the one we're > currently talking about.) Unless your entries are larger than pagesize *and* you have massive churn on those, you don't want to do this. Are you confident that's the case? What is your number of overflow pages? What kind of entries is it down to? If it's entries with large number of values in an attribute (e.g. groups), you might also want to look into sortvals (see man 5 slapd.conf) and multival (man 5 slapd-mdb) to store them more efficiently. > This always went fine, but now turns out to confuse other consumers in an > MMR environment. Should we instead run mdb_copy -c locally on each server? > (this can be a pretty slow operation) Or is there another "clean" way to > copy mdb databases between replica's? Include the corresponding accesslog? It should be safe to include the accesslog *if* server was shut down cleanly and everything was flushed into both. Do you configure persistent or in-memory sessionlog? > The other scenario was that after large batch updates, when the accesslog > has grown much bigger than usual (which is not a problem in itself), after > logpurge this leaves a large freelist in the accesslog as well. So as a > precaution, we "clean up" here as well by just dropping that accesslog - > obviously at a quite time and when all servers are in sync. This turned > out to be a mistake. Are your accesslog entries so large that they don't fit a page? If not, just let the freelist be reused for the next time you have a large batch of updates again. That's what it's there for. And even then, accesslog in particular shouldn't really suffer from fragmentation as much as the main DB would. >> If this is the case then yeah, you're removing every way the servers >> could have performed an efficient resync after reconnect/restart and >> that will take time and processing power to perform (probably running a >> refresh present, which is only one step up from a total resync). This >> makes little sense operationally. > > Ok, so far we only looked at the contextCSN of the main DIT, assuming this > told the whole story. Yeah, in δ-multiprovider both main DB and accesslog (and their contextCSNs) are used together and should be monitored as such. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Content Sync Refresh Required
On Mon, Feb 27, 2023 at 03:53:49PM +0100, Geert Hendrickx wrote: > We monitor and compare the contextCSN's continuously, that's how we noticed > the replication was not continuous anymore, but in "bursts". It seems to > reinitiate a full sync all the time (every 5 to 10 minutes), as long as new > updates were coming in. It only got back to regular delta sync once we had > a long enough period during the night with no updates. Hi Geert, you didn't answer the questions whether you also monitor the accesslog's contextCSN? In deltasync, the combination of both is important. > What exactly is the meaning of the 4096 ? See RFC 4533: "The server is REQUIRED to: ... c) indicate that the *incremental* convergence is not possible by returning e-syncRefreshRequired," My emphasis on "incremental". Usually when contextCSN and cookie are found to be incompatible (missing sids from cookie, or even tighter constraints when configured with syncprov-sessionlog-source), it tells the consumer to step down from deltasync or start without a cookie. >> Also not sure you need to touch accesslog so often, why not size your >> storage to deal with the extra capacity properly? Having a large >> freelist shouldn't be considered a problem in and of itself. > > At least for the main db, it makes a significant performance difference if > the accesslog gets too large. Therefor we mdb_copy -c the database from > time to time. We do this on one server, then distribute this mdb to other > servers and drop their accesslog, since it doesn't match the (imported) > main db anymore. But then other replica's start logging "Content Sync > Refresh Required" for the corresponding rid, even if no updates are coming > in through *that* server, so its contextCSN is static. You mean accesslog DB or accesslog freelist? Also now you're saying you're obliterating the whole accesslog (and compacting the mainDB), where previously you said you were compacting accesslog. If this is the case then yeah, you're removing every way the servers could have performed an efficient resync after reconnect/restart and that will take time and processing power to perform (probably running a refresh present, which is only one step up from a total resync). This makes little sense operationally. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Content Sync Refresh Required
On Fri, Feb 24, 2023 at 11:08:26PM +0100, Geert Hendrickx wrote: > We're on OpenLDAP 2.5.14, built from source on EL 8. > > After dropping the accesslog on an MMR master, we keep seeing on all > replica's: > >> do_syncrep2: rid=xxx (4096) Content Sync Refresh Required > > and all replica's keep falling back to refresh mode every few minutes. > > It's strange because we do this more often (typically after batch updates, > which leaves a large freelist in the accesslog upon pruning), but it's the > first time we hit this issue. We stopped the master (at a time no updates > are coming in), drop the accesslog, and start it again. > > Does it make sense to wait until this fixes itself? Or should I fix this > manually somehow? I already tried mdb_copying the provider db to the > replica's, but the same thing keeps happening. In the meantime replication > is working very slowly... Hi Geert, I would start any investigation by comparing the contextCSNs between nodes (both DB and its accesslog). Also check the reason why the provider sends 4096. Also not sure you need to touch accesslog so often, why not size your storage to deal with the extra capacity properly? Having a large freelist shouldn't be considered a problem in and of itself. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Entering Multi-Byte Values for DirectoryString attributes
On Tue, Feb 21, 2023 at 05:32:01PM +0100, Ede Wolf wrote: > Hello Ondřej, > > Thanks very much! That is exactly the anwer I have been looking for - even > more so in fact, as additionally I have been educated, that the dn is a > different part from the rest of the ldif. Makes sense, but I've never really > thought of this before. Correction: the dn is the same as anything else in the LDIF, it is the server that then does extra processing on the text it receives because its syntax is a DN, just like a 'member' attribute, 'seeAlso' and others like them will allow you to do the same - they are of the distinguished name syntax. Or like with the 'cn' attribute you can write 'TEST' or 'tEst' and they will be considered equivalent, because its syntax says so, not because the client did anything. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Entering Multi-Byte Values for DirectoryString attributes
On Tue, Feb 21, 2023 at 04:10:53PM +0100, Ede Wolf wrote: >> The same way you would enter Unicode in any other application. This >> is not an LDAP- or LDIF-specific question. >> >> 1) use a terminal and locale that support UTF-8. >> 2) use whatever tools your OS provides for entering Unicode >> characters. Probably something named "Unicode character map" or >> similar. > > Thanks again. But my question regards the values for attributes. > > Having a ldif file, for the dn I can enter: > dn: cn=A \F0\9F\99\82 Test,dc=example,dc=com > > That would literally give me the utf8 smiley icon as part of my dn - > provided my font feratures that, of course. > So I can use the hex encoding representation to enter any UTF-8 character. > > I can even search for that icon, using that hex encoding as search base or > part of the search filter. > > However, for a value, I cannot do this, and my question is, is there a way > at all? > This has nothing to do with my console. > > For a directorystring attribute (it value), is there any way of entering > code points straight into my ldif - be it U+ or hex notation - and > having the server interpret them, as it works for the dn? > > Not copy+paste from the command line, but, again, as encodigs where the ldap > server knows, these are to be interpreted. As it does for the dn. > > Something like: > cn: A \F0\9F\99\82 Test > > Just with a syntax that works. If that it possible at all. Hi Ede, in a search filter you are dealing with RFC 4515 which describes how to escape values into that string, similar with URIs, which have their own escaping rules you can leverage for this. With LDIF, you are dealing with RFC 2849 which has no concept of escaping values: you can enter a value as-is, base64 encoded or pass it from a separate file/URI but that's it. The client doesn't do any processing of the ldif data (unlike URLs, or filters, as discussed above) and will pass it on as it sees it, so it will send the text 'cn=A \F0\9F\99\82 Test,dc=example,dc=com' as DN. It is up to the server (and the attribute's syntax) to decide what happens with whatever you've input. In the case of DNs, sending 'cn=A \F0\9F\99\82 Test,dc=example,dc=com' is then (server-side) considered equivalent to you specifying 'cn=a 🙂 test , dc=EXAMPLE, dc=cOm' as per RFC 4514. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: using SRV-records in syncrepl
On Fri, Jan 20, 2023 at 03:33:21PM +, Norman Gray wrote: > Ondřej, hello. > > On 20 Jan 2023, at 10:47, Ondřej Kuzník wrote: >> That said, patches implementing some kind of SRV are welcome. The easiest >> way might be to introduce an lloadd tier implementation that manages its >> backend collection accordingly. > > It's not an OpenLDAP patch, but I've attached a module which might be > of interest here. This exposes a function > > char* get_sorted_srv_records(const char* domain); > > which does a SRV lookup, and orders the records that come back > according to the specification of RFC 2782 (though in a single pass, > rather than the clumsy multiple pass algorithm that the RFC suggests). Hi Norman, DNS retrieval and parsing of SRV records is the easy part, and libevent has code to help us with that already. It's the management of the backends on the tier (shutting down those that aren't listed anymore, adding those that are new, rearranging the lists) all while the server is still running unless we request a full server pause for it. And any of the backends being removed might still have pending operations, what do we do with those? And then the code that uses those levels and weights for each request that comes in, in an efficient way. But a lot of that is in lloadd (tier "weighted") and/or libldap already. All of this is managed if you have another process that manipulates cn=config for you and it can make some of those decisions as appropriate for your own deployment. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: using SRV-records in syncrepl
On Thu, Jan 19, 2023 at 04:39:26PM +0100, Stefan Kania wrote: > Hi Ondřej, > > I know, that I can put more then one uri to the "provider"-entry of > syncrepl. The questions comes up wile installing and testing lloadd. So it > not a special lloadd-thing. In general I would like to know if I could use > the SRV-records. That would make changing an OpenLDAP-Server (and it's > DNS-name) easy. I only need to change the SRV-record and don't have to > modify each ldap-server. Like in sssd and kerberos. Hi Stefan, unlike back-ldap etc., lloadd opens a pool of persistent connections to configured servers ahead of time. Using SRV records as a configuration source has been on the wishlist however there is no way of getting notified that the record has been changed. On top of that, it has been found much easier to maintain a separate manager process (a human with a checklist, ansible, some kind of provisioning tool, consul/nomad triggered script, k8s operator, ...) that updates its configuration when needed. That said, patches implementing some kind of SRV are welcome. The easiest way might be to introduce an lloadd tier implementation that manages its backend collection accordingly. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: using SRV-records in syncrepl
On Thu, Jan 19, 2023 at 11:48:45AM +0100, Stefan Kania wrote: > hi to all, > > is it somehow possible to finde the provider in "syncrepl" of a consumer via > DNS SRV-records. > If I have several providers with lloadd in front of it and the consumers are > only contacting the loadbalancer, the it would be nice to use the > SRV-Records of the DNS. I could then set up two loadbalancer with a > different priority, so if one failed the consumer would switch to the second > loadbalancer. Just an idea :-). Because using just one loadbalancer it will > be a single point of failure. Hi Stefan, or you can use libldap's fallback capabilities where a URI can be in the form of "uri1,uri2,uri3,...", and using that scheme in syncrepl's provider="" option, you don't even need a load balancer for that. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: dynlist vs memberof performance issues
On Mon, Jan 09, 2023 at 11:39:47AM -0800, Paul B. Henson wrote: > We're currently using dynlist to add the memberOf attribute to users. > One thing that was nice about the new dynlist implementation in 2.5 was > that it allows searching on the dynamic memberOf attribute which we > couldn't do in 2.4. Looking at the commit diff, there's one part that > says: > > "To enable filter evaluation on the dynamic list, the configuration must > be changed to explicitly map the dynamic attributes to be filtered" > > This just applies to groups created dynamically, right, not static > objects that get dynamic attributes added? Our current config is: The latest manpage update should make it clearer how dynamic *lists* differ from dynamic *groups*. And yes, no need to change config for groups. If you can give the current 2.5/2.6 branch a go, or if you decide to wait until we get a call for testing out, feedback is always welcome. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: lloadd Proxied Authorization Denied (123)
On Thu, Dec 15, 2022 at 03:02:00PM +0100, Stefan Kania wrote:
> --
> dn: cn=config
> changetype: modify
> replace: olcAuthzpolicy
> olcAuthzpolicy: any
> --
> Or do i have to set it inside the database for my object?
This is a global setting so that's the correct place.
> Then I changed the uid=lloadd to:
> ---
> dn: uid=lloadd,ou=users,dc=example,dc=net
> objectClass: account
> objectClass: simpleSecurityObject
> objectClass: top
> uid: lloadd
> userPassword: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$MTIz..
> authzFrom: ldap:///dc=example,dc=net??sub?(uid=*)
> ---
>
> But still not working. I also try it with "authzTo", but same result. As I
> read in man slapd.conf. At the beginning I just whant to get it working,
> then comes the security part. So I allow all uids.
Should be authzTo if you're adding it to the lloadd's identity, are you
sure uid=lloadd,ou=users,dc=example,dc=net has 'auth' (+x) access to
dc=example,dc=net and the uid attribute on the subtree?
Regards,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: lloadd Proxied Authorization Denied (123)
On Thu, Dec 15, 2022 at 01:43:41PM +0100, Stefan Kania wrote: > Am 15.12.22 um 13:10 schrieb Ondřej Kuzník: >> Hi Stefan, >> the backends are refusing the lloadd's identity (in your case >> uid=lloadd,ou=users,dc=example,dc=net) the permission to act as a proxy >> for the users in question. You should define a policy on the backends >> that allows this: you can do so using the authz-policy and >> authzTo/authzFrom attributes, see the slapd manpage for how they work. > > Ok, thank you, I will take a look at it. Up to now I only using authz-regexp > together with Kerberos. That's also used and the two should work together just fine. >> Note that since this control is added to every (non-bind) request we >> proxy, requests with this control present will end up with two and will >> be rejected by the backend, lloadd does not have a policy engine of any >> sort so it cannot decide whether it should be allowed or not, the only >> case exempt from this is if a client uses lloadd's own identity. > > So that means, at the moment it's not possible to identify as an other user > as the bind-user from the lloadd configuration to the backend-server? It's not possible inside lloadd but when lloadd uses an identity A and a client binds with identity B, then sends an operation to it, what the backend receives is an operation with proxyauthz carrying B over a connection bound to A. If authz-policy says that's allowed, normal processing is done with B's identity (you can use the prefix "real" to check A's identity in ACLs if needed, see man slapd.access). > I normaly have different clients with different users and different ACLs to > access the DIT. Yeah, that's fine and usually the reason to use "feature proxyauthz". Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: lloadd Proxied Authorization Denied (123)
On Wed, Dec 14, 2022 at 09:20:14PM +0100, Stefan Kania wrote: > I now took the example configuration and changed it to my settings: > > - > feature proxyauthz > bindconf bindmethod=simple > binddn=uid=lloadd,ou=users,dc=example,dc=net > - > > The bind-user exists in the database of the backend-server. If i start the > loadbalancer I can see that the connection are established. > > [...] > > I see the same messages on ldap02, so that's ok > > Then I do a search from a different machine: > > [...] > > - > root@ldap03:~# ldapsearch -x -D uid=repl-user,ou=users,dc=example,dc=net -w > geheim -H ldaps://loadbalancer.example.net:1636 -LLL > Proxied Authorization Denied (123) > Additional information: not authorized to assume identity > > > Why do I get different log-entries on the backend-server? And what did I > forgot? > > [...] > > So what's the point I'm missing to get proxyauthz work correctly? Hi Stefan, the backends are refusing the lloadd's identity (in your case uid=lloadd,ou=users,dc=example,dc=net) the permission to act as a proxy for the users in question. You should define a policy on the backends that allows this: you can do so using the authz-policy and authzTo/authzFrom attributes, see the slapd manpage for how they work. Note that since this control is added to every (non-bind) request we proxy, requests with this control present will end up with two and will be rejected by the backend, lloadd does not have a policy engine of any sort so it cannot decide whether it should be allowed or not, the only case exempt from this is if a client uses lloadd's own identity. Some future version might be able to hand over some authentication and authorization processing to the host slapd and this would allow us to decide what value to pass in the proxyauthz control but implementation has not started yet. I would be happy to guide anyone willing to implement this. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: lloadd standalone daemon
On Wed, Dec 14, 2022 at 06:57:05PM +0100, Stefan Kania wrote: > Am 14.12.22 um 18:17 schrieb Quanah Gibson-Mount: >> --On Wednesday, December 14, 2022 5:58 PM +0100 Stefan Kania >> wrote: >>> Hi to all, >>> >>> I want to test the "lloadd" as a standalone daemon. I'm using the symas >>> OpenLDAP 2.6 packages on a debian 11 system. I can only find the module >>> "lloadd.la" but not the standalone daemon. If I want to us it, do I have >>> to compile it myself? >>> >>> What would be the better way using the standalone daemon or use it as a >>> module as part of slapd. Hi Stefan, usually the slapd module is preferred (due to cn=config and cn=monitor support, see RELATION TO SLAPD(8) in the lloadd manpage), and since we only get to build one in a single installation, Symas packages offer that. >> You can run lloadd as a standalone slapd instance that loads the lloadd >> module. > > That's ok but the manpage for lloadd is telling me: > > SYNOPSIS > /opt/symas/lib/lloadd . > > And the manpage for lloadd.conf is telling me: > > DESCRIPTION >The file /opt/symas/etc/openldap/lloadd.conf contains configuration > information for the lloadd(8)daemon > > But non of the two files are existing. There is no lloadd.conf in /opt/symas/etc/openldap/ just like there is no slapd.conf in that installation, this is just the default path for the file. However a sample file slapd.conf.default is provided for slapd.conf and maybe it would be useful that a lloadd.conf.default be provided too. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Detecting replication delay when replicating a subset of data
On Mon, Dec 12, 2022 at 04:58:44PM +0100, Michael Ströder wrote: > On 12/12/22 16:47, thomaswilliampritch...@gmail.com wrote: >> For one particular use case we replicate a subset of the application >> database, but our replication check cannot work for this use case. > Partial replication is somewhat tricky because the highest entryCSN value > seen in a replicated entry might not the same like the highest entryCSN > value in the full data set (the latter stored as contextCSN at the > provider). > > So from my understanding just comparing contextCSN values will not work. Comparing entryCSN values will not work because of what you note, but if using OpenLDAP's own syncrepl (olcSyncrepl), contextCSNs should work just fine as they record whatever has been passed in the cookies. It might be necessary to retrieve if from the right place (manageDSAit on the suffix entry or reading the subentry if it was necessary to store contextCSN there). As usual I will note that you don't want to use contextCSNs for anything apart from being able to tell whether the contextCSN sets are up to date or not. Especially avoid guessing "replication delay" from its differences, doing so will yield meaningless values more often than you think. If you want to measure replication delay, use a time-series DB or syncmonitor[0]. > Since release 2.5 there's more replication info in back-monitor. Didn't have > the time to adapt my own monitoring checks to this though. [0]. https://git.openldap.org/openldap/syncmonitor Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: How to debug out of sync servers ?
On Thu, Oct 13, 2022 at 07:27:24AM -0500, Shawn McKinney wrote: > On Oct 12, 2022, at 9:25 AM, Frédéric Goudal > wrote: >> The behaviour that seems to occurs is that the logging sometimes stop >> (nothing more to do it seems) and when it stops the servers are in >> sync. So it seems the sync operations are very slow. Of course I do >> not log on normal operation. > > Where I’d start is to quantify how far out of sync they’re getting. A > good tool for that is the slapd watcher. It calculates based on > contextCSN’s and also provides stats from the monitor database. > > ldap://m02 > > EntriesBind Unbind SearchCompare Modify > ModDNAdd DeleteAbandon Extended > Num 578764502 1 44492 1 1 >018055171515081 0102 > Num/s 0.00 0.00 0.00 0.19 0.00 0.00 > 0.00 0.00 0.00 0.00 0.00 > contextCSN: 20221011141123.463727Z#00#001#00 actv@2022-10-10 > 13:08:15, idle@2022-10-11 19:16:45 > contextCSN: 20221011141123.851236Z#00#002#00 actv@2022-10-10 > 13:08:15, ahead 16:17:51, max delta 16:17:51 I would note that slapd-watcher's 'max delta' is *not* the same as replication delay, treating is as such would be committing the same mistake as most replication monitoring tools out there are doing. Watcher's output is for manual realtime monitoring and needs to be interpreted with caution. To measure replication delays one needs to take out a clock and measure how long it actually took, never calculate the difference of CSNs. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: RE25 testing call (2.5.14)
On Tue, Oct 04, 2022 at 06:38:36PM -0300, Alceu Rodrigues de Freitas Junior wrote: >> We've work underway on a python based testing suite for the future. > > That's great! > > Is this project available for the general public? I would like to take a > look to it and see if I can contribute. A first draft is available in tests/python in the master branch, work is needed to expand the infrastructure and eventually port the existing tests to Python (with a fallback to the existing scripts if requested or where Python tests can't be run). Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: no accesslog record on "delete" sync state control
On Mon, Sep 12, 2022 at 11:55:06PM +0300, Zeus Panchenko wrote: > hi > > I face a weird situation with my LDAP syncrepl consumer [1], > > please advise ... > > on "delete" sync state control receiving, I'm trying to search for > accesslog object with the just deleted object to use it in further > processing, but it is not available yet > > though if I set delay (sleep) for 1 sec just before the search, then I > successfully receive the object Hi Zeus, are you sure you are contacting the same server? If configured, the accesslog entry gets committed during write processing, so you shouldn't be able to detect any delay at all. Also looking at the code, I think you're a little confused. The server isn't sending LDAP_SYNC_DELETE for attribute deletion as you believe but because the entry doesn't match your search anymore (maybe it was deleted, moved away from the scope, no longer matches the filter or ACLs now hide it from your view). Also if you're interested in accesslog, you might want to switch to syncrepl on the log db instead. I suppose you'll try to remember the cookie eventually so you can resume. Then it's also worth keeping in mind that in OpenLDAP's implementation you cannot treat the cookie as opaque string when doing refreshAndPersist in multiprovider environments, merging the ones you receive in persist mode, rather than discarding the old one every time you've received a new. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: slapo-variant and searching virtual attrs
On Mon, Aug 22, 2022 at 02:07:25PM +0200, Michael Ströder wrote: > HI! > > I have the need to search a whole sub-tree for something like collective > attributes which AFAIK slapo-collect does not support. > > Now I'm wondering whether it's possible to search for the virtual attributes > generated by slapo-variant. And probably I'd like to use the regex variant. > > I've read the section LIMITATIONS in slapo-variant(5) which says that regex > variants only support reading the virtual attributes with scope base. It > also implies that searching for these virtual attributes is not possible at > all. > > Is that correct? Hi Michael, that's correct, if we can't identify potential candidates upfront, we would have to read the whole DB and do it ourselves. Pretty sure that's the very reason slapo-collect has the same limitations. As is usual with LDAP, the server isn't set up to correlate random data in a single search, you'll have to run the intermediate searches and synthesize things yourself. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Antw: [EXT] How to relay read and write requests to different ldap servers
On Wed, Jun 22, 2022 at 08:29:05AM -0700, Quanah Gibson-Mount wrote: >> Ignoring the loadbalancer issues, I think you add a race condition when >> reading possibly older data from your consumers and maybe write them back >> where newer data may exist already (i.e.: providers). BTW: Is a modify >> operation a read, or is it a write? > > modify ops are always a write operation, since they are doing a > modification. > > And yes, read-after-write can be a tricky issue to handle. In "load-balanced" setups, I usually suggest that people maintain two separate endpoints, one for clients that only ever issue reads and the other one for clients that might issue a write operation (potentially mixed in with read traffic). Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: logsuccess FALSE vs. replica contextCSN
On Thu, Jun 16, 2022 at 03:52:32PM +0200, Geert Hendrickx wrote: > On Thu, Jun 16, 2022 at 15:20:39 +0200, Ondřej Kuzník wrote: >> Yes, exactly. The accesslog is a DB like any other and you've chosen to >> add the entries that need an entryCSN of their own. Don't see a way out >> of that? On a pure replica it's just not involved in replication, on a >> provider, the accesslog shouldn't stay ahead for long? The NEW_COOKIE >> message should loop back to it AFAIK, but would need to test that. > > No, I'm speaking of the ContextCSN of the *main DIT*, not of the accesslog. > A no-op like deleting a non-existing object updates the ContextCSN of the > main db on the replica's but not on the provider. We monitor (the diff > between) the contextCSN's so it's indicates the provider is "behind" the > consumers here. I have tried reproducing this and the only DB that has contextCSN changes is the accesslog DB, the main DB stays intact. Please provide an example setup with 2.6 or master where you're seeing the above behaviour. Are you sure it's not something like ppolicy that makes changes to the local DB instead? Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: logsuccess FALSE vs. replica contextCSN
On Thu, Jun 16, 2022 at 03:03:53PM +0200, Geert Hendrickx wrote: > Yes, we see the replica's get an updated contextCSN with SID from the > provider, only the provider itself makes no change to its contextCSN and > stays with the old one, ie. the consumers appear to be ahead of this > provider. So for me, the behaviour of 2.6 and master is still the same as > 2.4/2.5. > > Regarding your fix, you mean the replica (*each* replica?) will increase > the contextCSN for its own SID for this operation? That seems strange to > me, for a failed/refused update on another provider, I would expect no > change at all on the replica's (and esp. the contextCSN associated with > their SID's to never change as long as they receive no updates directly). Yes, exactly. The accesslog is a DB like any other and you've chosen to add the entries that need an entryCSN of their own. Don't see a way out of that? On a pure replica it's just not involved in replication, on a provider, the accesslog shouldn't stay ahead for long? The NEW_COOKIE message should loop back to it AFAIK, but would need to test that. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: logsuccess FALSE vs. replica contextCSN
On Thu, Jun 16, 2022 at 01:29:55PM +0200, Geert Hendrickx wrote: > On Thu, Jun 16, 2022 at 12:42:46 +0200, Ondřej Kuzník wrote: >> this sounds a lot like ITS#9641. Could you also check 2.6? > > Thanks Ondřej, yes that ITS describes the same issue. > I can still reproduce it with 2.6.2 as well as master. Hi Geert, you mean the CSN recorded (a.k.a. "entryCSN:", not "reqMod: entryCSN:=") for these failed ops is still the original one rather than a new local SID? That would mean the ITS#9641 fix is not working and if that's the case, can you provide a test set up that reproduces this? Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: logsuccess FALSE vs. replica contextCSN
On Thu, Jun 16, 2022 at 12:28:27PM +0200, Geert Hendrickx wrote: > And thus update the contextCSN of their root DN (despite no other changes > to the main db) - their contextCSN is now different than the provider's. > > This obviously only happens with "logsuccess FALSE", but even in that case > this should not be expected behaviour; refused updates should not change > anything except getting logged to the accesslog? > > This is with OpenLDAP 2.5.12 (migrating from 2.4.x) Hi Geert, this sounds a lot like ITS#9641. Could you also check 2.6? Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Official way to import schema with cn=config
On Tue, Apr 05, 2022 at 05:01:44PM +0200, Michael Ströder wrote: > On 4/5/22 08:10, David Timber wrote: >> I know how to import schemas with cn=config. That was never a question. >> I was just complaining because it's a tedious process and I believe that >> it shouldn't be like this. > > I also think that cn=config should not be so complicated. And I've looked > into supporting this schema in web2ldap. Hi Michael, are you also talking about schema or something else here? So far this thread hasn't shown much that's complicated about the schema. True, we haven't touched on operational attributes and other parts of the schema compiled into slapd/loadable modules but my guess that's not what you're talking about either since they are no different from slapd.conf. > For now I'm just happy that static slapd.conf is still supported. It's still > the most DevOps-friendly way to configure OpenLDAP. We're not the outliers here, every major DB engine does the same thing. PostgreSQL and MySQL/MariaDB don't have an option to have a plain text file driving large parts of their configuration at all. How come people cope with that just fine and they can't do the same with OpenLDAP? Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Official way to import schema with cn=config
On Tue, Apr 05, 2022 at 02:10:37PM +0800, David Timber wrote: > I know how to import schemas with cn=config. That was never a question. I > was just complaining because it's a tedious process and I believe that it > shouldn't be like this. The whole cn=config matter was not even my question > in the first place. My concern was that I'm not happy with how cn=config > handles schemas and I want to stick with "deprecated" slapd.conf. slaptest > has to be used to convert schema to ldif, which is in no way intuitive and > convenient. Hi David, you're right, it doesn't have to be like this, and it's quite trivial to bypass slaptest as I showed earlier. The contents of the schema are the same they just have to be encapsulated in attributes and an LDAP entry. > On 5/4/22 12:27, Quanah Gibson-Mount wrote: >> And you're literally missing the point that a ".schema" file is a syntax >> specific to slapd.conf and a ".ldif" file is a syntax specific to >> cn=config. Just as you cannot load a ".schema" file into cn=config, you >> cannot load a ".ldif" file into slapd.conf. The two things are >> *equivalent* representations for their respective configuration types. >> In the future, expect only ".ldif" files to get shipped once we finalize >> deprecating slapd.conf. > > The format of schema is defined in RFC 4512. It's universal. OpenLDAP has no > right to be difficult in incorporating schemas. Forcing users to convert it > to ldif to just fit into the OpenLDAP specific cn=config format is not just > fair, especially for the sake of compatibility. I'd have been happy if I > could just use include: attribute to load .schema. Again, the contents of e.g. attributetype and olcAttributeTypes: are identical, both using the same RFC 4512 format as you rightly referenced. You probably want to explain again where you are coming from as I see no issue here. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Official way to import schema with cn=config
On Mon, Apr 04, 2022 at 11:24:36PM +0800, David Timber wrote: > This is all I can find. I'm not doing that. Are you saying I can just use > ldapadd? Care to elaborate? If you have a slapd.conf style file you have to convert it first, but it's not rocket science, this is a simple filter I came up with after 5 minutes and it seems to process all the schema files in OpenLDAP sources just fine (YMMV): sed -e 's/^\t\+/ /' | \ perl -p0e 's/\n //g' | \ sed \ -e "1i\cn=$name,cn=schema,cn=config\nobjectClass: olcSchemaConfig\ncn: $name" \ -e '/^#.*//' \ -e '/^[\s]*$/d' \ -e 's/^attributetype\s\+/olcAttributeTypes: /i' \ -e 's/^objectclass\s\+/olcObjectClasses: /i' \ -e 's/^ditcontentrule\s\+/olcDitContentRules: /i' \ -e 's/^ldap-syntax\s\+/olcLdapSyntaxes: /i' \ -e 's/^objectidentifier\s\+/olcObjectIdentifier: /i' Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Antw: [EXT] Re: RE26 testing call #1 (OpenLDAP 2.6.2)
On Fri, Apr 01, 2022 at 11:03:43AM +0200, Ulrich Windl wrote: >> On Wed, Mar 23, 2022 at 03:07:25PM +0100, Michael Ströder wrote: >>> Do you have any particular things in mind that need more thorough testing >>> before 2.6.2 is released? >> >> It was a general question. While it's nice that people run "make test" and >> sometimes "make its", it would be even nicer if we got regular feedback >> from actual test environments. If we got people to publish any metrics >> they gather (performance or otherwise), we could even track the >> evolution of the software in a real world setting, I know I'm not asking >> for much ;) > > Maybe maintain an OVL for each release, where "OVL" means "Operating System > Verification List" ;-) > (The list of Operating System Releases where compilation and selftest > succeeded) I don't think that's too helpful, since getting people to run OpenLDAP's own self-tests has never been a problem in my view. It's running the software with a real-world configuration that never seems to get reported. I know Shawn runs a few replication scenarios regularly. It would be nice to know if we could get others to consider running the release candidates in their own test or staging systems and what were the perceived issues to getting that going. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: RE26 testing call #1 (OpenLDAP 2.6.2)
On Wed, Mar 23, 2022 at 03:07:25PM +0100, Michael Ströder wrote: > On 3/23/22 12:19, Ondřej Kuzník wrote: >> On Tue, Mar 22, 2022 at 08:03:35PM +0100, Michael Ströder wrote: >> > On 3/22/22 18:21, Quanah Gibson-Mount wrote: >> > > This is the first testing call for OpenLDAP 2.6.2. >> > >> > Tested git revision 475e57281bc10e56a47021895a7b926e29ac9072 on openSUSE >> > Tumbleweed x64_64 (gcc version 11.2.1): >> > >> > - make test worked >> > - unit tests of my Python module ldap0 work >> Just a thought, are people pushing the RC code into testing/pre-prod >> environments? > > Sometimes I do on my openSUSE-based Æ-DIR test systems based on branches of > my packages in OBS. But it's additional work for which I don't always have > spare time left. Hi Michael, thanks, even that's appreciated. > Do you have any particular things in mind that need more thorough testing > before 2.6.2 is released? It was a general question. While it's nice that people run "make test" and sometimes "make its", it would be even nicer if we got regular feedback from actual test environments. If we got people to publish any metrics they gather (performance or otherwise), we could even track the evolution of the software in a real world setting, I know I'm not asking for much ;) >> Does the current schedule of 1+ weeks between a testing >> call and potential release give you enough time? > > IMHO most people are not going to test in real environments before the > OpenLDAP project cuts a release, no matter how long this testing period is. That has been a hypothesis for a while and this is an attempt to challenge it, just in case :) Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Response Ordering
On Fri, Mar 25, 2022 at 06:25:23PM +0100, Michael Ströder wrote: > Or you're verifying the password hash and password policy yourself. This > would require that the LDAP client has read access to password hashes. > > Or in case the server is a recent OpenLDAP slapd then you might want to look > into using the Verify Credentials extended operation. AFAIK you don't even need to do that, the behera ppolicy draft suggests[0] Compares should be processed in a very similar way without destroying connection state and ppolicy implements that. Not sure about the ACL requirements but that should be easy to figure out. [0]. https://datatracker.ietf.org/doc/html/draft-behera-ldap-password-policy-11#section-9.4 -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: RE26 testing call #1 (OpenLDAP 2.6.2)
On Tue, Mar 22, 2022 at 08:03:35PM +0100, Michael Ströder wrote: > On 3/22/22 18:21, Quanah Gibson-Mount wrote: >> This is the first testing call for OpenLDAP 2.6.2. > > Tested git revision 475e57281bc10e56a47021895a7b926e29ac9072 on openSUSE > Tumbleweed x64_64 (gcc version 11.2.1): > > - make test worked > - unit tests of my Python module ldap0 work Just a thought, are people pushing the RC code into testing/pre-prod environments? If so, would you be willing to share your results (pass/pass with concerns/fail, any relevant metrics you think might be of interest). Does the current schedule of 1+ weeks between a testing call and potential release give you enough time? Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: olcLastBind default to true
On Fri, Mar 11, 2022 at 02:19:44PM +0100, Erik de Waard wrote: > Hi, i've a weird case where olcLastBind defaults to TRUE. > When using convert (slaptest) method. > and explicit lastbind to off/false has no effect. Hi Erik, thanks for the report, I've filed ITS#9808[0] for this. [0]. https://bugs.openldap.org/show_bug.cgi?id=9808 -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: syncprov-sessionlog-source cn=accesslog
On Fri, Mar 11, 2022 at 10:47:53AM -0800, Quanah Gibson-Mount wrote: > --On Friday, March 11, 2022 12:25 PM +0100 Ondřej Kuzník > wrote: >> If you configure syncprov-sessionlog-source, adding syncprov-sessionlog >> to the mix will do nothing except eat memory, as the manpage and the >> logs will happily point out. If you're using plain syncrepl, you have a >> choice to store and use accesslog or stay the traditional sessionlog, >> both work fine but sure, there are tradeoffs. Since AFAIK anything >> persisted needs to be an LDAP entry, the silver bullet just isn't >> available. > > The issue is that to use the disk based sessionlog, you also have to set up > a full delta-based accesslog. If one could simply store only the necessary > data for the sessionlog in the accesslog DB and skip the other ops then it > would be a fine solution. As previously mentioned, it has to be an actual LDAP database, so the only way we could improve on this situation is by not storing reqMod: values. Everything else is either needed to make it a valid LDAP entry or necessary to support sessionlog. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: syncprov-sessionlog-source cn=accesslog
On Thu, Mar 10, 2022 at 12:30:49PM -0800, Quanah Gibson-Mount wrote: > --On Thursday, March 10, 2022 7:53 PM +0100 Michael Ströder > wrote: >> I wonder what the operational requirements are when using >> syncprov-sessionlog-source cn=accesslog >> instead of the in-memory session log. >> >> E.g. what about configured logpurge? You should set logpurge to however long you want your replicas to stay out of contact with the provider. This is much more predictable than the in-memory sessionlog which has no guarantees about how long a CSN stays in there and can expire CSNs in an unexpected order. >> What happens if the accesslog DB is completely deleted? > > You lose the sessionlog. This is a significant flaw in the current design > and is not what I was expecting when the need to implement a persistent > sessionlog was identified. If you completely drop the accesslog DB (which means you probably restarted), you're no worse than a restart with a traditional sessionlog - things fall back into a full present phase if a consumer wasn't up to date already. If you mess with the DB contents, you're on your own just like in deltasync. > Depending on the way in which the accesslog is > configured, storing the sessionlog in it can be worse than the in-memory > scenario. That's why it's not a default, but from my point of view, the predictability you get with logpurge being time-based is much more appealing. > Additionally, it's not particularly useful/compatible with standard syncrepl > since you have to fully implement storing delta's in the accesslog as well > as the sessionlog for it to function, at which point you may as well just > use delta-syncrepl instead of standard syncrepl. If you configure syncprov-sessionlog-source, adding syncprov-sessionlog to the mix will do nothing except eat memory, as the manpage and the logs will happily point out. If you're using plain syncrepl, you have a choice to store and use accesslog or stay the traditional sessionlog, both work fine but sure, there are tradeoffs. Since AFAIK anything persisted needs to be an LDAP entry, the silver bullet just isn't available. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: syncprov olcSpNoPresent not being honoured
On Thu, Mar 10, 2022 at 09:48:40AM +, Lisa Parratt wrote: > Hi Ondřej, > > My understanding was a sessionlog was required to record delete > events, to efficiently generate a Delete phase? The server has been > configured with `olcSpSessionlog: 1` since long before I inherited > it, and the consumer seems to be processing the transmitted Delete > phase as expected. Hi Lisa, it is required for that, but the fact your sessionlog isn't enough means you had already been missing deletes and setting olcSpNoPresent just hid that from view. It could be argued that olcSpNoPresent and sessionlog are mutually exclusive and we should reject that (or at least warn about it being very suspicious), feel free to open an issue for this. You might want to use olcSpSessionlogSource instead instead of the in-memory implementation to make sure you don't get in this situation even after a server restart. Maybe also keep olcSpNoPresent: FALSE to alert you when you'd be losing information already and need to handle that manually. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: syncprov olcSpNoPresent not being honoured
On Wed, Mar 09, 2022 at 04:42:17PM +, Lisa Parratt wrote: > Hi Ondřej, > > A byzantine java application connects to the LDAP server, and somehow > uses the information presented to trigger API requests to business > logic, eventually resulting in the data being replicated to a > relational database. If olcSpNoPresent is honoured, this works. It > it’s ignored, it dies with an error. I have, as yet, been unable to > find an engineer who can explain this behaviour to me, and this code > is largely forgotten. > > It seems reasonable to me that if I configure slapd to not do a > Present phase, then it shouldn’t do a Present phase? Am I wrong? The question was, is there a reason why you also configure a sessionlog when to me it seems you're saying you'd be perfectly happy without (ignoring any deletes)? -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: syncprov olcSpNoPresent not being honoured
On Wed, Mar 09, 2022 at 09:04:49AM +, Lisa Parratt wrote: > Hi Quanah, > > It’s not a replication setup. The consumer is a relatively ancient > proprietary implementation of the syncrepl protocol, over which I have > very influence. > > I believe the problem is syncprov.c lines 3335 and 3341, which appear > to be setting `do_present = SS_PRESENT;` while simultaneously ignoring > the value of si->si_nopres. Replacing the lines above with `if ( > !si->si_nopres ) do_present = SS_PRESENT;` appears to fix the problem > for my use case, and is closer to how the logic worked in previous > versions of slapd. Hi Lisa, I find it strange that you maintain a sessionlog (or use accesslog to host it) yet don't want to host a present/delete phase which is where they are useful. Could you explain what you're trying to achieve with your set up? -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: slow memberOf queries in 2.5 with dynlist overlay
On Mon, Feb 14, 2022 at 06:01:43PM -0800, Paul B. Henson wrote: > On Mon, Feb 14, 2022 at 09:57:06AM -0800, Quanah Gibson-Mount wrote: > >> How large is the total size of all mdb databases? > > [...] > So a total of a bit over 2GB. > >> How much RAM do you have on the system? > > 2GB. I don't think I'm running low on memory, there's usually a bit > free: > > # free -m > totalusedfree shared buff/cache > available > Mem: 1949 423 79 01446 > 1372 > Swap: 1023 291 732 > > And when it's being really slow for memberOf there's no swapping or other > signs of low memory. Other queries are still very responsive, it's just > memberOf that gets slow. The only metric that seems ramped when it occurs > is high read IO. So think about it: - your DB is just over the size of available RAM by itself - after a while using the system, other processes (and slapd) will carve out a fair amount of it that the system will be unwilling/unable to page out - if, to answer that query, you need to crawl a large part of the DB, the OS will have to page that part into memory, at the beginning, there is enough RAM to do it all just once, later, you've reached a threshold and it needs to page bits in and then drop them again to fetch others you develop these symptoms - lots or read I/O and a delay in processing Figure out what is involved in that search and see if you can tweak it so it doesn't need to crawl the whole DB or make sure you always have enough RAM to page the whole DB in, even when the other processes have been running for a bit. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Need to define behaviour when storing pwdChangedTime
On Wed, Jan 12, 2022 at 05:28:32PM +0100, Michael Ströder wrote: > On 1/12/22 10:35, David Coutadeur wrote: >> I suppose an admin changing the pwdChangedTime of an entry with the >> relax rule is a valid use case. > > This is IMO indeed a tricky one: > > I find arguments for the current behaviour but also for accepting submitted > pwdChangedTime value in case relax rules control is used. Modify requests seem to support this, gating it on ACL (password administrator role) + Relax control. > One could argue that the distinction between the two use-cases > > "admin restores userPassword/pwdChangedTime" > > and > > "admin sets new userPassword" > > can be deferred to ACL validation. The admin must have manage privilege on > pwdChangedTime for the restore to succeed. Those two would be distinguished by providing the new pwdChangedTime value in the Add? >From that perspective it might make sense to support this in Adds as we do in Modifies. Haven't thought about it too much yet. If you achieve consensus that the existing situation should change, please file an ITS addressing the above concerns and argue what Behera the draft intended. AFAIK you should already be able to add the user and then set userPassword+pwdChangedTime if you have the rights. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: 2.6 rhel8 rpm pkg - lastbind module issue
On Wed, Dec 01, 2021 at 10:06:11AM -0500, Dave Macias wrote: > slapadd -n 1 -F /opt/symas/etc/openldap/slapd.d -l data.ldif > <= str2entry: str2ad(authTimestamp): attribute type undefined > slapadd: could not parse entry (line=24) > Closing DB... Hi Dave, the functionality in core uses behera-ppolicy's pwdLastSuccess attribute instead. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: symas gpg-key
On Tue, Nov 30, 2021 at 03:08:29PM +0100, Stefan Kania wrote: > I installed the symas OpenLDAP 2.6. The first step was getting the > gpg-key but the command on your web-page is : > > root@ldap:~# apt-key adv --keyserver keyserver.ubuntu.com --recv-keys > DA26A148887DCBEB > Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d > instead (see apt-key(8)). > > is deprecated on debian 11. Do you provide a the key in .asc format so > the key can be installed via: > > wget -O- https://some-server.com/symas.gpg-key.asc | gpg --dearmor | tee > /etc/apt/trusted.gpg.d/symas.gpg > /dev/null > > > If you do, where can I find it? If not, could you provide it? :-) Hi Stefan, if you don't want to get it from the keyservers, it's also kept here: https://repo.symas.com/repo/gpg/RPM-GPG-KEY-symas-com-signing-key Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Logfile timestamp in 2.6
On Sat, Oct 16, 2021 at 04:11:25PM +0200, A. Schulze wrote: > Am 16.10.21 um 00:06 schrieb Nick Folino: >> Thanks, Howard. That's basically what I'm doing now. Just checking >> to see if there was an option I was missing. > > Hello, > > just an idea: maybe a similar function could be added to slapd itself. > One clean & reasonable fast implementation take the burden of > inventing that wheel again and again from many users. A new config > options would allow to enable convenient timestamp logging. Hi, OpenLDAP is still capable of logging to syslog and that formats timestamps in a way that suits causal needs (and is generally configurable). The dedicated logfile option is there for sites where syslog is not appropriate as it has proven to be a significant performance bottleneck even with logging set to "stats" only. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: 2.5.7 - bind err=49 after a userPassword and pwdChangedTime update
On Fri, Oct 08, 2021 at 09:35:31AM -0400, Dave Macias wrote: > Hello, > > Happy Friday! > > I have a script that defaults the password to the user's username and then > it sets the pwdChangedTime so far back that pwdMaxAge: 62208000 triggers. > > In 2.5.7 before I change the pwdChangedTime i MUST do a simple bind with > dn/password before I can apply the new pwdChangedTime. I say in 2.5.7 bc in > 2.4.59 i dont see this behavior. > > So my flow goes as follows: > > ldappasswd > ldapmodify (pwdChangedTime: 20191008133434Z) > ssh with new > > Oct 8 09:17:06 localhost slapd[1380194]: conn=1199 op=2 BIND > dn="uid=davetest,ou=People,dc=domain,dc=net" method=128 > Oct 8 09:17:06 localhost slapd[1380194]: conn=1199 op=2 RESULT tag=97 > err=49 qtime=0.26 etime=0.000262 text= Hi Dave, I'm not sure which is the operation that fails? Who are you binding as, if "uid=davetest,ou=People,dc=domain,dc=net", why should the user have write access to its own pwdChangedTime? > Flow i have to do so that bind works: Again, not sure from the logs what that corresponds to (there is no MODify operation logged, etc.). Also what are you actually trying to achieve? Is it to force the user to change their password? Shouldn't you just rely on the pwdReset attribute then? Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Is there significance in overlay order in replicated environment
On Tue, Sep 21, 2021 at 02:23:35PM +0200, Saša-Stjepan Bakša wrote: >> Also, in latest 2.5.7* olcLastBindPrecision* is not among list of >> possible attributes for mdb. I Have searched for it also but only >> olcLastBind is inherited from olcDatabaseConfig. >> >>*olcLastBindPrecision: * >> If olcLastBind is enabled, a new value is written only if >> the current one is more than *number *seconds in the past. > > But part of not finding *olcLastBindPrecision* still stands. This functionality is only implemented in the upcoming 2.6 release, it's not available in 2.5. If you have relied on this in your existing environment, you will need to keep using the lastbind overlay until then. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: How to create an entry, which is not returned on SEARCH
On Mon, Sep 13, 2021 at 01:33:50PM +0300, Дилян Палаузов wrote: > Hello, > > How can I create an entry (in terms of ldif/ldapadd/ldapmodify), which > is not returned on searches (apart from tweaking the olcAccess rules? > > [...] > > Rationale: I want to create a directory, containing contacts under: > > cn=juridical persons,dc=me > cn=natural persons,dc=me > > The LDAP clients shall query base dc=me with scope SUB. The LDAP > clients shall see all subentries of Juridical Persons and all > subentries of Natural Persons, but not the cn=juridical persons,dc=me > cn=natural persons,dc=me and dc=me entries itself. As the latter > entries do not represent Contacts (mail, phone, address), the entries > shall not appear in address books. Hi, if you care that the clients just can't see them or some data in there, whatever they do, you need to set ACLs. Otherwise just have the clients send a suitable filter, based on your description, you should be able to match on objectclass at the very least. Worst case, matching on entryDN (like the example given in slapcat's manpage) or using the ":dn:" flag might help if you wanted to filter out certain subtrees. Regards, Ondrej
Re: OpenLDAP 2.6.0 testing call
On Wed, Sep 08, 2021 at 06:07:41PM +0200, Michael Ströder wrote: > It would probably cause some confusion down-stream if OpenLDAP 2.6 > installs a file libldap-2.5. I'm really not keen on that mess. There would be one final transition from libldap-2.6.so.x to libldap.so.x, not embedding the version in the library name anymore and just using library versioning. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: OpenLDAP 2.6.0 testing call
On Wed, Sep 08, 2021 at 03:37:23PM +0200, Michael Ströder wrote: >> The most significant difference for slapd is the ability to bypass >> syslog for logging. > Does that really justify a version bump of libldap which in turn causes > more effort for downstream packagers? Don't think we've broken ABI compatibility in this release, so we shouldn't be bumping the soname, are we doing that? Quanah? -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Checking synchronization status into cn=monitor in OpenLDAP 2.5
On Wed, Sep 08, 2021 at 11:30:57AM +0200, David Coutadeur wrote: > Hi, > > I am trying to get the synchronization status of a given consumer for each > of his declared provider. > > Synchronization status = Is this provider synchronized with the current > consumer? (TRUE / FALSE) > > Currently, I can do that by comparing contextCSN stored into consumers and > providers. > > I have noted that in OpenLDAP 2.5 there are new piece of information into > cn=monitor: > 1/ I haven't found any documentation about these attributes in OpenLDAP > manual. Is there something in progress ? There is no documentation on any of this yet. Feel free to write something up for the admin guide, perhaps? > 2/ if I understand correctly the meaning of olmSRLastCookieRcvd, it should > be the best candidate for computing the synchronization status. However, > this attribut is empty at OpenLDAP startup, so I can't really rely on it. Do > anyone see other means to get the synchronization status? I guess you could go that way, my approach[1] is to observe the cookies directly (via syncrepl) where that of Howard's slapd-watcher[2] is to read the contextCSN from the DB/syncprov. As I usually mention in similar discussions, be wary of interpreting short-lived large differences between CSNs as long replication delays, you would emit many false positives. [1]. https://git.openldap.org/openldap/syncmonitor [2]. https://git.openldap.org/openldap/openldap/-/blob/master/tests/progs/slapd-watcher.c Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: OpenLDAP 2.6.0 testing call
On Tue, Sep 07, 2021 at 11:02:30AM -0700, Quanah Gibson-Mount wrote: > --On Tuesday, September 7, 2021 8:57 PM +0200 Michael Ströder > wrote: >> But what are the main differences compared to 2.5.7? > > I literally noted this in the testing call. The most significant difference > for slapd is the ability to bypass syslog for logging. You can also check the upgrade documentation in progress, tracked here: https://bugs.openldap.org/show_bug.cgi?id=9666 -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: OpenLDAP 2.5 Release Candidate Testing (OpenLDAP 2.5.4)
On Fri, Apr 23, 2021 at 10:44:35AM +0200, Dieter Klünter wrote: > There is a broken symlink in tests/testdata/homedir/skel/directory/ > which points to it self. Which is part of the test, the problem was an copy-paste error at the beginning of the script that should have noticed the overlay was not available. That's fixed now in master (commit defa618405) and will be part of 2.5.4 when Quanah gets a chance to include it. Thanks for testing things and if you get a chance to test with the fix and further, much appreciated. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: openSUSE and SLE packages of OpenLDAP 2.5.3beta available
On Thu, Apr 01, 2021 at 02:06:00PM +0200, Michael Ströder wrote: > On 4/1/21 6:17 AM, proj...@openldap.org wrote: >> OpenLDAP 2.5.3beta is now available for experimentation and testing. > > Danger area: openldap2 (You have been warned!) > > home:stroeder:openldap25/openldap2 is a *replacement* for the > OS-provided packages which replaces system-wide client libraries. > *This will likely break your system*! > If you know what you're doing you can install this into e.g. test VMs, > container or similar throw-away deployments. Thanks for providing this. I thought we changed the soname (+provided symbol versioning) so that the libraries can be co-installed safely and hopefully even loaded into a process that has loaded a 2.4 libldap already? -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: difference in multi-master replication since 2.4.57
On Thu, Mar 04, 2021 at 01:09:55PM +0100, Michael Ströder wrote: > On 3/4/21 12:20 PM, Ondřej Kuzník wrote: >> If it takes 1 second to replicate a change and a previous change >> happened x seconds before this one there's going to be a window of 1 >> second where you see an x second CSN difference between the provider and >> consumer. In no way does it mean the consumer is x seconds behind. > > I'm talking about the contextCSN difference being visible for several > *hours* while the changes have been already successfully replicated. > Replication delay is very short, syncrepl type is refreshAndPersist. Don't think I've ever seen this outside slapcat (only checkpoints affect the on-disk version). Please submit a bug if you can replicate this. >> If there's an acceptable delay of n seconds, you better wait for that >> amount of time before raising an alarm, > > And what's an appropriate value for n? 86400? ;-] Depends where in the galaxy you place your replicas :) >> See the logic in syncmonitor[0] > > Ideally I'd like to query cn=monitor whether slapd thinks replication is > in a healthy state. Consumer will never think its replication is slow/broken (unless it gets an actual error and you can already see that in cn=monitor). Provider might want to expose some information but that's not implemented yet and will not be able to spot many issues if other providers exist. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: difference in multi-master replication since 2.4.57
On Wed, Mar 03, 2021 at 09:52:26PM +0100, Michael Ströder wrote: >> --On Wednesday, March 3, 2021 6:24 PM +0100 Emmanuel Seyman >> wrote: >> >>> The problem is that I don't see any messages in the log that stand >>> out as being errors (granted, I'm not sure what I'm looking for). >>> In fact, the alert flaps every once in a while as the two nodes >>> come back in sync and drift away from each other again. >>> >>> I find these values surprising considering I've never seen a syncrepl >>> error in the 2 years before the upgrade. Is there a known issue with >>> replication in 2.4.57 that would explain these sync differences? > > My slapdcheck package [1] also implements exactly this check and > sometimes it shows a difference although the changes have been corrected > replicated (normal syncrepl). > > You can look at the code to verify what it's doing: > > https://gitlab.com/ae-dir/slapdcheck/-/blob/master/slapdcheck/__init__.py#L1070 > > (It reads the actual syncrepl providers from cn=config before comparing > the contextCSN values for each serverID.) > > I discussed this several times with Howard and Ondrej but no idea came > up why that happens. I don't remember the discussion anymore but there's a corner case people writing syncrepl checking scripts often forget to address: If it takes 1 second to replicate a change and a previous change happened x seconds before this one there's going to be a window of 1 second where you see an x second CSN difference between the provider and consumer. In no way does it mean the consumer is x seconds behind. If there's an acceptable delay of n seconds, you better wait for that amount of time before raising an alarm, either on the script level or monitoring infrastructure level. See the logic in syncmonitor[0] for an example of a live monitoring tool that should implement this, wrapping the code in a nagios check compatible tool is pending, patches welcome. [0]. https://git.openldap.org/openldap/syncmonitor/-/blob/master/syncmonitor/environment.py#L77 -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Syncprov shows issue with entry
On Sat, Jan 23, 2021 at 12:57:37AM +0200, Nick Milas wrote: > On 18/1/2021 6:27 μ.μ., Quanah Gibson-Mount wrote: > > > Nothing in the log snippet provided shows an issue. What leads you to > > believe an issue has been encountered? > > Hi Quanah, > > Thanks for the reply, > > I can't tell whether it was an issue or not (for example, I could call it a > phenomenon), but I found it strange to have this repeating for weeks every > three minutes and always on that single entry (among thousands). > > I am trying to figure out what does the log snippet mean. I would guess it > means that the particular entry at the master DIT is found to be older than > the one at the slave? Something writes to your consumer, if you have a MMR environment, you want to assign different serverids. Otherwise you want to figure out how the change happened and either fix the offending service or set up chaining on consumers. > If so, I wonder how this may have happened! Maybe due to a DIT change that > took place at some point in time when the master clock was a bit slower than > the slave? (Although both are running ntp service.) > > And - in any case - what would be the recommended way to stop this from > occurring constantly? Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Bind to OpenLDAP with a user not in DN format
On Thu, Jan 14, 2021 at 10:27:35PM -, gary.alg...@mavenir.com wrote: > Hello, > > I need to bind sometimes with a username that is not in DN format. I > have tried to use authz-regexp to translate it but I am not > successful. OpenLDAP will try and normalise the incoming DN and an email-like string is never a valid dn, so there's no way around that. How limited are your clients? Can they accept a DN to use? Each user in AD still has a relevant entry, so you can use their DN if you can find it. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: LMDB: iterating over the whole DB
On Thu, Aug 20, 2020 at 07:42:06PM +0200, Vladimír Čunát wrote: > Right, thanks, I did miss the title page when re-reading. > > It's a bit confusing that the paragraph after that sentence does not > appear to apply to the observed case, but that's not really important... > from this discussion I see no other option than shortening the > transactions to some magical constant. > > (Pages touched in a RO transaction can't be freed until it aborts - that > was always clear. For us the overall number of pages don't seem > possible to have ran out, assuming the MDB_stat counts reflected their > usage before all those operations began.) I don't remember where to point you so in my own words... You do understand that no pages reachable by an open read transaction can ever be reclaimed. At the moment, AFAIK a stronger claim can be made about LMDB: For an open read transaction #n, it avoids reclaiming any pages freed by transactions #n upwards. Keeping a read transaction open indefinitely, at some point you are going to run out of pages to reclaim having to reach for fresh ones. Later, you might run out of those too. This is what you're seeing. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: syncrepl does not work as expected
On Mon, Jul 20, 2020 at 08:49:51AM +0200, Ulrich Windl wrote: > Quanah Gibson-Mount schrieb am 16.07.2020 um 17:01 in > Nachricht <33146DC712C0F6197C97C784@[192.168.0.156]>: >> I've referenced the underlying bug for years. ITS#8125. > > I read the bug, but it's not quite clear what the true reason is. for me I > got: modrdn operations, multi-valued attributes with more than one change per > second, possibly non-persistent sessionlog. This combination leads to > unreliable synchronization. The situation is when several providers try and do a complete resync with each other at the same time. That situation is not handled well. Usually you have several layers before that (deltasync, sessionlog, yet more stuff in 2.5) that are well tested. > And it seems the bug isn't fixed yet. No and there is no way to fix this in 2.4. We're aiming to fix this in 2.5 but aren't there yet. > Couldn't there be a warning at least saying something like "unsafe sync > configuration detected. Expüect inconsistent replica"? The problem only surfaces when two servers get into the same situation at the same time, hard to detect. With multiple providers, you want to use deltasync at this point. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: two slapd processes accessing one MDB env
On Fri, Jan 17, 2020 at 07:42:31PM +0100, Michael Ströder wrote: > I guess you mean conflicts when generating entryCSN values? Good point. It never hits the other server's overlay stack, so syncprov won't see the modification and won't forward it to any of its active consumers. Many other things in syncprov will break for the same reason. > The problem to be solved: > > If a back-sock listener configured as overlay also needs access to some > LDAP entries then I have a loop in the frontend LDAP thread pool. This > possibly blocks. So my plan was to setup a shadow slapd and access the > database via this (separate LDAP thread pool). > > In the simplest form there would only be read access. But OATH-LDAP's > HOTP validator would also need to update some attributes. Maybe use 'readonly on' on the database or send referrals towards the writable slapd. You then still have the HOTP validator send writes to the writable replica so you are back to the original problem if all worker threads are busy in slapo-sock already. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Question about OpenLDAP and rwm overlay
On Mon, Jan 13, 2020 at 10:20:07PM +, Vandenburgh, Steve Y wrote: > Michael, > > I know this thread is old, but wanted to follow up by asking: would it > be possible to delay the BIND DN syntax check until after rwm > manipulations are completed? Unfortunately, there is a lot of client > software that is dependent on this quirk but it would be very > beneficial to be able to use OpenLDAP as a proxy to AD. I suspect > that delaying the syntax check until after rwm manipulations would > allow UPN-based authentication to work. Hi Steve, DN validation for binds/search bases/... happens way too early in the frontend for this to be possible. Same reason why you can't write a slapd module to handle the magic '' AD DNs. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: two slapd processes accessing one MDB env
On Fri, Jan 17, 2020 at 11:07:01AM +0100, Ondřej Kuzník wrote: > On Thu, Jan 16, 2020 at 04:08:28PM +0100, Michael Ströder wrote: > > HI! > > > > I vaguely remember that it's possible that two slapd processes can > > access a single MDB env. > > > > Is that supported? > > Any pre-cautions needed? > > I think if you were to configure both of them as a syncrepl consumer, > that might cause some headaches? (reply to list this time) Also if either of them is a syncrepl provider, probably make sure that no other server is accepting writes to this db file, I can imagine (refreshAndPersist) scenarios that might leave you unhappy otherwise. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Openldap support SHA-256 or SHA-3.
On Wed, Jan 08, 2020 at 01:52:11PM +0100, "POISSON Frédéric" wrote: > Hello, > > Does this project > https://github.com/sonOfRa/openldap/tree/argon2/contrib/slapd-modules/passwd/argon2 > could respond or it is off topic ? This is being tracked in ITS#8575 and should be part of 2.5 release. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Dynamic ACL in OpenLDAP with set:expand not working
On Thu, Aug 22, 2019 at 09:10:24AM +0200, Martin W. wrote: > Hi Ondřej, > Hi Dieter, > > Thanks for your replies! The basic links I've had already found and > read through carefully and didn't find a correct solution for my > problem =( > > The olcAccess statements out of the trials were all placed in front of > the asterisk * one. So the order should not be the problem =( Hi Martin, there are several olcAccess clauses (olcAccess attribute values) with several directives each. > With slapacl I don’t really get a clue – I’ll attach one result below, > that I would interpret like that my l.dap user is not allowed to > change the description of entity e1 … but if I use JXplorer to connect > to the directory as l.dap, I can – even submit. Is it wrong how I’m > using slapacl? Or isn’t it reliable since I’m using RegEx? > >> $ slapacl -v -U "uid=l.dap,ou=people,dc=example,dc=com" -b >> "o=e1,ou=entities,dc=example,dc=com" -d acl "description/write" This is the relevant snippet from the output: >> authcDN: "uid=uid\3Dl.dap\2Cou\3Dpeople\2Cdc\3dexample\2Cdc\3Dcom,cn=auth" >> 5d5db13a => access_allowed: write access to >> "o=jpbay,ou=lve,dc=example,dc=com" "description" requested >> 5d5db13a => acl_get: [2] attr description >> 5d5db13a => acl_mask: access to entry "o=jpbay,ou=lve,dc=example,dc=com", >> attr "description" requested >> 5d5db13a => acl_mask: to all values by >> "uid=uid\3Dl.dap\2Cou\3Dpeople\2Cdc\3dexample\2Cdc\3Dcom,cn=auth", (=0) >> 5d5db13a <= check a_dn_pat: self >> 5d5db13a <= check a_dn_pat: cn=admin,dc=example,dc=com >> 5d5db13a <= check a_set_pat: >> [cn=ldapadmins,ou=groups,dc=example,dc=com]/member* & user >> 5d5db13a => mdb_entry_get: found entry: >> "cn=ldapadmins,ou=groups,dc=example,dc=com" >> 5d5db13a ACL set[0]=cn=globaladmins,ou=groups,dc=example,dc=com >> 5d5db13a => mdb_entry_get: found entry: >> "cn=globaladmins,ou=groups,dc=example,dc=com" >> 5d5db13a ACL set[0]=cn=globaladmins,ou=groups,dc=example,dc=com >> 5d5db13a ACL set[1]=cn=admin,dc=example,dc=com >> 5d5db13a ACL set[2]=uid=l.dap,ou=people,dc=example,dc=com >> 5d5db13a => mdb_entry_get: found entry: "cn=admin,dc=example,dc=com" >> 5d5db13a <= mdb_entry_get: failed to find attribute member >> 5d5db13a => mdb_entry_get: found entry: >> "uid=l.dap,ou=people,dc=example,dc=com" >> 5d5db13a <= mdb_entry_get: failed to find attribute member >> 5d5db13a ACL set: empty >> 5d5db13a <= check a_dn_pat: users >> 5d5db13a <= acl_mask: [4] applying read(=rscxd) (stop) >> 5d5db13a <= acl_mask: [4] mask: read(=rscxd) >> 5d5db13a => slap_access_allowed: write access denied by read(=rscxd) >> 5d5db13a => access_allowed: no more rules >> write access to description: DENIED Which seems to correspond to your first olcAccess clause only: >>>>> olcAccess: to * >>>>> by self write >>>>> by dn="cn=admin,dc=example,dc=com" write >>>>> by set="[cn=ldapadmins,ou=groups,dc=example,dc=com]/member* & >>>>> user" write >>>>> by users read >>>>> by * none It shows that "by users read" matches and processing stops. If you want processing to continue past this clause, you will either have to reorganise the structure and ordering of your rules or (to get you started for now) use "break" at the end of certain directives (most likely the last two: "by users read" and "by * none"). Hopefully with this and man slapd.access in mind, you should be able to find a way to describe what you need. With more complex ACLs, it is also useful to maintain a test suite using slapacl or sample DBs so you can refactor them with confidence later. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: Dynamic ACL in OpenLDAP with set:expand not working
On Tue, Aug 20, 2019 at 10:22:56PM +0200, Martin W. wrote: > Dear OpenLDAP technical list, > > I‘ve been running into a little problem with my permission structures > – and was wondering if you could help me with it. > > I want the members of a group to administer a tree structure, the > group is member of it. I've tried some acl settings – I'll post my > trials below the basic structure. > > I've tried some different things ... and none Regex was successful :( > Since I'll post some fragments, I put every LDIF fragment within such > a bash fragment: > >> olcAccess: to * >>by self write >>by dn="cn=admin,dc=example,dc=com" write >>by set="[cn=ldapadmins,ou=groups,dc=example,dc=com]/member* & >> user" write >>by users read >>by * none > > trial 1 > >> olcAccess: to dn.regex="([^,]+,)?o=([^,]+),ou=entities,dc=example,dc=com" >>by self write >>by dn="cn=admin,dc=example,dc=com" write >>by set="[cn=ldapadmins,ou=groups,dc=example,dc=com]/member* & >> user" write >>by >> set.expand="[cn=admin,o=$2,ou=entities,dc=example,dc=com]/member* & user" >> write >>by set="this/member* & user" read >>by * none > > The result is, that admin and any member of ldapadminscan edit, the > members of specific entity admin subgroups cannot edit. > The specific admin subgroups cannot even see the entities subtree. Hi Martin, what is the order of the above two olcAccess statements? If they apply in the order above, it seems the first one will always apply and processing will stop there. In that case you either want to add a "break" in the first one or split/move it to be checked later. I assume you also know and use the slapacl tool (and loglevel acl) to test with? Does it show any additional information that might be helpful in diagnosing the issue? Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
