Watchguard SSO Made Simple(er) Part 1

This is the first part in our guide in getting Watchguard Single Sign on working in your active-directory environment.
See here for links to Part 2 and Part 3

A quick introduction here might be needed. Watchguard routers have a fantastic set of tools for reporting and controlling user access, dataloss prevention, IPS and Malware protection but applying these rules to groups of users can be a very intrusive process. Say for example the HR deptartment needs access to a job listing site like seek.com.au but no other staff require access. You can apply polices based on groups, however the Watchguard needs to know who is who. Forcing users to attempt connect to the web, get redirected and authenticate on the proxy web page and then resume their activities. This has the habit of breaking things like Outlook and Lync as the Proxy presents an SSL certificate that’s not expected.

This page, gets really really old.

There are 3 solutions to this.

1.) Static IP addressing.
This isn’t really a solution for end users, but fantastic for servers and appliances that need access to WAN resources.

2.) Watchguard XTM Authentication Gateway without SSO Agent.
This installs on a server in your infrastructure and will attempt to open the event viewer of any machine that uses the proxy to see what AD controller they authenticated against and is usually pretty reliable after you push out some firewall exclusions.

3.) Watchguard XTM Authentication Gateway with SSO Agent.
This is the method I prefer to use. The Watchguard will look for the SSO client before falling back to the event log method. So if for some reason the SSO service stops the user isn’t completely cut off.

In all cases the Watchguard will eventually failback to forms based authentication if none of the above methods work. This will throw an “invalid SSL error” to your clients unless you correctly install a trusted SSL cert in your device.

Getting SSO working in your Active Directory environment

This article assumes you’re a group policy novice and doesn’t necessarily indicate best practice in your AD or Watchguard environment. If in doubt speak with your Microsoft or Watchguard Partners
If you already have software deployment polices there is no need to configure new shares / GPO’s you should just be able to edit the existing ones.
This does assume however you know your way around Policy Manger, If in doubt check out the XTM training on the Watchguard websitehttp://www.watchguard.com/training/index.asp

Download the SSO files from the Watchguard Portal

Head on over to Watchguard and login to their website. In the Knowledgebase under software downloads for your appliance you will find the downloads for the SSO Agent and Client.
Make sure you download the Client MSI and not run it, and lastly if you have a Terminal server you will need to download and install the “Terminal Services SSO agent” to differentiate between users on the same box.
(You can also grab both Agents from Rob Collin’s website, but he doesn’t have the end user client, yet)http://www.watchguardtechnologies.com.au/software/software.asp

Grab these files from the Watchguard partner portal.

Install the SSO Agent on your Domain Controller
Once the downloads complete kick off the “Wg-Authentication-Gateway_11_7.exe” on your domain controller, Follow the bouncing ball and ensure you tick the “Event Log Monitor” option.

Note: You need to install the “Event Log Monitor” on every domain controller but the agent should only be on one as this is the server the Watchguard will connect to submit lookup requests later.

Make sure to select the Event Log Monitor.

Continue through the installation until you are asked for logon credentials. As the blurb states the user must be a member of the domain admins group and must have the “Logon as a service” right. You should have a dedicated account for these sorts of things already if not, quickly spin one up now and make sure the password never expires. Additionally ensure you enter the username in domain\user format.

Enter the details in Domain\Username format.

Once the installation completes, verify the services are running by clicking Start and searching for “services.msc” Run this and scroll down to the Watchguard services. You should see “Started” next to both the “Watchguard Authentication Event Log Monitor” and the “Watchguard Authentication Gateway” if not check the account you specified during setup is a member of Domain Admins and has the “Log on as a service” right.

Make sure the services are started before continuing, if not check your user accounts.

Configure the SSO Agent to service requests from the Watchguard

Start the SSO configuration application under the Watchguard section of your start menu and login.

Open the agent configuration…

and Login to the configuration interface.

The username and password by default is “admin” and “readwrite”

The first thing you will want to do is change the passwords, head over to “Edit > User Management” and update the passwords in there. Keep in mind the configuration tool doesn’t allow you to paste a password upon login, so generate a password that you can actually type.

Now you need to configure the SSO agent lookup and Event log monitor.
In the “Edit > Clientless SSO…” dialog box you can see the order that the Watchguard will attempt to authenticate users. You can leave this as the default as it’s pretty reliable.
Down the bottom of the window you will see a list of Domains and their associated monitors.
Add all your domain controllers and their associated domains here. Domains are in domainname.local or domainname.com.au format.

Once you leave this window your settings will autosave.

Remember: You need to have the event log service installed on ALL your domain controllers for the domains you want to authenticate.

Next you want to configure the actual AD agent.

Head over to “Edit > Add Domain…” and fill in the domain details.
Domain name is in the “Domainname.local” or “Domainname.com.au” format
Netbios should be self-explanatory but it’s the “domainname” format
For the searching user its simplest to specify as a UPN username@domainname.local
Once again this should not be your normal admin account, but can be shared with the service account from before
Note: Entering a bad username and password will cause a popup advising the UPN you entered is invalid.. Check the password too!

Installing and configuring the Terminal Services Agent (Optional)

If you have any Terminal Services or Remote Desktop servers in the domain it’s a wise idea to install the TS Agent to allow multiple users on your TS/RDS box to authenticate. Otherwise the Watchguard appliance will treat all traffic from that server as the same user. (The first to logon after a timeout) This causes 2 problems. Group based policies won’t be applied correctly and reporting will be skewed.

On each of your Terminal Servers, Switch over to application install mode by running an administrative command prompt and running “Change user /install”. This allows any changes you make on the TS box to apply to all users, not just the admin sandbox.
Locate and run “TO_AGENT_SETUP_11_7_4.exe” from your earlier download and follow the bouncing ball.

Once installed you will find the configuration tool in your start menu under Watchguard > TO Agent.

You can find the TS agent in your start menu.

Run “Set tool” and update the configuration as needed.

In the configuration window you will find a few tabs to configure
Destination Exceptions: For anything you want to be excluded from the Watchguard entirely.

Backend Service: Put users in here that will hit the static IP rules* for this box instead of classifying them as a user. Basically stick in the username of any automated services that need Internet access
Note: System, Network Service and Local Service are already excluded.

Diagnostic Log Level: There is no need to adjust this unless advised to do so by Watchguard support.

Any rules that require a user to be logged in on the Watchguard will be skipped, if the traffic hits the end of the rule list it will be denied, so make sure you put a rule with the servers IP as a valid source in your Watchguard.

Once this is all complete, Kick off another command prompt and run “Change User /Execute” to put your session back to normal.

Rinse and repeat the above for each Terminal Server in your domain.

The Server agents are now installed and configured ready to update the Watchguard and take advantage of the authentication functions. In part 2 we will cover deployment of the SSO client to end users as well as automatically adding the firewall exclusion for the agent via an easy to setup Group Policy Object (GPO)

In Part 2 we will cover deploying the SSO agent to end user PC’s as well as creating a Windows firewall exclusion via Group Policy

The Watchguard documentation is great, but it’s hard to find deployment guides like what you’ve done here. The information is in lots of different places… and it’s hard to figure out where to start and how to bugtest.

Thanks for your notes.

Easy enough for a Windows Domain and I see v11.8 supports OSX… haven’t seen any iPad/Android apps released yet however. Implementing this in to BYOD would be ideal.

Part 3 (soon) mentions this re:11.8.. I’ve heard some rumors that mobile devices will support SSO via Activesync in a newer 11.8 release so no apps to install.

An interim solution would be to stick your BYOD appliances into a DMZ wifi network and deploy the WG VPN to them.

I wont cover it all here but basically you email your users a link and attachment. the link redirects them to the app for their platform. They then open the attachment and the WG app configures the VPN for them on the device.

Once they connect to the VPN they are now an authenticated user and can be treated as such, just be aware of the extra load on your appliance.

With BYOD, I have made a user/pass that is in the Restricted AD Goup and is shared out to guests to the campus (not ideal I know but I don’t need the extra load on my XTM). I haven’t worked out how to deploy Watchguard certificates on users BYOD devices yet, but I’ll keep picking at it so I can avoid having to make users deploy the VPN client.

In January next year I will be putting in a Layer 3 switch at the core and VLAN’ing off guest wifi access so users do not see the SSO Authentication page but still get the same HTTP/HTTPS policies as the Restricted AD group.

This is looking like a really solid setup so far; I’m glad I went through with SSO deployment as it’s added A LOT of highly configurable options for managing policies on the XTM.

All views and advice on this webpage are those of James and have no relation to his employers, Microsoft or other Third-Parties.
Advice is general only and James nor parties listed on this site will be liable for any such use or mis-use of such information.