[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

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