f



RE: MIT Kerberos and Solaris 10 Kerberos #3

Thanks for the response. Please see inline...

> In Solaris 10, all of the Kerberos services are already bundled,
> there is no longer any external packages that need to be added.

Right.

> Whoever told you 'ksu' was part of the encryption kit was mistaken,
> ksu has never been part of SEAM.

OK, thanks for that clarification. It was a bit of a surprise to me when
I was told it was there. So, does the Solaris 10 SEAM have any
functionality similar to ksu, or just the standard su command?

> The encryption kit for Solaris 10 enhances the overall crypto
> capabilities of the system, the only benefit Kerberos gets is
> that it can support AES-256 with the S10 encryption kit.
> Without the S10 encryption kit, the strongest AES crypto
> available for Kerberos in S10 is AES-128.

And this fits more with what I understood, before my co-worker's
comments.

> On the S10 system, you must make sure to enable the "eklogin" service.
> Run this command (as root):
> 
> # svcadm enable eklogin

Hmm. That may be a good part of my problem. I added the inetd.conf entry
for the old (MIT) eklogin, and ran inetconv. So, this is probably really
confusing the system. I'll try to revert that, and do the svcadm.

> For Solaris 8 with the SEAM rlogin daemon, make sure your 
> inetd.conf entries
> are correct.   

We don't actually run SEAM on any Sol8 systems; it's all MIT.

> Don't bother with inetd.conf in S10, S10 uses 
> the new SMF
> system for managing services (its very nice once you get used to it).

I'm still getting used to it, but I like it. I just wish there was more
info on how to convert from old-style to new-style (beyond running
inetconv -i inetd.conf).

> You indicated below that you are using and MIT kerberos KDC on the
> Solaris 8 systems.  So, the key to making things work with the S8
> SEAM kerberos clients is to make sure that the host principals
> for those Solaris 8 systems are only issued DES keys.   The rlogin
> servers in SEAM only support DES since that is all that was
> available when the S8 SEAM packages were created.
> 
> 'kadmin -q 'addprinc -e des-cbc-md5:normal host/foo.bar.com"'
> 'kadmin -q 'ktadd -e des-cbc-md5:normal host/foo.bar.com"'
> 
> (Im not sure if the syntax for those commands is exactly correct,
> but you get the idea).
> 
> Solaris 10 systems can be issued AES keys (AES-128 if the encryption
> package is not installed, AES-256 otherwise) or RC4, 3DES, or DES.

Can we force the Sol10 box to only use DES, to be compatible with the
Sol8/MIT systems (which is everything but the one Sol10 box)?

> SSH in Solaris 10 does support GSSAPI authentication and ticket
> forwarding, you may need to enable debugging to get more information
> about why the GSS auth is failing (ssh -vvv  hostname).   If the host
> keys on S10 are AES-256, but the system doesnt have the enhanced
> crypto package, then that may be causing the failure, but I would
> check the debug output from ssh first.

OK, thanks. I'll poke harder at this once I have the previous issues
resolved. I'll make SSH a separate problem. (I think I can do that...)

> > Solaris 10, SEAM going one way, Solaris 8/MIT going the other.
> 
> We have tested this and it does work, but you have to make sure
> that the S8 system has only DES keys.

All Solaris 8 systems are MIT, so if I understood your earlier comments,
they already are DES; is that correct?

> > Solaris 8, MIT for rlogind in one direction, and Solaris 
> 10/SEAM in the
> > other. Typically, I am SSH'ing in to the Solaris 10 system initially
> > (from our production lab) and then trying to rlogin to the 
> Solaris 8/MIT
> > systems in the test lab (where the Solaris 10 system sits). 
> I have also
> > SSH'd to a test lab Solaris 8/MIT system, and tried to rlogin to the
> > Solaris 10/SEAM system.
> 
> All of this should work, start by getting detailed log 
> information from the
> SSH session to see why that part is failing.

Thank you for all of the help. I'll look at correcting the eklogin
service first, and move down the list from there. :-) Answers to the
above questions/clarifications will be greatly appreciated along the
way. :-)

Thanks again.
Rainer

________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

0
1/11/2005 7:01:02 PM
comp.protocols.kerberos 5541 articles. 1 followers. jwinius (31) is leader. Post Follow

2 Replies
981 Views

Similar Articles

[PageSpeed] 59

Heilke, Rainer wrote:

>>You indicated below that you are using and MIT kerberos KDC on the
>>Solaris 8 systems.  So, the key to making things work with the S8
>>SEAM kerberos clients is to make sure that the host principals
>>for those Solaris 8 systems are only issued DES keys.   The rlogin
>>servers in SEAM only support DES since that is all that was
>>available when the S8 SEAM packages were created.
>>
>>'kadmin -q 'addprinc -e des-cbc-md5:normal host/foo.bar.com"'
>>'kadmin -q 'ktadd -e des-cbc-md5:normal host/foo.bar.com"'
>>
>>(Im not sure if the syntax for those commands is exactly correct,
>>but you get the idea).
>>
>>Solaris 10 systems can be issued AES keys (AES-128 if the encryption
>>package is not installed, AES-256 otherwise) or RC4, 3DES, or DES.
> 
> 
> Can we force the Sol10 box to only use DES, to be compatible with the
> Sol8/MIT systems (which is everything but the one Sol10 box)?

If you are using MIT Kerberos on the Solaris 8 systems (including
pam_krb5 made for MIT, not the one that comes with SEAM), then
you should not worry about the enctypes because MIT already
supports all of the enctypes that S10 supports.

The only time you need to worry about enctypes is when you
are using pre-S10 systems with SEAM apps.  IN that situation,
ONLY the pre-solaris 10 systems need to have the DES keys,
it is perfectly acceptable for the S10 systems to have AES
and S8/S9 to have DES.   This should not affect interop if
your keytabs are correctly populated on the pre-S10 boxes.


>>
>>We have tested this and it does work, but you have to make sure
>>that the S8 system has only DES keys.
> 
> 
> All Solaris 8 systems are MIT, so if I understood your earlier comments,
> they already are DES; is that correct?
> 

Not necessarily.    If your S8 systems are MIT, then you don't
really need to worry much about the enctype support because
MIT has support for all enctypes (DES through AES-256).

You may run into problems if you try and mix/match the S8 SEAM
apps with S8 MIT stuff.   For example, the dtlogin problem
you mentioned - if dtlogin is using the SEAM pam_krb5 library,
then you must make sure that the host principals on that
S8 system have only DES keys.

If you use a 3rd party pam_krb5 library that links with MIT
Kerberos, then you should not have any enctype issues on
Solaris 8.

You may be seeing problems on your S8 systems because
you have a mixture of MIT Kerberos apps (with full enctype
support) and S8/SEAM Kerberos apps (which only support DES).


-Wyllys
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

0
1/11/2005 7:11:29 PM
But IIRC the Solaris "su" can use PAM, and thus could use pam_krb5 or
some other PAM routine to acomplish the same thing as the MIT su?


Heilke, Rainer wrote:

> Thanks for the response. Please see inline...
> 
> 
>>In Solaris 10, all of the Kerberos services are already bundled,
>>there is no longer any external packages that need to be added.
> 
> 
> Right.
> 
> 
>>Whoever told you 'ksu' was part of the encryption kit was mistaken,
>>ksu has never been part of SEAM.
> 
> 
> OK, thanks for that clarification. It was a bit of a surprise to me when
> I was told it was there. So, does the Solaris 10 SEAM have any
> functionality similar to ksu, or just the standard su command?
> 
> 
>>The encryption kit for Solaris 10 enhances the overall crypto
>>capabilities of the system, the only benefit Kerberos gets is
>>that it can support AES-256 with the S10 encryption kit.
>>Without the S10 encryption kit, the strongest AES crypto
>>available for Kerberos in S10 is AES-128.
> 
> 
> And this fits more with what I understood, before my co-worker's
> comments.
> 
> 
>>On the S10 system, you must make sure to enable the "eklogin" service.
>>Run this command (as root):
>>
>># svcadm enable eklogin
> 
> 
> Hmm. That may be a good part of my problem. I added the inetd.conf entry
> for the old (MIT) eklogin, and ran inetconv. So, this is probably really
> confusing the system. I'll try to revert that, and do the svcadm.
> 
> 
>>For Solaris 8 with the SEAM rlogin daemon, make sure your 
>>inetd.conf entries
>>are correct.   
> 
> 
> We don't actually run SEAM on any Sol8 systems; it's all MIT.
> 
> 
>>Don't bother with inetd.conf in S10, S10 uses 
>>the new SMF
>>system for managing services (its very nice once you get used to it).
> 
> 
> I'm still getting used to it, but I like it. I just wish there was more
> info on how to convert from old-style to new-style (beyond running
> inetconv -i inetd.conf).
> 
> 
>>You indicated below that you are using and MIT kerberos KDC on the
>>Solaris 8 systems.  So, the key to making things work with the S8
>>SEAM kerberos clients is to make sure that the host principals
>>for those Solaris 8 systems are only issued DES keys.   The rlogin
>>servers in SEAM only support DES since that is all that was
>>available when the S8 SEAM packages were created.
>>
>>'kadmin -q 'addprinc -e des-cbc-md5:normal host/foo.bar.com"'
>>'kadmin -q 'ktadd -e des-cbc-md5:normal host/foo.bar.com"'
>>
>>(Im not sure if the syntax for those commands is exactly correct,
>>but you get the idea).
>>
>>Solaris 10 systems can be issued AES keys (AES-128 if the encryption
>>package is not installed, AES-256 otherwise) or RC4, 3DES, or DES.
> 
> 
> Can we force the Sol10 box to only use DES, to be compatible with the
> Sol8/MIT systems (which is everything but the one Sol10 box)?
> 
> 
>>SSH in Solaris 10 does support GSSAPI authentication and ticket
>>forwarding, you may need to enable debugging to get more information
>>about why the GSS auth is failing (ssh -vvv  hostname).   If the host
>>keys on S10 are AES-256, but the system doesnt have the enhanced
>>crypto package, then that may be causing the failure, but I would
>>check the debug output from ssh first.
> 
> 
> OK, thanks. I'll poke harder at this once I have the previous issues
> resolved. I'll make SSH a separate problem. (I think I can do that...)
> 
> 
>>>Solaris 10, SEAM going one way, Solaris 8/MIT going the other.
>>
>>We have tested this and it does work, but you have to make sure
>>that the S8 system has only DES keys.
> 
> 
> All Solaris 8 systems are MIT, so if I understood your earlier comments,
> they already are DES; is that correct?
> 
> 
>>>Solaris 8, MIT for rlogind in one direction, and Solaris 
>>
>>10/SEAM in the
>>
>>>other. Typically, I am SSH'ing in to the Solaris 10 system initially
>>>(from our production lab) and then trying to rlogin to the 
>>
>>Solaris 8/MIT
>>
>>>systems in the test lab (where the Solaris 10 system sits). 
>>
>>I have also
>>
>>>SSH'd to a test lab Solaris 8/MIT system, and tried to rlogin to the
>>>Solaris 10/SEAM system.
>>
>>All of this should work, start by getting detailed log 
>>information from the
>>SSH session to see why that part is failing.
> 
> 
> Thank you for all of the help. I'll look at correcting the eklogin
> service first, and move down the list from there. :-) Answers to the
> above questions/clarifications will be greatly appreciated along the
> way. :-)
> 
> Thanks again.
> Rainer
> 
> ________________________________________________
> Kerberos mailing list           Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 
> 
> 

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

0
deengert (574)
1/11/2005 9:49:52 PM
Reply: