[Freeipa-devel] More types of replica in FreeIPA

[Dmitri Pal]

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.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/