Watchguard Server Center and Active Directory: more than just a centralized management
The Watchguard Server Center is a powerful tool included in many Watchguard devices purchase. And it can be a good option even if you have just one XTM box. Plus, this article describes how to integrate WSC authentication with Active Directory.
I found a good practice installing the WSC solution even in single XTM installations. It gives me multiple advantage points in systems management, and a wider overall system vision. The WSC is a powerful server application that allows a centralized management of one or more XTM devices from a single control point. It can also handle automated software upgrade, feature key synchronization, templates and access control based on user profile.
Within single Customer installations, a WSC is useful to keep track of your changes, who made the change if you work in a team, and to allow you a rollback process if something goes wrong, without the need to keep a manual archive of the XML configuration files. Which is pretty useful. Also you can plan a XTM OS upgrade to start an hour or so before you get on-site at the Customer's location, gaining more time and efficient management of your time or resources.
The most interesting feature I am using within the WSC is the change tracking. I am aware of who made what, access the various versions of configurations and review the policy settings applied in different points in time. Also I can be informed every time a change has been applied via e-mail, and force an operator to enter information about the changes have been made, being able this way to access (hopefully) the ticket that references sudden change. Within larger organizations I can also narrow down the user's management capabilities by disabling certain features.
One nice feature I am using more and more is the use of templates. Finally I can keep separated the management of Guest networks from the LAN networks, or core-services in different Policy sets, which allows a neater configuration and more efficient overall handling, and less complexity of management.
The integration with Active Directory is then a must if you have a wider organization, also if you have external cotractors that works within your Company or Customer's site. If your Company or Customer has an external consultant that manages its firewall, it's sufficient disabling its Active Directoy account to cut him/her off the system and, possibly, Mobile User VPN, giving the C* the full control of security of the Company's perimeter.
I have introduced the WSC setup and AD integration within my best practices on my work, because the way it simplifies the whole system management is pretty impressive. Its lightweightness allows it to be installed on pretty much any already in production server, and you can easily recover from failure just gaining back access to your box using the Policy Manager.
From a Customer's perspective, IMHO, the possibility of having a comprehensive report of who did what, and alerts about changes made to the Company's security profile is a positive match.
Of course you might want to build up an MSSP solution, which is really a piece of artwork too, having the chance of controlling all the boxes of your customers from a single point, but that might require a little more procedures and management skills, yet it is one hell of an implementation. I rather prefer the more "traditional" one, unless you are an ISP. The system stays confined to the Company's network and all the security features are merged with the entire IT infrastructure of the Company itself.
Either way if a firebox doesn't respond, it probably won't respond even if you have a direct access to it from outside, so most probably a manual reboot or on-site intervention will still be needed!
Integrate it with Active Directory
I have recently posted an article about how to set up LDAPS support for domain controllers within an Active Directory domain. What's all the fuss about? It's because you need it to be enabled in order to allow WSC to authenticate on your domain. Therefore you might want to take a look at it here before going on with this tutorial.
If your Active Directory supports the LDAPS access, you can open the WSC configuration panel and insert your domain name in the Active Directory tab. If you followed my template, you might also want to validate the CA againist a trusted set of CAs (yes you want to) by clicking import and then importing your CA certificate (ca.crt). Once completed click apply and you should have something like this (assuming my lab domain is named en3pylabs.domain, and you also should have your verification checkbox checked).
Once you're done, you'll might be tempted to click the "Test" button to verify if you can log on your system with your credentials, but I'd redirect you first to set up your Super Administrator user under the "Users" menu. Build within your Active Directory Users and Computers snap-in a new group, say "Watchguard Super Administrators". Add your own user to this group.
As a common best practice, you don't want to deal with single user setings, but by groups. Therefore in Your WSC you will set up a group access for management. This is the tricky part. In your AD Users and Computers snap-in click "View" and then "Advanced settings". The tree view will be reset and more items will be shown. Browse back to the OU where you created your group and double-click it. You should see a lot more tabs than earlier. Click on the "Object" tab. There's a read-only field that you can select and copy to clipboard. Do so and open the WSC. In the pane add a new Group, and paste your clipboard in the text box, then select AD Group, grant it the "Super Administrator" role and click "OK". Your group should be listed in the right pane.
Now you may want to go back to the Management Server configuration and click that "Test" button. If everything has been properly configured, by inserting your UPN login (name@domain) and your password you should get this message dialog.
By the other hand, if something went wrong, you might get a less nice dialog box like this.
If this happen you might want to check your checklist once again if:
- your Active Directory domain accepting connections on port 636/tcp (ldaps)
- your DNS resolves correctly the domain FQDN
- you have properly configured the Management Server (domain name)
- you have specified the CA check and imported the correct CA certificate (ca.crt in my previous example)
- you have specified a valid Group name in the WSC configuration
- you have provided a valid UPN login username and the correct password
The first-time configuration might be a little tricky, but once done, you can totally forget about the user management, and use your Active Directory credentials to either access the whole WSC system as well as managing your XTM device.
This documentation is provided as-is and it is your own responsibility to apply this solution in a working environment. The documentation has been written as it was tested in a lab environment based on Microsoft Windows 2008R2 server trial edition. Rest of work has been done on Fedora Linux, OpenSSL, GIMP. For any further information feel free to contact me.