If you would like to read the other parts in this article series please go to:
- Considerations for the TMG Firewall in Supporting Services (Part 1)
- Considerations for the TMG Firewall in Supporting Services (Part 2)
- Considerations for the TMG Firewall in Supporting Services (Part 3)
- Considerations for the TMG Firewall in Supporting Services (Part 4)
- Considerations for the TMG Firewall in Supporting Services (Part 6)
Introduction
In the first article in this series, I went over a number of issues surrounding domain membership for TMG firewalls. In the second article, I talked about authentication for outbound connections. In the third article, we went over some of the things you need to consider regarding authentication for inbound connection. Now let’s cross those subjects off the list and see what we have left:
Past articles:
- Domain member versus Workgroup
- Authentication for outbound connections
- Authentication for inbound connections
This article:
- Authentication for non-Windows clients
As you can see, in this final article in the series, we’ll continue the discussion by talking about authentication considerations for non-Windows clients.
Authentication of Non-Windows Clients: A New Perspective
In the not-so-distant past, the issue of authentication issues for non-Windows clients would have been a pretty short discussion. Everyone in the business world was using Windows clients (or almost everyone) and these clients were typically desktop PCs or laptops. These PCs and laptops were usually joined to the Windows domain, or if not, the user had a user account in your Active Directory domain. Life was easier (at least in some ways) back then.
Things have changed. In the second decade of the 21st century, it’s likely that a large number of the connections to your network that you see are going to be coming from non-Windows clients. With the proliferation of smart phones and tablet devices, many of which run iOS or Android, you can expect that a variety of different operating systems are going to be making inbound and outbound connections through your TMG firewall. That means you’re going to need to consider authentication issues for these devices, and you might need to think about authentication for users who aren’t even contained in your Active Directory domain.
Non-Windows Clients and Connections through the TMG Firewall
Probably the best way for you to approach authentication issues for non-Windows clients that are connecting through the TMG firewall is to break the connections down in several categories:
- inbound connections
- outbound connections, and
- remote access VPN client connections.
Let’s start by taking a look at the outbound connections.
Outbound Connections for Non-Windows Clients through the TMG Firewall
Recall from our previous discussion about outbound authentication that we have two options for authenticating those outbound connections. The first option is the web proxy client and the second option is the Firewall client.
For the web proxy client, authentication can be performed transparently if the user is using a Windows-based machine that belongs to an Active Directory domain and the user is logged into the machine with an Active Directory account. If the user is not using a Windows based operating system, however, this transparent authentication won’t be available because the user won’t be connecting from a machine that belongs an Active Directory domain, and thus won’t be able to log on with an Active Directory account.
This doesn’t mean that the user won’t be able to authenticate to the TMG firewall. If the browser on the non-Windows machine is configured to be a web proxy client, an authentication prompt will appear, and the user will be able to enter his/her user name and password so that the user will be able to authenticate with the TMG firewall. You will need to configure the TMG firewall to accept these kinds of requests, though.
If you want to authenticate non-web requests from a non-Windows client, things get a bit more complicated. The reason for that is that in order to authenticate requests for non-web protocols (which means anything that isn’t requested through the web proxy client configuration), you need to install the Firewall client. With a Windows computer, that’s easy. With a computer or device running a different OS, not so much. While there have been many requests made to Microsoft over the years for a Firewall client for non-Windows systems, that request had gone unanswered throughout the lifetimes of the ISA and subsequent TMG firewalls. Therefore, if you’re looking for a Winsock-proxy client for your iOS/OS X or Android/Linux device, you’re going to have a problem.
What can you do instead? An alternative might be to use a SOCKS proxy client configuration for applications on your non-Windows clients that can be configured to use a SOCKS proxy. The problem with this is that the TMG firewall does not contain a SOCKS proxy. In the past, at least for the ISA firewall, there were some third party SOCKS proxy products you could purchase, but I’m not aware of any similar SOCKS proxy add-ons for the TMG firewall. [Note: If you do know about a SOCKS proxy for TMG, let me know and we will pass that info along to readers via the ISAServer.org blog.]
Okay, then. What you do you do for your non-Windows clients when they need access to the Internet for non-web protocols through the TMG firewall? As a security person, it hurts to say this, but you are going to have to allow anonymous requests from them. You can get some measure of access control if you assign the non-Windows clients IP addresses in a certain range, and then create Access Rules based on that IP address range. While that won’t give you the visibility you’d like in terms of knowing what specific users (based on their account names) are doing, I suppose it’s better than nothing.
This also means that you are going to need to configure these non-Windows clients as SecureNAT clients. SecureNAT clients are machines that are configured with a default gateway that provides a routed path to the Internet through the TMG firewall. The TMG firewall doesn’t need to be the actual default gateway, but all routers between the SecureNAT client and the TMG firewall will need to contain a “path of last resort” that will send Internet bound requests to the TMG firewall.
How is this different, at the practical level, from the web proxy and Firewall client configuration? Since the web proxy client and the Firewall client actually know the IP address on the internal interface of the TMG firewall, you can assign those systems any default gateway you like, just as long as that gateway has routing table entries that provide enough information to get the requests to the IP address of the TMG firewall. This is one of the beauties of the web proxy and Firewall client configuration: these configurations do not require you to alter any of your routing table entries.
Inbound Connections for Non-Windows Clients through the TMG Firewall
The authentication situation for incoming connections through the TMG firewall is a bit different. It’s likely that most of those connections are going to be made to web servers that are published through the TMG firewall. Therefore, you will have a number of authentication options available. One big difference between outgoing and incoming connections in general is that for outgoing connections through the TMG firewall, there is an authentication scenario available where users are authenticated transparently. Of course, that transparent authentication option isn’t available to non-Windows client users, so it doesn’t really help us much in that regard.
For inbound connections coming from non-Windows clients trying to access web services, the users will be prompted for credentials when they connect to the web listener for the particular Web Publishing Rule. The user might be a member of an Active Directory domain, in which case the user can enter an Active Directory user name and password. However, an Active Directory domain account is not required to connect. You can configure the TMG firewall to use RADIUS to connect to an alternative authentication repository. But that’s not all. In fact, you don’t even need to use RADIUS or Active Directory if you create all the user accounts on the TMG firewall itself. Now, be aware that this isn’t very scalable and it’s definitely not something you’d do in an enterprise environment, but it’s still a viable and supported option for the many small and mid-size businesses that use TMG.
The bad news is that, for non-web connections, the situation is pretty much the same for Windows and non-Windows clients. The unhappy story is that there are no authentication options available. The reason for this is that for non-web connections, the only inbound option is to create Server Publishing Rules, and Server Publishing Rules do not support authentication for any protocol. There is no workaround, mitigation or clever fix for this; it just won’t happen.
Remote Access VPN Client Connections for Non-Windows Clients through the TMG Firewall
Did you know that non-Windows VPN clients can connect to the TMG firewall? You bet! If the users are members of your Active Directory domain, it’s a piece of cake. But what do you do when those users don’t have Active Directory domain accounts? The good news is that it’s still possible for those users to authenticate to the TMG firewall by taking advantage of RADIUS or EAP based authentication. In order to do that, you will need to use a feature that’s included in the TMG firewall called “user mapping.” User mapping is used to map VPN clients that are connecting to ISA Server using a non-Windows authentication method (RADIUS or EAP) to the Windows namespace. As a result of this, firewall policy access rules specifying the Windows users and groups user set are also applied to these non-Windows authenticated users. If you do not define user mapping for users from non-Windows namespaces, default firewall policy access rules will not be applied to them.
I’m going to talk about user mapping in more detail in a future article on TMG firewall security. So keep an eye out for that one.
Summary
In this, the last article in our series on authentication issues pertaining to the TMG firewall, we talked about authentication considerations for non-Windows clients. I hope you enjoyed this series and that maybe you learned a thing or two along the way. –Deb.
If you would like to read the other parts in this article series please go to:
- Considerations for the TMG Firewall in Supporting Services (Part 1)
- Considerations for the TMG Firewall in Supporting Services (Part 2)
- Considerations for the TMG Firewall in Supporting Services (Part 3)
- Considerations for the TMG Firewall in Supporting Services (Part 4)
- Considerations for the TMG Firewall in Supporting Services (Part 6)
