On Fri, May 31, 2013 at 09:26:40AM -0400, Simo Sorce wrote:
> On Fri, 2013-05-31 at 11:55 +0200, Jakub Hrozek wrote:
> > On Thu, May 30, 2013 at 07:23:38PM -0400, Dmitri Pal wrote:
> > > On 05/30/2013 06:52 PM, Chandan Kumar wrote:
> > > > Hello,
> > > >
> > > > As part of migration from passwd/shadow to IPA, I want to roll out
> > > > IPA/SSSD based password first for a small number of users and then for
> > > > all. (same goes with host. first small number of host and then all).
> > > >
> > > > I was trying to limit it using max_id/min_id parameters in sssd but it
> > > > does not seems to work the way I expected.
> > > > -------
> > > > min_id = 5000
> > > > max_id = 5100
> > > > ------
> > > > So there is a user "kchandan" with UID/GID 20000
> > > > ------
> > > > [root@tipa1 ~]# id kchandan
> > > > uid=20000(kchandan) gid=20000 groups=20000
> > > > -------
> > > >
> > > > But It is allowing me to login with that ID with only error showing
> > > > GID 20000 not found.
> > > > -----------
> > > > ssh 10.2.3.105 -l kchandan
> > > > kchandan@10.2.3.105 <mailto:kchandan@10.2.3.105>'s password: 
> > > > id: cannot find name for group ID 20000
> > > > -------------
> > > >
> > > > Is there any way to achieve this?
> > > 
> > > So you want to allow only a subset of users with a specific range to log
> > > into the systems controlled by SSSD before you open it to a broader 
> > > public?
> > > I would defer to SSSD gurus but the hack that comes to mind is to
> > > configure a simple access provider to limit the access to just the users
> > > you care about (man sssd-simple) or configure ldap access provider based
> > > on a filter (man sssd-ldap).
> > 
> > Hi,
> > 
> > The user shouldn't be even saved to cache if it's filtered out of range.
> > 
> > But looking at the current NSS code, the entry would have been returned if
> > it was saved *before* you changed the min_id/max_id parameters. Could that 
> > be
> > the case? Can you check if after removing the cache the entry still shows 
> > up?
> > 
> > I think that the fact that the entry is returned from cache even if it
> > should be filtered out is a bug:
> > https://fedorahosted.org/sssd/ticket/1954
> 
> So far we always maintained that if you consistently change
> configuration (and a change of ranges is a big change) then it's on the
> admin to wipe the cache file.

Yes, that's why the ticket is minor. But mostly I don't like the
inconsistency where some requests check the ranges even in the responder
and some don't.

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

Reply via email to