Hands-on Lab Exercise Guide

Transcription

1 611: NetScaler is the Gatekeeper. Become the Keymaster. Hands-on Lab Exercise Guide Christopher Rudolph May

2 Table of Contents Table of Contents... 2 Overview... 3 Lab Preparation... 6 Exercise 1: Initial Device Configuration... 8 Exercise 2: Client-Side Authentication Exercise 3: Preventing Brute-Force Password Attacks Exercise 4: Authentication Profiles Exercise 5: Authorization Policies Exercise 6: Traffic vs. Session Policies Exercise 7: Server-side SSO using NTLM and Form-Based Authentication Exercise 8: SAML Client-Side Authentication

3 Overview Hands-on Training Module Objective Multiple authentication mechanisms and different standards are proliferating in today's enterprises. Multiple logins, different credentials and different requirements make authentication one of the biggest challenges when deploying new applications. In this lab, attendees will learn how to use Citrix NetScaler to provide single-sign on services to common web applications with differing authentication mechanisms. Prerequisites Basic NetScaler administration experience. Audience Citrix Partners, Customers, Sales Engineers, Consultants, Technical Support. Lab Environment Details The Student Desktop is accessed remotely using Citrix Receiver running on your laptop. All Windows applications such as the XenCenter (the XenServer GUI management tool), are accessed from the Student Desktop. 3

4 Lab Guide Conventions This symbol indicates particular attention must be paid to this step Special note to offer advice or background information reboot VMDemo Start Text the student enters or an item they select from a dropdown menu is printed like this Filename mentioned in text or lines added to files during editing Bold text indicates reference to a button or object Focuses attention on a particular part of the screen (R:255 G:20 B:147) Shows where to click or select an item on a screen shot (R:255 G:102 B:0) 4

5 List of Virtual Machines Used VM Name IP Address Description / OS AD.training.lab Windows Server 2012 R2 Domain Controller/Certificate Authority/DNS Apache Debian 6.0 Apache Web Server Exchange Windows Server 2008 R2 Exchange 2010/OWA NS_VPX_ NetScaler VPX 3000 NetScaler 10.5 (Build 55.8) NS_VPX_ NetScaler VPX 3000 NetScaler 10.5 (Build 55.8) Sharepoint Windows Server 2008 R2 Sharepoint 2010 Foundations SQLServer Windows Server 2012 R2 MS SQL Required Lab Credentials The credentials required to connect to the environment and complete the lab exercises are shown within the step by step instructions and are summarized below: VM Name Username Password Description AD.training.lab Administrator Citrix123 Domain Controller/Certificate Authority/DNS NS_VPX_1 nsroot nsroot NetScaler VPX NS_VPX_2 nsroot nsroot NetScaler VPX Reserved IP Ranges IP range Description NetScaler Virtual IP Range List of DNS Entries DNS Entry IP Address Corresponding VM ad.training.lab Active Directory Domain Controller sqlserver.training.lab Microsoft SQL Server sp.training.lab Microsoft Sharepoint 2010 Server exchange.training.lab Microsoft Exchange 2010 Server ns1.training.lab NetScaler VPX 1 ns2.training.lab NetScaler VPX 2 apache.training.lab NetScaler Load Balanced Virtual Server apache2.training.lab NetScaler Load Balanced Virtual Server cs.training.lab NetScaler Content Switching Virtual Server sharepoint.training.lab NetScaler Load Balanced Virtual Server apache3.training.lab NetScaler Load Balanced Virtual Server aaa-df.training.lab NetScaler AAA Virtual Server aaa-sf.training.lab NetScaler AAA Virtual Server aaa-saml-sp.training.lab NetScaler AAA Virtual Server aaa-saml-idp.training.lab NetScaler AAA Virtual Server 5

6 Lab Preparation Attach XenCenter to Your XenServer Overview XenCenter is a graphical user interface application used for managing one or more XenServers. You will be using XenCenter to manage the XenServer needed for the lab. Step by step guidance Step Action 1. XenCenter will automatically launch when the Student Desktop launches. 2. Click Add Server to add your physical XenServer to XenCenter. 6

7 3. Enter your physical XenServer parameters from your welcome screen. IP Address Username admin Password Your XenServer password You may find it easier to copy and paste the password to ensure it is entered correctly. 4. Click Add. Your Physical XenServer name will be different. XenCenter will attach to your physical XenServer. Summary You have logged on to the lab environment and attached your XenServer to XenCenter. 7

8 Exercise 1: Initial Device Configuration Overview In this exercise, we will enable the required features and add a DNS suffix used throughout the lab exercises. Step by step guidance Estimated time to complete this exercise: 5 minutes. Step Action 1. Open Google Chrome and navigate to the NetScaler Administration UI using the NS_VPX_1 shortcut on the shortcut bar. Log on using the default credentials: User Name: nsroot Password: nsroot 8

9 2. First, you are going to need to enable the features that we are going to use for this lab. Navigate to System > Settings and click Configure Basic Features. Check the box next to the following features: SSL Offloading, Load Balancing, Rewrite, Authentication, Authorization, and Auditing, and Content Switching. Then click OK. 3. Next, you are going to add a DNS suffix for the training.lab domain to the NetScaler. Navigate to: Traffic Management > DNS > DNS Suffix and click Add. Type training.lab in the DNS Suffix field and click Create. 9

10 4. Save the NetScaler configuration by clicking the Save icon in the top right corner of the GUI. Then click Yes at the Confirm prompt. Exercise Summary We just completed the initial device configuration and enabled the necessary features used in this lab. We are ready to begin exploring the Traffic Management AAA functionality available in NetScaler

11 Exercise 2: Client-Side Authentication Overview In this exercise, we will configure single and dual factor client side authentication using the TM-AAA feature of the NetScaler appliance. We will explore how to setup an LDAP, Local, and Certificate authentication policy and verify how the NetScaler appliance processes keeps track of the user sessions. We will start slow and with the basics. If this is too basic, don t worry, this will get more interesting as we go along. Step by step guidance Estimated time to complete this exercise: 20 minutes. Step Action 1. First, create the necessary load-balancing configuration for the sample web applications we will use in the lab. While still logged on to the NetScaler GUI, navigate to Traffic Management > Load Balancing > Servers and then click Add. Enter the following parameters for the web server and then click Create. Server Name: apache IP Address:

12 2. Next, you are going to create the services for the servers that were just added to the NetScaler. Navigate to Traffic Management > Load Balancing > Services and then click Add. Create a new service using the following information and then click OK: Service Name: svc_apache Existing Server: apache ( ) Protocol: HTTP Port: 80 Then click Done. 12

13 3. Then create the load-balancing virtual server. Navigate to Traffic Management > Load Balancing > Virtual Servers and then click Add. Create a new virtual server using the following parameters and click OK: Name: lb_vsrv_apache Protocol: HTTP (default) IP Address: Port: 80 (default) 13

14 4. Click No Load Balancing Virtual Server Service Binding to add the services. Under Service Binding, click Click to select. Check the box next to svc_apache and click OK. Click Bind, click OK, and then click Done. 14

15 5. Save the NetScaler configuration by clicking the Save icon in the top right corner of the GUI. Then click Yes at the Confirm prompt. 6. Next, we are going to inspect the HTTP request/response headers to see what type of authentication the application is requesting. Open a Firefox browser window and click on the HTTP header viewer tool: LiveHTTPHeaders. The LiveHTTPHeaders plugin window will appear. 7. In the new browser tab, type the URL for the web application that is being load-balanced by the NetScaler: This FQDN resolves to the virtual IP. You should get prompted for authentication. This prompt comes from the web application. 15

16 8. In the LiveHTTPHeaders window, check the request and response headers. Look for the type of authentication requested by the website: In the 401 response, the WWW-Authenticate header defines the type of authentication required by the server, in this case it is just Basic authentication. 9. Fill out the credentials fields. After successful log on, you should have access to the webpage. Username: user1 Password: Citrix123 After logging on to the phpmyadmin web application, close the Firefox window. Basic authentication uses a base64 encoded string to represent the username and password separated by a :. Anyone sniffing the wire can get access to the user s credentials. In order to secure the authentication process, either use SSL in combination with a stronger authentication scheme. To protect our application, we will use dual factor authentication using LDAP and LOCAL. 16

17 10. Let s create our LDAP configuration to authenticate the user against the Active Directory service. Return to the NetScaler configuration utility and navigate to: Security > AAA Application Traffic > Policies > Authentication > Basic Policies > LDAP. Select the Servers tab and click Add. Create a new server profile using the following parameters: Name: AD.training.lab Server IP: Selected IP Address: Port: 389 Type: AD (default) Security Type: PLAINTEXT Base DN: dc=training,dc=lab Administration Bind DN: administrator@training.lab BindDN Password: Checked Administrator Password: Citrix123 Confirm Administrator Password: Citrix123 Server Logon Name Attribute: samaccountname Group Attribute: memberof Sub Attribute Name: cn SSO Name Attribute: Select <<New>> then type samaccountname Authentication: Checked User Required: Checked Click Create. 11. Select the Policies tab. Click Add and congire the policy using the following parameters: Name: LDAP_training Server: AD.training.lab Expression: ns_true 17

18 12. Now, let s define the Local configuration. Navigate to: Security > AAA Application Traffic > Policies > Authentication > Basic Policies > Local. Click Add. Name: LOCAL_training Expression: ns_true Click Create. 13. Now, we are going to create the AAA virtual server. Navigate to: Security > AAA Application Traffic > Virtual Servers. Click Add. 14. In the create virtual server window, use the following information: Name: aaa-df-vs IP Address: Click OK. 18

19 15. Under Certificates, click No Server Certificate. Click Click to Select. Then select wildcard.training.lab. Click OK, click Bind, and then click Continue twice. 19

20 16. Click the + icon under Basic Authentication Policies. Click Continue. Click Click to Select and then select LOCAL_training, then click OK and then click Bind. 20

21 17. Click the + icon under Basic Authentication Policies again. Select LDAP from the Choose Policy drop-down list box and then select Secondary from the Choose Type drop-down list box and click Continue. 18. Click Click to Select and then select LDAP_training, then click OK and then click Bind. Click Continue and then click Done. The reason we bound a Local policy as the primary and LDAP as the secondary is to prevent account lockout attacks. Since Local is usually used for OTP (one time password) authentication mechanisms, this protects the Active Directory account from any account lockouts that might occur from repeated authentication attempts. 19. Now we need to enable authentication at the Load Balancing Virtual Server level. Navigate to Traffic Management > Load Balancing > Virtual Servers. Select lb_vsrv_apache and click Edit. 21

22 20. Click Authentication from the Advanced column on the right side of the window. Select Form Based Authentication, type aaa-df.training.lab in the Authentication FQDN field and then select aaa-df-vs from the Authentication Virtual Server drop-down list box. Click OK then click Done. 22

23 21. Open a new Firefox window and navigate to: You should get automatically redirected to the AAA virtual server authentication page. 22. Enter the following credentials: Username: user1 Password 1: Citrix123 Password 2: Citrix123 Click Log On. If authentication passes these two sources, you should be prompted for additional credentials. This is being requested directly by the application. Ideally, the NetScaler appliance will be able to submit the necessary credentials to Single Sign-On to this application on behalf of the user. That is what we are going to do next! 23

24 23. To verify that the user has access to the application, enter the user1 credentials. Username: user1 Password: Citrix123 Close Firefox. 24. We will now create a session policy to enable SSO. In a session policy, we can determine certain parameters that apply to the user session. In the NetScaler configuration utility, navigate to: Security > AAA Application Traffic > Policies > Session and then click Add. Name the policy SSO_webapps and use an ns_true expression. Click the + button next to Request Profile to create a new Request Profile. 24

25 25. Name the profile SSO_profile and enable the following options: Single Sign-on to Web Applications: Checked Credential Index: Primary HTTPOnly Cookie: YES Click Create twice. 26. Now, bind the session policy to the AAA virtual server. Navigate to: Security > AAA Application Traffic > Virtual Servers Select the aaa-df-vs virtual server and click Edit. 25

26 27. Click on the Policies button in the right column under Advanced. Click the + button under Policies, then select Session from the Choose Policy drop-down list box and then click Continue. Click Click to select, select SSO_webapps and then click OK and then click Bind. Click Done. 26

27 28. Open a new Firefox window and navigate to You will be redirected to the AAA vserver. Enter the user credentials at the login page. User name: user1 Password 1: Citrix123 Password 2: Citrix123 Click Log On. You should not receive any prompt for additional credentials. Since the NetScaler is handling the SSO, it automatically responds to the 401 Unauthorized request with the necessary information the application is requesting. 29. Close the Firefox browser window Save the NetScaler configuration by clicking the Save icon in the top right corner of the GUI. Then click Yes at the Confirm prompt. Congratulations! You have configured Basic HTTP Authentication single sign-on. Continue to the next exercise. Exercise Summary In this exercise, we have configured a single and dual factor authentication with group extraction. We also configured a simple session policy to perform Basic HTTP authentication single sign-on to web applications. In the next exercise, we will explore some of the protection features to prevent brute force password attacks and how to leverage the AAA NetScaler framework to protect your application. 27

28 Exercise 3: Preventing Brute-Force Password Attacks Overview In this exercise, we will configure the new AAA parameters to slow down any brute-force password attacks. Step by step guidance Estimated time to complete this exercise: 10 minutes. Step Action 1. One of the AAA features in the NetScaler is the ability to define the maximum number of login attempts as well as a lockout timeout feature. While logged on to the NetScaler GUI, navigate to Security > AAA Application Traffic > Virtual Servers. Select the aaa-df-vs virtual server and click Edit. 2. In the Basic Settings pane, click the pencil icon to edit the parameters of the virtual server. Define the Max Login Attempts. In this example we will allow up to 3 login attempts. 3. In the Failed Login Timeout parameter, set it to 1. This will prevent any authentication requests from the same user within the next 60 seconds of the last failed attempt. Click OK. Then click Continue three times, and then click Done. 28

29 4. Open a new Firefox window and browse to You should be redirected to the AAA virtual server login page. Enter the wrong credentials three times. User name: user1 Password 1: 123 Password 2: 123 Click Log On. 5. At this point, the account has been temporarily locked out. Now, enter the incorrect user credentials one more time. You should receive a message stating that you have exceeded the maximum number of attempts. Verify that this is the case. 6. Close Firefox and reopen it. Browse to and attempt to log on as user2: User name: user2 Password 1: Citrix123 Password 2: Citrix123 You should be able to log on to the web application. 7. Close Firefox. After the 60 seconds have elapsed, reopen Firefox and browse again to You should be able to log on using the user1 credentials at this point. Verify that this is the case and then close Firefox. 29

30 8. Save the NetScaler configuration by clicking the Save icon in the top right corner of the GUI. Then click Yes at the Confirm prompt. 9. Congratulations! You have configured a simple account lockout mechanism using NetScaler. Continue to the next exercise. Exercise Summary We have learned how to configure the account protection features and lockout timeouts for an authentication virtual server. Next we will explore the new authentication profile feature and how to leverage it to further customize access to your application. 30

31 Exercise 4: Authentication Profiles Overview Authentication Profiles is a new feature introduced in NetScaler 10.x. In the past, there was a single authentication cookie assigned for each user session. As long as the client browser presented such cookie when contacting the NetScaler appliance, SSO was honored and the user was not prompted for credentials. With the introduction of authentication profiles, it is now possible to segregate authentication cookies per domain or virtual server. In this exercise, we will configure a simple policy that illustrates the usage of authentication profiles. This knowledge can be applied to other use cases according to your requirements. Step by step guidance Estimated time to complete this exercise: 20 minutes. Step Action In order to illustrate authentication profiles, let s first illustrate the problem. For this, we will create another virtual server and enable it for AAA authentication. 1. Navigate to Traffic Management > Load Balancing > Virtual Servers and click Add. 31

32 2. In the Create Virtual Server window, enter the following parameters: Name: lb_vsrv_apache2 Protocol: HTTP IP address: Port: 80 Click OK. 3. Click No Load Balancing Virtual Server Service Binding to add the services. Click Click to select. Check the box next to svc_apache and click OK. Click Bind and then click OK. 32

33 4. Click Authentication from the Advanced column on the right side of the window. Select Form Based Authentication, type aaa-df.training.lab in the Authentication FQDN field and then select aaa-df-vs from the Authentication Virtual Server drop-down list box. Click OK. Then click Done. 33

34 5. Since we are using the same backend service, we will access a new web application hosted on the same server. Open a new Firefox browser window and browse to this new virtual server address: 6. You should have been redirected to the AAA login page. Log on using the following credentials: User name: user1 Password 1: Citrix123 Password 2: Citrix From the same browser session, open a new tab and attempt to navigate to the first webapplication FQDN: Since the authentication cookie is globally valid, the user is logged on to the first web-application without any credential prompt, even when login through a different virtual server. Close the Firefox browser window. 8. Now, let s assume that you would like to use the same TM-AAA virtual server, but prevent users from navigating to other virtual servers without proper authentication. For this we will use authentication profiles. In the NetScaler configuration utility, navigate to Security > AAA Application Traffic > Authentication Profile. Click Add. At this point, you have authenticated with the appliance and redirected to the SugarCRM application login form. We will configure form-based SSO in a later exercise. For now, let s just focus on the face that you have already authenticated with the AAA virtual server and the session cookie has been created. Unfortunately, this cookie is used globally for any virtual server configured for AAA authentication. 34

35 9. We will create two profiles, one for each virtual server (or group of virtual servers) where we want to segment authentication. Use the following information to create the two authentication profiles: Profile 1 Profile 2 Name apache_profile apache2_profile Authentication VServer Name aaa-df-vs aaa-df-vs Authentication Host aaa-df.training.lab aaa-df.training.lab Click Create after each profile. 35

36 10. Navigate to Traffic Management > Load Balancing > Virtual Servers and select lb_vsrv_apache then click Edit. Under Authentication, click the pencil icon to edit the authentication parameters. Under Authentication Profile, select apache_profile and then click OK. Then click Done. 11. Repeat the same process with lb_vsrv_apache2 using apache2_profile. 12. Open a new Firefox window and browse to the first virtual server: Log on using the following credentials: User name: user1 Password1: Citrix123 Password2: Citrix123 You should see the protected area webpage. 13. Open a new tab in Firefox and browse to the second virtual server: 36

37 14. Since we are now using a different AAA cookie for each virtual server using the selected authentication profile, you are now prompted for credentials. Login with a different user account. User name: user2 Password 1: Citrix123 Password 2: Citrix123 After successfully logging on and seeing the SugarCRM logon screen, close Firefox Now, let s build a more compelling use case for the usage of authentication profiles. Imagine that you have to implement different authentication mechanisms for the different applications and restrict access based on group membership. Application 1 requires dual-factor authentication and application 2 requires single-factor. In addition, users of the contractors group are only authorized to access application 1. Users of the sales group are only authorized to access application 2. All access to these applications is done over a single externally accessible FQDN. To satisfy these requirements, we will build another AAA virtual server with only single factor authentication and modify our authentication profile and virtual server configuration to complete the implementation. 15. Since we have to support both applications through the same FQDN, we need to perform Content Switching based on the application virtual directory. Return to the NetScaler configuration utility and navigate to Traffic Management > Content Switching > Virtual Servers. Click Add. 37

38 16. In the Create Virtual Server window, enter the following parameters: Name: cs1 Protocol: HTTP IP Address: Port: 80 Click OK. 38

39 17. Under CS Policy Bound, click No Content Switching Policy Bound. Next to Select Policy, click the + button to create a new Content Switching policy. 39

40 18. In the Create Content Switching Policy pane, name the policy phpmyadmin and then enter the following expression into the Expression window: HTTP.REQ.URL.STARTSWITH( /phpmyadmin ) Then click Create. 40

41 19. You are now back on the Policy Binding screen. In the Target Load Balancing Virtual Server box, click Click to select. Select the radio button next to lb_vsrv_apache and click OK. Then click Bind. 20. Under CS Policy Bound, click 1 Content Switching Policy and then click Add Binding. Next to Select Policy, click the + button to create a new CS policy. 41

42 21. In the Create Content Switching Policy pane, name the policy sugarcrm and then enter the following expression into the Expression window: HTTP.REQ.URL.STARTSWITH( /sugarcrm ) Then click Create. 22. You are now back on the Policy Binding screen. In the Target Load Balancing Virtual Server box, click Click to select. Select the radio button next to lb_vsrv_apache2 and click OK. Then click Bind and then click Close. Click OK and then click Done to complete the creation of the CS virtual server. We will come back to this virtual server, as we need to create more Content Switching policies in order to get the correct authentication information sent to the corresponding target virtual server. 23. Next, we need to create an additional virtual server for single-factor authentication. Navigate to Security > AAA Application Traffic > Virtual Servers and click Add. 42

43 24. Create a new virtual server using the following parameters: Name: aaa-sf-vs IP Address: Click OK. 25. Under Certificates, click No Server Certificate. Click Click to Select. Then select wildcard.training.lab and click OK. Click Bind and then click Continue twice. 26. Click the + icon under Basic Authentication Policies again. Select LDAP from the Choose Policy drop-down list box and then select Primary from the Choose Type drop-down list box and click Continue. 43

44 27. Under Policy Binding, click Click to select. Then select the radio button next to LDAP_training and click OK and then click Bind. Click Continue. 28. Under Advanced, click Policies. Then click the + icon in the new Policies pane that displays. Select Session from the Choose Policy drop-down list box and click Continue. Under Policy Binding, click Click to select. Select the radio box next to SSO_webapps and click OK. Click Bind and then click Done. 44

45 29. Next, we need to modify the authentication profile we configured in a previous step to setup up the second virtual server for single factor authentication. Navigate to Security > AAA Application Traffic > Authentication Profiles. Click on the apache2_profile and click Edit. 45

46 30. Change the values to point to the new FQDN and AAA virtual server: Authentication Vserver Name: aaa-sf-vs Authentication Host: aaa-sf.training.lab Authentication Level: 1 Make sure the authentication level is set to 1 to force the NetScaler to prompt for credentials when navigating to an application set to authenticate with this profile. 46

47 31. We are not quite finished yet as there are other request and responses we need to divert to the correct target virtual server in order for the entire authentication process to work. To illustrate what needs to be done, open a new Firefox window and navigate to You should be redirected to the login page using the dual factor authentication configured for this site. Attempt to login. Use the following credentials: User name: user1 Password 1: Citrix123 Password 2: Citrix123 Unfortunately, after attempting to log on, we receive and error when the request is redirected to /cgi/selfauth/. Since there is no content switching policy that handles this type of traffic, the appliance responds with this error. Next, we will create the necessary policies to account for this type of traffic. 32. Optionally, you can open a new tab and verify that the authentication request to the other webapplication (SugarCRM) is sent to the alternate AAA virtual server configured for single factor authentication. Open a new tab in Firefox and navigate to Close Firefox and continue to the next step. 47

48 33. Navigate to Traffic Management > Content Switching > Policies and click Add. Configure a policy using the following parameters: Name: self-auth-dual Expression: HTTP.REQ.URL.PATH.SET_TEXT_MODE(IGNORECASE).STARTSWITH( /cgi/selfauth ) && HTTP.REQ.BODY(3000).CONTAINS( apache_profile ) Click Create. 34. Additionally, create another policy to handle the single factor authentication traffic. Select the self-auth-dual policy and click Add. Then, change the following parameters: Name: self-auth-single Expression: HTTP.REQ.URL.PATH.SET_TEXT_MODE(IGNORECASE).STARTSWITH("/cgi/selfauth") && HTTP.REQ.BODY(3000).CONTAINS("apache2_profile") Then click Create. 35. Now, we need to bind these policies to the Content Switching virtual server. Navigate to Traffic Management > Content Switching > Virtual Servers, select cs1 and click Edit. 48

49 36. Under CS Policy Binding, click 2 Content Switching Policies. Click Add Binding. Under Policy Binding, click Click to select then select the radio button next to self-auth-dual and click OK. Next, under Target Load Balancing Virtual Server, click Click to select. Select the radio button next to lb_vsrv_apache and click OK and then click Bind. 49

50 37. Click Add Binding again. Under Policy Binding, click Click to select then select the radio button next to self-auth-single and click OK. Next, under Target Load Balancing Virtual Server, click Click to select. Select the radio button next to lb_vsrv_apache2 and click OK and then click Bind. Click Close and then click Done to commit the changes. 38. We are ready to test our initial configuration. Open a new Firefox window and browse to: You should get redirected to the dual factor authentication login page. 39. Log on using the following credentials: User name: user1 Password 1: Citrix123 Password 2: Citrix Your session should be authenticated and single sign-on as user1 to the phpmyadmin application on the Apache server. Open a new Firefox tab and navigate to the second application URL: 50

51 41. You should have been redirected to the single factor authentication login page. Log on with the following credentials: Username: user2 Password: Citrix123 Your session is authenticated and the page redirected to the web application login page. In a later exercise, we will configure form-based single sign-on. 42. For now, let s just recap: We have satisfied 2 out of 3 requirements: - Used the same FQDN for both applications, by leveraging Content Switching - Different authentication mechanisms for each web application, by leveraging Authentication Profiles Now we need to focus on preventing unauthorized access based on group membership. We will configure additional authorization policies to ensure no malicious user can navigate to other URL without proper authentication. In the next exercise, we will complete the necessary configuration to accomplish this third requirement. 43. Save your configuration by clicking on the Save icon on the top right. Don t close your open session. You will be using it in the next exercise. 51

52 Exercise Summary In this exercise, we learn how to apply different authentication profiles to different virtual servers. This new feature is a major change in the AAA infrastructure as the NetScaler appliance can now keep track of multiple sessions to different applications. Also, by applying authentication profiles, the administrator can bundle applications so that SSO applies to a group of virtual servers, while still maintaining some authentication independence for those applications that require it. Next, we will explore authorization policies and how you can further customize access to your application. 52

53 Exercise 5: Authorization Policies Overview Authorization policies are used to restrict access to resources protected by the NetScaler appliance. Since we have full access to the AppExpert policy engine when creating authorization policies, specific expressions can be defined to allow access to specific resources under the right conditions. In this exercise, we will configure examples of authorization policies using different PI elements to illustrate how to use this feature in a production environment. Step by step guidance Estimated time to complete this exercise: 15 minutes. Step Action Recap: The previous scenario required that only users from certain groups access certain URL paths. In exercise 4, we enforce initial authentication when accessing the corresponding virtual servers serving applications; however, there is still a requirement that we have not addressed. If a malicious user attempts to navigate to a different URL pattern after authenticating successfully, he might still get unauthorized access to another application as the user session is valid and the user account exists in the directory service used for account validation. If you closed the previous session by mistake, refer to Steps of the previous exercise. 1. Let s create the necessary groups for the desired restrictions. In the NetScaler configuration utility, navigate to: Security > AAA Application Traffic > Groups and click Add. In the Group Name field, type Contractors. Then click OK and then click Done. Repeat the same process to create another group named Sales. 53

54 2. Navigate to Security > AAA Application Traffic > Policies > Authorization. Click Add. 54

55 3. Configure an authorization policy to allow only members of the Contractors group to access the first web site already set up for dual-factor authentication. Use the following parameters: Name: OnlyAllowContractors Action: ALLOW Expression: HTTP.REQ.USER.IS_MEMBER_OF( Contractors ) Click Create. 55

56 4. Configure another authorization policy to allow only members of the Sales group. Click Add again. Use the following parameters: Name: OnlyAllowSales Action: ALLOW Expression: HTTP.REQ.USER.IS_MEMBER_OF( Sales ) Click Create. 5. We need to bind these new policies to the corresponding Load Balancing virtual servers handling these applications. Navigate to Traffic Management > Load Balancing > Virtual Servers. Select lb_vsrv_apache and click Edit. 56

57 6. Under Advanced on the right side, click Policies. Click the + button to add a policy. Select Authorization from the Choose Policy drop-down list box, then select Request from the Choose Type drop-down list box and click Continue. 57

58 7. Under Policy Binding, click Click to select. Click the radio button next to OnlyAllowContractors and click OK. Click Bind and then click Done. 8. Repeat the same process to bind the OnlyAllowSales authorization policy to lb_vsrv_apache2. Before we start testing, we need to change the Default Authorization Action in order to enforce authorized access with the Authorization Policies that we configured in the previous step. Since the Default Authorization Action is Allow, we need to override such parameter either globally or at the virtual server level in order to apply more granular access through the new Authorization policies. In our particular example, the best place to adjust this parameter is in the Session Profile that we previously configured to perform HTTP Basic Authentication SSO. 9. Navigate to Security > AAA Application Traffic > Policies > Session. Click the Session Profiles tab and then select the SSO_profile policy and click Edit. 10. For Default Authorization Action, click Override Global and set it to DENY. Then click OK. 58

59 11. Now we can begin testing. Open a new Firefox browser window and browse to the URL of the first website: You should be redirected to the dual-factor authentication page. Since user1 is a member of the Contractors group, log on using the following credentials: User name: user1 Password 1: Citrix123 Password 2: Citrix Once the page loads, attempt to change the URL for the second web application, then hit Enter: You are redirected to the authentication page. Login with the same credentials: Username: user1 Password1: Citrix123 You should not have been authorized to access this URL pattern based on your group membership. 59

60 14. Close Firefox and reopen it. Browse to the second URL: Since user2 is a member of the sales group, log on with the following credentials: Username: user2 Password: Citrix123 You should be able to access the second web-application. 15. Attempting to change URLs while authenticated as user2 and accessing the first URL (/phpmyadmin), it is disallowed by the authorization policy. Try it! Authorization policies gives us a lot of control to ensure users only access authorized resouces; however, this authorization message is not the best user experience. We can enhance this by leveraging Responder policies to redirect the user to the appropriate authentication page if certain conditions are not met. The same policy engine expressions can be used to test for group membership and a valid session. 16. Save your configuration by clicking the Save icon on the top right corner. Exercise Summary In the previous exercise, we learn how to leverage authorization policies to protect resources behind NetScaler and ensure only authorized accounts get access to the correct resources. Since you have full access to the policy engine when creating authorization policies, you have granular control of these resources. 60

61 Exercise 6: Traffic vs. Session Policies Overview In this exercise, we will explore the differences and similarities between Traffic and Session policies and how we can use this type of configuration to apply a specific set of parameters. Step by step guidance Estimated time to complete this exercise: 15 minutes. Step Action 1. In a previous exercise, we leveraged session policies to apply certain parameters to a user session. In our example, we enabled HTTP Basic Authentication SSO, set the Default Authorization to DENY, and enabled the HTTP Only option for the authentication cookie for enhanced security. Navigate to: Security > AAA Application Traffic > Policies > Session. Click on the Profiles tab and select the SSO_profile to view the settings applied. Click Close when finished. Do not change any parameters! 61

62 Step Action A session policy is a set of expressions and settings applied to users, groups, or virtual servers. It is used for configuring specific settings for client connections, such as which type of credentials to use when attempting SSO, default authorization status, timeouts and SSO domains for HTTP authentication. Traffic Policies extend this functionality and provide more flexibility to perform SSO for other authentication mechanisms such as Kerberos, form-based authentication, or SAML SSO as well as provide similar functionality to session policies. In the next section we will configure a traffic profile to perform a simple SSO function for HTTP Basic authentication, replacing the functionality of session policy we create before. In a later exercise, we will leverage a Form-SSO profile in conjunction with a traffic policy to perform SSO into an application that uses an HTML form for authentication. 2. Let s create an SSO profile to be used with a traffic policy. Navigate to Security > AAA Application Traffic > Policies > Traffic. Select the Traffic Profiles tab, and then click on Add. 62

63 3. Create the Traffic Profile with the following parameters: Name: SSO_webapps_traffic Single Sign-On: ON Click Create. 4. Click the Traffic Policies tab and then click Add. 63

64 5. Create a new policy. Since we will attempt to SSO for all traffic, use a true expression. Potentially, this can be tailored to a particular URL pattern, or specific condition. Name: SSO_webapps_traffic Profile: SSO_webapps_traffic Expression: HTTP.REQ.IS_VALID Click Create. 6. Let s unbind the current session policy in order to use our traffic policy instead. Navigate to Security > AAA Application Traffic > Virtual Servers. Highlight the aaa-df-vs and click Edit. 7. Under Policies, click 1 Session Policy. 64

65 8. Highlight the SSO_webapps policy and click Unbind. Click Yes to confirm. Click Close and then click Done. Repeat the same process on the aaa-sf-vs AAA virtual server. 9. Next, we need to bind the Traffic policy. This is done at the Load Balancing virtual server level. Navigate to Traffic Management > Load Balancing > Virtual Servers. Select lb_vsrv_apache and click Edit. 10. Under Policies, click the + button. Select Traffic from the Choose Policy drop-down list box and then click Continue. 65

66 11. Under Policy Binding, click Click to select. Select the radio button next to SSO_webapps_traffic and click OK. Click Bind and then click Done. 12. It is time to test to see if our traffic policy performs the same basic SSO functions as the previous session policy. Open Firefox and navigate to You should be redirected to the dual factor authentication page. Use the following credentials: User name: user1 Password1: Citrix123 Password2: Citrix The user session should be authenticated and SSO is attempted in the same fashion as before. You should be logged on to the website as user1. Verify this is the case. 66

67 Step 15. Action SSO works the same as before. However, there is still one problem: Since we are performing SSO functions, attempting to logout of the application does not trigger a NetScaler AAA-TM session logoff. This can be seen as a security risk as the user just needs to refresh the page to get back into the application as an authorized user. Try this for yourself: Click the logout button and observe the behavior. 67

68 16. The web application session is terminated and the application triggers a 401 for the user to enter the corresponding credentials. However, since we are automatically performing SSO, all we need to do is to gain access to the application is click on Cancel and then refresh the page. 68

69 17. As a final step on this section, we will work on improving this Single Logout process. We will leverage Rewrite to accomplish this. We have to focus on two items: Expiring the application session using its own native mechanism Expire the TM-AA cookie for the user to be prompted for credentials We can use Rewrite to capture the request when the user clicks on the logout button, and then issue a Set-Cookie to expire the current AAA session cookie being used. 18. In Firefox, open a new tab and browse to and log on using the user1 credentials. Click on the LiveHTTPHeaders button. 19. Go back to the web application and click the logout button. You should now be prompted for credentials. Don t click on any button. 20. Go back to the LiveHTTPHeaders window. Scroll up and inspect the first request and the URL target when we clicked the Logout button. 21. Notice the logout mechanism the application is using: Send a GET request to main index document in the application URL base path including the current user token and an additional parameter specifying which user to expire: GET /phpmyadmin/index.php?token=xyz&old_usr=username We can tag along using Rewrite to this request structure and expire our own AAA cookie in order to perform a single logout. Close LiveHTTPHeaders and the Firefox tab. 69

70 The approach we will take is the following: Create a rewrite Action and Policy to expire the AAA cookie by issuing a Set-Cookie header with an expiration date in the past. Since the response to the logout request is a 401 response, some browsers do not honor cookies set in a 401. We will use Rewrite again to change this 401 into a 302 and redirect to the original URL. In addition, we will create these rewrite policies: a. Rewrite the response to change the STATUS code from 401 to 302 b. Rewrite the response to change the STATUS MESSAGE from Unauthorized to Moved Temporarily c. Insert a Location header in order to redirect the client browser to the original URL path. 22. First, let s create a rewrite policy and corresponding action in order to expire the AAA cookie used by the appliance for authentication. Navigate to AppExpert > Rewrite > Actions. Click Add. 70

71 23. Create an action using the following parameters: Name: expire_tmaa_cookie Type: INSERT_HTTP_HEADER Header Name: Set-Cookie String expression for header value: "NSC_TMAA=xyz;Path=/;expires=Thu, 19 Nov :52:00 GMT;Secure" Click Create. 71

72 24. Navigate to AppExpert > Rewrite > Policies. Click Add. Create a policy using the following parameters: Name: expire_tmaa_cookie Action: expire_tmaa_cookie Expression: HTTP.REQ.URL.PATH_AND_QUERY.CONTAINS("old_usr") Click Create. 72

73 25. Next, we will create 3 more actions and corresponding policies. The first one changes the 401 response status to a 302. Go back to the AppExpert > Rewrite > Actions node. Click Add and create an action with the following parameters: Name: res_302_status Type: REPLACE Expression to choose target text reference: HTTP.RES.STATUS String expression for replacement text: 302 Click Create. 73

74 26. The second action changes the status message from Unauthorized to Moved Temporarily as specified by RFC for a 302 response. Click Add and create another action with the following parameters: Name: res_302_status_msg Type: REPLACE Expression to choose target text reference: HTTP.RES.STATUS_MSG String expression for replacement text: Moved Temporarily Click Create. 74

75 27. Finally, we need to insert a Location header for the client browser to follow. Click Add and create an action with the following parameters: Name: res_302_location Type: INSERT_HTTP_HEADER Header Name: Location String expression for header value: HTTP.REQ.URL.PATH Bypass Safety Check: Checked Click Create. 75

76 28. Next we need to create the corresponding policies. Navigate to AppExpert > Rewrite > Policies. Click on Add and configure a policy with the following parameters: Name: res_302_status Action: res_302_status Expression: HTTP.REQ.URL.PATH_AND_QUERY.CONTAINS("old_usr") Click Create. 76

77 29. Click Add and configure the second policy using the following parameters: Name: res_302_status_msg Action: res_302_status_msg Expression: HTTP.REQ.URL.PATH_AND_QUERY.CONTAINS("old_usr") Click Create. 77

78 30. Click Add and configure the third and final policy using the following parameters: Name: res_302_location Action: res_302_location Expression: HTTP.REQ.URL.PATH_AND_QUERY.CONTAINS("old_usr") Click Create. 31. Navigate to Traffic Management > Load Balancing > Virtual Servers, select lb_vsrv_apache and click Edit. 78

79 32. Under Policies, click the + button. Select Rewrite from the Choose Policy drop-down list box and then select Response from the Choose Type drop-down list box. Then click Continue. Under Policy Binding, click Click to select. Select the radio button next to expire_tmaa_cookie and click OK. 33. Under Binding Details, select NEXT from the Goto Expression drop-down list box and click Bind. 79

80 34. Under Policies, click 1 Rewrite Policy. Click Add Binding to add another rewrite policy. Under Policy Binding, click Click to select. Select the radio button next to res_302_status and click OK. Under Binding Details, select NEXT from the Goto Expression drop-down list box and click Bind. 80

81 35. Click Add Binding to add another rewrite policy. Under Policy Binding, click Click to select. Select the radio button next to res_302_status_msg and click OK. Under Binding Details, select NEXT from the Goto Expression drop-down list box and click Bind. 81

82 36. Click Add Binding to add another rewrite policy. Under Policy Binding, click Click to select. Select the radio button next to res_302_location and click OK. Click Bind and then click Close. 37. It is time to test. Open a new Firefox tab. Navigate to the URL for the phpmyadmin application: You should be redirected to the dual factor login page. 38. Login with the following credentials: User name: user1 Password1: Citrix123 Password2: Citrix123 Your session is now authenticated, SSO occurs and you should be logged in the application. 39. Click the LiveHTTPHeaders button. Return to the main Firefox window and click the logout button. 82

83 40. You should see the dual factor login page. Return to the LiveHTTPHeaders and scroll all the way up. Observe the output of the first request and response. The response should be changed to a 302, the NSC_TMAA cookie should be expired, and the Location header set. 41. Return to the main Firefox window and login with again with user1 credentials: User name: user1 Password1: Citrix123 Password2: Citrix123 You should have been logged on to the application as user1 and a new AAA cookie is set. 42. Return to LiveHTTPHeaders and verify this is the case. Close Firefox and the LiveHTTPHeaders window. 43. Congratulations! You have secured your application. Save your configuration by clicking on the Save icon on the top right. Exercise Summary In this exercise, we explore the difference between a session and a traffic policy. Both of these elements can provide SSO services; however, traffic policies allow you to apply additional controls for traffic profiles when performing single sign-on services. In our next exercise, we continue expanding on the usage of traffic profiles when performing form-based authentication SSO. 83

84 Exercise 7: Server-side SSO using NTLM and Form-Based Authentication Overview In this exercise, we will explore the true single sign-on capabilities of the NetScaler appliance. We will configure for SSO to web applications using HTTP basic authentication and form based authentication. Since form based authentication is specific to the type of application front-ended by NetScaler, we will configure SSO to different web-applications to illustrate how to apply this knowledge to other production applications. Step by step guidance Estimated time to complete this exercise: 25 minutes. Step Action 1. In previous exercises, we configured simple SSO for Basic HTTP authentication using a session and traffic policies. This type of authentication is one of the simplest methods and it is rarely required by enterprise applications. In most environments, different authentication mechanisms are required such as NTLMv1, NTLMv2, and form-based authentication. To explore form-based SSO, we will start with our SugarCRM application. In order to automate this type of single sign-on mechanism, we need to understand how the authentication for application works, before we attempt any configuration. Open Firefox and navigate to The login form should be displayed. The following steps require some knowledge of HTML and HTTP. Skip this section (steps 2-10) if you are unfamiliar with these concepts. However, if you would like to configure Form-based SSO for your own web applications, it is best to start experimenting with these topics using a simple example such as this one. 2. Hit Ctrl + U to display the page source. 84

85 3. In the Source of window, hit Ctrl + F to locate the relevant User Name and Password input elements. Enter User Name in the Find in page box 4. The label User Name will be highlighted. Locate this line and the 5 consecutive lines of HTML code: 5. In order to fill out the necessary parameters in our form-based SSO profile, we need to find out what are the names of the fields representing the Username and Password. Most likely, application developers will name these input fields username / password; however, these values vary from application to application. Luckily, the SugarCRM web-dev team used familiar labels. Locate the name of the text field for each input element. In the HTML code, inspect the <input line for the username and password. They are named user_name and user_password. Record this information, we will need it later. Close the Source of window. 6. You should be back in the login form. Before clicking on any link or attempting to login, click on the LiveHTTPHeaders tool. 7. Return back to the main Firefox window and login using the following credentials: User Name: user2 Password: Citrix123 Click Log In. 85

86 8. Return to the LiveHTTPHeaders window. Scroll all the way up and inspect the first request. Two pieces of information are key in this step: The application submits the credentials in a POST along with many other parameters. The POST is sent to /sugarcrm/index.php We need to record this information. Select the line including the POST data and right-click, then Copy. 9. Open Notepad and paste this line of text. Leave it in the background as we will need this information later when defining our Form-based SSO profile. 86

87 10. Next, we need to inspect the application response to this POST. In LiveHTTPHeaders, scroll to the 302 response after the initial POST request. Notice the Location header value. This is indicating the client browser that the session was successfully authenticated and redirects to the main home page: Highlight the Location header. Right-click and then select Copy. We will need this information later. If you are curious, inspect what happens when a failed authentication attempt occurs. Since every application behaves differently, we have to inspect the success and failure use cases in order to determine the correct expressions for our Form SSO profile configuration. 11. Return to the NetScaler configuration utility. Navigate to Security > AAA Application Traffic > Policies > Traffic. Click on the Form SSO Profiles tab and then click on Add. 87

88 12. In the Create Form SSO Profile window, configure using the following parameters: Name: sugarcrm_sso Action URL: /sugarcrm/index.php User Name Field: user_name Password Field: user_password SSO Success Rule: HTTP.RES.HEADER("Location").CONTAINS("index.php?module=Home&action=index") Response Size: Extraction: DYNAMIC Submit Method: POST Click Create. 88

89 13. Click on the Traffic Profiles tab, and then click on the Add button. 14. Select the Profile tab. Create a Traffic Profile, with the following parameters: Name: sugarcrm_sso_prof Single Sign-on: ON Form SSO Profile: sugarcrm_sso Click Create. 15. Select the Traffic Policies tab and then click Add. 16. We need to define the conditions when the form-based SSO routine is executed. Create a Traffic policy using the following parameters: Name: sugarcrm_sso_pol Profile: sugarcrm_sso_prof Expression: HTTP.REQ.URL.PATH_AND_QUERY.EQ("/sugarcrm/index.php?action=Login&module=Users") Click Create. The expression was derived from our analysis of the authentication process for the SugarCRM application. Refer to steps Finally, we need to bind our policy in order to put it in action. Navigate to Traffic Management > Load Balancing > Virtual Servers. Highlight the lb_vsrv_apache2 virtual server and click Edit. 18. Under Policies, click the + button. Select Traffic from the Choose Policy drop-down list box and click Continue. 89

90 19. Under Policy Binding, click Click to select. Select the radio button next to sugarcrm_sso_pol and click OK. Click Bind and then click Done. 20. Close Firefox and the LiveHTTPHeaders tool. Reopen Firefox and navigate to the SugarCRM URL. You should be redirected to the single factor authentication login page. 21. Login with the following credentials: User name: user2 Password: Citrix123 Since this is the first time we access this application, the application takes about seconds to complete. This occurs because the database is being initialized during the first logon. 22. Single sign-on should be successful. Navigate the application and inspect that the currently logged on user is user Click the Log Out link right next to the username. Since this application uses a custom logout page, we would perform similar steps to trap the logout and invalidate the AAA session active on the NetScaler. I leave this as an optional task. Continue to the next step. HINT: Refer to the technique used in Exercise Next, we will explore NTLMv2 SSO. In Firefox, click on the LiveHTTPHeaders tool. Then open a new tab and navigate to the Sharepoint Site URL: You should get prompted for authentication. Login with the following credentials: Username: TRAINING\user1 Password: Citrix123 90

91 26. After the SharePoint site loads, return to the LiveHTTPHeaders window and scroll all the way up. Inspect the first request and response. You should see that the SharePoint site challenges the user for credentials and requests NTLM authentication. After inspecting the output, close Firefox and LiveHTTPHeaders, then continue to the next step. 27. We will configure a new server, service and virtual server object. Return to the NetScaler Configuration Utility and navigate to Traffic Management > Load Balancing > Servers and click Add. 91

92 28. Create a new Server object for SharePoint. Use the following parameters: Server Name: sharepoint IP Address:

93 29. Navigate to Traffic Management > Load Balancing > Services. Click Add. Create a new Service object with the following parameters: Service Name: svc_sharepoint Existing Server: Checked Server: sharepoint Protocol: HTTP Port: 80 Click OK. Then click Done. 30. Navigate to Traffic Management > Load Balancing > Virtual Servers and click Add. Create a new virtual server using the following parameters: Name: lb_vsrv_sharepoint Protocol: HTTP IP Address: Port: 80 Click OK. 31. Click No Load Balancing Virtual Server Service Binding. Under Service Binding, click Click to select. Check the box next to svc_sharepoint and click OK and then click Bind. Click OK and then click Done. 32. Open a new tab in Firefox. Navigate to the new virtual server FQDN. 93

94 33. You should get prompted for authentication. Login with the following credentials: Username: TRAINING\user1 Password: Citrix The SharePoint site should load properly. Close Firefox and return to the NetScaler Configuration utility. 35. In the Traffic Management > Load Balancing > Virtual Servers section, click on lb_vsrv_sharepoint, and then click Edit. 94

95 36. On the right side, under Advanced, click Authentication. For simplicity, we will configure single factor authentication for this new SharePoint virtual server. Configure the following parameters: Form Based Authentication: Checked Authentication FQDN: aaa-sf.training.lab Authentication vserver: aaa-sf-vs Click OK and then click Done. 37. Next, we will create a new session policy to enable NTLM SSO. Navigate to Security > AAA Application Traffic > Policies > Session. Click on the Session Profiles tab and then click on Add. 95

96 38. Create a Session profile with the following parameters: Name: SSO_NTLM_sharepoint Default Authorization: ALLOW Single Sign-on to Web Applications: Checked Credential Index: Primary HTTPOnly Cookie: YES Click Create. 39. Next, we need to create the Session Policy. Click on the Session Policies tab and then click Add. 40. Configure a new Session policy using the following parameters: Name: SSO_NTLM_sharepoint Request Profile: SSO_NTLM_sharepoint Expression: ns_true Click Create. 41. Now, it is time to bind our new session policy to the AAA virtual server we are using for authentication. Navigate to Security > AAA Application Traffic > Virtual Servers. Highlight the aaa-sf-vs virtual server and click Edit. 42. Under Advanced, on the right, click Policies. Then click the + button under Policies. 96

97 43. Select Session from the Choose Policy drop-down list box and click Continue. Under Policy Binding, click Click to select and select the radio button next to SSO_NTLM_Sharepoint and click OK. Click Bind and then click Done. 44. It is time to test our configuration. Open a new Firefox window. Browse to the Sharepoint virtual server: You should get redirected to the single factor login page. Login with the following credentials: Username: user1 Password: Citrix The session should be SSO ed into the SharePoint site. Verify this is the case by inspecting the currently logged on user on the top right corner. Close the Firefox window. Form-based SSO and NTLMv1/v2 are one of the most common authentication mechanisms for enterprise applications in Microsoft environments. In the next exercises, we will explore new client and server side authentication mechanisms and how to leverage the NetScaler to protect your applications and consolidate your authentication layer. 46. Congratulations! You have configured form-based and NTLM SSO successfully. Save your configuration by clicking on the Save icon on the top right. Continue to the next exercise. Exercise Summary Form-based and NTLM authentication are some of the most common authentication mechanisms used by web applications today. In this exercise, we learned how to analyze a web application in order to create the necessary traffic policy to perform single sign-on services. Next, we will explore more advanced authentication mechanisms supported by the NetScaler, not only on the client-side, but server side SSO. 97

98 Exercise 8: SAML Client-Side Authentication Overview At a glance SAML 2.0 is a set of open standards leveraging XML to transport authentication and authorization data between trusted endpoints. The most adopted use case is web single sign on or SSO. SAML 2.0 addresses the authentication challenges over the internet opposed to an intranet. Citrix NetScaler latest release 10.5 offers support for both SAML 2.0 endpoints. Service Provider (SP) & Identity Provider (IdP) In this exercise, we will walk through a how to setup Citrix NetScaler as both SP & IdP completing the SAML trust fabric. Step by step guidance Estimated time to complete this exercise: 20 minutes. Step Action 1. First, we are going to create the SAML Service Provider (SP) Profile on NetScaler NS_VPX_1. Navigate to Security > AAA Application Traffic > Policies > Authentication > Basic Policies > SAML. Select the Servers tab at the top and click Add. 98

99 2. Configure the SAML Server using the following parameters: Name: saml_sp IDP Certificate Name: wildcard.training.lab Redirect URL: Signing Certificate Name: wildcard.training.lab Issuer Name: aaa-saml.training.lab Leave all other fields with their default value. Click Create. 99

100 3. Next, we are going to create a SAML SP policy. Select the Policies tab and click Add. Type saml_sp in the Name field, then select saml_sp from the Server drop-down list box, and then type ns_true in the Expression field. Click Create. 4. Now we can create the AAA virtual server for the SAML service provider on NS_VPX_1. Navigate to Security > AAA Application Traffic > Virtual Servers and click Add. 100

101 5. Configure the AAA virtual server using the following parameters: Name: aaa-saml-sp IP Address: Click OK. 6. Under Certificates, click No Server Certificate. Under Server Certificate Binding, click Click to select and select the radio button next to wildcard.training.lab and click OK and then click Bind. Click Continue twice. 101

102 7. Under Basic Authentication Policies, click the + button to add a policy. Select LDAP from the Choose Policy drop-down list box and click Continue. Under Policy Binding, click Click to select and select the radio button next to LDAP_training and click OK. Click Bind. 102

103 8. Under Basic Authentication Policies, click the + button again to add another policy. Select SAML from the Choose Policy drop-down list box and then click Continue. Under Policy Binding, click Click to select and select the radio button next to saml_sp and click OK. Click Bind. Click Continue and then click Done. 9. Next, navigate to Traffic Management > Load Balancing > Virtual Servers and select lb_vsrv_apache and click Edit. 103

104 10. Click the pencil icon next to Authentication to edit the AAA settings of the virtual server. Then change the following settings: Authentication FQDN: aaa-saml-sp.training.lab Authentication Virtual Server: aaa-saml-sp Authentication Profile: Change to blank (no profile) Then click OK. Then click Done. 104

105 11. Now we are going to switch over to NS_VPX_2 and configure the SAML IdP side of the authentication. Open a new Google Chrome tab and click the NS_VPX_2 shortcut in the shortcut bar. Log on using the following credentials: User Name: nsroot Password: nsroot 12. First, we are going to create the SAML IdP Profile. Navigate to: Security > AAA Application Traffic > Policies > Authentication > Basic Policies > SAML IdP. Select the Profiles tab and click Add. 105

106 13. Configure the SAML IdP profile using the following parameters: Name: saml_idp SP Certificate Name: wildcard.training.lab IdP Certificate Name: wildcard.training.lab Issuer Name: aaa-saml.training.lab Audience: Click Create. 106

107 14. Next, we are going to create the SAML IdP Policy. Select the Policies tab and click Add. 107

108 15. Configure the SAML IdP plocy using the following parameters: Name: saml_idp Action: saml_idp Expression: HTTP.REQ.URL.CONTAINS( saml ) Click Create. 108

109 16. Now we are going to create the AAA virtual server for the SAML IdP. Navigate to Security > AAA Application Traffic > Virtual Servers and click Add. 17. Configure the AAA virtual server using the following parameters: Name: aaa-saml-idp IP Address: Click OK. 18. Under Certificates, click No Server Certificate. Under Server Certificate Binding, click Click to Select. Then select the radio button next to wildcard.training.lab and click OK. Click Bind and then click Continue twice. 19. Under Basic Authentication Policies, click the + button. Select LDAP from the Choose Policy drop-down list box and click Continue. Under Policy Binding, click Click to Select and select the radio button next to LDAP_training and click OK and then click Bind. 109

110 20. Under Basic Authentication Policies, click the + button again. Select SAMLIDP from the Choose Policy drop-down list box and click Continue. Under Policy Binding, click Click to Select and select the radio button next to saml-idp and click OK and then click Bind. Click Continue and then click Done. 21. Save your NetScaler configuration on both NetScalers. We are now ready for testing. Open a new browser window and browse to It should forward to the AAA virtual server. Log on using the following credentials: User name: user1 Password: Citrix If you see the colors homepage, than you have completed the configuration correctly. 110