Jump to content
Welcome to our new Citrix community!

STF URL based on AD Group


tohadlock

Recommended Posts

So we have several StoreFront sites on our STF servers.

I need to be able to redirect users based on an AD group there account is in.

We are using NS ADC VPX in front of the STF servers

We have a single gateway that has  multiple session policies that point to different STF URL's.

Gateway 1 

  • mydomain.com/Citrix/Prod (no AD group)
  • mydomain.com/Citrix/Dev (Dev Users AD Group)
  • mydomain.com/Citrix/Test (Test Users AD Group)

 

I need to be able to add a user to an AD group and  have the user presented to a different STF site something similar to the above example.

I am rather new to the ADC so I might get lost quick.

 

Thank you in advance for your assistance.

 

Link to comment
Share on other sites

Create AAA groups for the users in each AD group. The group names on the ADC must exactly match those in AD (it is case-sensitive).

Then create a session profile for each of the groups point to the correct StoreFront site.

Create a session policy for each session profile.

Finally bind the corresponding session policy to each AAA group defined above.

Make sure that the priorities of these policies are higher  (meaning a lower number) than the default session policy (if there is one) bound to the gateway vServer.

Link to comment
Share on other sites

Thank you Sam for your help.

I believe I understand this process now.

 

I created a single "Test" instance following your instructions but I must have done something wrong as my user is not in the group but is getting the "Test" sight rather than the default.

Any ideas?

 

Link to comment
Share on other sites

I added some thoughts to the other thread.  Check your ldap policy for group extraction.

1) You should be retrieving the member_of attribute in the "Group attribute" field (under search filter).

2) By default the policy is not doing nested group extraction. So it only retrieves the AD groups the user account is a direct member of; not groups that group belongs to.

 

You can view the group extraction by observing the login event 

shell

cd /tmp

cat aaad.debug

a LOT Of events will output when you test the one user log on, but you should see a groups list retrieved to help you compare groups from AD to the group names on NetScaler for that account.

Link to comment
Share on other sites

10 minutes ago, Rhonda Rowland1709152125 said:

I added some thoughts to the other thread.  Check your ldap policy for group extraction.

1) You should be retrieving the member_of attribute in the "Group attribute" field (under search filter).

2) By default the policy is not doing nested group extraction. So it only retrieves the AD groups the user account is a direct member of; not groups that group belongs to.

 

You can view the group extraction by observing the login event 

shell

cd /tmp

cat aaad.debug

a LOT Of events will output when you test the one user log on, but you should see a groups list retrieved to help you compare groups from AD to the group names on NetScaler for that account.

 

Honestly, the output doesn't really mean much to this noobie.

 

aaad_output.txt

Link to comment
Share on other sites

Yeah, its an intimidating log.

 

EDIT:  I'm wrong ... this is the RADIUS line and not LDAP... (rest of notes apply, but I grabbed wrong line of log; or you don't have ldap events in this one.)

In Notepad++, line 51:

Fri May  7 11:38:12 2021
 /usr/home/build/adc/usr.src/netscaler/aaad/radius_drv.c[2128]: process_radius 0-203: extracted group string :(null)

 

This is an indication of no groups returned from AD, which means your LDAP policy action is not extracting group memberships OR your user only belongs to Domain Users which is not extracted.

 

When you see your ldap policy action (aka server), 

Your user attribute is usually "sAMAccountName"

Your search filter may be <blank> or something else which affect the results.

The Group Attribute should be "memberOf"

https://support.citrix.com/article/CTX216282

This article has an example, but it is also leading towards nested group extraction which I wouldn't start with.

 

Once the ldap policy is retrieving the group list, you should see an event for "extracted group" to be a list of one or more AD group names....

 

 

 

 

 

 

 

 

Edited by Rhonda Rowland
Added notes. made a mistake in reference.
Link to comment
Share on other sites

So I've been assuming LDAP/AD authentication with group extraction. While group extraction with radius is also possible, the settings may be different.  But no group extraction in the radius events shown in that log.  Older article that may apply to radius (but the version is pretty way back):  https://support.citrix.com/article/CTX222260

Link to comment
Share on other sites

34 minutes ago, Rhonda Rowland1709152125 said:

Yes - that appears to be able to do ldap group extraction; but all of your aaad.debug events were radius.

 

Correct, it looks like only RADIUS is setup as authentication.

Can I just add another Basic authentication such as LDAPS? (Primary or Secondary?)

I'm thinking we'll have 2 boxes on the login page if we have a P and S login.

 

 

 

 

Link to comment
Share on other sites

IF the gateway is using classic policies, then:

a) two policies in the same bind point (primary) is a cascade aka LDAP OR RADIUS (only one has to work)

b) one policy in primary AND one policy in secondary is a two-factor: LDAP AND RADIUS and you have to meet both to get in.

 

Do you want LDAP authentication, LDAP and RADIUS, or something else?

If you want both, then bind one to primary and the other secondary (usually ldap, then radius) but there may be other factors at work.

 

But you can add the ldap policy, but this is going to affect all users on that vpn vserver.

 

 

 

 

 

Link to comment
Share on other sites

40 minutes ago, Rhonda Rowland1709152125 said:

IF the gateway is using classic policies, then:

a) two policies in the same bind point (primary) is a cascade aka LDAP OR RADIUS (only one has to work)

b) one policy in primary AND one policy in secondary is a two-factor: LDAP AND RADIUS and you have to meet both to get in.

 

Do you want LDAP authentication, LDAP and RADIUS, or something else?

If you want both, then bind one to primary and the other secondary (usually ldap, then radius) but there may be other factors at work.

 

But you can add the ldap policy, but this is going to affect all users on that vpn vserver.

 

 

 

 

 

 

Actually, I'm used to LDAP then RADIUS. (I haven't seen or used only RADIUS)

I'm assuming I can add LDAP in the primary area and bind it to a higher priority?

The user would get their AD prompt then be prompted with 2FA.

 

OK, so I put LDAP in at a higher priority and I "think" I am seeing LDAP queries.

 

New_Debug.txt

Link to comment
Share on other sites

Cascades vs two factor:

If you have both LDAP and RADIUS in the primary bind point, your users are doing LDAP first (if it works, then no further authentication). IF ldap fails, then it does radius only.  This is not two factor.

If users need to pass LDAP and RADIUS to get in, then LDAP needs to be primary and RADIUS needs to be in SECONDARY bind point. Both have to succeed or you will be denied.

 

Regarding the log:

You are doing LDAP first and then going to RADIUS, but hte user isn't being found.   Issue in the following lines:

 

(Viewing in notepad++; for line counts)

Line 117:   

/usr/home/build/adc/usr.src/netscaler/aaad/ldap_common.c[1405]: ns_ldap_search 0-353: Searching for <<(& (sAMAccountName=user@domain.com) (objectClass=*))>> from base <<dc=corp, dc=local>>

 

Then later at Line 138-139:

Fri May  7 13:13:08 2021
 /usr/home/build/adc/usr.src/netscaler/aaad/ldap_drv.c[499]: receive_ldap_user_search_event 0-353: ldap_first_entry returned null, user user@domain.com not found

 

Reason:

LDAP is failing for this account probably because your policy says sAMAccount Name but you are providing a UserPrincipalName during logon.

 

If your policy is set for sAMAccountName format, then during the gateway login just provide user name:  user1

not domain\user1 or user1@domain.com

 

If your user will be supplying a userPrincipalName during login, then the LDAP policy user attribute needs to be userPrincipalName (and not sAMAccountName) and the user account would then be:  user1@domain.com during the sign in on gateway.

Be sure your test account in AD has a first and last name specified, correct upn for what you are testing and the correct group memberships.

 

 

 

 

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...