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 ([email protected]) behalf. LDAP server cannot map [email protected] 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 [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
