nFactor MFA policy that skips the wrong group
A financial services firm uses Citrix ADC 13.1 as a Citrix Gateway for 3,500 employees and 400 contractors. The nFactor flow is: first factor LDAP against dc=corp,dc=example; second factor RADIUS OTP only for members of CN=VPN-MFA,OU=Security Groups,DC=corp,DC=example; all other users should go straight to the Gateway. The LDAP action uses a user search base of OU=Employees,DC=corp,DC=example and a group search base of OU=Employees,DC=corp,DC=example, with memberOf as the group attribute. The second-factor policy uses the expression http.REQ.USER.GROUPS.CONTAINS("VPN-MFA") and is bound in a policy label after LDAP. Contractors in OU=Contractors cannot authenticate at all, and employees in VPN-MFA are not prompted for OTP. The help desk sees LDAP bind success but an empty group list. The firm must fix this without weakening MFA for the security group and without requiring a second login for contractors.
1. Diagnose both symptoms and propose a corrected group-extraction design.
Read the worked answer
Both symptoms come from search bases that are too narrow. The user search base is OU=Employees, so the LDAP action cannot locate contractor accounts under OU=Contractors; that explains why contractors cannot authenticate even though a bind may succeed in a test. The group search base is also OU=Employees, so the VPN-MFA group under OU=Security Groups is never found. The result is an empty group list, and the second-factor expression evaluates false.
Correct the LDAP action so the user search covers both populations, for example a base of DC=corp,DC=example with a subtree scope and an appropriate user filter. Set the group search base to a scope that includes OU=Security Groups, OU=Employees, and contractor groups, typically DC=corp,DC=example with subtree scope. If the directory uses nested groups, enable nested group search and confirm that the group attribute and filter match the directory schema. Test with a contractor account and an employee in VPN-MFA, and inspect the extracted groups before changing the second-factor policy. Avoid granting access based on an empty group list; an empty list should be treated as a configuration failure, not as proof that the user is not in the MFA group.
2. Why did VPN-MFA employees not receive an OTP prompt, and how do you make the second factor fail closed?
Read the worked answer
They were not prompted because the group list was empty. http.REQ.USER.GROUPS.CONTAINS("VPN-MFA") returned false, so the policy label moved to its next factor, which allowed the user to reach the Gateway without RADIUS. That is a fail-open design: a group-extraction failure looks identical to a user who is not in the MFA group.
Fix extraction first, then make the policy structure explicit. After LDAP, add a policy that checks whether group extraction produced any groups. If the list is empty, present an error or deny rather than continuing. For users with a populated group list, evaluate the VPN-MFA policy; members go to RADIUS, and non-members go to an explicit allow/end factor. Do not place an unconditional end policy immediately after LDAP. Test the negative case by temporarily pointing the group search base at the wrong OU and confirming that authentication fails closed, then restore the correct base.
Verify with the nFactor visualizer and authentication logs that the group list contains VPN-MFA before the RADIUS factor is selected. Keep the RADIUS factor bound only to the MFA policy label so that other users cannot bypass it by manipulating the next-factor path.
3. Contractors should not be forced into MFA, but they must be authorized only for the contractor store. How do you implement authorization without a second login?
Read the worked answer
Keep the contractor experience as a single LDAP login, but make authorization depend on extracted groups. After LDAP, the group list should include contractor groups from OU=Contractors and employee groups from OU=Employees. Use a Gateway session policy or SmartAccess policy that evaluates the contractor group and assigns a restricted session profile: only the contractor StoreFront store, no full VPN tunnel, and the minimum network access required. Employees in VPN-MFA still go through RADIUS because their group matches the MFA policy.
The key is to separate authentication from authorization. Contractors authenticate once with LDAP and then receive a restricted session based on group membership. Do not create a second factor for them just to distinguish them from employees. Bind the session policy to the Gateway vserver and test with a contractor account to confirm that only the contractor store is visible and that direct internal resources are blocked. Also test an employee who is not in VPN-MFA to confirm that they reach the employee store without OTP, and an employee in VPN-MFA to confirm that RADIUS is enforced.