[Freeipa-devel] [RFC] Migrating existing environments to Trust - v2: reverse DNS lookup

[Sumit Bose]

On Mon, Jun 02, 2014 at 10:22:48AM +0200, Petr Spacek wrote:
> On 2.6.2014 10:11, Sumit Bose wrote:
> >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 at redhat.com
> >>>>>>https://www.redhat.com/mailman/listinfo/freeipa-devel
> >>>>>_______________________________________________
> >>>>>Freeipa-devel mailing list
> >>>>>Freeipa-devel at 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.
> 
> It is designed in a way which is compatible with any standard-compliant
> client using DNS SRV records. SSSD is only one of them.
> 
> See http://www.freeipa.org/page/V3/DNS_Location_Mechanism if you are
> interested in details.

yes, my point was that afaik e.g. pam_ldap or the Solaris LDAP utility
cannot be configured to use SRV records to find a LDAP server, but
expects plain DNS names or IP addresses.

bye,
Sumit

> 
> Petr^2 Spacek
> 
> >
> >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 at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel