On Mon, Jun 02, 2014 at 09:45:28AM +0200, Petr Spacek wrote:
> On 30.5.2014 15:47, Sumit Bose wrote:
> >On Fri, May 30, 2014 at 09:13:18AM -0400, Dmitri Pal wrote:
> >>On 05/30/2014 03:04 AM, Sumit Bose wrote:
> >>>On Thu, May 29, 2014 at 01:31:04PM -0400, Simo Sorce wrote:
> >>>>On Thu, 2014-05-29 at 18:50 +0200, Petr Spacek wrote:
> >>>>>On 29.5.2014 13:48, Sumit Bose wrote:
> >>>>>>== slapi-nis plugin/compat tree ==
> >>>>>>The compat tree offers a simplified LDAP tree with user and group data
> >>>>>>for legacy clients. No data for this tree is stored on disk but it is
> >>>>>>always created on the fly. It has to be noted that legacy clients might
> >>>>>>be one of the major users of the user-views because chances are that
> >>>>>>they were attached to the legacy systems with legacy ID management which
> >>>>>>should be replaced by IPA.
> >>>>>>
> >>>>>>In contrast to the extdom plugin it is not possible to determine the
> >>>>>>client based on the DN because connection might be anonymous. The
> >>>>>>Slapi_PBlock contains the IP address of the client in
> >>>>>>SLAPI_CONN_CLIENTNETADDR. Finding the matching client object in the IPA
> >>>>>>tree requires a reverse-DNS lookup which might be unreliable. If the
> >>>>>>reverse-DNS lookup was successful the slapi-nos plugin can follow the
> >>>>>>same steps as the extdom plugin to lookup up and apply the view.
> >>>>>Do we really want to base security decisions on reverse DNS resolution?
> >>>>No we do not want to play these games.
> >>>>
> >>>>>That
> >>>>>will be insecure. Attacker could tamper with reverse DNS to change 
> >>>>>UID/GID
> >>>>>mapping ... Maybe we can store IP->view mapping in the LDAP database. 
> >>>>>That
> >>>>>should be reliable if we assume that only TCP is used for connection to 
> >>>>>LDAP
> >>>>>database.
> >>>>It is not just about it being insecure, it is about it being wrong.
> >>>>As soon as you have a bunch of clients behind a NAT this pans goes belly
> >>>>up.
> >>>I do not like this one either. I just wanted to list to options I could
> >>>think of because I think supporting user-views on legacy clients is one
> >>>of the major use-cases for this feature.
> >>>
> >>>bye,
> >>>Sumit
> >>>
> >>>>>>As a alternative slapi-nis can provide one tree for each view.
> >>>>This is the only alternative, if we decide to pursue it.
> >>>>
> >>>>Simo.
> >>>>
> >>>>--
> >>>>Simo Sorce * Red Hat, Inc * New York
> >>>>
> >>>>_______________________________________________
> >>>>Freeipa-devel mailing list
> >>>>Freeipa-devel@redhat.com
> >>>>https://www.redhat.com/mailman/listinfo/freeipa-devel
> >>>_______________________________________________
> >>>Freeipa-devel mailing list
> >>>Freeipa-devel@redhat.com
> >>>https://www.redhat.com/mailman/listinfo/freeipa-devel
> >>
> >>Please correct me as I might be confused.
> >>We have the compat tree now for legacy clients. It is also used by latest
> >>SSSD clients to do special lookups, right?
> >
> >no, we discussed this with Alexander some time ago and he asked not to
> >use the compat tree from SSSD but the extdom plugin because of the given
> >limitations of the slapi-nis plugin.
> >
> >>The data in this tree comes from the SSSD on the server running in server
> >>mode.
> >>I wonder if we can say: here are replicas A, B, C that have vanilla "default
> >>view", here are replicas K, L, M where the data is overwritten with a
> >>special view (i.e. UID/GID fro ma special area) and then we have replicas
> >>X,Y,Z that have a different overlay view.
> >>It will be assumed that replicas A,B,C, serve clients in one "zone", new and
> >>legacy, while K, L, M serve another zone and X, Y, Z serve the other one.
> >>Would that work?
> >
> >Besides that it is very confusing it would be possible as long as the
> >overrides from the special views are done by slapi-nis because SSSD on
> >servers and replicas will always and only deliver the default view.
> 
> Also, this would completely break DNS-based fail-over (based on SRV records)
> because different replicas would provide different data.

Good point. Additionally please note that the compat tree is for legacy
clients where DNS-locations might not work at all.

bye,
Sumit

> 
> In theory, it could be done with DNS-locations (which we repeatedly decided
> not to support). In all cases, it requires re-configuration on client side
> because support for 'locations' has to be explicitly enabled in SSSD.
> 
> References:
> http://www.freeipa.org/page/V3/DNS_Location_Mechanism
> https://fedorahosted.org/freeipa/ticket/2008
> 
> -- 
> Petr^2 Spacek
> 
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to