[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
identity assertion
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