How to configure a NetScaler appliance for Nested Active Directory Group Extraction of LDAP

The credentials of a user attempting to log on to NetScaler Gateway are sent to the Active Directory for validation. If the user name and password are valid, the Active Directory sends the user attributes to the NetScaler appliance.

The memberOf attribute is one of the attributes that the Active Directory sends to the NetScaler appliance. This attribute contains the name of the group in which the user is defined as a member in the Active Directory. There can be cases in which a user is a member of GroupA, and GroupA is in turn is a member of GroupB, which is a member of GroupC, and so on. Group information extraction in such cases can be achieved by taking the following steps.

To configure a NetScaler appliance for Nested Active Directory Group Extraction

1. Log on to the NetScaler GUI and, on the Configuration tab, do one of the following: Navigate to System > Authentication > LDAP > Servers and jump to step 4.

User-added image

OR

Navigate to NetScaler Gateway ->Virtual Servers and select the VPN vserver for which the nested group extraction option needs to be set.

User-added image

  1. In the Basic Authentication section, click LDAP Policy.

    User-added image

  2. Select the LDAP policy that you want to edit, and click Edit.

    User-added image

4. Navigate to Nested Group Extraction, set the Group Name Identifier as –<< New >>– and type cn in the text field below it, select Group Search Attribute as –<< New >>– and type memberOf in the text field below it shown in the screen below. You can also set the memberOf attribute to match the search filter parameter set on the appliance. If the attribute matches, you are allowed to log on to the network. You can also set the maximum nesting level for group extraction.

User-added image

5. Attempt to log on to NetScaler Gateway as a member of one of the nested user groups defined in the Active Directory.

6. To verify that the group information for the logged on user has been extracted, open a command line editor and log on to the NetScaler appliance.

1.1. Verify that the group you logged on as a member of is included in the groups defined on the NetScaler appliance.

Example

> sh aaa group

1) GroupName: TestGRP 2) GroupName: group1 3) GroupName: TestNS 4) GroupName: Group2

Done

7. If the group is not listed, create a group using the below command:

 > add aaa group <groupname>

8. Use command shown in the following example to check for the logged-on groups.

Example

Done

Which should match the ‘Member Of’ tab when checked for this user in Active Directory as shown in the below screenshots.

> sh aaa group -loggedIn Group name: group1

Group name: TestNS

Group name: Group2

Which should match the ‘Member Of’ tab when checked for this user in Active Directory as shown in the below screenshots.

User-added image

User-added image

Related:

How to Pass Domain Information Along with Username to LDAP Server from NetScaler

Tradução automática

Эта статья была переведена автоматической системой перевода и не был рассмотрен людьми. Citrix обеспечивает автоматический перевод с целью расширения доступа для поддержки контента; Однако, автоматически переведенные статьи могут может содержать ошибки. Citrix не несет ответственности за несоответствия, ошибки, или повреждения, возникшие в результате использования автоматически переведенных статей.

Related:

  • No Related Posts

How to Test LDAP Authentication Settings on NetScaler Gateway Running 11.1 Version

Tradução automática

Эта статья была переведена автоматической системой перевода и не был рассмотрен людьми. Citrix обеспечивает автоматический перевод с целью расширения доступа для поддержки контента; Однако, автоматически переведенные статьи могут может содержать ошибки. Citrix не несет ответственности за несоответствия, ошибки, или повреждения, возникшие в результате использования автоматически переведенных статей.

Related:

  • No Related Posts

Extract and Use Custom Attributes from Active Directory for NetScaler Appliance

Although Active Directory (AD) username and realm/domain attributes are often sufficient for identifying a user, at times you need even more details of the user. For example, “UserPrincipalName” that contains the user’s domain might represent a forest level realm and not the organization to which the user actually belongs to. In some cases, user’s “objectGUID” is required to represent the user object. In addition, the administrator might configure custom attributes at AD for single sign-on and federation. To be able to get these attributes from AD as part of user authentication gives the flexibility to administrator, to control access protected resources and integrate with systems in the cloud.

In addition, one of the major scenarios this would solve is when multiple servers require unique attributes of user. For instance, server A might require user’s “DistinguishedName” and Server B might require “sAMAccountName”.

This article describes a mechanism to extract the user attributes from AD as a part of authentication and use these attributes to shape run time traffic.

Audience

This article aims at administrators who would like to take special actions based on user properties.

Extracted attributes can be used in a variety of ways, including but not limited to, federation with third parties, single sign-on to custom applications that might rely on user specific property such as “ObjectGUID”.

This applies to AAA-TM and Gateway products of NetScaler.

Prerequisite

NetScaler 10.5 54.x onwards.

Extracted Attributes

The following is a screen shot of user properties on AD Attribute Editor. All the attributes specified in the Attribute Editor, including custom attributes, can be extracted.

User-added image

Active Directory/LDAP Configuration on NetScaler

While this feature does not change the way AD/LDAP profile is configured on NetScaler, it however adds new options/parameters that is specified to extract specific user attributes.

New configuration parameters called attribute1, attribute2, and so on till attribute16 are introduced. These options allow administrator to specify upto 16 user attributes as defined in attribute editor in AD. Based on the configuration, NetScaler will query the AD for these attributes when authenticating the user. After it obtains the attributes, NetScaler stores these attributes in user context/session and makes them available with advanced policy expressions. The following section of this article describes how these attributes can be used in run time traffic.

The following is the example LDAP profile:

add authentication ldapAction <myServer> -serverIP 1.1.1.1 --serverPort 3268 -authTimeout 30 -ldapBase "dc=nsi-test,dc=com" -ldapBindDn Administrator@nsi-test.com -ldapBindDnPassword secret -encrypted -encryptmethod ENCMTHD_2 -ldapLoginName samaccountname -groupAttrName memberOf -ssoNameAttribute samaccountname –authentication ENABLED –attribute1 ObjectGUID –attribute2 DistinguishedName

In the preceding profile, you are configuring two attributes, attribute1 and attribute2. Attribute1 fetches “ObjectGUID” and attribute2 fetches “DistinguishedName”.

In NetScaler GUI, this is configured from, Security > AAA Application Traffic > Policies > Authentication > Basic Policies/Advanced Policies > LDAP.

Note: Advanced authentication policies also have this feature.

Similarly, NetScaler Gateway can be configured at, NetScaler Gateway > Policies > Authentication > LDAP.

The following is a screen shot from AAA Application Traffic module.

User-added image

Use Extracted Attributes at Runtime

After the user attributes are extracted and stored in user session on NetScaler, these can then be referenced in advanced policy expressions of NetScaler.

A new expression, “http.req.user.attribute(n)” can be used to extract these attributes. In the aforementioned expression, “n” is the index of the attribute that was previously stored.

Based on the LDAP profile configured in the preceding section, to extract “ObjectGUID” of user, “http.req.user.attribute(1)” can be used because “ObjectGUID” is obtained and stored in index 1. Likewise, to extract “DistinguishedName”, “http.req.user.attribute(2)” can be used.

Practical Uses of Attributes

Like mentioned in the first section, these attributes clearly locate/identify a user. For example, “distinguishedName” can be used to allow/disallow a user from accessing a particular resource and if a contractor is not allowed to access a finance application, these attributes can be used in authorization policies.

Likewise, these can be used in traffic, rewrite and responder policies as well.

Application Scenarios

Authorization

The following policy can be used to authorize user based on their “DistinguishedName”:

Add tm authorization policy <mypolicy> ‘http.req.user.attribute(1).eq(“cn=user1, cn=Users, DC=mytest, DC=com”)’ ALLOW

Traffic policy

The following policy can be used to select a specific traffic profile based on user’s “userPrincipalName”, assuming it is extracted and stored as attribute3:

Add tm trafficpolicy <mypol> ‘http.req.user.attribute(3).eq(user1@mytest.com)’ <myaction>

Likewise, rewrite and responder policies can take advantage of these attributes.

Conclusion

All the extracted attributes from different authentication sources (such as, AD, RADIUS, SAML, WebAuthentication) are stored in single namespace. This way, “UserPrincipalName” for AD can be specified differently in AD to the way it can be specified on RADIUS server. Administrator can extract “UserPrincipalName” from respective servers and reference them as attribute1 because of serializing namespaces.

Although this article describes extracting attributes from AD, these attributes can be obtained from SAML or WebAuthentication.

Regardless of the authentication source, attributes can be used at run time to shape user access.

Note: In a two factor setup, if both primary and secondary policies extract and store the same attribute index, the first one is stored and the second is ignored. That is, if a policy in primary cascade extracts attribute1 and another policy in secondary cascade extracts attribute1 again, the value gathered by primary cascade is preserved. To avoid this situation, care must be taken in assigning the attributes to be extracted such that there is no conflict.

Advanced Expression Return Value
http.req.user.login_name Returns the user entered logon name.
http.req.user.name Returns the SSO Name attribute value if configured. Otherwise, it returns user entered logon name.
http.req.user.domain Returns the Domain Name configured in the Session Profile.
http.req.user.passwd Returns the user entered password.
http.req.user.attribute(1…16) Returns the extracted attribute value.

Related:

How to Configure NetScaler to Use Active Directory Authentication and Privileges

Add Authentication Server

To add an authentication server, complete the following procedure from the graphical user interface of NetScaler:

  1. Click System > Authentication > LDAP > Servers > Add.

    You can then configure the parameters for the LDAP server in the Create Authentication dialog box, as shown in the following screen shot:

    User-added image

  2. Specify the required information to define the LDAP Server.

    The required fields are:

    • Name* – Name of the server.

    • Authentication Type – The authentication type, in this scenario is LDAP.

    • Server – The IP address and TCP port used by the LDAP server.

    • Base DN – The base, or node from where the ldapsearch should start.

    • Bind DN – The full distinguished name that is used to bind to the LDAP server.

    • Bind DN Password – The password for the Bind DN account.

    • Confirm Bind DN Password – The password for the Bind DN account.

    • Login Name – The name attribute used by the NetScaler appliance to query the external LDAP server or an Active Directory.

    • Search Filter – The string to be combined with the default LDAP user search string to form the value.

    • Group Attribute Name – The Attribute name for group extraction from LDAP server.

    • Sub Attribute Name – The Sub Attribute name for group extraction from LDAP server.

    • Security Type – Select Plaintext for non-secure LDAP communication or select TLS or SSL for secure LDAP communication.

  3. Click Create.

  4. Click the Policies tab, then click the Add button:

    User-added image

  5. Enter a name for the policy, select the server that you created in steps 2 and 3 from the drop-down menu.

  6. In the Expression text field, type ns_true, then click Create:

    User-added image

  7. Click the policy that you just created to select it, then click the Global Bindings button:

    User-added image

  8. Select the policy that you previously created from the drop-down menu, then click the Select button:

    User-added image

  9. Click Bind, then click Done.

Create Group

To add create a group on NetScaler, complete the following procedure from the graphical user interface of NetScaler:

  1. Click System > User Administration > Groups > Add:

    User-added image

  2. Type the group name, which must exactly match the name of the Active Directory group, as configured in Active Directory Users and Computers on the server. This group name is that one that you would like to allow access to the NetScaler.

    Click the Insert button in the Command Policies section:

    User-added image

  3. Select the appropriate policy that corresponds to the privilege level that you want to assign to the group.

    In this example, superuser is selected.

    Click the Insert button:

    User-added image

  4. Click Create.

  5. You should now be able to log into the NetScaler with the users assigned in Active Directory to the group that you just created on the NetScaler, and they should have the privilege level that you have assigned to them.

Sample LDAP Search Filter

In this article we have created an OU named Citrix Test, and in that OU, there is a group named Citrix Admins, and the users are located within that group. On the NetScaler, use the following search filter: memberOf=CN=Citrix Admins,OU=Citrix Test,DC=JKlab,DC=com.

User-added image

Related:

How to Use LDAP for Group Extraction Through NetScaler Without Authentication

To configure LDAP for group extraction without authentication and use other authentication method, for example RADIUS, you can proceed the following two ways:

  • Configure the authentication methods on cascade as primary, ensuring that LDAP for extraction has a higher priority that the authentication method.

  • Configure LDAP and the authentication method as a two factor authentication.

On LDAP authentication used just for group extraction, unckeck the Authentication checkbox on the LDAP server configured on NetScaler. This would hide the LDAP password field on the logon page, and will prompt for just the RADIUS authentication.

User-added image

User-added image

Related:

How to Monitor XenMobile Servers through SCOM

To configure SCOM to monitor XenMobile Server nodes and receive traps

Important: There are various approaches to monitoring in SCOM. Consult a SCOM expert for specific configuration steps. The steps in this article are only examples.

  1. Enable SNMP monitoring in the XenMobile console.

  2. Discover XenMobile Server nodes.

    1. Open the SCOM Operations Console and go to Administration. Right-click Network Management and then open Discovery Wizard.

    2. To discover XenMobile Server nodes, select Network devices.

      User-added image

    3. Because XenMobile Server supports only SNMP V3, select/add SNMP V3 Run As Account. Access mode can be either SNMP or ICMP and SNMP.

      User-added image

  3. To create Run As Account for SNMP v3 devices, the user should be the same user you added in the XenMobile console in the SNMP settings. Ensure that you add the correct password and protocols.

    User-added image

  4. This wizard creates a Discovery Rule to discover XenMobile Server nodes. After the rule is created, do one of the following:

    • Either allow the discovery rule to be run after the wizard is closed.

    • Run the rule manually.

      User-added image

  5. To run the discovery rule manually, go to Network Management > Discovery Rules. Select the Rule and then click Run from Tasks pane.

    User-added image

  6. To confirm the XenMobile Server nodes are successfully discovered, go to Network Management > Network Devices. If the discovery is successful, the XenMobile Server nodes appear. Check the Properties of each XenMobile Server. The Certification field should be CERTIFIED.

To create a Management Pack

Open the SCOM Operations Console and go to Administration. Right-click Management Packs and then click Create Management Pack. Type the appropriate values and then click Create to create a Management Pack.

User-added image

To create a group for XenMobile Servers

Open the SCOM Operations Console and go to Authoring. Right-click Groups and then select Create a new group.

User-added image

Grouping can be done based on Location (XenMobile). There could be other approaches to Grouping.

User-added image

To Create the State View

  1. Open the SCOM Operations Console and go to Monitoring. Create a folder. Right-click the folder and then select New > State View. Select the Target as Node.

    User-added image

  2. Select the group created in the previous step. This will only show the XenMobile Server nodes.

To Create the Diagram View

Open the SCOM Operations Console and go to Monitoring. Create a folder. Right-click the folder and select New > Diagram View. Select the Target as the group created earlier. This will only show XenMobile Server nodes.

User-added image

To create a rule to receive all traps as events

  1. Open the SCOM Operations Console and go to Authoring. Right-click Rules and then select Create a new rule. Follow the wizard to complete Rule creation.

  2. Click Collection Rules > Event Based > SNMP Trap (Event).

    User-added image

  3. Enter Rule Name and Description. Select Rule Target as Node. Ensure that Rule Category is Event Collection.

    User-added image

  4. Do not enter an OID here. Click Create to complete Rule creation.

    User-added image

To create an Event View

  1. Open the SCOM Operations Console and go to Monitoring.

  2. Create a folder. Right-click the folder and then select New > Event View. Select the Target as Node. Select the group created earlier. This will only show Traps from XenMobile Server nodes. In addition, you can select generated by specific rules and select XenMobile Server specific rules.

    User-added image

To create a rule to receive all traps as alerts

  1. Open the SCOM Operations Console and go to Authoring.

  2. Right-click Rules and then select Create a new rule. Follow the wizard to complete Rule creation.

  3. Select Alert Generating Rules > Event Based > SNMP Trap (Alert)

    User-added image

  4. Enter Rule Name and Description. Select Rule Target as Node. Ensure that Rule Category is Alert.

    User-added image

  5. Do not enter any OID. Click Next.

    User-added image

  6. Enter Alert name. Add appropriate Alert description. Set the Priority and Severity for the alert.

    User-added image

To create the alert view

  1. Open the SCOM Operations Console and go to Monitoring.

  2. Create a folder. Right-click the folder and select New > Alert View. Select the Target as Node. Select the group created earlier. This will only show Alerts from XenMobile Servers.

    User-added image

  3. In addition, you can select generated by specific sources and select XenMobile Server specific rules.

    User-added image

To create a rule based on a specific OID

Note: There could be multiple approaches.

  1. Open the SCOM Operations Console and go to Authoring.

  2. Right-click Rules and then select Create a new rule. Follow the wizard to complete Rule creation. Select Alert Generating Rules > Event Based > SNMP Trap (Alert)

    User-added image

  3. Enter Rule Name and Description. Select Rule Target as Node. Ensure that Rule Category is Alert.

    User-added image

  4. Enter OID 1.3.6.1.2.1.88.2.0.1 (mteTriggerFired).

    User-added image

  5. Enter Alert name. Add appropriate Alert description. Set the Priority and Severity for the alert.

    User-added image

  6. Export the Management Pack and edit the .xml file as shown below.

    1. Add the following in the xml file:

      For details, see the Microsoft blog post. https://blogs.technet.microsoft.com/kevinholman/2015/02/03/snmp-trap-monitoring-with-scom-2012-r2/

      Note: There could be other ways to configure this. This specific example is based on the blog post mentioned above.

      <ConditionDetection ID=”FilterSpecificVarbind” TypeID=”System!System.ExpressionFilter”>

      <Expression>

      <RegExExpression>

      <ValueExpression>

      <XPathQuery Type=”String”>EventData/DataItem/SnmpVarBinds/SnmpVarBind[6]/Value</XPathQuery>

      </ValueExpression>

      <Operator>ContainsSubstring</Operator>

      <Pattern>.1.3.6.1.4.1.3845.5.1.1.18.1.0</Pattern>

      </RegExExpression>

      </Expression>

      </ConditionDetection>

    2. Update the version number appropriately:

      <Version>1.0.0.1</Version>

  7. Import the .xml file as a management pack.

  8. In Authoring > Rules, right-click the Rule created and go to Properties.

  9. In Configuration, the added condition should be visible. Click Edit to view and edit the condition.

    User-added image

Create SNMP probe unit monitor

  1. Open the SCOM Operations Console and go to Authoring.

  2. Right-click Monitors and then select Create a monitor > Unit Monitor.

  3. Select SNMP > Probe Based Detection > Single Event Detection > SNMP Probe Monitor.

    User-added image

  4. Enter Monitor name and Description. Select Monitor Target as Node.

    User-added image

  5. Enter the OID to be monitored. Select Frequency.

    User-added image

  6. Enter appropriate threshold value: /DataItem/SnmpVarBinds/SnmpVarBind[1]/Value

    User-added image

  7. Enter the OID to be monitored. Select Frequency.

    User-added image

  8. Enter appropriate threshold value for the second SNMP probe: /DataItem/SnmpVarBinds/SnmpVarBind[1]/Value.

    User-added image

  9. Set appropriate Health State for the two SNMP Probes.

    User-added image

  10. Select how the alert will be generated. Enter Alert name and description. Set Priority and Severity for this alert.

    User-added image

To create performance rules to plot graphs

  1. Open the SCOM Operations Console and go to Authoring. Right-click Rules and the select Create a new rule.

  2. Select Collection Rules > Performance Based > SNMP Performance.

    User-added image

  3. Enter Rule name and Description. Select Rule Target as Node. Ensure that Rule Category is Performance Collection.

    User-added image

  4. Enter the required OID. Select Frequency.

    User-added image

To create performance views

  1. Open SCOM Operations Console and go to Monitoring. Create a folder. Right-click the folder and select New > Performance View. Select the Target as Node.

    User-added image

  2. Create multiple performance views for multiple rules or add all the rules in a single view.

    User-added image

Related:

Query: Shared Devices for iOS DEP

Q: Does XenMobile support shared devices for iOS when the devices are enrolled in Apple DEP?

A: Yes

Q: What is the difference between Basic DEP and Authorized DEP?

A:

Basic DEP: During the setup assistant, the initial enroller is the default DEP user. Then, it is the final user after MAM registration with SecureHub app (iOS agent).

Authorized DEP: In this case, it is the final user who is directly the enroller during the setup assistant.

Q: Does that mean using the DEP for individually issued devices is a Basic DEP?

A: For Shared Devices feature, you have to differentiate the 2 types of server mode:

  • MDM-only: In this case, you could use the default DEP user as Shared enroller because there is no authentication with this special user.
  • ENT: In this case, you must use the final user because it is possible to sign in with the Shared enroller.

Note:

Don’t forget that the DEP user’s password is a random and cannot be changed after its creation.

Q: How will it decide that this is an Authorized DEP device or a Basic DEP?

A: There are 2 ways to know it:

  1. In the admin console: Go to Settings -> Apple Device Enrollment Program and edit the DEP account. If the “Require credentials for device enrollment” setting is set to ON, it is an authorized DEP. Otherwise, it is a basic DEP.
User-added image
2. In the device setup assistant: If there is an authentication page, it is an authorized DEP. In the case of basic DEP, the MDM enrollment does not require the DEP user’s credentials. (Apple calls it “Automatic enrollment”)

Related:

NetSclaer MAS Stylebook Deployment will Not Complete if Load Balancing Server Already Exists on Destination Appliance

Tradução automática

Эта статья была переведена автоматической системой перевода и не был рассмотрен людьми. Citrix обеспечивает автоматический перевод с целью расширения доступа для поддержки контента; Однако, автоматически переведенные статьи могут может содержать ошибки. Citrix не несет ответственности за несоответствия, ошибки, или повреждения, возникшие в результате использования автоматически переведенных статей.

Related:

  • No Related Posts

StoreFront 3.9.0.56- Cannot change Default value of NetScaler Gateway under Store’s Remote Access Settings to internal store

Tradução automática

Эта статья была переведена автоматической системой перевода и не был рассмотрен людьми. Citrix обеспечивает автоматический перевод с целью расширения доступа для поддержки контента; Однако, автоматически переведенные статьи могут может содержать ошибки. Citrix не несет ответственности за несоответствия, ошибки, или повреждения, возникшие в результате использования автоматически переведенных статей.

Related:

  • No Related Posts