In article [EMAIL PROTECTED],
Ryan Odgers [EMAIL PROTECTED] wrote:
If the KDC is win2000 and the kerberos client is UNIX or MIT, does
cross-realm authentication still need to be set up?
It is the same kerberos realm, the unix machine points to the 2000 KDC as
its server.
we have done this
Henry B. Hotz [EMAIL PROTECTED] writes:
At 9:07 PM +0100 1/22/04, Harald Barth wrote:
I think that OpenSSL != OpenSSH.
Correct. I got the install order wrong. The right order is OpenSSL,
Heimdal, OpenSSH.
Harald.
OK, so how do you install OpenSSL with RFC 2712 support enabled?
build
In message [EMAIL PROTECTED] on Mon, 26 Jan 2004 10:03:01 +0100, Love [EMAIL
PROTECTED] said:
lha
lha Henry B. Hotz [EMAIL PROTECTED] writes:
lha
lha At 9:07 PM +0100 1/22/04, Harald Barth wrote:
lhaI think that OpenSSL != OpenSSH.
lha
lha Correct. I got the install order wrong. The
Hi,
I try to arrange an environment, where users can logon to a
Kerberos realm from Windows 2000 workstations via smartcard logon.
I've already reached a point where normal password logon works from
Windows workstations to the Kerberos realm, and the smartcard logon
works from the Windows
Ryan Odgers wrote:
I have AD users corresponding to the services eg. telnet and ftp and have
used ktpass to generate the following principals.
telnet/[EMAIL PROTECTED]
ftp/[EMAIL PROTECTED]
I just get lost in how to get a ticket from windows to use that service. if
i am on the unix machine
Robert,
For this to work, the UNIX KDC needs to support the PKINIT standard at the same draft
level as Microsoft (I believe this is draft 9). Do you know if your KDC supports
PKINIT ?
Thanks, Tim.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 26 January
Rather then implementing kafs in MIT Kerberos, I would like to
suggest an alternative which has advantages to all parties.
The OpenSSH sshd needs to do two things:
(1) sets a PAG in the kernel,
(2) obtains an AFS token storing it in the kernel.
It can use the Kerberos credentials
Jeffrey Altman wrote:
Douglas E. Engert wrote:
In its simplest form, all that is needed is:
system(/usr/ssh/libexec/aklog -setpag)
You would probably want this to be a configurable option in the sshd
configuration file
as opposed to have a fixed name, location and options which
Ben Lindstrom wrote:
I hate to derail this, but in the short term unless the code appears
perfect in the next looks down at his watch two hours, and is blessed
by all parties involved and is extremely simple and small. The chances
it will be including in this release of OpenSSH are zero.
I don't disagree with your proposal at all. Sounds good. It should
make it easier to fix/change things in the future.
But. . .
Isn't the reason this keeps coming up that AFS client doesn't
(can't?) behave like a normal Kerberos application and just get it's
own service ticket when it needs
On Mon, 2004-01-26 at 12:03, Douglas E. Engert wrote:
Ben Lindstrom wrote:
I'd perfer if we could test and ensure this release of OpenSSH can get out
the door without the B-But It does not work with XYZ common
configuration that seems to always crop up with KRB/AFS in general.
Henry B. Hotz wrote:
I don't disagree with your proposal at all. Sounds good. It should
make it easier to fix/change things in the future.
But. . .
Isn't the reason this keeps coming up that AFS client doesn't
(can't?) behave like a normal Kerberos application and just get it's
own
On Monday, January 26, 2004 11:23:34 -0800 Henry B. Hotz
[EMAIL PROTECTED] wrote:
Isn't the reason this keeps coming up that AFS client doesn't (can't?)
behave like a normal Kerberos application and just get it's own service
ticket when it needs one (based on an existing tgt)? The real reason
We have implemented the strategy similar to the one that Douglas suggested
in his posting. In our case (Heimdal) we allow user to login using his/her
K5 password and then call Heimdal afslog inside session.c:
system(/usr/sshutils/sbin/afslog /dev/null 21);
A small complementary trick
Does your ssh_config file have:
GSSAPIDelegateCredentials yes
or you need to specify on the command line. -o
Andrei Maslennikov wrote:
Hi Douglas, and thanks for your comment.
On Mon, 26 Jan 2004, Douglas E. Engert wrote:
1) ssh to host A, login with K5 password (and obtain a
On Mon, 26 Jan 2004, Douglas E. Engert wrote:
Does your ssh_config file have:
GSSAPIDelegateCredentials yes
Douglas, tons of thanks! This worked.
Everything has now became smooth and clean.
Greetings - Andrei.
Kerberos mailing list
Hi Douglas, and thanks for your comment.
On Mon, 26 Jan 2004, Douglas E. Engert wrote:
1) ssh to host A, login with K5 password (and obtain a PAG-based token)
Was the ticket marked forwardable? Can you set with Hiemdal in the
krb5.conf file a default that tickets should be forwardable?
On Monday, January 26, 2004 17:17:46 -0500 Dean Anderson [EMAIL PROTECTED]
wrote:
On Mon, 26 Jan 2004, Jeffrey Hutzelman wrote:
Worse, it would not solve the problem. The trouble here is not that AFS
tokens are stored in a kernel data structure instead of a file. It's
that they are indexed
Dean Anderson wrote:
Right. And there is an easy solution: Turn off Privsep. A process that
creates new user sessions needs root privileges, and those privileges
cannot be given away prematurely to improve security. Privsep is just a
stupid idea for some programs. Probably for most
Jeffrey Hutzelman wrote:
On Monday, January 26, 2004 17:17:46 -0500 Dean Anderson [EMAIL PROTECTED]
wrote:
On Mon, 26 Jan 2004, Jeffrey Hutzelman wrote:
Worse, it would not solve the problem. The trouble here is not that AFS
tokens are stored in a kernel data structure instead of a file. It's
On Mon, 26 Jan 2004, Jeffrey Hutzelman wrote:
Worse, it would not solve the problem. The trouble here is not that AFS
tokens are stored in a kernel data structure instead of a file. It's that
they are indexed by a value which must be set on login, inherited from each
process by its
21 matches
Mail list logo
