Re: GSSAPI SSH WIN 2003
From: Richard E. Silverman (res_at_qoxp.net)
Date: 29 Jul 2005 19:31:16 -0400
> What I am looking for is:
> AllowGroups/AllowUsers/DenyUsers based on their type of authentication.
> DenyUsers GSSAPI *
> AllowGroups GSSAPI my_friends
OpenSSH does not have this flexibility. In fact, I don't know of any SSH
server that does; it is one of the most long-standing inadequacies of most
SSH software, IMO. Authorization is usually completely ad-hoc and full of
random pointless restrictions -- e.g. most of the fine-grained
authorization controls in OpenSSH are only available if the client has
used publickey authentication, for the simple reasons that it's
implemented with options in the authorized_keys file.
Tectia took a step in the right direction with its
ExternalAuthorizationProgram option -- but even that is inadequate as it
stands, as the server passes very little information to the program! It
doesn't even distinguish between authid and authzid, let alone specify the
authentication method used.
I recall some talk early on about using KeyNote in OpenSSH, but don't know
what the status of that is.
> Other option for me, restrict at service ticket level from Windows AD
> 2003 level. I am not sure how and is it possible?
> Say i have global group in AD called "my friends":
> Add my friends to "my friends" group and only users in "my friends"
> group will get Service ticket for my HP-UX box.
I don't know if the Windows KDC can do this, but KDCs generally don't,
because this isn't the right way to address this need. The term "service
ticket" is misleading: it sounds as if the ticket provides permission to
use the service, i.e. authorization. It doesn't. The purpose of Kerberos
is authentication: the service ticket merely identifies one principal to
another, in this case authenticating a user to a server. The server's
decision of whether to allow the user access, once identified, is
authorization -- a completely separate process. Sure, you can deny
someone access to a service by refusing them authentication, but it's a
bit heavy-handed and causes other problem. As a scheme it happens to work
better with Kerberos than other systems due to the per-service
credentials, but still, it's not usually done.
-- Richard Silverman email@example.com