Re: (ITS#7019) attribute auditContext should not get replicated
by hyc＠symas.com
Michael Ströder wrote:
> hyc(a)symas.com wrote:
>> Hm, I take this back. slapd/result.c already filters out DSA-specific opattrs
>> on the provider side, when the Syncrepl control is present. Something else is
>> going on here, but since you failed to provide any config info there's no way
>> to tell where the problem is.
>
> Ah nice language, "you failed" boils down to "you suck".
If you want to read that into it, that's your problem.
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. If, knowing what you know, you still choose not to file useful bug
reports, that's also your problem.
> Anyway: http://www.stroeder.com/temp/openldap-testbed-RE24-mmr.tar.gz
>
> 0. Obviously you have to edit paths...
> 1. Load schulung-initial-1.ldif to one of the providers.
> 2. Modiy entry ou=schulung,dc=stroeder,dc=local.
>
> =>
>
> dn: ou=schulung,dc=stroeder,dc=local
> auditContext: cn=accesslog,dc=stroeder,dc=local
> auditContext: cn=accesslog,dc=stroeder,dc=local
> [..]
>
> Tried this several times...
>
--
-- 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
(ITS#7021) pwdAllowUserChange: FALSE disallows password change by anybody
by michael＠stroeder.com
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.
Unfortunately if (pwdAllowUserChange=FALSE) no password change is allowed at
all. slapd returns: "Insufficient access: User alteration of password is not
allowed"
11 years, 9 months
Re: (ITS#7019) attribute auditContext should not get replicated
by michael＠stroeder.com
hyc(a)symas.com wrote:
> Hm, I take this back. slapd/result.c already filters out DSA-specific opattrs
> on the provider side, when the Syncrepl control is present. Something else is
> going on here, but since you failed to provide any config info there's no way
> to tell where the problem is.
Ah nice language, "you failed" boils down to "you suck".
Anyway: http://www.stroeder.com/temp/openldap-testbed-RE24-mmr.tar.gz
0. Obviously you have to edit paths...
1. Load schulung-initial-1.ldif to one of the providers.
2. Modiy entry ou=schulung,dc=stroeder,dc=local.
=>
dn: ou=schulung,dc=stroeder,dc=local
auditContext: cn=accesslog,dc=stroeder,dc=local
auditContext: cn=accesslog,dc=stroeder,dc=local
[..]
Tried this several times...
11 years, 9 months
ITS#7016
by masarati＠aero.polimi.it
Your analysis is correct. I think prefixing "frontend" with "{-1}" fixes
the problem; however, back-config should recognize "frontent" as a special
type of database that needs to go in place "{-1}" and can only be
instantiated once, so the fix should probably be in back-config.
p.
11 years, 9 months
ITS#7020
by masarati＠aero.polimi.it
The ITS is meant to discuss software bugs. Usage questions must be
directed to the openldap-technical mailing list. This ITS will be closed.
p.
11 years, 9 months
(ITS#7020) How to design an architecture of OpenLDAP for satisfy our needs?
by hao.1.ma.ext＠nsn.com
Full_Name: ma hao
Version: 2.3.43
OS: Linux(RH)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (124.161.106.50)
Hi support,
We got a problem about our authentication architecture.
Here is our situation:
We are using two parts for user authentication, which both are openldap service.
One is password OpenLDAP service on remote server.
One is groups information OpenLDAP service, which also is users permission
info, on local server.
In fact we could not get the user password in our local Openldap, pasword
information stored in remote openldap which could not get our local group
inforamtion.
Do you have any idea to make our local OpenLDAP using remote OpenLDAP authorize
the password and using local OpenLDAP supply groups information?
Best Regards
Ma Hao
11 years, 9 months
RE: (ITS#6995) Request for Contribution of Identity Access Management Software to OpenLDAP Project
by shawn.mckinney＠jtstools.com
>Please submit a "statement of origin" in a follow-up to this ITS
Let me try this again:
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 McKinney
JoshuaTree Software
11 years, 9 months
RE: (ITS#6995) Request for Contribution of Identity Access Management Software to OpenLDAP Project
by shawn.mckinney＠jtstools.com
<html><body><span style=3D"font-family:Verdana; color:#000000; font-size:10=
pt;"><div>Kurt, thanks for taking the time to look this over and allowing t=
his to proceed. We are looking forward to working with you and the ot=
hers on this project in the near future. This has been a long time co=
ming for us and we appreciate this opportunity.</div><div><br></div><div>He=
re's the statement of origin. <br></div><div><br></div><div>The product nam=
ed "Fortress Core" includes contributions that were created by JoshuaTree S=
oftware, LLC, who =0Ais the exclusive owner of the works. This contri=
bution is made =0Aavailable as indicated by the copyright and license state=
ments attached to the the =0Awork.</div><div><br></div><div></div><div>Shaw=
n McKinney</div><blockquote id=3D"replyBlockquote" webmail=3D"1" style=3D"b=
order-left: 2px solid blue; margin-left: 8px; padding-left: 8px; font-size:=
10pt; color: black; font-family: verdana;">=0A<div id=3D"wmQuoteWrapper">=
=0A-------- Original Message --------<br>=0ASubject: Re: (ITS#6995) Request=
for Contribution of Identity Access<br>=0AManagement Software to OpenLDAP =
Project<br>=0AFrom: Kurt Zeilenga <<a href=3D"mailto:Kurt@OpenLDAP.org">=
Kurt(a)OpenLDAP.org</a>><br>=0ADate: Mon, August 15, 2011 2:35 pm<br>=0ATo=
: <a href=3D"http://shawn.mckinney@jtstools.com">shawn.mckinney(a)jtstools.co=
m</a><br>=0ACc: <a href=3D"mailto:openldap-its@OpenLDAP.org">openldap-its@O=
penLDAP.org</a><br>=0A<br>=0AShawn,<br>=0A<br>=0AI have reviewed the submit=
ted materials.<br>=0A<br>=0AOther than a lack of a statement of origin, I f=
ind no reason why these materials cannot be accepted. Please submit a "sta=
tement of origin" in a follow-up to this ITS. This can simply be a stateme=
nt to the effect that the all the submitted materials were authored by Josh=
uaTree Software, JoshaaTree is the exclusive owner of the works, and that t=
he 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.<br>=0A<br>=
=0AThe Foundation has no objection to the Project establishing a sub-projec=
t of the OpenLDAP Project, similar to the Java LDAP and JDBC-LDAP sub proje=
cts, to develop works based upon your contribution. It is the Foundation u=
nderstanding that Project is also willing to establish such a sub-project, =
and extend commit privs to the key developers who produced the contributed =
work.<br>=0A<br>=0AIt 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) fro=
m your contribution as well as possibly the contributions of others. The O=
penLDAP Foundation will license its copyright right interests (initially li=
kely quite limited) using the OpenLDAP Public License, and will encourage c=
ommunity members to license their contributions in a manner consistent with=
our general contribution guidelines. The OpenLDAP Public License is compa=
tible with the 'New BSD open source license' and similar in its basic terms=
.<br>=0A<br>=0AThe initial COPYRIGHT file (upon acceptance and initial publ=
ication by the OpenLDAP Foundation) would be based on the COPYRIGHT file cu=
rrently found in OpenLDAP Software distributions, excepting JoshuaTree Soft=
ware would be named as the contributor of the materials for which the publi=
shed work is derived from, and notice immediately following the Foundation'=
s notice would be that provided by JoshauTree covering the work as contribu=
tions.<br>=0A<br>=0AIt is noted that I recently attempted to re-download th=
e 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.<br>=0A=
<br>=0ARegards, Kurt<br>=0A<br>=0AOn Jul 14, 2011, at 6:51 PM, <a href=3D"h=
ttp://shawn.mckinney@jtstools.com">shawn.mckinney(a)jtstools.com</a> wrote:<b=
r>=0A<br>=0A> Full_Name: Shawn McKinney<br>=0A> Version: All<br>=0A&g=
t; OS: All<br>=0A> URL: ftp://<a href=3D"http://ftp.openldap.org/incomin=
g">ftp.openldap.org/incoming</a>/<br>=0A> Submission from: (NULL) (99.34=
.198.251)<br>=0A> <br>=0A> <br>=0A> Hello,<br>=0A> <br>=0A> =
We have created a new Identity and Access Management SDK, called Fortress, =
that<br>=0A> uses Java and OpenLDAP to provide authentication, RBAC, ARB=
AC, password<br>=0A> policies, auditing and more.<br>=0A> <br>=0A>=
It has taken us 2.5 years of steady work to get it ready for this 1.0 rele=
ase. <br>=0A> This SDK has approximately 50K lines of Java code of which=
approximately 25K are<br>=0A> dedicated to testing using JUnit automate=
d tests to ensure it works correctly. <br>=0A> There are in excess of 10=
0 public APIs available for use. There is also a Java<br>=0A> EE contai=
ner plug-in that provides authentication and authorization services to<br>=
=0A> Websphere, Tomcat and JBoss app servers in a declarative fashion. =
<br>=0A> <br>=0A> This product has not been published and we would li=
ke to release it as one of<br>=0A> the products under OpenLDAP family of=
products. The product will be released<br>=0A> under New BSD open sour=
ce license (license information is contained in the<br>=0A> source archi=
ves on ftp server).<br>=0A> <br>=0A> I have uploaded seven packages t=
o our FTP server that contain the source,<br>=0A> documentation and othe=
r items for you to look at.<br>=0A> <br>=0A> host: <a href=3D"http://=
jtstools.com">jtstools.com</a><br>=0A> user: jtsguest1<br>=0A> pw: Op=
enLd@p1<br>=0A> <br>=0A> The packages are as follows:<br>=0A> <br>=
=0A> Fortress Core SDK<br>=0A> <br>=0A> 1. source - fortressSrc-=
1.0.0-rc1.zip - 352K bytes<br>=0A> 2. source - fortressTestSrc-1.0.0-r=
c1.zip - 159K bytes<br>=0A> 3. tutorial/doc - fortressSamples-1.0.0-rc=
1.zip - 766K bytes<br>=0A> 4. javadoc - fortressDoc-1.0.0-rc1.zip - 1.=
4M bytes<br>=0A> 5. ldap (folder) - Fortress schema and OpenLDAP slapd=
.conf<br>=0A> <br>=0A> <br>=0A> Fortress Realm (Java EE Container =
plug-ins)<br>=0A> <br>=0A> 6. source - fortressRealmSrc-1.0.0-rc1.z=
ip - 45K bytes<br>=0A> 7. javadoc - fortressRealmDoc-1.0.0-rc1.zip - 7=
6K bytes<br>=0A> <br>=0A> <br>=0A> Package 4 contains complete jav=
adoc for the APIs. <br>=0A> <br>=0A> In package 4, this link, ./fortr=
essDoc-1.0.0-rc1/index.html, contains the<br>=0A> overall summary of the=
SDK.<br>=0A> <br>=0A> this link, ./oamCore/trunk/dist/docs/api/index=
.html, contains package<br>=0A> descriptions along with detailed documen=
tation describing the contents of the<br>=0A> SDK.<br>=0A> <br>=0A>=
; What we are requesting from the OpenLDAP foundation:<br>=0A> <br>=0A&g=
t; 1. Source code repository to host the SDK and Realm packages.<br>=0A>=
2. Bug tracking.<br>=0A> 3. Developer and User forums.<br>=0A> 4. Wi=
ki (this is a nice to have)<br>=0A> <br>=0A> Our goal is to run the o=
pen source project with your organization and cultivate<br>=0A> a health=
y developer and user community. We have high hopes for this product<br>=0A=
> (and OpenLDAP) and consider the 2 products together as an open source<=
br>=0A> alternative for IAM products that will compete with the commerci=
al vendor<br>=0A> offerings. <br>=0A> <br>=0A> Once 1.0 is releas=
ed, we will begin working on 2.0 which will include UI's to<br>=0A> cont=
rol Fortress and OpenLDAP along with a policy server to wrap the Fortress<b=
r>=0A> Java APIs with HTTP/REST Web APIs to make it available to all pla=
tforms.<br>=0A> <br>=0A> Thanks in advance for your consideration.<br=
>=0A> <br>=0A> Shawn McKinney<br>=0A> JoshuaTree Software<br>=0A&g=
t; <a href=3D"http://shawn.mckinney@jtstools.com">shawn.mckinney(a)jtstools.c=
om</a><br>=0A> <br>=0A<br>=0A=0A</div>=0A</blockquote></span></body></ht=
ml>
11 years, 9 months
Re: (ITS#6995) Request for Contribution of Identity Access Management Software to OpenLDAP Project
by Kurt＠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
Re: (ITS#7019) attribute auditContext should not get replicated
by masarati＠aero.polimi.it
> michael(a)stroeder.com wrote:
>> Full_Name:
>> Version: 2.4.26
>> OS:
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (84.163.26.156)
>>
>>
>> It seems that attribute auditContext is replicated to consumers if
>> there's an
>> accesslog DB configured at the provider. IMO this does not make sense
>> since the
>> accesslog DB is not replicated and one might not want to load
>> slapo-accesslog
>> module at all in the consumer's config.
>>
>> In a 2-way MMR setup with accesslog DB attached to both master providers
>> the
>> auditContext contains two values for auditContext and even the same one.
>
> Since a syncrepl operation is a regular LDAP search, the provider sends
> everything that matches the search request. Probably we should be
> filtering
> out DSA-specific opattrs at the consumer side.
Agree. User-wise, there could be a (set of) configuration option(s) that
result in a safe default filtering, while allowing "expert" users (or for
experimental reasons) to replicate things arbitrarily.
Alternatives:
1) protect auditContext with ACLs at the producer's side
2) document the need to use filter="(!(objectClass=auditContext))" (or
whatever is appropriate) when configuring the consumer.
p.
11 years, 9 months
