So we're finally moving to Windows Server 2019 from 2008 R2 and the new ADFS requirements are that ADFS stays behind a firewall and the Web Application Proxy will be exposed and forward any authentication requests to the actual ADFS server. So far so good.
But our initial ADFS setup did not use subdomains. So we don't have the luxury of just moving eg. sts.domain.com to a new server. Our web server, database server and ADFS server were all responding to www.domain.com. ADFS v2 was an application under IIS after all. Poor planning, but here we are.
So now we have 2 new production servers both running Windows Server 2019. One exposed to the internet running the Web Application Proxy and the actual ADFS server behind a firewall. All the settings, relying party trusts and claims providers have all been migrated with Microsofts bundled scripts. All good. But our ADFS is behind a firewall and the ADFS is configured to respond to www.domain.com and the federation service identifier is equally www.domain.com/adfs/services/trust.
If i set it all up with sts.domain.com externally pointing to the WAP and internally they both think the ADFS is sts.domain.com it works just fine. I can connect, it fetches metadata and lists Claims Providers.
But when i try the same trick with www.domain.com it fails.
So I've been trying to fool the ADFS server and edited hosts files so the ADFS server thinks it's www.domain.com and the web app proxy also thinks that the ADFS server is www.domain.com internally. But obviously still responding to web requests on www.domain.com on the external interface. But when i do that the WAP refuses to connect to the ADFS server.
What gives?
Related
I'm using haproxy to load balance more than one .net applications. IIS servers cofigured for running https and haproxy too. There are only one self signed certificate, and it's subject contains all of iis servers ips, domains, and haproxy servers too. I'm using ntlm to authenticate user and I want to switch it to kerberos.
I made an spn record for iis and ha proxy servers. And start all iis for same user.
When I want to go to IIS server directly, i can see the kerberos ticket on the traffic. But when i want to go with haproxy, i cannot see kerberos ticket. Is there any configuration for haproxy to pass kerberos?
ADFS server 2016 supports openId connect. I have external organization that hosts ADFS server , I want my web application to get authenticated from External ADFS server using openIdConnect .
Question : As per Microsoft docs . If we want to consume external organization's ADFS we should host ADFS in our organization also. My application should trust ADFS hosted inside my organization ,instead of trusting external ADFS directly.
Here I want to know why we cannot directly trust External ADFS using opendiconnect ? It seems possible. what is reason of not trusting external ADFS directly?
Both models work. If your application plans to have users from multiple organizations, it is better to have your app trust an internal org ADFS which can then be federated to multiple of these organizations with simple configuration changes. This makes the application simpler where it is dealing with only one IDP. An additional advantage for having an internal ADFS is that any authentication policy changes can be managed fully at internal ADFS layer and not potentially requiring application changes.
However, if your application is only going to support one external organization, you can do this directly in the application. Both models work for this.
Hope that helps.
Thanks //Sam (Twitter: #MrADFS)
I use Oauth2 to access a database in a cloud.
The code is developed in .net core 2.0.
The redirect urls are:
"AuthRedirectUri": "http://localhost:44378/auth/callback", "PostRedirectUri": "http://localhost:44378/myapp/Index",
I get connected to the database when the app runs on the visual studio (iis express). However, when the app is published on the local server (Windows Server 2012.R2) I receive an "invalid request" message from the third party web app. The published app is on http://localserver:80/. The solutions I have found in the web are redirecting to the localhost which doesn't work in my case.
Which hostname/port should be used to receive the callback code on the server? Shall I change anything in the iis or the server?
The solutions I have found in the web are redirecting to the localhost which doesn't work in my case.
Which hostname/port should be used to receive the callback code on the server? Shall I change anything in the iis or the server?
As far as I know, the redirect url should be your application's domain or IP address which could be access by someone outside your server.
Normally, we will use your server's public IP address and add your IIS application's port as the url(If you have the domain, you you should bind this url with domain address).
I suggest you could find this url and access from internet to make sure you could access the web application.
Then you could use this IP address and port plus sepcial fomat as the redirect url.
We have a running ADFS Service with Office 365 on one of our production box. Now we want to expose our ADFS to ASP.NET Applications as well. My understanding is that I have to install ADFS Web Proxy to do it.
My question is, Can I do it on the server where ADFS service is configured? or Do I have to have a separate server?
No - you have to have a separate server.
Typically the Web Application proxy (WAP) is in the DMZ while ADFS is behind a firewall.
In general, adding ASP.NET claims-enabled applications to ADFS does not require installing WAP.
Are these non claims-based? External?
Our IT staff refuses to install the SiteMinder agent on our application's IIS 6.0 web server, citing security concerns as it is a third-party software, as well as the possibility of high resource utilization impacting application performance.
They suggest that we set up an independent, segregated web server containing only a bare-bones IIS, the SiteMinder Agent, and a "shim" to authenticate login attempts.
This shim would be a single ASPX page marked to be protected by the agent. It would use the SiteMinder agent to authenticate the user ID, look up the user ID in the application's database, and return the user ID and password to the user's browser. A JavaScript function would then POST the user ID and password to the application's existing login page as if they typed it in themselves.
Are their concerns warranted? Why or why not?
Have you ever heard of anyone implementing a similar architecture?
Is their proposed solution good, bad, or ugly?
It does not look like it would work, because the agent manages not only the initial login, but subsequent calls to the application, i.e. authenticated session. The agent examines the cookie, validates it, etc. Your scenario does not describe how that would happen.
In our environment, all internet traffic goes through an Apache reverse proxy before hitting IIS. IIS is behind firewall. The Apache reverse proxy has the SM agent all it does is redirect the traffic to IIS. I suppose it would be feasible to do a similar setup with IIS acting as a reverse proxy.
BTW, tell your IT guy that his proposed shoestring and bubblegum login solution is a much bigger security concern than installing SiteMinder on IIS.
The apache reverse proxy solution will definitely work, but with SiteMinder r12.51, Secure Proxy Server is included, which is basically SiteMinder's version of a reverse proxy (plus a lot more).
SPS will let you configure a single server as a "gateway" for all of your applications that can't or won't install a SiteMinder agent. The web agent is embedded in SPS and a proprietary Java app does the heavy lifting. SPS also has a GUI which follows the look and feel of the r12 WAMUI, which makes configuring it very simple.
Secure Proxy Server also has a Federation Gateway feature, so you don't need to install the web agent option pack if you are doing SAML Federation. All of your fcc pages can also be served by the SPS, so you can reduce the number of webservers needed to support your SSO environment.