When you set up an organization, you configure the organization properties, sub-organizations, additional organizations, licenses, runtime environments, and user accounts.
To set up your company's organization, perform the following steps:
1Configure organization properties such as the organization name and address, authentication information, and notification email addresses.
2Verify that your organization has the appropriate licenses.
3Optionally, create one or more sub-organizations and configure licenses for the sub-organizations.
4Optionally, create additional production organizations and sandbox organizations.
5Configure runtime environments and Secure Agents.
6Set up users, user groups, and roles.
You might also need to download and install non-native connectors for your organization. For example, if users in your organization create tasks that read data from Teradata tables, you need to download and install the add-on connector for Teradata. For more information about downloading and installing add-on connectors, see Connections.
Authentication properties
You can configure authentication properties for your organization and sub-organizations. Authentication properties control password restrictions and IP address filtering.
Password restrictions are enforced when users create or change their passwords. If you change the password expiration date from "never" to a number of days, then users with passwords that are older than the number of days will be required to change their passwords the next time that they log in to IDMC.
The following table describes the authentication properties:
Property
Description
Minimum Password Length
Minimum password length required for a valid password. Must be a number between 4 and 12 characters.
Minimum Character Mix
Minimum number of character types required for a valid password.
Passwords can contain a mix of the following character sets:
- Lowercase alphabetic characters
- Uppercase alphabetic characters
- Numeric characters
- Special characters
For example, if you set Minimum Character Mix to 1, then passwords must contain at least one of the character sets. If you set Minimum Character Mix to 2, then passwords must contain at least two of the character sets.
Password Reuse
Controls whether users can reuse passwords.
Password Expires
Determines how often users must reset their passwords.
Enable Multi-Factor Authentication
Enables multi-factor authentication for native human users.
When multi-factor authentication is enabled, native human users receive a verification code through email when they log in to the user interface. The email address for each human user must be valid.
Categorize users as human or non-human users on the Users page. For more information, see User Administration.
Session Idle Timeout
Amount of time before a user's session times out due to inactivity. IDMC displays a warning message to the user 60 seconds before the user is logged out.
Default is 30 minutes.
Authentication Type
Authentication type used after a user logs in. Default is JSON Web Token (JWT).
For JWT authentication, select a duration for tokens to expire. Default is 30 minutes.
When you change the authentication type, the new type takes effect at the next login. The change doesn't affect sessions that are in progress.
Before you use the JWT authentication type, modify custom scripts to refresh the tokens before they expire.
For more information, see the JWT Support Knowledge article.
Note: Don't use the JWT authentication type if your organization uses API Manager or the REST V2 Connector.
Use Trusted IP Ranges
Enables IP address filtering.
IP address filtering uses trusted IP address ranges in addition to account passwords to prevent unauthorized users from accessing your organization. When you enable IP address filtering, a user with a valid login must also have an IP address within the range of trusted IP addresses, or the user can't log in to your organization.
When you enable this option, you must also enter one or more trusted IP address ranges.
Note: If you create a serverless runtime environment when trusted IP ranges are enabled, you must add the IP addresses of the DMZ NAT gateway to the list of trusted IP addresses. For a list of the DMZ NAT gateway addresses, see Runtime Environments.
Allowed Trusted IP Ranges
The trusted ranges of IP addresses from which users can log in to access the organization. IDMC supports IP address formats in IP version 4 (IPv4) and version 6 (IPv6).
Fields for the trusted IP address range appear when you enable IP address filtering. To enter additional address ranges, click +.
To ensure seamless communication between resources across both IPv4 and IPv6 networks, enable a dual stack configuration. For example, if your virtual machine uses one network type, IPv4 or IPv6, and the servers that host the connectors use another network type, enable dual stack on your virtual machine to ensure seamless communication regardless of their network type.
Note: If you enter an invalid IP address range, users cannot access your organization. Contact your network administrator for valid IP address ranges.
Fingerprint authentication properties
You can enforce a fingerprint authentication every time the Secure Agent starts. An authentication failure can trigger an email alert but allow normal operations, or it can disallow agent startup.
To set the authentication mode, configure the options in Fingerprint Authentication on the Organization page.
You can configure these levels of authentication enforcement:
No enforcement, no notifications
Disable fingerprint enforcement and don't specify an email address.
No authentication check is performed when the Secure Agent starts up. This is the default.
Report violations only
Disable fingerprint enforcement and specify an email address. The email format is checked, but the validity of the email address isn't verified. Be sure to allow emails from the address "admin@informaticacloud.com".
An authentication check is performed during Secure Agent start up. Any fingerprint mismatch triggers a notification to the email recipient, but the agent starts up normally.
Enforce authentication match
Set fingerprint enforcement to On and specify an email address. The email format is checked, but the validity of the email address isn't verified. Be sure to allow emails from the address "admin@informaticacloud.com".
Any fingerprint mismatch triggers a notification to the email recipient and the Secure Agent log in is prevented from starting up.
Note: An email address is required if enforcement is turned on.
A fingerprint is created the first time a Secure Agent starts up, using device attributes from the agent's host machine. The data is anonymized and hashed to produce a unique fingerprint. When switching from no enforcement to any other level of enforcement, the Secure Agent generates a fingerprint the first time it starts up.
If you reinstall the Secure Agent on the same machine, the fingerprint doesn't change.
The following table summarizes what happens when fingerprint enforcement prevents the Secure Agent from starting up:
Action
Message
Error is logged to agentcore.log
"Internal error. Agent <Secure Agent ID> fingerprint is not matching with the previous stored value for request <Request ID>."
Email notification is sent (if an email address was specified)
"There was a fingerprint mismatch while logging in agent with name <Secure Agent name> for Organization <Organization ID>. The agent was last active on <Date in UTC>."
Connection Credentials storage location
You can configure where to store the connection properties for your organization and sub-organizations. To specify where to store the connection properties, configure the Connection Credentials on the Settings page in Administrator.
You can store connection properties in either of the following locations:
Informatica Cloud
When you store connection properties on the cloud, the connection properties are stored in the IDMC repository and are always available. The connections are encrypted by the IDMC key management service.
IDMC backs up connection properties regularly as part of standard backup procedures.
Local Secure Agent
You might store connection properties with a local Secure Agent if you need the connection properties to reside within your firewall. When you enable this option, the properties for all connections that are listed on the Connections page are stored with the local agent.
Note: In organizations subject to FedRAMP, you can't store connection properties with a local Secure Agent.
If you choose this option, you can store connection properties with one Secure Agent. Connection properties are stored in the following directory:
When you store properties with a local Secure Agent, the Secure Agent must be running so that tasks can run and users can work with connections. Back up connection properties regularly to prevent loss of data. A best practice is to back up connection properties after you change the location or the encryption key for connection properties.
The connections are encrypted by the IDMC key management service. IDMC uses CBC (Cipher Block Chaining) mode 256 AES encryption to store the connections.
If you use an external secrets manager like AWS Secrets Manager or Azure Key Vault to store sensitive connection credentials, you need to set the connection credential storage to Informatica Cloud. When you do this, sensitive credentials are retrieved from the secrets manager and other connection properties are stored in the IDMC repository. You can't use a secrets manager if you store connection credentials on a local Secure Agent. For more information about secrets manager configuration, see Secrets manager.
You can change where you want to store connection properties. When you do this, IDMC moves the connection properties to the appropriate location. For example, your license expires, so you configure the organization to store connections on the cloud. IDMC moves the connection properties from the local Secure Agent to IDMC.
Enterprise Data Catalog integration properties
If your organization uses data catalog discovery in Data Integration, you can configure Enterprise Data Catalog integration properties for your organization and sub-organizations. Configure Enterprise Data Catalog integration properties so that users can use catalog assets in mappings, synchronization tasks, and file ingestion and replication tasks.
The Enterprise Data Catalog integration properties that you configure for the organization apply to the data catalog searches that all users in the organization perform. If your organization includes sub-organizations, you can configure different Enterprise Data Catalog integration properties for the parent organization and for each sub-organization.
The following table describes the Enterprise Data Catalog integration properties:
Property
Description
Catalog URL
URL of the Enterprise Data Catalog Service. Use the following format:
http://<fully qualified host name>:<port>
Do not append /ldmcatalog at the end of the URL.
Runtime environment
Name of the Secure Agent group that is used to read data from Enterprise Data Catalog.
The agents in the group that you select must be able to communicate with Enterprise Data Catalog. Therefore, the Enterprise Data Catalog host must be in the same network as the agent machines or it must have the appropriate ports open for communication.
User name
Enterprise Data Catalog user account that the Secure Agent uses to access Enterprise Data Catalog.
This user account must have privileges to view and search for objects in Enterprise Data Catalog and to perform functions using the Enterprise Data Catalog REST API.
Password
Password for the Enterprise Data Catalog user account.
Show the data catalog
Shows and hides the Data Catalog page in Data Integration.
Data Integration service properties
Data Integration service properties are used by Data Integration. Configure these properties to set the time zone and default email addresses for job notifications.
You can set the following Data Integration service properties:
Jobs properties
The following table describes the jobs properties:
Property
Description
Schedule Offset
A small amount of time that is added to schedule start times to help prevent server overload at standard schedule start times. An organization has a single schedule offset that is applied to all schedules. The schedule offset does not affect the start time of manually started tasks or taskflows. You cannot change the schedule offset.
Even though it is not displayed in the schedule details, the schedule offset for your organization is added to the time range configured for all schedules. This ensures that scheduled tasks run as often as expected. For example, you configure a schedule to run every hour from 8:00 a.m. to 12:00 p.m., and the schedule offset for your organization is 15 seconds. Your schedule runs at 8:00:15, 9:00:15, 10:00:15, 11:00:15, and 12:00:15.
Time Zone
Time zone used to display job execution time stamps in email notifications.
Default email notifications properties
Configure the default email notifications properties to set the default email addresses to use for job failure, warning, and success messages. Enter one or more valid email addresses. Separate email addresses with a comma (,) or semicolon (;).
You can also set email notification properties at the task level. When you set email notifications in a task or taskflow, IDMC sends email to the addresses in the task or taskflow instead of the addresses configured for the organization.