If you want to be able to do a simple bind as one DN but perform actions as another DN, you need to use some sort of identity assertion. Is there a way to do this without using back-ldap?
Specifically, I'm trying to work around the lack of ACL access to the config backend by allowing specific DNs to assert the cn=config rootDN. I've got rootdn for cn=config set to cn=config,dc=test and an entry in a bdb backend for cn=config,dc=test with a authzFrom attribute set. So I just need to bind as a user that is authorized with the authzFrom and assert the cn=config,dc=test identity, right? The only way I could think to do that was to try to set up another virtual naming context of something like cn=admin and use some sort of rewriting so that cn=config,cn=admin points at cn=config. So I'm trying to set up an ldap backend that will proxy the bind through to the dc=test backend and then assert the identity of cn=config,dc=test so that the authorization is handled at dc=test via the authz-policy from. Is this the right approach? I guess one thing I'm a little unclear on is what exactly is the authcID? That's what has to match the authzFrom attribute, right? Is it basically just the bind DN in a simple bind situation? So far, a simple slapd config looks like the following, but I think slapd is first authenticating the client by proxy and then rebinding anonymously to try to assert the cn=config,dc=test identity. database config rootdn cn=config,dc=test database bdb suffix dc=test ... database ldap suffix cn=admin uri "ldap://localhost" idassert-bind mode=self bindmethod=simple authzID="dn:cn=config,dc=test" overlay rwm rwm-suffixmassage "cn=admin" "" I connect to localhost, do a simple bind as a real user, try to perform and operation on cn=config,cn=admin, hoping that the operation will be relayed to cn=config with an effective identity of cn=config,dc=test, but I get insufficient access errors and the logs indicate that before the identity assertion there is an anonymous bind. Isn't the mode=self supposed to take care of that? Does my ldap database section need to have 'idassert-authzFrom "dn:*"'? Suggestions, please? I get the impression that I'm supposed to be using the extra features of SASL binds but I was hoping not to open that can of worms for a while. Do I just need to go the SASL route? Is there a way to move to SASL with my current SSHA userPassword credentials intact? -- Eric Irrgang - UT Austin ITS Unix Systems - (512)475-9342