Jump to content
Welcome to our new Citrix community!

Advanced authentication policy to match on LDAPS usernames that contain certain characters


Josh Slaney

Recommended Posts

Hello, 

 

I've implemented MFA authentication successfully for administration of the Netscaler appliances.  However, there are certain users I want to skip the MFA authentication for.  I have created a separate advanced authentication policy to match on those users and applied it with lower priority than the default auth policy.  The policy looks like this:

 

add authentication Policy NO_MFA_LDAP -rule "AAA.LOGIN.USERNAME.CONTAINS(\"user1\")" -action LDAPVIP
bind system global NO_MFA_LDAP -priority 100 -gotoPriorityExpression END

 

This policy appears to be working properly for user1.  Is this the correct way to setup an advanced policy for LDAPS auth based off the login username?

 

Thanks,

 

 

Link to comment
Share on other sites

For clarity:  Lower priority should mean less important and refers to higher index number. High priority should mean high importance and has a lower index.  Meaning priority 1 is more important than priority 100 and priority 1 overrides priority 100. (Just in case, you meant lower priority means lower index, this should help make sure we are describing the same thing.)

 

When you make the override (don't do authentication for these users) less important than the default policy, then the default policy takes effect first. (If you in fact meant it had lower index but in fact higher importance, than it likely correct.)

 

Without seeing the policy bindings, its hard to say if it is correct. Testing the "edge" cases should confirm if it is or isn't working as expected. And viewing the AAA authentication output in /tmp/aaad.debug can help you confirm which authentication events have occurred and if they succeed or fail:

shell

cd /tmp

cat aaad.debug

 

While what you describe might work, the priority description sounded odd to me. But you have to confirm bindings, next factors,  and priorities achieve what you intend. 

IF you do ldap BEFORE your second factor, you could put all your users who are exempt from second factor into a specific "no2FAreq" group. Then when you do your group extraction, you can exempt the 2nd factor based on group membership.  It would be a variant of this example:  https://support.citrix.com/article/CTX220793/nfactor-dual-factor-authentication-with-selective-authentication-factors-based-on-active-directory-group-membership (You might not need the first group extraction part, but you could see how to use groups to determine single vs. two factor authentication options.)

But the group filter might be more flexible for you than by user name criteria. If the priorities are correct, your method may work to.

 

Main thing is to make sure you that are properly building the next factor as a 2 factor required. So when you test be sure you test scenarios:

a) single factor only user with good and bad password and confirm only the ldap is required. And bad passwords are rejected.

b) two factor required user with good first and second credential.  Logon works and verify both authentication events fired.

c) two factor required user with good first and bad second credential: confirm logon fails.

d) two factor required user with bad first and bad second credential: confirm logon fails.

e) two factor required user with bad first and second credentials: should fail (and only first confirmed; second won't be attempted)

>> The two factor failure tests help confirm, you actually implement 2factor required and not a cascade where only one is required to get in.

 

Test a two factor user whose name is close to the single factor only criteria if not doing a group-based model, to make sure your expression for exemptions is narrow enough not to allow additional users to sneak in with single factor only requirements.

 

 

Link to comment
Share on other sites

22 hours ago, Rhonda Rowland1709152125 said:

For clarity:  Lower priority should mean less important and refers to higher index number. High priority should mean high importance and has a lower index.  Meaning priority 1 is more important than priority 100 and priority 1 overrides priority 100. (Just in case, you meant lower priority means lower index, this should help make sure we are describing the same thing.)

 

When you make the override (don't do authentication for these users) less important than the default policy, then the default policy takes effect first. (If you in fact meant it had lower index but in fact higher importance, than it likely correct.)

 

Without seeing the policy bindings, its hard to say if it is correct. Testing the "edge" cases should confirm if it is or isn't working as expected. And viewing the AAA authentication output in /tmp/aaad.debug can help you confirm which authentication events have occurred and if they succeed or fail:

shell

cd /tmp

cat aaad.debug

 

While what you describe might work, the priority description sounded odd to me. But you have to confirm bindings, next factors,  and priorities achieve what you intend. 

IF you do ldap BEFORE your second factor, you could put all your users who are exempt from second factor into a specific "no2FAreq" group. Then when you do your group extraction, you can exempt the 2nd factor based on group membership.  It would be a variant of this example:  https://support.citrix.com/article/CTX220793/nfactor-dual-factor-authentication-with-selective-authentication-factors-based-on-active-directory-group-membership (You might not need the first group extraction part, but you could see how to use groups to determine single vs. two factor authentication options.)

But the group filter might be more flexible for you than by user name criteria. If the priorities are correct, your method may work to.

 

Main thing is to make sure you that are properly building the next factor as a 2 factor required. So when you test be sure you test scenarios:

a) single factor only user with good and bad password and confirm only the ldap is required. And bad passwords are rejected.

b) two factor required user with good first and second credential.  Logon works and verify both authentication events fired.

c) two factor required user with good first and bad second credential: confirm logon fails.

d) two factor required user with bad first and bad second credential: confirm logon fails.

e) two factor required user with bad first and second credentials: should fail (and only first confirmed; second won't be attempted)

>> The two factor failure tests help confirm, you actually implement 2factor required and not a cascade where only one is required to get in.

 

Test a two factor user whose name is close to the single factor only criteria if not doing a group-based model, to make sure your expression for exemptions is narrow enough not to allow additional users to sneak in with single factor only requirements.

 

 

To clarify, I had my NO_MFA_LDAP policy at 100 priority and I had my other policy that included the next factor at 110.  The 100 priority should get hit first on match with username.  The confusion I had on my side was that I wasn't seeing my the policy hits when running this:

root@netscaler# cd /var/nslog  

root@netscaler# nsconmsg -d current -g _hits 

 

However the behavior I was seeing indicated the policy was working fine.  Of course, I walked away and came back a day later and then was seeing the hits on the NO_MFA_LDAP policy.

 

I'll definitely run the tests you suggested. Thats great information.  

 

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...