Re: Integrated Windows Logon
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.
Re: Integrated Windows Logon
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
Re: Integrated Windows Logon
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
Re: Integrated Windows Logon
Quote:
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.
Re: Integrated Windows Logon
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.
Re: Integrated Windows Logon
Quote:
Originally Posted by
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
I dunno yet I havent really looked into it (too busy at work today :( ) but I'll check it out tonight
Re: Integrated Windows Logon
Quote:
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.
Re: Integrated Windows Logon
Quote:
Originally Posted by
NeedSomeAnswers
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
Re: Integrated Windows Logon
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.