From: Alan Pae (paedalbu@yahoo.com)
Date: Thu Oct 30 2003 - 21:06:38 EST
Thanks to:
Joco_Miguel_Chaves, Thomas M. Payerle, Michael Schulte,
Sandwich Maker, Tim Chipman, and Devin Ganger
> When you enable Kerberos, does it work like NIS, where
> when you logon, you authenticated via kerberos and
> therefore have a ticket when you land at the prompt,
> or do you logon to Solaris first, and then logon again
> to Kerberos. If the former, doesn't this blow away
> the old theory that you can only have 8 characters for
> a password? One of the docs stated that Kerberos
> passwords are from 8-255 characters.
You can have both behaviors. You can setup pam_krb5 in pam.conf so
that the user only needs to enter his password once. As an example the
pam_unix modules authenticates the user on the local machine, then
pam_krb5 module gets a kerberos ticket trying the same password, and
prompts the user for another if it fails. If you omit the pam_krb5,
then the user will have to manually request a ticket.
and
Technically, NIS passes the password around to the various machines;
Kerberos receives your password from the machine and verifies it.
In either case, this is your login to the machine itself [1 login].
Kerberos does not use crypt; the 8 character limit does not apply.
My input
I was looking over the new Sun Press book on the Secured LDAP client
included in Solaris 9, it goes through a configuration example
integrating Kerberos and LDAP.
http://www.sun.com/books/catalog/haines_bialaski_ldap.xml
> Do you really need to run OpenSSH anymore. Doesn't
> the Kerberos telnet daemon running with security do
> the same thing? Same question for ftp and scp?
> Do you need IPSec anymore, or will Kerberos provide
> for a form of network layer security?
Kerberos only encrypts the verification, not the session. The data
that moves back and forth is still un-encrypted. There is a reason that
OpenSSH/scp/IPSec may still be needed.
and
Any PAM-aware application will take advantage of Kerberos, so yes, you
get the benefits of Kerberos authentication for telnet, ftp, etc.
*HOWEVER* -- Kerberos does *not* provide point-to-point encryption, so
even though you are no longer sending auth credentials over the wire in
the clear, you are still sending the rest of the traffic in the clear
(unless the protocol explicitly provdes encryption either natively like
ssh/scp/sftp or via extensions such as SSL and TLS).
also
Kerberos provides secure authentication. It provides no network-layer
security features.
> Has anyone ever put in a feature request to move the
> buffer size of the crypt function from 8 to something
> larger, or is this a mute point.
moot. the passwd size is a function of the des algorithm crypt uses.
i believe 3des that *bsd use allows more; blowfish and md5 which linux
uses allow more.
and
This is a moot point. You can use Blowfish or MD-5 password hashing;
see the sunmanager archive for details.
Some caveat's include:
I believe, a slight kludge (unofficial, but, updated library) was
needed from sun to get the screen-lock/unlock routine to update the
kerberos ticket. AFAIK this remains an outstanding issue, ie, every
time we jumbo-patch our sunray server, we must replace the offending
library again.
Additionally, Kerberos is limited to the machines within the realm. I
can't use Kerberos to provide secure authentication to foreign systems.
With the appropriate deployment options, IPSec can be used between
enterprises, especially if the number of endpoints is small enough to
make the use of shared secrets or manual keying practical. IPSec is
also great in perimeter networks and on unsecured public interfaces to
help protect traffic, two scenarios where you wouldn't necessarily want
Kerberos machines or traffic to be.
Some things to think about include:
users login @ dtlogin (sunray environment) and thus have a kerberos
ticket that is good for <approx 12 hours>.
thus from their session, they can connect to other kerberos-aware
servers without needing to re-authenticate
we've been using openssh with built-in kerberos support as the means
for users to get consoles on other boxes. Since openssh uses kerberos
tickets transparently, no authenticaion is required if the user has a
good ticket.
Certainly, we've found kerberos to be a great thing here and would
recommend this kind of environment to others.
To sum it all up:
Kerberos is used as a Single Sign On mechanism for Applications
that support it. This sign on information is not extended
to the filesystem. I finally got that point into my head.
So you need to do a Unix logon for that using NIS, NIS+, LDAP or
files, and you need a logon to get a Kerberos ticket. By using
PAM, you might be able to accomplish this in one step.
Once you have a ticket, you don't need to use a login/password
scenario to get access to the application, as long as the application
has Kerberos support built into it.
There is no mechanism in Kerberos to encrypt the network traffic
that happens after your authenticated. OpenSSH, IPSec, internal
VPN, etc. will still be needed if you need to encrypt the data
going over the wire.
Everyone had only good things to say about using Kerberos, there
were no negative comments.
thanks to all,
alan
http://www.imdb.com/title/tt0088256/
Exclusive Video Premiere - Britney Spears
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:27:23 EDT