Picking up a couple of pieces of this thread:
> Date: Tue, 25 Sep 2007 12:33:24 -0400 > From: Sam Hartman <[EMAIL PROTECTED]> > > Jeff, what we're trying to do here is determine what customers want. > In particular we're trying to determine how likely it is that the > windows username will match the kerberos username in cases where the > NIM credentials dialogue is used. IN particular I'd like to exclude > cases where MSLSA is used. I'm not certain what you mean by "exclude" so let me answer it as completely as I can and hopefully some of it is what you are looking for: At Stanford I'd estimate roughly 20% of the Windows machines are joined to an Active Directory domain, the vast majority of which are joined to our centrally run offering. The namespace between our Windows AD and our MIT Kerberos realm is synchronized. Any exceptions would be almost certainly be an isolated workgroup that setup their own AD domain and didn't properly plan. For the remaining ~80% of machines that are using local accounts it's much more of a toss up as to whether the local account name will match the Kerberos principal. It is a recommended best practice and I think it's fair to say that for department-deployed machines the two would match a majority of the time. For privately owned machines it is less likely, but there has always been a strong interest in single sign-on from our users and we frequently will assist users with changing their local account name to match their Kerberos principal for this reason. > Date: Tue, 25 Sep 2007 14:19:06 -0400 > From: Sam Hartman <[EMAIL PROTECTED]> > >>>>>> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes: > > Russ> Jeff's analysis is correct for Stanford University: > Russ> "Kerberos" as a label is likely to be confusing to our less > Russ> technical users. We use an internal branding of "SUNet ID" > Russ> for a variety of reasons and many users don't know and don't > Russ> care what authentication technology is behind it. > > Interesting. We've been branding KFM as Kerberos for years and > haven't run into trouble. > > I think we'd definitely be very interested in discussing this issue > with users who think it would be harmdful. > Could you forward this to the appropriate folks at Stanford for > such a discussion? I manage the second tier help desk in the Client Support organization at Stanford, so I'm appropriate folk. From a user experience perspective I don't think mentioning Kerberos would be harmful, but I also don't think it would be helpful in solving this *theoretical* problem: > "Kevin Koch" <[EMAIL PROTECTED]> writes: > >> MIT support staff believe that users will try to obtain >> credentials and >> fail, whenever the Windows username isn't the same as the Kerberos >> username. I've worked with quite a few users where this initial NIM login window appeared with the local username (in cases where it didn't match the Kerberos principal) entered by default. In the vast majority of cases users knew to change the username. In the few cases where they did not and were unable to login, the user quickly caught the problem themselves and corrected the username. I do not believe changing the text to "Kerberos username" would have reduced the few number of errors. The errors occurred not because the user didn't know their username, but because they didn't read it. If they didn't read the username, they aren't going to read the label for the username field. I think your comparison to Kerberos for Macintosh supports this--the initial login with KfM autofills the local account name, just as NIM does. I don't ever remember getting a support case from a user who needed assistance realizing they needed to change the username. > Date: Tue, 25 Sep 2007 15:23:24 -0500 > From: "Christopher D. Clausen" <[EMAIL PROTECTED]> > > I would prefer to not modify the current NIM prompts and assume > that the > Windows username matches the Kerberos principal name in the default > realm. > That would be my preference as well. If there is strong interest from other institutions in a per-realm branding concept that Russ mentioned that would be fine with us provided it is transparent to institutions who choose not to use it. We've spent the past year rolling out KfW, going from 3.0 to 3.1 and now to 3.2.0. There are a number of UI refinements in 3.2.0's NIM that we contracted with Secure Endpoints to do based on feedback from our user and support community. These changes have increased user satisfaction with KfW, so we generally are not sensing an immediate need to modify the existing interface. Best, Jason Cowart IT Services Stanford University _______________________________________________ kfwdev mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/kfwdev
