Integrated Windows Logon

[chris128]

Quite a few programs now offer the ability to automatically log in to the program using your windows credentials so that you do not have to enter a separate username and password for the application.
I had assumed that the way this works is simply that the program looks at your windows username and just bases its security on that - it does not actually need to know your windows password at all as it knows that if you are logged on to the PC with that username then you have already had to enter the windows password to get logged in to the PC (unless the user has just left the PC unlocked and walked off of course...).

However someone mentioned a piece of software called VisualSVN to me today (something I'm sure a lot of you are familiar with) and I just noticed on their website it says this about the Integrated Windows Auth mode that their software can use:

Unlike Basic authentication, Integrated Windows Authentication (formerly known as NTLM authentication) does not prompt users for a username and password. The current Windows user information on the client computer is supplied through a cryptographic exchange involving hashing with the VisualSVN Server. Either NTLM or Kerberos V5 authentication protocols can be used.

Now I dont understand how it can actually do this NTLM/Kerberos authentication without having to ask the user for their password initially, store the user's password somewhere locally, transmit it to the server each time the user logs in to the program and then fail to login every time the user changes their password and prompt them for it again...

So basically I'm just wondering how people implement this functionality in their apps if anyone here has ever done it. I'm thinking that the description from the VisualSVN site is just marketing bumf and it doesnt actually work like that but perhaps there is something I'm not thinking of that could make this work smoothly and not just rely on the user's username on its own to prove their identity.

Cheers
Chris

[RobDog888]

I believe that it can read an "IsAuthenticated" property of the users username/account in AD. It should be making a webservice call over https to pass the encrypted data. You can pass the credientials too and have it validate the paired information.

[chris128]

but to pass the credentials you would have to always have the user's current password right? So what about when the user changes their windows password, the program would stop working

[gep13]

Hey,

Does that mean you are going to run VisualSVN then Chris?

Sorry, I don't have the answer that you are looking for, I will have to speak to the guy in our office who said up our VisualSVN Server, which is now due to retire, since we got TFS

Gary

[NeedSomeAnswers]

but to pass the credentials you would have to always have the user's current password right? So what about when the user changes their windows password, the program would stop working

I think what rob is saying is that as long as you have there Windows Login ID you are ok, because you can query AD for the "IsAuthenticated" property of that user.

You wouldn't need to login to AD with that users Login, you would just want some kind of service account which had access to read Users account details.

[chris128]

I dont think there is such a property for an AD user account though... the user account in AD is not what is actually logging on, its just an object that provides a security context for someone to use. You can log on to multiple PCs using the same user account at the same time for example, so then when you query this IsAuthenticated property, which logged on user is it going to actually look at? Perhaps you are referring to a method in .NET rather than a property/attribute in AD?

EDIT: I just found this: http://support.microsoft.com/kb/326340 - is that what you are talking about? They are just defining their own IsAuthenticated method there, but it requires knowledge of the user's username and password so like I said the user's credentials would have to be remembered by the program (which is unsecure in itself) and it would also stop working as soon as they changed their password.

[chris128]

Hey,

Does that mean you are going to run VisualSVN then Chris?

Sorry, I don't have the answer that you are looking for, I will have to speak to the guy in our office who said up our VisualSVN Server, which is now due to retire, since we got TFS

Gary

I dunno yet I havent really looked into it (too busy at work today ) but I'll check it out tonight

[NeedSomeAnswers]

I dont think there is such a property for an AD user account though... the user account in AD is not what is actually logging on, its just an object that provides a security context for someone to use

You could just get the current logged-in user from Windows itself, and use that Username to authenticate to your own application, the idea being that the user is already logged in to windows and therefore is trusted so you don't need a password to login to your own application.

[chris128]

You could just get the current logged-in user from Windows itself, and use that Username to authenticate to your own application, the idea being that the user is already logged in to windows and therefore is trusted so you don't need a password to login to your own application.

I know lol thats exactly the point of this thread. I was saying that was how I assumed it worked but then I saw this program claiming that it does proper NTLM/Kerberos authentication and it made me wonder if there is any way other than just using the windows username on its own

[dilettante]

For remote authentication the client PC stores the necessary information to create and pass the hash which is used to authenticate the user. I doubt Windows ever stores the plain-text password after logon, and I'm sure it doesn't send it over the wire. Both NTLM and Kerberos involve challenge-response dialogs though. The infrastructure required normally makes it impractical for use by the average local application, which doesn't really need it anyway.

See:

http://tools.ietf.org/html/rfc4120
http://tools.ietf.org/html/rfc3244
http://tools.ietf.org/html/rfc4757


Basic authentication as used with Web servers is another beast altogether of course, sending just a Base64 encoded user/pw.