By Mark Waldstein, LiveSecurity Content Specialist, WatchGuard Technologies
[Editor's Note: In the March, 2008 edition of my podcast Radio Free Security: Firebox Special, WatchGuard's lead technical trainer Kyle Porter told our listeners all about Single Sign-On, a new feature in Fireware Version 10. It's available on any WatchGuard appliance that can run Version 10, including our e-Series Fireboxes and our Edge product line. I've summarized Kyle's descriptions here, for those who prefer reading to listening; or, for those who've heard the podcast and want some backup documentation. --Mark]
Single Sign-On should be seen as a part of the larger authentication setup on Fireboxes. Before SSO, users could authenticate to the firewall, either as a specific user or as a member of a group. The network administrator could restrict access to particular services, or apply particular WebBlocker rules, to users who were authenticated. You, the administrator, could also integrate that authentication with your existing domain controller (such as an Active Directory server), but there was a limitation: End users had to affirmatively authenticate to the firewall using a web browser. Whether or not they were logged onto their Active Directory domain was unimportant to the firewall; it still needed them to prove who they were by directing our web app to the firewall.
So, if you had a hundred users on your network, all one hundred of them had to know how to get to a particular web page, and what to type when they got there. (In most cases, they had to enter the same username and password they had already entered when they logged onto the network that morning.) This process also meant that you probably spent more time than you wanted in educating users how to do that. So, it was probably not our most popular feature. Admins really liked the results…but that first week could be a little painful for them.
By Mark Waldstein, LiveSecurity Content Specialist, WatchGuard Technologies
[Editor's Note: In the March, 2008 edition of my podcast Radio Free Security: Firebox Special, WatchGuard's lead technical trainer Kyle Porter told our listeners all about Single Sign-On, a new feature in Fireware Version 10. It's available on any WatchGuard appliance that can run Version 10, including our e-Series Fireboxes and our Edge product line. I've summarized Kyle's descriptions here, for those who prefer reading to listening; or, for those who've heard the podcast and want some backup documentation. --Mark]
Single Sign-On should be seen as a part of the larger authentication setup on Fireboxes. Before SSO, users could authenticate to the firewall, either as a specific user or as a member of a group. The network administrator could restrict access to particular services, or apply particular WebBlocker rules, to users who were authenticated. You, the administrator, could also integrate that authentication with your existing domain controller (such as an Active Directory server), but there was a limitation: End users had to affirmatively authenticate to the firewall using a web browser. Whether or not they were logged onto their Active Directory domain was unimportant to the firewall; it still needed them to prove who they were by directing our web app to the firewall.
So, if you had a hundred users on your network, all one hundred of them had to know how to get to a particular web page, and what to type when they got there. (In most cases, they had to enter the same username and password they had already entered when they logged onto the network that morning.) This process also meant that you probably spent more time than you wanted in educating users how to do that. So, it was probably not our most popular feature. Admins really liked the results…but that first week could be a little painful for them.
All of that is behind us now, replaced by a much simpler method. With the new Single Sign-On (SSO) process in Fireware 10, you merely install one piece of software — the WatchGuard Authentication Gateway — onto a PC on your domain. The end users don’t have to install any software on their PCs. So here’s how it works now: If you’re integrating with an Active Directory domain, the end user logs in to the network in the morning as he normally would. When he tries to pass traffic through the firewall, the firewall invokes SSO and queries the agent we’ve installed. That agent queries the Active Directory controller, and identity is established without the user ever knowing that it all happened in the background. This works regardless of whether that traffic is going out to the Internet, or across the firewall to other networks.
Easier to set up, too
Administrators will find the same authentication gateway installation process for both Edge and Fireware systems; after that, each product is configured in a slightly different way on the various user interfaces. Here’s an overview of how to get Single Sign-On up and running on your network:
First of all, you need to have a directory server that can take advantage of the software, such as an LDAP or an Active Directory server.
Next, install our Authentication Gateway software on a PC that has a static IP address on the network, so the Firebox can always find it. That PC has to be a member of the domain in which the users will authenticate.
Then, in theFirewall Authentication dialog, select “Enable Single Sign-On” and point to the IP address where the gateway software has been installed. But since you’ve previously set up the Active Directory domain, and have users and groups established, most of the heavy work has already been done. You’re just telling the Firebox, “Here’s a computer on the network that can tell you all about these users when you need to know.”
If all this sounds too good to be true, well, there are some minor “gotchas” — but in my view, they’re not serious. I’ve already mentioned some of the limitations in the ways our SSO interacts with Active Directory:
- Your system must use LDAP or Active Directory architecture
- The PC you install the gateway software on must be a member of that domain, and
- The PC must have a static IP address.
There are a few other minor limitations: The user account under which you install SSO must run as a service on the domain. (This is a particular domain membership attribute that can be selected in domain setup.) That PC must also be a member of the domain administrator’s group, in Active Directory. Those aren’t serious limitations, though; most of the time you’ll probably install this gateway software on the directory controller itself, which already has all these existing permissions.
One other issue to pay attention to: If the PC from which a user authenticates has more than one account (for example, maybe you’ve installed software that runs with one level of permissions in the background, while the end user logs in with a different account), that’s not a good setup for an architecture using Single Sign-On. You want your PCs to be running a single user account that the domain controller can query for.
A network administrator who runs a dynamically-addressed environment, and wants to restrict “who can do what” during the workday, cannot limit this by IP address; the addresses are assigned dynamically, and they change often. An IP address doesn’t map reliably to a specific user. By having the user authenticate to the Firebox instead, you can apply rules based upon who a user actually is, rather than the user’s current IP address. Fireware 10′s new Single Sign-On feature gets extra leverage off the work you’ve already put into defining your users in Active Directory. With SSO, firewall authentication is much easier to implement — making it easier for you to enjoy the benefits of nuanced control over your users.