[33636] in Kerberos
how to "ban" clients?
daemon@ATHENA.MIT.EDU (Chris Hecker)
Sun Jul 24 04:14:03 2011
Message-ID: <4E2BD438.6070202@d6.com>
Date: Sun, 24 Jul 2011 01:13:44 -0700
From: Chris Hecker <checker@d6.com>
MIME-Version: 1.0
To: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
I want to be able to disable client accounts when necessary, even if
they currently have a live krbtgt. I understand I can't revoke live
tickets, so any existing live sessions they have will still work until
they expire, and I'm fine with that, but I don't want them to be able to
get any more tickets to new services and users.
I thought setting -allow_tix and -allow_tgs_req would do it, but I can
still get new valid tickets for services from an account with those
flags set.
The krb5kdc.log knows who's asking for the ticket, and it prints out:
Jul 24 02:45:55 blah.com krb5kdc[17432](info): TGS_REQ (4 etypes {18 17
16 23}) 1.1.1.1: ISSUE: authtime 1311493077, etypes {rep=18 tkt=18
ses=18}, a@BLAH.COM for b@BLAH.COM
even though a@BLAH.COM has:
Attributes: DISALLOW_TGT_BASED DISALLOW_ALL_TIX REQUIRES_PRE_AUTH
There must be some way to do this? I totally get the aspect of not
being able to revoke live tickets and sessions, and those having to
expire, but getting new tickets seems like something that should be
disable-able?
The -allow_tgs_req entry on man kadmin seems like it would be what I
want, since the log above says it's a TGS_REQ, but the entry says, "This
option is useless for most things." so I'm obviously misunderstanding
what it does. Yet -allow_tix only seems to prevent tickets from being
issued _FOR_ the princ with it set, so b@BLAH.COM above, which I don't
want to disable, since it's a service others will be using. I just want
a@BLAH.COM to stop working.
As a bonus, I'd like services to be able to check if a@BLAH.COM has an
enabled account, and -allow_tix seems to work for that, since if the
service tries to get a ticket for a@BLAH.COM it fails.
What am I missing?
Thanks,
Chris
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos