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

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

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

Reply via email to