I am using Windows Server 2018, IIS 10 and my web application targets .Net Framework 4.5.1. My API, I built using .Net Core 2.1 and Visual Studio 2017. Both the website and the API use windows authentication.
I used this person's tutorial to try and setup Kerberos two hop authentication (https://blogs.msdn.microsoft.com/surajdixit/2018/02/07/kerberos-configuration-manager-for-internet-information-services-server/).
Steps I've taken and tried,
Set the app pool to run under a custom domain account.
Added an SPN to the domain account that points to the website DNS address in the domain
Switched the app pool to classic mode
Turned on Windows Authentication and Impersonation for the website.
Had system admin grant the custom domain account delegation rights.
The current problem I am facing, is now that I made all these modifications to the app pool and the website in IIS, when I try to connect to the website, it prompts for credentials, which shouldn't happen as it should authenticate me through my windows domain account, when I input the credentials, it just refreshes with the prompt for credentials again. When running locally everything works correctly and the HttpClient in my web application successfully calls out to the API.
I have spent hours on this and would appreciate any help. I am out of ideas.
So after trying multiple walkthroughs and working with other developers, I found that the issue was both applications, the web app and the api, running on the same server. Once I moved the api to it's own dedicated server, I had no need for impersonation and was able to just load the user profile credentials from the app pool as it was running as a domain account. HttpClient and WebClient objects were both successful then at making requests to the api by setting UseDefaultCredentials = true.
If anyone ever has this issue, try hosting your api on a different server. I spent a few days thinking it was something I had done wrong in configuring things, and in the end, it was just where I was hosting the applications.
There may be a way to make this work successfully on the same server, but I was unable to make it work. Maybe someone else who is more experienced can add to this post to help show how to do this on the same server. Happy coding everyone.
Related
Does anyone have experience setting up Azure AD on an ASP.NET 4.X website? I've registered my app in Azure and have been trying to follow the instructions here:
https://learn.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app
However, the following docs regarding SSO, etc. are written for ASP.NET MVC/Core applications.
I've tried using OWIN, and it kinda looks like it's working. I get a login prompt, enter my credentials, and pass through, but I had configured IIS 7 to use Windows Auth, so it might be picking up on that. (I've read that Azure authentication is done at the application level, not IIS, so my previous IIS settings might not be affecting anything.)
Does anyone have advice? I don't have experience adding authentication to a website and appreciate any help. Ideally, I was told I'd hit my organizations 365 login page, authenticate through it, and pass on to my website, but this isn't happening. I just get a standard popup login box. (It works, but I don't know if I'm authenticating through Azure.)
You can use Visual Studio 2019 Create a new ASP.NET (not Core) Web Application wizard. Choose any option that supports Authentication and set it to Cloud - Single or Multiple Organizations:
I need to make a web request from WebServiceA running as ServiceAccountA to WebServiceB and have it authenticate using NTLM. Both web services are dotnet core 2.2 APIs hosted in IIS. ServiceAccountA is the service account set on the IIS App Pool. Just to be clear, I am NOT doing impersonation.
I'm using the RestSharp library to make HttpClient requests.
See NTLM Authenticator: https://github.com/restsharp/RestSharp/blob/master/RestSharp/Authenticators/NtlmAuthenticator.cs
The NTLM Authenticator with RestSharp uses System.Net.CredentialCache.DefaultCredentials. This works locally but after I deploy a dotnet core 2.2 web api to a windows server and host the app in IIS (in process) CredentialCache.DefaultCredentials is no longer working as expected. The WebServiceB is returning a 401.1 and when I check the IIS logs a service account is not being passed along after the challenge request.
I have tried using System.Net.CredentialCache.DefaultNetworkCredentials but I get the same issue. I confirmed that WebServiceB is working correctly with windows auth by hitting the service directly via a web browser and it authenticates my personal windows identity just fine.
I can see in task manager that the IIS worker process is indeed running as the correct Service Account. Is there a better or different way to pull the ICredentials object from the current running process?
To help people who have similar problem. I would like to post the answer here.
When you failed to authenticate NTLM with CredentialCache.DefaultCredentials.
You could try to disable DisableLoopbackCheck.
1.Go to registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
2.Create a REG_DWORD(32-bit) named DisableLoopbackCheck=1
3.Please reboot the server to make it work.
I installed a MVC 5 web application on a cloud hosted server. It uses Windows authentication. The company itself uses a different domain than the servers in the cloud use.
For example. The company uses xycom as domain and the cloud computers use xycloudcom as domain.
The xycloudcom servers have access to the AD controller of the xycom domain.
Now I installed an application on the cloud server. It has only Windows Authentication enabled and all works fine when accessing from a computer and account in xycom domain.
The only issue is that I am not able to open the website from the server itself. It opens a dialog asking me for my credentials. If I enter them (my xycom account) I get a 401 Unauthorized.
If I enable Anonymous authentication I can open the web site. So it's not a DNS issue.
Can someone help to solve this issue since I need to trigger an action by a console application in ScheduledTasks using a web request.
Server is Windows 2012 R2.
You will not be able to open the site from the server, if that server is not on the same domain.
The integrated windows authentication would work only if there is a trust between your Cloud VM's domain and the xycom comain.
Hope this helps.
I've setup an Asp.Net Core 2.0 application following the guide here
The goal is to enable Windows Authentication. I've enabled NTLM and Negotiate. I'm working (and will update) on testing Kerberos and Basic as well, but I fear I might not get the automatic sign-in that negotiate brings.
The application works correctly, and when hosted on Service Fabric I can access it directly from the server IP and port. Windows authenticates correctly, everyone is happy, birds are singing, rainbows appear in the sky... its great.
However, when I try to access the application via the Service Fabric Reverse Proxy service, I hit a wall. My browser prompts me for credentials, and will not accept anything that I pass into it.
I fear this may be a limitation of the built in reverse proxy, but this is something so common that its hard to believe that to be the case.
Is there a way to enable pass-through Windows authentication for the built in proxy?
Note: This is not hosted in Azure, but on premises.
Update: Enabling Basic Authentication and Kerberos didn't help either. Basic authentication actually further complicated the issue. With just Basic authentication enabled, I got repeated 401s, even when connecting directly to the service.
I am deploying a .NET web service that connects to a database.
When a user within the domain connects to the webservice, I want their identity to be known by the webservice (since a subsequent call to the DB from the webservice uses a USER_ID() function to know which user is making the request).
The app pool that is running the web service is configured to run under a domain account that allows access to the database. When I query the web service, it is connecting as that account of the app pool, and not the user that is calling the web service.
I have tried various different impersonation configurations but I can't get the web service to interpret the caller's identity. Can anyone advise what I am doing wrong? Is the fact that my app pool that is running under a named account causing the problem? Should it be configured to something else?
No, it's not the app pool's problem. Impersonation has to be also set from configuration files which in fact, it's probably already been specified.
Now, you didn't mention what of service you are using. For the service to be aware of who is making the request through impersonation the service must be running in asp.net compatibility mode so it can participate in the asp.net pipeline. It's a pretty basic topic, but if you need more info, then refer to the MSDN article below
http://msdn.microsoft.com/en-us/library/system.servicemodel.activation.aspnetcompatibilityrequirementsattribute(v=vs.110).aspx
Leo