The online documentation is all about port requirement between the outside and the WAP/ADFS. And in that regard, you don't need the port 80.
I guess you refer to the Metadata Monitoring of your Azure AD relying party trust (for any other port requirement with Azure AD, please refer to this document:
https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-ports/ which indeed mention CRL access). It is not a requirement since metadata can be updated manually. The ADFS server try to access the URL:
https://nexus.microsoftonline-p.com/federationmetadata/2007-06/federationmetadata.xml (this is the URL in my lab... Build a long time ago, maybe yours is different, you can check from the GUI). So in my case I need to be able to check the certificate revocation
status for the TLS cert of
https://nexus.microsoftonline-p.com/ which is:
[1]CRL Distribution Point
Distribution Point Name:
Full Name:
URL=http://mscrl.microsoft.com/pki/mscorp/crl/msitwww2.crl
URL=http://crl.microsoft.com/pki/mscorp/crl/msitwww2.crl
But as well the AIA to check the issuer cert validity:
[1]Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://www.microsoft.com/pki/mscorp/msitwww2.crt
[2]Authority Info Access
Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
Alternative Name:
URL=http://ocsp.msocsp.com
But this certificate has been issued by another CA, so I also need to be able to access the other CRL and AIA of the chain. Etc... The challenge is often how can my ADFS even do that? Some ADFS server don't even have external name resolution. One option
is to opt for a WinHTTP proxy configuration. See there:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa384069(v=vs.85).aspx
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.
