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.
--
Regards,
Ondrej Hamada
FreeIPA team
jabber:oh...@jabbim.cz
IRC: ohamada
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
