Kerberos Digest, Vol 44, Issue 32

[Jason Mogavero]

The lightbulb kind of came on about that after I sent off that email.  Your
clarification certainly helped cement that.  I'm going to be using
samba/winbind to provide authorization and access to local priveleges.

Just a question, though, I have one account in the non-windows KDC that can
log into the ssh server via gssapi and it does not have a .k5login file in
it's home directory...does this work because I have a user principal in the
non-windows KDC?  If I were to add user accounts for the Active Directory as
principals to the non-windows KDC, would the behavior be the same?  What I
want to avoid is having to create home directories on all of our servers for
our tech support staff just to store a .k5login file.

Thanks for the input



Date: Tue, 22 Aug 2006 22:30:50 GMT
> From: Jeffrey Altman <jaltman2 at nyc.rr.com>
> Subject: Re: Windows GSSAPI ssh connection via cross-realm
>         authentication
> To: kerberos at MIT.EDU
> Message-ID: <uALGg.16670$rI5.6304 at news-wrt-01.rdc-nyc.rr.com>
>
> Jason:
>
> I think you misunderstand the role of Kerberos here.  Kerberos is being
> using to authenticate the user by name.  If the SSH service is in realm
> "A.EXAMPLE.COM" and the user is in realm "B.EXAMPLE.COM", the after
> successful authentication the SSH service knows the name as something
> like "name at B.EXAMPLE.COM".  The question that then must be answered is
> this:
>
>    Is name at B.EXAMPLE.COM authorized to access this account on this
>    machine?
>
> The answer to that question is an authorization decision and it is made
> independently of the KDCs for A.EXAMPLE.COM.  The default method
> provided in the Kerberos libraries is to perform a lookup in a file
> ~/.k5login to see if the authenticated name is listed.  You can replace
> this mechanism with one of your own choosing but it requires that the
> Kerberos function krb5_kuserok() not be used to make the authorization
> decision by the application.
>
> Jeffrey Altman
>
>
>
>