4.1 Understanding LDAP Identity Sources

For CloudAccess to provision user accounts to the SaaS applications, each user account in the identity source must contain the attributes listed. If you are using an LDAP identity source, there are specific attributes that must be populated on the user accounts. If you are using a JDBC database, there are certain columns of information that must be populated. The information for each identity source is different.

NOTE:For security reasons, by default CloudAccess does not allow you to add a user with a user name that is the same as a previously added user. If you attempt to do so, CloudAccess displays the user as not activated. For more information, see Troubleshooting Provisioning Issues.

Review the information in the following sections before you deploy the appliance and when you configure additional identity sources. Ensure that your identity source meets all requirements and the user account information in the identity source contains the proper information to synchronize the accounts.

4.1.1 Active Directory Requirements

Verify that your Active Directory environment meets the following requirements:

  • Windows Server 2012 R2 or Windows Server 2008 R2.

  • A unique identity for each user account, whether you have one or more domains or identity sources. The appliance uses the sAMAccountName as the unique identifier for the users.

To provision user accounts from Active Directory to the SaaS applications, all of the following attributes must be populated on the Active Directory users:

  • First name

  • Last name

  • Full name (Display name is the field that populates this attribute.)

  • sAMAccountName or Logon Name (Pre-Windows 2000)

  • User Principal Name (UPN)

  • Email address

Obtain the following required items:

  • The password and the fully distinguished LDAP-formatted name of a user in Active Directory who has read access to the user objects. The appliance will use this user account to make LDAP binds to Active Directory.

  • The IP address of one or more Active Directory servers that contain the users.

  • The context of the users in Active Directory.

4.1.2 eDirectory Requirements

Verify that your eDirectory environment meets the following requirements:

  • eDirectory LDAP 8.8.8.

  • A unique identity for each user account, whether you have one or more eDirectory trees or identity sources.

To provision user accounts from eDirectory to the SaaS applications, all of the following attributes must be populated on the eDirectory users:

  • CN (Username is the field that populates this attribute.)

  • Given Name (First name is the field that populates this attribute.)

  • Internet EMail Address

  • Surname (Last name is the field that populates this attribute.)

Obtain the following required items:

  • The password and fully distinguished LDAP-formatted name of a user in eDirectory who has the following rights. The appliance will use this user account to make LDAP binds to eDirectory:

    • Property Rights

      • CN: compare, read, inherit

      • Description: compare, read, inherit

      • Given Name: compare, read, inherit

      • GUID: compare, read, inherit

      • Internet EMail Address: compare, read, inherit

      • Login Disabled: compare, read, inherit

      • Member: compare, read, inherit

      • Group Membership: compare, read, inherit

      • Surname: compare, read, inherit

    • Entry Rights: browse, inherit

  • The IP address of one or more eDirectory servers that contain a replica of the partition holding the user objects and that run NLDAP.

  • The context of the users in eDirectory.

4.1.3 Understanding LDAP Advanced Options

The connector for Active Directory and the connector for eDirectory contain predefined behaviors for importing, matching, and provisioning users. You can override the default behavior of the connectors for LDAP identity sources through the Advanced Options for the connectors in the administration console. For example, if you have a large number of users or groups and you want to import only a subset of those users and groups, you can use the Advanced Options to filter them to a set of users and groups you want imported.

By default, CloudAccess uses an internal unique attribute to match users and to provision users to the connected systems. For more information about provisioning, see Troubleshooting Provisioning Issues.

NOTE:The connectors for the LDAP identity sources change all of the keys and values in the filter fields to lowercase. It is best to use a case-ignore attribute.

Identity source search polling rate every: Select how often you want the connector for the LDAP directory to poll the LDAP identity source for changes. By default, the rate is every minute.

Filter extension: Specify a filter for the object class and attribute you want to use to import users. If users do not meet the criteria defined in the filter, CloudAccess does not import those users.

For example, (&(objectclass=user)(samaccountname=abc*)) imports only users that start with the samaccountname of abc*.

Identity source LDAP attribute to use for imported accounts: Specify the LDAP attribute that the connector uses as the naming attribute (login name) when importing accounts from the identity source.

Allow unmapped users to authenticate: Select whether to allow users to authenticate that have not been imported to CloudAccess, because they have been excluded by the filter extension. The unmapped users must use an email address to log in. These users can still log in to the User portal page, but will see only public appmarks.

Override default group filter: Select whether to override the default group filter so you can limit which groups the connector for the LDAP identity source imports to CloudAccess. If you select this option, you must specify a correct filter.

For example, (&(objectclass=group)(cn=custom*)) allows only groups with a CN that start with custom*.

NOTE:When you configure a filter extension for an eDirectory identity source, user objects in the external eDirectory identity store that do not match the filter are not imported into CloudAccess. If you also enable the option Allow unmapped users to authenticate, unmapped users can use Basic SSO type connectors, but they cannot store or play back their credentials for single sign-on later because their user objects do not actually exist in CloudAccess.

Attribute mappings: Click Default to view the default mappings that CloudAccess makes between the identity sources and the connected systems. The attributes on the left are the attributes for CloudAccess. The attributes on the right are for the LDAP directory.

(Optional) Above the default attributes, you can map five attributes to five custom attributes in CloudAccess. To map the LDAP directory attribute, specify the attribute name in the field next to the custom attribute, then click OK and Apply to save the changes.

NOTE:Similar to the CN attribute that must be unique for each user, if you configure custom attribute matching, the value of each custom attribute must also be unique.

Relaxed user matching: By default, CloudAccess matches users using an internal unique ID. This option changes the appliance to match users by the CN or sAMAccountName attributes.

Use this option when you want to recreate previously deleted users so CloudAccess can manage the users again. However, ensure that you do not create different users with the same CN or sAMAccountName as previously deleted users. Otherwise, those users will have access to the previously deleted users’ cloud application data.