The challenge
A remote access front door that needed a second factor
The client is a Canadian healthcare organization. Its staff reach the applications and desktops they work in every day through a Citrix Virtual Apps and Desktops environment, published through Citrix StoreFront and a NetScaler Gateway. Sign-in relied on a username and password checked against Active Directory.
The organization decided to modernize that sign-in with multi-factor authentication: a username, a password and a one-time token on a single login screen, with the token checked over RADIUS by the organization's own token service. An earlier plan built around a different authentication model was set aside in favour of this approach.
Two things made the change delicate. Remote access was a live service staff depended on, so nothing could be switched on until it had been proven. And parts of the underlying platform were running an older release, so compatibility had to be confirmed rather than assumed before any configuration began.
Our approach
BITSUMMIT delivered the work as a fixed sequence of four phases. Every configuration change was built and validated in a proof-of-concept environment first, then promoted unchanged to QA and finally to production, so no untested logic reached users.
Phase 1: Environment preparation and validation
Before touching configuration, the team validated that the existing environment could support the new sign-in flow. That covered StoreFront and virtual delivery agent compatibility, NetScaler firmware and feature readiness for advanced authentication policies, DNS and load balancing naming, firewall dependencies for directory and RADIUS traffic, and SSL certificate availability. It also confirmed that the client had created the directory groups the new flow relies on. Any gaps were documented and shared before Phase 2 started.
Phase 2: RADIUS, StoreFront and Gateway configuration
BITSUMMIT retired the legacy basic authentication policies on the gateway and built a multi-step nFactor authentication flow in their place: the Active Directory password over LDAP first, then the token over RADIUS. A login schema presents username, password and token on one screen, and advanced authentication policies control the order of factors.
The same phase introduced load balancing for the StoreFront tier, with health monitors, persistence and certificate bindings, and pointed the gateway at the load-balanced address instead of individual servers. Failover behaviour was tested against explicit pass/fail criteria, with a documented rollback procedure in case a test failed. Changes were promoted from QA to production in coordination with the client's network and security teams, with transition support available during rollout.
Phase 3: Firewall and connectivity testing
The client owned its firewall rules. BITSUMMIT validated them: RADIUS communication between the gateway and the token service, LDAP and LDAPS connectivity to the domain controllers, and gateway reachability to the StoreFront servers. Any failures or latency were documented for the client's teams to review.
Phase 4: Testing, documentation and knowledge transfer
The full sign-in was tested end to end with a pilot group of users and hardware tokens, with authentication logs captured to confirm each factor was processed correctly. StoreFront failover was tested by taking one server offline and confirming traffic moved to the remaining node with user access intact.
BITSUMMIT then delivered an as-built document covering the authentication flow, profiles and bindings, the login schema, the load balancing design, updated architecture diagrams, and an upgrade readiness summary with recommended next steps. Functional test results were recorded as user acceptance testing evidence, and structured knowledge transfer sessions for the client's technical staff were held before the production cutover.
Platforms
- Citrix Virtual Apps and Desktops and Citrix StoreFront
- NetScaler Gateway with nFactor authentication and load balancing
- Active Directory (LDAP/LDAPS) and RADIUS token authentication
- DNS and SSL certificates
The outcome
The engagement was designed to deliver:
- A second factor on remote access. Staff now need a password and a token before they reach their apps and desktops, all on one login screen.
- Change proven before it reached users. Every configuration passed through proof of concept and QA before production, with defined pass/fail criteria and a rollback plan.
- More resilient access. A load-balanced StoreFront tier, tested by taking a server offline, so a single server failure does not take sign-in down.
- A team that owns it. An as-built document, recorded test evidence and knowledge transfer, so the client's staff can run and troubleshoot the solution themselves.
- A view of what comes next. An upgrade readiness summary listing dependencies and recommended next steps for the platform.
