Tip & Tricks - AuthAnvil Two Factor Auth

September 16, 2013

We’re pleased to announce that version 2 of the AuthAnvil SoftToken for iPhone is now available in the App Store.

This new version includes some important fixes, and a couple
neat features as well.

What’s New?

Improved screen-use on 4” Retina
displays, such as the iPhone 5 and later.

Copy any displayed one-time
password to the clipboard with a single tap on the OTP.

Stylish new app icon

Important: Existing
users moving to iOS7 must apply this update and generate at least one OTP
before doing the OS upgrade to keep your current SoftToken keys. Otherwise the
user will require their SoftToken to be reset. If you haven’t reset a SoftToken
before, please check
out this video, or visit scorpionsoft.com/help for more information.

April 11, 2013

If you already have an AuthAnvil SoftToken running on your smartphone, you may feel like you don’t want to give up the flexibility of having your authenticator on your phone. We understand that. We also know that you want fast access to the environments that you need to log into each day with YubiKeys, and think you shouldn’t have to sacrifice that time savings so you can have another app on your phone.

So why not use both?

If you want a more detailed picture of how much time YubiKeys can save you, check out the free eBook below.

March 22, 2013

AuthAnvil Two Factor Auth was built with security in mind. Any security measure that constantly impairs the end user tends to get disabled, or circumvented at some point. While we always recommend that you use your pin, plus a one-time password from an AuthAnvil token to log in, there are times when a temporary bypass is required. Watch the video to learn how.

March 29, 2012

Some of the questions that Customer Support has frequently been fielding recently have been from users who would like to move their AuthAnvil Two Factor Auth database from their existing SQL server to a new SQL server. Reasons for moving the database range from outgrowing SQL express, and wanting to take advantage of the features provided by full SQL, to retiring their existing SQL server, to wanting to consolidate all of their SQL databases on a single machine. Whatever the reason, it’s a pretty simple process, and here’s how you do it. (These steps can be applied to AuthAnvil 3.5 and later.)

Step 1: Before doing anything else, take an AuthAnvil backup as a precautionary measure. For more information on how to do a backup, check out the “Backing up the AuthAnvil Two Factor Auth Database” section of the Two Factor Auth Installation Guide.

Step 2: Open up the IIS Manager for the server, navigate to the Application Pools node, and stop the AuthAnvil Application Pools (AuthAnvilAdmin, AuthAnvilADUS, AuthAnvilManager, AuthAnvilSAS, and AuthAnvilSelfService). This will stop Two Factor Auth from responding to authentication requests so that we can safely move the database.

Step 3: Launch SQL Management Studio and connect to the current Two Factor Auth database server. Expand the “Databases” node, right click on the “Anvil” database, and click “Detach, under the “Tasks” menu option.” Make sure that “Drop Connections” and “Update Statistics” are checked, and click “OK.”

Step 4: Expand the “Security” node, then “Logins”. Right click on the user “DOMAIN\AADBUser” and click “Delete”. Click “OK” on the dialog box that comes up to complete the deletion process.

Step 5: Copy the Anvil.mdf and Anvil_log.ldf files from the data storage location on the current database server to the data storage location on the new database server.

Step 6: Launch SQL Management Studio and connect to the new database server, right click on the “Databases” node and click “Attach.” Click “Add”, then navigate to the database file (Anvil.mdf) and click “OK,” then “OK” again to attach the database.

Step 7: Expand the “Security” node, right-click on “Logins” and click “New Login”. The user will use Windows Authentication, the Login name will be DOMAIN\aadbuser, and the default database will be set to “Anvil”. Under the “Server Roles” tab, the user only needs the "public" role, and under the “User Mapping” tab, they need to be mapped to the “Anvil” database, and be assigned to the "db_datareader," "db_datawriter," "db_owner," and "public" database roles on that database.

Step 8: On the Two Factor Auth Server, open up the AuthAnvil Web Config Editor, located by default at C:\Program Files\Scorpion Software\AuthAnvil\AuthAnvilTools\AAWebConfigEditor.exe. In the “Connection String” field, change the “Server” value to point at your new SQL server (and instance if applicable). Then, click “Apply.”

NOTE: Do not change any of the other values in the connection string. This can cause your Two Factor Auth Server to be unable to connect to the database.

Step 9 (AuthAnvil 4.0 and later only): Open Notepad on the Two Factor Auth Server (elevated on Server 2008 and later), and navigate to C:\Program Files\Scorpion Software\AuthAnvil\AuthAnvilRedirect\AuthAnvilSAS\web.config. Scroll down to the “ConnectionStrings” section, and in the key that reads “add name="Anvil"”, change the “Server” value in the “connectionString” field to point at your new SQL server (and instance if applicable). Then, save and close the file.

NOTE: As before, do not change any of the other values in the connection string. This can cause your Two Factor Auth Server to be unable to connect to the database.

Step 10: Restart the Application Pools in the IIS manager and test the new configuration by logging in to the AuthAnvil Manager. If you can successfully log in, you’re good to go. You've successfully moved the Two Factor Auth Database to a new server. If you run into any issues, please contact customer support at www.scorpionsoft.com/help.

March 28, 2012

In today’s installment of AuthAnvil Two Factor Auth Best Practices, we’re going to follow up on yesterday’s post about ADUS, and look at ADUS Best Practices. As mentioned yesterday, ADUS allows you to perform a one way synchronization of users from Active Directory to AuthAnvil Two Factor Auth. While this greatly simplifies user management, there are a few things to keep in mind.

Best Practice 1:Each Two Factor Auth site should synchronize with only one ADUS client. ADUS is designed to to synchronize users from one Active Directory domain to one AuthAnvil site. Synchronizing multiple domains may introduce username collisions in the Two Factor Auth Database, which will cause those users to not correctly be assigned tokens, and will make them difficult to remove from the ADUS groups without impacting the existing user. In general, if you plan to have members of multiple Active Directory domains maintaining their own tokens, you will want to consider using multiple Two Factor Auth sites on the same server, or multiple Two Factor Auth Servers.

Best Practice 2: The ADUS client’s update frequency should be relative to how frequently user data is modified. The default update frequency of 5 minutes is excellent for organizations that make daily changes to user data. However, for organizations with stable user bases that make less frequent changes, an update frequency of 30 or 60 minutes is typically appropriate. This ensures that the AuthAnvil Two Factor Auth user database is kept up to date, while keeping unnecessary synchronization traffic to a minimum.

Best Practice 3: Tune the ADUS policies to meet your organization’s needs. In the settings page of the AuthAnvil Manager, you can choose the policies that ADUS will follow when a user is added to the ADUS group, updated, or removed from the ADUS group. Make sure that you configure them so that they make sense for your organization. For example, if a user leaves the organization, you may want to have their user account deleted rather than simply disabled. Or, when creating a user, you may want them to be created in Two Factor Auth, but not assigned a token until the AuthAnvil administrator okays it. For more information on the ADUS policies, check out the ADUS Policies section of the ADUS Configuration Guide. And, don’t forget, to help defend against denial of service attacks on Two Factor Auth by a rogue administrator or an attacker that compromises Active Directory, ADUS cannot affect any user that is marked as a site admin in Two Factor Auth.

Best Practice 4: Make sure that you have enough SoftTokens in the system to meet demand. If there are not enough SoftTokens in the system for the users that ADUS creates, ADUS will still create the user, but not assign them a token, and inform the administrator. The administrator must then manually import and assign tokens, which can potentially take some time, depending on how many users you need to assign tokens to.

ADUS is a powerful asset to a Two Factor Auth administrator. You just need to make sure that it is tuned to meet the needs of your organization so that you can put it to the most effective use.

March 27, 2012

Active Directory User Synchronization, also known as ADUS, solves the problem of getting large numbers of users into AuthAnvil Two Factor Auth. Rather than having to create users manually, or import them from a spreadsheet, ADUS allows you to take advantage of your existing Active Directory infrastructure to synchronize changes to Two Factor Auth, and create, update, and delete Two Factor Auth users based on changes in AD.

ADUS is made up of two parts: the ADUS web service, which is installed on every Two Factor Auth server running 4.0 or later; and the ADUS client, with is installed on an AD Domain Controller. If you install Two Factor Auth on a domain controller, you’ll have the option to install the ADUS client as well. Otherwise, Two Factor Auth deploys the ADUS client installer to the C:\Program Files\Scorpion Software\AuthAnvil\AuthAnvilTools directory, from where it can be copied to a domain controller.

To activate the ADUS web service on the Two Factor Auth server, you simply log into the AuthAnvil Manager and open up the ADUS panel in the settings tab. Here, you can turn on ADUS, and set a shared secret. This shared secret will be used to secure communications between the ADUS client and the ADUS Web Service on the Two Factor Auth Server, although we still recommend an SSL connection for communications between the ADUS client and the ADUS web server in production environments. Here, you can also set the policies that ADUS will follow when users are added to the ADUS Active Directory groups, have their active directory details modified, or are removed from the ADUS groups. One thing to note is that users who are site admins in Two Factor Auth will not be affected by changes made by ADUS to prevent denial of service attacks. The final requirement for making this work successfully is that the Two Factor Auth server is installed on a domain-joined machine. It does not have to be joined to the same domain as the ADUS client, it just has to be joined to a domain.

Deciding which users get synchronized up through ADUS is handled on the client side, through the ADUS configuration tool (available in the Windows Control Panel) by specifying groups in Active Directory. ADUS allows you to specify two groups, one which will assign users SoftTokens, and one which will assign users Hardware Tokens, as well as how often the synchronization will happen. We recommend about every 60 minutes or so. Here, you also specify the location of the ADUS web service, the Two Factor Auth Site ID that you want to synchronize to, and the shared secret that you configured in the ADUS settings on the Two Factor Auth Server.

Once ADUS is configured, all that you need to do is move users around in Active Directory, making Two Factor Auth user administration incredibly simple.