Intranet and Extranet SSO and Usability Project - Part 2
by, 27th January 2013 at 06:07 PM (8938 Views)
This post is a continuation of my battle to compelte a cohesive intranet; and some more ramblings about Sharepoint. Its turned into a monster of a project this one. The external single sign on (SSO) was a breeze - thanks to Forefront Threat Management Gateway (TMG) - but this presented an issue - internal or external, you would be faced with a logon screen. Not ideal - internally we wanted a double SSO which would use your Active Directory logon session to SSO with the TMG HTTP session.
Lets pick up that story....
A quick review
Where did we get to? We had just finished with creating our Split DNS infrastructure - and Id outlined the need to then play with your web publishing and listeners in TMG.
We need a new web listener, which will be waiting for incoming requests only from the internal network. As you probably already know, a Web Listener is a software component that is used by Web Publishing Rules. The Web Listener accepts incoming connection requests for published Web servers. Web Listeners define the authentication methods that can be used by the TMG firewall to authenticate users before the connections are allowed to the published Web server. This is often referred to as “pre-authentication”. There are many security advantages to pre-authentication and if your site requires authentication, you should always take advantage of this option.
TMG Configuration - Step by step...
1. On the New menu, click the Web Listener option - which brings up the Welcome to the New Web Listener Wizard page
2. Enter a name for the Web Listener here. In this example, we’ll name the Web Listener HTTP Listener, with the intent that this Web Listener will be used for accepting incoming connections to using HTTP Authentication.
3. To match up our external to internal (really just to not confuse users - and think here, we are using HTTP authentication; you should really use some kind of encryption for security) you should ensure that you choose "SSL".
4. This will need HTTP authentication not forms authentication (which our external network will be using) - this allows it to use the same details that TMG/ISA itself is using to recognising our clients already for things like proxy (if you are using it).
NB-Image from the "Edit Properties" version, rather than the Wizard screen - so your screen may look slightly different)
5. Next up is telling this listener to only wait for traffic from our internal NIC. So - in the image below - you will see Internal network is selected only. Your other external listener needs to have Internal de-selected, which you can change by editing its properties.
That finishes off your listener configuration.
We than also need to change our existing rule so that it only listens on the external network. That's not where it ends though - as we then need a load of new publishing rules for our services to match up to our listener. This should be relatively simple though, as you can copy (select rule, right click and choose copy, and then right click and paste. I would then disable the copied rule while you do the editing.
Your new "internal" rules should be above your external rules so make sure you move them up. You also need to change the listener used in the new rule, and the authentication delegation. When you change to internal http listener services, you cannot use ntlm as your authentication method.
For things like Sharepoint and Exchange, this means moving to Kerberos. Now, from the Application point of view, this is quite easy to do. You will need to set up several srv records, and also allow TMG to act on behalf of your Sharepoint and Exchange servers when it comes to credential delegation. Sounds scary? Well, some of it can be if you haven't done it before. It also gets a bit more complicated if you are running a farm for these services, as you cannot authorise a server which to all intents and purposes doesn't exist.
The rest of this article will cover the TMG steps, the next one will cover the Sharepoint/Exchange and Kerberos side of things.
Kerberos Constrained Delegation (KCD) is a primary functionality of the Kerberos protocol introduced in Windows Server 2000 domain environments for authenticating users, services and computers. If a published Web server like the SharePoint needs to authenticate a user that sends a request to it and if the Forefront TMG computer cannot delegate authentication to the published Web server by passing user credentials to the published Web server or impersonating the user, the published Web server will request the user to provide credentials for a second time. ISA Server 2006 introduced support for Kerberos constrained delegation to enable published Web servers to authenticate users by Kerberos, after their identity has been verified by the ISA Server using a non-Kerberos authentication method. The same continued into TMG 2010. When used in this way, Kerberos constrained delegation eliminates the need for requiring users to provide credentials twice. To get Kerberos Constrained Delegation to work, we must change the Authentication Delegation method to Kerberos Constrained Delegation in the Forefront TMG Management console for the SharePoint publishing rule. The Service Principal Name (SPN) is host/InternalDNSFQDN of the SharePoint Server.
So, on the properties of the rule (make sure you are still working on your internal rule here, and don't break your external one), on Authentication delegation, choose Kerberos. You will then need to enter/amend the Kerberos SPN name.
Next up, in Part 3 will be the SETSPN tools you need to use to allow the delegation to work; how to check this - and also making the changes in Active Directory.
Total Trackbacks 0