[Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?

[Simo Sorce]

On Thu, 2014-06-19 at 17:33 +0300, Alexander Bokovoy wrote:
> On Thu, 19 Jun 2014, Simo Sorce wrote:
> >On Thu, 2014-06-19 at 17:24 +0300, Alexander Bokovoy wrote:
> >> On Thu, 19 Jun 2014, Simo Sorce wrote:
> >> >On Thu, 2014-06-19 at 17:10 +0300, Alexander Bokovoy wrote:
> >> >> On Thu, 19 Jun 2014, Simo Sorce wrote:
> >> >> >> >> and named successfully started, with 389-ds showing autobind to the same
> >> >> >> >> krprincipalname=dns/... in the logs.
> >> >> >> >
> >> >> >> >why do we need to associate bind to dns/whatever ??
> >> >> >> Because we already have ACIs given to dns/hostname to handle DNS
> >> >> >> entries.
> >> >> >
> >> >> >Which are easy to change on upgrade.
> >> >> >
> >> >> >> >we can have a sysaccount called named, like we did for kerberos before
> >> >> >> >we had the ipa-kdb driver.
> >> >> >> A modification of DNS service with 'ipa service-mod' is all what we
> >> >> >> need for single node case, I tried it.
> >> >> >
> >> >> >I do not like it at all, plus each server has a different object and
> >> >> >they would all be duplicates. I prefer very much a single, passwordless
> >> >> >special user in sysconfig, added to the same group that control access
> >> >> >for the DNS tree.
> >> >> autobind needs uidNumber=<uid>+gidNumber=<gid> search to resolve to a
> >> >> single entry. Given that replicas might be running on machines where
> >> >> 'named' user could deviate (think Fedora, RHEL, and Debian), there will
> >> >> still be multiple 'named' sysaccounts and the whole story will break. I
> >> >> don't see how this helps compared to having DNS/hostname principal
> >> >> object extended to cover uidNumber/gidNumber.
> >> >
> >> >This is not really a huge issue.
> >> >We need to allow access to the DNS tree to a group, so all we need is
> >> >for install/upgrade script to check what is the named user on the system
> >> >and create a corresponding system account.
> >> So, now we'll have to manage multiple named accounts named what,
> >> 'named1', 'named2', ... ? How to manage them?
> >
> >what is there to manage ?
> >
> >> One solution could be to have multi-value uidNumber/gidNumber
> >> attributes...
> >
> >nope, you just need to create a new object only if one does not exist
> >with the same uidNumber, and add it to the group we use for ACIs on DNS.
> I assume the account like that shouldn't have any password at all, to
> prevent its use over LDAP instead of LDAPI.

Yep.

> I'm still a bit uncomfortable with it because if this trend goes, we'll
> be making such accounts for other services as well. Given that we have
> no means to manage sysaccounts from IPA right now, their life cycle is a
> bit weird.

I know.

> I may need to revive my sysaccounts module...

There is one more issue though, and this one really concerns me.
If you need to put there multiple accounts because different servers
have different local accounts, then you open up access to unrelated
services. Because all these uids are shared on all systems.

I think this kills my own proposal of sticking these entries in
cn=sysaccounts.

However we could have something in cn=config maybe ?
So that each server can:
A) use the same name/DN
B) have ids that match exactly the local named account no matter how
many different variants we have
C) no management issues when the server is killed from the
infrastructure as cn=config is local to that server and goes away with
it.

What do you think ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York