[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth



subbarao@computer.org wrote:
> 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) (76.99.175.5)
>
>
> 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 
case, "cn=localhost,o=OpenLDAP,st=Some-State,c=US"

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/