Elevated Privileges and User ID in Active Directory Environments Nick Piagentini Palo Alto Networks 3300 Olcott Street Santa Clara, CA 95054 www.paloaltonetworks.com
Table of Contents Background... 3 Objections... 3 Solution... 4 2011 Palo Alto Networks Page 2
Background The most common scenario in which we encounter issues with User Identification (Used-ID) and elevated privileges is in the case of network administrators who have multiple accounts within the same directory. One account is most commonly a regular user account that provides access to traditional network services such as file shares and email. The other is an account with administrative rights on the network and is used to perform specific tasks on demand through either the use of an RDP session to a network server or through the Windows Run As command from the desktop. There are additional examples of this in the form of any cloud based SaS solutions where network users have separate credentials for access to the cloud service then for local network access. Examples include Salesforce.com as well as Google Apps. In these cases, the current Palo Alto Networks User-ID solution will associate only one network identity with the users IP address (or IP / Port combination in the case of Terminal Services). For example if a network administrator has been identified based on their user level account, and the administrative level account was used in firewall policy to allow access to a resource, they would be unable to accomplish their required administrative task. The inverse is also a problem. If they are mapped with their administrative level account they may lose access to email or user drives which are provisioned based on their user level account. In theory this issue can be extended to any other set of credentials the user possess, although credentials outside the scope of the enterprise network are probably not required in firewall policy. The problem becomes what account should be used for any given firewall policy. Objections Most commonly administrators will wish to use Admin level accounts in firewall policy for administrative traffic, and user level accounts for base traffic. The screen shot below captures a common initial configuration. The following assumptions are made regarding the users Active Directory design. Administrators have 2 AD accounts 2011 Palo Alto Networks Page 3
One account is a member of Corporate Employees One account is a member of IT Admins The IT Admins account is not a member of Corporate Employees, it is a group that only has access to higher administrative functions. In most cases members of this group will not have been provisioned for email or other basic user services. The accounts are solely used for high level administrative tasks. The user will most likely log into their workstation as a member of the Corp Employees group and then launch RDP to access the domain controller where they would need to provide IT Admin permissions. Since User-ID would have them mapped to their general purpose user account they would not be able to initiate the RDP session in the first place. Even if they launched the RDP client using Run as it would not work since the use of the Run as command does not generate the proper events in the Windows security log. Without a full understanding of how User-ID on a network firewall should be deployed this issue can be perceived as a significant shortcoming. Solution The key concept to addressing this issue is to define network security policy based around who the user is, rather than the level of access they are currently exercising. In the scenario where entities in the customer environment have multiple user identities for access to different resources, the firewall rules should be defined on the base user group. In the above example the firewall rules would be defined around Joe Doe s JDoe user account. This account would be allowed to run RDP to the domain controllers as well as be allowed access to the Exchange server. When connecting to the domain controller, Joe will need to provide his JD-Admin account credentials to successfully connect. This maintains the two discrete levels of access for administrative functions. Along the same lines, if Joe needs to run a SQL server client on his workstation as the JD-Admin user to manage a database, his JDoe account would be provisioned on the firewall to allow SQL access, while the SQL server would still require the elevated credentials provided when Joe ran the client using Run as The Base account will usually be a member of groups based on general job function. So while JDoe is not a member of the IT Admins group that would provide access to Domain Controllers, he is most certainly a member of a group such as Network Services. These organizational groups can be used to identify the users that will most likely have secondary elevated accounts. By provisioning applications based on this account, and then securing the end points based on the elevated account we can achieve both a clean and logical firewall policy set with the enhanced security of the dual user role. 2011 Palo Alto Networks Page 4
It is critical to note that the use of the base account groups for policy does not represent a loss of security. Nor should firewall rules be seen as a replacement for the granular security provided by end points such as file servers, terminal servers and data base systems. 2011 Palo Alto Networks Page 5