The reason that [EMAIL PROTECTED] is able to login to account "user" via SSH is because the SSH service exists in the realm A.EXAMPLE.COM. Therefore, [EMAIL PROTECTED] is assumed to be the same entity as "user".
The same assumption cannot be made for [EMAIL PROTECTED] Jeffrey Altman Jason Mogavero wrote: > 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 <[EMAIL PROTECTED]> >> Subject: Re: Windows GSSAPI ssh connection via cross-realm >> authentication >> To: [email protected] >> Message-ID: <[EMAIL PROTECTED]> >> >> 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 "[EMAIL PROTECTED]". The question that then must be answered is >> this: >> >> Is [EMAIL PROTECTED] 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 >> >> >> >> > ________________________________________________ > Kerberos mailing list [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
