openldap-technical February 2023

openldap-technical@openldap.org

26 participants
32 discussions

dynlist dont deliver memberof attribute
by Andreas Ladanyi 27 Feb '23

27 Feb '23

Hi, iam using one 2.5 Master / Provider / syncprov and some 2.5 Slaves / Consumers / syncrepl. I added the dynlist to generate memberOf attribute to slapd.conf on Master and all Slaves. Problem is only on some slaves the dynlist doesnt generate memberof attribute output when ldapsearch to a user. Iam using the objectClass labeledURIObject and attribute labeledURI to store the LDAP URI for dynlist to trigger / generate the DN of group membership for memberof attribute of the user. The labeledURI attribute is replicated successfully. User entry output on non working slaves with attribute labeledURI, memberof is missing: ldapsearch -x -LLL -ZZ -H ldap://non_working_slave -b 'ou=X,dc=department,dc=organization,dc=X,dc=X' '(&(uid=X))' results in the user entry with all objectClasses and all attributes except the memberof attribute. #start snip: ... objectClass: labeledURIObject ... labeledURI: ldap:///dc=department,dc=organization,dc=X,dc=X??sub?(&(objectClass=groupOfNames)(member=uid=XXXX,ou=account,ou=X,dc=department,dc=organization,dc=X,dc=X)) #stop snip slapd.conf: overlay dynlist dynlist-attrset labeledURIObject labeledURI memberOf The difference between working and non working slaves is the length of ACL list. The important ACL entry is: access to dn.sub=dc=department,dc=organization,dc=X,dc=X \ attrs=entry by peername=IP_subnet read by * break access to dn.regex=^[^,]+,ou=(account|group|groupOfNames),ou=X,dc=department,dc=organization,dc=X,dc=X$ by peername=IP_subnet read by * break i set no attrs= parameter at "access to dn.regex" rule to output all attributes. cheers, Andreas

1 1

ACL issue
by eric.innocente＠univ-avignon.fr 23 Feb '23

23 Feb '23

Hi, Using OpenLDAP 2.4 and this ACL : ===== olcAccess: {0}to * by dn="cn=admin,ou=ldap,dc=univ-avignon,dc=fr" write by * break olcAccess: {1}to attrs=userPassword by self write by anonymous auth by * none olcAccess: {2}to attrs=myAttribute by dn="cn=myUser,ou=ldap,dc=univ-avignon,dc=fr" read by * none olcAccess: {3}to * by * read ===== in the aim (rule {2}) to grant read access to attribute 'myAttribute' for myUser and no other user (except admin). As wanted, [R1] with authentified user myUser : [R1] ldapsearch -x -LLL -h <myLDAP> -b 'ou=people,dc=univ-avignon,dc=fr' -D 'cn=myUser,ou=ldap,dc=univ-avignon,dc=fr' -w <secret> "(uid=someUid)" myAttribute give me the dn and the required "myAttribute" : dn: uid=someUid,ou=people,dc=univ-avignon,dc=fr myAttribute: <attribute value> and [R2] with another authentified user : [R2] ldapsearch -x -LLL -h <myLDAP> -b 'ou=people,dc=univ-avignon,dc=fr' -D 'cn=anotherUser,ou=ldap,dc=univ-avignon,dc=fr' -w <secret> "(uid=someUid)" myAttribute does NOT give me the required "myAttribute", only the dn : dn: uid=someUid,ou=people,dc=univ-avignon,dc=fr BUT by replacing "read" by "none" in rule {3}, I get an error "No such object (32)" with either [R1] and [R2]. Since rule {3} should not be evaluated after matching rule {2}, I don't understand why modifying rule {3} modifies the behaviour. And by replacing "read" by "search" in rule {3}, I no longer get an error, but I do NOT obtain the required "myAttribute" and nor the dn, with neither [R1] nor [R2]. Does it mean that "read" in rule {3} was necessary to read the dn ? And that without reading the dn, rule {2} cannot be evaluated ? Please, help me ! Eric

2 1

Using Ppolicy in a provider peer cluster can trigger consumer refresh condition
by James Rawlins 22 Feb '23

22 Feb '23

Hi there, My ldap consists of a cluster of 3 providers that all replicate to each other, and a fleet of consumers replicating from them, and we have ppolicy installed on our providers and consumers both, though we're currently not using it to enforce any particular policies automatically. I've recently discovered a situation where a script could fail to login with a non-rootDN service account to all three provider instances in short order. The providers seem to be able to figure things out quickly, but the consumers sometimes detect some ContextCSN inconsistency and when this happens consumers to enter a REFRESH state caused by updates to the operational attributes on the service account's dn entry in all three providers at nearly the same time. In production this can cause latency due to the extra CPU and network traffic of refreshing all consumers at once. The only relevant documentation I've been able to find for this use case are from https://linux.die.net/man/5/slapo-ppolicy: Note that the current IETF Password Policy proposal does not define how these operational attributes are expected to behave in a replication environment. In general, authentication attempts on a slave server only affect the copy of the operational attributes on that slave and will not affect any attributes for a user's entry on the master server. Operational attribute changes resulting from authentication attempts on a master server will usually replicate to the slaves (and also overwrite any changes that originated on the slave). These behaviors are not guaranteed and are subject to change when a formal specification emerges. And the related ability for consumers to send updates up a replication chain using the chain overlay: ppolicy_forward_updates Specify that policy state changes that result from Bind operations (such as recording failures, lockout, etc.) on a consumer should be forwarded to a master instead of being written directly into the consumer's local database. This setting is only useful on a replication consumer, and also requires the updateref setting and chain overlay to be appropriately configured. tl;dr Ppolicy wrote operational attributes to a service account's dn to all of my provider instances at the same time when my SA used the wrong password to login to them all at once, and caused all my consumers to refresh at the same time. My question is: is the ppolicy overlay inherently unsafe for a provider cluster? Right now I'm considering these options to get rid of the risk of accidentally triggering a consumer REFRESH again: - Remove the ppolicy overlay from the replicated backend (I'm still checking if there's anything we actually use it for, but if it's inherently unsafe in this configuration then it's gotta go) - Move all of the service accounts to another database that ppolicy is not installed on. Thanks!

2 1

Re: Antw: [EXT] Re: Entering Multi-Byte Values for DirectoryString attributes
by Ede Wolf 22 Feb '23

22 Feb '23

> Hi! > > I'd say: Get the proper app (eg. BabelPad on Windows, see attachment) and then BASE64-encode the string. > > Regards, > Ulrich > Thanks, but windows is not an option. Again, base64 encoding is fine with echo -en "" | base64. With a browser I can search for the symbol and do copy paste into the ldif. All that works fine, even if my console font does not even support that symbol. I've done it. But feels a bit hackish. I just hoped, there was an option, to tell the server, when the ldif has this sequence, interpret it as an ecoding, not as a literal string. Now I know, this does only work for the dn (and maybe only openldap, will test, see other post), and for the rest I do have a work around.

2 3

Entering Multi-Byte Values for DirectoryString attributes
by Ede Wolf 22 Feb '23

22 Feb '23

Hello, This is probably more a ldif than an OpenLDAP question, but still, maybe somebody knows the answer: Is there a way to put multibyte characters into an attribute value and let the server know, these are not to be treated literally, but are utf8 character encodings? I've tried to dig into rfc3629 and 4517, but those were above my capabilities. It does of course work for the dn, it also works, if I provide base64 code to the attributes, but is there a way, to directly put them into a ldif an let the server know, these are character encodings? Also, rfc2849 only talks about not line breaking multi-byte characters. In this silly, but easy, example, both cn: and description: are entered literally, while the dn words as intended: dn: cn=A \F0\9F\99\82 Test,dc=example,dc=com cn: A \F0\9F\99\82 Test objectClass: person sn: Test description: %xF0%x9F%x99%x82 Test This is about understanding, not about the intention, to really put a smily into a dn. I am aware, this a potential recipe for disaster. Also, I am aware, the OpenLDAP kindly adds a proper cn value anyway, but that does not help here. And still would leave the description open. Also, as mentioned before: echo -en "A \xF0\x9F\x99\x82 Test" | base64 is a viable workaround, but a cumbersome one. So maybe there is an easier way Thanks Ede

4 11

Re: Antw: [EXT] Entering Multi-Byte Values for DirectoryString attributes
by Ede Wolf 21 Feb '23

21 Feb '23

Am 20.02.23 um 16:18 schrieb Ulrich Windl: > Hi! > > Ever notices the "double-colons" "::"? > > For example: > userPassword:: e1NTSEF9... > > Kind regards, > Ulrich Windl > > Yes, but I am unaware, that those hint to something else than base64 encoding? I may stand more than happily corrected, tough My question was more, how to provide single unicode charater encoding within a ldif file, like it can be done with the dn, where I may provice the hex values for a character.

1 0

Re: OpenSSL1.1.1 support after its EOL
by Anil 1. Tadikamalla (EXT-NSB) 21 Feb '23

21 Feb '23

Hi Team, Can you please help to address below queries ASAP from OpenLDAP point of view: 1. Please do let us know if OpenLDAP can provide extended support of OpenSSL1.1.1 beyond the EOL(End of life cycle) i.e after september 2023? 2. Does OpenLDAP depend on RHEL for OpenSSL support or Does it package OpenSSL on its own? If it depends on RHEL and RHEL introduces OpenSSL3.0 support, how would this be handled by OpenLDAP? Regards, Anil Kumar ________________________________ From: Anil 1. Tadikamalla (EXT-NSB) Sent: Friday, December 9, 2022 9:54:28 AM To: openldap-technical(a)openldap.org Cc: Seenivasan 1. Alagarsamy (EXT-NSB) Subject: Re: OpenSSL1.1.1 support after its EOL Hi Team, GENTLE REMINDER.... Can you please help to address below query to from OpenLDAP Point of View ASAP. Does OpenLDAP depend on RHEL for OpenSSL support or Does it package OpenSSL on its own? If it depends on RHEL and RHEL introduces OpenSSL3.0 support, how would this be handled by OpenLDAP? Regards, Anil Kumar ________________________________ From: Anil 1. Tadikamalla (EXT-NSB) Sent: Friday, December 9, 2022 12:53 AM To: openldap-technical(a)openldap.org Cc: Seenivasan 1. Alagarsamy (EXT-NSB) Subject: OpenSSL1.1.1 support after its EOL Hi Team, Please do let us know if OpenLDAP can provide extended support of OpenSSL1.1.1 beyond the EOL(End of life cycle) i.e after september 2023? Regards, Anil Kumar

2 3

ppolicy and olcPPolicyUseLockout
by Stefan Kania 21 Feb '23

21 Feb '23

Hello, I have the following configuration for my overlay ppolicy (OpenLDAP 2.6) It's a testing system! --------- dn: olcOverlay={0}ppolicy,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {0}ppolicy olcPPolicyDefault: cn=default,ou=policies,dc=example,dc=net olcPPolicyHashCleartext: FALSE olcPPolicyForwardUpdates: FALSE olcPPolicyUseLockout: TRUE --------- My default-policy: --------- dn: cn=default,ou=policies,dc=example,dc=net objectClass: pwdPolicy objectClass: person cn: default pwdAttribute: userPassword pwdAllowUserChange: TRUE pwdExpireWarning: 1440 pwdGraceAuthNLimit: 5 pwdInHistory: 5 pwdLockout: TRUE pwdFailureCountInterval: 300 pwdMaxFailure: 5 pwdMinLength: 8 sn: OurDefaultPolicy pwdLockoutDuration: 120 pwdMustChange: TRUE pwdMaxAge: 2000 --------- Everything works, but I don't get a different message if the account is locked because of to many bad locking attempts. The manpage of slapo-ppolicy telling me: ppolicy_use_lockout = TRUE then a AccountLocked is shown. But I still get: Permission denied, please try again. if I'm giving the correct password after the account is locked because of to many bad locking attempts. Did I miss something? If "yes" what? Thank's Stefan

2 1

Tools parsing dc=foo URLs
by Norman Gray 20 Feb '23

20 Feb '23

Greetings. This command fails in an unexpected way: % ldapsearch -x -H 'ldap:///dc=example,dc=net' '(cn=foo)' Could not parse LDAP URI(s)=ldap:///dc=example,dc=net (3) It appears that ldapsearch wants me to escape the '=' and ',' in that URI: % ldapsearch -x -H 'ldap:///dc%3dexample%2cdc%3dnet' '(cn=foo)' DNS SRV: Could not turn domain=example.net into a hostlist But why? The manpage for ldapsearch says -H ldapuri Specify URI(s) referring to the ldap server(s); a list of URI, separated by whitespace or commas is expected; only the protocol/host/port fields are allowed. As an exception, if no host/port is specified, but a DN is, the DN is used to look up the corresponding host(s) using the DNS SRV records, according to RFC 2782. The DN must be a non-empty sequence of AVAs whose attribute type is "dc" (domain component), and must be escaped according to RFC 2396. I read that as clearly saying (via the 'exception' branch of that paragraph) that the first -H argument is correct. RFC digression: According to RFC 2396, the /dc... is `"/" path_segments`, segments are composed of *pchar, and pchar = unreserved | escaped | ":" | "@" | "&" | "=" | "+" | "$" | "," ...which includes both '=' and ','. Thus those characters don't need to be escaped, by RFC 2396. Or, put another way, 'ldap:///dc=example,dc=net' _is_ escaped according to RFC2396, in the sense that nothing in it needs to be escaped. Looking instead at RFC 4516, the 'dn' in the 'ldapurl' is a 'distinguishedName' from RFC 4514 which (Sect.3) permits '=' and ',' to be included. Sect.2.1 of 4516 requires that the URI must include <reserved>, <unreserved> or <pct-encoded> of RFC 3986, but if we look at that, then Sect.2.2 indicates that <reserved> includes both '=' and ','. Thus the behaviour of ldapsearch, when parsing the -H option, doesn't appear to match the documentation. Explanation: Looking at common.c:tool_args and common.c line 1199, I see that it calls ldap_url_parselist to break the -H argument into a list of URIs, and this will separate dc=example,dc=net at the comma. And sure enough, in practice it's only the ',' that has to be escaped by %2c. I believe this behaviour doesn't match the manpage, which (clearly in my reading of it) requires either a list of protocol/host/port URIs OR (the exception) a single URI containing no host/port but only a DN. That suggests that common.c:tool_args has to detect that exception/second case. Apart from the documentation issue, having to escape commas is both repeatedly surprising and a pain in the neck on the occasions when I want to use the dc=... syntax with ldapsearch. Re detecting that exception, searching for "///" in the ldapuri string would seem to be sufficient, and calling ldap_url_parselist_int in that case (instead of ldap_url_parselist) with a sep argument of " " looks like it would do the job with a minimal change to the code. Best wishes, Norman -- Norman Gray : https://nxg.me.uk

3 4

OpenLDAP proxy to AD
by Sajesh Singh 15 Feb '23

15 Feb '23

RHEL 8 OpenLDAP 2.6.4 Trying to use OpenLDAP as a proxy to AD and most of my configuration seems to be working as expected, but when I try to use the rwm-suffixmassage option an LDAP search against the server returns the following error: No such object (32) If I remove the rwm-suffixmassage option then I am returned the expected entry. Relevant config snippet: suffix "dc=subdomain,dc=domain,dc=tld" uri "ldaps://dc1.subdomain.domain.tld/ ldaps://dc2.subdomain.domain.tld/" chase-referrals no idassert-bind bindmethod=simple binddn="cn=user,ou=OU,dc=subdomain,dc=domain,dc=tld" credentials="secret" mode=self tls_reqcert=demand tls_cacert=cert.file flags=non-prescriptive overlay rwm rwm-suffixmassage "dc=subdomain,dc=domain,dc=tld" "dc=domain,dc=tld" Any help would be appreciated. Thank you, SS

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical February 2023