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

[Petr Spacek]

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.

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