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

[Petr Spacek]

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.

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