I have a self-hosted owin web api service on a test environment, and to give it a better name I use a domain alias, and ARR.
My web api runs on port 8888, and uses Windows Authentication. I have configured my arr to run under testserver:80 with anonymous authentication. I want to deploy a service on the box that will pool the webapi for data. When I try to visit testserver from my web browser on my desktop it works fine. However, when I remote into that box and try to hit testserver it prompts me for credentials. Even if I type them correctly it still will issue me a 401. If I go to localhost:8888 the site will work.
Since, I'd prefer to use the pretty name for the server in my service how do I correct this issue. How do I get it to pass credentials on the same box through ARR?
You might have have an issue with LSA loopback checking.
You get the 401 because ARR forwards your Windows Authentication to localhost, which is not allowed (default setting).
Try to disable LSA loopback checking (restart most probably required). If that works you can limit the disabling of loopback checking to specific websites (to prevent security holes).
See You receive error 401.1 when you browse a Web site that uses Integrated Authentication and is hosted on IIS 5.1 or a later version for more information on the LSA loopback check and how to disable it completely or only for specific hostnames.
Related
I'm having an issue getting Traefik to proxy applications that are secured using Integrated Windows Authentication (IWA). When the content being served is simply an IIS virtual directory secured with IWA there is no problem. However, when it is a .NET Core application or MVC application or even just a simple Default.aspx page and IWA is enabled I continually get prompted for my credentials (never being accepted). See below for my configuration:
Traefik Configuration:
# ns-ws
[frontends.ns_ws]
passHostHeader=true
entrypoints=["http","https"]
backend = "ns_ws"
[frontends.ns_ws.routes.match_all]
rule = "Host:ns-ws.example.com"
[backends.ns_ws]
# ns-ws
[backends.ns_ws.loadbalancer.stickiness]
[backends.ns_ws.servers.server1]
url = "http://x.x.x.x:80"
I've played with removing pass host headers and stickiness, but no luck.
Seems like the original request makes it through because I do not get an unauthenticated error message from IIS for the page, but most subsequent requests to the server will return a 401 (seems sporadic).
Example Image:
I've tried changing the "authPersistNonNTLM" option in IIS, as described here: https://boyan.io/kerberos-load-balancers/ (with no luck)
I realize this is a very stale issue but in case this helps others.
I can confirm that Windows Integrated authentication works successfully with Traefik 2.x using a TCP as opposed to HTTP router with successful logins proven on Windows/Mac using Safari/Chrome/IE.
Note that when testing it is important to ensure you have cleared cookie caches or you can get unpredictable results due to prior login attempts on non-working configurations you may have attempted. Indeed I experienced something similar to your described behavior with repeated unexplained login prompts until I reset my browser.
In our configuration we have a mixed-OS docker Swarm (Linux/Windows) with Traefik operating on Linux and sending requests straight to back-end Windows-containers running on Windows swarm nodes.
If you have configured your Windows app and containers correctly I can confirm that from:
A domain-joined machine you will get straight through login to Windows back-end containers using the domain-joined machine's Kerberos credentials
A non-domain-joined machine connection will downgrade to Windows NTLM authentication and prompt for Windows authentication credentials.
From a Traefik configuration perspective our docker containers have labels like this:
- "traefik.tcp.routers.dotnet-tcpexample.entrypoints=websecure"
- "traefik.tcp.routers.dotnet-tcpexample.tls=true"
- "traefik.tcp.routers.dotnet-tcpexample.tls.options=default"
- "traefik.tcp.routers.dotnet-tcpexample.rule=HostSNI(`windows.foo.bar`)"
- "traefik.tcp.routers.dotnet-tcpexample.tls.passthrough=true"
- "traefik.tcp.routers.dotnet-tcpexample.service=dotnet-tcpexample"
- "traefik.tcp.services.dotnet-tcpexample.loadbalancer.server.port=443"
Note that configuring containers for Windows integrated authentication in itself is non-trivial but documented here.
We recently changed the IP-address on a server hosting one of our services based on .NET Web API 2.
The service is using OAuth2, providing external logins via Facebook/Google.
We're still using the same server and the same host name for our services, only the IP-address has changed. Now I'm getting back my login URL with "&error=access_denied" whenever I try to login using Facebook/Google.
I have checked every setting in both Facebook's and Google's developer consoles but nothing seems to apply. If I remove the OAuth redirect URI, I get an error that the URL is blocked, so the settings seems to take effect.
What have I missed?
Funny how asking a question makes you think even more outside of the box. The culprit was that wrong DNS-server was set on the web host.
I'll see myself out...
I'm using the Keycloak authorization server in order to manage my application permissions. However, I've found out the standalone server can be accessed locally only.
http://localhost:8080/auth works, but not it does http://myhostname:8080/auth. This issue doesn't permit accessing the server from the internal network.
The standalone Keycloak server runs on the top of a JBoss Wildfly instance and this server doesn't allow accessing it externally by default, for security reasons (it should be only for the administration console, but seems to affect every url in case of Keycloak). It has to be booted with the -b=0.0.0.0 option to enable it.
However, if your Wildfly is running on a remote machine and you try to
access your administrative page through the network by it’s IP address
or hostname, let’s say, at http://54.94.240.170:8080/, you will
probably see a graceful This webpage is not available error, in
another words, Wildfly said “No, thanks, I’m not allowing requests
from another guys than the ones at my local machine”.
See also:
Enable Wildfly remote access
Wildfly remotely access administration console doesnt work
you can start keycloak server with this command
standalone.bat -b 0.0.0.0
For anyone who happens by here now, I found this in the documentation for Keycloak 8:
Users can interact with Keycloak without SSL so long as they stick to
private IP addresses like localhost, 127.0.0.1, 10.0.x.x, 192.168.x.x,
and 172.16.x.x. If you try to access Keycloak without SSL from a
non-private IP address you will get an error.
This is how you can disable it from the admin console, just click on your realm, and make the mentioned option.
Note: Don't forget the following
standalone.bat -b 0.0.0.0
I've followed the guide:
Getting Started with Authentication with Mobile Services .NET for Windows Store
I'm able to run the service locally as long as I don't need to authenticate the user. I can also authenticate the user if I publish the service to Azure. But I want to be able to test and authenticate the user locally. How can this be done?
I'm using Live ID and I have the correct ClientID and ClientSecret set in the Web.config. When I attempt to call LoginAsync from the client the call fails with The request could not be completed. (Method Not Allowed)
** Update 2014-03-20 **
Based on the comments of Carlos and Henrik, I've updated my local service to look exactly like my server instance. I followed Scot Hanselmans excellent guide and now I have my service running locally on port 80 and port 443 with a completely valid SSL certificate. It's even running on the exact same https://xxxx.azure-mabile.net hostname.
With these changes, there is now no configuration difference whatsoever between running the app against my local machine or running it against Azure. I can go to https://xxxx.azure-mabile.net in the browser, get redirected to Live login, sign in, and get redirected back to the service successfully. In the browser it all works. However it still doesn't work in the app.
I attached the debugger, set CLR errors to "break when thrown" and I managed to trap the exception in the service. Here's what I see in the immediate window:
The Response property is not helpful. It does not provide any additional information about the problem.
The only thing that stands out to me is that the app is trying to do a POST to /login/microsoftaccount while the browser would normally be doing a GET at this address (then getting redirected).
** Update #2 2014-03-20 **
After following Henriks guide for remote debugging I was able to load symbols and get a tiny bit more information:
"An existing connection was forcibly closed by the remote host"
The error code is 10054 (WSAECONNRESET) Connection reset by peer.
It appears the Live Authentication server may be forcibly terminating the connection, but only when I'm authenticating with the app. Again, authentication within the browser is fine. This, combined with the fact that /login/microsoftaccount is a POST from the app seems to suggest there is a problem with the authentication token I'm getting back from LiveClient.LoginAsync. I'll do some more digging...
At the moment, it is set up so that you don't need authentication when running locally and access the service from localhost. In this case, anonymous access is let through (this is of course disabled while running in the cloud).
We don't really have a way for your to authenticate locally as redirect URIs won't work (they can't point to localhost as there is not way that Facebook, say, can resolve "localhost").
One option is that we somehow can mock the authentication locally and give you a token without connecting with the various identity providers. I am not sure exactly what that would look like but it is something we can consider.
Henrik
Did you perhaps set Mobile client app: Yes in your Live Connect project? I think that setting is meant to be used with the Live Connect SDK (client) flow, not the browser-based (server) flow. The client flow isn't supported yet with a .NET backend.
You also want to make sure you are using LoginAsync(MobileServiceAuthenticationProvider.MicrosoftAccount) on the client to trigger the server flow.
IIS Media Services 4.1:
I have a dedicated website setup on my win 7 dev box. I'm testing the REST service with Windows Auth turned on from both calls from a browser as well as a test C# winform app. Using the browser I try to hit http://iismediatestsite/services/smoothstreaming/publishingpoints.isml I get challeneged (good) but when I put in my domain creds I get into a loop where it keeps prompting for creds. My domain account is an admin on this box. If I use my test app I set UseDefaultCredentials to true but I get a 401 returned.
Using Basic Auth works fine with both clients.
Any ideas?
TIA
Okay apparently this is caused by an issue when authenticating by NTLM via a loopback address. It is better explained and a workaround provided here:
http://support.microsoft.com/kb/896861