Trying to implement windows authentication on my published asp.net core 2.2 application.
Hosting server is Windows server 2016 (IIS).
I would like to use the active directory logged in user account to authenticate the user on my application.
I'm getting the user details by these methods:
User.Identity.Name; //return null in local host, worked when IIS
System.Security.Principal.WindowsIdentity.GetCurrent() // local host
I keep getting in the browser, the Sign in dialog box (although I would like to get rid of it, even when entering credentials - <username> + password - it doesn't authenticated).
I would like to get rid of it
Stop getting error 401 - unauthorized
I've configured what ever I was advised - both IIS and browser, but still - keep getting it:
Browser:
Browser security - Entered the host IP address to the trusted sites
IIS:
Set Authentication => enable Windows Authentication to true.
Through web.config - set "forwardWindowsAuthToken" to "true".
Site Configuration:
In the IIS site configuration (applicationHost) - system.webserver -> Security -> Authentication -> windows authentication -> "UseKernelmode" = "true"
ApplicationPool:
.NET CLR Vesrion = "No Managed Code"
Managed Pipeline Mode = " Integrated"
event tried to change in the "advanced settings" the Identity from "ApplicationPoolIdentity" to "NetworkService"
NTFS permissions:
Set basic and defaults Permissions to the account<Server host Name>\IIS_IUSRS on the server published code directory: Read & Execute, List folder contents, Read.
Maybe the problem is here - because the IIS_IUSRS account is defined in the server and not in the domain ?
You can try this method to solve the problem:
Open iis and in Windows Authentication, Right-Click to set the Providers, set the NTLM to be FIRST.
Check that under Advanced Settings... the Extended Protection is Accept and Enable Kernel-mode authentication is checked.
Related
Below is my code to popup and login through MSAL.
var app = PublicClientApplicationBuilder.Create(msal.ClientId)
.WithDefaultRedirectUri()
.WithTenantId(msal.TenantId)
.Build();
var result = await app.AcquireTokenInteractive(msal.Scopes).ExecuteAsync();
Code above works when it's running on my local machine.
And below is my settings in Azure AD. Its working when I set it to localhost:5000
But when I set the localhost to 'myWebAppUrl' which is hosted on Azure Virtual Machine. MSAL won't popup. And it will just return "The operation was cancelled". Anything I missed here?
Please check the below points.
In azure ad,the reply URL must begin with the scheme https, unless using localhost. ex:http://localhost:5000
Else you can use something like https://yourappurl and don’t forget to Grant admin consent
Under Permissions for the scopes you have in azure ad.
Please check Redirect URI restrictions
Apps that use system browsers: http://localhost
Apps that use embedded
browsers:https://login.microsoftonline.com/common/oauth2/nativeclient
For Node.js, you can use msal://redirect
Please check Add a redirect URI section and Client application configuration (MSAL) | Microsoft Docs
And check if you can use confidential client to your app
.
Some authentication libraries like MSAL.NET use a default value of
urn:ietf:wg:oauth:2.0:oob when no other redirect URI is specified,
which is not recommended. This default will be updated as a breaking
change in the next major release.
Other references
Instantiate a public client app (MSAL.NET) - Microsoft identity platform | Microsoft Docs
Initialize MSAL.NET client applications - Microsoft identity platform | Microsoft Docs
I've published my SPA site on the intranet but it's not picking up the users Windows AD account. When I run the app in VS2012 it picks up my user name fine however, when I open the site via my browser and run a URL to the API i get this message (generated by my controller)
string user = System.Environment.UserName; //(user being: OURDOMAIN\\WEBSERVERNAME$)
and in the returned JSON...
'Result':'Failed to do check: Login failed for user 'OURDOMAIN\WEBSERVERNAME$'
This is a DB message (as OURDOMAIN\WEBSERVERNAME$ isn't a DB user), the problem I have is that I want it to pick up the windows AD user, not the server name.
Windows Auth is enabled on IIS and everything else disabled.
Many thanks for any help.
itsdanny
I have IIS 7.5 site:
Authentication = Windows Aythentication enabled
Application Pool = DefaultAppPool
DefaultAppPool Identity = ApplicationPoolIdentity
Load User Profile = True
On the filesystem,
DefaultAppPool has Read and Execute privileges to the entire site.
Also added a security group with Read and Execute privileges to the entire site.
With these settings, only users in the security group are able to access the site. All others get a AD login window, which has no affect. I'm not understanding this behaviour.
From research, it looks like I don't need to add the DefaultAppPool to the filesystem, if users are only executing, but still doesn't explain why they get the login challenge.
I'm also unclear if i need to set the AuthenticatedUserOverride (in Config Editor) from UseAuthenticatedUser to UseWorkerProcessUser if i want to use the filesystem security of DefaultAppPool. When i set this, i get an access error, not even the login challenge.
Note: site is not in the Default Web Site, but on a specific port number.
I'm unclear why i seem to need users listed in an ACL rather than using the generic DefaultAppPool.
Windows authentication determines how you determine who is who. Impersonation means which user account the security context runs under. Because you are loading the user profile, the context is taking on the AD user's security. Your DefaultAppPool identity is now out of the picture which is why you need ACL's on your files / folder.
Users will continue to receive the login prompt who are not cleared at the ACL level because IIS doesn't know what to do until an account that can access the files is provided. Watch in fiddler and you'll continue to see challenge messages from the server.
I have a classic ASP app that I want to run under specific windows account/identity, e.g, "MEME". The asp app virtual root authentication is anonymous only (other types of auth are disabled) as the app will be doing form authentication. The filter needs to force app identity to MEME (IUSR dont have permissions to do all things I need, like open service manager etc...).
I have isapi filter and registered the SF_NOTIFY_AUTHENTICATION event. The event is firing and the filter sets pszUser = "MEME" (most of the time and other times other "MEME2" account) and the pszPassword = "memepass". But the app runs under IUSR identity. IIS7 ignores settings of pszUser/pszPassword.
I can set the app identity statically, editing virtual root, adv properties, Physical Path Credentials = "MEME"/"memepass" and that works but this is static and I need to determine MEME or MEME2 at run time.
If I enable Basic Auth then the pszuser/pszpassword set in the filter works correctly but I cannot have any auth dialogs popup on client side.
So how do I make isapi filter set the app identity to MEME (or any other win account)?
I have other events firing like SF_NOTIFY_PREPROC_HEADERS.
In the IIS Manager you can set the anonymous access on the root folder of your site to MEME and pw.
Do this by right clicking on your site name and select properties. Select the Directory Security Tab and then Edit the "Authentication and access control". Make sure the "Enable anonymous access" is checked, and write the credentials to be used in the fields below. Click ok etc etc..
Now if you only run this site on the IIS-server here is one solution that might work for the Isapi filter.
You can set the Isapi filter on a global level instead of site level. Do the same thing as above but do this on the "Web sites" map in the IIS Manager. Here change the Anonymous user to MEME2 and then set your ISAPI filters.
Might work...
edit updated with new information
I've been trying to configure a ASP.Net site to use windows authentication impersonation, and use this to call Sharepoint 2010 web services.
I've enabled impersonation and windows authentication on the site, and given in a "classic" .net 4.0 app pool identity. I display the user that is logged in. When the site is run from the server, everything works fine - the user is impersonated correctly. Tried with several user accounts (but all local admins...). This can upload a file to sharepoint which records the "Created by" "Modified by" as the site user (and not the app pool identity). This is the situation I want.
When run from a client machine, it fails. The page is loaded, but it seems to fail when it tries to access the Sharepoint lists service with a 401 unauthorised. Further inquiries have shown me the following info the Sharepoint weblogs when calling the list.asmx service:
2012-01-12 22:42:52 10.197.104.208 POST /iain/Cesa/_vti_bin/Lists.asmx - 80 - 10.143.16.141 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+4.0.30319.239) 401 0 0 13
2012-01-12 22:42:52 10.197.104.208 POST /iain/Cesa/_vti_bin/Lists.asmx - 80 - 10.143.16.141 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+4.0.30319.239) 401 1 2148074254 3
2012-01-12 22:42:52 10.197.104.208 POST /iain/Cesa/_vti_bin/Lists.asmx - 80 - 10.143.16.141 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+4.0.30319.239) 401 1 5 1
From: http://support.microsoft.com/kb/969060 I know that: "The win32 status of "2148074254" (also defined as -2146893042 / 0x8009030E / SEC_E_NO_CREDENTIALS) means "No credentials are available in the security package." In other words, the client has not sent any credentials."
This looks like my web site is not passing the impersonated credentials to the Sharepoint site. Is there any way of solving this? Because it works from the server I'm sure it can work, but I'm at my wits end trying to find a solution.
This is caused by windows authentication using NTLM rather than Kerberos (I thought it was using Kerberos...).
I'm looking into getting Kerberos properly configured, but this is a big task. In the meatime I have simply moved the site and it is now hosted on the same SharePoint web front end as the web services it is contacting. Now there is now double hop, no need for deleaged credentials, and so it works :)