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

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



This is a multi-part message in MIME format.
--------------090509020601080703090604
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 01/28/2011 08:27 PM, Howard Chu wrote:
>> 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.

Hmm, I'm not quite seeing what you're saying here. For example, in 
slapd.1.log, *before* ppolicy_forward_updates (olcPPolicyForwardUpdates) 
is enabled, I can see the certificate being mapped exactly as I expect it:

=====
==> rewrite_context_apply [depth=1] res={0,'cn=localhost,dc=example,dc=com'}
[rw] authid: "cn=localhost,o=openldap,st=some-state,c=us" -> 
"cn=localhost,dc=example,dc=com"
[...]
<==slap_sasl2dn: Converted SASL name to cn=localhost,dc=example,dc=com
slap_sasl_getdn: dn:id converted to cn=localhost,dc=example,dc=com
SASL Canonicalize [conn=1004]: slapAuthcDN="cn=localhost,dc=example,dc=com"
SASL proxy authorize [conn=1004]: 
authcid="cn=localhost,o=openldap,st=some-state,c=us" 
authzid="cn=localhost,o=openldap,st=some-state,c=us"
conn=1004 op=1 BIND authcid="cn=localhost,o=openldap,st=some-state,c=us" 
authzid="cn=localhost,o=openldap,st=some-state,c=us"
SASL Authorize [conn=1004]:  proxy authorization allowed authzDN=""
send_ldap_sasl: err=0 len=-1
conn=1004 op=1 BIND dn="cn=localhost,dc=example,dc=com" mech=EXTERNAL 
sasl_ssf=0 ssf=256
do_bind: SASL/EXTERNAL bind: dn="cn=localhost,dc=example,dc=com" sasl_ssf=0
=====

Based on this, I'm assuming that my authz-regexp is behaving as I'm 
intending -- looking for a certificate with "cn=localhost" anywhere in 
the subject DN, and mapping that to the DN 
cn=localhost,dc=example,dc=com in the directory.

It's only *after* olcPPolicyForwardUpdates is enabled that the SASL 
EXTERNAL authentication stops working.

Can you help me understand the disconnect between what I'm seeing and 
what you're saying?

> 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.

I have updated the expiration date on the certificate and have attached 
it to this message.

> 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.

Ok, will keep this in mind.

Thanks,

	-Kartik

--------------090509020601080703090604
Content-Type: text/plain;
 name="localhost.crt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="localhost.crt"

-----BEGIN CERTIFICATE-----
MIICCTCCAXICCQC1gKCIQ2we4DANBgkqhkiG9w0BAQUFADBJMQswCQYDVQQGEwJV
UzETMBEGA1UECBMKU29tZS1TdGF0ZTERMA8GA1UEChMIT3BlbkxEQVAxEjAQBgNV
BAMTCWxvY2FsaG9zdDAeFw0xMTAxMzExNjE1NTdaFw0xMjAxMzExNjE1NTdaMEkx
CzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpTb21lLVN0YXRlMREwDwYDVQQKEwhPcGVu
TERBUDESMBAGA1UEAxMJbG9jYWxob3N0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQCqZU3fA/o/y5gHXxm0JpdMoV64LAOIPgcZTHv4+OkVjoW2gMHT8AMerJzk
Cr07y1JjfeqV1c7sZl6+aqC3H+HLs0cCtXFKPFY9FmoehO9KBksDaH5o2f7h104r
s/xg2cNTDy1dFFJUzMWQIc8TU7+GpjS3gP0/9gNlIyiLdio9LwIDAQABMA0GCSqG
SIb3DQEBBQUAA4GBAGFeVSjX4ZjLmrU7oob4CyoWO2ekeVyldWLjVOUCyeSMae3n
I1/kQ5AbGrJdtQQeLyRhIQKUM2a1AqjPLW1QKPXHnHnbsnzuWmC2C9fIw1C3o0yZ
UBsxlqoA7K486qeyAb6bUO5X2JD2rOng+HL/pgKlo9h8dW23tWj4CEUMepOh
-----END CERTIFICATE-----

--------------090509020601080703090604--