Pierangelo Masarati wrote:

Simon Gao wrote:

...

Hi,

I'd like to know if chain overlay currently supports sasl binding or not with OpenLDAP 2.3.35.

Since both idassert-bind and chain-idassert-bind are handled by ldap backend, can I assume sasl binding should be available to chain overlay also?

Yes, it does. But, of course, it cannot bind with the user's credentials. It can use SASL bind when exploiting the idassert feature, namely to bind as an administrative identity to proxyAuthz the user's identity.

That's great to know. Do you think following setup will work on a consumer?

========================================================= overlay chain chain-rebind-as-user FALSE

chain-uri ldaps://provider/ chain-rebind-as-user TRUE chain-idassert-bind bindmethod=sasl saslmech=GSSAPI

binddn="uid=host/consumer1,cn=gssapi,cn=auth mode="self" =========================================================

I have set ACL on provider so that uid=host/consumer1 has correct permissions to write all attributes. But it did not work. The error says that host/consumer1 not allowed to assert identity.

Do I need to make host/consumer1 an administrative identity on provider? How?

The issue I am trying to resolve is that I prefer not putting clear text password in slapd.conf. SASL binding fits such need perfectly if I can get it work with chain overlay.

Thanks,

Simon

Pierangelo Masarati wrote:

Simon Gao wrote:

...

That's great to know. Do you think following setup will work on a consumer?

========================================================= overlay chain chain-rebind-as-user FALSE

chain-uri ldaps://provider/ chain-rebind-as-user TRUE chain-idassert-bind bindmethod=sasl saslmech=GSSAPI

binddn="uid=host/consumer1,cn=gssapi,cn=auth mode="self" =========================================================

I have set ACL on provider so that uid=host/consumer1 has correct permissions to write all attributes. But it did not work. The error says that host/consumer1 not allowed to assert identity.

Do I need to make host/consumer1 an administrative identity on provider? How?

The issue I am trying to resolve is that I prefer not putting clear text password in slapd.conf. SASL binding fits such need perfectly if I can get it work with chain overlay.

It appears that authz is not allowed by the provider for that identity. You need to make sure that host/consumer1 has an authzTo rule that allows it to proxyAuthz, and you need to allow the appropriate authz-policy.

I am not making much progress. Here what I tried to add to provider's slapd.conf:

authz-policy both authzFrom dn.exact:uid=host/consumer1,cn=GSSAPI,cn=auth authzTo dn.subtree:ou=people,dc=example,dc=com

Anything I missed?

Simon

Simon Gao wrote:

I am making some progress on this. Following example test014, I am able to get sasl bind working.

I still have two questions.

1)For chain-idassert-bind, if I put bindmethod, saslmech, binddn, mode on each individual line, then sasl binding does not work. They all must be on the same one line. Any reason why multiple line works for simple bind, but not for sasl binding? The inconsistency will cause more efforts in troubleshooting.

This should not be true. I suspect you're doing something weird with leading blanks in continuation lines, since the configuration parser sees each statement as a single line anyway, after gluing multiple lines by replacing continuation indentation with a single blank. If you intend to submit an example of your configuration, please attach it to the message (if small) or make it available for public download. Cut'n'paste could mess up critical portions of the message, like lining and whitespace.

2)Is it possible to add authzTo/authzFrom at "ou=people,dc=example,dc=com" level and all the child entry be proxy authenticated?

I'm not aware of any feature like that. In any case, it should be of very limited help in chaining, since the rationale behind chaining is that users that cannot autonomously authenticate on a remote DSA get authorized by some special identity that has authorization privileges. SO all you need is authzTo in the special identity's entry, while in general the identity that's being authorized does not necessarily reside in the DSA.

p.

Ing. Pierangelo Masarati OpenLDAP Core Team

SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------