This probably is a stupid question, but I am wondering how secure the LOGON_USER server variable is?? Would you use it as the only means for authentication against AD or are there some vulnerabilities?? thanks.
Absolutely the string in LOGON_USER can easily be spoofed.
The thing is though that your Active Directory isnt going to grant access unless it is spoofed with a valid domain and password and then, if you have the valid domain and password then why bother spoofing?
There is also a password component of the Request header but ASP doesnt put that into the ServerVariables collection thinking it better not to make it too easy on web developers to steal passwords.
Also you can use this "LOGON_USER" ServerVariable for a number of purposes. One application it is used for is to set permissions to various parts of an intranet.
You can use the LOGON_USER variable to determine who is visiting the page, and if they are a particular user, then they will be allowed to continue on, else they are taken to a page explaining that they do not have adequate permissions.
Thanks guys for that info. Here is my plan of execution:
- This application is going to be used by both Internal as well as external personnel (using SSL)
- When either internal or external personel go to the site, I would like to validate their LOGON_USER against AD; if they are validated then I want to pull some info from AD, if they are not in AD then I want to display a logon screen (username and password) to have the individual validated against a USERS table in SQL Server.
Based on this info, is there anything that you can foresee being an issue as far as authentication goes??
Just make it so that the page doesn't have anon access, then you wont have to worry about it. Anyone that can actually see the page has already been validated and everyone else will get permission denied or forbidden.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.