Re: Windows GSSAPI ssh connection via cross-realm authentication problems
- From: greg@xxxxxxxxxxxx
- Date: Fri, 25 Aug 2006 10:09:52 -0500
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.
Good.
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
account.
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
more tenable.
Let me know if you need patches and I can forward them along.
Douglas E. Engert <DEEngert@xxxxxxx>
Best wishes for a pleasant weekend.
}-- End of excerpt from "Douglas E. Engert"
As always,
Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC.
4206 N. 19th Ave. Specializing in information infra-structure
Fargo, ND 58102 development.
PH: 701-281-1686
FAX: 701-281-3949 EMAIL: greg@xxxxxxxxxxxx
------------------------------------------------------------------------------
"God made man, the appendix was the result of a committee."
-- Dr. G.W. Wettstein
Guerrilla Tactics for Corporate Survival
________________________________________________
Kerberos mailing list Kerberos@xxxxxxx
https://mailman.mit.edu/mailman/listinfo/kerberos
.
- Prev by Date: Re: kadmin on windows
- Next by Date: sshd, Tiger and KRB5CCNAME
- Previous by thread: Re: Windows GSSAPI ssh connection via cross-realm authentication problems
- Next by thread: kpasswd: Failed decrypting request
- Index(es):
Relevant Pages
|
