[Date Prev][Date Next]
Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
- From: email@example.com
- Date: Sat, 29 Jan 2011 01:28:11 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
> Full_Name: Kartik Subbarao
> Version: 2.4.23
> OS: Debian Linux 5.0.5
> URL: ftp://ftp.openldap.org/incoming/kartik_subbarao.101116.tgz
> Submission from: (NULL) (22.214.171.124)
> I'm trying to get a consumer server to forward ppolicy-related updates to its
> provider server, and to use certificate-based authentication (SASL EXTERNAL)
> over STARTTLS when authenticating to the provider.
> I'm running into multiple problems here. The core problem seems to be that
> enabling ppolicy_forward_updates breaks the chaining overlay such that it binds
> anonymously instead of with SASL EXTERNAL.
That's because your authz-regexp is wrong. You mapped "cn=localhost" but when
using SASL EXTERNAL, the user's DN is the complete certificate DN. In your
The reason this didn't break replication is because in this test, everything
has anonymous read access so the consumer was able to pull what it needed.
> Another problem is that bind
> operations to the consumer server start to return two result messages -- one
> with the error code of the chained operation, and one with the error code of the
> bind operation.
I didn't get this far because your test certificate is now expired. I guess I
can substitute some other certs and look at it again, but I think the core
issue is your misconfigured authz-regexp.
> To simplify reproducing the problem, I've worked with test022-ppolicy in the
> openldap test framework. Here, I ran into another issue. I can't seem to be able
> to configure sasl external/starttls chaining properly with the cn=config style
> configuration that test022-ppolicy applies. The self-signed cert that I'm using
> works fine with replication, but it doesn't seem to work with chaining. This may
> or may not be another issue that needs to be resolved.
> In any case, with the attached files in the ITS, I hope that what I'm trying to
> do and the results that I'm getting should be as clear as possible.
Better to rename your scripts when you modify one of our existing ones. E.g.
test999-xxxxxx and just create new data files instead of modifying ours.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/