[Freeipa-users] how to allow a remote realm user to be an IPA admin?

[Alexander Bokovoy]

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 credentials
At this step IPA server code you are talking to attempts to bind to LDAP server
on your (administrator at MSAD.TEST) behalf. LDAP server cannot map
administrator at 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