We Keep Coding

Windows Authentication for Blazor Server app - login popup

I am building a Blazor Server app using .NET 6.0.11 and deploying using Http.Sys . The server and clients are all on the same Windows domain. I'd like to authorize users based on their domain login, instead of building a username/password database and infrastructure specific to this app.
The code in Program.cs to enable Windows Authentication, based on code from the official documentation:
if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
{
builder.Services.AddAuthentication(HttpSysDefaults.AuthenticationScheme);
builder.WebHost.UseHttpSys(options =>
{
options.Authentication.Schemes =
AuthenticationSchemes.NTLM | AuthenticationSchemes.Negotiate;
options.Authentication.AllowAnonymous = false;
});
}
// ...
app.UseAuthentication();
app.UseAuthorization();
I view the authentication state using the first code sample from ASP.NET Core Blazor authentication and authorization.
If I launch the application on http://localhost:55555 then the page loads instantly and it shows my domain and username successfully.
However, if I launch the application as http://mycomputername.our.domain:55555, and access it via Chrome or Edge on the same machine, then a popup appears asking for username and password:
Note: I had to run a netsh http add urlacl url=.... one time only; the command was suggested by an exception message generated on first run after changing the launch URL.
Entering my domain login username and password is accepted, and the previous code sample does show my username successfully. I also noticed the following behaviour:
setting AllowAnonymous = true; means it will not prompt at all for the username/password; the page just proceeds with the user not authenticated.
If the username/password is not entered correctly (for a user on the domain) then HTTP error 401 is generated instantly, it never tries to execute the Blazor default error page for example.
I hope the authentication is being done between the client and the domain controller, not sending the user's password over the HTTP connection!
I am presuming the above behaviour will be the same for other domain uses on different machines accessing this server, although have not tested that yet.
My questions:
is it possible to skip the username/password popup , and just get the domain user that is already logged in on the client machine and doing the access?
(If not) would deploying to IIS instead of Http.Sys change anything?
There seem to be Blazor-based solutions discussed on this SO thread , but I can't see how to use them because the popup always appears as soon as any page is attempted , before any page is rendered; and if login fails, HTTP 401 error is generated with none of the Blazor pages being executed.
Footnote: I was using HTTP.sys instead of Kestrel due to documentation indicating that Kestrel did not support Windows Authentication; however it is working using Kestrel for me now, along with the information from the Accepted answer -- not sure what the story is there.

This is a client-side issue.
If I launch the application on http://localhost:55555 then the page loads instantly and it shows my domain and username successfully.
However, if I launch the application as http://mycomputername.our.domain:55555, and access it via Chrome or Edge on the same machine, then a popup appears asking for username and password:
That's because the browser recognizes localhost as a (somewhat trustworthy) server within your intranet, but considers mycomputername.our.domain to be a (potentially hostile) Internet service. For security reasons, Chrome and Edge only use your Windows credentials with servers within your own intranet by default.
To determine which group an URL belongs to, Chrome, Internet Explorer and Edge use Windows's own "Intranet zone" settings. To add your URL,
search for "Internet options" in the Windows Start Menu, then
navigate to Security/Local intranet/Sites/Advanced.
If you want to test with a non-Chromium based browser, here's how to configure Firefox. Firefox manages its own list of URLs where Windows authentication is allowed:
How to configure Firefox for NTLM SSO (Single-Sign-On)?
I hope the authentication is being done between the client and the domain controller, not sending the user's password over the HTTP connection!
If the client and the server agree to use Kerberos, sure: The client communicates with the domain controller to authenticate and to get a service ticket and then uses that ticket to access your service.
If they don't agree, they will use NTLM. In this case, authentication happens between the client and your server. However, NTLM won't send your password in plain text either, but rather uses it as part of a challenge-response mechanism.

is it possible to skip the username/password popup , and just get the
domain user that is already logged in on the client machine and doing
the access?
IMHO, this is not possible with "windows authentication", because the popup dialog that you see is a special browser feature to enable the windows authentication.This one created in order to support internal application with domain authentication. I don't know of any way to access that browser behavior.
(If not) would deploying to IIS instead of Http.Sys change anything?
Haven't done a deployment with Http.Sys, but according to the documentation it says that Http.Sys supports windows authentication. The deployment would be different since for Http.Sys you need to write the configuration in code, unlike the IIS.

ASP.NET processing unauthenticated file request in site with Windows Authentication: How?

I have a curious problem with a legacy ASP.NET web application using Windows Authentication. A particular page is crashing, and an inspection of the page and the site logs indicates the page is crashing because the request is not properly authenticated - no Windows identity is being requested by IIS or supplied by IE 11.
The page has a curious path; it took a few minutes to decode how it was originally assembled. The initial request is not for a specific page, but is merely a folder-only URL that is routed to Default.aspx. The handler checks the query string and redirects to specific pages accordingly.
The initial request to the site is authenticated, as evidenced by the IIS site logs. The page to which the request is redirected (Response.Redirect) does not authenticate. The absence of the Windows authentication challenge leaves the site with no automatic identity to the targeted page, leading to the page crash (code depending on the identity fails). The sequence goes this way:
Original URL: /sitename/folder/?parameter1=value&parameter2=value
IIS issues the authentication challenge, and the authenticated user is shown in the logs - eg, domain\user
The request is then handled by folder/Default.aspx (default page as defined in IIS)
Default.aspx.cs inspects the query string, and routes the request to (eg) OtherPage.aspx via Response.Redirect.
OtherPage.aspx is requested, and the request is logged - with no authentication, and no challenge
OtherPage.aspx.cs crashes (no user credential)
I am trying to theorize how or why ASP.NET is even permitting the unauthenticated file request. I have tried to reproduce the behavior in a test environment, and have been unable to do so. I have suspected that "Automatic logon in Intranet zone" might have been disabled, or that stored local credentials may be present but somehow causing a conflict, but neither of those scenarios panned out. The former did result in a failed authentication attempt and a proper 401 response from the server (the target page was not fired in a test environment).

Further research into this question has led to a solution if not a 100% dissection of the cause.
The users experiencing the problem were accessing the target site via a link in an email message. The link, for some unknown reason, inhibited the credential exchange between IE and IIS until the site URL was placed in the "Local Intranet" sites list of IE. This allowed the "Automatic logon in Intranet sites only" option to apply which, in turn, allowed the authentication to work.
The reason this is not a "100% dissection" is because these users were accessing the site previously, wherein authentication worked when the site was accessed conventionally. Exactly how the email message link inhibited the authentication exchange is not known. At the moment, I theorize that some security setting inhibits authentication when originating from an email link unless the specific site URL is explicitly qualified as a trusted or Intranet site.
Thanks for your consideration.

MVC4 403 forbidden error with siteminder

We have a MVC4 application running on a windows server 2008 with iis 7.5. everything was running fine until out SSO team installed siteminder for single sign on.
Now the application after the SSO redirect is giving a 403 forbidden error. Any Suggestions?
Here's what is happening.
1. access the site.
2. Site redirects to SSO page
3. after entering the credentials (everything is validated as the siteminder trace and logs is showing no errors)
4. application redirects the original entered url and we see a 403.
we currently have no implementation that uses the SSO user coz we were waiting for the SSO to be setup and our current authentication in web config is set to "None"
application was all good before the siteminder and the url was accessible.
Verified everything but not sure what is the issue.
1. Application pool is set to 4.0
2. TestConnection is ok for authorization and authentication
3. No errors in siteminder logs (the SM cookie is set correctly)
4. We do not have SSL
5. this is the only site running on the server
6. IIS_IUSRS is given access to the sites root folder
Not sure if there is anything we can do in the sites web config. though as i have mentioned before it was all ok before site minder. Now Even if we disable the siteminder the application just return 403 forbidden.
please help!!

well we finally reached out to some people with extensive siteminder experience and they suggested to use the "classic" app pool instead of "Integrated" which solved our issue.

Active Directory Authentication using Client Certificate in ASP.NET MVC

I am working on one project where we have to deploy two different application on server, one is Cognos website and other is .NET website.
Now, when request come to web server (IIS) it should asked for Client Certificate Selection, once you choose the client certificate it should go back and check where it is attached with any Active Directory Users or not.
basically i wanted to implement authentication using Active Directory and Client certificate using .NET.
Appreciate for any suggestion/direction.

This should work out of the box with no code.
First, turn off anonymous access and basic authentication for the website and turn on integrated windows authentication and certificate integration.
Then, in your asp.net application, set the auth mode to windows.
Then, turn on SSL for the website and check the option "require client certificate".
http://technet.microsoft.com/pl-pl/library/cc753983%28v=ws.10%29.aspx
From now on, when the browser supports certificate integrated authentication and the client machine has the certificate either in the user store (IE) or in the browser store (other browsers), the browser will automatically ask the user to pick up the certificate.
My advice is to start with integrated windows authentication over SSL but without certificates (do not check "Require client certificates"). Test with IE and configure the IIS until your users are automatically authenticated without any prompt for credentials.
This is the most troublesome part. If you have it working, you just turn on the requirement of client certificates.

Unsecured & secured HTTP

I have an application which uses 2 web sites (so I guess that is 2 applications...). The user logs on via a https website and is then diverted to a unsecure http website application on successful logon (using forms authentication). I (and others) have started getting the message
"The current web page is trying to open a site in your Trusted sites list. Do you want to allow this?"
when the user is redirected.
Is there a way to stop this in the server configuration or in the code ?
Thanks

If the user is accountable for any actions performed on the "unsecured site", it should not be unsecured. It's not safe to authenticate a user on HTTPS, then let them perform actions using that authentication over HTTP.
If someone is not worried about a man-in-the-middle, it doesn't make sense for them to use HTTPS at all. On the other hand, if a man-in-the-middle attack is a possibility (and in general I assume it is) then sending the session identifier cookie (or other credential) obtained via secure login over an insecure channel allows an attacker to steal it and forge requests to the service.

I think what you are doing at login is to post the login information from the secured page to the non-secured page, which in turn pops up that message.
What you could have done is for the secured login to post to a secured page, then redirect from there to the non-secured page. That should remove the message.

That message appears to be IE's trusted sites warning. There is no way to control it from a remote server, nor should there be as it would be a security risk.