Authentication Fails for Users Belonging to Groups in Multiple Domains

Authentication at the logon point fails for users who belong to groups in different domains. For example, two domains in the same forest, where userA exists in domainA but is also a member of a universal group in domainB.

User-added image

The Access Gateway log contains an LDAP operation error:

ns | :LDAP (052):openldap (03) | LDAP operation failed: error code = 10 (referral), error message = ‘0000202B: RefErr: DSID-03100742, data 0, 1 access points

ref 1: ‘example.com

Related:

InsightIQ 4.1: Configuring Active Directory authentication

Article Number: 494592 Article Version: 4 Article Type: How To



Isilon,Isilon InsightIQ

InsightIQ configuration:

  1. Log in to InsightIQ web administration interface.
  2. Click SETTINGS tab.
  3. Click Users on the SETTINGS ribbon.
  4. Click Configure LDAP.
  5. Check Enable LDAP. Enabling LDAP allows you to edit the remaining fields on this page.
  6. Type Active Directory (AD) server (Domeain Controler) URI into the LDAP server field. Server URI should begin with ldap:// or ldaps://. Port is optional
  7. Type the Base Search Entry. Distinguished Name (DN) of the entry to start searches at. If your AD domain is domain.com, your DN would be dc=domain,dc=com.
  8. Type AD server credentials in the Bind entry and Bind password fields. The Bind Entry should have the format of “user@domain”. For example: ldap_service@emc.com
  9. Click link: Show optional setings.
  10. Type user into Object Class for users field. Attribute that defines a user on this server.
  11. Type group into Object Class for groups field. Attribute that defines a group on this server.
  12. Click Submit.

Active Directory server configuration:

**NOTE** InsightIQ 4.1.2 supports logging in via sAMAccountName.

If you are running InsightIQ4.1.2, you do not need to configure gidNumber or uid attributes in your Active Directory server.


On the Active Directory server confirm following attributes for groups and users.

1. Groups have to have a valid, configured gidNumber attribute.

2. Users have to have their uid set and it should be the same as their sAMAccountName attribute

Tools, resources used while reproducing the issue/configuration in a lab environment:

  • IIQ 4.1 vm
  • Windows 2012 AD
  • Wireshark to verify IIQ LDAP requests and responses from AD
  • Softerra LDAP Browser to verify LDAP / AD servers Distinguished Names and users and groups attributes

To verify groups and users attributes in the Active Directory:

  1. Log in to Domain Controller.
  2. Go to Active Directory Users and Computers.
  3. Click Viewtab.
  4. Click/check Advanced Features.
  5. Navigate to Users and open Properties window of related group or user.
  6. Navigate to and click on the Attribute Editor.

Related:

XtremIO: LDAPS authentication failure due to failed SSL handshake between LDAPS server and XMS

Article Number: 524958 Article Version: 4 Article Type: Break Fix



XtremIO Family,XtremIO X1,XtremIO HW Gen2 400GB,XtremIO HW Gen2 400GB Encrypt Capbl,XtremIO HW Gen2 400GB Encrypt Disable,XtremIO HW Gen2 400GB Exp Encrypt Disable,XtremIO HW Gen2 400GB Expandable,XtremIO HW Gen2 800GB Encrypt Capbl

Logging into an XMS server using an LDAPS user account is unsuccessful.

Note: The cause and resolution contained within this KB should only be considered after referring to and following the instructions within the below KB articles where applicable:

The affected XMS server’s OpenLDAP configuration file (/etc/openldap/ldap.conf) may contain an additional line (beginning with TLS_PROTOCOL_MIN) which results in a failedSSL handshake between the customer’s LDAPS server and the affected XMS server.

Note: The aforementioned line is only expected to exist within the XMS server’s OpenLDAP configuration file via manual addition (usually by a member of the XtremIO Support team during troubleshooting of a past LDAPS issue reported on the same XMS server). That being said, although the probability of this being the case is deemed to be extremely low, it is still worth looking into the above as a potential root cause of failed LDAPS authentication

To ensure that the reported LDAPS authentication failure is a result of the issue described within the Cause section of this KB, contact XtremIO Technical Support for assistance by creating a Service Request (SR) for the reported issue. When contacting XtremIO Technical Support, provide the numbers of any SRs (if applicable) that were created for LDAPS authentication issues reported on the affected XMS server in the past and ensure that you have a fresh XtremIO log bundle available for attachment to the Service Request (SR) to expedite the review process. To collect an XtremIO log bundle, follow the instructions within KB 334928 – How to collect XtremIO log bundle for analysis by EMC Global Technical Support.

Related:

Using samba SID from LDAP?

Hi,

we use an openldap server as the authentication provider in OneFS 8.1.2. The attribute sambaSID from the samba schema contains the users’ SID which is used by our samba servers. Is it possible to use this attribute for smb shares in OneFS? OneFS creates its own default SID for every ldap user. For example:

On our samba servers:

# net sam show xmuster

SAMBAxmuster is a User with SID S-1-5-21-400xxx2-314xxx9-252xxx7-69720

On our Isilon:

# isi auth users view xmuster

Domain: LDAP_USERS

Provider: lsa-ldap-provider:LDAP Cluster

Sam Account Name: xmuster

UID: 34360

SID: S-1-22-1-34360

Thanks.

Related:

How to configure LDAP Nested group validation for Microsoft Active Directory(AD) using Object Identifier(OID)

By default, NetScaler will only search for usernames that are direct members of the Active Directory group.

When communicating specifically to Microsoft Active Directory (AD) you can provide object identifier (OID) prefixes in the bind filter to instruct AD to use specific rules when searching for a match. One such rule is to walk the LDAP directory, which is needed when you are looking for nested group memberships.

First, configure your LDAP server on the NetScaler as desired, The details of the LDAP server configuration is explained in How to Configure LDAP Authentication on NetScaler or NetScaler Gateway

In order to search for groups within which the end user is a member including those groups for which membership is by nested groups, the LDAP server must be asked to recursively search through all group membership nodes by using an OID as part of the search filter.

LDAP Matching rule OID: 1.2.840.113556.1.4.1941

String Identifier: LDAP_MATCHING_RULE_IN_CHAIN.

So your search filter would simply look like: memberOf:1.2.840.113556.1.4.1941:=CN=<DN of Group>

Example:

memberof:1.2.840.113556.1.4.1941:=cn=NEEDED_GROUP,DC=COMPANY,DC=COM

If the user is a member of group NESTED_GROUP, and the group NESTED_GROUP is nested within group NEEDED_GROUP, then an LDAP authentication profile that uses a search filter for group NEEDED_GROUP will deny logon for that user unless the LDAP_MATCHING_RULE_IN_CHAIN OID is included in the search filter so that the LDAP server can be instructed to perform recursive group nesting.

Once configured the LDAP server configuration should look like below:

User-added image

Related:

LDAP Sync Configuration

I need a solution

Hi,

In our company, we have accounts in Symantec VIP that are not in our AD. Previously, we thought that if we filter those accounts from the user store, it will not be deleted by LDAP Sync. With this documentation above, it seems that if the user does not exist in the user store filter, then it will be deleted. Is this correct?

Is there any way that we can use LDAP Sync if some of the accounts are not in AD?

Is there a way we can we only turn on LDAP Sync for some accounts?

0

Related:

7020381: How to Allow Users to Login to the QMS Using LDAP

For the LDAP server connection address, place DNS name or IP address of the server.

The username and password needs to be a full LDAP username including context. The user should have administrator rights. Note: Some systems only require the username or domainusername.

The DN search base can be set to specify the LDAP tree where GWAVA will begin to search for objects. For eDirectory this field can be left blank, though if set, it specifies a starting point for the search in the LDAP tree. (For instance: ou=user,o=gwava) If using Active Directory the DN must be set for the user list to work (ie. cn=user,dc=gwava,dc=com)

Search fields are usually not necessary for any system to setup, but can be useful if desired. By default most LDAP servers (including eDirectory and Active Directory) have an attribute applied to an object of the type “mail” which contains the object’s or user’s email address. If you have email addresses for users stored under an attribute other than mail you can specify the possible attributes by separating them with commas.

In the example below the LDAP server is set to search for the attributes ‘mail’ and ‘secondarymail’.

4) Click on the green plus sign, to add it.

5) Save changes.

Related: