After having tons of discussions about user identity and why VLANs are important, or if ACL is enough for securing the corporate services, we all (I believe) know the answers. Networking people stepped up to the next level starting to ask how to keep track of user identity. Why? One thing is that corporate policies requires complete history of employee activites and ability to restrict the the rights of many flavors granularly, second, from the IT departments perspective managing the access rights and user priviliges based on usernames instead of IP addressing, simplifies and clarifies the IT and Network management.
Now, where to track the user and what possibilities we have? End to end or at Internet Edge firewall level is enough? There is no simple answer and as always it depends. When the corporate architecture is built using “best” practice, the Internet Edge Firewall Tier is not the only point we need the visibility. For example, having 70% of all everyday traffic load on Intranet DC points us to the need of tracking the users on DC Firewall Tier as well. Shortly, where to have the visibility is about design. Believe me that well designed network and services can make life simple (and cost effective) whereas deliver solutions madly causes only troubles.
The source of user identity is naturally any kind of user database like corporate Active Directory or kind of LDAP. Hard to imagine that organization does not have such structure nowadays. So, this is the hint where we can take the identities. Second question is how we can recall to which user belongs the packet traversing network? The IP and Username “pairing” logic has to be ensured. IP-User binding in most vendor implementations relies on built-in or standalone agents reading the Security Event log from Domain Controllers. An example can be Palo Alto Network User-ID Agent (built-in), FSSO from Fortinet (built-in) or Cisco Context Directory Agent (standalone), now Firepower User Agent standalone solution (Cisco Firepower). Idea is simple in description: Agent reads regularly the Domain Controller (DC) Security Event Log, parses the information retrieving IP-User binding, and sends this information to the network device. Network device can enforce policies based on usernames and AD groups when packets traverse the firewall.
Scheme below shows the information flow.
As the idea is rather simple and logical in description, the issues come with real environments when users move, leave the laptops, change wifi to cables, hibernate their laptops, use different operating systems which behaves different in relation to domain, like MacOS, Windows, Linux, Android, iOS. I will concentrate on those challenges as well as on solutions next post in this category.
Interesting post 🙂
What about defining exceptions for specified device, e.g: I want to crawl data from a website using specified computer on my desk.
Will I need a separate mechanism? (IP, MAC based)?
Hello Kamil,
thanks for posting the comment. Identity based filtering is the “extra feature” mechanism in most of current vendor implementations, so good old methods are still available. Depending on what kind of restriction and for whom you want to enforce, you can always prepare some exception rules e.g. based on IP addressing or particular interface where the packet is seen. MAC based filtering is rare in real live implementations, especially because the MAC info is missing (stripped) when user / host sits in different L3 segment than firewall. Very similar and common application of your example is creating rules for IP of servers when need to download the updates regularly. In such cases there is no Domain User logged in but admins still need to have those machines to go to Internet.
BR
Marcin Biały