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

[Petr Spacek]

On 2.6.2014 10:33, Sumit Bose wrote:
> 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.

Oh, in that case we are not adding any new problem (from configuration point 
of view) because it already is a nightmare :-)

You can either:
- use DNS locations - and have functional fail-over with ability to add/remove 
replicas as needed (without further reconfiguration on client side)

or

- use replica-name/IP address directly - then you don't have any problem with 
SRV records

Petr^2 Spacek

>
> 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