https://bugs.openldap.org/show_bug.cgi?id=6531
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9813
Issue ID: 9813
Summary: Incompatibility between remoteauth and ppolicy
overlays
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: thierry.pubellier(a)paris.fr
Target Milestone: ---
Hi,
We are planning to use OpenLDAP as a proxy for some users in our Active
Directory servers, using remoteauth overlay.
We want this OpenLDAP instance to also implement an account lockout policy,
preventing the lockout on our internal Active Directory servers.
But there seems to be an incompatibility between remoteauth and ppolicy
overlays : remoteauth won't remote authenticate a user if local userPassword
attribute exists, while ppolicy overlay needs this attribute.
Could there be a configuration parameter in ppolicy to allow lockout
checks/modifications (which seemed to be the default behavior of OpenLDAP
before ITS#7089) ?
I can provide a patch if allowed.
Thanks by advance,
Best regards,
Thierry
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8476
--- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Seems like a good idea. For constraints where no custom message was provided,
we could return the constraint number to provide a pointer to which constraint
was triggered.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6198
--- Comment #6 from OndÅ™ej KuznÃk <ondra(a)mistotebe.net> ---
A few open questions I can't resolve yet:
- Do we rely on OID macros from schema or let slap_control/load_extop2 register
it? The suggestions above tend to prefer OID macros but they have to be defined
in the schema (there's only one) and they're currently case-sensitive
For controls:
- Do we want to be able to use ACLs to turn non-critical controls to ignored?
- Do we want to be able to use ACLs to refuse control combinations?
- Apart from the 'to' clause, do we want it allowed in the 'by' clause as well
(when would it be useful? There's control combinations, anything else?)
I'll start with "no" to all 3 of the above for now.
As for combination with other specifiers (especially for exops), ACL checks are
issued with the operation and an entry right now, they do make sense in that
scope so password modify/DDS refresh should be in the clear. Other extops are
more of a problem:
- whoami: technically there is a DN but it doesn't have to correspond to an
entry
- verify credentials: tricky, since it's processed as a bind
- cancel: abandon can't be restricted, so probably the same
- turn: no idea
- ChainedRequest: even less of one
Probably happy for those to be impossible to restrict in this way, at least for
now.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8905
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|bugs(a)openldap.org |gnoe(a)symas.com
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7982
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8943
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |SUSPENDED
--- Comment #6 from Howard Chu <hyc(a)openldap.org> ---
One major problem here is that overlays assume they all execute in the same
thread for the duration of an operation. Putting the response in the worker
thread would break overlay response callbacks.
It would be quite a lot of refactoring to make overlays thread-independent, and
that's not going to happen soon.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10255
Issue ID: 10255
Summary: OpenLDAP should leak the SSL ctx and not try to free
it in an atexit() handler
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: simon.pichugin(a)gmail.com
Target Milestone: ---
As mentioned in the subject, OpenLDAP incorrectly handles OpenSSL in its
destructor.
Сomprehensive information can be found here (along with a possible solution):
https://github.com/openssl/openssl/issues/25294
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10252
Issue ID: 10252
Summary: Unable to fetch groups and users at duo admin panel
for enabling MFA for Ldap users
Product: OpenLDAP
Version: 2.5.18
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ajay41.kumar(a)airtel.com
Target Milestone: ---
Hi Team,
I got stuck at configuring openldap server with member of overlay for
groups with below requirement.We are trying to enable Multifactor
authentication using duo auth proxy & duo admin panel configuration for ldap
users.
Ldap server is getting synced successfully with Duo admin portal but
groups and users details not fetching at duo admin portal. Duo support team
mentioned to change ldap configuration as mention article. Can someone help me,
How i can make these changes.
https://duo.my.site.com/s/article/4529?language=en_US
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10251
Issue ID: 10251
Summary: wrong type passed to getsockname
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
New compilers don't allow passing sockaddr_storage * to getsockname() so
clients/tools/common.c no longer compiles. Fix is coming.
--
You are receiving this mail because:
You are on the CC list for the issue.