Re: (ITS#7021) pwdAllowUserChange: FALSE disallows password change by anybody
by michael＠stroeder.com
masarati(a)aero.polimi.it wrote:
> OTOH, by strictly interpreting the way its use is discussed in the draft,
> it should only apply to attempts by "self" to modify the password, so a
> modification performed by a different identity (provided ACLs permit it)
> should not be affected.
Yes, that's my understanding too.
Ciao, Michael.
11 years, 9 months
ITS#7008
by masarati＠aero.polimi.it
I confirm that the issue is related to performing the operation with a
privileged identity, which results in pooled connections taken nearly
randomly regardless of the client's connection requesting paged results.
p.
11 years, 9 months
Re: (ITS#7021) pwdAllowUserChange: FALSE disallows password change by anybody
by masarati＠aero.polimi.it
> Full_Name:
> Version: 2.4.26
> OS:
> URL:
> Submission from: (NULL) (84.128.254.201)
>
>
> slapo-ppolicy(5) says:
>
> pwdAllowUserChange
>
> This attribute specifies whether users are allowed to change
> their own passwords or not. If pwdAllowUserChange is set to
> "TRUE", or if the attribute is not present, users will be
> allowed to change their own passwords. If its value is
> "FALSE", users will not be allowed to change their own pass-
> words.
>
> Given this text I'd expect that admins can still set the userPassword
> attribute.
> Such a policy is often used for system/machine accounts where the machine
> entity
> itself does not have to change the password but an admin should be allowed
> to do
> so.
By reading the code, I note that pwdAllowUserChange is not checked when
the operation is performed by the rootdn, which in many senses can be seen
as an administrator. If by administrator you mean a generic user that is
logically granted administrative privileges (e.g. limited to this purpose)
I concur it is not possible currently.
By reading the man page (and the draft), this attribute seems to be
essentially intended as a replacement (a workaround for the absence) of
access control. So you could avoid setting it, and use ACLs instead.
OTOH, by strictly interpreting the way its use is discussed in the draft,
it should only apply to attempts by "self" to modify the password, so a
modification performed by a different identity (provided ACLs permit it)
should not be affected.
p.
11 years, 9 months
Re: (ITS#6995) Request for Contribution of Identity Access Management Software to OpenLDAP Project
by Kurt＠OpenLDAP.org
On Aug 15, 2011, at 7:15 PM, <shawn.mckinney(a)jtstools.com> <shawn.mckinney(a)jtstools.com> wrote:
> The product named "Fortress Core" includes contributions that were created by JoshuaTree Software, LLC, who is the exclusive owner of the works. This contribution is made available as indicated by the copyright and license statements attached to the the work.
Shawn, the wording of this statement is not sufficient clear for a couple of reasons. One, the term product doesn't necessarily refer to the contributed works. Two, "includes" language doesn't exclude the possibility that portions of the contributed work were created by others. We need the statement of origin to be quite clear. Assuming all of the contributed works were created by JohshuaTree Software, LLC, we suggest stating something of the form.
The contributed works provided by <creator> and referenced in this ITS were created by <creator>, who is the exclusive owner of the contributed works. The contributed works are made available as indicated in the copyright and license statements attached to the work.
where <creator> was replaced with JoshuaTree Software, LLC.
Please restate the statement of origin, either in the above form or other appropriate form, in response to this ITS.
Regards, Kurt
>
> Shawn McKinney
> -------- Original Message --------
> Subject: Re: (ITS#6995) Request for Contribution of Identity Access
> Management Software to OpenLDAP Project
> From: Kurt Zeilenga <Kurt(a)OpenLDAP.org>
> Date: Mon, August 15, 2011 2:35 pm
> To: shawn.mckinney(a)jtstools.com
> Cc: openldap-its(a)OpenLDAP.org
>
> Shawn,
>
> I have reviewed the submitted materials.
>
> Other than a lack of a statement of origin, I find no reason why these materials cannot be accepted. Please submit a "statement of origin" in a follow-up to this ITS. This can simply be a statement to the effect that the all the submitted materials were authored by JoshuaTree Software, JoshaaTree is the exclusive owner of the works, and that the contribution is made available as indicated by the copyright and license statements in the work. If the work includes materials derived from works to which others own or otherwise have rights to, please detail.
>
> The Foundation has no objection to the Project establishing a sub-project of the OpenLDAP Project, similar to the Java LDAP and JDBC-LDAP sub projects, to develop works based upon your contribution. It is the Foundation understanding that Project is also willing to establish such a sub-project, and extend commit privs to the key developers who produced the contributed work.
>
> It is noted that the OpenLDAP Foundation, if it accepts the final contribution, would from time to time publish works derived (such as the source repository itself, and possibly packaged source bundles) from your contribution as well as possibly the contributions of others. The OpenLDAP Foundation will license its copyright right interests (initially likely quite limited) using the OpenLDAP Public License, and will encourage community members to license their contributions in a manner consistent with our general contribution guidelines. The OpenLDAP Public License is compatible with the 'New BSD open source license' and similar in its basic terms.
>
> The initial COPYRIGHT file (upon acceptance and initial publication by the OpenLDAP Foundation) would be based on the COPYRIGHT file currently found in OpenLDAP Software distributions, excepting JoshuaTree Software would be named as the contributor of the materials for which the published work is derived from, and notice immediately following the Foundation's notice would be that provided by JoshauTree covering the work as contributions.
>
> It is noted that I recently attempted to re-download the materials and they were no longer available. That fine, we'd want you to upload fresh zips to our servers once we all were ready to proceed.
>
> Regards, Kurt
>
> On Jul 14, 2011, at 6:51 PM, shawn.mckinney(a)jtstools.com wrote:
>
> > Full_Name: Shawn McKinney
> > Version: All
> > OS: All
> > URL: ftp://ftp.openldap.org/incoming/
> > Submission from: (NULL) (99.34.198.251)
> >
> >
> > Hello,
> >
> > We have created a new Identity and Access Management SDK, called Fortress, that
> > uses Java and OpenLDAP to provide authentication, RBAC, ARBAC, password
> > policies, auditing and more.
> >
> > It has taken us 2.5 years of steady work to get it ready for this 1.0 release.
> > This SDK has approximately 50K lines of Java code of which approximately 25K are
> > dedicated to testing using JUnit automated tests to ensure it works correctly.
> > There are in excess of 100 public APIs available for use. There is also a Java
> > EE container plug-in that provides authentication and authorization services to
> > Websphere, Tomcat and JBoss app servers in a declarative fashion.
> >
> > This product has not been published and we would like to release it as one of
> > the products under OpenLDAP family of products. The product will be released
> > under New BSD open source license (license information is contained in the
> > source archives on ftp server).
> >
> > I have uploaded seven packages to our FTP server that contain the source,
> > documentation and other items for you to look at.
> >
> > host: jtstools.com
> > user: jtsguest1
> > pw: OpenLd@p1
> >
> > The packages are as follows:
> >
> > Fortress Core SDK
> >
> > 1. source - fortressSrc-1.0.0-rc1.zip - 352K bytes
> > 2. source - fortressTestSrc-1.0.0-rc1.zip - 159K bytes
> > 3. tutorial/doc - fortressSamples-1.0.0-rc1.zip - 766K bytes
> > 4. javadoc - fortressDoc-1.0.0-rc1.zip - 1.4M bytes
> > 5. ldap (folder) - Fortress schema and OpenLDAP slapd.conf
> >
> >
> > Fortress Realm (Java EE Container plug-ins)
> >
> > 6. source - fortressRealmSrc-1.0.0-rc1.zip - 45K bytes
> > 7. javadoc - fortressRealmDoc-1.0.0-rc1.zip - 76K bytes
> >
> >
> > Package 4 contains complete javadoc for the APIs.
> >
> > In package 4, this link, ./fortressDoc-1.0.0-rc1/index.html, contains the
> > overall summary of the SDK.
> >
> > this link, ./oamCore/trunk/dist/docs/api/index.html, contains package
> > descriptions along with detailed documentation describing the contents of the
> > SDK.
> >
> > What we are requesting from the OpenLDAP foundation:
> >
> > 1. Source code repository to host the SDK and Realm packages.
> > 2. Bug tracking.
> > 3. Developer and User forums.
> > 4. Wiki (this is a nice to have)
> >
> > Our goal is to run the open source project with your organization and cultivate
> > a healthy developer and user community. We have high hopes for this product
> > (and OpenLDAP) and consider the 2 products together as an open source
> > alternative for IAM products that will compete with the commercial vendor
> > offerings.
> >
> > Once 1.0 is released, we will begin working on 2.0 which will include UI's to
> > control Fortress and OpenLDAP along with a policy server to wrap the Fortress
> > Java APIs with HTTP/REST Web APIs to make it available to all platforms.
> >
> > Thanks in advance for your consideration.
> >
> > Shawn McKinney
> > JoshuaTree Software
> > shawn.mckinney(a)jtstools.com
> >
>
11 years, 9 months
ITS#7016
by masarati＠aero.polimi.it
Fixed in master, please test. Now it should work correctly also in case
the LDIF that is bootstrapped actually contains
dn: olcDatabase=frontend,cn=config
instead of
dn: olcDatabase={-1}frontend,cn=config
p.
11 years, 9 months
(ITS#7022) Patch - Mozilla NSS - NSS_Init* functions are not thread safe
by rmeggins＠redhat.com
Full_Name: Rich Megginson
Version: current tip of master branch
OS: RHEL6
URL: ftp://ftp.openldap.org/incoming/0001-NSS_Init-functions-are-not-thread-sa...
Submission from: (NULL) (76.26.104.137)
The NSS_InitContext et. al, and their corresponding shutdown functions,
are not thread safe. There can only be one thread at a time calling
these functions. Protect the calls with a mutex. Create the mutex
using a PR_CallOnce to ensure that the mutex is only created once and
not used before created. Move the registration of the nss shutdown
callback to also use a PR_CallOnce. Removed the call to
SSL_ClearSessionCache() because it is always called at shutdown, and we must
not call it more than once.
These patch files are derived from OpenLDAP Software. All of the
modifications to OpenLDAP Software represented in the following
patch(es) were developed by Red Hat. Red Hat has not assigned rights
and/or interest in this work to any party. I, Rich Megginson am
authorized by Red Hat, my employer, to release this work under the
following terms.
Red Hat hereby place the following modifications to OpenLDAP Software
(and only these modifications) into the public domain. Hence, these
modifications may be freely used and/or redistributed for any purpose
with or without attribution and/or other notice.
11 years, 9 months
Re: (ITS#7019) attribute auditContext should not get replicated
by michael＠stroeder.com
hyc(a)symas.com wrote:
> You seem to forget that nobody has any obligation to help you, at all. You're
> imposing on the generosity of volunteers.
And you seem to forget that my testing and filing ITS is also voluntary work.
Ciao, Michael.
11 years, 9 months
Re: (ITS#7019) attribute auditContext should not get replicated
by hyc＠symas.com
Michael Ströder wrote:
> Howard Chu wrote:
>> Of course, you've also been around the Project for pretty much its entire
>> existence, and ought to know by now what information is needed in a useful bug
>> report.
>
> I didn't expect having to provide a complete working setup for each small
> issue. MMR setup with slapo-accesslog attached to each provider already says
> it all. I also didn't expect to read non-sense about the accesslog DB itself
> being replicated (see follow-up 1).
>
> Demanding more and more information for almost trivial things pretty much
> reminds me of bad support for commercial products.
You seem to forget that nobody has any obligation to help you, at all. You're
imposing on the generosity of volunteers. If you're just going to complain
about the response you get, as opposed to trying to help other people help
you, then you should not be surprised if no help materializes.
I even agree with you that follow-up #1 is nonsense. S#1t happens. Would you
prefer that we moderate/censor all replies before they get posted? What
exactly is it that you believe you're entitled to?
> Now we'll see if this ITS will ever turn out something useful...
With an attitude like that, why should anybody even take the time?
> Ciao, Michael.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 9 months
Re: (ITS#7019) attribute auditContext should not get replicated
by michael＠stroeder.com
Howard Chu wrote:
> Of course, you've also been around the Project for pretty much its entire
> existence, and ought to know by now what information is needed in a useful bug
> report.
I didn't expect having to provide a complete working setup for each small
issue. MMR setup with slapo-accesslog attached to each provider already says
it all. I also didn't expect to read non-sense about the accesslog DB itself
being replicated (see follow-up 1).
Demanding more and more information for almost trivial things pretty much
reminds me of bad support for commercial products.
Now we'll see if this ITS will ever turn out something useful...
Ciao, Michael.
11 years, 9 months
