On 04/19/2012 12:33 PM, Simo Sorce wrote: > On Thu, 2012-04-19 at 10:10 -0400, Dmitri Pal wrote: >> If the eSSO is not required and we talk about the initial login only >> we >> can have a DS instance as a consumer do not need to have the whole IPA >> becuase KDC, CA and management frameworks are not needed. This DS can >> replicate a subset of the users, groups and other data using >> fractional >> replication for the identity lookups can and use PAM pass-through >> feature with SSSD configured to go to the real master for >> authentication. >> > What's the point of a "login" server if SSSD then has to go and talk to > a different remote server ? > I mean what is the use case ?
Local server is the central hub for the authentications in the remote office. The client machines with SSSD or LDAP clients might not have access to the central datacenter directly. Another reason for having such login server is to reduce the traffic between the remote office and central data center by pointing to the clients to the login server for the identity lookups and cached authentication via LDAP with pam proxy and SSSD under it. The SSSD will be on the server. > Also we need to keep in mind that we cannot assume SSSD to be always > available on clients. We can assume that SSSD can be used on this login server via pam proxy. > Also replicating a subset of user is easy, but once you try to decide > about other data it becomes progressively more difficult, do you > replicate all the groups that are referenced by the users you > replicated ? (not possible with current fractional replication) > What about HBAC and hosts groups and sudo rules ... ? > Or do we let admins decide what to replicate and rely on referrals to > resolve missing parts referenced by the users ? > > Referrals have 2 issues: a lot of clients do not support them properly > and they would probably break the compat plugins (although I guess we > can fix the plugins to add referrals as well for the ldap part). I agree with the questions and challenges. This is something for Ondrej to research as an owner of the thesis but I would think that it should be up to the admin to define what to synch. We have a finite list of the things that we can pre-create filter for. Think about some kind of the container that would define what to replicate. The object would contain following attributes: uuid - unique rule id name - descriptive name description - comment filter - ldap filter base DN - base DN scope - scope of the search attrs - list of attributes to sync enabled - whether the rule is enabled we can define (but disable by default) rules for SUDO, HBAC, SELinux, Hosts etc and tel admin to enable an tweak. > Simo. > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-devel mailing list Freeipafirstname.lastname@example.org https://www.redhat.com/mailman/listinfo/freeipa-devel