SSO using Microsoft ADFS with Windows Integrated Authentication - which ports?

[Dieselboy]

As far as I understood, authentication is between the client and the ADFS server on either HTTP or HTTPS depending on how it's set up. I have HTTPS set up. So I take it that client <-> server communication is on HTTPS tcp/443 only?

I found one website that said there are other ports (but doesn't list them), and I've found all other websites that say it's only on HTTPS. Does anyone have more insight into this? It's confusing me.

[deanwebb]

There are other settings that need to be in place for this to work. https://blogs.technet.microsoft.com/abizerh/2013/04/11/more-information-about-sso-experience-when-authenticating-via-adfs/

Check on those. If any need fixing, fix them all and try again. If, after verifying that all the settings are correct, it then doesn't work, we can poke around for more ports.

EDIT: More neato stuff: https://support.microsoft.com/en-us/kb/2535227

[Dieselboy]

Thanks I found these links before but they don't go into the detail I need.

The reason why we stick to form based authentication when going via the proxy is because it just requires the SSL port 443 to be exposed. We cannot do Windows Integrated Authentication over the internet, because the ports and services required for it cannot be exposed to the internet.

Which ports and services? Because as far as I can see, the only port is HTTPS 443 for the SSO URL. The client / end user contacts the SSO URL for authentication. Once completed the client then goes back to the "service" it was trying to access originally with the token received from ADFS SSO. There isn't any communication between the client and ADFS on other TCP ports. There isn't any communication between the client and a domain controller for ADFS to work. Of course ADFS and domain controllers have unrestricted access to each other on the same subnet / LAN.

I do have Integrated Auth. working via the internet, without a proxy, using only HTTPS 443. But sometimes it does not work for one application and I'm trying to find out more details to find out why.

I've not really been able to find any detail on how this works exactly, apart from what I've already described.

[deanwebb]

That application may require another port. The WIA works with just 443, like you said. It's that one app.

If that app requires other AD ports open, then you basically open up half of all the high ports and about 30 others below 32000.

What does the network trace show?

[Dieselboy]

Thanks If it does require extra ports then I'd just put a proxy in the DMZ.

The documentation states it only requires HTTPS 443 to ADFS. The app. is Cisco Jabber.

The network trace shows normal communication on TCP 443. Although I didn't look too long for other traffic / connection attempts. I can do this again and look further, but didn't want to waste time unnecessarily without at least being armed with some idea of what to look for.

Debugging the HTTPS, the ADFS responds with a 401. I had suspected there being an issue with Jabber pulling the credentials and passing them to ADFS. If ADFS was receiving the credentials correctly then it would not respond with a 401.
I asked them if they could show me that Jabber is successfully pulling the credentials from the logged in user account, and successfully providing them to ADFS, thinking software bug. I have seen in the debug logs on the Cisco side that incorrect usernames are attempted. I don't know why.

Their response:

The development escalation contact seems to be asking whether you could provide any evidence of exactly why the ADFS the server is sending Jabber the "401".   Apparently, "Jabber does not support the server sending it a 401 error".

I do see your earlier statement that "The issue is simply that Jabber is not providing the correct credentials to ADFS"... but would like to understand myself what evidence you have of this.

Their response did frustrate me a bit.

"Jabber does not support the server sending it a 401 error" -> why not? If authentication is incorrect, jabber just crashes? To be honest, when authentication is incorrect (done on purpose) Jabber just gives a message "Page cannot be displayed". Although this could be looked at as a security feature.

"I do see your earlier statement that "The issue is simply that Jabber is not providing the correct credentials to ADFS"... but would like to understand myself what evidence you have of this." -> well, I thought a good start was the 401 response.

Still, I'm happy to look at all avenues / cover all bases in case I am wrong.

[deanwebb]

See if Skype/Lync works.

If it does, welcome to the world of implementing Microsoft competitors on Microsoft platforms.

[icecream-guy]

Try modifying the firewall to permit ip any any for communications between Microsoft servers. This is a the recommendation from Microsoft (if you want support).

[deanwebb]

Bit of truth to that... but if it works, the security solution is not to leave it that way.

[Dieselboy]

The servers are on the same LAN and are not separated by a firewall. I'm not using MS Lync, only Cisco Jabber.

The issue is authentication from the client to Cisco Jabber Remote Access (VCS) servers. From everything I have read, the client only needs to communicate with ADFS for SSO on tcp/443 which is what is allowed (and what is working for 99% of people). Occasionally, the ADFS server sends a 401 error in response back to the client. I'm trying to find out if the client needs access to anything else which is the cause of this occasional failure. The one link mentioned below, does mention "other ports" but there is absolutely no information anywhere about this. So I take it that the note in that link is not factually correct and is only a mention just in case.

Therefore I will keep pressing on that the cause of the 401 response from ADFS is that the credentials are not being passed automatically to ADFS from Cisco Jabber. Since I cannot even see a username in the ADFS logs I take it that the username is incorrect.

Dean, I understand the risk is having ports open from the internet to the inside network / especially a domain controller. The ADFS system is not a domain controller but it is domain-joined. The port is 443 / encrypted and there are other security measures in place. It's a bit of an iffy situation, where some people will say it's fine and some people would stamp their foot.
I've seen many MS Exchange implementations that have OWA access from the internet straight to the Exchange server, dating back to 2007. I'm not saying that is the best or correct way to do things, but you can get away with that. If money is no object, time is no object and engineer time is also no object then the right way to do things is a proxy in the DMZ.

[deanwebb]

OWA since 2000 involved a HTTPS proxy in the DMZ that would then send the MAPI commands back to Exchange.

I mentioned Lync because it wouldn't be the first time an MSFT product succeeded where a competitor's failed. They have access to code snippets that not everyone knows about.