2.4 Identity Source Requirements

Use the information in the following sections to verify that your identity source meets all requirements before you deploy the appliance. For CloudAccess to provision user accounts to the SaaS applications, each user account in the identity source must contain the attributes listed.

IMPORTANT:The initial import of a large number of users (for example, 20,000 or more) from the identity source can take several hours, and the administration console does not currently provide a warning to administrators before beginning the process. During the user import process, the health status in the console might report the following warnings on and off: Driver seems unresponsive | Provisioning | bis_AD_a4uLn | Driver seems unresponsive.

If you have a large number of users in your environment, ensure that you allow several hours for the provisioning process to complete. After users are added, performance of other administration tasks in the console improves considerably.

2.4.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 name and password of a user in Active Directory who becomes the administrator of the appliance. The user must reside in the user search context specified during the appliance initialization procedure.

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

  • The context of the users in Active Directory.

2.4.2 eDirectory Requirements

Verify that your eDirectory environment meets the following requirements:

  • eDirectory 8.8 SP7 or eDirectory 8.8 SP6.

  • 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 name and password of a user in eDirectory who becomes the administrator of the appliance. The user must reside in the subtree of the search context for the identity source specified during the initialization of the appliance.

  • 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.

2.4.3 JDBC Requirements

To use the JDBC database as an identity source, you must know and understand JDBC databases. The information provided in this section is intended for database administrators.

Meeting the Requirements

Verify that you meet the following requirements or obtain the following information before using a JDBC database as an identity source:

  • The supported type of JDBC database. For more information, see Identity Source.

  • The IP address of the JDBC database.

  • The port for communication. The default port is 1433 for Microsoft SQL Server or 1521 for Oracle Database.

  • The database name or sid. (idm for Microsoft SQL Server defined as the sid in Oracle Database).

  • The script files must be installed before you can configure a JDBC database as an identity source. For more information, see Obtaining the Script Files.

  • The password for the user name in the sample scripts you install. For more information, see Obtaining the Script Files.

Obtaining the Script Files

To use JDBC as an identity source, you must install script files on your JDBC database so CloudAccess knows what tables to read to access the users and groups information. You download the script files when you configure the JDBC identity source.

You can download the files during the initialization process, if you select JDBC as your identity source, or you can download the scripts when you configure JDBC as an identity source after the appliance is initialized. You download a single zipped file that contains multiple scripts.

The different scripts are:

  • indirect_install: Installs the schema, which includes the indirect tablespace and proc_authuser () stored procedure, as well as the automatic triggers for the indirect.user and indirect.grp tables.

  • copy_from: Copies user account information from the database default user store into the indirect.usr table for processing by the connector for JDBC.

  • uninstall: Removes the schema and deletes or drops the connector user accounts in the underlying database.

Populating the Required Columns

To provision users from the JDBC databases to the SaaS applications, you must have the following columns populated for each user account in the JDBC database:

  • indirect.usr.idu

  • indirect.usr.username

  • indirect.usr.fname (Mandatory only for Google Apps accounts)

  • indirect.usr.lname

  • indirect.usr.email (Mandatory only for Salesforce accounts)

Dataflow Information

The connector for JDBC uses indirect tables to gather the needed information, ensuring that the appliance does not work directly with the information in the database. The following graphic depicts how the connector for JDBC obtains the information from the JDBC database. This process is the same regardless of the type of database to which the appliance connects.

Figure 2-1 Dataflow of User Information

The database administrator creates the user accounts or logs in to the user$ table. (The dataflow figures are based on the default Oracle security table user$.) The database administrator defines triggers or procedures that copy information into the indirect.usr table.

The indirect_install SQL script creates the automatic insert, update, or delete triggers on the indirect.usr table. When rows in the indirect.usr table are altered, the automatic triggers add a row to the indirect.indirect_process table.

The appliance polls the indirect.indirect_process table. When the appliance detects rows in the indirect.indirect_process table of type user, the appliance adds, modifies, or deletes the user account in the applications connected to the appliance.

The appliance then deletes the row from the indirect.indirect_process table after the appliance processes the information.

Figure 2-2 Dataflow of Group Information

The database administrator performs a direct or triggered insert of data into the indirect.grp table.

The indirect_install SQL script creates the automatic insert, update, or delete triggers on the indirect.grp table. When rows in indirect.grp are altered, the automatic triggers add a row to the indirect.indirect_process table.

When the appliance detects rows in the indirector.indirect_process table of type group, the appliance adds, modifies, or deletes the groups in the applications connected to the appliance. The appliance then deletes the row from the indirect.indirect_process table after the appliance processes the information.

Figure 2-3 Relationship between Users and Groups

The indirect schema does not have a direct concept of group membership, but maintains a relationship between the user idu column and the group idg column in the tables indirect.grp_member and indirect.usr_mbr_of tables.

For group membership, the desired group idg and user idu must exist in both tables. The indirect_install SQL script creates the automatic insert, update, or delete triggers on the indirect.grp_member and indirect.usr_mbr_of tables. When rows in these tables are altered, the automatic triggers add a row to the indirect.indirect_process table.

When the appliance detects rows in the indirect.indirect_process table for group membership, the appliance adds, modifies, or deletes the group memberships in the applications connected to the appliance. The appliance then deletes the row from the indirect.indirect_process table after the connector processes the information.For example, if the administrator wants to add a user with idu 6 to a group with idg 10, they would have to manually (or through triggers) add entries into both the grp_member and usr_mbr_of tables.

"INSERT INTO indirect.grp_member(idg,idu) VALUES(10,6); INSERT INTO indirect.usr_mbr_of(idu,idg) VALUES(6,10);”

Figure 2-4 Authentication Process

To verify authentication credentials, the appliance calls a stored procedure indirect.proc_authuser with the parameters of @username,@password. The procedure compares the username parameter with the default user table (user$) and the indirect.usr.username fields. If they matched, the process checks the indirect.usr.disabled flag (disabled > 0 = disabled). If login is enabled (disabled = 0), the process compares the password parameter to the existing password hash in the user$ table. If the password hash matches, then the process authenticates the user successfully. If any of these conditions are not met, then the process returns an SQLException to the appliance, and authentication fails.

You can alter the stored procedure based on the desired schema that the database administrator wishes to use for authentication. The administrator needs to keep in mind that the stored procedure indirect.proc_authuser(@username,@password) is hard-coded into the appliance, and expects either a success (1) or SQLException returned.

2.4.4 Requirements for Other Identity Sources

The CloudAccess appliance allows you to use additional identity sources after you deploy the appliance. However, these additional identity sources cannot be used during the initialization of the appliance.

Requirements for Self-Service User Store

The Self-Service User Store is an internal identity source you can use with the appliance. However, you can use this identity source only after you configure the appliance. The Self-Service User Store cannot be used during the initialization process of the appliance.

There are no specific requirements to use this service. For more information, see Section 4.2.1, Configuring Self-Service Registration and Password Management.

Requirements for SAML Federation Partner as Identity Source

You can create a custom connector that allows users to authenticate to the CloudAccess appliance through a SAML federated connection. To create this federation, you must create a custom SAML In connector.

For more information, see Creating a SAML 2.0 Inbound (SAML2 In) Connector Template in the NetIQ® CloudAccess Connectors Guide.