Jump to content

  • Articles

    Show all categories
    Guest
    Continued from Part 1
    Configure the AD FS farm
    Now you can begin your AD FS post-deployment configuration from Server Manager. Click Configure the federation service on this server.

    On the Welcome page, select Create the first federation server in a federation server farm, and then click Next.

    On the Connect to Active Directory Domain Services page, ensure the Domain Administrator account is specified, and then click Next.

    On the Specify Service Properties page, complete the following steps, and then click Next:
    Choose the certificate which was installed on the server in the previous steps. The federation service name will automatically be populated based on the subject name of the certificate. Put the display name for the federation service. For example, CTXDEMOS STS.
    On the Specify Service Account page, select Create a Group Managed Service Account, and enter a unique name for this account. Group Managed Service Accounts are supported in Windows Server 2012 onwards and come with strict, complex passwords which are changed automatically every 30 days. Click Next.

    On the Specify Configuration Database page, select specify the location of a SQL Server database. Click Next.

    On the Review Options page, verify your configuration selections, and then click Next.

    On the Pre-requisite Checks page, verify that all prerequisite checks are successfully completed, and then click Configure.

    On the Results page, ensure that the installation is successful. Click Close to exit the wizard.
    OTE:
    To complete the following steps, you will need your Azure Tenant ID.
    You can get the Azure Tenant ID by following the steps in the Microsoft documentation article, Get AzureID Tenant Detail.
    Microsoft documentation also provides information about the Azure MFA Client GUID in Configure AD FS 2016 and Azure MFA.
    Configure AD FS farm - automated
    You can run the following PowerShell script:
    ## Windows PowerShell script for AD FS Deployment#Import-Module ADFSInstall-AdfsFarm `-CertificateThumbprint:"BD02F30D90A96EEE4A5934F2EA979E7A052584AE" `-FederationServiceDisplayName:"CTXDEMOS STS" `-FederationServiceName:"adfs.ctxdemos.com" `-GroupServiceAccountIdentifier:"C
    Configure AD FS with Azure MFA
    Configure AD FS servers
    On each of your AD FS servers, launch PowerShell and run the following commands:
     
    # Install Windows PowerShell MSOnline ModuleInstall-Module MSOnline# Import Windows PowerShell MSOnline ModuleImport-Module MSOnline# Get the Azure Global Administrator credential$credential = Get-Credential# Sign in to your Azure Active Directory environmentConnect-MsolService -Credential $credential# Set a variable for the Azure Tenant name$azureTenantID = "ctxdemos.onmicrosoft.com"# Set a variable for the Azure MFA Client GUID$azureMFAClientGUID = "981f26a1-7f43-403b-a875-f8b09b8cd720"# Generate a certificate for the Azure MFA on AD FS server$azureMFACertificate = New-AdfsAzureMfaTenantCertificate -TenantId $azureTenantID# Add the new credentials to the Azure MFA Client Service PrincipalNew-MsolServicePrincipalCredential -AppPrincipalId $azureMFAClientGUID -Type asymmetric -Usage verify -Value $azureMFACertificate
    Configure AD FS farm
    Only on one of the AD FS servers, run the following command:
    Set-AdfsAzureMfaTenant -TenantId $azureTenantID -ClientId $azureMFAClientGUID
    Restart the AD FS service on each of your servers. Then you will see that Azure MFA is available as the primary and multifactor authentication method for the intranet and extranet use.


    Configure AD FS with NetScaler ADC
    You need to create a federation trust between AD FS and NetScaler ADC. In the AD FS Management Console, navigate to Relying Party Trust and select Add Relying Party Trust.

    Select Enter data about the relying party manually and click Next.

    Enter a descriptive display name and optional notes. Click Next.

    Click Next.

    Select Enable support for the SAML 2.0 WebSSO protocol and enter https://NetScalerGatewayFQDN/cgi/samlauth. In the demo environment, it is https://access.ctxdemos.com/cgi/samlauth. Click Next.
     
     

    Enter a unique identifier string for the Relying Party Trust. In the demo environment, it is https://access.ctxdemos.com. This identifier will be used as an Issuer URL in the NetScaler ADC SAML profile. Click Next.

    On the Choose Access Control Policy page, select Permit everyone and require MFA. Click Next.

    Click Next.

    On the Finish page, select Configure claims issuance policy for this application. Click Close.

    On the Issuance Transform Rules page, click Add Rule.

    Click Next.

    Enter a descriptive name in the Claim rule name field. Under Attribute store, select Active Directory. Then select the following: LDAP Attributes and Outgoing Claim Types.

    Create a new rule and use Send Claims Using a Custom Rule as a Claim rule template. Enter a descriptive name for the Claim rule name and enter the following string for Custom rule:
     
     
    => issue(Type = "logoutURL", Value = "https://access.ctxdemos.com/cgi/tmlogout", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/attributename"] = "urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified");

    When the Claim Issuance Policies are created, click Ok.
    Right-click Relying Party Trust > NetScaler ADC, and select Properties. Select Endpoints and add an endpoint by clicking Add SAML for Logout. From the Endpoint type list, select SAML Logout. For Binding, select POST, and for Trusted URL, enter https://sts.ctxdemos.com/adfs/ls/?wa=wsignout1.0. This will act as a logout URL when logging out of NetScaler ADC. Click OK.

    Right-click Relying Party Trust > NetScaler ADC, and select Properties. Select Encryption and add a public SSL certificate that is installed on NetScaler Gateway. This certificate will be used to decrypt an incoming SML Request from NetScaler ADC. Repeat the same on the Signature tab. This certificate will be used to check the signature of an incoming SAML Request. Click OK.
    Enable IdP initiated sign-on page
    You can enable the AD FS IdP-initiated sign-on page. You will be using the IdP-initiated sign-on to present a custom error page to unregistered MFA users. To enable, run the following command:
    Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
    Test AD FS farm
    Open a web browser and navigate to:
    https://sts.ctxdemos.com/FederationMetadata/2007-06/FederationMetadata.xml https://sts.ctxdemos.com/adfs/fs/federationserverservice.asmx https://sts.ctxdemos.com/adfs/ls/idpinitatedsignon.aspx NetScaler ADC and NetScaler Gateway
    Configure NetScaler Gateway
    You can configure NetScaler Gateway through the wizard. Log on to NetScaler ADC Management GUI, navigate to Unified Gateway, and click Create New Gateway. Then click Continue.

    Enter the name, IP, and FQDN for Unified Gateway and click Continue.

    Select the public SSL certificate and click Continue.

    Create a basic LDAP policy and bind it to Unified Gateway. Click Continue.

    Create a portal theme based on RfWebUI and bind it to Unified Gateway. Click Continue.

    Select the plus sign (+) in front of the applications to integrate NetScaler Gateway with StoreFront.

    Integrate Citrix StoreFront into NetScaler Gateway
    On the Application page, select XenApp & XenDesktop, and from the Choose Integration Point list, select StoreFront. Click Continue.

    Enter a StoreFront URL and click Retrieve Stores. Then enter the Default Active Directory Domain and Secure Ticket Authority URL settings. Click Test STA Connectivity and then click Continue.

    Click Done and then click Continue.

    Continued in Part 3
    Guest
    NetScaler Gateway
    Author: Saman Salehian, Partner Sales Engineer

    Federation and single sign-on
    NetScaler Gateway provides federated identity and supports SAML 2.0, OAuth, and OpenID to achieve single sign-on across all applications, whether web, VDI, enterprise, or SaaS applications.
    User directory on-premises
    NetScaler Gateway provides SSO to SaaS applications such as Office 365 and Salesforce, and it keeps the user directory on-premises. It can be implemented as an IdP or proxy for Microsoft Active Directory Federation Services (AD FS).
     Multi-factor (nFactor) authentication
    NetScaler Gateway provides nFactor authentication mechanisms and allows granular control over who is accessing the network, what is being accessed, and how and when it is accessed. It supports all the authentication mechanisms, such as RADIUS, TACACS, NTLM, Diameter, SAML 2.0, OAuth 2.0, and OpenID 2.0.
     Contextual access control policies
    NetScaler Gateway allows granular access control to business applications based on the state of the end-user device, user, user location, and other data. An IT administrator can create, manage, and enforce the policies to access data securely in an application environment. These policies can be implemented for VDI, web, mobile, enterprise, and SaaS applications.
     Visibility and Monitoring
    NetScaler Application Delivery Management includes Gateway Insight, which provides visibility of the end-to-end user experience for all applications accessed through NetScaler Gateway. It provides information for application support teams to troubleshoot issues regarding authentication failures, including EPA check failures and single sign-on failures.

    People are connecting to organizational resources in increasingly complicated scenarios. People connect from organization-owned, personal, and public devices on and off the corporate network using smartphones, tablets, PCs, and laptops, often on multiple platforms. In this always-connected, multi-device, and multi-platform world, the security of user accounts is more important than ever. Passwords, no matter their complexity, used across devices, networks, and platforms are no longer sufficient to ensure the security of the user account, especially when users tend to reuse passwords across accounts. Sophisticated phishing and other social engineering attacks can result in user names and passwords being posted and sold across the dark web.The security of the two-step verification process lies in its layered approach. Compromising multiple authentication factors presents a significant challenge for attackers. Even if an attacker manages to learn the user’s password, it is useless without also having possession of the additional authentication method. It works by requiring two or more of the following authentication methods:
    Something you know (typically a password) Something you have (a trusted device that is not easily duplicated, like a phone) Something you are (biometrics) Azure Multi-Factor Authentication helps safeguard access to data and applications. It provides an extra layer of security using a second form of authentication. Organizations can use conditional access to make the solution fit their specific needs.
    Microsoft Azure MFA deployment methods
    There are different methods to leverage Azure MFA as a second factor of authentication. Such methods are briefly explained below with their pros and cons.
    Azure MFA server
    Microsoft Azure Multi-Factor Authentication server was the original method and it is going to be deprecated. It should not be considered for any new implementation as
    There is no further investment from Microsoft going forward on this method. There is no integration with SSPR and Azure MFA Cloud-based. There is no seamless migration tool from MFA Server to MFA Cloud-based solution. Azure MFA Network Policy Server extension
    Network Policy Server (NPS) extension for Azure MFA is a supported solution that uses NPS Adapter to connect with Azure MFA Cloud-based. It can be used as the on-premises RADIUS server.
    NPS Adapter (RADIUS) will provide a network location inside/outside MFA Rule or On/Off. It is not compatible with Azure AD Conditional Access Policies similar to SAML integration method. Conditional Access policies have much richer and better user experiences. Users must be registered in MFA prior to using NPS Adapter. Unlike Azure MFA Cloud-based and Conditional Access, if the user is not registered, then NPS Extension fails to authenticate the user, which generates more calls to the help desk. When NPS Adapter invokes MFA, it hits the user's registered default option. There is no visual notification to the user that MFA is required and coming. There is no UI for the user to change MFA methods during a gated process. If the user doesn’t have their default device with them, it will fail. The user must go back to the self-service portal and reset the default option, and then try to connect again. Microsoft AD FS and Azure MFA
    If your organization is federated with Azure AD, but Passwords Hash are not synchronized with Azure AD, then you can use on-premises AD for Lightweight
    Directory Access Protocol (LDAP) and enable Azure MFA as part of Access Policies on AD FS relay parties. Starting with Windows Server 2016, you can now configure Azure MFA for primary authentication.
    Azure MFA adapter is built into Windows Server 2016, and there is no need for an additional installation. Azure MFA adapter integrates directly with Azure AD and does not require an on-premises Azure MFA server. If users are not registered for MFA, they are guided through the process on their next sign-in. It ensures fewer calls to the help desk and a better process for users. Users get a visual notification that MFA is required and coming. Users can change the gateway option during a gated process in the UI. Azure AD and Azure MFA
    If your organization is synchronizing Passwords Hash into Azure AD, Azure MFA can be leveraged via Conditional Access policies to challenge users for second-factor authentication.
    This method does not require any additional installations on-premises. If users are not registered for MFA, they are guided through the process on the next sign-in. It ensures fewer calls to the help desk and a better process for users. Users get a visual notification that MFA is required and coming. Users can change the gateway option during a gated process in the UI. Azure AD pass-through authentication and Azure MFA
    Azure AD pass-through authentication (PTA) permits users to sign in to both on-premises and cloud-based applications using the same passwords. When users sign in using Azure AD, this feature validates users’ passwords directly against on-premises Active Directory. Azure AD PTA is an alternative to Azure AD Password Hash Synchronization, which provides the same benefit of cloud authentication to organizations.
    Azure AD PTA requires a lightweight agent to be installed on-premises. Azure AD PTA protects the user accounts by working seamlessly with the Azure AD Conditional Access policies, including Azure MFA. Users can complete self-service password management tasks in the cloud. On-premises passwords are never stored in the cloud in any form. The agent only makes outbound connections from within your network. Therefore, there is no requirement to install the agent in a perimeter network, also known as a DMZ. Current situation
    An environment with the following characteristics requires leveraging Azure MFA as a second factor of authentication:
    On-premises AD with Azure AD Synchronization is configured. Azure AD Password Hash Synchronization is disabled. Access to O365 applications is required. Access to Citrix Virtual Apps and Desktops on-premises is required. Access to applications with modern authentication methods (SAML, OAuth) is required. Access to applications with legacy authentication methods is required. Design points
    Here are the design points for the proposed solution:
    Access hosted, SaaS, enterprise, and web applications in a single portal, and security is required. Users must only be required to enter their credentials once during the authentication process. Single sign-on must be provided for all hosted, SaaS, enterprise, and web applications. Proposed solution
    Overview
    The proposed solution is based on the following components:
    On-premises NetScaler Gateway On-premises Microsoft AD On-premises Microsoft AD FS On-premises NetScaler ADC as AD FS Proxy Microsoft Azure MFA NetScaler Gateway is leveraging authentication, authorization, and auditing feature (NetScaler ADC AAA) and nFactor authentication mechanisms to authenticate the user with LDAP policy and leverage Access Policy on AD FS Relay Party to trigger Azure MFA validation process. After Azure MFA validates the user, AD FS generates SAML Assertion (SAML response) and redirects the user back to NetScaler Gateway. At that point, the user is authenticated and NetScaler Gateway presents all applications that the user is authorized to use.
     
    The solution requires two public DNS records and two public IP addresses:
     
    Description
    Value
    NetScaler Gateway FQDN
    access.ctxdemos.com
    NetScaler authentication, authorization, and auditing FQDN
    aaa.ctxdemos.com
     The solution uses one public SSL certificate:
    Description
    Value
    Common Name
    access.ctxdemos.com
    Subject Alternative Name
    sts.ctxdemos.com
    Subject Alternative Name
    aaa.ctxdemos.com
    The solution also uses a wildcard SSL certificate issued by internal Microsoft Certificate Authority Services:
    Description
    Value
    Common Name
    *.ctxdemos.com
    Authentication flow
    Sequence diagram
    The following sequence diagram shows the authentication flow for the solution:

    Authentication steps
    The authentication steps are:
    User navigates to https://access.ctxdemos.com. NetScaler Gateway redirects the user to the first NetScaler ADC AAA VIP (Non-Addressable). First NetScaler ADC AAA VIP uses a no-schema logon, which is configured with a single sign-on. Then it starts processing the advanced authentication policies. The first authentication policy is SAML SP to a non-addressable LB VIP to generate authentication cookies. The helper LB VIP is configured to use the second NetScaler ADC AAA VIP (Addressable) for authentication. So, it redirects the user to the second authentication, authorization, and auditing VIP. Second NetScaler ADC AAA VIP uses the Username Only logon schema, which prompts the user for the user name. Then it starts processing the advanced authentication policies. The first authentication policy is a Group Extraction, which queries the user name in an on-premises AD and validates if the user belongs to the AzureMFACAUsers security group. Once the result of validation is successful, it starts to process the next authentication factor which is the LDAP policy. The LDAP policy uses the UsernameAndPassword login schema and a pre-filled user name field and prompts the user for the AD password. When authentication on the second NetScaler ADC AAA VIP is completed successfully, it goes back to helper LB VIP which generates a SAML response for the first authentication, authorization, and auditing VIP. The first NetScaler ADC AAA VIP starts processing the next factor, which is a Group Extraction to ensure the user’s groups are extracted from AD and stored in the authentication, authorization, and auditing variable to be used later in the process. First NetScaler ADC AAA VIP starts processing the next factor, which is a SAML SP to AD FA Proxy VIP on NetScaler ADC. NetScaler ADC is federated with the AD FS farm. The detailed steps are explained in later sections. AD FS Proxy VIP validates that the authentication cookies (NSC_TMAA and NSC_TMAS) are set. Then it sends the SAML Request to a back end AD FS server (the back-end AD FS servers should be load balanced on internal NetScaler ADC for high availability and resiliency of service). AD FS server processes the SAML request. Because the Access policy on the Relaying Party is set to “Permit all users and require MFA for authentication,” it triggers the Azure MFA authentication process. Azure MFA processes the user name. If it is already registered, it challenges the user with the configured method. If not, it prompts the user to register and set the primary and secondary authentication methods. Once the Azure MFA authentication process is completed successfully, AD FS generates a SAML response for NetScaler Gateway (First NetScaler ADC AAA VIP). First NetScaler ADC AAA VIP receives a SAML response and confirms that the authentication process for the user is completed. NetScaler Gateway sends authentication information to Citrix StoreFront, which enumerates all applications and desktops that the user is authorized to use. Also, it processes the user’s group membership to present published bookmarks on NetScaler Gateway. Authentication screens
    Most of the steps mentioned above are seamless to users as they are occurring internally between various VIPs on the NetScaler ADC. The user experience is shown below:



    ​​​​​Implementation
    Microsoft AD FS
    Certificate requirements
    Federation servers require the certificates in the following table:
     
    Implementation
    Microsoft AD FS
    Certificate requirements
    Federation servers require the certificates in the following table:
     
    Certificate Type
    Description
    What needs to be known before deploying
    Secure Sockets Layer (SSL) certificate
    This is a standard Secure Sockets Layer (SSL) certificate that is used for securing communications between federation servers and clients.
    This certificate must be bound to the default website in the Internet Information Services (IIS) for a Federation Server or a Federation Server Proxy. For a Federation Server Proxy, the binding must be configured in IIS prior to running the Federation Server Proxy Configuration Wizard successfully. Recommendation: Because this certificate must be trusted by clients of AD FS, use a server authentication certificate that is issued by a public (third-party) certification authority (CA). For example, Verisign. Tip: The Subject name of this certificate is used to represent the Federation Service name for each instance of AD FS that you deploy. For this reason, you may want to consider choosing a Subject name on any new CA-issued certificates that best represents the name of your company or organization to partners.
    Service communication certificate
    This certificate enables WCF message security for securing communications between federation servers.
    By default, the SSL certificate is used as the service communications certificate. This can be changed using the AD FS Management console.
    Token-signing certificate
    This is a standard X509 certificate that is used for securely signing all tokens that the federation server issues.
    The token-signing certificate must contain a private key, and it should chain to a trusted root in the Federation Service. By default, AD FS creates a self-signed certificate. However, you can change this later to a CA-issued certificate by using the AD FS Management snap-in, depending on the needs of your organization.
    Token-decryption certificate
    This is a standard SSL certificate that is used to decrypt any incoming tokens that are encrypted by a partner federation server. It is also published in the federation metadata.
    By default, AD FS creates a self-signed certificate. However, you can change this later to a CA-issued certificate by using the AD FS Management snap-in, depending on the needs of your organization.
     Demo Environment Configuration
    Certificate type
    Demo Environment Configuration
    Secure Sockets Layer (SSL) certificate
    Internal certificate issued by internal issuing CA on AD FS server. Public trusted certificate on NetScaler ADC.
    Service communication certificate
    Internal certificate issued by AHS internal issuing certificate authority.
    Token-signing certificate
    Auto generated by AD FS service.
    Token-decryption certificate
    Auto generated by AD FS service.
    In the demo environment, a wildcard certificate is enrolled and installed on the server.
    Service account requirements
    You can either create a service account or leverage Group Managed Service Accounts (gMSA). To use gMSA, you need to create a Key Distribution Service Root Key. So, launch PowerShell and run the following command:
     
    Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))
    This command creates a Key Distribution Service Root Key, stored in Active Directory, and it allows you to create a group Managed Service Account (gMSA) as the AD FS service account you create later. Run this command with Domain Admin rights.

    DNS record requirements
    You need DNS A record for your AD FS Federation Service Name internally and externally. In the demo environment, Internal DNS record is pointing to the AD FS server IP and External DNS record is pointing to the NetScaler Gateway public IP.
    Record name
    Scope
    Type
    IP address
    sts.ctxdemox.com
    Internal
    A
    22.22.22.6
    sts.ctxdemox.com
    External
    A
    40.85.225.175
    Add the AD FS role and configure the AD FS farm
    Add the AD FS role
    To add the AD FS role to Windows Server 2016 launch PowerShell and run the following command:
     Install-WindowsFeature AD FS-Federation -IncludeManagementTools
    Continued in Part 2
     
    Magnus Esse
    Tech Brief: Policy Label


    Overview


    The aim of this article is to look at the concept of policy labels and give a few examples of how they might be useful.


    If you have ever used nFactor authentication, most likely you have been exposed to policy labels. However, they can be used in more places. Some examples are together with responder, rewrite and content switch policies. 


    What are policy labels?


    A policy label can be seen as a container where one or more policies are bound. The policy label is invoked when a policy expression is evaluated as true.





    Why use policy labels?


    Having the policies with the most hits as early as possible in the evaluation chain is always important. 


    When you have many policies that require evaluation, it might become hard to understand the flow and see the result. It might even be risky to add additional policies if required, as you might add them incorrectly.


    There is also a tiny bit of latency added when evaluating policy expressions, if you just have a few policies to evaluate it doesn't matter that much, but when you have a lot of policy expressions, it might start to matter. When you start grouping policies, which belong together in policy labels, you might skip the evaluation of a lot of policies. If the rules are made properly, this will lower the overall resources used for policy evaluation.


    Another good reason to use policy labels is if you have several policies that should be bound to several services. This will limit the number of bindings you are required to make, and it will also be easier to update all services when required as you will only need to update the bindings within the policy label and this will affect all places where it is used.


    Examples


    Example 1:


    In this example, policy labels are used together with rewrite policies to create a simple method of scrubbing HTTP response headers from unwanted information. There are many HTTP headers that the server might set that are leaking a lot of information about how the server is set up. Some HTTP headers are optional and not required by the client for the applications to work properly and can be removed from the response sent.


    If you use a browser and use the developer tools for the browser, you can inspect which HTTP headers are being received by a client. I have picked a few header examples that normally, a client should not be able to see. Example headers to be scrubbed:


    Server X-Powered-By X-Aspnet-Version X-Aspnetmvc-Version
      First, create the rewrite actions that will do the HTTP header scrubbing:

    add rewrite action scrubb-Server-rwact delete_http_header Server add rewrite action scrubb-X-Powered-By-rwact delete_http_header X-Powered-By add rewrite action scrubb-X-Aspnet-Version-rwact delete_http_header X-Aspnet-Version add rewrite action scrubb-X-Aspnetmvc-Version-rwact delete_http_header X-Aspnetmvc-Version


    Next create the rewrite policies that will do the HTTP header scrubbing:


    add rewrite policy scrubb-Server-rwpol "HTTP.RES.HEADER(\"Server\").EXISTS" scrubb-Server-rwact add rewrite policy scrubb-X-Aspnet-Version-rwpol "HTTP.RES.HEADER(\"X-Aspnet-Version\").EXISTS" scrubb-X-Aspnet-Version-rwact add rewrite policy scrubb-X-Aspnetmvc-Version-rwpol "HTTP.RES.HEADER(\"X-Aspnetmvc-Version\").EXISTS" scrubb-X-Aspnetmvc-Version-rwact add rewrite policy scrubb-X-Powered-By-rwpol "HTTP.RES.HEADER(\"X-Powered-By\").EXISTS" scrubb-X-Powered-By-rwact


    Now create the rewrite policy that will select which traffic should pass the policy label:


    add rewrite policy scrubb-HTTP-headers-rwpol true NOREWRITE


    Create the policy label, in this example we want the “Transform Name” to be http_res:


    add rewrite policylabel scrubb-HTTP-headers-label http_res


    Bind the scrubbing policies to the policy label:


    bind rewrite policylabel scrubb-HTTP-headers-label scrubb-Server-rwpol 100 NEXT bind rewrite policylabel scrubb-HTTP-headers-label scrubb-X-Powered-By-rwpol 110 NEXT bind rewrite policylabel scrubb-HTTP-headers-label scrubb-X-Aspnet-Version-rwpol 120 NEXT bind rewrite policylabel scrubb-HTTP-headers-label scrubb-X-Aspnetmvc-Version-rwpol 130 NEXT


    Lets create a content switch where the policy label can be bound:


    add cs vserver scrubb-HTTP-headers-csvs HTTP 10.1.1.1 80 -cltTimeout 180 -persistenceType NONE


    Lastly, lets bind the selection policy and use it to invoke the policy label:


    bind cs vserver scrubb-HTTP-headers-csvs -policyName scrubb-HTTP-headers-rwpol -priority 100 -gotoPriorityExpression NEXT -type RESPONSE -invoke policylabel scrubb-HTTP-headers-label


    To reuse the same policy label for several http services you simply add the last policy bind with the invocation for each of the virtual servers where it is required.


    If you later need to modify which HTTP headers are being scrubbed, you just modify the policy label, and it will be applied to all your HTTP services simultaneously.


    Example 2:


    In this example, policy labels will be used to group content switch policies instead of binding all policies directly on the content switch. 


    In this example, two applications are consolidated under the same content switch virtual server. 


    The plex application requires traffic to some URLs to be directed to a specific load-balanced virtual server, which will handle the traffic that requires authentication, and all other traffic to be sent to the normal load-balanced virtual server.


    The web application is a web hosting service that will only allow traffic destined for specific sites to be forwarded. They are all hosted on the same load-balanced virtual server.


    First we create the Content Switch virtual server:


    add cs vserver webservices-csvs HTTP 10.1.1.100 80 -cltTimeout 180 -persistenceType NONE


    Creation of the content switch actions and policies for the plex application:


    add cs action plex-csact -targetLBVserver plex-lbvs add cs action plexauth-csact -targetLBVserver plexauth-lbvs add cs policy plex-csvs -rule "HTTP.REQ.HOSTNAME.SERVER.EQ(\"plex.example.local\")" add cs policy plex-all-csvs -rule HTTP.REQ.IS_VALID -action plex-csact add cs policy plex-admin-csvs -rule "HTTP.REQ.URL.STARTSWITH(\"/admin/\")" -action plexauth-csact add cs policy plex-upload-csvs -rule "HTTP.REQ.URL.STARTSWITH(\"/upload/\")" -action plexauth-csact


    Create and bind policies to the plex policy label:


    add cs policylabel plex-plabel HTTP bind cs policylabel plex-plabel plex-upload-csvs 100 bind cs policylabel plex-plabel plex-admin-csvs 110 bind cs policylabel plex-plabel plex-all-csvs 120


    Creation of the content switch actions and policies for the web application:


    add cs action web-csact -targetLBVserver web-lbvs add cs policy web-cspol -rule "HTTP.REQ.HOSTNAME.SERVER.EQ(\"web.example.local\")" add cs policy web-site1-cspol -rule "HTTP.REQ.URL.STARTSWITH(\"/site1/\")" -action web-csact add cs policy web-site2-cspol -rule "HTTP.REQ.URL.STARTSWITH(\"/site2/\")" -action web-csact add cs policy web-site3-cspol -rule "HTTP.REQ.URL.STARTSWITH(\"/site3/\")" -action web-csact


    Create and bind policies to the web policy label:


    add cs policylabel web-plabel HTTP bind cs policylabel web-plabel web-site1-cspol 100 bind cs policylabel web-plabel web-site2-cspol 110 bind cs policylabel web-plabel web-site3-cspol 120


    Bind policies and invoke the policy labels on the content switch virtual server:


    bind cs vserver webservices-csvs -policyName plex-csvs -priority 100 -gotoPriorityExpression USE_INVOCATION_RESULT -invoke policylabel plex-plabel bind cs vserver webservices-csvs -policyName web-cspol -priority 110 -gotoPriorityExpression USE_INVOCATION_RESULT -invoke policylabel web-plabel


    Note that this is a simple example to show how policy labels can be used, it could be written in different ways without the usage of so many policies.
    Guest
    NetScaler ADC SSL Profiles Validated Reference Design
    September 12, 2022
    Author:  Luis Ugarte, Beth Pollack
    Overview
    NetScaler ADC summary
    NetScaler ADC is an all-in-one application delivery controller that makes applications run up to five times better, reduces application ownership costs, optimizes the user experience, and ensures that applications are always available by using:
    Advanced L4-7 load balancing and traffic management Proven application acceleration such as HTTP compression and caching An integrated application firewall for application security Server offloading to significantly reduce costs and consolidate servers As an undisputed leader of service and application delivery, NetScaler ADC is deployed in thousands of networks around the world to optimize, secure, and control the delivery of all enterprise and cloud services. Deployed directly in front of web and database servers, NetScaler ADC combines high-speed load balancing and content switching, http compression, content caching, SSL acceleration, application flow visibility, and a powerful application firewall into an integrated, easy-to-use platform. Meeting SLAs is greatly simplified with end-to-end monitoring that transforms network data into actionable business intelligence. NetScaler ADC allows policies to be defined and managed using a simple declarative policy engine with no programming expertise required.
    Overview NetScaler ADC SSL profiles
    You can use an SSL profile to specify how a NetScaler ADC processes SSL traffic. The profile is a collection of SSL parameter settings for SSL entities, such as virtual servers, services, and service groups, and offers ease of configuration and flexibility. You are not limited to configuring only one set of global parameters. You can create multiple sets (profiles) of global parameters and assign different sets to different SSL entities. SSL profiles are classified into two categories:
    Front-end profiles, containing parameters applicable to the front-end entity. That is, they apply to the entity that receives requests from a client. Back-end profiles, containing parameters applicable to the back-end entity. That is, they apply to the entity that sends client requests to a server. Unlike a TCP or HTTP profile, an SSL profile is optional. Once SSL Profiles (a global parameter) is enabled, all SSL endpoints inherit default profiles. The same profile can be reused across multiples entities. If an entity does not have a profile attached, the values set at the global level apply. For dynamically learned services, current global values apply.
    Compared to the alternate way that requires configuration of SSL parameters, ciphers, and ECC curves on individual SSL endpoints, SSL Profiles on NetScaler ADC simplify configuration management by acting as a single point of SSL configuration for all related endpoints. Furthermore, configuration problems such as cipher reordering and downtime when ciphers are reordered are solved with the use of SSL Profiles.
    SSL Profiles help in setting required SSL parameters and cipher bindings on those SSL endpoints on which traditionally one could not set these parameters and bindings. SSL Profiles can be set on secure monitors as well.
    The following table lists the parameters that are part of each profile:
    Front End Profile
    Backend Profile
    cipherRedirect, cipherURL
    denySSLReneg
    clearTextPort*
    encryptTriggerPktCount
    clientAuth, clientCert
    nonFipsCiphers
    denySSLReneg
    pushEncTrigger
    dh, dhFile, dhCount
    pushEncTriggerTimeout
    dropReqWithNoHostHeader
    pushFlag
    encryptTriggerPktCount
    quantumSize
    eRSA, eRSACount
    serverAuth
    insertionEncoding
    commonName
    nonFipsCiphers
    sessReuse, sessTimeout
    pushEncTrigger
    SNIEnable
    pushEncTriggerTimeout
    ssl3
    pushFlag
    sslTriggerTimeout
    quantumSize
    strictCAChecks
    redirectPortRewrite
    TLS 1.0, TLS 1.1, TLS 1.2
    sendCloseNotify
     
    sessReuse, sessTimeout
     
    SNIEnable
     
    ssl3
     
    sslRedirect
     
    sslTriggerTimeout
     
    strictCAChecks
     
    tls1, tls11, tls12,tls13
     
    *The clearTextPort parameter applies only to an SSL virtual server.
    An error message appears if you try to set a parameter that is not part of the profile (for example, if you try to set the clientAuth parameter in a backend profile).
    Some SSL parameters, such as CRL memory size, OCSP cache size, UndefAction Control, and UndefAction Data, are not part of any of the above profiles, because these parameters are independent of entities. These parameters are present in Traffic Management > SSL > Advanced SSL Settings.
    An SSL profile supports the following operations:
    Add—Creates an SSL profile on the NetScaler ADC. Specify whether the profile is front end or back end. Front end is the default.  
    Set—Modifies the settings of an existing profile.  
    Unset—Sets the specified parameters to their default values. If you do not specify any parameters, an error message appears. If you unset a profile on an entity, the profile is unbound from the entity.  
    Remove—Deletes a profile. A profile that is being used by any entity cannot be deleted. Clearing the configuration deletes all the entities. As a result, the profiles are also deleted.  
    Bind—Binds a profile to a Vserver.  
    Unbind—Unbinds a profile from a Vserver.  
    Show—Displays all the profiles that are available on the NetScaler ADC. If a profile name is specified, the details of that profile are displayed. If an entity is specified, the profiles associated with that entity are displayed.  
     
    SSL profiles use cases
    SSL default profiles
    NetScaler ADC appliances come with two in-built default profiles –
    ns_default_ssl_profile_frontend – default front-end profile for all SSL type virtual servers and Internal services.  
    ns_default_ssl_profile_backend – default back-end profile for SSL type services, service groups, and secure monitors.  
    Any new endpoint created gets corresponding default SSL profile bound.
    It is possible to change the SSL parameters and ciphers of default SSL profiles. This ensures that customers can change the settings and bindings at one point which gets referenced by corresponding endpoints.
    Important:
    Save your configuration before you upgrade the software and enable the default profiles.
    Upgrade the software to a build that supports the enhanced profile infrastructure, and then enable the default profiles. You can take one of two approaches depending on your specific deployment. If your deployment has a common SSL configuration across end points, see Use Case 1. If your deployment has a large SSL configuration and the SSL parameters and ciphers are not common among end points, see Use Case 2.
    After upgrading the software, if you enable the profile, you cannot reverse the changes. That is, the profile cannot be disabled. Therefore, the only way to reverse the change is to reboot using the old configuration.
    Note: A single operation (Enable Default Profile or set ssl parameter -defaultProfile ENABLED) enables (binds) both the default front-end profile and the default back-end profile.
    Note: Default SSL profiles are now available for clustering starting from v11.1
    To save the configuration by using the NetScaler ADC command line, at the command prompt, type:
    save configshellcd /nsconfigcp ns.conf ns.conf.NS<currentreleasenumber><currentbuildnumber> 
    Use case 1
    After you enable the default profiles, they are bound to all the SSL end points. The default profiles are editable. If your deployment uses most of the default settings and changes only a few parameters, you can edit the default profiles. The changes are immediately reflected across all the end points.
    The following flowchart explains the steps that you must perform:

    For information about upgrading the software, see Upgrading the System Software.  
    Enable the default profiles by using the NetScaler ADC command line or GUI. At the command line, type: set ssl parameter -defaultProfile ENABLED If you prefer to use the GUI, navigate to Traffic Management > SSL > Change advanced SSL settings, scroll down, and select Enable Default Profile. (Optional) Manually change any settings in the default profile. At the command line, type: set ssl profile <name> followed by the parameters to modify. If you prefer to use the GUI, navigate to System > Profiles. In SSL Profiles, select a profile and click Edit. Use case 2
    If your deployment uses specific settings for most of the SSL entities, you can run a script that automatically creates custom profiles for each end point and binds them to the end point. Use the procedure detailed in this section to retain the SSL settings for all the SSL end points in your deployment. After upgrading the software, download and run a migration script to capture the SSL-specific changes. The output of running this script is a batch file. Enable the default profiles and then apply the commands in the batch file. See the appendix for a sample migration of the SSL configuration after upgrade.
    The following flowchart explains the steps that you must perform:

    For information about upgrading the software, see Upgrading the System Software. Download and run a script to capture the SSL-specific changes. In addition to other migration activities, the script analyzes the old ns.conf file and moves any special settings (other than the default) from an SSL end point configuration to a custom profile. You must enable the default profiles after the upgrade for the configuration changes to apply. The script can be downloaded from the NetScaler GitHub Repository. https://github.com/netscaler/defaul-ssl-profile-script.  
     
    Note:
     
    The script requires Python3 to be installed on the device running the script. When running the migration script, you can choose to automatically generate the profile names, or you can prompt the user for the profile names interactively. The migration script, checks the following and creates pro-files accordingly.
     
    End points with the default settings and similar ciphers and cipher group settings: The script creates one profile. End points with the default settings and with different cipher groups or different priorities for the Ciphers/cipher groups: In each case, the script creates a user-defined cipher group, binds it to a profile, and binds each profile to the appropriate end points. End points with the default settings and default ciphers: A default profile is bound to the end point. To run the script, at the command prompt, type:
     
    ./SSLconfigConverter_linux /nsconfig/ns.conf -b <output file name>

    You must run this command from the folder in which you store the script.
     
    Enable the default profiles by using the NetScaler ADC command line or GUI.  
    At the command line, type: set ssl parameter -defaultProfile ENABLED If you prefer to use the GUI, navigate to Traffic Management > SSL > Change advanced SSL settings, scroll down, and select Enable Default Profile.  
    Custom SSL profiles
    Besides the default SSL profiles, customers can create custom front-end and back-end SSL profiles for specific use cases. There can be scenarios where different applications need different ciphers and SSL parameters. In those cases, customers can create new profiles and bind them to endpoints.
    There is no upper limit on the number of custom profiles which can be created in a system.
    Visit SSL Profiles documentation for information on how to enable SSL profiles and more.
     
    SSL front-end profiles
    Front-end SSL profiles are related to SSL type virtual servers and Internal services. Front-end profiles are applicable to all the SSL type virtual servers in Load Balancing virtual server, Content Switching virtual server, AAA-TM virtual server, and Gateway VPN virtual server categories.
    Following type of virtual servers support front-end profiles – SSL, SSL_TCP, SIP_SSL, SSL_FIX and SSL_DIAMETER.
    All internal services support front-end profiles.
     
    SSL back-end profiles
    Back-end profiles are related to SSL type services, service groups, and secure monitors. Services and service groups of following type support Back-end profiles – SSL, SSL_TCP, SIP_SSL, SSL_FIX, SSL_DIAMETER.
    Some monitors can be configured to check the health of backend servers over secure connections. SSL profiles can be bound to such monitors to configure the SSL parameters and ciphers. Such monitors are – HTTP, HTTP-ECV, HTTP-INLINE, TCP, and TCP-ECV.
     
    Subhojit Goswami
    Author: Shruti Vijay Dhamale
     A lot of organization’s implement restrictions on the internet access-based security policies configured to check the destination IP addresses or domain names. As the organizations are moving to cloud services like Microsoft 365, These traditional access lists are failing as the services are hosted in public cloud and utilize shared domain names such as outlook.office.com and login.microsoftonline.com. So, users can use their personal resources using same domain names. To restrict the user access, blocking these addresses would keep users from accessing Outlook on the web entirely, instead of merely restricting them to approved identities and resources. 

    To address this issue, Microsoft introduced an HTTP custom headers based feature called tenant restrictions to help administrators control access to Microsoft tenant.  
    Restrict-Access-To-Tenants, use a value of <permitted tenant list>, which is a comma-separated list of tenants. Any domain that is registered with a tenant can be used to identify the tenant in this list, as well as the directory ID itself. Restrict-Access-Context, use a value of a single directory ID, declaring which tenant is setting the tenant restrictions. NetScaler SSL Forward Proxy allows administrators to implement SSL inspection at granular level to implement security policies efficiently. NetScaler’s SSL interception feature combined with Rewrite feature allows administrators to implement Microsoft tenant restriction in just a few steps described as below.

    Let’s get started.
    So, assuming you have implemented SSL forward proxy setup in your environment. You have confirmed that the SSL interception, connectivity to internet works as expected. 
    Ensure that the users can resolve and connect to various Office365 URLs and IP addresses defined by Microsoft.
    We then begin with the configuration specific for tenant restrictions-
    Create a pattern set (patset) listing Azure AD urls used for authentication.  add policy patset PATSET_MS_Tenant_Restriction
    bind policy patset PATSET_MS_Tenant_Restriction login.windows.net -index 1
    bind policy patset PATSET_MS_Tenant_Restriction login.microsoft.com -index 2
    bind policy patset PATSET_MS_Tenant_Restriction login.microsoftonline.com -index 3
     Configure SSL Policy to allow interception for this patset.   add ssl policy SSLPOLICY_MS_Tenant_Restrction -rule "CLIENT.SSL.CLIENT_HELLO.SNI.EQUALS_ANY(\"PATSET_MS_Tenant_Restriction\")" -action INTERCEPT
     Configure two Rewrite Policies to insert HTTP headers Restrict-Access-Tenants and Restrict-   Access-Context  add rewrite action RWACTION_MS_Tenant_Restriction_1 insert_http_header Restrict-Access-To-Tenants "\"domain.com,domain.onmicrosoft.com,xxx-xxx-xxx\""
    add rewrite action RWACTION_MS_Tenant_Restriction_2 insert_http_header Restrict-Access-Context "\"456ff232-35l2-5h23-b3b3-3236w0826f3d\""
    add rewrite policy RWPOLICY_MS_Tenant_Restrction_1 "HTTP.REQ.HOSTNAME.EQUALS_ANY(\"PATSET_MS_Tenant_Restriction\")" RWACTION_MS_Tenant_Restriction_1
    add rewrite policy RWPOLICY_MS_Tenant_Restrction_2 "HTTP.REQ.HOSTNAME.EQUALS_ANY(\"PATSET_MS_Tenant_Restriction\")" RWACTION_MS_Tenant_Restriction_2
     Bind the policies to SSL Proxy vServer. Ensure the policies do not conflict with the existing policies.   bind ssl vserver PROXYVSRV_Explicit_Citrixdemo -policyName SSLPOLICY_MS_Tenant_Restrction_ssli -priority 100 -type INTERCEPT_REQ
    bind cs vserver PROXYVSRV_Explicit_Citrixdemo -policyName RWPOLICY_MS_Tenant_Restrction_1 -priority 100 -gotoPriorityExpression NEXT -type REQUEST
    bind cs vserver PROXYVSRV_Explicit_Citrixdemo -policyName RWPOLICY_MS_Tenant_Restrction_2 -priority 110 -gotoPriorityExpression END -type REQUEST
     The Microsoft Tenant Restriction must be active now. If the configuration is in place correctly now, in the packet trace you would see that headers are inserted when the request is sent from NetScaler SNIP to Microsoft servers.
    Observe the below request sent by the client to Proxy vServer, which does not contain any information about the tenants it needs to access
    When this same request is sent from SNIP on NetScaler to the Microsoft servers, we see the rewrite policies taking effect and headers being inserted as below.
     
    Subhojit Goswami
    Authors: Vaibhav Khare, Satyam Mehrotra
     Security is always a top priority for any business. Central to this for internet-facing applications is ensuring that the data is not intercepted, viewed or changed by unauthorized users. To protect this sensitive data from compromise, cryptographically secure encryption is critical for all applications.
     
    Cryptographic processes like SSL/TLS come at a price. The CPU load on servers to process encryption and decryption is severe and can impact the performance of the backend server and hence the application itself.
     
    As a pioneer in the Application Delivery Controller (ADC) market, NetScaler was the first ADC to introduce integrated SSL offload in 2002. This relieved much of the hard graft of SSL processing for businesses and lowered the TCO. Further benefits of SSL offloading extended beyond direct cost. Access to the higher layers meant encrypted traffic could be inspected and secured, as well as directed more intelligently. Moreover, centralizing the SSL made for much less complex certificate management.
     
    SSL Challenges
    SSL is not without challenges. Over time vulnerabilities in the SSL protocol have been discovered and exploited (e.g. POODLE), and advances in computing power have rendered low strength ciphers insecure and vulnerable to attack. Similarly, older SSL versions lack support for modern security features like Perfect Forward Secrecy (PFS), which provides increased protection against eavesdropping and decryption of past communication even if the private key is compromised. 
     
    While it is important to configure all the SSL elements to suit a particular environment for maximum security, this can be a manual and time-consuming process. More than this, it is error-prone, which can lead to security gaps and exposure of sensitive data. 
     Enhanced SSL profiles to ensure consistent configuration
    To solve this problem, NetScaler introduced SSL profiles. SSL profiles are a single point of configuration that can bind SSL configuration specifications to an entity. The ability to group parameters like SSL protocol versions, client/server authentication parameters, Diffie-Hellman parameters as well as cryptographic settings for ciphers and ECC curves and more, make SSL configuration simpler. 
     
     
    SSL profiles improve the time to protection and reduce configuration workload. More than this, however, it makes it easy to ensure consistent configuration and compliance with corporate security policies and industry regulation while dramatically minimizing SSL errors, which reduces the risk of security gaps.
     Enhanced SSL Profiles can be enabled from GUI (Figure 1) or via the following command:
    Set ssl parameter -defaultProfile ENABLED
                             
    Figure 1: Enable Enhanced SSL profiles under Traffic Management > SSL > Advanced SSL Settings (NOTE: Once enabled, the only way to disable is to clear the NetScaler config)
    Types of SSL profiles
    There are two types of SSL profiles. Frontend profiles are bound to internet/client-facing entities, while backend profiles define the settings for entities that interact with the application server resources.
     
    While similar in content, some parameters are only applicable to certain environments. For example, frontend profiles have settings for client authentication and backend profiles have settings for server authentication. Similarly, the different profiles have different default cipher groups included – although it is possible to change these to be the same. Overall, there are more configurable elements in a frontend profile than in the backend profile (see Figure 2 and Figure 3 for a comparison)

    Figure 2: Parameter settings for default frontend SSL profile
     

    Figure 3: Parameter setting for default backend SSL profile
     NetScaler includes a number of default profiles, which contain settings that are suitable for most scenarios. While these default settings are configured with the most secure SSL protocols and cryptographic settings and can be used as they are, all are fully customizable and can be tailored to suit customer-specific environments and security policies. 
     
    It is, however, not possible to delete or rename the default profiles, but NetScaler provides users with the flexibility to create their own SSL profiles, give them meaningful names that fit with their corporate policies and apply them to the SSL end points as required (Figure 4).
     
    Figure 4: User defined SSL Profiles can be bound to different virtual servers as required
    Advantages of SSL Profiles
    The biggest advantage of using SSL profiles is that they can be bound to multiple SSL endpoint entities on demand. Configuring SSL parameters for every individual entity is a tedious, manual task, that is prone to error. SSL profiles are simple to use (Figure 5) and remove many of the repetitive steps. Attaching a profile to an SSL end-point can be done from the NetScaler GUI or using the CLI command: 
    set ssl vserver <name> -sslprofile <name of ssl profile>
     
    Figure 5: Binding an SSL profile to an SSL End point is quick, easy and error-free from the GUI Traffic Management > Load Balancing > Virtual Servers
    Figure 6 shows how much easier it is to configure SSL settings on end-points with SSL profiles. Instead of 4 individual config changes, the admin only needs to configure the profile once and then bind it to each entity to which those settings apply. Once bound, any update to the profile – changing to stronger ciphers, for example – is propagated to each entity automatically.
     
    Figure 6: Configuring with profiles is much quicker, simpler and less prone to error
     Best Practices for SSL 
    NetScaler strongly recommends the use of Enhanced SSL profiles as a best practice for all SSL configuration. These profiles contain the full suite of SSL parameters required to make your applications secure and protect your data. They are simpler to use and far less likely to leave security gaps in your infrastructure caused by errors. 
     
    Most new SSL functionality on NetScaler will only be accessible via enhanced SSL profiles. For example, the only way to implement TLS v1.3 is to enable enhanced SSL Profiles. 
     
    To make it easier for existing customers with legacy configs, NetScaler has created a tool  to aid migration to enhanced SSL profiles. This tool will scan the config file and automatically generate the correct commands to run to update the configuration to use enhanced SSL profiles. Customers can take advantage of the tighter security features in minutes.
     While there should never be shortcuts with security, SSL profiles are an excellent way to both reduce potentially damaging errors and automate configuration. We envision a day when all configuration is this simple and secure.

    For more information on the SSL profile infrastructure, please visit the eDocs.
    Nagaraj Harikar
    The limitations of static load balancing 
    Traditional GSLB solutions rely on DNS-based load balancing to direct users to the closest available server. However, these solutions have a number of limitations.
    First, they lack the ability to accurately measure geolocation and network latency, which can result in suboptimal routing decisions.
    Second, they do not provide visibility into network congestion, micro outages or other factors that can impact performance.
    Third, they require manual configuration and maintenance, which can be time-consuming and error-prone.
    Need for real-time data and insights: In today's fast-paced and rapidly changing internet condition, there is a growing need for real-time data and insights that can help organizations to make better decisions. Internet state data from real users can help to provide this type of information, by enabling the collection and analysis of data in real-time.
    The benefits of modern GSLB 
    Modern GSLB solutions, such as the one offered by NetScaler, leverage advanced technologies to overcome these limitations. For example, Intelligent Traffic Management (ITM) uses real-time network analytics to optimize traffic routing decisions (Figure1) based on actual network performance, rather than just geographical location. This ensures that users are always directed to the best-performing server, regardless of their location.
     
    Figure1: ITM optimized algorithm to improve your application performance
    In addition, ITM provides real-time visibility into network performance and congestion, allowing businesses to proactively address performance issues before they impact end-users. They also automate configuration and maintenance, reducing the risk of errors and freeing up IT resources for more strategic initiatives.
    Multi-CDN use-case
    Multi-CDN global server load balancing (GSLB) with ITM (Citrix Intelligent Traffic Management) is a solution that enables organizations to provide a high-performance, highly available, and scalable user experience for their global customers. This solution leverages multiple content delivery networks (CDNs) to distribute user traffic across the best-performing CDN based on real-time data and performance metrics.
    With ITM, organizations can define GSLB policies that automatically route user traffic to the optimal CDN or the origin server based on factors such as user location, network conditions, and CDN availability. This approach helps to ensure that users are always directed to the optimal data source, reducing latency, improving the user experience and save cost.
    Here's how multi-CDN GSLB works:
     A user requests content from a website or application that is delivered by a CDN.  The DNS query for the website or application is directed to the NetScaler ITM.  The NetScaler ITM uses its geographic and network-aware load balancing algorithms to determine the most optimal CDN or Origin Datacenter for the user based on their location, network conditions, and other factors.  The NetScaler ITM returns the IP address of the optimal CDN to the user's device.  The user's device sends the request for the content to the CDN with the returned IP address.  The content is delivered to the user's device from the CDN.  As shown in Figure2, If CDN2's E2a edge becomes unavailable, the NetScaler ITM automatically redirects the user to the next optimal CDN1 E1b edge to ensure continuous delivery of the content. 
    Figure2: ITM optimized multi-cdn high availability 

    Figure3: ITM ensuring business continuity for its users during Azure global outage (Jan 25th 2023).
     Conclusion
     Traditional algorithms in GSLB solutions have been a mainstay of web traffic management for many years, but they are increasingly being supplanted by more modern and advanced solutions like NetScaler ITM. By leveraging real-time network analytics, providing visibility into network performance, and automating configuration and maintenance, modern GSLB solutions offer a more effective and efficient way to manage web traffic in today's complex digital environment.
    If you're application is deployed across multiple datacenters, it's time to consider upgrading to this modern solution. Contact NetScaler netscaler-itm@cloud.com today to learn more about how our Intelligent Traffic Management solution can help you optimize your web traffic and deliver a superior user experience.
        
    Guest

    Listen Policy

    By Guest, in Core ADC use cases,

    Listen Policy
    Contributed by Magnus Esse

    Overview
    Listen policies were initially a way of simulating multi-tenancy using "shadow vservers." If the requirement is to isolate different network paths from each other, the recommended way of doing that now is to use Admin Partitions.
    There are other situations when the usage of listen policies can be helpful, and some examples of when it might be worth considering using them will be covered here.
     
    Listen policies are configured on a virtual server level. Load Balanced (LB) vserver, Content Switched (CS) vserver, and Gateway vserver are where I have seen them used. When configuring a listen policy for a virtual server, it can use the same IP, port and protocol as another virtual server. It is possible to have several virtual servers sharing the same IP with different listen policies, the listen priority will tell in which order the policies should be evaluated, and the listen policy getting hit first will decide which virtual server should be used. If there is one virtual server without any listen policy, it will be used for all traffic not evaluated true in any of the listen policies.
     
    Example 1:
    In this scenario, you have a service that should only be accessible from certain clients. If a client that is not allowed tries to connect to the virtual server, the ADC will not answer the client connecting at all, and thus the connection will fail.
     

     
    Example 2:
    In this scenario, you have a service that is using a AAA vserver for authentication, but there are some specified IP addresses that are to be excempted from the authentication. You can set this up with the help of a content switch if you want, however, you can also use listen policies.
     

     
     
    Use Case Example:
    In this scenario, third-party users are allowed to connect through Citrix Gateway to be able to work remotely. If a user leaves the other company, it might not be communicated quickly that the user has left. In this case, that user will still be able to connect through the Citrix Gateway service and still have access. One solution to minimize the risk is to enforce all access by third-party contractors from the same source IP within a specified range that corresponds to the expected IP for the third-party company. The reasoning is that the third-party company will revoke access to their company network even though they might forget to inform their customers that the user has left their company. By forcing all third-party contractors to access from known addresses, the risk can be minimized considerably.
     
     



     
    Guest

    ACLs and Datasets

    By Guest, in Core ADC use cases,

    ACLs and Datasets
    Contributed by Magnus Esse

    Summary
    This document intends to give a brief description of how the usage of datasets in combination with ACLs might reduce your configuration considerably as well as make it a lot easier to understand what has been configured, and makes life a lot easier if there are any changes needed in the future.
     
    Limitations
    ADC access lists (ACL) only look at the incoming traffic on the ADC interfaces. An ACL will never affect any of the internal ADC traffic.
    There is currently (firmware release 13.1)  a limitation of 10,000 Effective ACL Count, which might be higher than what you have actually configured. You can check the number of ACLs in use by the command stat acl and look for the following information.
    ACL Count
     
     
    --
     
    1
      Effective ACL Count
     
    --
     
    1
     
    Examples
    In later releases, it is possible to use datasets instead of specifying a range of IP addresses in the source and destination fields. This makes it simpler to configure, and the configuration will be easier to understand and maintain. However, there is one major thing to keep in mind if using datasets within the ACL configuration, and that is that even though it will look like you get fewer ACLs, it might be the other way around. always verify with the stat acl command how many resources are being used.
    Some benefits of looking at using datasets together with ACLs are that it will be a lot easier to get an overview and manage a bit more complex ACL configuration. One clear advantage is the simplification, as it is a lot easier to add/remove items from a dataset than doing it in the actual ACLs.
    Let's look at the following simple example for two ACL configurations that will achieve the same result.
     
    Example 1:
    add ns acl ACL-01 ALLOW -srcIP = 10.10.10.10-10.10.10.19 -destIP = 10.100.100.10-10.100.100.19 -destPort = 22 -protocol TCP -priority 10add ns acl ACL-02 ALLOW -srcIP = 10.20.20.10-10.20.20.19 -destIP = 10.100.100.10-10.100.100.19 -destPort = 22 -protocol TCP -priority 20add ns acl ACL-03 ALLOW -srcIP = 10.10.10.10-10.10.10.19 -destIP = 10.100.100.10-10.100.100.19 -destPort = 443 -protocol TCP -priority 30add ns acl ACL-04 ALLOW -srcIP = 10.20.20.10-10.20.20.19 -destIP = 10.100.100.10-10.100.100.19 -destPort = 443 -protocol TCP -priority 40apply ns acls
     
    Stat acl gives the following information regarding number of ACLs in use:
    ACL Count
     
     
    --
     
    4
      Effective ACL Count
     
    --
     
    4
     
    Example 2:
    add policy dataset srcIP_dataset ipv4add policy dataset dstIP_dataset ipv4add policy dataset dstport_dset numberbind policy dataset srcIP_dataset 10.10.10.10 -index 1 -endRange 10.10.10.19bind policy dataset srcIP_dataset 10.20.20.10 -index 2 -endRange 10.20.20.19bind policy dataset dstIP_dataset 10.10.10.110 -index 1 -endRange 10.10.10.119bind policy dataset dstport_dset 22 -index 1bind policy dataset dstport_dset 443 -index 2add ns acl ACL-01 ALLOW -srcIP = srcIP_dataset -destIP = dstIP_dataset -destPort = dstport_dset -protocol TCP -priority 10
     
    Stat acl gives the following information regarding number of ACLs in use:
    ACL Count
     
     
    --
     
    1
      Effective ACL Count
     
    --
     
    4
     
    Example Summary:
    Consider the changes you will need to do in the configurations in the two examples above if you would need to also allow for traffic on port 80. In example 1 that would include creating 2 new ACL rules. In example 2 it would only be needed to add port 80 to the dataset.

     

© Cloud Software Group, Inc. All rights reserved.

×
×
  • Create New...