This is a discussion on Re: Windows GSSAPI ssh connection via cross-realm authenticationproblems - Kerberos ; On Aug 21, 5:36pm, "Douglas E. Engert" wrote: } Subject: Re: Windows GSSAPI ssh connection via cross-realm authentication Good day to everyone, hope the end of the week is going well. > Jason Mogavero wrote: > > > Ok, I ...
On Aug 21, 5:36pm, "Douglas E. Engert" wrote:
} Subject: Re: Windows GSSAPI ssh connection via cross-realm authentication
Good day to everyone, hope the end of the week is going well.
> Jason Mogavero wrote:
> > Ok, I should note that adding a .k5login file to the home directory of the
> > user I want to log in as did work. However, this setup won't work for
> > us in
> > the long run.
> > The ultimate goal is to have tech support reps be able to ssh into our
> > multitude of hosted web servers to perform basic troubleshooting, but we
> > have hundreds of servers and cannot reasonable manage that many local
> > databases. The idea is to use sudo for priveleges (via sudo's LDAP
> > support) and kerberos for authentication. Control over the user database
> > needs to lie entirely within the AD, hence the need for authentication
> > without the .k5login files. The non-Windows KDC needs to trust any user
> > with Windows kerberos tickets, regardless of presence of a local account.
> Its not the non-windows KDC that is that needs to have trust, it will
> issues a ticket to any user in the cross realm. It only authenticates.
> Its the local machine that needs to accepts the authentication, then
> authorize the use of the local account. the ~/.k5login is an ACL for the
> > Any suggestions as to how I might approach this?
> replace the krb5_userok routine with your own on each client. Since Windows
> also adds a PAC in the ticket, which has group info, you might be able
> to use that for some authorization decisions, looking for the support rep
> group, using some local unix account.
I'm just completing the work to make MIT 1.4.x useful when it comes to
dealing with authorization. Our extension architecture now makes the
implementation of krb5_kuserok pluggable via a shared library. It may
make it a bit easier to implement your own authorization routine if
you choose to go down that route.
I'm also working on implementing an API to make examination of the
authorization payload field pluggable. With this basic
infra-structure in place implementing authorization should be a bit
Let me know if you need patches and I can forward them along.
> Douglas E. Engert
Best wishes for a pleasant weekend.
}-- End of excerpt from "Douglas E. Engert"
Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC.
4206 N. 19th Ave. Specializing in information infra-structure
Fargo, ND 58102 development.
FAX: 701-281-3949 EMAIL: firstname.lastname@example.org
"God made man, the appendix was the result of a committee."
-- Dr. G.W. Wettstein
Guerrilla Tactics for Corporate Survival
Kerberos mailing list Kerberos@mit.edu