On 1/7/2010 11:48 AM, Jeff Blaine wrote: > Jeffrey, > > I ended up solving my issues by forceably finding and removing > all traces of anything related to KfW after "uninstall with > no config saving" -- and reinstalling. > > [ I consider it a bug that 'uninstall' does not clean up the ] > [ registry when I've said not to keep my "configuration" info. ] File a bug with MIT. > > I don't know what the problem was. Oh well. Depending on which keys you are talking about, the per user configuration data is never removed by an uninstaller since the uninstaller doesn't have access to the per user data. Not all users may be logged into the machine. > > I'd love to be a tester, but unfortunately I need to run the > version our users have in order to troubleshoot things. Without being a tester, you won't be able to ensure that the next release works the way you want it to in your environment. Unless you are providing funding or some in-kind assistance in the development, why should I spend my time answering your e-mails when you have trouble? > > Aside, is there a reason for the 2-step credential obtaining > process where the account is 'checked' then one is given a > password text entry field? It's clunky to interact with. In NIM v1.x the account's existence is verified before prompting for a password in order to protect against users that typo the username or realm and created an identity in the database that in fact does not exist.
In NIM v2, identities are created by a wizard that walks the user through the configuration of all applicable credential providers. After the identity is created the user simply selects one of the pre-configured ones instead of manually typing the username and realm each time. This change is both to improve usability but also to permit NIM v2 to be used with X.509 and Keystore identities in addition to Kerberos v5. > > Another aside, what release will have krb4 cred obtaining > disabled by default? Any release you want. As I have said before, you can use a transform to configure the MSI installer to disable Kerberos v4. You can do this today. >> What I would do is use "Network Monitor v3.2" from Microsoft Connect to >> examine the network traffic and see what requests are failing to receive >> responses. > > FWIW 3.3 is out > > Looks like a nice tool. I may ditch put Ethereal in the attic. They each have their own strengths and weaknesses. Ethereal can be used to decrypt encrypted traffic and has AFS support. NetMon does a much better job of analyzing and displaying conversations.
________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
