[Freeipa-users] Limiting Host access by UID/GID

[Chandan Kumar]

Sorry for late reply. Thanks for helping out. Yes after deleting the sssd
cache from /var/lib it does not allow user groups outside min/max_id.


Thanks
Chandan

On Tuesday, June 4, 2013, Jakub Hrozek wrote:

> On Fri, May 31, 2013 at 08:50:29AM -0700, Chandan Kumar wrote:
> > As far as my understanding goes it does not stop even if I disable cache
> > credentials. I set following parameters in sssd.conf but still UID 20000
> is
> > able to login.
> >
>
> Sorry, there was some terminology confusion. I didn't ask for disabling
> cache credentials, but removing the on-disk cache and starting afresh.
>
> The cache is stored in /var/lib/sss/db/cache_$domname.ldb, so you can mv
> or rm it and check again if the IDs are still allowed.
>
> > cache_credentials = False
> > krb5_store_password_if_offline = False
> > min_id=5000
> > max_id=5010
> > enumerate = False
> > entry_cache_timeout=3
> >
> > Package Info:
> > Client;
> > sssd-client-1.9.2-82.7.el6_4.x86_64
> >
> > Server:
> > ipa-server-2.2.0-16.el6.x86_64
> >
> > Thanks
> > Chandan
> >
> > On Friday, May 31, 2013, Jakub Hrozek wrote:
> >
> > > 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 at 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 at 10.2.3.105 <mailto:kchandan at 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 at redhat.com
> > > <https://www.redhat.com/mailman/listinfo/freeipa-users>



-- 

--
http://about.me/chandank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20130605/63b96252/attachment.htm>