Re: Creation of principal without password

2006-08-18 Thread Fariba
Your case is a good example. How do you allow principal creation with no 
random keys? I hope this means with no password as well.  Also with 
PKINIT, it is window's specific. right? And still user needs to have the 
password set first and then PKINIT comes to picture. right? As admin we 
want to create the users via a process and when user tries to login to 
our system, it is asked to set its password and our admin process will 
set the password in kerberos for them. But it seems kerberos cannot be a 
place holder for username without password!? And if somehow it is how 
does it handle when it comes to authentication? I see its chpassword 
needs old and new password to be specified. Even if it lets you to say 
the old password is null and does not return an error, then it is a 
security hole, since anybody with that username and null password can 
authenticate!? Thank you.

Ken Raeburn wrote:
 An administrator could change the password with kadmin's cpw command.

 This is roughly the use case I had in mind:  At a school, a registrar 
 creates accounts (including Kerberos principals) for use by the 
 students in a class, with names constructed like class 
 identifiersequence number, e.g., c101_12, with random keys (or, if 
 we allowed it, with no keys).  The realm is shared across a bunch of 
 classes.  The instructors for the class are given the ability to 
 change passwords for accounts, but not to create new accounts.  After 
 the first class, each student meets with the instructor or teaching 
 assistants, gets assigned an account id, and picks a password which is 
 set on the principal then and there by the instructor.  Probably not 
 the most convenient way of doing it, compared to, say, having the 
 registrar assign initial passwords and require that the passwords be 
 changed immediately, but it would work.


 Another no-password case would be PKINIT; if the initial tickets are 
 always acquired via PKINIT, there's no need for a password.

 Ken


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


Re: Creation of principal without password

2006-08-17 Thread Fariba
Thank you and others for replying.  If we use the randkey option to 
create the principal and do not transfer it to the keytab (if you 
transfer it to the keytab, I assume anyone typing the username is 
authenticated, so it is nor secure), is there a way to set the real 
password? Using  k_chpass  requires the knowledge of the old password, 
which when it is random we do not know it . Unless we can set the 
password to known string (even null) for the users, I do not see an 
alternative. I think I am answering myself. Seems like you cannot use 
kerberos just to store the users and later add their passwords. Any 
thoughts?
Ken Raeburn wrote:


 On Aug 17, 2006, at 06:07, ronnie sahlberg wrote:
 a principal witout its associated password would be pointless for
 kerberos since that account would not be able to use tickets that by
 definition are encrypted with a key based on said accounts password.

 Not at all... a keytab file could be generated to store the key 
 directly, without using a password.  In fact, in the MIT 
 implementation, this is the normal case for server principals.

 Theoretically, if you separated the create principal and set 
 password privileges into different groups of admins, you could create 
 a new account for a new hire, or an incoming group of students, or 
 whatever (assuming your local policy dictates how principal names are 
 formed, and doesn't give the users the option), with a random key, and 
 then let a less-privileged administrator set the password for the user 
 later.  Offhand I don't know of anyone who does it this way, but you 
 *could*...

 Ken


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


Re: Creation of principal without password

2006-08-17 Thread Fariba
Could you elaborate on that?
Ken Raeburn wrote:
 On Aug 17, 2006, at 12:20, Fariba wrote:
 Thank you and others for replying.  If we use the randkey option to 
 create the principal and do not transfer it to the keytab (if you 
 transfer it to the keytab, I assume anyone typing the username is 
 authenticated, so it is nor secure), is there a way to set the real 
 password? Using  k_chpass  requires the knowledge of the old 
 password, which when it is random we do not know it . Unless we can 
 set the password to known string (even null) for the users, I do not 
 see an alternative. I think I am answering myself. Seems like you 
 cannot use kerberos just to store the users and later add their 
 passwords. Any thoughts?

 You'd need some sort of administrator access, either through the 
 kadmin protocol, or the set/change password protocol being worked on 
 in the IETF.

 Ken




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


Creation of principal without password

2006-08-16 Thread Fariba
Is it possible to create a principal without password in kerberos? Thank 
you.


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


Re: Assertion failuers

2005-07-25 Thread fariba
seems like it worked. we have not been getting dead mureqds for a 
while(this is our application that was failing)


fariba wrote:

i relinked our other application(mureqd) with the new 2.6 (thread 
disabled) and released it,  to see if the process functions better now.


Phil Dibowitz wrote:


On Sun, Jul 10, 2005 at 03:53:40PM -0400, Sam Hartman wrote:
 


fariba == fariba  [EMAIL PROTECTED] writes:




   fariba i work with phil as well. i was wondering what are the
   fariba proc/con of using these flags:

   fariba --disable-shared --enable-static --disable-threads

It turns off threads support which gets you roughly the 1.3.x
behavior.  If miltiple threads are using the library at once you can
run into problems.  It disables shared libraries and enables static
libraries.  That means that Kerberos is linked into each application
instead of using a dynamic library.
  



BTW, I didn't disable shared libraries (we need them), but I did disable
threads.

 




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




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


Re: Assertion failuers

2005-07-11 Thread fariba


thank you. may be i should explain what o really want to know: why by 
disabling the threads our problem on 2.6 went away? why using these 
flags was suggested? is multi-threading support kind of buggy?


Sam Hartman wrote:


fariba == fariba  [EMAIL PROTECTED] writes:
   



   fariba i work with phil as well. i was wondering what are the
   fariba proc/con of using these flags:

   fariba --disable-shared --enable-static --disable-threads

It turns off threads support which gets you roughly the 1.3.x
behavior.  If miltiple threads are using the library at once you can
run into problems.  It disables shared libraries and enables static
libraries.  That means that Kerberos is linked into each application
instead of using a dynamic library.


--Sam

 




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


Re: Assertion failuers

2005-07-11 Thread fariba
i relinked our other application(mureqd) with the new 2.6 (thread 
disabled) and released it,  to see if the process functions better now.


Phil Dibowitz wrote:


On Sun, Jul 10, 2005 at 03:53:40PM -0400, Sam Hartman wrote:
 


fariba == fariba  [EMAIL PROTECTED] writes:
 


   fariba i work with phil as well. i was wondering what are the
   fariba proc/con of using these flags:

   fariba --disable-shared --enable-static --disable-threads

It turns off threads support which gets you roughly the 1.3.x
behavior.  If miltiple threads are using the library at once you can
run into problems.  It disables shared libraries and enables static
libraries.  That means that Kerberos is linked into each application
instead of using a dynamic library.
   



BTW, I didn't disable shared libraries (we need them), but I did disable
threads.

 




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


Re: Problem compiling MIT Kerberos 5 - 1.4.1 on Solaris...

2005-06-16 Thread fariba

i have resolved all the issues. exactly what is your problem?

Haskins, Russell wrote:


KernelPacket,

Did you get a resolution to this problem? I am getting the exact same
error message.

Thanks Russ...

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




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


gethostbyname, gethostbyaddr in kerberos 5-1.4.1

2005-05-31 Thread fariba


where are the host commands in netdb.h of kerberos 5-1.4.1-gssrpc? how 
can they be replaced?



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


Re: mixing sun solaris's rpc with mit's rpc

2005-05-27 Thread fariba
hostent in netdb.h seems to be changed to rpcent in  mit 1.4.1 
gssrpc/netdb.h.  in our routins we assign sockaddr_in.s_addr to 
hostent.h_addr. rpcent does not have a such entry!


Kevin Coffman wrote:

has anybody used sun's rpc  and mit's rpc in a kerborised application? 
the mit's rpc (gssrpc)  is to be used for encrypted  communication and 
the sun's rpc is used for non-encrypted communication. we have such a 
program but we want to upgrade to 5-1.4.1 version of kerberos,  but the 
header files are quite different now and we run into compilation issues. 
whereas we did not have a problem with prior kerberos releases. we use 
solaris 2.6 , 2.8 and 2.9. also anybody ever used sun's rpc and kerberos 
to  communicate with  mit's kerberos server? i appreciate the help very 
much. thank you.
   



Are you talking about differences between 1.3.x rpc headers and
1.4.1 headers?

What kind of problems are you having?  I'm looking at changes to our
version of the rpc library which we need for NFSv4.

 




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


Re: mixing sun solaris's rpc with mit's rpc

2005-05-27 Thread fariba
plus comparing solaris's netdb.h with the mit's: what should we replace 
gethostbyname, etc?

fariba wrote:

hostent in netdb.h seems to be changed to rpcent in  mit 1.4.1 
gssrpc/netdb.h.  in our routins we assign sockaddr_in.s_addr to 
hostent.h_addr. rpcent does not have a such entry!


Kevin Coffman wrote:

has anybody used sun's rpc  and mit's rpc in a kerborised 
application? the mit's rpc (gssrpc)  is to be used for encrypted  
communication and the sun's rpc is used for non-encrypted 
communication. we have such a program but we want to upgrade to 
5-1.4.1 version of kerberos,  but the header files are quite 
different now and we run into compilation issues. whereas we did not 
have a problem with prior kerberos releases. we use solaris 2.6 , 
2.8 and 2.9. also anybody ever used sun's rpc and kerberos to  
communicate with  mit's kerberos server? i appreciate the help very 
much. thank you.
  



Are you talking about differences between 1.3.x rpc headers and
1.4.1 headers?

What kind of problems are you having?  I'm looking at changes to our
version of the rpc library which we need for NFSv4.

 




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




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


Re: mixing sun solaris's rpc with mit's rpc

2005-05-26 Thread fariba
maybe i was not clear enough. the server is mit rpc/gssrpc and the 
clients are both sun rpc and mit rpc/gssrpc. the main thing is how mit 
gssrpc include files have changed and causing compilation errors.

Sam Hartman wrote:


It is almost certain that the same source file will not be able to
include both MIT's RPC and Sun's RPC.

 




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


mixing sun solaris's rpc with mit's rpc

2005-05-25 Thread fariba
has anybody used sun's rpc  and mit's rpc in a kerborised application? 
the mit's rpc (gssrpc)  is to be used for encrypted  communication and 
the sun's rpc is used for non-encrypted communication. we have such a 
program but we want to upgrade to 5-1.4.1 version of kerberos,  but the 
header files are quite different now and we run into compilation issues. 
whereas we did not have a problem with prior kerberos releases. we use 
solaris 2.6 , 2.8 and 2.9. also anybody ever used sun's rpc and kerberos 
to  communicate with  mit's kerberos server? i appreciate the help very 
much. thank you.


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