Here at the U-M Library, we run several services on Windows servers that require them to be accessed from many staff machines running dedicated clients, or using scripts and third party tools to query for data. Traditionally, this would be done by using firewalls on servers to allow specific IP subnets that those machines live on. This approach has worked well in the past, but Library IT is faced with a new kind of user - the mobile user.
This user may be sitting at a cafeteria, at home, or on an airplane travelling to the other side of the planet and they’re using a variety of devices to connect to an enterprise environment to do their job. They don’t care about VPNs, they don’t care about routing rules, certificates and other technologies that although designed to make life a bit easier, are not always that intuitive to use and in some cases don’t scale well.
Microsoft’s Connnection Security rulesallow LIT to configure firewalls on Windows servers and workstations to securely authenticate each other, regardless of which network they’re on. After the authentication is completed all the traffic between workstation and server is encrypted at the network level offering seamless connectivity while maintaining a high security level.
To implement the Connection Security rules we use the University’s centralized Active Directory environment to configure a Group Policy to deploy the firewall settings necessary for the feature to work. Both the servers and the clients have to be configured to negotiate the secure tunnel that is necessary to establish secure communications, and at the same time authenticate both the computer and the user who's using that computer to the server, in order for the traffic to be established.
This setup provides us with several advantages over the traditional IP restrictions.
- It allows us to authenticate the computer and the user prior to opening a port to the firewall. Even if the computer is allowed (say in a lab environment), if the user is not authorized, the port will remain closed.
- If the software that connects to the data does not support encryption, or its encryption is weak, we can enforce stronger encryption without having to change anything in the code of the software or service.
- Unlike traditional IP restrictions which need to be managed and updated, Connection Security rules can work without them, because they’re placing the authentication and authorization on the actual entity (whether it’s a computer, user or both) that’s on the network and not the network itself.
- Connection Security rules can work with Active Directory Groups which can be managed and automated with a variety of tools, either GUI or command line.
- Centralized deployment of these settings with Group Policies allows us to have consistent behavior across multiple servers.
- All authentication is done via Kerberos. Authorization is done by group or by individual domain accounts.
- This process is seamless to the users as the Operating System, behind the scenes, uses the authentication tickets to establish this connection without asking for additional credentials from the user.
Setting up the servers and clients to utilize Connection Security rules has allowed our staff to use our services from virtually every location on- or off-campus and has allowed us to expand our services to networks that are not owned or managed by LIT and have had unpredictable behavior.