locked
ADFS access from the internet RRS feed

  • Question

  • I have configured ADFS on a Windows Server 2012 VM. When I connect, I am able to access the metadata (to eventually use it as a single sign on service) when I put a path like this. I did the whole thing on the new azure portal.

    https://localhost/FederationMetadata/2007-06/FederationMetadata.xml

    Upon seeing the contents of the xml file, I get a full domain which looks something like this, and using which I am able to once again access the exact same metadata file as above.

    https://somevmname.somedomain.com/FederationMetadata/2007-06/FederationMetadata.xml

    somevmname = my vm name

    somedomain = the domain name I am using.

    Now, if i try to use the above url, outside the VM itself, I cannot touch it. Hence, i cannot use it for single sign on. Now, the question is, how to I make this ADFS available outside?

    For instance, when I try to create a onpremises single user authentication visual studio solution, it will give an error saying that the metadata is not accessible. How do I overcome this?

    Is this where the ADFS proxy enters the picture?
    • Edited by Jay_Technet Wednesday, May 31, 2017 11:48 AM got some additional info that will help others to help me.
    Wednesday, May 31, 2017 11:46 AM

Answers

  • Ideally you would use a public namespace for the URL of your ADFS deployment and manage the internal clients name resolution with a split-brain DNS. This is explained here: https://docs.microsoft.com/en-ca/windows-server/identity/ad-fs/design/ad-fs-requirements#BKMK_7 in the DNS Configuration section.

    In a nutshell, when you internal clients want to reach https://adfs.contoso.com/... they will use the internal DNS server which resolve it to the internal IP address of our ADFS server (or to the VIP of your load balancer in you use any). When you external clients want to do the same, they will use the public DNS and resolved adfs.contoso.com with the external (public) IP of your WAP server (aka ADFS proxy).


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    • Marked as answer by Jay_Technet Thursday, June 1, 2017 8:20 AM
    Thursday, June 1, 2017 2:10 AM

All replies

  • Ideally you would use a public namespace for the URL of your ADFS deployment and manage the internal clients name resolution with a split-brain DNS. This is explained here: https://docs.microsoft.com/en-ca/windows-server/identity/ad-fs/design/ad-fs-requirements#BKMK_7 in the DNS Configuration section.

    In a nutshell, when you internal clients want to reach https://adfs.contoso.com/... they will use the internal DNS server which resolve it to the internal IP address of our ADFS server (or to the VIP of your load balancer in you use any). When you external clients want to do the same, they will use the public DNS and resolved adfs.contoso.com with the external (public) IP of your WAP server (aka ADFS proxy).


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    • Marked as answer by Jay_Technet Thursday, June 1, 2017 8:20 AM
    Thursday, June 1, 2017 2:10 AM
  • Overnight, I continued working on this and I realise the mistake I had done. As you have suggested above, yeah, I should use a public namespace for the URL for the ADFS deployment. 

    I am doing the whole thing on Azure, and the confusion happened because in the classic azure portal, a public facing DNS was automatically (in fact it was mandatory) assigned to VMs. In the new modern azure portal (which is where I setup everything), DNS is optional so I ended up using a fake domain name as I went through configuration. 

    Yes, I will go with the ADFS proxy as well. Thank you. For now, this has helped me :) 

    Thursday, June 1, 2017 8:20 AM