On Wed, 18 Jul 2012, Rob Crittenden wrote:
Alexander Bokovoy wrote:
On Tue, 17 Jul 2012, Rob Crittenden wrote:
Alexander Bokovoy wrote:
On Fri, 13 Jul 2012, Alexander Bokovoy wrote:

when adding AD trusts support, we need to ensure we have valid kerberos
ticket of the user from 'admins' group or otherwise appropriate ACIs
will not be granted.

This patch introduces a check for that. We already check if
ipa-adtrust-install is run by root so this complements existing checks.

After discussing on IRC with Simo and Rob, we came to conclusion that it
is possible to switch to LDAPI and autobind feature of dirsrv for
authentication and remove requirement for Directory Manager credentials

Updated patch makes use of LDAPI + autobind under root privileges to map
automatically to Directory Manager privileges in dirsrv. Additionally it
ensures we have Kerberos credentials to fetch keytab with CIFS service

Service._ldap_mod() is extended to switch to autobind when self.ldapi is
set to True and we are running as root.

For those interested in why ACIError is mapped to 'outdated Kerberos
credentials' error message, this is because we'll get ACIError for 'ipa
user-show <uid>' command when authenticated by the Kerberos credentials
for <uid> in a default ccache only when Kerberos credentials are
stale --
either belong to a user that was removed or to a previous IPA install
that was wiped before reinstalling. The latter is how I discovered
this case. :)

I think that this should raise an exception if one tries to use ldapi,
doesn't provide the DM password and is not root. Otherwise it won't
authenticate at all.
This is not exactly true.

$ id
uid=757000001(abokovoy) gid=757000001(abokovoy) groups=757000001(abokovoy)

$ ldapsearch -vvv -H ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*'
ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base )
SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Inappropriate authentication (48)
    additional info: SASL EXTERNAL bind requires an SSL connection

$ ldapsearch -vvv -Y GSSAPI -H
ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*' >/dev/null
ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base )
SASL/GSSAPI authentication started
SASL username: abokovoy@IPA.LOCAL
SASL data security layer installed.
filter: (objectclass=*)
requesting: *
So GSSAPI auth works with LDAPI access. I can simply enforce -Y GSSAPI
when non-root and no dm_password regardless of self.ldapi, this would
extend previously available logic to following:

- ldapi: use -H ldapi://url instead of -h hostname
- dm_password: add Directory Manager auth
- root without dm_password: use autobind
- non-root without dm_password: use GSSAPI

In reality, I think all this service code always runs as root, so it
may be a moot point, but this code is kinda convoluted.

Sorry, I didn't mean this in general, but this code is going to result in no auth being used which is going to fail. So rather than failing with some no auth error we either enforce that Service is executed as root or raise an exception in this auth code. In other words, if we know something isn't going to work before we try it, we should fail with a more friendly error.
What the code did before in such case (no DM, non-root, non-ldapi) is to
use -Y GSSAPI. So this forces to try GSSAPI auth already. My latest
patch (-2) expands this also to (no DM, non-root, ldapi) case.

However, one case is not covered yet: no DM, root, non-ldapi. We either can try -Y GSSAPI here as well or raise exception. I'd prefer the
/ Alexander Bokovoy

Freeipa-devel mailing list

Reply via email to