IP address based SSO


My intention with this post is not to grade or evaluate the solution described here. My only point is to be sure you are aware of the potential side effects of using this particular configuration. Also, as not being a subject-matter expert, this post only reflects what I learnt and understood after few hours of testing.

UPDATE: other security products have the same authentication option, so please do not focus on the given product, but also check yours.

Background story

Suppose you have a Barracuda Web Security Gateway operating in inline mode (1) and you also have the SSO option configured and enabled (2). Note that (1) and (2) conditions are important.
In such case the appliance can see two types of users – authenticated and unauthenticated. Barracuda offers you to have different policy settings for these two groups.


You connect a laptop (not domain member) to the network running whatever OS you like – in this case it was OSX if you are interested, but doesn’t matter really ;). As the proxy is operating in inline mode you can start browsing the internet. Let’s log in to the Barracuda and check the logs related to the IP address of this laptop.  There are two options:

  • You see the newcomer as an unauthenticated user – no surprise here
  • You see him as an authenticated user and a “random” (ok, it’s not random, see below) username is being associated with him. Long story short: with a home laptop without providing any credentials you may become an authenticated user.


The first thing that bugged me is the authentication (especially the SSO) itself. If the device is in inline mode there must be a trick, right? And there is. Barracuda’s DC Agent comes to rescue. Here is the description straight from the official site (https://techlib.barracuda.com/BWF/DCAgentOverview):

You can install the Barracuda DC Agent either on the domain controller or on a dedicated Windows PC on the office network. The Barracuda DC Agent periodically checks the domain controller for login events and to obtain a record of authenticated users. The IP addresses of authenticated users are mapped to their username and group context. The list of authenticated users is provided to the Barracuda Session Manager on your Barracuda Networks product, allowing true single sign-on capabilities.

So what’s going on here? When the appliance synchronises the login data, it binds the usernames to IP addresses. As a result, the appliance identifies (and authenticates – according to the terminology) the users based on their IP addresses.

In one hand, it makes sense as this is the only information the appliance can see in inline mode. It has no “direct contact” with the clients, the traffic just “get routed” via the appliance. Ok, I know there are other ways…

On the flipside though, you must be aware of that in such configuration your proxy is going to authenticate your users based on their IP addresses only. Needless to say changing the IP address is not a brain puzzle. It may lead to user impersonation in the proxy context. Consider the following scenario, Bob plugs in his laptop, logs in to the domain and does some work. Then Bob needs to leave for a meeting, he unplugs the laptop, so his IP is free to use. Eve may configure this IP or the IP is assigned to her via DHCP (after a given period of time). Anyway as soon as Eve has the IP, she becomes to Bob – at least for the proxy.

One thing you can use is the “Cache groups for” option of the DC Agent. This is the amount of time (in minutes) to allow the DC Agent to rely on cached login information (the default is 480 minutes). However it’s not a real solution.

I guess the best you can do (if you need authentication) is using the device in forward proxy mode with NTLM Domain User Authentication or with the Kerberos Authentication.

Happy Hacking!