Re: [Freeipa-users] how to allow a remote realm user to be an IPA admin?
On Mon, 2012-12-10 at 14:25 +0200, Alexander Bokovoy wrote: > 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. Note that this[1] DS tickeet needs to be implemented for us to be able, at some point to create a fallback mapping so we can map foreign user to a 'role' object in DS. This way we will be able to properly authorize remote users to operate on freeipa, even as admins at some point as long as we can map them to an object role based on a SAL mapping. This will take a while though. For the moment you need a real FreeIPA user to manage freeipa, you can think of foreign uses as 'guests' atm. Simo. [1] https://fedorahosted.org/389/ticket/534 -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] how to allow a remote realm user to be an IPA admin?
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 (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 Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] how to allow a remote realm user to be an IPA admin?
How do you let a remote user be an admin for IPA? 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? Thanks, Brian sh-4.1$ kinit administra...@msad.test Password for administra...@msad.test: sh-4.1$ klist Ticket cache: FILE:/tmp/krb5cc_1653800500 Default principal: administra...@msad.test Valid starting ExpiresService principal 12/09/12 22:34:43 12/10/12 08:35:09 krbtgt/msad.t...@msad.test renew until 12/10/12 22:34:43 sh-4.1$ sh-4.1$ kinit administra...@msad.test^C sh-4.1$ 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 sh-4.1$ klist Ticket cache: FILE:/tmp/krb5cc_1653800500 Default principal: administra...@msad.test Valid starting ExpiresService principal 12/09/12 22:34:43 12/10/12 08:35:09 krbtgt/msad.t...@msad.test renew until 12/10/12 22:34:43 12/09/12 22:35:31 12/10/12 08:35:09 krbtgt/ipa.t...@msad.test renew until 12/10/12 22:34:43 12/09/12 22:35:09 12/10/12 08:35:09 HTTP/ipa1.ipa.t...@ipa.test renew until 12/10/12 22:34:43 sh-4.1$ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
