Hello,

I have some questions which I will describe here below.

Say I have an ADFS server on my internal network and a ADFS Proxy in my DMZ. I configure ADFS for single sign on with a third party application (SAP Cloud for Customer in this case) and all my internal devices have single sign on access. Should work.

Now, I have a couple of users with Windows RT and Windows Surface Pro tablets externally. They connect through local Wifi connectoins (for example in a super market) to the third party cloud application. I also want to setup single sign on for them. My issue is here that they should be able to access the ADFS server on the internal network in order to single sign on to the cloud application, am I right? That creates the situation where they should use a token (SSL vpn) to connect to our network first and then they are able to use single sign on for the third party cloud applications, am I right? Or is there any other way to do that.

I think that it would be best to deploy direct access to get this to work flawlessly. That would be best right? Or is there any other smarter way? I have thought of configuring ADFS in Azure, I can extend my AD to azure and then configure and ADFS server there, but that would be same thing as setting it up on-premise and bypassing the DMZ. I could create a DMZ setup in Azure, but then I would still have the same issue as I have on-premise I would assume. Am I right about this or are there any other smarter tricks to get this to work for external clients?

• Edited by Niels Wes 23 hours 25 minutes ago

My issue is here that they should be able to access the ADFS server on the internal network in order to single sign on to the cloud application, am I right?

No. Your SSO experience will work for users from external networks as long as your ADFS is published and accessible to them. You will have SSO as long as you access ADFS-Integrated applications from the same Web browser (That way you do not kill the session cookie for SSO).

Hi Ahmed, thanks for your reply! Aha, ok! But off course, if I use the same URL as internal via split dns then clients can look it up internally and external. Am I correct with regards to ADFS? Secondly, the way this works is that external (domain joined, workplace joined) clients request access via their web-browser, the application redirects them to adfs.company.com and then clients connect to the internet facing interface of the ADFS proxy and they then connect to the internal ADFS. Correct? Does the ADFS proxy authenticate on behalf of them or does it really redirect them like a reverse proxy (without pre-autentication)? 

Hi Ahmed, thanks for your reply! Aha, ok! But off course, if I use the same URL as internal via split dns then clients can look it up internally and external. Am I correct with regards to ADFS? 

Correct.

Secondly, the way this works is that external (domain joined, workplace joined) clients request access via their web-browser, the application redirects them to adfs.company.com and then clients connect to the internet facing interface of the ADFS proxy and they then connect to the internal ADFS. Correct? 

Yes. Your ADFS proxy servers will allow the communication with the internal ADFS servers.

 Does the ADFS proxy authenticate on behalf of them or does it really redirect them like a reverse proxy (without pre-autentication)? 

It is like a reverse proxy.

Hey Ahmed! Thanks for the quick reply! Iam a little bit confused by your 2nd and 3rd anwser. Your question "Your ADFS proxy servers will allow the communication with the internal ADFS servers?" sounds to me that I am trying something that is not possible, not designed to work that way or not very wise to do? :-) I thought that that is necessary for ADFS to build a claim. That is where your anwser on my third question comes into play. If it is like a reverse proxy, then they should have access to then internal servers. Right? Or am I missing something here?

It is like a reverse proxy.