Intranet and Extranet SSO and Usability Project - Part 1
by, 20th January 2013 at 09:02 PM (7184 Views)
Its been a long time since I last wrote about Sharepoint - the platform for our Intranet; but now with the rest of the ongoing projects nearing completion - I've been able to return to this monster of a project.
So, lets go back to the start and show what the end goal was.
1. Intranet Portal - containing Departmental, Staff and Student Areas. Department areas would have staff and student storage as well as news, events, discussions, blogs and all the usual suspects
2. Booking System - does what is says on the tin, web system for booking rooms and resouces
3. Helpdesk System - does what is says on the tin, access to our existing online ICT helpdesk system
4. SSO (Single Sign On) - enter username and password once for all services, and transparently log in to all the others
Progress to date
Progress was good! The web based helpdesk (GLPI) was installed and has been in use for over a year now. Sharepoint was installed as a farm, and branded up with custom designed Academy theming. All the departmental and staff areas were added, and the supporting Active Directory groups put in place. The excellent Home Access Plus is being used successfully for bookings - and we work with the team to tweak the development.
Forefront TMG was installed to replace the out of date ISA 2006 software. This gave the SSO we wanted - but also presented a challenge. Externally - we wanted the logon dialog presented; but not internally. This actually started to become a bit of a barrier to adoption... and thats where this blog post picks up the story.
So, some of you may have seen this term "split dns" banded around before. Well - that is what you need here. In simple terms, split dns allows your dns server to respond and act as if it was authoritative for a domain other than the name of your Active Directory domain. Take the following example:
Domain Name: school.internal
External Name: school.authority.sch.uk
Now, your external access will likely come through an address such as webmail.school.authority.sch.uk or gateway.school.authority.sch.uk.
What you need to do is add the domain "school.authority.sch.uk" as a forward lookup on your dns server. Once we've created the zone, we can then add the hosts that we want to internally resolve. Any hosts that we don't add to our own copy of the "school.authority.sch.uk" domain will have their requests sent out onto the upstream local authority/internet provider dns servers as normal. If you want to find out a bit more about this, and what it all really means - then there is a great write-up of it here http://www.isaserver.org/tutorials/y...split_dns.html.
Lets create a new dns zone for "school.authority.sch.uk"...
1. Load up the DNS administration snap in, and browse down through one of your dns servers followed by "Forward Lookup Zones".
2. Right click on "Forward Lookup Zones" and choose new zone. This will start the wizard. Click Next.
3. We will be creating a "Primary" zone, so select this. Also, ensure that the "Store in AD" check box is selected. This will ensure that all AD DNS servers will respond to requests for the site. After clicking next, you should also select the option for all DNS servers in the domain for the same reason.
4. Next up, its time to enter the DNS name itself. If you are wanting your internal network to resolve webmail.school.authority.sch.uk; then the dns name is "school.authority.sch.uk". Enter this here.
5. We all know about DNS security (don't we?) - so the obvious choice on the next screen is "Secure transfers only" - back to how dns gets updated in step three. Only secure updates should ever be used on AD domains. Choose it, click next and then finish! That's it... simples??
Well - yes, but at the moment - our split dns doesn't actually do anything. We haven't got any hosts in yet, so all requests still go out to our isp.
1. Choose our newly created zone, and right click.
2. From the popup menu, choose "New Host (A)". This will present the new host entry screen.
You will need to know the internal ip address of your host to publish at this point. For me - that was simple - its our ISA/TMG server. Why? Well, remember right at the top of this article.... all our services are published via our ISA/TMG box. Ensure at this point you also enter the name as used externally too (so this would be webmail or gateway in our example... nb, you don't need to put the rest of the address in as that is the dns domain).
Internal SSO without logon dialogs
So, the last bit needs some changes on TMG. We need a new web listener, which will be waiting for incoming requests only from the internal network. 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).
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.
That will be the subject of the next post - as will the playing with the three-headed dog that is Kerberos!
Also in the writing is my BETT preview post; and following that, some interesting interviews from BETT 2013 itself.
Total Trackbacks 0