NetScaler native OTP

Native one time password using Citrix NetScaler is a new feature released in version 12.0 build 51.24. Using the native OTP capabilities of NetScaler reduces the need to purchase third party authentication systems when you want to protect your resources with multiple factors of authentication.

Native OTP is built on the nFactor authentication system which requires an AAA Virtual Server and advanced authentication policies. I have described nFactor in detail including it’s capability across the following posts:

http://www.jgspiers.com/single-sign-on-office-365-netscaler-saml-azure-mfa-authentication/

http://www.jgspiers.com/netscaler-nfactor-authentication-google-recaptcha-first-ldap-second-factor/

http://www.jgspiers.com/nfactor-authentication-with-netscaler-gateway/

Requirements:

  • Because we need to use nFactor, you’ll require a NetScaler Enterprise license at a minimum.
  • An Active Directory Domain Functional Level of 2008 and above is also supported.
  • A NetScaler bind account with permissions to manage the userParameters Active Directory attribute for enrolling users.

The following guide describes setting up a one-time password portal where users enrol their mobile devices and manage their enrolled devices going forward. NetScaler Gateway will also be used to protect XenDesktop resources by challenging users for their LDAP credentials and a one-time password. The mobile app used to provide the one-time password is Google Authenticator. Keep in mind that any application that supports one time passwords can be used, such as Microsoft Authenticator.

♣ Create AAA vServer
♣ Create Authentication Policies
♣ Create Login Schemas
♣ Create Policy Label
♣ Create Traffic Policy
♣ Bind Login Schemas to AAA vServer
♣ Bind Authentication Policies to AAA vServer
♣ Enrol Mobile Phones for One-Time Password
♣ Test One-Time Password Authentication
♣ Additional Thoughts & Troubleshooting

Create AAA vServer


Create an Authentication virtual server. An IP is not needed so set the IP Address Type to Non Addressable. Click OK.

Bind any server certificate to the virtual server. It does not matter which one.

Make sure the Portal Theme is set to RfWebUI. Click OK -> Done.

Next create an Authentication Profile and under Authentication Host enter any URL, it does not matter. Under Authentication Virtual Server select the AAA vServer you just created. Click Create.

Edit your NetScaler Gateway virtual server and under Authentication Profile choose the profile you just created. No basic authentication policies should be attached to the NetScaler Gateway vServer. Click OK.

Create Authentication Policies


Next we will create a required advanced Authentication Actions/Profiles, Policies, Login Schemas and Policy Labels. Firstly navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Advanced Policies -> Actions -> LDAP -> Add.

The first LDAP server action will be for standard LDAP authentication. Enter a name, the LDAP IP and bind account information.

Under Server Logon Name Attribute enter sAMAccountName. Under Group Attribute enter memberOf if you want to perform LDAP group extraction and under SSO Name Attribute enter cn. Click Create.

Create a second LDAP action, this time for OTP Management authentication. Uncheck Authentication and enter other details as below.

Under OTP Secret enter userParameters and click Create.

Create a third LDAP Authentication action for OTP Challenge authentication. Uncheck Authentication as with the above policy but this time under Search Filter enter userParameters>=#@. I discovered an issue were the OTP Challenge which is obviously going to be internet facing was allowing users to log on with single factor LDAP authentication if that user had not yet enrolled any device. Even though the Login Schema presented users with an OTP Passcode field and LDAP username/password fields, users did not have to enter anything in the OTP Passcode field if they had not enrolled a device. This is because the last factor in the chain has authentication disabled meaning Group Extraction is simply performed rather than verifying username and password. The Search Filter will now make sure a user has enrolled their device with OTP and if not, they cannot log on using LDAP+OTP until they enrol.

Navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Advanced Policies -> Authentication Policies -> Add.

Enter a name for the OTP LDAP Management policy. Under Action select the LDAP SAN action. Enter an expression of HTTP.REQ.COOKIE.VALUE(“NSC_TASS).EQ(“manageotp”) and click Create. 

Create a second authentication policy for OTP management using LDAP. Under Action select the LDAP authentication action that has authentication switched off. Under Expression enter HTTP.REQ.COOKIE.VALUE(“NSC_TASS”).EQ(“manageotp”). Using this expression, only users who browse to the OTP management portal will be challenged for this LDAP policy. Click Create.

Create a third authentication policy for OTP Challenge using LDAP. Select the same LDAP standard SAN authentication policy that has authentication turned on. Enter an expression of true and click Create.

Create a fourth Authentication Policy for OTP Management authentication. Under action select the LDAP SAN policy. Under expression enter HTTP.REQ.COOKIE.VALUE(“NSC_TASS”).EQ(“manageotp”). Click Create.

Create Login Schemas


Next we need to create two Login Schemas. Navigate to Security -> AAA – Application Traffic -> Login Schema -> Profiles -> Add.

Enter a name for the OTP management portal and under Authentication Schema click the pencil button.

Select the OTP management schema. Click Select. You should create your own schema and place on the NetScaler under directory /nsconfig/loginschema/. I have pasted the Login Schema for OTP management below which you can copy and paste in to your own XML file.

ManageOTPSchema.xml

Click Create.

Now create a second Login Schema, this time for OTP challenges. Enter a name and click the pencil button.

Select your challenge OTP schema under directory /nsconfig/loginschema/. This schema is made up of Username, Password and Passcode boxes for LDAP and OTP factors. Click Select. I have pasted the Login Schema for OTP challenges below which you can copy and paste in to your own XML file.

LDAPOTPSchema.xml

Click More.

Enter 1 in the Password Crential Index box. We want to capture the credentials entered in the first factor for authentication to StoreFront. Click Create.

Navigate to the policies tab and click Add.

Enter a name for the OTP management schema and select the same under Profile. Enter an expression of HTTP.REQ.COOKIE.VALUE(“NSC_TASS).EQ(“manageotp”) which makes sure only users browsing to the OTP management portal receive this Login Schema. Click Create.

Create another Login Schema for the OTP challenge for users authenticating to NetScaler Gateway. Enter an expression of true. Click Create.

Create Policy Label


To create Policy Labels which contain next factors of authentication, navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Advanced Policies -> Policy Labels -> Add.

Enter a name for the OTP Policy Label. Under Login Schema select noschema. Click Continue.

Under Select Policy click Click to select.

Select the OTP Managment LDAP policy where authentication is turned off.

Under Goto Expression select END. Click Bind. 

Click Add Binding again.

Select the LDAP OTP Challenge policy that has authentication turned off and the Search Filter defined.

Give this policy a higher priority. By default NetScaler will assign a priority of 110. Select END under Goto Expression and click Bind.

Click Close.

Create Traffic Policy


Next a Traffic Policy is needed to make sure StoreFront is presented with credentials (username/password) from the correct factor of authentication and not the OTP passcode factor which would obviously result in an error. Navigate to NetScaler Gateway -> Policies -> Traffic Policies -> Traffic Profiles -> Add.

Enter a name and scroll down.

Under SSO Password Expression enter http.REQ.USER.ATTRIBUTE(1) and click Create.

Click the Traffic Policies tab -> Add.

Enter a name and select the Request Profile you just created. Under Expression enter true. Click Create.

Browse to your NetScaler Gateway virtual server and next to Policies click +.

Use the drop-downs to select Traffic and Request. Click Continue.

Click Click to select.

Select the Traffic Policy you just created.

Click Bind.

Bind Login Schemas to AAA vServer


Now we have to bing the Authentication Policies and Login Schemas to the AAA vServer, as well as linking the Authentication Policies the single Policy Label. Edit your AAA vServer and click No Login Schema.

Click Click to select.

Choose the OTP management Login Schema which only evaluates if the users NSC_TASS cookie matches manageotp.

Click Bind.

Bind the second Login Schema for LDAP and OTP challenges. That Login Schema should have a higher priority. Anyone not browsing the OTP management URL are presented with an LDAP and OTP schema to authenticate to NetScaler Gateway. Click Close.

Bind Authentication Policies to AAA vServer


Click No Authentication Policy.

Click Click to select.

Select the management OTP LDAP policy which evaluates when users have a NSC_TASS cookie matching manageotp.

Click Click to select under Select Next Factor.

Select the noschema OTP Policy Label.

Click Bind.

Click Add Binding to begin binding the Authentication Policy for NetScaler Gateway authentication.

Click Click to select.

Choose the OTP challenge LDAP policy. This policy have an expression of true for all users accessing the NetScaler Gateway URL.

Under Select Next Factor click Click to select.

Select the noschema OTP Policy Label.

Click Bind.

Click Close.

Save the running configuration. The setup is complete.

Enrol Mobile Phones for One-Time Password


Users must firstly enrol their phones to be able to use OTP. The URL they need to use is https://netscalergatewayurl/manageotp. In my case, https://unifiedgateway.jgspiers.com/manageotp. When browsing to this URL, NetScaler sets a cookie against your session which allows the management OTP Login Schema and LDAP authentication policy to evaluate. Enter an LDAP username and password and click Submit.

Note: It would be possible to use a different URL such as https://manageotp.company.com and NetScaler appends the /manageotp directory to the end of the URL. In my case I’m using a single URL pointing to a Content Switch. As mentioned, a second URL could be configured to point to the same Content Switch.

Since this is the first time logging in, no devices will be registered. To register a device click Add Device.

Enter a name to identity the device your enrolling such as your personal Android or corporate mobile. Click Go.

A QR code displays. You’ll need to download Google Authenticator to your phone.

Once downloaded open Google Authenticator and click Scan a barcode. Scan the QR code and then click Done in the OTP management portal.

You’ll get the Added successfully! message. To test authentication is working with one-time passwords click Test.

Using your phone, look at the current one-time password.

Type this code into the management portal and click Go. You should receive a verification successful message. You can return to the OTP management portal at any time to test authentication, delete devices or add more devices.

Within Active Directory for users who have enrolled, the userParameters value is updated including the name users specified during enrollment. 

Test One-Time Password Authentication


Now when you want to authenticate with NetScaler Gateway, omit manageotp from your URL, instead entereing https://netscalergatewayurl. Since you aren’t browsing the management OTP URL, no cookie is set and as a result you are presented with the OTP challenge Login Schema. Enter your LDAP credentials and one-time password. Click Log On.

You should successfully authenticate and reach StoreFront.

Additional Thoughts and Troubleshooting

  • As mentioned in the comments. The OTP Management portal is protected by single factor authentication which is unsecure when internet facing. To make this portal more secure you can:
    • Protect the portal with additional factors of authentication such as User Certificate.
    • Restrict the portal to internal VLANs only using expressions on the Management Login Schema such as HTTP.REQ.COOKIE.VALUE(“NSC_TASS”).EQ(“manageotp”) && CLIENT.IP.SRC.IN_SUBNET(x.x.x.x/24).
    • Make use of Server 2016 Active Directory time-based group membership, which makes sure a user only has access to the portal for a short period of time externally and afterwards they have to enrol their phones from the corporate LAN or else request another attempt at enrolling externally using time-based groups.
  • A default installation of OTP is unsecure as users who have not enrolled can authenticate to the LDAP+OTP authentication challenge page without entering a one-time password. Because the user has not enrolled, their userParameters attribute in Active Directory will likely be <null>/<not set> and NetScaler will as a result simply accept LDAP credentials and authenticate the user. To get around this, we set a Search Filter on the OTP Challenging LDAP authentication policy. This is all explained in the above guide.
  • The NetScaler and client mobile device must have accurate time, otherwise OTP authentication will fail.
  • Google Authenticator for example is RFC 6238 TOTP compliant. https://tools.ietf.org/html/rfc6238
  • To view enrolment statistics, you can run command nsconmsg -g otp -d stats. The statistics shown are:
    • aaa_otp_tot_verify_success – Total number of successful OTP verifications.
    • aaa_otp_tot_verify_fail – Total number of failed OTP verifications.
    • aaa_otp_tot_manage_success – Total number of successful enrollments.
    • aaa_otp_tot_manage_fail – Total number of failed enrollments.
  • When troubleshooting OTP registration or verification, look at the syslog (ns.log) logs. You should also set the log level to DEBUG using command set syslogparams -loglevel DEBUG.

48 Comments

  • Carl Stalhood

    July 24, 2017

    Do you find it’s too easy to add more OTP devices? You only need single factor auth to access the device registration page, even after a device has already been registered. This means that access to the manageotp page must be restricted.

    Reply
    • George Spiers

      July 24, 2017

      Hi Carl. Yeah it is too easy out of the box, as you say it’s protected by just single factor. It would be easy to protect it with more factors if you can using additional Policy Labels, or make the management page internal facing only forcing users to enrol and perform management only from internal locations. Food for thought!

      Reply
      • Jochen Hoffmann

        August 1, 2017

        George, first of all: great article, many thanks for that and greetings to Carl btw.
        When it comes to the “easy” user device registration, maybe it’s a possibility to create dependency to a specific AD Group Membership, e.g. w/ the according authentication Policy. Yeah, it’s not that smart.
        Any possibilty to at some kinda traffic / AppFW policy, so the /manageotp sub URL is available only internally? Anyway, great new feature.
        Just some thoughts outta “old europe” … 😉
        Cheers, Jochen.

        Reply
        • George Spiers

          August 1, 2017

          Thanks. Couple of different options. You can restrict the OTP Management Login Schema by Group Membership as you say, and can also restrict the Login Schema to certain IP ranges. Use default expressions directly on the Management Login Schema policy object to define which conditions should evaluate to true. For example HTTP.REQ.COOKIE.VALUE(“NSC_TASS”).EQ(“manageotp”) && CLIENT.IP.SRC.IN_SUBNET(x.x.x.x/24)

          Reply
          • Timo

            September 18, 2017

            Hi!

            Regarding this: how about if we plan to use this for external users coming from various sources? These users will have accounts in our AD, but they come from all over. This is the reason we want to apply two-factor authentication. How would we protect the /manageotp in that case? IP-address won’t be an option. Could you explain more about the AD-group option?

          • George Spiers

            September 18, 2017

            AD Groups basically only allow users who are in a specific AD Group to access the OTP Management Login Schema. So for example, you may be able to use time based Active Directory group membership if you have a forest functional level of Windows Server 2016. If not, you can use standard Group Membership. You could also restrict the OTP Management page to internal IPs. The problem is, when a user has not enrolled for two-factor they have to authenticate to /manageotp to enroll. This is a problem because to authenticate to the OTP Management page they cannot use two-factor (because they have not yet enrolled) so have to use single factor, unless you have another two-factor method. If using single-factor, you have to take extra steps to secure that page.

      • Shannon

        August 2, 2017

        Nice Article. Maybe a thought is require a Domain Certificate on the PC to be able to enroll a device for OTP. So you’ll have dual factor to enroll a device for OTP. If you are on a nonauthorized device you will not be able to add a mobile device for OTP.

        Reply
        • George Spiers

          August 2, 2017

          Thanks and yes there are many different ways to go about it 🙂

          Reply
  • JD Mac

    July 25, 2017

    Is there a private release of the 51.24 firmware needed to enable this feature? I’m running that code version and my NetScaler does not show the “OTP Secret” field on the “Create Authentication LDAP Server” screen.

    Reply
    • George Spiers

      July 25, 2017

      No private builds. The public release is the one you need. 12.0.51.24.
      Are you running this build in production or a lab?

      Reply
      • JD Mac

        July 26, 2017

        It’s a Plat VPX running in a lab. The VPX promises it’s on 12.0.51.24.nc 🙂 That field is simply missing from the config screen.

        Reply
        • George Spiers

          July 26, 2017

          Can you run the following command as a test? “add authentication ldapAction test -serverName test -ldapBase test -ldapBindDn test -ldapBindDnPassword 123 -authentication DISABLED -OTPSecret 123” If that works, OTP is there but for some reason not showing in GUI. I’d suggest building another VPX. I’ve not seen it personally before and have upgraded a few appliances.

          Reply
          • JD Mac

            July 26, 2017

            Well, look at that. The parameter is there on the CLI. I’ll do my test config from CLI and redeploy the thing when I have a few minutes. Thanks!

  • Carl Stalhood

    July 26, 2017

    What Portal Theme do you have on your Gateway vServer?

    Reply
    • JD Mac

      July 26, 2017

      The Gateway is set to RfWebUI.

      Reply
      • Carl Stalhood

        July 26, 2017

        Hmm, I’m getting “please select one of the following” when I assign RfWebUI to Gateway. If I select X1 theme and leave RfWebUI on AAA, then everything works.

        Reply
  • Carl Stalhood

    July 26, 2017

    I figured out my RFWebUI problem. It’s caused by enabling HSTS in the Default Front End SSL Profile. This setting also broke my manageotp page.

    Reply
    • George Spiers

      July 27, 2017

      Thanks Carl, I replicated what you are seeing also here in my lab. Looks like the old way of inserting the STS header via Rewrite works..

      Reply
  • Jacob Dixon

    July 27, 2017

    I am testing this out and running into a couple of issues. When I click submit when logging in, the submit button turns to a refresh and just hangs. Chrome dev tools shows:

    Uncaught ReferenceError: _localize is not defined
    at Object.getLabelTypeMarkup (https://access.compsyscloud.com/logon/LogonPoint/plugins/ns-gateway/ns-nfactor.js:91:41)
    at Object.addStandaloneLabel (and more……)

    The other issue is when I refresh the page I am presented with the “My Registered Devices” page. I think there should be a “Done” button somewhere to let the user get back to the login or get to storefront. Doesn’t seem very straight forward unless I have something configured incorrectly.

    Reply
    • Jacob Dixon

      July 27, 2017

      I figured out what it was. I had the ChallengeOTP_Schema profile bound to the wrong authentication schema (was set to ManageOTPSchema.xml which is wrong).

      Let me ask you this though, is it possible to configure this to present a new page for the OTP only if the user belongs to a specific security group?

      Like most OTP there are normal steps:
      * User Logs In
      * If user is supposed to have OTP and hasn’t setup OTP then present the Add Devices page
      * If user is supposed to have OTP and is setup, then present a new page to get the OTP
      * User is presented storefront page after correct OTP is entered

      Reply
      • George Spiers

        July 27, 2017

        Absolutely. So for example you could have one group in AD where members are those users who have registered with OTP. All other non-members are simply not OTP registered. When users authenticate with NetScaler, group extraction is performed and if users are members of the group they get the Challenge OTP schema. If users are not, they receive the Register OTP schema. To determine what Schema to present users with, expressions on NetScaler would be used such as “HTTP.REQ.USER.IS_MEMBER_OF(“OTPGroup”)”. You’d have to keep the OTP Group up to date though with users who have enrolled. That wouldn’t be the NetScaler’s job.

        Reply
  • Timco Hazelaar

    July 28, 2017

    Aloha George,

    Great article, but I have one question.

    I followed your article, all is working fine, except for the SSO part to StoreFront. I think its mixing up “username” and “password” for SSO. In the eventlog on my StoreFront it states that user is trying to logon. And “MyPassword” is actually my password for my LAB infra… I double checked the “password credential index” field, which is 1..

    Regards,

    Timco

    Reply
    • George Spiers

      July 28, 2017

      Did you create the Traffic Policy and bind it to your NetScaler Gateway vServer? Doing that, and setting an index of 1 on the Challenge OTP schema is required.

      Reply
  • Daniel Weppeler

    July 28, 2017

    Which rights have your service user “svc_ns” ?

    I’ve get some error messages (aaad.debug log):

    +++++++++++++
    Fri Jul 28 14:07:10 2017
    /home/build/rs_120_51_22_RTM/usr.src/netscaler/aaad/ldap_common.c[260]: ns_show_ldap_err_string 0-305: LDAP error string: <>
    Fri Jul 28 14:07:10 2017
    /home/build/rs_120_51_22_RTM/usr.src/netscaler/aaad/ldap_common.c[446]: ns_ldap_check_result 0-305: LDAP action failed (error 50): Insufficient access
    +++++++++++++

    Reply
    • George Spiers

      July 28, 2017

      You need at minimum permission to be able to read and write to the userParameters attribute. You can use delegation in AD to grant the service account with those permissions.

      Reply
  • Pingback: EUC Weekly Digest – July 29, 2017 – Carl Stalhood

  • lowdez

    July 30, 2017

    Hey, great article ! thank you !
    I’ve followed your documentation to the letter and having issues when registering the mobile device –

    /home/build/rs_120_51_22_RTM/usr.src/netscaler/aaad/ldap_drv.c[554]: receive_ldap_user_search_event 0-261: User search succeeded, attempting user authentication(Bind) for
    Sun Jul 30 12:35:55 2017
    /home/build/rs_120_51_22_RTM/usr.src/netscaler/aaad/ldap_drv.c[558]: receive_ldap_user_search_event 0-261: noauth, preparing to update otp in attribute for , devicelen 7, devicename mobile
    Sun Jul 30 12:35:55 2017
    /home/build/rs_120_51_22_RTM/usr.src/netscaler/aaad/ldap_common.c[1466]: ns_ldap_register_otp 0-261: Attempt to manage otp when otp attribute is not defined!, sending reject
    Sun Jul 30 12:35:55 2017
    /home/build/rs_120_51_22_RTM/usr.src/netscaler/aaad/naaad.c[3322]: send_reject_with_code 0-261: Not trying cascade again
    Sun Jul 30 12:35:55 2017
    /home/build/rs_120_51_22_RTM/usr.src/netscaler/aaad/naaad.c[3324]: send_reject_with_code 0-261: sending reject to kernel for : testacc
    Sun Jul 30 12:35:55 2017
    /home/build/rs_120_51_22_RTM/usr.src/netscaler/aaad/naaad.c[3327]: send_reject_with_code 0-261: Rejecting with error code NULL

    Reply
    • George Spiers

      July 30, 2017

      Sounds like you don’t have the OTP Secret field completed in your LDAP profile? Under the field “OTP Secret” you should enter “userParameters” without the quotation marks.

      Reply
      • Lowdez

        July 30, 2017

        Yes ! that’s the one, must’ve missed it.
        Thank you !

        Reply
  • Igor

    August 2, 2017

    Excellent examples.
    I have been able to repeat and consolidate your examples login
    1. Certificates
    2. OTP.
    The question is how to solve the problem
    The same user receives a different profile at logon 1 and 2
    It’s probably because
    If you log on to a certificate, use the userPrincipalName =(username/domen) field
    With OTP-sAMAccountName =(username)
    Thank you!

    Reply
    • George Spiers

      August 2, 2017

      On your AAA vServer you could have a cert authentication policy bound with priority 100 with nextfactor set to PolicyLabel which has a UPN LDAP Policy attached. The AAA vServer can have a second authentication policy attached (higher priority e.g. 110) for when certificate authentication fails. This policy uses the OTP/SamAccountName LDAP policies and OTP challenge PolicyLabel..

      Reply
      • Igor

        August 5, 2017

        Thank you!

        Reply
  • Pingback: NetScaler Gateway 12 Native One Time Passwords (OTP) – Carl Stalhood

  • Steve Ludlow

    August 4, 2017

    I have a query. Pretty sure I have this configured as documented. With the LDAP server that has authentication disabled and userParamters>=#@ in the Search filter no users can login once registered, just get a “Try again or contact your help desk” error.

    If I remove the userParamters>=#@ from the search filter then I can log in with OTP. But obviously users that are not enrolled can also login without entering an OTP.

    Any clues as to what is going on here?

    Reply
    • George Spiers

      August 4, 2017

      If you look in AD for an affected (OTP registered) user, under the Attribute Editor tab what value is set for userParameters?

      I assume that users can log on to the Management OTP all the time, regardless if userParameters>=#@ is set? You should have two LDAP policies with authentication turned off. One for Challenging front-end authentication with userParameters>=#@ set and a second strictly for the OTP Management portal without userParameters>=#@.

      Reply
      • Steve Ludlow

        August 4, 2017

        So in userparameters for an AD account I have #@OP3T=GZHGSGC2NXQ2GIOU&, for example.

        Yes, can log into the management OTP all the time without issue.

        And yes, LDAP Polices setup exactly as described.

        Reply
        • George Spiers

          August 4, 2017

          Interesting, run a cat aaad.debug from CLI for a single login that fails with this error. Feel free to post the output here or to my email george@jgspiers.com

          Reply
      • Igor

        August 9, 2017

        I’m checking the user’s identity to the group. Detected if the OTP device is not registered, you can log on to the system without an access code. I had to make a complicated filter.
        &(userParameters>=#@)(memberOf:1.2.840.113556.1.4.1941:= CN=NetScalerExtUser,CN=Users,DC=v…..,DC=s…,DC=…)

        Reply
  • Ciprian

    August 4, 2017

    What if you have GSLB serving one single URL around the globe ? Will the same OTP work on different Netscaler pairs part of the GSLB .. not sure how the OTP is generated therefore I’m just asking if this is possible ..

    Thank you

    Reply
    • George Spiers

      August 4, 2017

      Yes it will work just fine. So long as the NetScaler appliances all probe the same Active Directory domain for authentication!

      Reply
  • Stan

    August 11, 2017

    So I can register my device fine. I can see that the attribute/property is updated correctly in AD. However, when I test, I don’t go any further than ‘Test failed for my phone’.

    Thoughts?

    Reply
    • George Spiers

      August 11, 2017

      You are testing and getting this error using the Manage OTP portal or when trying to log on to NetScaler Gateway? Run an AAAD Debug using CLI to see if you can pick up any pointers as to why it is failing.

      Reply
  • Pingback: Detailed Change Log – Carl Stalhood

  • Srini

    September 12, 2017

    I followed your article and got OTP working for RfWeb, but services site with native Receiver client is not working. When adding an account, Receiver challenges for OTP but the authentication fails. I have not checked AAAD logs yet, wanted to check if you have tested services site using Receiver client.

    Reply
    • Srini

      September 12, 2017

      I just read Carl’s blog and found that OTP uses nFactor & that doesn’t support Receiver clients

      Reply
      • George Spiers

        September 12, 2017

        Correct. nFactor is not yet supported for native Receiver clients.

        Reply
  • Jeff Sani

    September 17, 2017

    Hey George,

    Thanks for all these great articles. One typo to correct in your post:

    Enter a name for the OTP LDAP Management policy. Under Action select the LDAP SAN action. Enter an expression of HTTP.REQ.COOKIE.VALUE(“NSC_TASS).EQ(“manageotp”) and click Create.

    The reference image actually has a different name displayed. Minor thing but thought you might want to know. I agree with your comments about the documentation and I already voiced concern about it and am working with PM to improve it. I can tell you that much of the other feedback about the missing controls is being addressed. This is V1 of this great feature and so far the feedback has been overwhelming so I think it was a hit. Thank you again for all your contributions.

    Regards,
    Jeff

    Reply
    • George Spiers

      September 18, 2017

      Thanks for pointing that out Jeff. I corrected the screenshot. Regarding documentation I can’t remember making any comments on that, but agree it is a great feature which my customers are already embracing!

      Reply

Leave a Reply