I set up a test PeopleSoft 9.2 virtual box and had this message after entering user/password which stopped me logging into the system. I enabled cookies in my browsers but no luck
Related
I'm currently experiencing an issue with some users of an ASP.NET 4.8 Web API application hosted on Windows Server 2012 and IIS. The following properties are not returning that user's correct user name, and instead returning the name of a service account used for this server:
HttpContext.Current.User.Identity.Name
HttpContext.Current.Request.LogonUserIdentity.Name
I have no idea how to begin troubleshooting this - myself and most other users do not experience this issue, but for a handful of users the above does not return the correct username, returning the username of a service account used to remotely connect to the server in question. Forcing a login via a browser private window does rectify the issue, and the application correctly returns the expected username for each of the above properties.
What could be a cause for Windows Authentication not returning the correct user name and what is the best way to troubleshoot an issue like this?
edit: I was able to resolve the issue, see my answer below
After some additional research and troubleshooting, I determined that the users experiencing the issue described above had the service account in question stored in the Windows Credential Manager:
Removing the service account in question allowed them to be authenticated with the Intranet site with their normal Windows domain\username. As #pcalkins suggested, at some point the affected users had used these credentials on their machine, and Chrome, Edge, IE were using that saved credential when authenticating with the Intranet site.
Please check the following steps:
Make sure that windows authentication is enable and Anonymous Authentication is disable for the website.
Enable integrated security in Interner Explorer (Options/Advanced and checkin the "Enable Integrated Windows Authentication" option).
Add your website to Local Intranet zone and select at least "Automatic logon only in Intranet Zone" option under Options/Security Settings/Local intranet/Custom level).
Aake sure the user and application server are in the same domain.
I have a website on \\WEBSERVER that needs to download from two UNC virtual dir: \\vDir1 and \\vDir2 from two separate pages.
\\WEBSERVER to \\vDir1:
No problems
same user/password on both computers
Connect as... with user/password on IIS 7
Test Settings... gives green in authentication and authorization, "Path is accessible"
\\WEBSERVER to \\vDir2:
Logon Failure: unknown user name or bad password when trying to browse \\vDir2
same user/password on both computers
Connect as... with user/password on IIS 7
Test Settings... gives green in authentication and authorization, "Path is accessible"
So in all, I have three servers all with the same user account user/password. I pass the credentials through the application pool's identity which is the only app pool that runs for this website.
I am still learning IIS, but I am thinking my problem lies within the computer of vDir2. I've even added user to "Access this computer from the network" in Local Security Policy but still no luck.
PS: The webpage uses form authentication so I do not want to enable anonymous authentication.
PSS: in Visual Studios, vDir1 has a web.config file automatically written when I disable anon authentication. vDir2 threw an error and did not write a web.config file when disabling anon authen. Enabled write permissions, still threw same error.
Please help
I have an ASP.net web application that’s running on our intranet, it is using active directory for authentication. We recently migrated away from an old domain to a new domain. Some users are getting This Page Cannot Be Displayed error when connecting to the application.
The errors seem to persist on IE 11 but works in Chrome or Firefox. I suspect that IE is caching user credentials and trying to log users on using their stored credentials and passwords.
We have tried clearing cache and cookies with mixed results, the server has also been restarted but the problems persist.
Any thoughts on how to address this and force IE to users the use their actual credentials and not cached credentials?
Not to add confusion, but I have had some success with some users connecting using the IIS webserver IP address rather than the qualified name e.g. 10.x.x.x/appname.aspx instead of MyServerName/appname.aspx
Thanks
I suspect for those users with the problem that they have allowed IE to save their password. That is not in a cookie.
Have a look in Credential Manager on their workstations. Depending on the OS it would be: Control Panel\User Accounts\Credential Manager
Click "Web Credentials" and if there is a Web Password stored for your application, you will see the URL listed. Just delete it.
This would also explain why the IP works. Because the cached credential is tied to the URL.
To implement automatic log-in on server's 401 Query ( Basic Authentication) i am using nsHttpAuthManager( a manager that stored credentials to bre used in automatic authenticat). when i am adding the credentials it should be added to HTTP authentication manager but for some reason popup for credential is still coming.How can i check what are the values of a stored entry
how can i test whether Credentials with port,username,password,realm are being added to Authentication manager or not? Any tutorial would help.
I've set up a site using ASP.NET MVC 5 to use claims based security using our on premise ADFS server. The site performs the redirect to the ADFS server which asks for the users AD credentials to log in, and then redirects back to my site. At that point the user is authenticated and I have access to all the claims that ADFS is sending.
The issue is I don't my users to have to enter their credentials. I would assume their windows credentials could be sent to the server to make the sign in process seamless but I can't figure out how. I have attempted to set the authentication mode to windows but it has no effect.
Both the ADFS and my site are internal and the ADFS site appears in my Local Intranet Sites settings. I've tested with both IE9 & Chrome and they both have pop up a dialog box looking for credentials. I've spoken with the sysadmin and windows authentication is enabled for ADFS.
How can I authenticate with ADFS without my users being prompted for their credentials?
I encountered the same issue as well and finally figured out the cause. This may occur if the ADFS authentication page url is a non-intranet address.
To resolve the issue, change the wsfederation issuer address in application's web.config to one that would be treated by the browser as an intranet address.
Change the following
<wsFederation passiveRedirectEnabled="true" issuer="https://xyz.abc.com/adfs/ls/" realm="http://myapps/MVCpluADFS" requireHttps="true" />
to
<wsFederation passiveRedirectEnabled="true" issuer="https://xyz/adfs/ls/" realm="http://myapps/MVCpluADFS" requireHttps="true" />
where xyz is the machine name where ADFS is installed.
Do not change the adfs trust urls though. Keep them as they are since they would be used for matching and establishing trust between your application and ADFS.
The browser treats "xyz.abc.com" as an internet address, and hence displays a login prompt while "xyz" is treated as an intranet address so it automatically forwards logged in user credentials to the application without the user having to specify credentials himself/herself.
After this change, any intranet user would be directly logged in to the application if the browser used is Internet Explorer with default security settings (i.e. "Automatic logon only in Intranet zone" under Security tab -> Internet -> Custom level) or Chrome (since it picks up the settings set for Internet Explorer).
To make the automatic login work in Firefox, the following additional steps would have to be performed:
1) Type about:config into the firefox address bar. You might be warned about editing this section, go ahead anyway.
2) Type "fqdn" in the search bar. You should now see 2 settings i.e. "network.automatic-ntlm-auth.allow-non-fqdn" and "network.negotiate-auth.allow-non-fqdn". Change the values of both to true.
Are these intranet or extranet users?
Only intranet users can log in seamlessly with WIA.
This works OOTB with IE with the correct settings but other browsers need to be explicitly configured.
What browsers are you using?
Also the ADFS config needs to allow integrated auth.