Setup:
Server 1: ARR Reverse Proxy
Server 2: App Server
Server 3: Identity Server (Identity Server 3).
Both the App Server and Identity Server are behind DMZ and accessible only via Reverse Proxy.
App Server redirects unauthenticated requests to Identity Server for AuthN.
Identity Server uses Active Directory as Identity Provider.
Application uses OpenIDConnect as the AuthN Middleware.
All the URL Rewrite rules are working properly and the redirections happen correctly.
Browser popup asks for credentials after redirection to Identity Server (401 challenge). After entering the credentials ARR returns 502.3 (Server returned invalid response) error. Response to 401 challenge is not even sent to the Identity Server. ARR throws the above error.
Error in ARR IIS Log: 502.3 sc-win32-status: 12018 (The type of handle supplied is incorrect for this operation).
Any pointers will really help.
Thank you
There are up to 65,535 ports.
For me, using port # 80'000 (by mistake) for reverse proxy caused the 502.3 error
Related
We have a client that connects to a web service (service1.svc) with the URL https:\destination.domain\Service1.svc. This web service connects to a second web service (service2.asmx) with the URL https:\localhost.domain\service2.asmx. Both service are hosted on the same webserver. The DNS on the Domain controller sets destination.domain to point to the IP of webserver and localshost.domain to 127.0.0.1. The application pool account is a global service managed account that is configured to allow delegation and is called webserveraccount. The application pool is configured to use the appPoolIdentity.
We see a 401 autherisation error connecting to the second webservice (service2.asmx). I have also see the a KDC_ERR_BADOPTION which makes me this our SPN configuration is incorrect. What would the correct format for SPN in the above scenario? Or is this not a kerberos related issue?
We have a couple of back-end web applications to which we want to provide access via the public internet. To that end, we are setting up a reverse proxy (IIS 7.5) from our DMZ. At the same time, we want these web applications to be claims-enabled through ADFS 2.0.
WEB1.MYCORP.COM/WFE1 is the other back-end web application, on our internal network
WEB1.MYCORP.COM/WFE2 is the other back-end web application, on our internal network
ADFS.MYCORP.COM is the ADFS 2.0 server, on our internal network
FSPROXY.MYCORP.COM is the ADFS 2.0 proxy server, on our DMZ
RPROXY1.MYCORP.COM is the reverse proxy for WFE1, on our DMZ
RPROXY2.MYCORP.COM is the reverse proxy for WFE2, on our DMZ
In keeping with the proper configuration of ADFS, our internal DNS resolves ADFS.MYCORP.COM to the actual internal server, while external DNS points ADFS.MYCORP.COM to the ADFS proxy (FSPROXY).
So, here's the scenario:
End user browses to RPROXY.MYCORP.COM
Reverse proxy forwards request to WEB1.MYCORP.COM/WFE1
WFE1 redirects browser to ADFS.MYCORP.COM (actually FSPROXY)
ADFS Proxy prompts for credentials and authenticates against ADFS server
Upon successful authentication, browser redirected back to web app
I have a couple of questions. Do I need to configure something in the rp or the application to allow this. Also the adfs endpoint is the rp url is that an issue?
Do I need to set up something for the reverse proxy as well? (Should I/can I) set up a claims-enabled reverse proxy in IIS? How do I set up the reverse proxy rules to pass back the ADFS request unaltered? Currently, when I try to access the back-end application, it fails with a 401 authentication error. If I remove the proxy and just hit the app server it works fine.
Further,
This fails:
The path is client --> rp -->app -->adfs --> rp -->app --> rp -->client machine
this works:
The path is client -->rp -->app -->adfs -->app -->rp -->client machine
Any suggestions would be greatly appreciated!
Not familiar with how you enabled reverse proxy in IIS (ARR?). Something like this http://blogs.iis.net/carlosag/setting-up-a-reverse-proxy-using-iis-url-rewrite-and-arr
One choice for you is to use ADFS 2012R2 (if possible) because the proxy in that, the Web Application Proxy, handles both ADFS authentication and can handle app publishing for your claims enabled application. There are 2 ways you can publish your app to the internet. Once is pass-through which is kinda what you are trying to do. But it also allows pre-authentication support for a claims aware app. This way, you can have a different policy that decides whether the application can get pass your EDGE network before a packet goes to your internal application.
After doing lots of digging and fiddler traces I found the issue. In testing idp setup the token was different then stage env. The fiddler traces showed that the token was making it back to the app server. The issue was it also looked like the cookie dropped off for no reason. The issue was because the old dev ipd value disagreed with the stage value...naturally. Once I cleared the old token from the database everything worked.
I have a web app running on Server A that calls a WCF service (K2 Workflow) on Server B that requires impersonation/delegation to run as the calling user. If I run the web app from Server A, the app works great. If I run the app from my local PC in debug, it also works great. If I hit the app from a browser on my PC to Server A, I get the following error:
The HTTP request is unauthorized with client authentication scheme 'Ntlm'. The authentication header received from the server was 'Ntlm,Negotiate'. System.Net.WebException: The remote server returned an error: (401) Unauthorized. at System.Net.HttpWebRequest.GetResponse() at System.ServiceModel.Channels.HttpChannelFactory`1.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout).
I use the following code to run the service:
SvcWorklist.ClientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Delegation;
SvcWorklist.ClientCredentials.Windows.ClientCredential = System.Net.CredentialCache.DefaultNetworkCredentials;
I feel like I've done everything, here is a list of what I've tried:
Setup a SPN (including port) with by Server A App pool domain user to Server B
(NETBIOS and FQDN)
Set the same domain user as the app pool user on Server A and B
Ensure the app pool user is allowed to delegate in Active directory
Ensure both servers are allowed to delegate in AD
Set authentication to windows and impersonate=true in web.config on Server A
Ensured Thread.CurrentPrincipal.Identity.Name has my user ID
Ensured IIS is set for windows and impersonation
Tried restricting the IIS configuration on server A and B to only Ntlm and/or Negotiate
Any help or ideas are truly appreciated.
For the dude who had the same issue - I figured it out. I had the SPN set on the target service, not the service it's hosting. I also needed to set sharepoint to use negotiate versus ntlm.
I have an api (running in a jetty instance) where I use two-legged oauth protocol to give access to the clients. I wrote a simple java client (using oauth-signpost) to connect to the api and the connection is successful.
I would like to put the api behind an apache http server. The apache http server is configured to forward request to api.
The following works:
(without oauth) Client ---> Apache HTTP Server --> Jetty
(with oauth) Client ---> Jetty
The following doesn't work:
(with oauth) Client ---> Apache HTTP Server ---> Jetty
I receive the following error message
"Invalid signature for signature method HMAC-SHA1"
Has any of you faced this issue? Is it possible to sign the request but without the hostname and port?
Thank you.
I had a similar problem. The problem I found was that the OAuth signature and the OAuth header block need to have the Jetty URL, not the Apache URL.
I had to modify my code to pass along two URLs. The URL I was sending the request to (Apache) and the URL of the resource on the final system (Jetty URL).
I have the following setup:
Server machine running a WCF service exposed via an IIS application that requires Windows authentication.
A proxy server (Squid) requiring Windows authentication.
A client machine running a Windows service which tries to make a connection to the WCF service through the proxy server. The service is set with a domain account credentials.
All machines are on the same domain.
If I drop the proxy from the setup and set just the following properties on the client security binding, all works well:
SecurityMode = TransportCredentialOnly
Transport.ClientCredentialType = Windows
The connection is made successfully and the correct credentials are passed to the server.
If I add the proxy but drop the required Windows authentication on the proxy server, everything works fine too. The only setting I change here on the security binding is:
ProxyAddress = http://myproxyserver:3128
I can see the calls go through the proxy server with the correct credentials.
The problem is that when I set the Windows authentication requirement on the proxy server, the proxy server returns 407 error. When I check the log files, I can see there is no second attempt to respond to the 407 error with the correct credentials. The setting I add is:
Transport.ProxyCredentialType = Windows
Things I tried and didn't work:
Set UseDefaultProxy - since this is a Windows service, it doesn't accept the default proxy.
Manually set Windows Credentials in ClientCredentials.Windows (including domain).
Add default proxy in app.config and machine.config.
Any ideas on what's going on and how to fix it?
Two things that might be the problem. First, and I can not be sure about this as I have not tried using a Windows credential with TransportCredentialOnly, is that transport security tends to be point-to-point. That means that an intermediate service, such as a proxy, would have to authenticate your transport credential itself, as well as reestablish the appropriate credentials for its repeat of your request to the real endpoint. Again, I am not certain how this works with a Windows credential...but given that it is a transport-level security setting, I would be doubtful that it can pass through the proxy without additional setup to ensure the proxy repeats the appropriate credentials. (Keep in mind, doing so effectively nullifies your security at the proxy...which in a controlled setting is not a problem, but can be in a real-world scenario.)
Second, the transport child element of the security element for your binding configuration should have a proxyCredentialType setting. If your proxy is interfering with your security, you may need to authenticate against the proxy itself. The proxyCredentialType setting defines what kind of proxy credential to use to authenticate against the proxy itself. You would then need to supply proxy credentials before you send your message.