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

[hyc@symas.com]

Kartik Subbarao wrote:
> 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:

OK, that's probably a red herring. With your updated cert, I see two issues 
from the logs -
   1) since ppolicy uses the database rootdn to perform the pwdFailuretime 
update, this is considered a privileged connection. Note from the 
slapd-ldap(5) manpage that acl-bind is used for root/privileged connections. 
Your idassert-bind directive had no effect here. The TLS session failed 
because the acl-bind context had no CA cert configured. Adding an appropriate 
olcDbACLBind directive got past this issue.
   2) since pwdFailuretime is an operational attribute, you need to have 
manage privilege to update it. With (1) fixed the modify is correctly chained 
to the provider, but the provider rejects it with Insufficient Access. 
Changing the ACL in slapd-ppolicy.conf to grant "manage' instead of "write" 
access fixes that. With both of those corrections, your test script succeeds. 
Closing this ITS as user config error, there is no software bug here.
>
> =====
> ==>  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
>
>
> 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-----


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/