On Sun, 09 Dec 2012, Brian Cook wrote:
How do you let a remote user be an admin for IPA?
You cannot do it, at least right now.

I followed the fedora group example

external group:ad_admins_external
Posix Group: ad_admins

Then I made ad_admins a group member of ipa group 'admins' -
theoretically now MSAD\Administrator is an IPA admin?  I get the
following.  How does this work?

Being able to perform IPA management operations means being able to bind
to IPA LDAP with the identity in question. For Kerberos authentication
LDAP server maps user principal to a DN of an object in LDAP.

In case of trust users there are no LDAP objects that they represent
since the whole idea of a trust was to avoid replicating objects between
the realms, so while IPA KDC accepts AD realm's tickets for the users,
IPA LDAP server doesn't know what they map to in terms of LDAP objects.

Thus, trust users cannot be used to bind for LDAP access.

sh-4.1$ ipa user-add
ipa: ERROR: Could not create log_dir u'/home/msad.test/administrator/.ipa/log'
First name: joe
Last name: blo
User login [jblo]:
ipa: ERROR: Insufficient access: SASL(-14): authorization failure: Invalid 
At this step IPA server code you are talking to attempts to bind to LDAP server
on your (administra...@msad.test) behalf. LDAP server cannot map
administra...@msad.test to an existing DN, thus a failure is raised.

Since access controls in 389-ds LDAP server are built around DNs of
existing objects, you need to be able to map these ephemeral users to
some existing objects first to allow them to bind to LDAP. We haven't
done that yet but may at some point in future consider adding sort of
ephemeral bind support. It is unclear how to do it properly, considering
all security implications.

/ Alexander Bokovoy

Freeipa-users mailing list

Reply via email to