On Sat, 13 Jan 2007, Jeffrey Altman wrote: > I don't understand why this requires initial authentication.
Im not a kerberos wiz, but me either.. When you add a host entry to a keytab it changes the key in MIT. So the only password, I could see you needing was an admin password which the user may or may not have. The easiest way I can think of to do this is to actually just use an alternative in-memory keytab file for your program. Where is simply iterates through the real keytab file, one key at a time, and uses that single key as its keytab entry so it can't see the other keys. It can just spit back warning messages for invalid key, key doesnt exist, etc and a README with hints as to how to deal with the issues with various implementations. (Actually i think you need the host key to verify a service key so two keys after you verify the initial host keys..) Alternatively and less secure, you can just copy the keytab file and use a copy instead. If you try to "fix" the issue, then it gets a lot messier, requires passwords, admin privs, etc. Just being aware of the issue, is 50% of the battle in most cases and having directions as what to do if such and such error comes up, is another 25%. The last 25% is environmental politics. The least of which is say a policy rule, that says, you can only change your password within xxx amount of time. Which in MIT, actually means, when you create your host principal, you have changed your password, when you add the key to the host keytab, you are changing it again. Your "fix" might actually cause issues because the user might think, they fixed the issue when they really didn't and they have to wait for the time-out. -------------------------------------- Sean O'Malley, Information Technologist Michigan State University ------------------------------------- _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
