Asp.net windows authentication against domain - use local (cached) credentials when offline - asp.net

I have ASP.NET MVC application that uses windows authentication against remote active directory server. The computer where the app runs is connected via VPN to the AD server. The problem is that after user logs into the PC with domain user and logs into the application it needs to run even while offline as well, but it throws this error:
The trust relationship between workstation and domain failed.
From what I understood there is no cookie and the authorization works on per-request basis. Is there any way to authorize the user name/password against the locally cached credentials? The connection often drops and the application needs to keep running.
Also I can't turn on Anonymous Authentication as we want to sign in users without providing credentials.
Any suggestions appreciated.
Thank you

It was due to calling (while off the network)
User.IsInRole(role)
We have custom role management, so removing base.IsInRole on our custom WindowsPrincipal solved this issue.
After doing research I thought that it actually has to be on the network, but to keep using cached credentials you don't have to be, just do not try to fetch any user related information.

Related

Windows Authentication issue on Test server

We have a web application developed for use on the intranet of our client. There is no login page, hence there is no Forms authentication.
The application creates a number of records which have to be stored in the DB along with the name of the currrently logged in user. For this we have enabled windows authentication which works just fine in our development environment - and I assume, that when this is deployed on the envinronment of the client, it will work too.
The problem is, that when we host this on a test server, we need to give public IP access to the clients to check it out - and hence the virtual directory is configured to allow "anonymous access". This obviously causes a problem for us while storing the records since we are not able to capture the login name for the person who is creating/testing this application.
If we enable windows authentication for the test machine, then anyone who tries to access the app through the public IP gets a login window popup which we dont want.
Any ideas on how to capture the logged in user name for this scenario ?
Based on your design, user should log on a windows machine in your network the server is located. For that scenario, VPN would serve best and simulate real environment.

how to manually authenticate user in asp.net windows authentication

I have an Intranet application with Windows Authentication. Everything works fine. However, for some sensitive operations (it could be approving AP check, or grading a student) I need to get user's id and password. The goal is to prevent somebody walking to unattended terminal, and generally for non-repudiation. Trivial with forms authentication - but I can't figure out how to do it with Windows authentication.
I don't think it matters, but it's MVC application and authentication is done against Active Directory
Typically, server application needs to issue HTTP Status Code 401 to tell client for authentication information. However, in case of windows authentication, once user is authenticated, the token is cached by client system or browser and used subsequently whenever needed. So in your case, even if you issue 401, client will send the same token again - so your main problem of abusing unattended terminal will not get solved (as user already logged in there into the system).
One of the way could be simulate forms authentication from the application - i.e. on sensitive operations, prompt user for his/her windows password again (note that you will be already having user's name(identity) if you are using windows authentication) and then re-validate that password using active directory API (or logon user windows API).
Personally, I feel that you are trying to solve the problem at server which is wrong end - I would rather have a IT policy that prohibits unlocked unattended terminals - either user should lock the workstation or have a password protected screen saver. Typically, these things can be somewhat enforced via group policy.
In my webforms app I've got one page set as only allowing Windows Auth and no others, and then to get the username (since they have to have already done the 401 auth procedure via the browser) I get their username like thus:
string username = Request.ServerVariables["LOGON_USER"];
and then I can query the Membership provider to get the user information from the infrastructure.
Or are you trying to manually do the 401 auth process?
how to manually authenticate user in asp.net windows authentication

Classic ASP Impersonation problem on IIS7 Windows 2008 server

I am trying to write to a file on a server (web05) from a classic asp site running on Windows 2008 serer on IIS7 (webadmin). This fails and web05 logs an anonymous logon attempt during the course of the save operation.
Webadmin's site is running on an app pool in classic mode with a domain user as the process account. The process account has rights to "Trust this user for delegation to any service (Kerberos only)". The same applies for the web05 and webadmin servers.
The site is using Windows Authentication and the idea is that when I log on the site with my domain user, the rights of my user should define what I am allowed to do in the context of the IIS site. If I turn on Basic Authentication, everything works fine.
I have also used setspn.exe to add an SPN for the URL. If I type setspn.exe -L webadmin, I get:
HTTP/webadmin.companyname.com
TERMSRV/webadmin
TERMSRV/webadmin.companypub.local
HOST/webadmin
HOST/webadmin.companypub.local
So from what I understand the SPNs are set up correctly.
If I run processmonitor on webadmin while the save operation is executed, it says that the process is indeed impersonating my domain user - but getting "Access denied" (and as I said before, web05 logs an anonymous logon attempt).
Any idea what causes this?
Kind regards,
Simon
It sounds to me like you're a little confused over impersonation. The process isn't impersonating the domain user account its simply running as that user. There is a difference.
When a request arrives into ASP it will then impersonate a user and the thread handling the request will be running under the security token of the impersonated user. Its quite possible to have the same process impersonating multiple different users in multiple threads. In most cases where the anonymous user access is enabled this user is the Guest level IUSR account. Its most likely that its under this user your code is attempting and failing to run.
However if anonymous is turned off for the resource being accessed or the IUSR account does not have access to the resource then the a 401 response is sent back, with some indication of what authentication protocols it will accept. The browser may then attempt to authenticate the connection using either the current users credentials or request some credentials from the user.
You don't specify exactly how you are attempting to save file. Its worth pointing out couple of things though.
ASP code exection which may subsequently result in an access denied will not use the above mechanism to try to resolve the user.
Once a connection is authenticated it often continues to be re-used for subsequent requests (which is counter-intuative to the knowledge the HTTP is a "connection-less" protocol).
I am trying to clean up my previous questions. This answer is not sufficient to answer the question above, but I concluded that it is better to provide some insight than none. If op disagrees, please take necessary action.
This is a way back - but I recall wanting to run kerberos authentication on this app. The problem turned out to be that I tried to do kerberos outside the firewall. The app would work fine within the domain and firewall of the server's home domain but failed whenever requests came from outside.
I did a lot of chatting with an Irish technician in Microsoft, and he taught me a little about the limitations when using Kerberos. The reason I wanted to use Kerberos was that I didn't like the thought of Basic Windows authentication being unencrypted.
Good luck with your Kerberos quest :-)
I ran into this same issue and it turned out to be a simple change to the application pool. If enable 32-bit applications is set to FALSE then I recieved a prompt to login to the machine. Setting this value to true fixed the issue.

How do I tell which account is trying to access an ASP.NET web service?

I'm getting a 401 (access denied) calling a method on an internal web service. I'm calling it from an ASP.NET page on our company intranet. I've checked all the configuration and it should be using integrated security with an account that has access to that service, but I'm trying to figure out how to confirm which account it's connecting under. Unfortunately I can't debug the code on the production network. In our dev environment everything is working fine. I know there has to be a difference in the settings, but I'm at a loss with where to start. Any recommendations?
Have you looked in the IIS logs?
I would also recommend looking in the Security event log on the server for authentication failures. You should find a footprint of the failed authorisation attempt here. Be warned though - it is not unusual to get 10s of security events a second, so ideally you need to be able to access the event log as the requests are failing.
If you do not specify which credentials to use in your ASP.NET page when you instantiate the web service then I believe it defaults to NT_Authority\Anonymous.
If you're using System.Net.CredentialCache then your web service needs to be in a trusted domain, accessed over HTTPS and using either NTLM, Kerberos or Digest Auth otherwise it does not pass the credentials from the cache.
http://msdn.microsoft.com/en-us/library/system.net.credentialcache.defaultcredentials.aspx
http://msdn.microsoft.com/en-us/library/system.net.credentialcache.defaultnetworkcredentials.aspx
http://msdn.microsoft.com/en-us/library/system.net.credentialcache.defaultcredentials.aspx
Perhaps the production server uses a different user for its application pool than your dev environment? I once spent a day figuring that one out. Another option would be the (lack of) impersonation in the web.config

Control a service on a remote server from IIS

Please note: In each step I describe below I'm logged in as the same domain user account.
I have a web application that controls a service on a remote machine (via ServiceController). When I connect to the website remotely and attempt to control the service, I get an InvalidOperationException: Access is denied.
I know it CAN work, because when I connect to the website from the web server (remote desktop in, login as my domain user, then open the webpage), it works as expected.
I have configured IIS and ASP.NET to require windows authentication and impersonation. I log the current thread's principal when this fails, and I see that the thread is running under my identity whether I'm connecting remotely or from the server itself.
I have tried forcing IIS to use Kerberos authentication, NTLM authentication and both at the same time; whether my principal reports its AuthenticationType as "Negotiate" or "NTLM" it doesn't matter. None of them work when I connect remotely (from my local machine)
ANOTHER weird thing about this is that if I'm debugging from my local machine/connecting to the remote server, it works every time! But I'm NOT debugging, it fails every time!
What in the heck could be going on here?
Your scenario is delegation and not impersonation. Delegation is hard to achieve and it depends on many thing that are done right.
A place to start would be Kerberos authentication and troubleshooting delegation issues
David Wang blog is a very useful resource on thous issues.
"ANOTHER weird thing about this is that if I'm debugging from my local machine/connecting to the remote server, it works every time! But I'm NOT debugging, it fails every time!"
That's a clear indication that you have permission issues. When you run in the debugger you're running as the logged on user, when you're not debugging it runs as whatever IIS is set to use (NETWORK SERVICE by default). Try setting (temporarily!) the Enable anonymous access using your domain account as the user and see if that works. If it does then it means your IIS is not setup properly to impersonate (and it's probably running as NETWORK SERVICE).
Permissions in IIS can be a bitch to fine tune properly...
Good luck!
P/S: This looks more like a network administration question than a programming one (see https://stackoverflow.com/questions/321618/stackoverflow-is-for-programming-questions-here-are-some-better-forums-for-your#321756)

Resources