We have tomcat 8 hosted on a VM on which we have deployed a couple of services which requires authentication to be passed in the header (LDAP authentication enabled). Sometimes we do observe 401 exceptions from the service. Initially we thought it was the LDAP authentication going for a toss. But on checking the tomcat localhost access log, we see that the username (which generally appears if we pass a user name in the header is not listed) even though basic authentication headers are passed. This happens intermittently. How to go about debugging this?
Turns out the answer was present in catalina.out all along. The LDAP server was unreachale intermittently and hence were facing the issue.
Related
I am currently working on an .NET 5 & SignalR application and in localhost everything seems to be working fine. When I try to deploy it to IIS pre-production Server which doesn't have a SSL certificate configured, pages other than Login are showing the message "This site can’t provide a secure connection". In the login page from the browser console I can see that most of me javascript and css files aren't loaded with the error "Failed to load resource: net::ERR_SSL_PROTOCOL_ERROR". Also from what I can see after user logs in, the request is redirected to Https.
I have removed app.UseHttpsRedirection(); from the Startup and disabled SSL in the Debug properties of the application. That seems to be a wired behavior because I used to deploy applications in .NET CORE before and didn't have these kind of problems. is there any way around this problem, except configuring an SSL certificate?
From the suggestions in server fault, configuring a self-signed certificate provided by IIS itself seems to be the problem solver. Still I don't get why the application was making that https redirection, but anyways in case someone else has this kind of issue.
We have OpenAM plugin for Apache Http server.
Here Apache Http server works as reverse-proxy.
OpenAM plugin validates user requests for authentication and authorisation then forwards the requests to service.
This works fine for some days. But suddenly, OpenAM plugin fails to authenticate and authorise and requests directly goes to service.
Only fix is to restart the Apache HTTP server.
But this is not the correct fix. We would like to find the real route cause of this problem and fix. There is no logging reported from http server.
Thanks.
There is no logs reported. Totally clueless. It is happening once in two days or >so.
You should set the Agent level to message and check the debug.log (in agent root --> instances --> debu --> debug.log) and trace the requests in the agent log files that are not working. There may also be relevant information in the system logs in the agent root log folders.
But suddenly, OpenAM plugin fails to authenticate and authorise and requests
directly goes to service.
What HTTP status code is returned during this period? By default, if the Agent cannot communicate to AM for policy advice (unless it has preconfigured fallback not enforced URLs) will be to 403 each request. You'd really need to check your debug and apache access logs to look at these requests hitting the reverse proxy (or whether they hit them at all).
In the interest of avoiding yak-shaving, I'll try to provide as much context as possible.
We have an internal application that's also available on the public internet. This application runs on several instances of Apache on the IBM i - most of these instances require http basic authentication, except for one instance that acts as the 'welcome page' so to speak. This 'welcome page' has no authentication, but acts as a navigation hub with links for the user to go to other parts of the app (which DO have authentication and run on different instances of Apache).
We also have some documentation stored in Confluence (a wiki application) that runs on a separate server. This wiki application can display the documentation without requiring authentication, but if you authenticate, you then have the option to edit the documentation (assuming you're authorized to do so, of course). But the key is that the documentation is visible without requiring authentication.
My problem is: we want the documentation in Confluence to be accessible from within the main application (both when being accessed internally and over the internet) but, because the documentation is somewhat sensitive, we don't want it accessible to the internet at large.
The solution we came up with was to use a reverse proxy - we configure the Apache instances on the main application such that requests to /help/ on the main application are proxied to the confluence application. Thus, the Confluence application is not directly exposed to the Internet.
But this is where the problem starts.
If we just proxy /help/ through the main application Apache instance that doesn't require authentication, then the documentation is available from the main application without a problem - but since you don't require authentication, it's available to everyone on the Internet as well - so that's a no-go.
if we instead proxy '/help/' through the main application Apache instances that DO require authentication, it seems as though the basic authentication information is passed from the main application servers onto the Confluence server, and then we get an authentication failure, because not everyone who uses the main application has an account on the Confluence server. (For those that do, it works fine - but the majority of users won't have a Confluence account).
(Possible yak shaving alert from this point forward)
So, it seems as though when dealing with HTTP Basic authentication, if you set up proxy configuration from server A to server B, and set up the proxy on server A to require http basic authentication, then that authentication information is passed straight through to the server B, and in this scenario, server B complains since it doesn't expect authentication information.
My solution to that problem was to set up 2 levels of proxying - use the Apache instances requiring authentication to also require authentication for the proxy to /help/, but have /help/ proxy to a different server (Server C). This Server C doesn't require authentication but is not exposed to the internet. And Server C is configured to proxy /help/ to the actual Confluence server.
I did this on the basis of proxy-chain-auth - an environment variable which seems to indicate that by default, if you have a proxy chain, the authentication information is NOT automatically sent along the chain.
Alas, this did not work - i got an authentication error that seems to indicate that Server C did in fact proxy the authentication info onwards, even though i did not set proxy-chain-auth.
So, that's my yak-shaving journey.
I simply want to set up a configuration such that our documentation stored on Confluence requires some sort of authentication, but that authentication comes from the main application, not from Confluence.
(Without the requirement of having it accessible over the internet, none of this would've been an issue since the Confluence server can be viewed by anyone on its network without a problem).
I hope my question is clear enough - I honestly don't mind being pointed in a different direction to achieve the main goal, with the caveat that I can't change the main application (or Confluence for that matter) from using HTTP Basic Authentication.
Ideas, anyone?
PS. To retrieve the documentation from the Confluence server, I'm actually using their REST API to retrieve the page content - i don't know if that has any relevance, but I just wanted that made clear in case it does.
It turns out that the solution to the issue was pretty straightforward.
For my second proxy that does not require authentication, I had to change the Apache configuration to remove any authorization headers.
RequestHeader unset Authorization
This stops the authentication information from being passed from the second proxy onto Confluence.
I have an IIS 7.5 on Windows Server 2008 R2. It has the Basic, Anonymous and Windows Authentication modes enabled. I have hosted a restful WCF service in it.
I make an http request with Authorization header from my client within the LAN/VPN, all goes well. On the service side I could see that the OperationContext.Current.IncomingMessageHeaders contains the Authorization header with the right value.
When I attempt to do the same from outside the LAN/VPN, (I used a different Internet connection and also a public proxy), the OperationContext.Current.IncomingMessageHeaders seems to have missing Authorization header.
I am unsure as to what exactly removes the header. I suspect a misconfigured IIS. Any clues?
If you want your service to always do windows authentication as the question seems to suggest, remove disable all other auth modes in IIS, requests from LAN are passing probably because people requesting it are from the same domain, in an internet (putting this simply) will go for the least required auth mode, which in this case would be anonymous.
I'm working on a project which requires delegation in a double-hop scenario. We have a desktop client, connecting to a WCF service using a net.tcp binding, connecting to a SQL database on another server. Our goal is to use the user's credentials to access the SQL database.
Both the WCF service and SQL database are running under the same domain user, which has delegation enabled for the SQL database. The instructions here have been followed, with no success.
Now, some details recorded in our logs:
The login used on the SQL database appears as the user the WCF service is running under, and uses Kerberos.
The login used on the WCF server appears as the client's user, but uses NTLM.
Using either [OperationBehavior(Impersonation = ImpersonationOption.Allowed)] or using (ServiceSecurityContext.Current.WindowsIdentity.Impersonate()) results in commands being run as the client, on the WCF server. This leads me to believe impersonation is working fine.
So, what could be causing the first hop to fall back to NTLM? We suspect it's a SPN issue, but we've registered the SPNs of both the WCF service and SQL service to the shared domain user. Also, as per the instructions listed above, we've set the SQL service as trusted for delegation on the domain user.
We've used EndpointIdentity.CreateSpnIdentity on the WCF service to set the SPN, and this is the SPN we've registered to the domain user.
Any suggestions? Thanks in advance!
Edit:
We've found something that may have been an issue - We had not used EndpointIdentity.CreateSpnIdentity on the client. After setting this we receive the error
“call to SSPI failed” with an inner exception of “target principle name is incorrect”. But the SPN we've set in the client and the server match, and both match the hostname of the service. If we set both the client and the server SPN to something completely different, or if the client's specified SPN does not match the server's SPN, authentication falls back to NTLM as it did before. We've done research into the error, but cannot find its cause. Any suggestions?
We've also performed packet captures of both cases - falling back to NTLM and when we receive the "call to SSPI failed" error. In both cases, similar packets are sent and received until, on one, NTLM is mentioned. On the other, a "TURN CHANNEL" packet is sent from the client to the server. The packets contain nothing human readable except the IP address of the server until either NTLM is mentioned, and the username and computer names are sent, or the "TURN CHANNEL" packet is sent, which contains what appears to be the SPN, and possibly the hostname. There doesn't appear to be any human readable error codes or error messages. Any suggestions on what to look for in the packets?
We found our error - the client was creating the connection using the IP address of the server. After switching the IP to a fully qualified domain name, the first hop consistently authenticates using Kerberos.
The IP address resolves to the same string we used in both SPNs, but I suppose the client checks if the connection string matches the portion of the SPN following the slash before performing any other checks.
We tested our results using both Network Service and our domain user, and as long as the SPN was registered to the computer or user respectively, there were no issues.
Hopefully this answer will save others some time and hassle!
Additional Note: While this enabled Kerberos authentication for all connections, we later discovered that this was unnecessary in our situation. Part of our connection to the database was not inside the impersonation using block, which was causing the table read to fail. We have since removed all delegation and SPN related code, and the database connection continued to work correctly. Our first hop is using NTLM. We're not exactly sure how the credentials are being used at the SQL server, as our connection appears to be exactly what is described as the double hop scenario, which should require Kerberos and delegation, but it's hard to argue with what's working. I suspect it may have something to do with the note located under delegation in this document:
When a client authenticates to the front-end service using a user name and password that correspond to a Windows account on the back-end service, the front-end service can authenticate to the back-end service by reusing the client’s user name and password. This is a particularly powerful form of identity flow, because passing user name and password to the back-end service enables the back-end service to perform impersonation, but it does not constitute delegation because Kerberos is not used. Active Directory controls on delegation do not apply to user name and password authentication.
If anyone has any other suggestions for the reason it's working, I'd love to hear them. However, I don't feel it's worth opening another question for.