I'm having an issue where my website is not redirecting to Okta when a client is browsing. same code hosted on my dev machine works properly. Okta applications are properly configured (Okta production and OktaPreview for testing). The only difference is that the server VM is not allowed to browse internet. We cannot use search engine or download anything ON the server. Is it possible that this lack of local internet on the IIS server is playing a role in the Blazor Server-Side app not doing anything when user clicks "Login"? The user sees a spinning wheel and the template is shown instead of any error.
As it turns out, even the user's click on a button is execute at server side. So, internet access had to be enabled for all Okta domain on server side and the client is now properly redirected to Okta for SSO.
Related
I am running two Windows server 2016s with IIS 10.0.14393. One server for staging purposes, and one for production.
The application has one "front-end app" and one "back-end REST api" running on the same IIS server. The front end communicates with the backend (suprise!). The difficulty I am facing is that the staging server works as expected, i.e no "Sign in" box appears when entering the front-end web page (React). However, on the production server this box pops-up.
When the page is loaded, there is javascript that fetches some information from the API, and it seems that this async fetch is causing the pop-up to occur (the request is in pending mode until login).
I have studied the configuration of IIS on the two servers but can't seem to find any obvious differences.
Both instances have both windows authentication and anonymous authentication turned on for both front-end and backe-end. I need this as the API has different types of authentication for the endpoints.
Anyone that has solved a similar issue?
Thanks
If someone experiences a similar issue the following link may help: https://support.microsoft.com/en-us/help/258063/internet-explorer-may-prompt-you-for-a-password
In my case I was sending the request to the api with the full domain url. The problem was fixed by just using the machine name (and port in my case) when sending the request. If the whole domain with punctuation is used, the system believes that the request is meant for the Internet and not the intranet, and will not include any credentials.
Another, and probably more robust solution, is to add the site in question to: Internet properties -> security -> Local intranet -> sites -> advanced.
I have an Intranet Web Application which uses Windows Authentication. All windows/PC users can login in fine.
There happen to be 2 Mac Users that use Safari as their default browser and prefer it over chrome for Mac.
When trying to access the Intranet Web Application on the network, nothing happens. But when trying to access the Intranet Web Application from another network or source of internet outside the network, the user is able to login.
Is there something I have missed? Any thoughts on this please.
Converting them to Chrome is the last option in this option.
Thanks in advance
If anyone stumbles across this, the answer was simple. In IIS under the Authentication. Setting the providers. I removed Negotiate and kept NTLM. Apple seems to accept this security method.
I have deployed an MVC 3 website on IIS of my Windows Server 2003 edition. I have set the authentication to Basic, Integrated, and Windows in order to enable site to use Windows authentication, and automatically log in into website if the user has launched the site from the same domain. If user access the site from another domain, it should prompt the Windows credentials and should allow user to log in.
However the problem is that, user is presented with Windows login prompt every time (irrespective to same or different domain), and also when user provides valid credentials it doesn't allow user to access the site.
What could be the problem here? Or, can anyone provide me proper guide to configure IIS to use Windows Authentication while deployed on Windows Server 2003?
What is the version of IIS you are using ? Could you try to force NTLM authentication and see whether it will change anything ? Followin technet article will tell you how to change to NTML http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/7258232a-5e16-4a83-b76e-11e07c3f2615.mspx?mfr=true. Please backup the server/iis configs before attempting any modifications to the metabase
I have a REST web service running on a Windows 2003 Server. I want to prompt my users from a mobile app to enter their Windows domain credentials. I want to send those credentials to the web service, and cache them for a few days. It appears I can cache the credentials using the low-level Credentials Management functions but everything I've seen so far implies they're made to be called from an interactive session. What's the best way to cache these credentials in a web service?
MORE INFO: The reason why I need to cache the credentials in the Web Service is because I need them to access some back-end resources (i.e. SQL Server, etc.)
You don't typically cache things in a web service.
How are you prompting them to enter their credentials to begin with? That app / piece should cache the information.
It appears that Windows Identity Foundation provides a better mechanism to accomplish what I want. I'll be looking into that.
I am running a asp .net web service on IIS7. The latter is running on a Windows 2008 R2 Server. IIS7/the web service is configured for asp .net impersonation. The worker process owner is set to NETWORK SERVICE.
The web service invokes sqlplus.exe impersonated with his/her domain account on the server. I can see that through the task manager. However, when sqlplus is started, oracle says the username/password is wrong.
sqlplus.exe is started like this: sqlplu.exe / . This works great if I manually log on the server with the user account and type the statement above, everything works great
I believe you're running into the "double hop" issue here.
Your first hop is using impersonation from the client's computer to the web server. The second hop is from the web server to your database server, where you're attempting to pass those same credentials along to the database.
When you manually log on and run the sqlplus statement, it's only a single hop from the web server to the database server.
The following is quoted from MSDN. Notice the recommendation to use basic authentication from the client to the web server.
The double-hop issue occurs when the
ASPX page attempts to use resources
located on a server that is different
from the IIS server. In our case, the
first "hop" is from the web browser
client to the IIS ASPX page; the
second hop is to Active Directory.
Active Directory requires a primary
token. Therefore, the IIS server must
know the password for the client to
pass a primary token to Active
Directory. If the IIS server has a
secondary token, the
NTAUTHORITY\ANONYMOUS account
credentials are used. This account is
not a domain account and has very
limited access to Active Directory.
The double-hop using a secondary token
occurs, for example, when the browser
client is authenticated to the IIS
ASPX page by using NTLM
authentication. In this example, the
IIS server has a hashed version of the
password as a result of using NTLM. If
IIS turns around and passes the
credentials to Active Directory, IIS
is passing a hashed password. Active
Directory cannot verify the password
so it uses NTAUTHORITY\ANONYMOUS LOGON
for authentication.
If your browser client uses Basic
authentication to authenticate to the
IIS ASPX page, the IIS server has the
client password and can make a primary
token to pass to Active Directory.
Active Directory can verify the
password and authenticate the domain
user.
http://msdn.microsoft.com/en-us/library/ms817871.aspx