What is the best practice for locking down AuthAnvil Two-Factor Auth (2FA) web services?

For part two of the AuthAnvil Best Practices series, we’re going to look at the AuthAnvil web services. In version 3.0 and later, AuthAnvil installs four new directories to your IIS web site of choice:

• AuthAnvilSAS: This directory holds the AuthAnvil strong authentication web service. This is what all of the AuthAnvil agents authenticate to.
• AuthAnvilAdmin: This directory holds the Admin web service, which is the backend service used for managing AuthAnvil. The AnvilManager Web interface uses this service to perform its management, and management tasks can also be performed by scripting languages that support web service calls, such as PowerShell. An example of using PowerShell to manage AuthAnvil can be found here: Using PowerShell to change a User’s PIN.
• AnvilManager: This contains the AuthAnvil Manager web interface. The AnvilManager is used to do all of your regular day to day AuthAnvil management.
• ManageToken: Introduced in AuthAnvil 3.0, the Self Service Portal allows users to do some management of their own tokens, including activating their tokens, testing their tokens, and changing their PINs, without requiring any administrator intervention.

If you are using AuthAnvil:

1. On your internal network only;
2. On a server that cannot be accessed from the internet;
3. You don’t need any remote users to be able to authenticate; and
4. You are not concerned with remote management

... then you can lock everything down to the internal network by blocking it at either the server or firewall level. That’s it, you’re good to go. If you have remote users that need to log on, or you want to manage AuthAnvil remotely, then read on.

For remote users, of the four directories, the only one that *needs* to be accessible to the Internet is the AuthAnvilSAS virtual directory. This is all that AuthAnvil agents require in order to authenticate to the server. If you want to allow remote management of the AuthAnvil server and to allow remote users to manage their own tokens, then the AnvilManager and ManageTokendirectories can be exposed to the Internet. If not, then they can be restricted to the local network. The AuthAnvilAdmin web service does not need to be exposed to the Internet, and unless you want to be able to perform management tasks via scripts, can even be restricted to the local machine only. Note that if you do restrict the AuthAnvilAdmin web service to the local machine, you may need to use the instructions in Appendix C of the AuthAnvil Install Guide to change the server name on the Admin URL to one that is correctly resolvable and reachable from the AuthAnvil server.

You can lock these directories down at the IIS level, following the instructions in Appendix D of the Install Guide for Windows Server 2003. For Windows Server 2008, it’s a little more complicated:

1. If necessary, add the IP and Domain Restrictions Role Service to the IIS Role
   1. Open Server Manager
   2. Expand Roles and Web Server
   3. Scroll Down to Role Services and click the “Add Role Services” button.
   4. Scroll down to the “Security” section and click the check box beside IP and Domain Restrictions. 
      
      
   5. Compete the wizard.
2. Open the IIS Manager
3. Navigate to the directory that you want to protect.
4. Double click “IP Address and Domain Restrictions” in the IIS section. 
   
   
5. Click “Edit Feature Settings…” and set Access for unspecified clients to deny. 
   
    
6. Click “Add Allow Entry…” and add entries as appropriate. 
   
   
7. Repeat steps 3 - 6 as required.

In this area too, AuthAnvil is flexible, helping you harden your servers by allowing you to expose only as many services as your needs require. This is something to take into account and take advantage of when planning your network and Internet services policies. 

Questions?

If you have any questions or need some help, we would be happy to assist. Open a case at help.scorpionsoft.com or send an email to support@scorpionsoft.com.