2005-03-22 15:39:26

by mehta kiran

[permalink] [raw]
Subject: Re: problem mounting using NFSv4 when using -o sec=krb5 option

Hi Kevin ,
This are some of the lines from your previos mails.
Sorry , but i could not digest this lines.
------------------

if you create a principal using a password, you should
be able to
authenticate as that pricipal using that password.
However, once you
do a ktadd for that principal the password will no
longer work. See my
previous message about what ktadd does.



P.S. Here is what the ktadd command does:
- It generates a new random key value for the
principal (with a new key version)
- It puts this new key into the Kerberos DB, replacing
any previous key with a lower kvno
- It puts this new key into the keytab file that was
specified

Therefore, each time you run ktadd, the old keytab
entry
becomes obsolete.
---------------------
Why(reason)should password become ineffective after
ktadd ?And if that is the case , why does it ask for
password during addprinc? continuing with this:what is
use of this password then?

thanks,
--kiran







__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/


-------------------------------------------------------
This SF.net email is sponsored by: 2005 Windows Mobile Application Contest
Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones
for the chance to win $25,000 and application distribution. Enter today at
http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs


2005-03-22 16:13:10

by Kevin Coffman

[permalink] [raw]
Subject: Re: problem mounting using NFSv4 when using -o sec=krb5 option

By convention, when creating a _service principal_, the addprinc
"-randkey" option is used. This option says to generate a random value
for the initial key instead of prompting for a password.

When you do a ktadd, a new random key for that principal is generated
and put into both the Kerberos Database and the keytab file. Any
previous keys for that principal become obsolete, including any keys
generated from a password.

So, giving a password when creating a _service principal_ is useless
because the key generated from that password becomes obsolete as soon
as the ktadd command is done.


> Hi Kevin ,
> This are some of the lines from your previos mails.
> Sorry , but i could not digest this lines.
> ------------------
>
> if you create a principal using a password, you should
> be able to
> authenticate as that pricipal using that password.
> However, once you
> do a ktadd for that principal the password will no
> longer work. See my
> previous message about what ktadd does.
>
>
>
> P.S. Here is what the ktadd command does:
> - It generates a new random key value for the
> principal (with a new key version)
> - It puts this new key into the Kerberos DB, replacing
> any previous key with a lower kvno
> - It puts this new key into the keytab file that was
> specified
>
> Therefore, each time you run ktadd, the old keytab
> entry
> becomes obsolete.
> ---------------------
> Why(reason)should password become ineffective after
> ktadd ?And if that is the case , why does it ask for
> password during addprinc? continuing with this:what is
> use of this password then?
>
> thanks,
> --kiran
>
>
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Small Business - Try our new resources site!
> http://smallbusiness.yahoo.com/resources/




-------------------------------------------------------
This SF.net email is sponsored by: 2005 Windows Mobile Application Contest
Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones
for the chance to win $25,000 and application distribution. Enter today at
http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs