Long Summary: Kerberos Questions

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