how to "ban" clients?

[Chris Hecker]

> You could modify the KDC code locally to do this if you need it. I
> don't have any other clever ideas for doing what you want.

Would you guys be interested in a patch?  It seems very strange and 
surprising--as someone just starting to learn and use Kerberos--that you 
basically can't disable an account for any new requests to the KDC since 
the ban, and the fix seems very simple.  I could put it on a profile 
bool and default it to off if that would make it easier to accept into core.

I don't understand the cross-realm authentication issue very well, 
though, since I haven't really learned that stuff yet.  I was going to 
use similar code to what's in the as_req path to generate the client and 
pass it to validate_tgs_request, hopefully that would "just work"?  Hmm, 
trying to understand this a bit more, could I just check 
is_local_principal and only do the check in that case?  I'm trying to be 
conservative here...the patch wouldn't ever allow anything the current 
code doesn't, it would just disallow more things, which seems safe? 
Although, I guess its behavior for cross-realm stuff would have to be 
documented well so nobody was misled into thinking it would ban somebody 
across realms...?  Maybe I name the profile bool something like 
check_allow_tix_for_local_client_princs to be clear...

> authentication to that principal. In 1.7 we changed the error return
> for that case to KDC_ERR_MUST_USE_USER2USER, but I haven't been able
> to find code that allows user-to-user requests to such principals.

Yeah, I looked into it a bit farther in 1.9.1 and it definitely looks 
like it would still fail even on u2u requests, which seems like bug, at 
least given the new error code for the svr case implying it should work? 
  Either that or it should be documented.

I don't think I'm qualified to fix that one unless there's some easy way 
to check if it's a u2u request in validate_tgs_request, so I'll just 
have to leave them +allow_svr for now.  I'll look at it more when I'm 
fixing the allow_tix one.  Hmm, wait, poking around more, it looks like 
the if should just be something like this:

     /* Server must be allowed to be a service */
     if (isflagset(server.attributes, KRB5_KDB_DISALLOW_SVR) &&
         !isflagset(request->kdc_options, KDC_OPT_ENC_TKT_IN_SKEY)) {
         *status = "SERVER NOT ALLOWED";
         return(KDC_ERR_MUST_USE_USER2USER);
     }

Thanks for putting up with all my mails!
Chris


On 2011/07/24 14:02, Greg Hudson wrote:
> On Sun, 2011-07-24 at 05:00 -0400, Chris Hecker wrote:
>> More details from looking at the kdc code...it looks like
>> validate_tgs_request in kdc_util.c only checks the server's attributes
>> for KRB5_KDB_DISALLOW_ALL_TIX, while validate_as_request checks both
>> client and server.  It seems like it'd be easy to add the client check
>> to validate_tgs_request, but I'd also have to get the client db entry in
>> do_tgs_req.
>
> For performance reasons and because of cross-realm authentication, we
> don't look up the client principal for TGS requests.  That does mean
> it's impossible to deny TGS requests based on updated database state for
> the client.
>
> You could modify the KDC code locally to do this if you need it.  I
> don't have any other clever ideas for doing what you want.
>
> As for -allow_svr, I think you would want to set that on your user
> principals (earlier I suggested -allow_tgs_req, but that's the wrong
> flag, since it wouldn't prevent someone from making an AS req to another
> user principal and performing an offline dictionary attack).  However, I
> think you're right that it would conflict with user-to-user
> authentication to that principal.  In 1.7 we changed the error return
> for that case to KDC_ERR_MUST_USE_USER2USER, but I haven't been able to
> find code that allows user-to-user requests to such principals.
>
>
>
>