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
