[Freeipa-devel] More types of replica in FreeIPA

[Simo Sorce]

On Sat, 2012-03-03 at 18:33 -0500, Dmitri Pal wrote:
> On 03/01/2012 08:32 AM, Ondrej Hamada wrote:
> > On 02/29/2012 04:36 PM, Simo Sorce wrote:
> >> On Wed, 2012-02-29 at 16:19 +0100, Ondrej Hamada wrote:
> >>> Hi everyone,
> >>> I'm currently working on my thesis. It's objective is $SUBJ and we
> >>> already have ticket for that: #194. The task is to create two more
> >>> replica types - the HUB and Consumer. In 389-DS both the HUB and
> >>> Consumer are read-only. Additionally the HUB can push the data to the
> >>> Consumers.
> >>>
> >>> In case of FreeIPA the server is not only providing data, but also
> >>> services like CA, NTP, DNS, Kerberos. Therefore I'm kindly asking you
> >>> for advices and opinions on that:
> >>>
> >>> 1. What should be the position of HUB?
> >>> I mean should it be used as an interconnection between Masters and
> >>> Consumers only, so that it will be 'hidden' in the topology and only
> >>> forwards the updates, or should the HUB be also used as a regular
> >>> Consumer which has additional ability to push the updates further to
> >>> Consumers/HUBS?
> >>>
> >> I would think that having shadow HUBs would make things more reliable.
> >>
> >>> 2. Which services should be available on HUB and Consumer?
> >>> I think, the priority of these replicas would be to answer to data
> >>> request by ipa whatever-(find|show) commands or to provide some LDAP
> >>> data for email addressing etc. Also it shouldn't cause much trouble to
> >>> run NTP on Consumer, but what about Kerberos or CA? Is it a good
> >>> solution to let users authenticate against these replicas? Is it
> >>> correct to leave classified data like passwords on these replicas?
> >> CA's clearly have no place in a read-only replica in my mind.
> >>
> >> Kerberos stuff is different. The problem with a read-only replica and
> >> Kerberos is that krb needs to write data for local user lockouts.
> >> Password changes can be avoided by allowing kadmind only on full
> >> masters.
> >>
> >> There is also another angle to consider and that is the Rad-Only Domain
> >> Controller (RODC) available in the Microsoft world. This kind of server
> >> is even more limited than a read-only replica as it does not contain the
> >> full data. To do that it requires quite some tweaking on the KDC
> >> component too, so maybe it is out of scope, but it may make sense
> >> reading up on what they do to have a sense of the kind of services they
> >> enable/disable on read only servers.
> >
> > I've read some articles about RODC and according to them, RODC is
> > supposed to be used in branch offices where could be problem providing
> > physical security of the machine - therefore RODC doesn't contain any
> > passwords or confident data. The authentication requests must be
> > forwarded to regular Domain Controller, but it is also possible to
> > cache some credentials - usually the credentials of users that uses
> > the RODC frequently, so that possible crack of RODC affects only this
> > small group of users. If someone's credentials are not cached and the
> > connection is broken between RODC and DC, he can't log in. RODC also
> > supports read-only DNS.
> >
> > If the consumer should really be read-only, then the RODC way seems to
> > be exactly what we are looking for.
> >> Simo.
> >>
> >
> >
> This sounds like enabling DS pass-through PAM proxy using SSSD to relay
> to IPA if user connects via LDAP and use AuthHub if he authenticates
> using Kerberos is something you should consider. I would start exploring
> those projects and features but the setup would be pretty complex. May
> be it can be tuned down in some way with a special plugin like AuthHub
> that would go directly to SSSD.

I am not so sure your characterization is really spot on.
For ldap binds we would probably have a much simpler plugin than
PAm-passthrough and simply perform a bind against the remote server.

For kerberos, keep in mind that authhub needs a special client and sends
password over the wire (yes encrypted, still makes little difference).
It is not a solution where normal kerberos clients and services are
involved (authhub does not help you if you have a keytab and want to
kinit with it). For many years it will be a good solution for 2FA, but
hardly applicable beyond that.

For a read-only KDC we need to investigate what's the better solution.
There are many ways we can handle the issue, one of the simplest is
probably to allow the RO KDC to use a special LDAP Extended operation
against a full R/W server to get the user keys to sign, authenticating
with a special R/O KDC principal. We can also investigate how MS does
internal forwarding and do something similar as I suspect that's
something samba4-RODC will want to implement too, so we could share some
of the development burden there.

Simo.

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