Follow

Configure Policy-Based Active Directory or Smart Card Authentication for AuthAnvil SSO

By default, AuthAnvil Single Sign On logins are configured to require two factor authentication in the form of your AuthAnvil passcode. AuthAnvil SSO v4.1 includes a policy module framework that can load alternative authentication providers by policy decisions configured in the web.config. This includes "Windows auth" using Kerberos for Active Directory, or using smart card auth which is used for Common Access Cards (CAC) by the USA DoD, NATO, and other government identities.

The policy restrictions for the Windows auth are IP based, which allow you to enable it for your local LAN segment, but still enforce 2FA when users are connecting from outside your network. This provides risk-based authentication options, allowing internal users to access SSO without any further prompting, but forces a strong auth check when outside the trusted network.

 

Configuring AuthAnvil Single Sign On "Authentication Modules"

Authentication Modules can be configured in the SSO web.config located at C:\Program Files\Scorpion Software\AuthAnvil\AuthAnvilSAS\SSO\web.config. Around Line 53 there is a <policies> section that should list the default policy for two factor authentication:

<policies>
<policy handler="OTP" type="IPAddr" />
</policies>

This policy is used by default because it has no name="" defined. All selective policies should have a name defined as a label to identify them.

Note: When using integrated authentication you must update "C:\Program Files\Scorpion Software\AuthAnvil\AuthAnvilSAS\SSO\web.config"

<system.web><authentication mode="Forms" /> to <system.web><authentication mode="Windows" />

 

In AuthAnvil SSO v4.1 there are 3 available authentication module handlers:

  • OTP - One Time Password authentication using an AuthAnvil passcode
  • Integrated - Windows / Active Directory authentication (Kerberos)
  • TlsAuth - Certificate or Smart Card authentication

The type="" of all policies should be "IPAddr", allowing the user to define an IP Address or a range of addresses using the value="" attribute. IP Addresses should be in single IP or CIDR format, or you can use a wildcard (*) for general matches:

type="IPAddr" value="192.168.1.2"

type="IPAddr" value="10.10.10.0/24"

type="IPAddr" value="*"

Here is an example of a complete policy setting that will allow users from 192.168.*.* to authenticate via Active Directory, while external users are required to use two-factor authentication.

<policies>
<policy handler="Integrated" name="somename" type="IPAddr" value="192.168.0.0/16" />
<policy handler="OTP" type="IPAddr" />
</policies>

 

Note: When using Integrated auth / Kerberos, Internet Explorer treats the session as a trusted Intranet site. In this scenario credential injection using the SSO Assistant will not work as Internet sites are in a different trust zone, and Internet Explorer does not allow the communication across that trust boundary. If your configured SSO applications are using enterprise-class SSO protocols (SAML or WS-Federation) they will work across the board, but if you need to use a password injected from the Password Server, it will not work since the Internet site cannot call into an Intranet site to make the request. One way to work around this would be to add the Internet site to the Trusted zone, but you would have to do that for every site you want to do injection for on every computer on the LAN. This can be done using Group Policy if that is the case. Another alternative is to use Google Chrome, which doesn't support zone security.

Note: For this to work the Windows username must match the SSO username.

 

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.

 

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments

Powered by Zendesk