n-factor has been around for a few years now, and n-factor flows have also been on board a Citrix NetScaler for some time.
n-factor flows are much clearer than “traditional” n-factor authentication, but there are a few obstacles on the way to a good deployment. One problem that I have failed at is SSO (Single Sign On) when the password is the second factor.
The deployment I am presenting here can be used with StoreFront or Microsoft Exchange/Sharepoint without any problems.
n-factor is a flexible authentication method. Each factor can call up the next factor. This is done via policy labels, which are called when a policy has been successfully applied. Policy labels are objects in which one or more policies are bound. In the case of authentication labels, a logon scheme, i.e. the appearance of the dialog, is also linked to the policy label.
n-Flows hide the complexity from the administrator and at the same time present the entire flow in a very clear way.
Native OTP
Native OTP is a method of using a second factor for authentication without having to buy expensive additional components such as RSA tokens or SMS tokens. Only a cell phone or tablet is required. A program must be installed on this device. Possible apps are:
- for Android: andOTP, Twilio Authy, Google Authenticator, Microsoft Authenticator, Cisco Duo Mobile, FreeOTP, Okta.
- for iOS: Okta, OTP auth, Step Two, Twilio Authy, Google Authenticator, Microsoft Authenticator, Cisco Duo Mobile, FreeOTP, iOS built-in authenticator.
The list is of course not complete. I use Okta and Google Authenticator.
How Native OTP works
Native OTP stores an attribute in the Active Directory. This attribute is the key used by the Authenticator software. In simple terms, the software encrypts the time. A more detailed explanation of the functionality of a native OTP solution can be found in Wikipedia. The screenshot shows the attribute for a user, displayed with the ADExplorer from Sysinternals (aka Microsoft)
How the flow looks like
From a user’s perspective
Device enrolment
The user has to surf to https://myaaa-vserver.mydomain.tld/manageotp.
Authentication
From an admin’s perspective
1st Factor
The first factor, shown in orange/yellow, is a so-called decision block. A decision block does not have a login scheme, i.e. it does not display a dialog. This decision block is used to find out whether it is a “normal login process” or whether someone wants to unroll an OTP device. Of course, the two connected policies are also not “normal” authentication policies, their action is neither LDAP nor RADIUS, TACACS, SAML, …, but NO_AUTHN. They are only used to call up the next policy label.
These are the two policies:
-
aaa_pol_select_enroldevice -rule "HTTP.REQ.COOKIE.VALUE(\"NSC_TASS\").EQ(\"manageotp\")" -action NO_AUTHN
This one gets triggered, if someone surfs to the URL /manageotp. Here we branch off into the device enrolment. This policy must be bound first.aaa_pol_select_dualauth -rule true -action NO_AUTHN
This one is a catch-all policy, for all the rest of the cases.
Device enrolment
The upper branch is used for device enrolment. The first factor shown in grey is a simple user name/password authentication. The second is the actual device enrolment.
2nd Factor: Authentication
I have named this factor sf_logon2manage. It is a simple username/password authentication. For this reason, the expression of the policy aaa_pol_select_enroldevice could be rewritten so that it can only be accessed by internal users. The expression would then be HTTP.REQ.COOKIE.VALUE("NSC_TASS").EQ("manageotp") && CLIENT.IP.SRC.IN_SUBNET(10.0.0.0/8).
The login schema must be based on the SingleAuthManageOTP.xml template and not on SingleAuth.xml, as this schema displays the dialog for rolling out a mobile device immediately after authentication.
Don’t forget to press “Select” before you press “Create”, otherwise it will use the noauth-schema, no matter, which schema you selected or which changes you did to this schema.
The action is a simple LDAP Policy. The expression has to be a simple true.
3rd Factor: Store the secret key in Active Directory
I have named this factor enroldevice. The schema that we assign must be the no_schema, as we do not want to display a dialog.
The LDAP action is crucial.
You see, I unchecked Authentication (we do not have a dialog to ask for a password). But we want to store a parameter, the so-called OTP Secret, in the Active Directory attribute userParameters. The rest is a normal LDAP-Action. Group Attribute and Sub Attribute Name are not needed. They came here, as I copied the original LDAP policy.
The expression for this policy is a simple true.
2 Factor Authentication
2nd factor: LDAP authentication
I have named this factor dualauth. It displays a two-factor logon. For this factor, we need a little trick if Single Sign On (SSO) to a backend application such as Citrix Storefront™, Microsoft Exchange™ or Sharepoint™ is required.
The problem here: For SSO, the last password that was entered is always transferred. However, we will probably ask for the password first and the token second in the dialog. This would transfer the token instead of the password and SSO would fail.
The trick is to give the password field a number and then connect a traffic policy to the gateway that references this number. For the sake of clarity, I will also show the traffic policy here.
Design this dialogue, based on DualAuth.xml. Click Select and More.
Leave User and Password Expression empty. Write 1 into the Password Credential Index field. This will be used in a traffic policy, to select the first password for Single Sign On (SSO). Enable Single Sign On and click Create.
Bind the same policy as you used for the single-factor authentication during device enrolment.
The traffic policy
The traffic policy uses Single Sign On to define which password is sent to the backend server. It must of course be the same number that was specified in the login scheme.
Protocol has to be HTTP of course, the password expression is the second term entered (the first one would be the username, the token came third). The Policy expression is a simple true.
3rd factor: OTP-verification
I have named this factor verify_otp. This one, similar to enroldevice, does not display a dialogue, so the schema would be no_schema. The authentication policy is an LDAP policy. It has to find the user, but instead of authenticating the user to LDAP (Achtive Directory), it extracts the secret key for this user from Active Directory (it is stored in the UserAttributes field, see here) and verifies the token.
Again, this LDAP profile is a non-authentication one (Authentication turned off). There is a Search Filter so that only users with a token stored in the userParameters field are found. The policy expression would be true.
