Informatica® 10.4.0
Security Guide Informatica Security Guide 10.4.0 December 2019 © Copyright Informatica LLC 2013, 2020 This software and documentation are provided only under a separate license agreement containing restrictions on use and disclosure. No part of this document may be reproduced or transmitted in any form, by any means (electronic, photocopying, recording or otherwise) without prior consent of Informatica LLC. U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation is subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License. Informatica, the Informatica logo, Informatica Cloud, PowerCenter, and PowerExchange are trademarks or registered trademarks of Informatica LLC in the United States and many jurisdictions throughout the world. A current list of Informatica trademarks is available on the web at https://www.informatica.com/trademarks.html. Other company and product names may be trade names or trademarks of their respective owners. Portions of this software and/or documentation are subject to copyright held by third parties. Required third party notices are included with the product. The information in this documentation is subject to change without notice. If you find any problems in this documentation, report them to us at [email protected]. Informatica products are warranted according to the terms and conditions of the agreements under which they are provided. INFORMATICA PROVIDES THE INFORMATION IN THIS DOCUMENT "AS IS" WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING WITHOUT ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND ANY WARRANTY OR CONDITION OF NON-INFRINGEMENT.
Publication Date: 2020-06-26 Table of Contents
Preface ...... 10 Informatica Resources...... 10 Informatica Network...... 10 Informatica Knowledge Base...... 10 Informatica Documentation...... 10 Informatica Product Availability Matrices...... 11 Informatica Velocity...... 11 Informatica Marketplace...... 11 Informatica Global Customer Support...... 11
Chapter 1: Introduction to Informatica Security...... 12 Overview of Informatica Security...... 12 Infrastructure Security...... 13 Authentication...... 13 Secure Domain Communication...... 14 Secure Data Storage...... 15 Operational Security...... 15 Domain Configuration Repository...... 15 Security Domain...... 16
Chapter 2: User Authentication...... 17 User Authentication Overview...... 17 Native User Authentication...... 18 LDAP User Authentication...... 18 Kerberos Authentication...... 19 SAML Authentication for Informatica Web Applications...... 19
Chapter 3: LDAP Authentication...... 20 Overview...... 20 LDAP Security Domains...... 20 User Account Synchronization...... 21 LDAP Directory Services...... 21 Azure Active Directory for Secure LDAP Authentication...... 22 Creating an LDAP Configuration...... 23 Create the LDAP Configuration and Configure the LDAP Server Connection...... 23 Configure the Security Domain...... 25 Configure the Synchronization Schedule...... 26 Using Nested Groups in the LDAP Directory Service...... 27 Using a Self-Signed SSL Certificate...... 28 Deleting an LDAP Configuration...... 28
Table of Contents 3 Chapter 4: Kerberos Authentication...... 29 Kerberos Overview...... 29 How Kerberos Works in an Informatica Domain...... 30 Kerberos Cross Realm Authentication...... 32 Converting a Domain From Kerberos Single Realm Authentication to Kerberos Cross Realm Authentication...... 32 Preparing to Enable Kerberos Authentication...... 33 Determine the Kerberos Service Principal Level...... 33 Configure the Kerberos Configuration File...... 34 Create Kerberos Principal Accounts in Active Directory...... 37 Generate the Service Principal Name and Keytab File Name Formats...... 38 Generate the Keytab Files...... 43 Enable Delegation for the Kerberos Principal User Accounts in Active Directory...... 47 Enabling Kerberos Authentication...... 48 Enable Kerberos Authentication in the Domain...... 49 Update the Nodes in the Domain...... 51 Enabling Kerberos on Informatica Nodes...... 52 Copy the Keytab Files to the Informatica Nodes...... 53 Enable Kerberos Authentication for Informatica Clients...... 54 Enabling User Accounts to Use Kerberos Authentication...... 55 Import User Accounts from Active Directory into LDAP Security Domains...... 55 Migrate Native User Privileges and Permissions to the Kerberos Security Domain...... 58
Chapter 5: SAML Authentication for Informatica Web Applications...... 60 SAML Authentication Overview...... 60 SAML Authentication Process...... 61 Enable SAML Authentication in a Domain...... 61 Create an LDAP Configuration for the Identity Provider or LDAP Store...... 62 Export the Assertion Signing Certificate...... 62 Import the Certificate into the Truststore Used for SAML Authentication...... 62 Configure the Identity Provider...... 63 Add Informatica Web Application URLs to the Identity Provider...... 63 Enable SAML Authentication in the Domain...... 63 Enable SAML Authentication on the Gateway Nodes...... 65 Configuring Web Applications to Use Different Identity Providers...... 67 Prepare to Use an Identity Provider...... 67 Configure Informatica Administrator to Use an Identity Provider...... 67 Configure an Informatica Web Application...... 69
Chapter 6: Domain Security...... 71 Domain Security Overview...... 71 Secure Communication Within the Domain...... 72
4 Table of Contents Secure Communication for Services and the Service Manager...... 72 Secure Domain Configuration Repository Database...... 78 Secure PowerCenter Repository Database...... 80 Secure Model Repository Database...... 80 Secure Communication for Workflows and Sessions...... 81 Secure Connections to a Web Application Service...... 82 Requirements for Secure Connections to Web Application Services...... 82 Enabling Secure Connections to the Administrator Tool...... 83 Informatica Web Application Services...... 83 Cipher Suites for the Informatica Domain...... 86 Create the Cipher Suite Lists...... 86 Configure the Informatica Domain with a New Effective List of Cipher Suites...... 87 Secure Sources and Targets...... 88 Data Integration Service Sources and Targets...... 88 PowerCenter Sources and Targets...... 89 Secure Data Storage...... 89 Secure Directory on UNIX...... 90 Changing the Encryption Key from the Command Line...... 90 Application Services and Ports...... 93
Chapter 7: Security Management in Informatica Administrator...... 96 Using Informatica Administrator Overview...... 96 User Security...... 97 Encryption...... 97 Authentication...... 97 Authorization...... 98 Security Tab...... 99 Using the Search Section...... 99 Using the Security Navigator...... 99 Groups...... 100 Users...... 100 Roles...... 101 Operating System Profiles...... 101 LDAP Configuration...... 102 Account Management...... 102 Audit Reports...... 102 Password Management...... 103 Changing Your Password...... 103 Domain Security Management...... 103 User Security Management...... 104
Chapter 8: Users and Groups...... 105 Users and Groups Overview...... 105
Table of Contents 5 Default Groups...... 106 Administrator Group...... 106 Everyone Group...... 106 Operator Group...... 106 Understanding User Accounts...... 107 Default Administrator...... 107 Domain Administrator...... 107 Application Client Administrator...... 108 User...... 108 Managing Users...... 109 Creating Native Users...... 109 Editing General Properties of Native Users...... 110 Assigning Native Users to Native Groups...... 110 Assigning LDAP Users to Native Groups...... 111 Enabling and Disabling User Accounts...... 111 Deleting Native Users...... 111 LDAP Users...... 112 Unlocking a User Account...... 112 Increasing System Memory for Many Users...... 112 Viewing User Activity...... 113 Managing Groups...... 117 Adding a Native Group...... 117 Editing Properties of a Native Group...... 118 Moving a Native Group to Another Native Group...... 118 Deleting a Native Group...... 118 LDAP Groups...... 118 Managing Operating System Profiles...... 118 Operating System Profile Properties for the PowerCenter Integration Service ...... 119 Operating System Profile Properties for the Data Integration Service...... 120 Operating System Profile Properties for the Metadata Access Service...... 122 Creating an Operating System Profile...... 122 Editing an Operating System Profile...... 123 Assigning a Default Operating System Profile to a User or Group...... 124 Deleting an Operating System Profile ...... 124 Working with Operating System Profiles in a Secure Domain...... 125 Working with Operating System Profiles in a Domain with Kerberos Authentication...... 125 Account Lockout...... 126 Configuring Account Lockout...... 126 Rules and Guidelines for Account Lockout...... 127
Chapter 9: Privileges and Roles...... 128 Privileges and Roles Overview...... 128 Privileges...... 128
6 Table of Contents Roles...... 129 Domain Privileges...... 130 Security Administration Privilege Group...... 130 Domain Administration Privilege Group...... 131 Monitoring Privilege Group...... 135 Tools Privilege Group...... 136 Cloud Administration Privilege Group...... 136 Analyst Service Privileges...... 137 Content Management Service Privileges...... 138 Data Integration Service Privileges...... 138 Metadata Manager Service Privileges...... 139 Catalog Privilege Group...... 139 Load Privilege Group...... 140 Model Privilege Group...... 141 Security Privilege Group...... 142 Model Repository Service Privileges...... 142 PowerCenter Repository Service Privileges...... 143 Tools Privilege Group...... 143 Folders Privilege Group...... 144 Design Objects Privilege Group...... 146 Sources and Targets Privilege Group...... 148 Run-time Objects Privilege Group...... 150 Global Objects Privilege Group...... 154 PowerExchange Listener Service Privileges...... 156 PowerExchange Logger Service Privileges...... 157 Scheduler Service Privileges...... 158 Test Data Manager Service Privileges...... 158 Administration Privilege Group...... 159 Connections Privilege Group...... 159 Data Domains Privilege Group...... 159 Data Masking Privilege Group...... 160 Data Subset Privilege Group...... 160 Policies Privilege Group...... 160 Projects Privilege Group...... 161 Rules Privilege Group...... 161 Data Generation Privilege Group...... 161 Managing Roles...... 161 System-Defined Roles...... 162 Custom Roles...... 163 Assigning Privileges and Roles to Users and Groups...... 165 Inherited Privileges...... 165 Assigning Privileges and Roles to a User or Group by Navigation...... 165
Table of Contents 7 Viewing Users with Privileges for a Service...... 166 Troubleshooting Privileges and Roles...... 166
Chapter 10: Permissions...... 169 Permissions Overview...... 169 Types of Permissions...... 170 Permission Search Filters...... 171 Domain Object Permissions...... 171 Permissions by Domain Object...... 172 Permissions by User or Group...... 173 Operating System Profile Permissions...... 174 Connection Permissions...... 175 Types of Connection Permissions...... 176 Default Connection Permissions...... 176 Assigning Permissions on a Connection...... 176 Viewing Permission Details on a Connection...... 177 Editing Permissions on a Connection...... 177 Cluster Configuration Permissions...... 178 Application and Application Object Permissions...... 178 Types of Application and Application Object Permissions...... 178 Assigning Permissions on an Application or Application Object...... 178 Viewing Permission Details on an Application or Application Object...... 179 Editing Permissions on an Application or Application Object...... 179 Denying Permissions on an Application or Application Object...... 180 SQL Data Service Permissions...... 180 Types of SQL Data Service Permissions...... 180 Assigning Permissions on an SQL Data Service...... 181 Viewing Permission Details on an SQL Data Service...... 181 Editing Permissions on an SQL Data Service...... 182 Denying Permissions on an SQL Data Service...... 182 Column Level Security...... 183 Web Service Permissions...... 184 Types of Web Service Permissions...... 184 Assigning Permissions on a Web Service...... 185 Viewing Permission Details on a Web Service...... 186 Editing Permissions on a Web Service...... 186
Chapter 11: Audit Reports...... 187 Audit Reports Overview...... 187 User Personal Information...... 188 User Group Association...... 188 Privileges...... 189 Roles Association...... 190
8 Table of Contents Domain Object Permission...... 190 Selecting Users for an Audit Report...... 191 Selecting Groups for an Audit Report ...... 191 Selecting Roles for an Audit Report...... 192
Appendix A: Command Line Privileges and Permissions...... 193 infacmd as Commands...... 193 infacmd cluster Commands...... 194 infacmd dis Commands...... 195 infacmd dp Commands...... 196 infacmd es commands...... 196 infacmd ipc Commands...... 197 infacmd isp Commands...... 197 infacmd mas Commands...... 206 infacmd mrs Commands...... 207 infacmd ms Commands...... 209 infacmd tools Commands...... 209 infacmd ps Commands...... 210 infacmd pwx Commands...... 210 infacmd rms Commands...... 211 infacmd rtm Commands...... 212 infacmd sch commands...... 212 infacmd sql Commands...... 213 infacmd wfs Commands...... 214 pmcmd Commands...... 214 pmrep Commands...... 217
Appendix B: Custom Roles...... 222 Analyst Service Custom Role...... 222 Metadata Manager Service Custom Roles...... 223 Operator Custom Role...... 224 PowerCenter Repository Service Custom Roles...... 225 Test Data Manager Custom Roles...... 226
Appendix C: Default List of Cipher Suites...... 230
Index...... 232
Table of Contents 9 Preface
Use the Informatica Security Guide to learn how to enable security in an Informatica domain. Understand how to configure and manage various authentication protocols, including Lightweight Directory Access Protocol, Kerberos, and Security Assertion Markup Language. Learn how to manage users and groups, and how to use permissions, privileges, and roles to manage user security.
Informatica Resources
Informatica provides you with a range of product resources through the Informatica Network and other online portals. Use the resources to get the most from your Informatica products and solutions and to learn from other Informatica users and subject matter experts.
Informatica Network
The Informatica Network is the gateway to many resources, including the Informatica Knowledge Base and Informatica Global Customer Support. To enter the Informatica Network, visit https://network.informatica.com.
As an Informatica Network member, you have the following options:
• Search the Knowledge Base for product resources.
• View product availability information.
• Create and review your support cases.
• Find your local Informatica User Group Network and collaborate with your peers.
Informatica Knowledge Base
Use the Informatica Knowledge Base to find product resources such as how-to articles, best practices, video tutorials, and answers to frequently asked questions.
To search the Knowledge Base, visit https://search.informatica.com. If you have questions, comments, or ideas about the Knowledge Base, contact the Informatica Knowledge Base team at [email protected].
Informatica Documentation
Use the Informatica Documentation Portal to explore an extensive library of documentation for current and recent product releases. To explore the Documentation Portal, visit https://docs.informatica.com.
10 If you have questions, comments, or ideas about the product documentation, contact the Informatica Documentation team at [email protected].
Informatica Product Availability Matrices
Product Availability Matrices (PAMs) indicate the versions of the operating systems, databases, and types of data sources and targets that a product release supports. You can browse the Informatica PAMs at https://network.informatica.com/community/informatica-network/product-availability-matrices.
Informatica Velocity
Informatica Velocity is a collection of tips and best practices developed by Informatica Professional Services and based on real-world experiences from hundreds of data management projects. Informatica Velocity represents the collective knowledge of Informatica consultants who work with organizations around the world to plan, develop, deploy, and maintain successful data management solutions.
You can find Informatica Velocity resources at http://velocity.informatica.com. If you have questions, comments, or ideas about Informatica Velocity, contact Informatica Professional Services at [email protected].
Informatica Marketplace
The Informatica Marketplace is a forum where you can find solutions that extend and enhance your Informatica implementations. Leverage any of the hundreds of solutions from Informatica developers and partners on the Marketplace to improve your productivity and speed up time to implementation on your projects. You can find the Informatica Marketplace at https://marketplace.informatica.com.
Informatica Global Customer Support
You can contact a Global Support Center by telephone or through the Informatica Network.
To find your local Informatica Global Customer Support telephone number, visit the Informatica website at the following link: https://www.informatica.com/services-and-training/customer-success-services/contact-us.html.
To find online support resources on the Informatica Network, visit https://network.informatica.com and select the eSupport option.
About the Security Guide 11 C h a p t e r 1
Introduction to Informatica Security
This chapter includes the following topics:
• Overview of Informatica Security, 12
• Infrastructure Security, 13
• Operational Security, 15
• Domain Configuration Repository, 15
• Security Domain, 16
Overview of Informatica Security
You can secure the Informatica domain to protect from threats from inside and outside the network on which the domain runs.
Security for the Informatica domain includes the following types of security: Infrastructure Security Infrastructure security protects the Informatica domain against unauthorized access to or modification of services and resources in the Informatica domain. Infrastructure security includes the following aspects:
• Protection of data transmitted and stored within the Informatica domain
• Authentication of users and services connecting to the Informatica domain
• Security of connections for external components, including client applications and relational databases for repositories, sources, and targets.
Operational Security Operational security controls access to the data and services in the Informatica domain. Operational security includes the following aspects:
• Setting restrictions to user access to data and metadata based on the role of the user in the organization
• Setting restrictions to user ability to perform operations within the Informatica domain based on the user role in the organization
12 Informatica stores the domain configuration information and the list of users authorized to access the domain in the domain configuration repository. The domain configuration repository also contains the groups, roles, privileges, and permissions that are assigned to each user in the Informatica domain.
Informatica organizes the list of users by security domains. A security domain contains a collection of user accounts. A domain can have multiple security domains.
Infrastructure Security
Infrastructure security includes user and service authentication, secure communication within the domain, and secure data storage.
Authentication
The Service Manager authenticates the services that run in the domain and the users who log in to the Informatica client tools.
You can configure the Informatica domain to use the following types of authentication: Native Authentication Native authentication is a mode of authentication available only for user accounts in the Informatica domain. When the Informatica domain uses native authentication, the Service Manager stores user credentials and privileges in the domain configuration repository and performs all user authentication within the Informatica domain.
If the Informatica domain uses native authentication, by default, the domain has a Native security domain and all user accounts belong to the Native security domain.
Informatica uses user name and passwords to authenticate users and services in the Informatica domain. Lightweight Directory Access Protocol (LDAP) Authentication LDAP is a software protocol for accessing users and resources on a network. If the Informatica domain uses LDAP authentication, the user accounts and credentials are stored in the LDAP directory service. The user privileges and permissions are stored in the domain configuration repository. You must periodically synchronize the user accounts in the domain configuration repository with the user accounts in the LDAP directory service. Informatica uses user name and passwords to authenticate informatica users and services in the Informatica domain. Kerberos Authentication Kerberos is a network authentication protocol which uses tickets to authenticate users and services in a network. When the Informatica domain uses Kerberos authentication, the user accounts and credentials are stored in the Kerberos principal database, which can be an LDAP directory service. The user privileges and permissions are stored in the domain configuration repository. You must periodically synchronize the user accounts in the domain configuration repository with the user accounts in the Kerberos principal database. Informatica uses the Kerberos tickets to authenticate Informatica users and services in the Informatica domain.
Infrastructure Security 13 SAML-based Single Sign-on
Security Assertion Markup Language (SAML) is an XML-based data format for exchanging authentication and authorization information between a service provider and an identity provider. You can configure SAML-based single sign-on for the Administrator tool, the Analyst tool, and the Monitoring tool web applications.
In an Informatica domain, the Informatica web application is the service provider, and Microsoft Active Directory Federation Services (AD FS) is the identity provider. The accounts and credentials for Informatica web application users are stored in Microsoft Active Directory. You import accounts from Active Directory into a security domain within the Informatica domain. You must periodically synchronize the user accounts in the security domain with the user accounts in the Active Directory directory service.
Note that you cannot enable SAML-based single sign-on in an Informatica domain configured to use Kerberos authentication.
Secure Domain Communication
The Informatica domain has various options to secure the data and metadata that are transmitted between the Service Manager and services in the domain and the client applications. Informatica uses the TCP/IP and HTTP protocols to communicate between components in the domain and uses SSL certificates to secure the communication between services and the Service Manager in the domain.
The SSL/TLS protocol uses public key cryptography to encrypt and decrypt network traffic. The public key used to encrypt and decrypt traffic is stored in an SSL certificate that can be self-signed or signed. A self- signed certificate is signed by the creator of the certificate. Because the identity of the signer is not verified, a self-signed certificate is less secure than a signed certificate. A signed certificate is an SSL certificate that has the identity of the person who requested the certificate verified by a certificate authority (CA). Informatica recommends CA signed certificates for a higher level of security.
A keystore contains private keys and certificates. It is used to provide a credential. A truststore contains the certificate of trusted SSL/TLS servers. It is used to verify a credential.
To secure connections in the domain, Informatica requires keystores and truststores in PEM and JKS formats. You can use the following programs to create the required files: keytool You can use the Java keytool key and certificate management utility to create an SSL certificate or a certificate signing request (CSR) as well as keystores and truststores in JKS format. The keytool utility is available in the following directory on domain nodes:
The type of connection that you secure determines the files required.
14 Chapter 1: Introduction to Informatica Security Secure Data Storage
Informatica encrypts sensitive data, such as passwords and secure connection parameters, before it stores the data in the domain configuration repository. Informatica also saves sensitive files, such as configuration files, in a secure directory.
Operational Security
You can assign privileges, roles, and permissions to users or groups of users to manage the level of access users and groups can have and the scope of the actions that users and groups can perform in the domain.
You can use the following methods to manage user and group access in the domain:
Privileges Privileges determine the actions that users can perform in the Informatica client tools. You can assign a set of privileges to a user to restrict access to the services available in the domain. You can also assign privileges to a group to allow all users in the group the same access to services. Roles A role is a set of privileges that you can assign to users or groups. You can use roles to more easily manage assignments of privileges to users. You can create a role with limited privileges and assign it to users and groups that have restricted access to domain services. Or you can create roles with related privileges to assign to users and groups that require the same level of access. Permissions Permissions define the level of access that users have to an object. A user who has the privilege to perform a certain action might require permission to perform the action on a particular object. For example, to manage an application service, a user must have the privilege to manage services and permission on the specific application service. Default Administrator Group The Informatica domain has a system-defined Administrator group that includes all privileges and permissions for a service. Any user account that you add to the Administrator group has privileges and permissions on all services and objects in the domain. When you install Informatica services, the installer creates a user account that belongs to the Administrator group. You can use the default Administrator account to initially log in to the Administrator tool.
Domain Configuration Repository
The domain configuration repository contains information about the domain configuration and user privileges and permissions.
If the Informatica domain uses native user authentication, the domain configuration repository also contains the user credentials. If the domain uses LDAP or Kerberos authentication, the domain configuration repository does not contain the user credentials. All LDAP and Kerberos user credentials are stored outside the Informatica domain, in the LDAP directory service or Kerberos principal database.
Operational Security 15 When you create the Informatica domain during installation, the installer creates a domain configuration repository in a relational database. You must specify the database in which to create the domain configuration repository. You can create the repository on a database secured with the SSL protocol.
Security Domain
A security domain is a collection of user accounts and groups in the Informatica domain.
The Informatica domain can have the following types of security domains: Native Security Domain The Native security domain contains the users and groups created and managed in the Administrator tool. Informatica stores all credentials for user accounts in the Native security domain in the domain configuration repository. By default, the Native security domain is created during installation. After installation, you cannot create additional Native security domains or delete the Native security domain.
If the Informatica domain uses Kerberos authentication, the domain does not use the Native security domain.
LDAP Security Domain An LDAP security domain contains users and groups imported from an LDAP directory service. If the Informatica domain uses LDAP or Kerberos authentication, you can create an LDAP security domain and add users and groups that you import from the LDAP directory service. When you install Informatica services and create a domain that uses native or LDAP authentication, the installer creates the Native security domain but does not create an LDAP security domain. You can create LDAP security domains after installation. When you install Informatica services and create a domain that uses Kerberos authentication, the installer creates the following LDAP security domains:
• Internal security domain. The installer creates an LDAP security domain with the name _infaInternalNamespace. The _infaInternalNamespace security domain contains the default administrator user account that you create during installation. After installation, you cannot add users to the _infaInternalNamespace security domain or delete the security domain.
• User realm security domain. The installer creates an empty LDAP security domain gives it the same name as the Kerberos user realm you specify during installation. After installation, you can import users from the Kerberos principal database into the user realm security domain. You cannot delete the user realm security domain. When you run command line programs in a domain that uses Kerberos authentication, the security domain option defaults to the user realm security domain created during installation. You create and manage LDAP security domains the same way, whether the Informatica domain uses LDAP authentication or Kerberos authentication.
16 Chapter 1: Introduction to Informatica Security C h a p t e r 2
User Authentication
This chapter includes the following topics:
• User Authentication Overview, 17
• Native User Authentication, 18
• LDAP User Authentication, 18
• Kerberos Authentication, 19
• SAML Authentication for Informatica Web Applications, 19
User Authentication Overview
User authentication in the Informatica domain depends on the type of authentication that you configure when you install the Informatica services.
The Informatica domain can use the following types of authentication to authenticate users in the Informatica domain:
• Native user authentication
• LDAP user authentication
• Kerberos network authentication
• Security Assertion Markup Language (SAML)-based single sign-on
Native user accounts are stored in the Informatica domain and can only be used within the Informatica domain.
LDAP and Kerberos and user accounts are stored in an LDAP directory service and are shared by applications within the enterprise.
SAML-based single sign-on authenticates users against account credentials stored in Microsoft Active Directory. Accounts are imported from Active Directory into a security domain within the Informatica domain.
You can select the type of authentication to use in the Informatica domain during installation. If you enable Kerberos authentication during installation, you must configure the Informatica domain to work with the Kerberos key distribution center (KDC). You must create the service principal names (SPN) required by the Informatica domain in the Kerberos principal database. The Kerberos principal database can be an LDAP directory service. You must also create keytab files for the SPNs and store it in the Informatica directory as required by the Informatica domain.
If you do not enable Kerberos authentication during installation, the installer configures the Informatica domain to use native authentication. After installation, you can set up a connection to an LDAP server and configure the Informatica domain to use LDAP authentication in addition to native authentication.
17 You can use native authentication and LDAP authentication together in the Informatica domain. The Service Manager authenticates the users based on the security domain. If a user belongs to the native security domain, the Service Manager authenticates the user in the domain configuration repository. If the user belongs to an LDAP security domain, the Service Manager passes the user name and password to the LDAP server for authentication.
You cannot use native authentication with Kerberos authentication. If the Informatica domain uses Kerberos authentication, all user accounts must be in LDAP security domains. The Kerberos server authenticates a user account when the user logs in to the network. The Informatica client applications use the credentials from the network login to authenticate users in the Informatica domain. Native groups and roles are still supported.
You can enable SAML-based single sign-on for Informatica web applications during installation, or after installation. However you must complete all required set up tasks before enabling SAML-based single sign- on. You cannot enable SAML-based single sign-on in an Informatica domain configured to use Kerberos authentication.
Native User Authentication
If the Informatica domain uses native authentication, the Service Manager stores all user account information and performs all user authentication within the Informatica domain. When a user logs in, the Service Manager uses the native security domain to authenticate the user name and password.
If you do not configure the Informatica domain to use Kerberos network authentication, the Informatica domain contains a native security domain by default. The native security domain is created at installation and cannot be deleted. An Informatica domain can have only one native security domain. You create and maintain user accounts in the native security domain in the Administrator tool. The Service Manager stores details about the user accounts, including the user credentials and privileges, in the domain configuration repository.
LDAP User Authentication
You can configure an Informatica domain to enable users in an LDAP directory service to log in to Informatica client applications. You can create multiple LDAP configurations for a domain, each connecting to a different LDAP server. A domain can use LDAP user authentication in addition to native user authentication.
To enable the Informatica domain to use LDAP user authentication, you must set up a connection to an LDAP server and specify the users and groups from the LDAP directory service that can have access to the Informatica domain. You can use the Administrator tool to set up the connection to the LDAP server.
When you synchronize the LDAP security domains with the LDAP directory service, the Service Manager imports the list of LDAP user accounts with access to the Informatica domain into the LDAP security domains. When you assign privileges and permissions to users in LDAP security domains, the Service Manager stores the information in the domain configuration repository. The Service Manager does not store the user credentials in the domain configuration repository.
When a user logs in, the Service Manager passes the user name and password to the LDAP server for authentication.
Note: The Service Manager requires that LDAP users log in to a client application with a password even though an LDAP directory service may allow a blank password for anonymous login mode.
18 Chapter 2: User Authentication Kerberos Authentication
You can configure the Informatica domain to use Kerberos network authentication to authenticate users and services on a network.
Kerberos is a network authentication protocol which uses tickets to authenticate access to services and nodes in a network. Kerberos uses a Key Distribution Center (KDC) to validate the identities of users and services and to grant tickets to authenticated user and service accounts. In the Kerberos protocol, users and services are known as principals. The KDC has a database of principals and their associated secret keys that are used as proof of identity. Kerberos can use an LDAP directory service as a principal database.
To use Kerberos authentication, you must install and run the Informatica domain on a network that uses Kerberos network authentication. Informatica can run on a network that uses Kerberos authentication with Microsoft Active Directory service as the principal database.
You can configure an Informatica domain to use Kerberos cross realm authentication. Kerberos cross realm authentication enables Informatica clients that belong to one Kerberos realm to authenticate with nodes and application services that belong to another Kerberos realm.
The Informatica domain requires keytab files to authenticate nodes and services in the domain without transmitting passwords over the network. The keytab files contain the service principal names (SPN) and associated encrypted keys. Create the keytab files before you create nodes and services in the Informatica domain.
SAML Authentication for Informatica Web Applications
You can configure an Informatica domain to allow users to use Security Assertion Markup Language (SAML) authentication to log into the Administrator tool, the Analyst tool, Metadata Manager, and the Monitoring tool web applications.
Security Assertion Markup Language is an XML-based data format for exchanging authentication and authorization information between a service provider and an identity provider. In an Informatica domain, the Informatica web application is the service provider. Microsoft Active Directory Federation Services (AD FS) is the identity provider, which authenticates web application users with your organization's Active Directory identity store.
To enable the Informatica domain to use SAML-based single sign-on, you must create an LDAP security domain for Informatica web application user accounts, and then import the users into the domain from Active Directory. You can use the Administrator tool to set up the connection to the Active Directory server, and then import users into the security domain.
When a user logs into an Informatica web application, the application sends a SAML authentication request to AD FS. AD FS authenticates the user's credentials against the user account information in Active Directory, and then returns a SAML assertion token containing security-related information about the user to the web application.
You configure AD FS to issue SAML tokens used to authenticate Informatica web application users. You must also export the Identity Provider Assertion Signing Certificate from AD FS, and then import the certificate into the Informatica default truststore file on each gateway node in the domain.
Kerberos Authentication 19 C h a p t e r 3
LDAP Authentication
This chapter includes the following topics:
• Overview, 20
• LDAP Security Domains, 20
• User Account Synchronization, 21
• LDAP Directory Services, 21
• Azure Active Directory for Secure LDAP Authentication, 22
• Creating an LDAP Configuration, 23
• Deleting an LDAP Configuration, 28
Overview
You can configure an Informatica domain to enable users imported from one or more LDAP directory services to log in to Informatica nodes, services, and application clients such as Informatica Developer and Informatica Analyst.
An LDAP directory service stores account user names and passwords. Using LDAP authentication enables you to consolidate the credentials for all of your Informatica users in a single identity store, simplifying the task of creating and updating account credentials.
You can use native authentication and LDAP authentication together in an Informatica domain. The Service Manager running on the master gateway node within the domain authenticates users based on the security domain the users belong to. If a user belongs to the default native security domain, the Service Manager authenticates the user against account information in the domain configuration repository. If the user belongs to an LDAP security domain, the Service Manager passes the user's credentials to the LDAP server for authentication.
LDAP Security Domains
An LDAP security domain contains users and groups imported from an LDAP directory service. You can define multiple LDAP security domains within an Informatica domain. You can then import accounts from LDAP directory services into the security domains.
You must create an LDAP security domain if you configure an Informatica domain to use Kerberos authentication. When you install Informatica services and enable Kerberos authentication, the Informatica
20 installer creates an LDAP security domain with the name of the Kerberos realm that you specify during installation.
When you create an LDAP security domain, you configure search bases and filters that define the set of LDAP user accounts and groups to include in the security domain. The Service Manager uses the security domain configuration to import or synchronize users and groups in the security domain with users and groups in the LDAP directory service.
The Service Manager uses the following criteria when it imports or synchronizes users and groups within an LDAP security domain:
• The Service Manager uses the user search bases and filters to import user accounts.
• The Service Manager uses the group search bases and filters to import groups.
• The Service Manager imports the groups that are included in the group filter and the user accounts that are included in the user filter.
User Account Synchronization
The Service Manager updates the security domain with the users and groups in an LDAP directory service on a scheduled basis. You can set up the synchronization schedule when you configure LDAP authentication.
The Service Manager performs the following steps during synchronization:
• Retrieves an updated list of users and groups from the LDAP directory service, based on the search base and filters you configured for the security domain.
• Updates the list of LDAP users and groups in the security domain. If an LDAP user in the security domain has been deleted in the LDAP directory service, the Service Manager transfers ownership of the user’s objects to the domain administrator account.
LDAP Directory Services
You can import user accounts into Informatica security domains from LDAP directory services.
You can import users from the following LDAP directory services:
• IBM Tivoli Directory Server
• Microsoft Active Directory
• Microsoft Azure Active Directory
• Novell eDirectory
• OpenLDAP
• Oracle Directory Server (ODSEE)
• Oracle Unified Directory (OUD)
• Sun Java System Directory Server
Note: If you use Kerberos authentication, you can import users only from Microsoft Active Directory.
User Account Synchronization 21 The Service Manager requires a particular unique ID (UID) to identify users in each LDAP directory service. The following table lists the default UID for each LDAP directory service:
LDAP Directory Service UID
IBM Tivoli Directory Server uid
Microsoft Active Directory sAMAccountName
Microsoft Azure Active Directory UserPrincipalName
Novell eDirectory uid
OpenLDAP uid
Oracle Directory Server (ODSEE) uid
Oracle Unified Directory (OUD) uid
Sun Java System Directory Server uid
Azure Active Directory for Secure LDAP Authentication
You can import users from Azure Active Directory (Azure AD) into an LDAP security domain.
Azure Active Directory Domain Services provide a secure LDAP public IP address that you use to import user accounts from Azure Active Directory into an LDAP security domain. Users you import can use their LDAP credentials to log in to Informatica nodes, services, and applications that run on virtual machines in an Azure Active Directory managed domain.
You must enable Secure Lightweight Directory Access Protocol (secure LDAP) authentication in Azure Active Directory Domain Services to authenticate Informatica users.
Complete the following steps to prepare to import user accounts from Azure Active Directory into an Informatica domain:
1. Verify that port 636, which is the Azure Active Directory secure LDAP port, is accessible through your firewall. 2. Enable secure LDAP authentication in Azure Active Directory Domain Services. You use the Azure portal to enable secure LDAP in Azure Active Directory Domain Services. For information about configuring secure LDAP in Azure Active Directory Domain Services, see the following link: https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-admin- guide-configure-secure-ldap 3. When you configure the secure LDAP certificate in Azure Active Directory Domain Services, ensure that the Subject name on the certificate is the Fully Qualified Domain Name (FQDN) of Azure Active Directory. 4. Convert the secure LDAP certificate from the PFX format to the PEM format. Java requires that the certificate is in the PEM format.
22 Chapter 3: LDAP Authentication 5. Import the certificates used by all domain nodes into the Java cacerts truststore file in the following directory on a single gateway node in the domain:
Creating an LDAP Configuration
You can create one or more LDAP configurations to enable user accounts and user groups that you import from LDAP directory services to authenticate with an Informatica domain.
You create and manage LDAP users and groups in the LDAP directory service. You set up a connection to the LDAP directory server and use search filters to specify the users and groups that you want to have access to the Informatica domain. You then import the user accounts into an LDAP security domain. If the LDAP server uses the SSL protocol, you must also specify the location of the SSL certificate.
After you import users into an LDAP security domain, you can assign roles, privileges, and permissions to the users. You can assign LDAP user accounts to native groups to organize the accounts based on their roles in the Informatica domain.
You cannot use the Administrator tool to create, edit, or delete users and groups in an LDAP security domain. You must make changes to LDAP users and groups in the LDAP directory service, and then synchronize the LDAP security domain with the LDAP directory service.
Use the LDAP Configuration dialog box to set up the connection to the LDAP directory service and create the LDAP security domain into which to import user accounts. You can also use the LDAP Configuration dialog box to set up a synchronization schedule.
To create an LDAP configuration, perform the following steps:
1. Configure the connection to the LDAP server that contains the directory service from which you want to import user accounts and groups. 2. Create an LDAP security domain for each set of user accounts and groups you want to import from the LDAP directory service. 3. Set up a schedule for the Service Manager to update the LDAP security domains with new or changed users and groups in the LDAP directory service.
Create the LDAP Configuration and Configure the LDAP Server Connection
Create the LDAP configuration and configure the connection to the LDAP server that contains the directory service from which you want to import the user accounts.
When you configure the connection to the LDAP server, indicate that the Service Manager must ignore the case sensitivity of the distinguished name attributes of the LDAP user accounts when it assigns users to groups in the Informatica domain. If the Service Manager does not ignore case sensitivity, the Service Manager might not assign all the users that belong to a group.
Creating an LDAP Configuration 23 If the LDAP server uses SSL, you must import the certificate used by each domain node into the cacerts truststore file on a gateway node domain. You then copy the cacerts file that contains the imported certificates to the same directory on every node in the domain. For more information, see “Using a Self- Signed SSL Certificate” on page 28.
To set up a connection to the LDAP directory service, perform the following tasks:
1. In the Administrator tool, click the Security tab. 2. Click the LDAP Configuration tab. 3. Click the Actions menu, and then and select Create LDAP Configuration. 4. In the Create LDAP Configuration dialog box, click the LDAP Connectivity tab. 5. Configure the connection properties for the LDAP server. You might need to consult the LDAP administrator to get the information needed to connect to the LDAP server. The following table describes the LDAP server configuration properties:
Property Description
LDAP Configuration Name of the LDAP configuration. Name
Server Name Host name or IP address of the machine hosting the LDAP directory service.
Port Listening port for the LDAP server. This is the port number to communicate with the LDAP directory service. Typically, the LDAP server port number is 389. If the LDAP server uses SSL, the LDAP server port number is 636. The maximum port number is 65535.
LDAP Directory Service Type of LDAP directory service. Note: If you use Kerberos authentication, you must select Microsoft Active Directory Service.
Name Distinguished name (DN) for the principal user. The user name often consists of a common name (CN), an organization (O), and a country (C). The principal user name is an administrative user with access to the directory. Specify a user that has permission to read other user entries in the LDAP directory service. To connect to Azure Active Directory, specify the User Principal Name (UPN) for the principal user.
Password Password for the principal user. Leave blank for anonymous log in.
Use SSL Certificate Indicates that the LDAP server uses the Secure Socket Layer (SSL) protocol.
Trust LDAP Certificate Determines whether the Service Manager can trust the SSL certificate of the LDAP server. If selected, the Service Manager connects to the LDAP server without verifying the SSL certificate. If not selected, the Service Manager verifies that the SSL certificate is signed by a certificate authority before connecting to the LDAP server.
Not Case Sensitive Indicates that the Service Manager must ignore case sensitivity for distinguished name attributes when assigning users to groups.
24 Chapter 3: LDAP Authentication Property Description
Group Membership Name of the attribute that contains group membership information for a user. This is Attribute the attribute in the LDAP group object that contains the DNs of the users or groups who are members of a group. For example, member or memberof.
Maximum Size Maximum number of user accounts to import into a security domain. For example, if the value is set to 100, you can import a maximum of 100 user accounts into the security domain. If the number of user to be imported exceeds the value for this property, the Service Manager generates an error message and does not import any user. Set this property to a higher value if you have many users to import. Default is 1000.
6. Click Test Connection to verify that the connection to the LDAP server is valid. 7. Click OK to save the LDAP configuration.
Configure the Security Domain
Create an LDAP security domain for each set of user accounts and groups you want to import from the LDAP directory service. Set up search bases and filters to define the set of user accounts and groups to include in a security domain.
The names of users and groups to be imported from the LDAP directory service must conform to the same rules as the names of native users and groups. The Service Manager does not import LDAP users or groups if names do not conform to the rules of native user and group names. Note that unlike native user names, LDAP user names can be case sensitive.
The Service Manager uses the user search bases and filters to import user accounts and the group search bases and filters to import groups. The Service Manager uses the filters to imports groups and the list of users that belong to each group.
If you modify the LDAP connection properties to connect to a different LDAP server, the Service Manager does not delete the existing security domains. You must ensure that the LDAP security domains are correct for the new LDAP server. Modify the user and group filters in the security domains or create additional security domains so that the Service Manager correctly imports the users and groups that you want to use in the Informatica domain.
To configure an LDAP security domain, perform the following steps:
1. In the Administrator tool, click the Security tab. 2. Click the Actions menu, and then select LDAP Configuration. 3. In the LDAP Configuration dialog box, click the Security Domains tab. 4. Click Add.
Creating an LDAP Configuration 25 The following table describes the filter properties that you can set for a security domain:
Property Description
Security Domain Name of the LDAP security domain. The name is not case sensitive and must be unique within the domain. The string cannot exceed 128 characters or contain the following special characters: , + / < > @ ; \ % ? The name can contain an ASCII space character except for the first and last character. All other space characters are not allowed.
User search base Distinguished name (DN) of the entry that serves as the starting point to search for user names in the LDAP directory service. The search finds an object in the directory according to the path in the distinguished name of the object. For example, in Microsoft Active Directory, the distinguished name of a user object might be cn=UserName,ou=OrganizationalUnit,dc=DomainName, where the series of relative distinguished names denoted by dc=DomainName identifies the DNS domain of the object.
User filter An LDAP query string that specifies the criteria for searching for users in the directory service. The filter can specify attribute types, assertion values, and matching criteria. For example: (objectclass=*) searches all objects. (&(objectClass=user)(! (cn=susan))) searches all user objects except “susan”. For more information about search filters, see the documentation for the LDAP directory service.
Group search base Distinguished name (DN) of the entry that serves as the starting point to search for group names in the LDAP directory service.
Group filter An LDAP query string that specifies the criteria for searching for groups in the directory service.
5. Click Preview to view a subset of the list of users and groups that fall within the filter parameters. If the preview does not display the correct set of users and groups, modify the user and group filters and search bases to get the correct users and groups. 6. To immediately synchronize the users and groups in the security domains with the users and groups in the LDAP directory service, click Synchronize Now. The Service Manager synchronizes the users in all the LDAP security domains with the users in the LDAP directory service. The time it takes for the synchronization process to complete depends on the number of users and groups to be imported. 7. Click OK to save the security domain.
Configure the Synchronization Schedule
You can set up a daily schedule for the Service Manager to update the LDAP security domains with new or changed users and groups in the LDAP directory service.
When the Service Manager synchronizes the LDAP security domains with the LDAP directory service, it imports all users that match the user filter settings from the LDAP directory service into the security domain. The Service Manager then imports all groups that match the group filter settings, and associates users with their corresponding groups. The Service Manager also deletes any user or group not found in the LDAP directory service from the security domain.
By default, the Service Manager is not scheduled time to synchronize with the LDAP directory service. To ensure that the list of users and groups in the LDAP security domains is accurate, schedule when the Service
26 Chapter 3: LDAP Authentication Manager synchronizes the LDAP security domains with the LDAP directory service. The Service Manager synchronizes the LDAP security domains with the LDAP directory service every day at the times you set.
To ensure that synchronization succeeds, consider the following recommendations before set up the synchronization schedule:
Verify that the /etc/hosts file contains an entry for the LDAP server.
Verify that the /etc/hosts file on each node gateway in the domain contains an entry with the host name and IP address of the LDAP server. If the Service Manager cannot resolve the host name for the LDAP server, synchronization can fail. Enable paging in LDAP if you are synchronizing more than 100 users or groups. Enable paging on the LDAP directory service before you synchronize more than 100 users or groups. If you do not enable paging on the LDAP directory service, synchronization can fail. Synchronize security domains during times when most users are not logged in to Informatica applications. During synchronization, the Service Manager locks each user account it synchronizes. Users might not be able to log in to the Informatica application clients during synchronization. Users logged in to an application client when synchronization starts might not be able to perform certain tasks. To set up a schedule that synchronizes LDAP security domains with the LDAP directory service, perform the following steps:
1. In the Administrator tool, click the Security tab. 2. Click the Actions menu and select LDAP Configuration. 3. In the LDAP Configuration dialog box, click the Schedule tab. 4. Click the Add button (+) to add a time. The synchronization schedule uses a 24-hour time format. 5. To immediately synchronize the users and groups in the LDAP security domains with the users and groups in the LDAP directory service, click Synchronize Now.
6. Click OK to save the synchronization schedule. Note: Wait until the Service Manager synchronizes with the LDAP directory service before restarting the Informatica domain to avoid losing the synchronization times that you set in the schedule.
Using Nested Groups in the LDAP Directory Service
An LDAP security domain can contain nested LDAP groups. The Service Manager can import nested groups that are created in the following manner:
• Create the groups under the same organizational units (OU).
• Set the relationship between the groups. For example, you want to create a nested grouping where GroupB is a member of GroupA and GroupD is a member of GroupC.
1. Create GroupA, GroupB, GroupC, and GroupD within the same OU. 2. Edit GroupA, and add GroupB as a member. 3. Edit GroupC, and add GroupD as a member. You cannot import nested LDAP groups into an LDAP security domain that are created in a different way.
Creating an LDAP Configuration 27 Using a Self-Signed SSL Certificate
You can connect to an LDAP server that uses an SSL certificate signed by a certificate authority (CA). By default, the Service Manager does not connect to an LDAP server that uses a self-signed certificate.
To connect to an LDAP server that uses an SSL certificate, use the Java keytool key and certificate management utility to import the certificates used by all domain nodes into the Java cacerts truststore file on a single gateway node in the domain. You then copy the cacerts keystore file that contains the imported certificates to the other nodes in the domain.
The cacerts truststore file is in the following directory on each node:
The keytool utility is available in the following directory on each node:
Restart the node after you import the certificate.
Deleting an LDAP Configuration
You can delete an LDAP configuration and the associated security domains to permanently prohibit users from accessing the domain.
When you delete an LDAP configuration, you must first delete the security domains associated with the LDAP configuration. The Service Manager deletes all user accounts and groups in each deleted LDAP security domain from the domain configuration database.
1. In the Administrator tool, click the Security tab. 2. Click the LDAP Configuration tab. 3. Click the Security Domains tab, and then click the Edit button. 4. Select a security domain in the Edit LDAP Configuration dialog, and then click Delete. 5. Select the LDAP configuration to delete in the LDAP Configuration navigator. 6. Click the Actions menu, and then and select Delete LDAP Configuration. 7. Click OK to confirm that you want to delete the LDAP configuration.
28 Chapter 3: LDAP Authentication C h a p t e r 4
Kerberos Authentication
This chapter includes the following topics:
• Kerberos Overview, 29
• How Kerberos Works in an Informatica Domain, 30
• Kerberos Cross Realm Authentication, 32
• Preparing to Enable Kerberos Authentication, 33
• Enabling Kerberos Authentication, 48
• Enabling Kerberos on Informatica Nodes, 52
• Enabling User Accounts to Use Kerberos Authentication, 55
Kerberos Overview
Kerberos is a computer network authentication protocol that enables Informatica clients, nodes, and services communicating over a network to connect to one another in a secure manner.
Kerberos authentication eliminates Informatica native accounts and removes the need for the domain to pass user credentials to an LDAP server. After you enable Kerberos authentication in a domain, Informatica clients use the Kerberos tickets created during the Windows authentication process to log in to the Informatica services running in the domain.
You can enable Kerberos authentication in a domain that runs on a Windows network. The network must use Microsoft Active Directory Domain Services (AD DS) as the Kerberos principal database.
To enable Kerberos authentication in an Informatica domain, perform the following steps:
Prepare to enable Kerberos authentication. You must complete multiple tasks before you enable Kerberos authentication. The tasks you must complete include the following tasks:
• Create the Kerberos configuration file.
• Create accounts for Kerberos principal users in Active Directory.
• Generate the service principal name (SPN) and keytab formats.
• Create the keytab files used to authenticate users and services in the network. Enable Kerberos authentication in the Informatica domain. You can enable Kerberos authentication in an Informatica domain when you install the Informatica services, or you can enable Kerberos authentication after you install the services. If you do not enable
29 Kerberos authentication during installation, you can use the Informatica command line programs to configure the domain to use Kerberos authentication. Enable Kerberos authentication on Informatica nodes and client hosts. After you enable Kerberos in the domain, copy the Kerberos configuration file to each node in the domain and to each Informatica client host. You also configure web browsers to access the Informatica web applications. Enable Informatica users to use Kerberos authentication. After you enable Kerberos authentication, import Informatica users from Active Directory into an LDAP security domain that contains the Kerberos user accounts. You must also migrate the groups, roles, privileges, and permissions of the native user accounts to the user accounts in the LDAP security domain.
How Kerberos Works in an Informatica Domain
In a domain configured to use Kerberos authentication, Informatica clients authenticate with nodes and application services within the domain, without requiring passwords.
In a domain that uses Kerberos authentication, services that run within the domain, including node processes, web application processes, and Informatica application services, are Kerberos principals. The Active Directory principal database the Kerberos realm uses contains a user account for each principal.
The Kerberos authentication protocol uses keytabs to authenticate Informatica clients with services that run within the domain. The keytab for a principal is stored on the node on which the service runs. The keytab contains the service principal name (SPN) that identifies the service within the Kerberos realm, and the key assigned to the SPN in Active Directory.
When the KDC gives a service ticket to a client, it encrypts the ticket with the key assigned to the SPN. The requested service uses the key to decrypt the service ticket.
30 Chapter 4: Kerberos Authentication The following image illustrates the basic Kerberos authentication flow:
The following outline describes the basic Kerberos authentication flow:
1. An Informatica client user logs in to a network computer hosting an Informatica client. 2. The login request is directed to the Authentication Server, a component of the Kerberos Key Distribution Center (KDC). The KDC is a network service with access to user account information that runs on each domain controller within the Active Directory domain. 3. The Authentication Server verifies that the user exists in the principal database, and then creates a Kerberos token called a ticket-granting-ticket (TGT) on the user's computer. 4. The user attempts to access a process or service within the Informatica domain through an Informatica client. 5. Informatica and the Kerberos libraries use the TGT to request a service ticket and session key for the requested service from the Ticket Granting Server, which also runs within the KDC. For example, if the user accesses a Model Repository Service from the Informatica Developer client, the TGT requests a service ticket for the node on which the requested service runs. The TGT also requests a service ticket for the Model Repository Service. 6. Kerberos uses the service ticket to authenticates the client with the requested service. The service ticket is cached on the computer hosting the Informatica client, enabling the client to use the ticket while it remains valid. If the user shuts down and then restarts the Informatica client, the client reuses the same ticket to access processes and services within the Informatica domain.
How Kerberos Works in an Informatica Domain 31 Kerberos Cross Realm Authentication
You can configure an Informatica domain to use Kerberos cross realm authentication. Kerberos cross realm authentication enables Informatica clients that belong to one Kerberos realm to authenticate with nodes and application services that belong to another Kerberos realm.
When you configure a domain to use Kerberos cross-realm authentication, you add properties for each Kerberos realm to the Kerberos configuration file. You also include the name of each realm when you run infasetup commands to enable Kerberos authentication in the domain and on domain nodes.
The Active Directory servers that the domain uses for Kerberos cross realm authentication must belong to the same Active Directory forest. An Active Directory forest is a group of Active Directory domains that share a common global catalog, directory schema, logical structure, and directory configuration. You connect to the global catalog to import users from the Active Directory servers into LDAP security domains.
To use Kerberos cross domain authentication, two-way trust must be enabled between the Active Directory servers in the forest.
Converting a Domain From Kerberos Single Realm Authentication to Kerberos Cross Realm Authentication
You can convert an Informatica domain that uses a single Kerberos realm to authenticate users to use Kerberos cross realm authentication.
You must upgrade the domain to version 10.2 HotFix 2 before you convert the domain to use Kerberos cross realm authentication.
You must also import user and group accounts from the Active Directory global catalog into an LDAP security domain. When you import accounts, existing accounts in the LDAP security domain, which use the samAccount name attribute, are deleted and are replaced with new accounts that use the user principal name attribute.
Users log in to Informatica clients with the fully qualified user principal name, which is in the following format:
After you import the user and group accounts, assign privileges, roles, and permissions to the accounts.
1. Upgrade the domain to version 10.2 HotFix 2. 2. Add the required properties for each Kerberos realm to the Kerberos configuration file. Set the properties for each realm in the krb5.conf configuration file on each node in the domain. Restart the domain after you update the file on all of the nodes in the domain. For more information about configuring the krb5.conf configuration file for Kerberos cross realm authentication, see “Configure the Kerberos Configuration File” on page 34. 3. Copy the updated krb5.conf file to the following directory on each computer that hosts an Informatica client:
32 Chapter 4: Kerberos Authentication 5. Run the UpdateKerberosConfig command on a gateway node within the domain. Specify the name of each Kerberos realm that the domain uses to authenticate users as the values for the -srn and -urn options, separated by a comma. 6. Run the UpdateKerberosAdminUser command on a gateway node within the domain. Specify the fully qualified user principal name for the domain administrator user account. 7. Import user and group accounts into LDAP security domains. Connect to the Active Directory global catalog. When you connect to the global catalog, you import users from the Active Directory server used by each Kerberos realm. For more information about connecting to the global catalog and importing accounts, see “Import User Accounts from Active Directory into LDAP Security Domains” on page 55. 8. Assign privileges, roles, and permissions to the user and group accounts you imported into an LDAP security domain. For more information about assigning privileges and roles, see Chapter 9, “Privileges and Roles” on page 128. For more information about assigning permissions, see Chapter 10, “Permissions” on page 169.
Preparing to Enable Kerberos Authentication
You must complete multiple tasks to prepare to enable Kerberos authentication in an Informatica domain. The procedures you follow for each task depend on the service principal level at which you enable Kerberos.
Note: You cannot disable Kerberos authentication in a domain after you enable it. You also cannot switch the service principal level between the node level and the process level.
Determine the Kerberos Service Principal Level
When you prepare to enable Kerberos authentication, you must determine the required service principal level. The required service principal level determines the procedures you must follow to prepare to enable Kerberos authentication in the domain.
You can enable Kerberos authentication at one of the following levels: Node Level
If you use the domain for testing or development, and the domain does not require a high level of security, you can enable Kerberos at the node level. You can use a single service principal name and a single keytab file for the node and for all of the processes and services that run on the node. You must also create a an SPN and a keytab file for the HTTP processes that run on the node.
Process Level
If you use the domain for production, and the domain requires a high level of security, you can set the service principal at the process level. You create a unique SPN and keytab file for each node and each process on the node. You must also create a an SPN and a keytab file for the HTTP processes that run on the node.
Kerberos enabled at the process level provides the highest level of security, but might be difficult to manage in an Informatica domain that contains many nodes or has many services. In this scenario, you might want to enable Kerberos at the node level.
Preparing to Enable Kerberos Authentication 33 Configure the Kerberos Configuration File
Set the properties required by Informatica in the Kerberos configuration file, and then copy the file to each node in the Informatica domain.
Kerberos stores configuration information in a file named krb5.conf. You must set the properties in the krb5.conf configuration file and then copy the file to every node in the Informatica domain.
If the domain uses Kerberos cross realm authentication, enter the required properties for each Kerberos realm.
1. Configure the following Kerberos library properties in the libdefaults section of the file. The following table describes the properties to enter:
Property Description
default_realm Name of the Kerberos realm to which the Informatica domain services belong. The realm name must be in uppercase. If the domain uses a single Kerberos realm for authentication, the service realm name and the user realm name must be the same.
forwardable Allows a service to delegate client user credentials to another service. The Informatica domain requires application services to authenticate the client user credentials with other services. Set to true.
default_tkt_enctypes Encryption types for the session key included in ticket-granting tickets (TGT). Set this property only if session keys must use specific encryption types. Ensure that the Kerberos Key Distribution Center (KDC) supports the encryption type that you specify. Do not set this property to allow the Kerberos protocol to select the encryption type to use. If the node hosts or Informatica client hosts use 256-bit encryption, install the Java Cryptography Extension (JCE) unlimited strength policy files on all node hosts and Informatica client hosts to avoid authentication issues.
rdns Determines whether reverse name lookup is used in addition to forward name lookup to canonicalize host names for use in service principal names. Set to false.
renew_lifetime The default renewable lifetime for initial ticket requests.
ticket_lifetime The default lifetime for initial ticket requests.
udp_preference_limit Determines the protocol that Kerberos uses when it sends a message to the KDC. Set to 1 to use the TCP protocol if the domain experiences intermittent Kerberos authentication failures.
34 Chapter 4: Kerberos Authentication Property Description
dns_lookup_kdc Indicates whether the Kerberos client uses DNS SRV records to locate the KDCs and other servers for a realm, if they are not listed in the information for the realm. DNS uses SRV records to identify computers that host specific services. Required when the domain is Kerberos-enabled. Requires you to set the admin_server realm property. Set to true.
dns_lookup_realm Indicates whether the Kerberos client uses DNS TXT records to determine the Kerberos realm of a host. DNS uses text or TXT records to associate arbitrary text with a host or other name, such as human readable information about a server, network, data center, or other accounting information. Required when the domain is Kerberos-enabled. Set to true.
2. Define each Kerberos realm in the realms section of the file. The following example shows the entry for a Kerberos realm named COMPANY.COM: [realms] COMPANY.COM = {...} 3. Enter the following realm properties inside the brackets for each Kerberos realm in the realms section of the file. The following table describes the properties to enter:
Property Description
admin_server The name or IP address of the Kerberos administration server host. You can include an optional port number, separated from the host name by a colon. Default is 749. Required if you configure dns_lookup_kdc in the libdefaults section.
kdc The name or IP address of a host running the Key Distribution Center (KDC) for the realm. You can include an optional port number, separated from the host name by a colon. Default is 88.
The following example shows the entries for each Kerberos realm in a Kerberos cross realm configuration: [realms] COMPANY.COM = { admin_server = KDC01.COMPANY.COM:749 kdc = KDC01.COMPANY.COM:88 } EAST.COMPANY.COM = { kdc = 10.75.141.193 admin_server = 10.75.141.193 } WEST.COMPANY.COM = { kdc = 10.78.140.111 admin_server = 10.78.140.111 } 4. In the domain_realms section, map the domain name or host name to a Kerberos realm name. The domain name is prefixed by a period (.).
Preparing to Enable Kerberos Authentication 35 The following example shows the parameters for the Hadoop domain_realm if the Informatica domain does not use Kerberos authentication: [domain_realm] .hadoop_realm.com = HADOOP-REALM hadoop_realm.com = HADOOP-REALM The following example shows the parameters for the Hadoop domain_realm if the Informatica domain uses Kerberos authentication: [domain_realm] .infa_ad_realm.com = INFA-AD-REALM infa_ad_realm.com = INFA-AD-REALM .hadoop_realm.com = HADOOP-REALM hadoop_realm.com = HADOOP-REALM 5. Copy the krb5.conf file to the following locations on the machine that hosts the Data Integration Service:
•
•
The following example shows the content of a Kerberos configuration file with the required properties for a single Kerberos realm configuration: [libdefaults] default_realm = COMPANY.COM forwardable = true rdns = false renew_lifetime = 7d ticket_lifetime = 24h udp_preference_limit = 1 dns_lookup_kdc = true dns_lookup_realm = true
[realms] COMPANY.COM = { admin_server = KDC01.COMPANY.COM:749 kdc = KDC01.COMPANY.COM:88 }
[domain_realm] .company.com = COMPANY.COM company.com = COMPANY.COM The following example shows the content of a Kerberos configuration file with the required properties for a Kerberos cross realm configuration: [libdefaults] default_realm = COMPANY.COM forwardable = true rdns = false renew_lifetime = 7d ticket_lifetime = 24h udp_preference_limit = 1 dns_lookup_kdc = true dns_lookup_realm = true
[realms] COMPANY.COM = { admin_server = KDC01.COMPANY.COM:749 kdc = KDC01.COMPANY.COM:88 } EAST.COMPANY.COM = { kdc = 10.75.141.193 admin_server = 10.75.141.193 } WEST.COMPANY.COM = { kdc = 10.78.140.111 admin_server = 10.78.140.111
36 Chapter 4: Kerberos Authentication [domain_realm] .company.com = COMPANY.COM company.com = COMPANY.COM .east.company.com = EAST.COMPANY.COM east.company.com = EAST.COMPANY.COM .west.company.com = WEST.COMPANY.COM west.company.com = WEST.COMPANY.COM For more information about the Kerberos configuration file, see the Kerberos network authentication documentation.
Create Kerberos Principal Accounts in Active Directory
Create LDAP user accounts for the Kerberos principals in Active Directory. A Kerberos principal is a process, service, or user within the Kerberos realm.
If you set the default_tkt_enctypes property in the krb5.conf configuration file to the 128-bit or 256-bit AES encryption types, configure each account to use the corresponding encryption type in Active Directory.
The accounts that you create depend on whether you enable Kerberos at the node level or at the process level.
Note: Account names can be a maximum of 20 characters in length.
Accounts Required at Node Level Create the LDAP user accounts required to enable Kerberos authentication at the node level in Active Directory.
Create the following Kerberos principal accounts in Active Directory if you enable Kerberos at the node level:
Node processes Create an account for each node that runs in the domain. HTTP process Create an account for the Informatica web applications that run on a node in the domain. Web applications that run on a node might include the Administrator tool, Informatica Analyst, and Catalog Administrator. Create a single account that is shared by all of the web applications that run on the node. Bind User Distinguished Name (DN) Create an LDAP bind user account that you use to synchronize the LDAP security domain that contains Kerberos user accounts with Active Directory.
Accounts Required at Process Level Create the LDAP user accounts required to enable Kerberos authentication at the process level in Active Directory.
Create the following Kerberos principal accounts in Active Directory if you enable Kerberos at the process level:
Node processes Create an account for each node that runs in the domain.
Preparing to Enable Kerberos Authentication 37 HTTP processes Create an account for the Informatica web applications that run on a node in the domain. Web applications that run on a node might include Informatica Analyst and Catalog Administrator. Create a single account that is shared by all of the web applications that run on the node. Informatica Administrator service Create an account for the Administrator tool on each gateway node in the domain. Informatica application services Create an account for every Informatica application service that runs on each node in the domain. Bind User Distinguished Name (DN) Create an LDAP user account that you use to synchronize the LDAP security domain that contains Kerberos user accounts with Active Directory.
Generate the Service Principal Name and Keytab File Name Formats
Use the Informatica Kerberos SPN Format Generator utility to generate the service principal name (SPN) and keytab file name formats required to use Kerberos authentication. The Kerberos SPN Format Generator utility generates a text file named SPNKeytabFormat.txt that contains the correct format for the SPNs and keytab file names.
The SPN and keytab file name formats you generate depend on whether you enable Kerberos at the node level or at the process level.
Generate the Service Principal Name and Keytab File Name Formats at Node Level Generate the formats for the SPNs and keytab file names required to enable Kerberos authentication at the node level.
The Informatica domain requires SPNs and keytab files for the following processes when you enable Kerberos authentication at the node level:
Node processes Informatica requires an SPN and keytab file for every node in the domain. Kerberos uses the same service principal name and keytab to authenticate the Informatica application services that run on the node. HTTP processes Informatica requires an SPN and keytab file for the web applications that run on each node in the domain. Web applications that run on a node might include the Administrator tool, Informatica Analyst and Catalog Administrator. Kerberos uses the same service principal name to authenticate all of the web applications that run on the node.
1. On a Windows Informatica node host, go to the directory that contains the SPNFormatGenerator.bat batch file:
38 Chapter 4: Kerberos Authentication 3. Click Next. 4. Select Node Level. 5. Click Next. 6. Enter the properties required to generate the SPN and keytab file formats. The following table describes the properties:
Prompt Description
Domain Name Name of the Informatica domain. The name must not exceed 128 characters and must be 7- bit ASCII. It cannot contain a space or any of the following characters: ` % * + ; " ? , < > \ /
Service Realm Name of the Kerberos realm. The realm name must be in uppercase. Name
Node Name Name of the Informatica node.
Node Host Name Fully qualified name of the node host. The node host name cannot contain the underscore (_) character. Note: Do not use localhost. The host name must explicitly identify the host.
7. To generate the SPN format for an additional node, click +Node and specify the node name and host name. The following image shows the entries for multiple nodes in the InfaDomain domain in the SPN Format Generator utility:
8. Click Next. The SPN Format Generator utility displays the path and file name of the file that contains the list of service principal names and keytab file names.
Preparing to Enable Kerberos Authentication 39 9. Click Done to exit the SPN Format Generator utility.
Generate the Service Principal Name and Keytab File Name Formats at Process Level Generate the formats for the SPNs and keytab file names required to enable Kerberos authentication at the process level.
The Informatica domain requires SPNs and keytab files for the following processes and services when you enable Kerberos authentication at the process level:
Node processes Informatica requires an SPN and keytab file for every node in the domain. Informatica Administrator Informatica requires an SPN and keytab file for the Administrator tool for every gateway node in the domain. HTTP processes Informatica requires an SPN and keytab file for the web applications that run on a node in the domain. Web applications that run on a node might include Informatica Analyst and Catalog Administrator. Informatica application service processes Informatica requires an SPN and keytab file for each Informatica application service that runs on every node in the domain.
1. On a Windows Informatica node host, go to the directory that contains the SPNFormatGenerator.bat batch file:
Prompt Description
Domain Name Name of the Informatica domain. The name must not exceed 128 characters and must be 7- bit ASCII. It cannot contain a space or any of the following characters: ` % * + ; " ? , < > \ /
Service Realm Name of the Kerberos realm. The realm name must be in uppercase. Name
40 Chapter 4: Kerberos Authentication Prompt Description
Node Name Name of the Informatica node.
Node Host Fully qualified name or the IP address of the node host. The node host name cannot contain Name the underscore (_) character. Note: Do not use localhost. The host name must explicitly identify the host.
7. To generate the SPN format for an Informatica application service that runs on a node, click Service after entering the node details. Enter the name of the Informatica application service as shown in the Administrator tool. Complete this step for each Informatica application service that runs on each node in the domain. 8. To generate the SPN format for an additional node, click +Node and specify the node name and host name. The following image shows the entries for multiple nodes and application services that run in the InfaDomain domain in the SPN Format Generator utility:
9. Click Next. The SPN Format Generator utility displays the path and file name of the file that contains the list of service principal names and keytab file names. 10. Click Done to exit the SPN Format Generator utility.
Review the Service Principal Name and Keytab File Name Format Text File After you generate the SPNKeytabFormat.txt file, you can review the file.
You use the information in the file to generate the keytab files, and to associate each SPN with the corresponding principal user account in Active Directory.
Preparing to Enable Kerberos Authentication 41 The SPNKeytabFormat.txt file contains the following information:
Entity Name Identifies the node or service associated with the process. Service Principal Name Format for the SPN. The SPN is case sensitive.
Note: If you enter a string containing multiple Kerberos domain names, or add an asterisk before a realm suffix to include all realms that include the suffix, the SPN format does not include the realm name.
The following table describes the SPN formats:
Keytab type SPN Format
NODE_SPN isp/
NODE_AC_SPN _AdminConsole/
NODE_HTTP_SPN HTTP/
SERVICE_PROCESS_SPN
Keytab File Name Format for the name of the keytab file to be created for the associated SPN. The keytab file name is case sensitive. The following table describes the keytab file name formats:
Keytab Type Keytab File Name
NODE_SPN
NODE_AC_SPN _AdminConsole.keytab
NODE_HTTP_SPN webapp_http.keytab
SERVICE_PROCESS_SPN
Service Principals at Node Level The following image shows the contents of the SPNKeytabFormat.txt file generated for service principals at the node level:
42 Chapter 4: Kerberos Authentication Service Principals at Process Level The following image shows the contents of the SPNKeytabFormat.txt file generated for service principals at the process level:
Generate the Keytab Files
Generate the keytab files used to authenticate Informatica users and services.
You use the Microsoft Windows Server ktpass utility to generate a keytab file for each user account you created in Active Directory. You must generate the keytab files on a member server or on a domain controller within the Active Directory domain. You cannot generate keytab files on a workstation operating system such as Microsoft Windows 7.
To use ktpass to generate a keytab file, run the following command: ktpass.exe -out
Option Description
-out The file name of the Kerberos keytab file to generate as shown under the KEY_TAB_NAME column in the SPNKeytabFormat.txt file.
-princ The service principal name displayed under the SPN column in the SPNKeytabFormat.txt file. If the domain uses Kerberos cross realm authentication, the service principal name must be unique across all Kerberos realms.
-mapuser The Active Directory user account to associate with the SPN. The account name can be a maximum of 20 characters.
-pass The password set in Active Directory for the Active Directory user account, if applicable.
-crypto Specifies the key types generated in the keytab file. Set to all to use all supported cryptographic types.
-ptype The principal type. Set to KRB5_NT_PRINCIPAL.
-target The name of the realm to which the Active Directory server belongs. Include this option if the following error occurs when you run the utility: DsCrackNames returned 0x2 in the name
The keytab files you generate depends on whether you enable Kerberos at the node level or at the process level.
Preparing to Enable Kerberos Authentication 43 Generate the Keytab Files at Node Level When you run ktpass to generate the keytab files at the node level, you associate each Kerberos principal user account with the corresponding SPN in Active Directory.
The following table shows the association between the Kerberos principal user accounts and the SPNs shown in the example SPNKeytabFormat.txt file:
User Account Keytab Type Service Principal Name
nodeuser01 NODE_SPN isp/node01/InfaDomain/COMPANY.COM
httpuser01 NODE_HTTP_SPN HTTP/[email protected]
nodeuser02 NODE_SPN isp/node02/InfaDomain/COMPANY.COM
httpuser02 NODE_HTTP_SPN HTTP/[email protected]
You also create a keytab for the LDAP bind user account that is used to access and search Active Directory during LDAP synchronization.
1. Create a keytab file for the Kerberos principal user account that you created for each node in Active Directory. Copy the keytab file name from the KEY_TAB_NAME column in the SPNKeytabFormat.txt file. Copy the service principal name from the SPN column in the SPNKeytabFormat.txt file. The following example creates a keytab file for a Kerberos principal user account named nodeuser0: ktpass.exe -out node01.keytab -princ isp/node01/InfaDomain/COMPANY.COM -mapuser nodeuser01 -crypto all -ptype KRB5_NT_PRINCIPAL 2. Create a keytab file for each HTTP process Kerberos principal user account that you created in Active Directory. If the domain uses Kerberos cross realm authentication, the principal user account can exist in any Kerberos realm the domain uses. Copy the keytab file name from the KEY_TAB_NAME column in the SPNKeytabFormat.txt file. Copy the service principal name from the SPN column in the SPNKeytabFormat.txt file. The following example creates a keytab file for a Kerberos principal user account named httpuser01: ktpass.exe -out webapp_http.keytab -princ HTTP/[email protected] -mapuser httpuser01 -crypto all -ptype KRB5_NT_PRINCIPAL 3. Create a keytab for the LDAP bind user account that is used to access and search Active Directory during LDAP synchronization. Structure the value for the -princ option as
44 Chapter 4: Kerberos Authentication Generate the Keytab Files at Process Level When you run ktpass to generate the keytab files at the process level, you associate each Kerberos principal user account with the corresponding SPN in Active Directory.
The following table shows the association between the Kerberos principal user accounts and the SPNs shown in the example SPNKeytabFormat.txt file:
User Account Keytab Type Service Principal Name
nodeuser01 NODE_SPN isp/node01/InfaDomain/COMPANY.COM
admintooluser01 NODE_AC_SPN _AdminConsole/node01/[email protected]
httpuser01 NODE_HTTP_SPN HTTP/[email protected]
MRSdevuser01 SERVICE_PROCESS_SPN MRS_dev/node01/[email protected]
DISdevuser01 SERVICE_PROCESS_SPN DIS_dev/node01/[email protected]
nodeuser02 NODE_SPN isp/node02/InfaDomain/COMPANY.COM
admintooluser02 NODE_AC_SPN _AdminConsole/node02/[email protected]
httpuser02 NODE_HTTP_SPN HTTP/[email protected]
CATdevuser01 SERVICE_PROCESS_SPN CAT_dev/node02/[email protected]
You also create a keytab for the LDAP bind user account that is used to access and search Active Directory during LDAP synchronization.
1. Create a keytab file for the Kerberos principal user account that you created for each node in Active Directory. Copy the file name from the KEY_TAB_NAME column in the SPNKeytabFormat.txt file. Copy the service principal name from the SPN column in the SPNKeytabFormat.txt file. The following example creates a keytab file for a Kerberos principal user account named nodeuser01: ktpass.exe -out node01.keytab -princ isp/node01/InfaDomain/COMPANY.COM -mapuser nodeuser01 -crypto all -ptype KRB5_NT_PRINCIPAL 2. Create a keytab file for each HTTP process Kerberos principal user account that you created. If the domain uses Kerberos cross realm authentication, the principal user account can exist in any Kerberos realm the domain uses. Copy the file name from the KEY_TAB_NAME column in the SPNKeytabFormat.txt file. Copy the service principal name from the SPN column in the SPNKeytabFormat.txt file. The following example creates a keytab file for a Kerberos principal user account named httpuser01: ktpass.exe -out webapp_http.keytab -princ HTTP/[email protected] -mapuser httpuser01 -crypto all -ptype KRB5_NT_PRINCIPAL 3. Create a keytab file for each Administrator tool Kerberos principal user account that you created. Copy the file name from the KEY_TAB_NAME column in the SPNKeytabFormat.txt file. Copy the service principal name from the SPN column in the SPNKeytabFormat.txt file.
Preparing to Enable Kerberos Authentication 45 The following example creates a keytab file for a Kerberos principal user account named admintooluser01: ktpass.exe -out _AdminConsole.keytab -princ _AdminConsole/node01/[email protected] - mapuser admintooluser01 -crypto all -ptype KRB5_NT_PRINCIPAL 4. Create a keytab file for each Informatica application service Kerberos principal user account that you created. Copy the file name from the KEY_TAB_NAME column in the SPNKeytabFormat.txt file. Copy the service principal name from the SPN column in the SPNKeytabFormat.txt file. The following example creates a keytab file for a service Kerberos principal user account named MRSdevuser01: ktpass.exe -out MRS_dev.keytab -princ HTTP/[email protected] -mapuser MRSdevuser01 -crypto all -ptype KRB5_NT_PRINCIPAL 5. Create a keytab for the LDAP bind user account that is used to access and search Active Directory during LDAP synchronization. Structure the value for the -princ option as
Verify the Service Principal Names and Keytab Files You can use Kerberos utilities to verify that the SPNs and the keytab files are valid. You can also use the utilities to determine the status of the Kerberos Key Distribution Center (KDC).
You can use Kerberos utilities such as kinit and klist to view and verify the SPNs and keytab files. To use the utilities, ensure that the KRB5_CONFIG environment variable contains the path and file name of the Kerberos configuration file. For more information about running the Kerberos utilities, see the Kerberos documentation.
Use the following utilities to verify the SPNs and keytab files: kinit
You can use the kinit utility to request a ticket-granting ticket (TGT) from the KDC and verify that a keytab file can be used to establish a Kerberos connection. If the keytab and specified SPN are valid, the command obtains a ticket, and then caches the ticket in the specified cache.
The kinit utility is available in the following directory on an Informatica node:
To request a ticket-granting ticket for an SPN, run the following command: kinit -c
46 Chapter 4: Kerberos Authentication klist You can use the klist utility to list the Kerberos principals and keys in a keytab file. To list the keys in the keytab file and the time stamp for the keytab entry, run the following command: klist -k -t
Enable Delegation for the Kerberos Principal User Accounts in Active Directory
Enable delegation for each Kerberos principal user account you created in Active Directory.
Delegated authentication happens when a user is authenticated with one service, and that service uses the credentials of the authenticated user to connect to another service. Because services in the Informatica domain need to connect to other services to complete an operation, the Informatica domain requires the delegation option to be enabled in Active Directory.
You must enable delegation for all accounts for all of the accounts you created, except for the LDAP bind user account that you use to access and search Active Directory during LDAP synchronization. Set delegation to Trust this user for delegation to any service (Kerberos only) in the Delegation tab in the properties dialog box for each user account.
Preparing to Enable Kerberos Authentication 47 Note: The Delegation tab is not available in the properties dialog box until you run ktpass to create the keytab files.
The following image shows the Delegation tab in the nodeuser01 account properties dialog box:
Enabling Kerberos Authentication
You can enable Kerberos authentication in an Informatica domain when you install the Informatica services, or you can enable Kerberos authentication after you install the services.
For information on how to enable Kerberos authentication when you install the Informatica services, see the Informatica 10.2 HotFix 2 Installation and Configuration Guide.
If you do not enable Kerberos authentication during installation, follow the steps in this section to use the Informatica command line programs to enable Kerberos authentication after you install the services.
48 Chapter 4: Kerberos Authentication Enable Kerberos Authentication in the Domain
Enable Kerberos on a gateway node within the domain.
Run the infasetup switchToKerberosMode command on a gateway node within the domain to change the authentication to Kerberos network authentication.
1. Shut down the domain and all Informatica services. Shut down the services in the following order:
• Metadata Manager Service
• PowerCenter® Integration Service
• PowerCenter® Repository Service
• Content Management Service
• Analyst Service
• Data Integration Service
• Model Repository Service 2. At the command prompt on a gateway node, switch to the directory where the infasetup executable is located:
Enabling Kerberos Authentication 49 The following table describes the options and arguments for the infasetup switchToKerberosMode command:
Option Argument Description
-administratorName user_name User name for the domain administrator -ad account that is created when you configure Kerberos authentication. Specify the name of an account that exists in Active Directory. After you configure Kerberos authentication, this user is included in the _infaInternalNamespace security domain that the command creates. If the domain uses a single Kerberos realm to authenticate users, specify the samAccount name of the account you want to use as the administrator account. If the domain uses Kerberos cross realm authentication, specify the fully qualified user principal name of the account you want to use as the administrator account, including the realm name. For example: [email protected]
-ServiceRealmName Kerberos_realm_name Name of the Kerberos realm that the -srn domain uses to authenticate users. The realm name must be in uppercase and is case-sensitive. To configure Kerberos cross realm authentication, specify the name of each Kerberos realm that the domain uses to authenticate users, separated by a comma. For example: COMPANY.COM,EAST.COMPANY.COM,W EST.COMPANY.COM Use an asterisk as a wildcard character before a realm name to include all realms that include the name. For example: *EAST.COMPANY.COM
50 Chapter 4: Kerberos Authentication Option Argument Description
-UserRealmName Kerberos_realm_name Name of the Kerberos realm that the -urn domain uses to authenticate users. The realm name must be in uppercase and is case-sensitive. To configure Kerberos cross realm authentication, specify the name of each Kerberos realm that the domain uses to authenticate users, separated by a comma. For example: COMPANY.COM,EAST.COMPANY.COM,W EST.COMPANY.COM Use an asterisk as a wildcard character before a realm name to include all realms that include the name. For example: *EAST.COMPANY.COM
-SPNShareLevel NODE|PROCESS Service principal level for the domain. -spnSL Set to NODE to enable Kerberos at the node level. Set to PROCESS to enable Kerberos at the process level.
The following example changes the domain authentication to Kerberos and sets the sysadmin user account as the administrator account in a domain that uses a single Kerberos realm to authenticate users: infasetup switchToKerberosMode -ad sysadmin -srn COMPANY.COM -urn COMPANY.COM –spnSL NODE The following example changes the domain authentication to Kerberos and sets the sysadmin user account as the administrator account in a domain that uses Kerberos cross realm authentication: infasetup switchToKerberosMode -ad [email protected] -srn COMPANY.COM,COMPANY.EAST.COM,COMPANY.WEST.COM -urn COMPANY.COM,COMPANY.EAST.COM,COMPANY.WEST.COM –spnSL NODE
Update the Nodes in the Domain
Update all gateway and worker nodes with the Kerberos authentication server information except the gateway nodes on which you ran the infasetup switchToKerberosMode command.
Use the following commands to update the gateway and worker nodes: infasetup UpdateGatewayNode
Use the UpdateGatewayNode command to set the Kerberos authentication parameters on a gateway node in the domain. If the domain has multiple gateway nodes, run the UpdateGatewayNode command on each gateway node. infasetup UpdateWorkerNode Use the UpdateWorkerNode command to set the Kerberos authentication parameters on a worker node in the domain. If the domain has multiple worker nodes, run the UpdateWorkerNode command on each worker node.
1. At the command prompt on a node, switch to the directory where the infasetup executable is located:
Enabling Kerberos Authentication 51 2. To set the Kerberos authentication parameters on a gateway node, run the following command: infasetup UpdateGatewayNode -krb
Option Argument Description
-EnableKerberos true|false Configures the Informatica domain to use Kerberos -krb authentication. Set to true to enable Kerberos authentication. Default is false.
- Kerberos_realm_name Name of the Kerberos realm that the domain uses to ServiceRealmNa authenticate users. The realm name must be in uppercase and is me case-sensitive. -srn To configure Kerberos cross realm authentication, specify the name of each Kerberos realm that the domain uses to authenticate users, separated by a comma. For example: COMPANY.COM,EAST.COMPANY.COM,WEST.COMPANY.COM Use an asterisk as a wildcard character before a realm name to include all realms that include the name. For example: *EAST.COMPANY.COM
-UserRealmName Kerberos_realm_name Name of the Kerberos realm that the domain uses to -urn authenticate users. The realm name must be in uppercase and is case-sensitive. To configure Kerberos cross realm authentication, specify the name of each Kerberos realm that the domain uses to authenticate users, separated by a comma. For example: COMPANY.COM,EAST.COMPANY.COM,WEST.COMPANY.COM Use an asterisk as a wildcard character before a realm name to include all realms that include the name. For example: *EAST.COMPANY.COM
The following example updates a worker node to use Kerberos authentication: infasetup updateWorkerNode -krb true -srn COMPANY.COM -urn COMPANY.COM The following example updates a worker node to use Kerberos cross realm authentication: infasetup updateWorkerNode -krb true -srn COMPANY.COM,COMPANY.EAST.COM,COMPANY.WEST.COM -urn COMPANY.COM,COMPANY.EAST.COM,COMPANY.WEST.COM
Enabling Kerberos on Informatica Nodes
After you enable Kerberos in the domain, you must copy the Kerberos configuration file to each node in the domain. You must also configure web browsers to access the Informatica web applications.
Copy the keytab files to the following directory on each node:
52 Chapter 4: Kerberos Authentication
The keytab files you copy depends on whether you enable Kerberos authentication at the node level or at the process level. Keytab Files at Node Level Copy each keytab file generated at the node level to the corresponding node.
The following table shows the node to which to copy each keytab file:
Keytab File Location on Node
webapp_http.keytab Copy each file to the corresponding gateway node.
ldapuser.keytab Copy the file to each gateway node.
Keytab Files at Process Level Copy each keytab file generated at the process level to the corresponding node.
The following table shows the node to which to copy each keytab file:
Keytab File Location on Node
webapp_http.keytab Copy each file to the corresponding gateway node.
_AdminConsole.keytab Copy each file to the corresponding gateway node.
ldapuser.keytab Copy the file to each gateway node.
Configure web browsers to access Informatica web applications. In Microsoft Internet Explorer and Google Chrome, add the URL of the Informatica web applications, such as the Analyst tool, to the list of trusted sites.
If you are using Chrome version 41 or later, you must also set the AuthServerWhitelist and AuthNegotiateDelegateWhitelist policies.
Copy the Keytab Files to the Informatica Nodes
After you create the keytab files, copy each keytab file to the corresponding node.
Copy the keytab files to the following directory on each node:
The keytab files you copy depends on whether you enable Kerberos authentication at the node level or at the process level.
Enabling Kerberos on Informatica Nodes 53 Keytab Files at Node Level Copy each keytab file generated at the node level to the corresponding node.
The following table shows the node to which to copy each keytab file:
Keytab File Location on Node
webapp_http.keytab Copy each file to the corresponding node.
ldapuser.keytab Copy the file to each gateway node.
Keytab Files at Process Level Copy each keytab file generated at the process level to the corresponding node.
The following table shows the node to which to copy each keytab file:
Keytab File Location on Node
webapp_http.keytab Copy each file to the corresponding node.
_AdminConsole.keytab Copy each file to the corresponding node.
ldapuser.keytab Copy the file to each node.
Enable Kerberos Authentication for Informatica Clients
Copy the Kerberos configuration file to each computer that hosts an Informatica client, and then set an environment variable to point to the configuration file. You must also enable client browsers to access the Informatica web applications.
After you configure the Informatica domain to run with Kerberos authentication, perform the following tasks on the Informatica client tools:
Copy the Kerberos configuration file to each Informatica client host.
Copy the krb5.conf file to each computer that hosts a Informatica client such as the PowerCenter Client or Informatica Developer (the Developer tool). Copy the file to the following directory on each host:
Set the KRB5_CONFIG environment variable on each Informatica client host.
Set the KRB5_CONFIG environment variable to the path and file name of the Kerberos configuration file on each computer that hosts Informatica clients such as the PowerCenter Client and the Developer tool.
Configure web browsers to access Informatica web applications.
In Microsoft Internet Explorer and Google Chrome, add the URL of the Informatica web applications, such as the Analyst tool, to the list of trusted sites.
54 Chapter 4: Kerberos Authentication If you are using Chrome version 41 or later, you must also set the AuthServerWhitelist and AuthNegotiateDelegateWhitelist policies.
Enabling User Accounts to Use Kerberos Authentication
After you enable Kerberos authentication in the domain, import Informatica user accounts from Active Directory into the LDAP security domain that contains Kerberos user accounts. You must also migrate the groups, roles, privileges, and permissions from the native security domain to the corresponding Active Directory user accounts in the LDAP security domain that contains Kerberos user accounts.
Import User Accounts from Active Directory into LDAP Security Domains
Import user accounts from Active Directory into LDAP security domains.
When you enable Kerberos authentication in the domain, Informatica creates an empty LDAP security domain with the same name as the Kerberos realm. You can import user accounts from Active Directory into this LDAP security domain, or you can import the user accounts into a different LDAP security domain.
You use the Administrator tool to import the user accounts that use Kerberos authentication from Active Directory into an LDAP security domain.
To configure Kerberos cross realm authentication, connect to the Active Directory global catalog. When you connect to the global catalog, you import users from the Active Directory server used by each Kerberos realm.
1. Start the domain and all Informatica services. 2. Log in to Windows with the administrator account you specified when you enabled Kerberos authentication in the domain. 3. Log in to the Administrator tool. Select _infaInternalNamespace as the security domain. 4. In the Administrator tool, click the Security tab. 5. Click the Actions menu and select LDAP Configuration. 6. In the LDAP Configuration dialog box, click the LDAP Connectivity tab. 7. Configure the connection properties for the Active Directory. You might need to consult the LDAP administrator to get the information needed to connect to the LDAP server.
Enabling User Accounts to Use Kerberos Authentication 55 The following table describes the LDAP server configuration properties:
Property Description
Server name Host name or IP address of the Active Directory server. To configure Kerberos cross realm authentication, connect to the Active Directory global catalog host. Specify the fully qualified hostname. For example: host.company.local
Port Listening port for the Active Directory server. The default is 389. The default SSL port is 636. To configure Kerberos cross realm authentication, connect to the Active Directory global catalog port. The default is 3268. The default SSL port is 3269.
LDAP Directory Service Select Microsoft Active Directory Service.
Name Specify the bind user account you created in Active Directory to synchronize accounts in Active Directory with the LDAP security domain. Because the domain is enabled for Kerberos authentication, you do not have the option to provide a password for the account. If the domain uses Kerberos cross realm authentication, include the name of the realm to which the Active Directory principal database belongs.
Use SSL Certificate Indicates that the LDAP server uses the Secure Socket Layer (SSL) protocol.
Trust LDAP Certificate Determines whether the Service Manager can trust the SSL certificate of the LDAP server. If selected, the Service Manager connects to the LDAP server without verifying the SSL certificate. If not selected, the Service Manager verifies that the SSL certificate is signed by a certificate authority before connecting to the LDAP server.
Not Case Sensitive Indicates that the Service Manager must ignore case sensitivity for distinguished name attributes when assigning users to groups.
Group Membership Name of the attribute that contains group membership information for a user. This is Attribute the attribute in the LDAP group object that contains the DNs of the users or groups who are members of a group. For example, member or memberof.
Maximum Size Maximum number of user accounts to import into a security domain. For example, if the value is set to 100, you can import a maximum of 100 user accounts into the security domain. If the number of user to be imported exceeds the value for this property, the Service Manager generates an error message and does not import any user. Set this property to a higher value if you have many users to import. Default is 1000.
8. In the LDAP Configuration dialog box, click the Security Domains tab. 9. Click Add.
56 Chapter 4: Kerberos Authentication The following table describes the filter properties that you can set for a security domain:
Property Description
Security Domain Name of the LDAP security domain into which you want to import user accounts from Active Directory.
User search base Distinguished name (DN) of the entry that serves as the starting point to search for user names in Active Directory. The search finds an object in the directory according to the path in the distinguished name of the object. For example, to search the USERS container that contains Informatica user accounts in the example.com Windows domain, specify CN=USERS,DC=EXAMPLE,DC=COM.
User filter An LDAP query string that specifies the criteria for searching for users in the directory service. The filter can specify attribute types, assertion values, and matching criteria. For example: (objectclass=*) searches all objects. (&(objectClass=user)(! (cn=susan))) searches all user objects except “susan”. For more information about search filters, see the documentation for the LDAP directory service.
Group search base Distinguished name (DN) of the entry that serves as the starting point to search for group names in the LDAP directory service.
Group filter An LDAP query string that specifies the criteria for searching for groups in the directory service.
Enabling User Accounts to Use Kerberos Authentication 57 The following image shows the information required to import LDAP users from Active Directory into the LDAP security domain created when you enabled Kerberos in the domain:
10. Click Synchronize Now. The Service Manager synchronizes the users in all the LDAP security domains with the users in the LDAP directory service. The time it takes for the synchronization process to complete depends on the number of users and groups to be imported. 11. Click OK to save the LDAP security domain.
Migrate Native User Privileges and Permissions to the Kerberos Security Domain
If the Informatica domain has user accounts in the native security domain, the corresponding Active Directory user accounts in the Kerberos security domain must have the same groups, roles, privileges, and permissions. Migrate the groups, roles, privileges, and permissions of the native users to the corresponding user accounts in the Kerberos LDAP security domain.
1. Review the list of native user accounts and determine the accounts that you want to migrate to the LDAP security domain for Kerberos authentication. To list the user accounts in the Informatica domain, run the following command: infacmd isp ListAllUsers Each native user account that you want to migrate to the Kerberos security domain must have a corresponding account in the Active Directory service that you use for Kerberos authentication.
58 Chapter 4: Kerberos Authentication 2. Create the user migration file. The user migration file is a plain text file that contains the list of native users and the corresponding Kerberos users that require the same groups, roles, privileges, and permissions. Use the following format to list entries in the user migration file: Native/
Option Description
-DomainName Name of the Informatica domain. -dn
-UserName User name to connect to the domain. -un Specify the user name of the administrator account you specified in the infasetup switchToKerberosMode command.
-Password Password for the administrator account. -pd
-SecurityDomain LDAP security domain of the administrator account used to connect to the domain. -sdn Specify _infaInternalNamespace.
-UserMigrationFile Path and file name of the user migration file. -umf The command skips entries with a duplicate source user name or target user name.
The following example migrates the groups, roles, privileges, and permissions for users based on the um_s.txt user migration file: infacmd isp migrateUsers -dn InfaDomain -un nodeuser01 -pd password -sdn _infaInternalNamespace -umf C:\Infa\um_s.txt The command overwrites the connection object permissions assigned to the LDAP user with the connection object permissions for the native user. The command merges the groups, roles, privileges, and domain object permissions for native users and corresponding LDAP users. The migrateUsers command creates a detailed log file named infacmd_umt_
Enabling User Accounts to Use Kerberos Authentication 59 C h a p t e r 5
SAML Authentication for Informatica Web Applications
This chapter includes the following topics:
• SAML Authentication Overview, 60
• SAML Authentication Process, 61
• Enable SAML Authentication in a Domain, 61
• Configuring Web Applications to Use Different Identity Providers, 67
SAML Authentication Overview
You can configure Security Assertion Markup Language (SAML) authentication for Informatica web applications.
Security Assertion Markup Language is an XML-based data format for exchanging authentication information between a service provider and an identity provider. In an Informatica domain, the Informatica web application is the service provider.
You can configure the following Informatica web applications to use SAML authentication:
• Informatica Administrator
• Informatica Analyst
• Metadata Manager
• Enterprise Data Catalog
• Enterprise Data Preparation
Informatica supports the following identity providers:
• Microsoft Active Directory Federation Services (AD FS)
• PingFederate
For information about supported versions of these identity providers, see the Product Availability Matrix on Informatica Network: https://network.informatica.com/community/informatica-network/product-availability-matrices.
Note: SAML authentication cannot be used in an Informatica domain configured to use Kerberos authentication.
60 If you enable a domain to use SAML authentication, all web applications that run in the domain use the identity provider you configure in the domain by default. However, you can configure web applications that run in a domain to use different identity providers. For example, you might configure Informatica Administrator to use AD FS as the identity provider, and configure Informatica Analyst to use PingFederate as the identity provider.
For more information about configuring web applications to use different identity providers, see “Configuring Web Applications to Use Different Identity Providers” on page 67.
SAML Authentication Process
Informatica web applications and the identity provider exchange authentication information to enable SAML authentication in an Informatica domain.
The following steps describe the basic SAML authentication flow:
1. A user accesses an Informatica web application. 2. The user selects the security domain containing LDAP user accounts used for SAML authentication on the application log in page, and then clicks the log in button. If the user selects the native security domain, the user provides a user name and password and logs in to the application. 3. Based on the identity provider configuration, the user is prompted to provide the credentials required for first time authentication. 4. The identity provider validates the user's credentials and creates a session for the user. The identity provider also validates the target web application URL, and then redirects the user to the web application with a SAML token containing the user's identity information. 5. The application validates the SAML token and user identity information, creates a user session, and then completes the user log in process. The existing user session in the browser is used for subsequent authentication. To access another Informatica web application configured to use SAML authentication, the user selects the LDAP security domain on the application log in page. The user does not need to supply a user name or password.
The user remains logged in to all Informatica web applications that are running in the same browser session. However, if the user logs out of an Informatica web application, the user is also logged out of other Informatica web applications running in the same browser session.
Enable SAML Authentication in a Domain
Configure the identity provider, the Informatica domain, and the gateway nodes within the domain to use SAML authentication.
To configure SAML authentication for supported Informatica web applications that run in a domain, perform the following tasks:
1. Create an LDAP configuration to connect to the LDAP identity store that contains Informatica web application user accounts. You also create an LDAP security domain, and then import the user accounts into the security domain.
SAML Authentication Process 61 2. Export the assertion signing certificate from the identity provider. 3. Import the assertion signing certificate into a truststore file on each gateway node in the domain. You can import the certificate into the Informatica default truststore file, or into a custom truststore file. 4. Add one or more relying party trusts or service providers in the identity provider. 5. Add the URL for each Informatica web application to the identity provider. 6. Enable SAML authentication in the domain. 7. Enable SAML authentication on every gateway node in the domain.
Create an LDAP Configuration for the Identity Provider or LDAP Store
Use the Administrator tool to create an LDAP configuration for the identity provider or LDAP store that contains the web application user accounts that use SAML authentication.
When you create an LDAP configuration, you create a security domain for the user accounts, and then import the accounts into the security domain. After you import the accounts into the security domain, assign the appropriate Informatica domain roles, privileges and permissions to the accounts in the security domain.
For more information about creating an LDAP configuration, see “Creating an LDAP Configuration” on page 23.
Export the Assertion Signing Certificate
Export the Assertion Signing certificate from the identity provider.
The certificate is a standard X.509 certificate used to sign the assertions within the SAML tokens that the identity provider issues to Informatica web applications. You can generate a self-signed Secure Sockets Layer (SSL) certificate, or you can get a certificate from a certificate authority, and then import it into the identity provider.
Import the Certificate into the Truststore Used for SAML Authentication
Import the assertion signing certificate used by the identity provider into the truststore file used for SAML authentication on every gateway node within the Informatica domain.
You can import the certificate into the default Informatica truststore file, or into a custom truststore file.
The file name of the default Informatica truststore file is infa_truststore.jks. The file is installed in the following location on each node:
Note: Do not replace the default infa_truststore.jks file with a custom truststore file.
If you import the certificate into a custom truststore file, you must save the truststore file in a different directory than the directory containing the default Informatica truststore file. The truststore file name must be infa_truststore.jks.
You can use the Java keytool key and certificate management utility to create an SSL certificate or a certificate signing request (CSR) as well as keystores and truststores in JKS format. The keytool is available in the following directory on domain nodes:
62 Chapter 5: SAML Authentication for Informatica Web Applications If the domain nodes run on AIX, you can use the keytool provided with the IBM JDK to create an SSL certificate or a Certificate Signing Request (CSR) as well as keystores and truststores.
1. Copy the certificate files to a local folder on a gateway node within the Informatica domain. 2. From the command line, go to the location of the keytool utility on the node. 3. Run the keytool utility to import the certificate. 4. Restart the node.
Configure the Identity Provider
Configure the identity provider to issue SAML tokens to Informatica web applications.
Perform the following tasks to configure the identity provider:
• Add a relying party trust for the domain in the identity provider. The relying party trust definition enables the identity provider to accept authentication requests from Informatica web applications that run in the domain.
• Edit the Send LDAP Attributes as Claims rule to map LDAP attributes in your identity store to the corresponding types used in SAML tokens issued by the identity provider. You provide the name of the relying party trust when you enable SAML authentication in a domain. Depending on your security requirements, you might create multiple relying party trusts in the identity provider to enable domains used by different organizations within the enterprise to use SAML authentication.
Informatica recognizes "Informatica" as the default relying party trust name. If you create a single relying party trust with "Informatica" as the relying party trust name, you do not need to provide the relying party trust name when you enable SAML authentication in a domain.
Note: All strings are case sensitive in the identity provider, including URLs.
Add Informatica Web Application URLs to the Identity Provider
Add the URL for each Informatica web application using SAML authentication to the identity provider.
You provide the URL for an Informatica web application to enable the identity provider to accept authentication requests sent by the application. Providing the URL also enables the identity provider to send the SAML token to the application after authenticating the user.
Enable SAML Authentication in the Domain
You can enable SAML authentication in an existing Informatica domain, or you can enable it when you create a domain.
When you enable a domain to use SAML authentication, all web applications that run in the domain use the default identity provider you specify when you enable SAML authentication in the domain. For example, if you configure AD FS as the identity provider, all web applications use AD FS as the identity provider, unless you configure a web application to use a different identity provider.
Select one of the following options:
Enable SAML authentication when you run Informatica installer. You can enable SAML authentication and specify the identity provider URL when you configure the domain as part of the installation process.
Enable SAML Authentication in a Domain 63 Enable SAML authentication in an existing domain.
Use the infasetup updateDomainSamlConfig command to enable SAML authentication in an existing Informatica domain. You can run the command on any gateway node within the domain.
Enable SAML authentication when you create a domain.
Use the infasetup defineDomain command to enable SAML authentication when you create a domain.
See the Informatica Command Reference for instructions on using the commands.
infasetup updateDomainSamlConfig Command Options Set the SAML options in the infasetup updateDomainSamlConfig command to enable SAML authentication in a domain. Shut down the domain before you run the command.
Specify the identity provider URL as the value for the -iu option. The following example shows the command usage to configure a domain to use AD FS as the identity provider:
infasetup updateDomainSamlConfig -saml true -iu https://server.company.com/adfs/ls/ -spid Prod_Domain -cst 240
The following table describes the options and arguments:
Option Argument Description
-EnableSaml true|false Required. Set this value to true to enable SAML authentication for -saml supported Informatica web applications within the Informatica domain. Set this value to false to disable SAML authentication for supported Informatica web applications within the Informatica domain.
-idpUrl identity_provider Required if the -saml option is true. Specify the identity provider URL for the -iu _url domain. You must specify the complete URL string.
-ServiceProviderId service_provider Optional. The relying party trust name or the service provider identifier for -spid _id the domain as defined in Active Directory Federation Services (AD FS). If you specified "Informatica" as the relying party trust name in AD FS, you do not need to specify a value.
- clock_skew_toler Optional. The allowed time difference between the AD FS host system clock ClockSkewToleran ance_in_seconds and the master gateway node's system clock. ce The lifetime of SAML tokens issued by AD FS by is set according to the AD -cst FS host system clock. The lifetime of a SAML token issued by AD FS is valid if the start time or end time set in the token is within the specified number seconds of the master gateway node's system clock. Values must be from 0 to 600 seconds. Default is 120 seconds.
See the Informatica Command Reference for instructions on using the infasetup updateDomainSamlConfig command.
infasetup DefineDomain Command Options Use the infasetup defineDomain command to enable SAML authentication when you create a domain.
The following example shows the options to configure a domain to use AD FS as the identity provider in the final six options at the command prompt:
infasetup defineDomain -cs "jdbc:informatica:oracle://host:1521;sid=DB2" -dt oracle -dn TestDomain -ad test_admin -pd test_admin -ld $HOME/ISP/1011/source/logs -nn TestNode1 -na
64 Chapter 5: SAML Authentication for Informatica Web Applications host1.company.com -saml true -iu https://server.company.com/adfs/ls/ -spid Prod_Domain -cst 240 -asca adfscert -std \custom\security\ -stp password -mi 10000 -ma 10200 -rf $HOME/ISP/BIN/nodeoptions.xml
The following table describes the SAML options and arguments:
Option Argument Description
-EnableSaml true|false Required. Set this value to true to enable SAML authentication for -saml supported Informatica web applications within the Informatica domain. Set this value to false to disable SAML authentication for supported Informatica web applications within the Informatica domain.
-idpUrl identity_provider Required if the -saml option is true. Specify the identity provider URL for the -iu _url domain. You must specify the complete URL string.
-ServiceProviderId service_provider Optional. The relying party trust name or the service provider identifier for -spid _id the domain as defined in Active Directory Federation Services (AD FS). If you specified "Informatica" as the relying party trust name in AD FS, you do not need to specify a value.
- clock_skew_toler Optional. The allowed time difference between the AD FS host system clock ClockSkewToleran ance_in_seconds and the master gateway node's system clock. ce The lifetime of SAML tokens issued by AD FS by is set according to the AD -cst FS host system clock. The lifetime of a SAML token issued by AD FS is valid if the start time or end time set in the token is within the specified number seconds of the master gateway node's system clock. Values must be from 0 to 600 seconds. Default is 120 seconds.
- idp_assertion_si Required if the -saml option is true. The alias name specified when AssertionSigningC gning_certificate importing the identity provider assertion signing certificate into the ertificateAlias _aliaseAlias truststore file used for SAML authentication. -asca
-SamlTrustStoreDir saml_truststore_ Optional. The directory containing the custom truststore file required to use -std directory SAML authentication on gateway nodes within the domain. Specify the directory only, not the full path to the file. SAML authentication uses the default Informatica truststore if no truststore is specified.
- saml_truststore_ Required if you use a custom truststore. The password for the custom SamlTrustStorePa password truststore file. ssword -stp
See the Informatica Command Reference for instructions on using the infasetup defineDomain command.
Enable SAML Authentication on the Gateway Nodes
You must configure SAML authentication on every gateway node in the Informatica domain.
Select one of the following options to configure SAML authentication on a gateway node:
Enable SAML authentication when you define a gateway node on a machine. Use the infasetup DefineGatewayNode command to enable SAML authentication on the gateway node.
Enable SAML Authentication in a Domain 65 Enable SAML authentication when you configure a gateway node to join a domain that uses SAML authentication.
Use the infasetup UpdateGatewayNode command to enable SAML authentication on the gateway node.
Enable SAML authentication when you convert a worker node to a gateway node.
Use the isp SwitchToGatewayNode command to enable SAML authentication on the node.
See the Informatica Command Reference for instructions on using the commands.
Gateway Node Command Options Use the infasetup DefineGatewayNode command to enable SAML authentication when you create a gateway node. Use infasetup UpdateGatewayNode or infacmd isp SwitchToGatewayNode to enable SAML authentication on an existing node.
The SAML options are identical for all of these commands. The following example shows the SAML options as the final four options on the infasetup DefineGatewayNode command line:
infasetup defineGatewayNode -cs "jdbc:informatica:oracle://host:1521;sid=xxxx" -du test_user -dp test_user -dt oracle -dn TestDomain -nn TestNode1 -na host2.company.com:1234 -ld $HOME/ISP/1011/source/logs -rf $HOME/ISP/BIN/nodeoptions.xml -mi 10000 -ma 10200 -ad test_admin -pd test_admin -saml true -asca adfscert -std \custom\security\ -stp password
The following table describes the options and arguments:
Option Argument Description
-EnableSaml true|false Required. Enables SAML authentication in the Informatica domain. -saml Set this value to true to enable SAML authentication in the domain. Set this value to false to disable SAML authentication in the domain.
- idp_assertion_si Required if SAML authentication is enabled for the domain. The alias name AssertionSigningC gning_certificate specified when importing the identity provider assertion signing certificate ertificateAlias _aliaseAlias into the truststore file used for SAML authentication. -asca
-SamlTrustStoreDir saml_truststore_ Optional. The directory containing the custom truststore file required to use -std directory SAML authentication on gateway nodes within the domain. Specify the directory only, not the full path to the file. The default Informatica truststore is used if no truststore is specified.
- saml_truststore_ Required if you use a custom truststore. The password for the custom SamlTrustStorePa password truststore file. ssword -stp
See the Informatica Command Reference for instructions on using the infasetup DefineGatewayNode, the infasetup UpdateGatewayNode, and the infacmd isp SwitchToGatewayNode commands.
66 Chapter 5: SAML Authentication for Informatica Web Applications Configuring Web Applications to Use Different Identity Providers
You can configure Informatica web applications that run in a domain to use different identity providers. For example, you might configure Informatica Administrator to use AD FS as the identity provider, and configure Informatica Analyst to use PingFederate as the identity provider.
When you enable a domain to use SAML authentication, all web applications that run in the domain use the default identity provider you specify when you enable SAML authentication in the domain. For example, if you configure AD FS as the identity provider, all web applications use AD FS as the identity provider, unless you configure a web application to use a different identity provider.
You specify the default identity provider when you use one of the following options to enable SAML authentication:
• When you create the domain and install the Informatica services.
• When you run the infasetup defineDomain command to create the domain.
• When you run the infasetup updateDomainSamlConfig command to enable SAML authentication in an existing domain. You use the Administrator tool to configure a web application to use a different identify provider. To configure the Administrator tool or the monitoring application to use a different identity provider, you modify the SAML configuration on the node where the application runs. To configure other web applications to use a different identity provider, you modify the SAML configuration within the application process.
Prepare to Use an Identity Provider
Complete the following tasks to prepare an Informatica web application to use an identity provider.
1. Create an LDAP configuration for the identity provider store that contains Informatica web application user accounts. You also create an LDAP security domain, and then import the user accounts into the security domain. 2. Export the identity provider assertion signing certificate from the identity provider. 3. Import the identity provider assertion signing certificate into a truststore file on each gateway node in the domain. You can import the certificate into the Informatica default truststore file, or into a custom truststore file. If you change the alias name, import the corresponding certificate into the truststore file on each gateway node, and then restart the node. 4. Add one or more relying party trusts in the identity provider, and map LDAP attributes to the corresponding types used in security tokens issued by the identity provider. 5. Add the URL for the Informatica web application to the identity provider.
Configure Informatica Administrator to Use an Identity Provider
Use the Administrator tool to configure the Administrator tool or the monitoring application to use a SAML identity provider. You configure the Administrator tool or the monitoring application to use an identity provider on the node where the application runs.
1. In the Administrator tool, click the Services and Nodes tab. 2. Select the gateway node where the Administrator tool and the monitoring application run in the Domain Navigator.
Configuring Web Applications to Use Different Identity Providers 67 3. Click the edit icon next to SAML Configuration. 4. Enter the properties required to enable the application to use an identity provider. The following table describes the properties you enter:
Property Description
Identity Provider Optional. The URL for the identity provider server. You must specify the complete URL string. URL
Service Provider Optional. The relying party trust name or the service provider identifier for the domain as ID defined in the identity provider.
Assertion Optional. The alias name specified when importing the identity provider assertion signing Signing certificate into the truststore file used for SAML authentication. Certificate Alias If you change the alias name, import the corresponding certificate into the truststore file on each gateway node, and then restart the node.
Clock Skew Optional. The allowed time difference between the identity provider host system clock and Tolerance the system clock on the master gateway node. Optional. The lifetime of SAML tokens issued by the identity provider by is set according to the identity provider host system clock. The lifetime of a SAML token issued by the identity provider is valid if the start time or end time set in the token is within the specified number seconds of the system clock on the master gateway node. Values must be from 0 to 600 seconds. Set to -1 to use the value configured for the domain. Default is 120 seconds.
The following image shows the configuration to enable the Administrator tool to use AD FS as the identity provider. If you do not specify a value for a property, the domain uses the value set in the default SAML configuration.
5. Click OK. 6. Restart the application.
68 Chapter 5: SAML Authentication for Informatica Web Applications Configure an Informatica Web Application
Use the Administrator tool to configure an Informatica Web application to use a SAML identity provider.
1. In the Administrator tool, click the Services and Nodes tab. 2. Select the application or the application service in the Domain Navigator.
• To configure the Metadata Manager application to use an identity provider, select the Metadata Manager Service, and then click the Properties tab.
• To configure the Analyst tool application to use an identity provider, select the Analyst Service, and then click the Processes tab.
• To configure the Enterprise Data Preparation application to use an identity provider, select the Enterprise Data Preparation Service, and then click the Processes tab.
• To configure the Enterprise Data Catalog application or the Catalog Administrator application to use an identity provider, select the Catalog Service, and then click the Processes tab. 3. Click the edit icon next to SAML Configuration. 4. Enter the properties required to enable the web application to use an identity provider. The following table describes the properties you enter:
Property Description
Identity Provider Optional. The URL for the identity provider server. You must specify the complete URL string. URL
Service Provider Optional. The relying party trust name or the service provider identifier for the domain as ID defined in the identity provider.
Assertion Optional. The alias name specified when importing the identity provider assertion signing Signing certificate into the truststore file used for SAML authentication. Certificate Alias If you change the alias name, import the corresponding certificate into the truststore file on each gateway node, and then restart the node.
Clock Skew Optional. The allowed time difference between the identity provider host system clock and Tolerance the system clock on the master gateway node. Optional. The lifetime of SAML tokens issued by the identity provider by is set according to the identity provider host system clock. The lifetime of a SAML token issued by the identity provider is valid if the start time or end time set in the token is within the specified number seconds of the system clock on the master gateway node. Values must be from 0 to 600 seconds. Default is 120 seconds.
Configuring Web Applications to Use Different Identity Providers 69 The following image shows the configuration to enable Enterprise Data Catalog to use PingFederate as the identity provider:
5. Click OK. 6. Restart the application or application service after you configure an application to use a SAML identity provider.
70 Chapter 5: SAML Authentication for Informatica Web Applications C h a p t e r 6
Domain Security
This chapter includes the following topics:
• Domain Security Overview, 71
• Secure Communication Within the Domain, 72
• Secure Connections to a Web Application Service, 82
• Cipher Suites for the Informatica Domain, 86
• Secure Sources and Targets, 88
• Secure Data Storage, 89
• Application Services and Ports, 93
Domain Security Overview
You can enable options in the Informatica domain to configure secure communication between the components in the domain and between the domain and client components.
You can enable different options to secure specific components in the domain. You do not have to secure all components in the domain. For example, you can secure the communication between the services in the domain but not secure the connection between the Model Repository Service and the repository database.
Informatica uses the TCP/IP and HTTP protocols to communicate between components in the domain. The domain uses SSL certificates to secure communication between components.
When you install the Informatica services, you can enable secure communication for the services in the domain and for the Administrator tool. After installation, you can configure secure communication in the domain in the Administrator tool or from the command line.
During installation, the installer generates an encryption key to encrypt sensitive data, such as passwords, that are stored in the domain. You can provide the keyword that the installer uses to generate the encryption key. After installation, you can change the encryption key for sensitive data. You must upgrade the content of repositories to update the encrypted data.
You can enable secure communication in the following areas: Domain Within the domain, you can select options to enable secure communication for the following components:
• Between the Service Manager, the services in the domain, and the Informatica client tools
• Between the domain and the domain configuration repository
71 • Between the repository services and repository databases
• Between the PowerCenter Integration Service and DTM processes Web application services You can secure the connection between a web application service, such as the Analyst Service or the REST Operations Hub Service, and the browser. Sources and targets You can enable secure communication between the Data Integration Service and PowerCenter Integration Service and the source and target databases. Data storage Informatica encrypts sensitive data, such as passwords, when it stores data in the domain. Informatica generates an encryption key based on a keyword that you provide during installation. Informatica uses the encryption key to encrypt and decrypt sensitive data that are stored in the domain.
Secure Communication Within the Domain
You can use the Secure Communication option to secure the connection between services and between services and the service managers in the domain. Additionally, you can enable security for workflows and use secure databases for the repositories that you create in the domain.
After you secure the domain, configure the Informatica client applications to work with a secure domain.
Secure Communication for Services and the Service Manager
You can configure secure communication within the domain during installation. After installation, you can configure secure communication for the domain on the Administrator tool or from the command line.
Informatica provides an SSL certificate that you can use to secure the domain. However, you should provide a custom SSL certificate for domains that require a higher level of security, such as a domain in a production environment. Specify the keystore and truststore files that contain the SSL certificates you want to use.
Note: Informatica provides SSL certificates for evaluation purposes. If you do not provide an SSL certificate, Informatica uses the same default private key for all Informatica installations. The security of your domain could be compromised. Provide an SSL certificate to ensure a high level of security for the domain. The certificate that you provide can be self-signed or from a certificate authority (CA).
When you configure secure communication for the domain, you secure the connections between the following components:
• The Service Manager and all services running in the domain
• The Data Integration Service and the Model Repository Service
• The Data Integration Service and the workflow processes
• The PowerCenter Integration Service and the PowerCenter Repository Service
• The domain services and the Informatica client tools and command line programs
Requirements for Secure Communication within the Domain Before you enable secure communication within the domain, ensure that the following requirements are met:
72 Chapter 6: Domain Security You created a certificate signing request (CSR) and private key. You can use keytool or OpenSSL to create the CSR and private key. If you use RSA encryption, you must use more than 512 bits. You have a signed SSL certificate. The certificate can be self-signed or CA signed. Informatica recommends a CA signed certificate. You imported the certificate into keystores.
You must have a keystore in PEM format named infa_keystore.pem and a keystore in JKS format named infa_keystore.jks. The keystore files must contain the root and intermediate SSL certificates.
Note: The password for the keystore in JKS format must be the same as the private key pass phrase used to generate the SSL certificate.
You imported the certificate into truststores.
You must have a truststore in PEM format named infa_truststore.pem and a truststore in JKS format named infa_truststore.jks. The truststore files must contain the root, intermediate, and end user SSL certificates. The keystores and truststores are in the correct directory.
If you enable secure communication during installation, the keystore and truststore must be in a directory that is accessible to the installer. If you enable secure communication after installation, the keystore and truststore must be in a directory that is accessible to the command line programs.
For more information about how to create a custom keystore and truststore, see the Informatica How-To Library article How to Create Keystore and Truststore Files for Secure Communication in the Informatica Domain: https://kb.informatica.com/h2l/HowTo%20Library/1/0700-CreateKeystoresAndTruststores-H2L.pdf
After you secure the domain, configure the Informatica client applications to work with a secure domain.
Enabling Secure Communication for the Domain from the Command Line Use the infacmd and infasetup commands to enable secure communication for the domain. After you enable secure communication, you must restart the domain for the change to take effect.
To use your SSL certificate files, specify the keystore and truststore files when you run the infasetup command.
To configure secure domain communication from the command line, use the following commands: infacmd isp UpdateDomainOptions Use the UpdateDomainOptions command to set the secure communication mode for the domain. infasetup UpdateGatewayNode Use the UpdateGatewayNode command to enable secure communication for the Service Manager on a gateway node in a domain. If the domain has multiple gateway nodes, run the UpdateGatewayNode command on each gateway node.
Secure Communication Within the Domain 73 infasetup UpdateWorkerNode Use the UpdateWorkerNode command to enable secure communication for the Service Manager on a worker node in a domain. If the domain has multiple worker nodes, run the UpdateWorkerNode command on each worker node.
1. Verify that the domain you want to secure is running. 2. Update the domain. Run the following command with the required options and arguments:
• Windows: infacmd isp UpdateDomainOptions
• UNIX: infacmd.sh isp UpdateDomainOptions To configure secure communication for the domain, include the following option when you run the infacmd command:
Option Argument Description
-DomainOptions option_name=value Set the following option to configure secure -do communication for the domain: TLSMode=True
3. Shut down the domain. The domain must be shut down before you run the infasetup commands. 4. Run infasetup with the required options and arguments. Enter the following command:
• Windows: infasetup UpdateGatewayNode or infasetup UpdateWorkerNode
• UNIX: infasetup.sh UpdateGatewayNode or infasetup.sh UpdateWorkerNode To configure secure communication on the nodes, run the commands with the following options:
Option Argument Description
-EnableTLS enable_tls Configures secure communication for the services in -tls the Informatica domain.
-NodeKeystore node_keystore_directo Optional if you use the default SSL certificate from -nk ry Informatica. Required if you use your SSL certificate. Directory that contains the keystore files. The Informatica domain requires the SSL certificate in PEM format and in Java Keystore (JKS) files. The directory must contain keystore files in PEM and JKS formats. The keystore files must be named infa_keystore.jks and infa_keystore.pem You can use the same keystore file for multiple nodes.
-NodeKeystorePass node_keystore_passw Optional if you use the default SSL certificate from -nkp ord Informatica. Required if you use your SSL certificate. Password for the infa_keystore.jks file.
74 Chapter 6: Domain Security Option Argument Description
-NodeTruststore node_truststore_direct Optional if you use the default SSL certificate from -nt ory Informatica. Required if you use your SSL certificate. Directory that contains the truststore files. The Informatica domain requires the SSL certificate in PEM format and in Java Keystore (JKS) files. The directory must contain truststore files in PEM and JKS formats. The truststore files must be named infa_truststore.jks and infa_truststore.pem. You can use the same truststore file for multiple nodes.
-NodeTruststorePass node_truststore_pass Optional if you use the default SSL certificate from -ntp word Informatica. Required if you use your SSL certificate. Password for the infa_truststore.jks file.
5. Run the infasetup command on each node in the domain. If you have multiple gateway nodes in the domain, run infasetup UpdateGatewayNode on each gateway node. If you have multiple worker nodes, run infasetup UpdateWorkerNode on each worker node. You must use the same keystore and truststore files for all nodes in the domain. 6. Restart the domain. After you complete updating all nodes in the domain, you must update the machines that host the Informatica client tools. Set the location of the SSL certificates in the Informatica truststore environment variables.
Enabling Secure Communication for the Domain in the Administrator Tool You can use the Administrator tool to enable secure communication for the domain. When you enable secure communication in the Administrator tool, you must also run infasetup commands to update the nodes.
When you enable the Secure Communication option in the Administrator tool, you also need to run the infasetup command to update Informatica configuration files on each node. To specify the SSL certificate files to use, specify the keystore and truststore files when you run the infasetup command.
To update the Informatica configuration files on each node, use the following commands: infasetup UpdateGatewayNode Use the UpdateGatewayNode command to enable secure communication for the Service Manager on a gateway node in a domain. If the domain has multiple gateway nodes, run the UpdateGatewayNode command on each gateway node. infasetup UpdateWorkerNode Use the UpdateWorkerNode command to enable secure communication for the Service Manager on a worker node in a domain. If the domain has multiple worker nodes, run the UpdateWorkerNode command on each worker node.
To enable secure domain communication from the Administrator tool, perform the following steps:
1. On the Administrator tool, select the domain. 2. In the contents panel, click the Properties view. 3. Go to the General Properties section and click Edit. 4. On the Edit General Properties window, select Enable Secure Communication. 5. Click OK
Secure Communication Within the Domain 75 6. Shut down the domain. The domain must be shut down before you run the infasetup commands. 7. Run infasetup with the required options and arguments. Enter the following command:
• Windows: infasetup UpdateGatewayNode or infasetup UpdateWorkerNode
• UNIX: infasetup.sh UpdateGatewayNode or infasetup.sh UpdateWorkerNode To configure secure communication on the nodes, run the commands with the following options:
Option Argument Description
-EnableTLS enable_tls Configures secure communication for the services in -tls the Informatica domain.
-NodeKeystore node_keystore_directo Optional if you use the default SSL certificate from -nk ry Informatica. Required if you use your SSL certificate. Directory that contains the keystore files. The Informatica domain requires the SSL certificate in PEM format and in Java Keystore (JKS) files. The directory must contain keystore files in PEM and JKS formats. The keystore files must be named infa_keystore.jks and infa_keystore.pem You can use the same keystore file for multiple nodes.
-NodeKeystorePass node_keystore_passw Optional if you use the default SSL certificate from -nkp ord Informatica. Required if you use your SSL certificate. Password for the infa_keystore.jks file.
-NodeTruststore node_truststore_direct Optional if you use the default SSL certificate from -nt ory Informatica. Required if you use your SSL certificate. Directory that contains the truststore files. The Informatica domain requires the SSL certificate in PEM format and in Java Keystore (JKS) files. The directory must contain truststore files in PEM and JKS formats. The truststore files must be named infa_truststore.jks and infa_truststore.pem. You can use the same truststore file for multiple nodes.
-NodeTruststorePass node_truststore_pass Optional if you use the default SSL certificate from -ntp word Informatica. Required if you use your SSL certificate. Password for the infa_truststore.jks file.
8. Run the infasetup command on each node in the domain. If you have multiple gateway nodes in the domain, run infasetup UpdateGatewayNode on each gateway node. If you have multiple worker nodes, run infasetup UpdateWorkerNode on each worker node. You must use the same keystore and truststore files for all nodes in the domain. 9. Restart the domain. After you complete updating all nodes in the domain, you must update the machines that host the Informatica client tools. Set the location of the SSL certificates in the Informatica truststore environment variables.
76 Chapter 6: Domain Security Configuring the Informatica Client Applications to Work with a Secure Domain When you enable secure communication within the domain, you also secure connections between the domain and Informatica client applications, such as the Developer tool. You might need to specify the location and password for the truststore files that you use to secure the domain in environment variables. You set the environment variables on machines hosting client applications that access services within the domain.
SSL certificates that are used to secure an Informatica domain are contained in truststore files named infa_truststore.jks and infa_truststore.pem. The truststore files must be available on each client host.
You might need to set the following environment variables on each client host: INFA_TRUSTSTORE
Set this variable to the directory that contains the infa_truststore.jks and infa_truststore.pem truststore files. INFA_TRUSTSTORE_PASSWORD Set this variable to the password for the truststore. The password must be encrypted. Use the command line program pmpasswd to encrypt the password.
Informatica provides an SSL certificate in default truststore files that you can use to secure the domain. When you install the Informatica clients, the installer sets the environment variables and installs the truststore files in the following directory by default:
If you use the default Informatica SSL certificate, and the infa_truststore.jks and infa_truststore.pem files are in the default directory, you do not need to set the INFA_TRUSTSTORE or INFA_TRUSTSTORE_PASSWORD environment variables.
You must set the INFA_TRUSTSTORE and INFA_TRUSTSTORE_PASSWORD environment variables on each client host in the following scenarios:
You use a custom SSL certificate to secure the domain.
If you provide an SSL certificate to use to secure the domain, import the certificate into truststore files named infa_truststore.jks and infa_truststore.pem, and then copy the truststore files to each client host. You must specify the location of the files and the truststore password.
Important: If you push processing to a compute cluster and the Data Integration Service runs on a grid, import the certificates one time and then copy them to each Data Integration Service on the grid. Each time you import a certificate, the contents of the certificate are identical, but the hex values are different. As a result, concurrent mappings that run on the grid fail with initialization errors.
You replace the default Informatica truststore files with your own truststore files in the default directory.
If you replace the default the infa_truststore.jks and infa_truststore.pem truststore files with your own truststore files in the default Informatica directory, you must specify the truststore password. The truststore files must have the same filenames as the default truststore files. You use the default Informatica SSL certificate, but the truststore files are not in the default Informatica directory.
If you use the default Informatica SSL certificate, but the default infa_truststore.jks and infa_truststore.pem truststore files are not in the default directory, you must specify the location of the files and the truststore password.
Secure Communication Within the Domain 77 Secure Domain Configuration Repository Database
The Informatica domain configuration repository stores configuration information and user account privileges and permissions. When you create an Informatica domain, you must create a domain configuration repository.
You can create a domain configuration repository on a database that is secured with the SSL protocol. The SSL protocol uses SSL certificates stored in a truststore file. Access to the secure database access requires a truststore that contains the certificates for the database.
You can create a secure domain configuration repository database when you install the Informatica services and create a domain. For more information about configuring a secure domain configuration repository during installation, see the Informatica installation guides.
After installation, you can configure a secure domain configuration repository database from the command line.
Note: Before you configure a secure domain configuration repository database after installation, you must enable secure communication for the domain.
You can create a secure domain configuration repository on the following databases:
• Oracle
• Microsoft SQL Server
• IBM DB2
Configuring a Secure Domain Configuration Repository Database After installation, you can change the domain configuration repository to a secure database. You can use a secure domain configuration repository database only if you enable secure communication for the domain.
You must shut down the domain before you change the domain configuration repository database. Use the infasetup command to back up the domain configuration repository database and to restore it in a secure database. When you restore the domain configuration repository in the secure database, specify the security parameters for the secure database. Then update the gateway node with the domain configuration repository information.
To back up and restore the repository database and update the gateway node, use the following commands: infasetup BackupDomain Use the BackupDomain option to back up data from the domain configuration repository database. infasetup RestoreDomain Use the RestoreDomain option to restore domain configuration repository data to a secure database. infasetup UpdateGatewayNode Use the UpdateGatewayNode option update the domain configuration repository settings in the gateway nodes of the domain.
To change the domain configuration repository to a secure database, complete the following steps:
1. Verify that secure communication is enabled for the domain. The domain must be secure before you can use a secure database for the domain configuration repository. 2. Shut down the domain. 3. Run the infasetup BackupDomain command and specify the database connection information.
78 Chapter 6: Domain Security When you run the BackupDomain command, infasetup backs up most of the domain configuration database tables to the file name you specify. Note: If the infasetup backup or restore command fails with a Java memory error, increase the system memory available for infasetup. To increase system memory, set the -Xmx value in the INFA_JAVA_CMD_OPTS environment variable. 4. Use the database backup utility to manually back up additional repository tables that the infasetup command does not back up. Back up the contents of the following table:
• ISP_RUN_LOG 5. To restore the domain configuration repository in the secure database, run the infasetup RestoreDomain command and specify the database connection information. In addition to the connection information, specify the following options required for the secure database:
Option Argument Description
-DatabaseTlsEnabled database_tls_enabled Required. Indicates whether the database into which -dbtls the domain configuration repository will be restored is a secure database. Set this option to True.
-DatabaseTruststoreLocation database_truststore_l Required. Path and file name of the truststore file -dbtl ocation that contains the SSL certificate for the database.
-DatabaseTruststorePassword database_truststore_p Required. Password for the database truststore file -dbtp assword for the secure database.
In the connection string, include the following security parameters: EncryptionMethod Required. Indicates whether data is encrypted when transmitted over the network. This parameter must be set to SSL. ValidateServerCertificate Optional. Indicates whether Informatica validates the certificate that the database server sends. If this parameter is set to True, Informatica validates the certificate that the database server sends. If you specify the HostNameInCertificate parameter, Informatica also validates the host name in the certificate. If this parameter is set to False, Informatica does not validate the certificate that the database server sends. Informatica ignores any truststore information that you specify. Default is True.
HostNameInCertificate Optional. Host name of the machine that hosts the secure database. If you specify a host name, Informatica validates the host name included in the connection string against the host name in the SSL certificate. cryptoProtocolVersion Required. Specifies the cryptographic protocol to use to connect to a secure database. You can set the parameter to cryptoProtocolVersion=TLSv1.1 or cryptoProtocolVersion=TLSv1.2 based on the cryptographic protocol used by the database server.
Secure Communication Within the Domain 79 6. Use the database restore utility to restore the repository tables that you manually backed up. Restore the following table:
• ISP_RUN_LOG 7. To update the nodes in the domain with information about the secure domain configuration repository, run the infasetup UpdateGatewayNode command and specify the secure database connection information. In addition to the node options, specify the following options required for the secure database:
Option Argument Description
-DatabaseTlsEnabled database_tls_enabled Required. Indicates the database used for the domain -dbtls configuration repository is a secure database. Set this option to True.
-DatabaseConnectionString database_connection_ Required. Connection string to use to connect to the -cs string secure database. The connection string must include the security parameters that you included in the connection string when you ran the infasetup RestoreDomain command in step 5
-DatabaseTruststorePassword database_truststore_p Required. Password for the database truststore file -dbtp assword for the secure database.
If you have multiple gateway nodes in the domain, run infasetup UpdateGatewayNode on each gateway node.
8. Restart the domain.
Secure PowerCenter Repository Database
When you create a PowerCenter Repository Service, you can create the associated PowerCenter repository on a database secured with the SSL protocol.
The PowerCenter Repository Service connects to the PowerCenter repository database through native connectivity.
When you create a PowerCenter repository on a secure database, verify that the database client files contain the secure connection information for the database. For example, if you create a PowerCenter repository on a secure Oracle database, configure the Oracle database tnsnames.ora and sqlnet.ora client files with the secure connection information.
Secure Model Repository Database
When you create a Model Repository Service, you can create the associated Model repository in a database secured with the SSL protocol.
The Model Repository Service connects to the Model repository database through JDBC drivers.
1. Set up a database secured with the SSL protocol. 2. In the Administrator tool, create a Model Repository Service. 3. In the New Model Repository Service dialog box, enter the general properties for the Model Repository Service and click Next.
80 Chapter 6: Domain Security 4. Enter the database properties and the JDBC connection string for the Model Repository Service. To connect to a secure database, enter the secure database parameters in the Secure JDBC Parameters field. Informatica treats the value of Secure JDBC Parameters field as sensitive data and stores the parameter string encrypted. The following list describes the secure database parameters: EncryptionMethod Required. Indicates whether data is encrypted when transmitted over the network. This parameter must be set to SSL. ValidateServerCertificate Optional. Indicates whether Informatica validates the certificate that the database server sends. If this parameter is set to True, Informatica validates the certificate that the database server sends. If you specify the HostNameInCertificate parameter, Informatica also validates the host name in the certificate. If this parameter is set to False, Informatica does not validate the certificate that the database server sends. Informatica ignores any truststore information that you specify. Default is True. HostNameInCertificate Optional. Host name of the machine that hosts the secure database. If you specify a host name, Informatica validates the host name included in the connection string against the host name in the SSL certificate. cryptoProtocolVersion Required. Specifies the cryptographic protocol to use to connect to a secure database. You can set the parameter to cryptoProtocolVersion=TLSv1.1 or cryptoProtocolVersion=TLSv1.2 based on the cryptographic protocol used by the database server. TrustStore Required. Path and file name of the truststore file that contains the SSL certificate for the database. If you do not include the path for the truststore file, Informatica looks for the file in the following default directory:
Secure Communication for Workflows and Sessions
By default, when you enable secure communication option for the domain, Informatica secures the connection between the Data Integration Service and PowerCenter Integration Service and the DTM processes.
In addition, if you run PowerCenter sessions on a grid, you can enable an option to secure the data communication between the DTM processes.
Secure Communication Within the Domain 81 To enable secure data communication between DTM processes in PowerCenter sessions, select the Enable Data Encryption option for the PowerCenter Integration Service.
Note: PowerCenter sessions require more CPU and memory when the DTM processes run in secure mode. Before you enable secure data communication between DTM processes for PowerCenter sessions, determine whether the domain resources are adequate for the additional load.
Enabling Secure Communication for PowerCenter DTM Processes To secure the connection between the DTM processes in PowerCenter sessions running on a grid, configure the PowerCenter Integration Service to enable the data encryption for DTM processes.
1. In the Navigator of the Administrator tool, select the PowerCenter Integration Service. 2. In the contents panel, click the Properties view. 3. Go to the PowerCenter Integration Service Properties section and click Edit. 4. On the Edit PowerCenter Integration Service Properties window, select Enable Data Encryption. 5. Click OK. When you run a PowerCenter session on a grid, the DTM processes send encrypted data when they communicate with other DTM processes.
Secure Connections to a Web Application Service
To protect data that is transmitted between a web application service and the browser, secure the connection between the web application service and the browser.
You can secure the following connections: Connections to the Administrator tool You can secure the connection between the Administrator tool and the browser. Connections to web application services You can secure the connection between the following web application services and the browser:
• Analyst Service
• Metadata Manager Service
• REST Operations Hub Service
• Test Data Manager Service
• Web Services Hub Console Service
Requirements for Secure Connections to Web Application Services
Before you secure the connection to a web application service, ensure that the following requirements are met:
You created a certificate signing request (CSR) and private key. You can use keytool or OpenSSL to create the CSR and private key. If you use RSA encryption, you must use more than 512 bits.
82 Chapter 6: Domain Security You have a signed SSL certificate. The certificate can be self-signed or CA signed. Informatica recommends a CA signed certificate. You imported the certificate into a keystore in JKS format. A keystore must contain only one certificate. If you use a unique certificate for each web application service, create a separate keystore for each certificate. Alternatively, you can use a shared certificate and keystore. If you use the installer-generated SSL certificate for the Administrator tool, you do not need to import the certificate into a keystore in JKS format. The keystore is in an accessible directory. The keystore must be in a directory that is accessible to the Administrator tool and the command line programs.
Enabling Secure Connections to the Administrator Tool
After installation, you can configure secure connections to the Administrator tool from the command line.
You must update the gateway nodes in the domain with the properties for a secure connection between the browser and the Informatica Administrator service.
To update the gateway node with secure connection properties, run the following command: infasetup UpdateGatewayNode
Include the following options:
Option Argument Description
-HttpsPort AdminConsole_https_p Port number to use for a secure connection to the -hs ort Informatica Administrator service.
-KeystoreFile AdminConsole_Keystor Path and file name of the keystore file to use for the -kf e_File HTTPS connection to the Informatica Administrator service.
-KeystorePass AdminConsole_Keystor Password for the keystore file. -kp e_Password
If you have multiple gateway nodes in the domain, run the command on each gateway node.
Informatica Web Application Services
Configure a secure connection for a web application service when you create or configure it. Each application service has specific properties for the secure HTTPS connection.
Secure Connections to a Web Application Service 83 Security for the Analyst Tool When you create the Analyst Service, you can configure the secure HTTPS properties for the Analyst tool.
To secure the connection between the browser and the Analyst Service, configure the following Analyst Service properties:
Property Description
Enable Secure Communication Select to enable a secure connection between the Analyst tool and the Analyst Service.
HTTPS Port Port number that the Informatica Analyst web application runs on when you enable the Transport Layer Security (TLS) protocol. Use a different port number than the HTTP port number.
Keystore File Directory where the keystore file that contains the digital certificates is stored.
Keystore Password Plain-text password for the keystore file. If this property is not set, the Analyst Service uses the default password changeit.
SSL Protocol Informatica recommends that you leave this field blank. The version of TLS enabled depends on the value. A blank field enables the highest version of TLS available. If you enter a value, earlier versions of TLS might be enabled. The behavior is based on the Java version for your environment. For more information, see the documentation for your Java version.
Security for REST Operations Hub Service When you use the REST Operations Hub Service, you can configure the secure HTTPS properties for the REST Operations Hub.
To secure the connection between the browser and the REST Operations Hub Service, configure the following REST Operations Hub Service properties:
Property Description
HTTP Port Unique HTTP port number for the REST Operations Hub Service process when the service uses the HTTP protocol. Default is 6555.
HTTPS Port Port number that the REST Operations Hub Service runs on when you enable the Transport Layer Security (TLS) protocol. Use a different port number than the HTTP port number.
Enable Transport Select to enable a secure connection between the REST Operations Hub Service and REST client. Layer Security
Keystore File Directory where the keystore file that contains the digital certificates is stored.
Keystore Plain-text password for the keystore file. If this property is not set, the REST Operations Hub Password Service uses the default password.
SSL Protocol A blank field enables the highest version of TLS available. The version of TLS enabled depends on the value. If you enter a value, earlier versions of TLS might be enabled. The behavior is based on the Java version for your environment. For more information, see the documentation for your Java version.
84 Chapter 6: Domain Security Security for the Web Services Hub Console When you create the Web Services Hub Service, you can configure the secure HTTPS properties for the Web Services Hub console.
To secure the connection between the browser and the Web Services Hub Service, configure the following Web Services Hub Service properties:
Property Description
URLScheme Indicates the security protocol that you configure for the Web Services Hub: - HTTP. Run the Web Services Hub on HTTP only. - HTTPS. Run the Web Services Hub on HTTPS only. - HTTP and HTTPS. Run the Web Services Hub in HTTP and HTTPS modes.
HubPortNumber Port number for the Web Services Hub on HTTPS. Appears when the URL scheme selected (https) includes HTTPS. Required if you choose to run the Web Services Hub on HTTPS. Default is 7343.
Keystore File Path and file name of the keystore file that contains the keys and certificates that are required for an HTTPS connection.
Keystore Password Password for the keystore file. If this property is not set, the Web Services Hub uses the default password changeit.
Security for Metadata Manager When you create the Metadata Manager Service, you can configure the secure HTTPS properties for the Metadata Manager web application.
To secure the connection between the browser and the Metadata Manager Service, configure the following Metadata Manager Service properties:
Property Description
Enable Secure Indicates that you want to configure a secure connection for the Metadata Manager web Sockets Layer application. Note: This property is displayed when you create a Metadata Manager Service. To secure the connection for an existing Metadata Manager Service, set the URL Scheme configuration property to HTTPS.
Port Number Port number that the Metadata Manager application runs on. Default is 10250.
Keystore File Keystore file that contains the keys and certificates required if you configure a secure connection for the Metadata Manager web application. Note: The Metadata Manager Service uses RSA encryption. Therefore, Informatica recommends that you use a security certificate that was generated with the RSA algorithm.
Keystore Password for the keystore file. Password
Secure Connections to a Web Application Service 85 Cipher Suites for the Informatica Domain
You can configure the cipher suites that the Informatica domain uses when it encrypts connections within the Informatica domain. Connections from the Informatica domain to resources outside of the domain are not affected by the cipher suite configuration.
When you enable secure communication for the Informatica domain or secure connections to web application services, the Informatica domain uses cipher suites to encrypt traffic.
Informatica creates the effective list of cipher suites that it uses based on the following lists: Blacklist List of cipher suites that you want the Informatica domain to block. When you blacklist a cipher suite, the Informatica domain removes the cipher suite from the effective list. You can add cipher suites that are on the default list to the blacklist. Default list List of cipher suites that Informatica domain supports by default. If you do not configure a whitelist or blacklist, the Informatica domain uses the default list as the effective list. For more information, see Appendix C, “Default List of Cipher Suites” on page 230 Whitelist List of cipher suites that you want the Informatica domain to support. When you add a cipher suite to the whitelist, the Informatica domain adds the cipher suite to the effective list. You do not need to add cipher suites that are on the default list to the whitelist.
Informatica creates the effective list by adding cipher suites from the whitelist to the default list and removing cipher suites on the blacklist from the default list.
Consider the following guidelines for effective lists:
• To use a custom effective list for secure connections to web clients, the Informatica domain must use secure communication within the domain. If the domain does not use secure communication, Informatica uses the default list as the effective list.
• The effective list only governs connections within the Informatica domain. Connections to data sources do not use the effective list.
• The effective list must contain at least one cipher suite that TLS v1.1 or 1.2 supports.
• The effective list must be a valid cipher suite for Windows, the Java Runtime Environment, and OpenSSL.
Create the Cipher Suite Lists
To configure the Informatica domain to use specific cipher suites, create a whitelist specifying the additional cipher suites to support. You can also create a blacklist specifying the cipher suites to block.
Work with your network security administrator to determine the cipher suites that are suitable for the Informatica domain.
The list of cipher suites must be a comma-separated list. Use the Internet Assigned Numbers Authority (IANA) names for the cipher suites in the list. Alternatively, you can use a regular Java expression.
You configure the whitelist and blacklist with infasetup. You can provide the lists directly in command parameters or specify plain-text files that contain comma-separated lists.
The following sample text shows a list with two cipher suites: TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_3DES_EDE_CBC_SHA
86 Chapter 6: Domain Security You can configure the whitelist and blacklist of cipher suites for the Informatica domain when you create the domain. Use infasetup to create the Informatica domain, gateway nodes, and worker nodes. For more information about infasetup commands, see the Informatica Command Reference.
Alternatively, you can configure the whitelist and blacklist for an existing Informatica domain.
Configure the Informatica Domain with a New Effective List of Cipher Suites
To configure the cipher suites that the Informatica domain uses, you must update the Informatica domain, all gateway nodes, and all worker nodes with the same whitelist and blacklist.
Note: Changes to the blacklist, whitelist, and effective list are not cumulative. Informatica creates a new effective list based on the blacklist, default list, and whitelist when you run the command. The new effective list overwrites the previous list.
To configure an existing Informatica domain with a new effective list of cipher suites, perform the following steps:
1. Shutdown the Informatica domain. 2. Optionally, run the infasetup listDomainCiphers command to view the lists of cipher suites that a domain or node supports or blocks. For example, run the following command to view all the cipher suite lists: infasetup listDomainCiphers -l ALL -dc true 3. Run the infasetup updateDomainCiphers command on a gateway node and specify a whitelist, blacklist, or both. For example, run the following command to add one cipher suite to the effective list and remove two cipher suites from the effective list: infasetup updateDomainCiphers -cwl TLS_DHE_DSS_WITH_AES_128_CBC_SHA -cbl TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_3DES_EDE_CBC_SHA 4. Run the infasetup updateGatewayNode command on each gateway node and specify a whitelist, blacklist, or both. Use the same whitelist and blacklist as the domain. For example, run the following command: infasetup updateGatewayNode -cwl TLS_DHE_DSS_WITH_AES_128_CBC_SHA -cbl TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_3DES_EDE_CBC_SHA 5. Update each worker node with the same set of cipher suites as the Informatica domain. Use the same whitelist and blacklist as the domain. For example, run the following command: infasetup updateWorkerNode -cwl TLS_DHE_DSS_WITH_AES_128_CBC_SHA -cbl TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_3DES_EDE_CBC_SHA 6. Start the Informatica domain. 7. Optionally, run the infacmd isp listDomainCiphers command to view the lists of cipher suites that a domain or node uses. For example, run the following command to view the effective list of cipher suites that the domain uses: infacmd isp listDomainCiphers -l EFFECTIVE
Cipher Suites for the Informatica Domain 87 Secure Sources and Targets
Informatica uses connection objects to connect to relational databases as source or target. You can create a connection object to a relational database that is secured with an SSL certificate.
You create PowerCenter connection objects in the Workflow Manager. You create Data Service , Data Quality, or Profiling connections in the Developer tool or in the Administrator tool.
You can create a connection to a secure source or target on the following databases:
• Oracle
• Microsoft SQL Server
• IBM DB2
Data Integration Service Sources and Targets
When you create a connection object for the Data Integration Service to process mappings, data profiles, scorecards, or SQL data services, you can define a connection to a database secured with the SSL protocol.
The Data Integration Service connects to the source or target database through JDBC drivers. When you configure the connection to a secure repository database, you must include the secure connection parameters in the JDBC connection string.
1. Set up a database secured with the SSL protocol to use as a source or target. 2. In the Administrator tool, create a connection. 3. In the New Connection dialog box, select the connection type. and click OK. You can create a connection to a secure DB2, Microsoft SQL Server, or Oracle database. 4. In the New Connection - Step 1 of 3 dialog box, enter the properties for the connection and click Next. 5. In the New Connection - Step 2 of 3 page, enter the connection string to the database. To connect to a secure database, enter the secure database parameters in the Advanced JDBC Security Options field. Informatica treats the value of the Advanced JDBC Security Options field as sensitive data and stores the parameter string encrypted. The following list describes the secure database parameters: EncryptionMethod Required. Indicates whether data is encrypted when transmitted over the network. This parameter must be set to SSL. ValidateServerCertificate Optional. Indicates whether Informatica validates the certificate that the database server sends. If this parameter is set to True, Informatica validates the certificate that the database server sends. If you specify the HostNameInCertificate parameter, Informatica also validates the host name in the certificate. If this parameter is set to False, Informatica does not validate the certificate that the database server sends. Informatica ignores any truststore information that you specify. Default is True.
88 Chapter 6: Domain Security HostNameInCertificate Optional. Host name of the machine that hosts the secure database. If you specify a host name, Informatica validates the host name included in the connection string against the host name in the SSL certificate. TrustStore Required. Path and file name of the truststore file that contains the SSL certificate for the database. TrustStorePassword Required. Password for the truststore file for the secure database. Note: Informatica appends the secure JDBC parameters to the connection string. If you include the secure JDBC parameters directly to the connection string, do not enter any parameters in the Advanced JDBC Security Options field. 6. Test the connection to verify that the connection to the secure database is valid. 7. Complete the process to create the relational connection.
PowerCenter Sources and Targets
When you create a connection object for a PowerCenter session, you can define a connection to a database secured with the SSL protocol.
You can connect to relational PowerCenter sources and targets through native connectivity or ODBC drivers.
If you connect to a secure relational source or target through native connectivity, verify that the database client contains the connection information for the secure database. For example, if you connect to a PowerCenter target on a secure Oracle database, configure the Oracle database client file tnsnames.ora with the connection information for the secure database.
If you connect to a secure relational source or target through ODBC drivers, verify that the database client contains the connection information for the secure database and the ODBC data source correctly defines the connection to the secure database.
Secure Data Storage
Informatica encrypts sensitive data, such as passwords and secure connection parameters, before it stores the data in the domain configuration repository. Informatica uses a keyword that you provide to create an encryption key with which to encrypt sensitive data.
During installation, you must provide a keyword for the installer to use to generate the encryption key for the domain. All nodes in a domain must use the same encryption key. If you install on multiple nodes, the installer uses the same encryption key for all nodes in the domain. For more information about generating an encryption key for the domain during installation, see the Informatica installation guides.
After installation, you can change the encryption key for the domain. Run the infasetup command to generate an encryption key and change the encryption key for the domain. After you change the encryption key for the domain, you must upgrade the content of the repositories in the domain to update the encrypted data.
Note: You must keep the name of the domain, the keyword for the encryption key, and the encryption key file in a secure location. The domain name, keyword, and encryption key are required when you change the encryption key for the domain or move a repository to another domain. If you lose the encryption key file, you need the keyword to generate the encryption key again. If you lose the keyword and encryption key, you cannot change the encryption key for the domain or move a repository to another domain.
Secure Data Storage 89 Secure Directory on UNIX
When you install Informatica, the installer creates a directory to store Informatica files that require restricted access, such as the domain encryption key file. On UNIX, the installer assigns different permissions for the directory and the files in the directory.
By default, the installer creates the following directory within the Informatica installation directory to store the encryption key:
The /keys directory contains the encryption key file for the node. If you configure the domain to use Kerberos authentication, the directory also contains the Kerberos keytab files.
During installation, you can specify a different directory in which to store the encryption file. The installer assigns the same permissions to the specified directory as the default directory.
The /keys directory and the files in the directory have the following permissions: Directory Permissions
The owner of the directory has -wx permissions to the directory but no r permission. The owner of the directory is the user account used to run the installer. The group to which the owner belongs also has - wx permissions to the directory but no r permission.
For example, the user account ediqa owns the directory and belongs to the infaadmin group. The ediqa user account and the infaadmin group have the following permissions: -wx-wx---
The ediqa user account and the infaadmin group can write to and run files in the directory. They cannot display the list of files in directory but they can list a specific file by name.
If you know the name of a file in the directory, you can copy the file from the directory to another location. If you do not know the name of the file, you must change the permission for the directory to include the read permission before you can copy the file. You can use the command chmod 730 to give read permission to the owner of the directory and subdirectories.
For example, you need to copy the encryption key file named siteKey to a temporary directory to make it accessible to another node in the domain. Run the command chmod 730 on the
After you complete copying the files, change the permissions for the directory back to write and execute permissions. You can use the command chmod 330 to remove the read permission.
Note: Do not use the -R option to recursively change the permissions for the directory and files. The directory and the files in the directory have different permissions.
File Permissions
The owner of the files in the directory has rwx permissions to the files. The owner of the files in the directory is the user account used to run the installer. The group to which the owner belongs also has rwx permissions to the files in the directory.
The owner and group have full access to the file and can display or edit the file in the directory.
Note: You must know the name of the file to be able to list or edit the file.
Changing the Encryption Key from the Command Line
After installation, you can change the encryption key for the domain from the command line. You must shut down the domain before you change the encryption key.
Use the infasetup command to generate an encryption key and configure the domain to use the new encryption key.
90 Chapter 6: Domain Security The following infasetup commands generate and change the encryption key: generateEncryptionKey Generates an encryption key in a file named sitekey. If the directory specified for the encryption key contains a file named sitekey, Informatica renames the file to siteKey_old. migrateEncryptionKey Changes the encryption key used to store sensitive data in the Informatica domain.
To change the encryption key for a domain, complete the following steps:
1. Shut down the domain. 2. Back up the domain before you change the encryption key. To ensure that you can recover the domain if you encounter problems when you change the encryption key, back up the domain before you run the infasetup commands. 3. To generate an encryption key for the domain, run the infasetup generateEncryptionKey command. Specify the following options required to generate an encryption key:
Option Argument Description
-keyword keyword The text string used as the base word from which to -kw generate an encryption key. The keyword must meet the following criteria: - From 8 to 20 characters long - Includes at least one uppercase letter - Includes at least one lowercase letter - Includes at least one number - Does not contain spaces
-domainName domain_name Name of the Informatica domain. -dn
-encryptionKeyLocation encryption_key_location Directory that contains the current encryption key. The -kl name of the encryption file is sitekey. Informatica renames the current sitekey file to sitekey_old and generates an encryption key in a new file named sitekey in the same directory.
4. To change the encryption key for the domain, run the infasetup migrateEncryptionKey command and specify the location of the old and new encryption key.
Secure Data Storage 91 Specify the following options required to change the encryption key for the domain:
Option Argument Description
-LocationOfEncryptionKeys location_of_encryption_keys Directory in which the old encryption key file named -loc siteKey_old and the new encryption key file named siteKey are stored. The directory must contain the old and new encryption key files. If the old and new encryption key files are stored in different directories, copy the encryption key files to the same directory. If the domain has multiple nodes, this directory must be accessible to any node in the domain where you run the migrateEncryptionKey command. Note: On UNIX, the file name siteKey_old is case- sensitive. If you manually rename the previous encryption key file, verify that the file name has the correct letter case.
-IsDomainMigrated is_domain_migrated Indicates whether the domain has been updated to -mig use the latest encryption key. When you run the migrateEncryptionKey command for the first time, set this option to False to indicate that the domain uses the old encryption key. After the first time, when you run the migrateEncryptionKey command to update other nodes in the domain, set this option to True to indicate that the domain has been updated to use the latest encryption key. Or, you can run the migrateEncryptionKey command without this option. Default is True.
5. Run the infasetup command on each node in the domain. If the domain has multiple nodes, run infasetup migrateEncryptionKey on each node. Run the command on the gateway nodes before you run the command on the worker nodes. You can omit the IsDomainMigrated option after the first time you run the command. 6. Restart the domain. You must upgrade all repository services in the domain to update and encrypt sensitive data in the repositories with the new encryption key. 7. Upgrade all Model Repository Services, PowerCenter Repository Services, and Metadata Manager Services. You can upgrade a Model Repository Service and a PowerCenter Repository Service in the Administrator tool or at the command prompt. You can upgrade a Metadata Manager Service in the Administrator tool. Note: The Metadata Manager Service must be disabled before you can upgrade it. To upgrade a service in the Administrator tool, select Manage > Upgrade in the header area. If you select multiple services, the Administrator tool upgrades the services in the correct order.
92 Chapter 6: Domain Security To upgrade a service at the command prompt, use the following commands:
Repository Service Type Command
Model Repository Service infacmd mrs UpgradeContents
PowerCenter Repository Service pmrep Upgrade
Application Services and Ports
Informatica domain services and application services in the Informatica domain have unique ports.
Informatica Domain
The following table describes the ports that you can set:
Port Description
Service Manager port Port number used by the Service Manager on the node. The Service Manager listens for incoming connection requests on this port. Client applications use this port to communicate with the services in the domain. The Informatica command line programs use this port to communicate to the domain. This is also the port for the SQL data service JDBC/ODBC driver. Default is 6006.
Service Manager Shutdown Port number that controls server shutdown for the domain Service Manager. The port Service Manager listens for shutdown commands on this port. Default is 6007.
Informatica Administrator Port number used by Informatica Administrator. Default is 6008. port
Informatica Administrator No default port. Enter the required port number when you create the service. HTTPS port Setting this port to 0 disables an HTTPS connection to the Administrator tool.
Informatica Administrator Port number that controls server shutdown for Informatica Administrator. shutdown port Informatica Administrator listens for shutdown commands on this port. Default is 6009.
Minimum port number Lowest port number in the range of dynamic port numbers that can be assigned to the application service processes that run on this node. Default is 6014.
Maximum port number Highest port number in the range of dynamic port numbers that can be assigned to the application service processes that run on this node. Default is 6114.
Analyst Service The following table lists the default port associated with the Analyst Service:
Type Default Port
Analyst Service (HTTP) 8085
Analyst Service (HTTPS) No default port. Enter the required port number when you create the service.
Application Services and Ports 93 Content Management Service The following table lists the default port associated with the Content Management Service:
Type Default Port
Content Management Service (HTTP) 8105
Content Management Service (HTTPS) No default port. Enter the required port number when you create the service.
Data Integration Service The following table lists the default port associated with the Data Integration Service:
Type Default Port
Data Integration Service (HTTP proxy) 8080
Data Integration Service (HTTP) 8095
Data Integration Service (HTTPS) No default port. Enter the required port number when you create the service.
Profiling Warehouse database No default port. Enter the database port number.
Metadata Access Service The following table lists the default port associated with the Metadata Access Service:
Type Default Port
Metadata Access 7080 Service (HTTP) The Metadata Access Service uses consecutive port numbers to connect to multiple Hadoop distributions.
Metadata Access No default port. Enter the required port number when you create the service. The Service (HTTPS) Metadata Access Service uses consecutive port numbers to connect to multiple Hadoop distributions.
Metadata Manager Service The following table lists the default port associated with the Metadata Manager Service:
Type Default Port
Metadata Manager Service (HTTP) 10250
Metadata Manager Service (HTTPS) No default port. Enter the required port number when you create the service.
PowerExchange® Listener Service
Use the same port number that you specify in the SVCNODE statement of the DBMOVER file.
94 Chapter 6: Domain Security If you define more than one Listener Service to run on a node, you must define a unique SVCNODE port number for each service.
PowerExchange Logger Service
Use the same port number that you specify in the SVCNODE statement of the DBMOVER file.
If you define more than one Listener Service to run on a node, you must define a unique SVCNODE port number for each service.
Web Services Hub Service The following table lists the default port associated with the Web Services Hub Service:
Type Default Port
Web Services Hub Service (HTTP) 7333
Web Services Hub Service (HTTPS) 7343
Application Services and Ports 95 C h a p t e r 7
Security Management in Informatica Administrator
This chapter includes the following topics:
• Using Informatica Administrator Overview, 96
• User Security, 97
• Security Tab, 99
• Password Management, 103
• Domain Security Management, 103
• User Security Management, 104
Using Informatica Administrator Overview
Informatica Administrator is the tool that you use to manage the Informatica domain and Informatica security.
Use the Administrator tool to complete the following types of tasks:
• Domain administrative tasks. Manage logs, domain objects, user permissions, and domain reports. Generate and upload node diagnostics. Monitor Data Integration Service jobs and applications. Domain objects include application services, nodes, grids, folders, database connections, operating system profiles, and licenses.
• Security administrative tasks. Manage users, groups, roles, and privileges.
The Administrator tool has the following tabs:
• Manage. View and edit the properties of the domain and objects within the domain.
• Monitor. View the status of profile jobs, scorecard jobs, preview jobs, mapping jobs, SQL data services, web services, and workflows for each Data Integration Service.
• Logs. View log events for the domain and services within the domain.
• Reports. Run a Web Services Report or License Management Report.
• Security. Manage users, groups, roles, and privileges.
• Cloud. View information about your Informatica Cloud® organization.
The Administrator tool has the following header items:
• Log out. Log out of the Administrator tool.
96 • Manage. Manage your account.
• Help. Access help for the current tab and determine the Informatica version.
User Security
The Service Manager and some application services control user security in application clients. Application clients include Informatica Administrator, Informatica Analyst, Informatica Developer, Metadata Manager, and PowerCenter Client.
The Service Manager and application services control user security by performing the following functions:
Encryption When you log in to an application client, the Service Manager encrypts the password. Authentication When you log in to an application client, the Service Manager authenticates your user account based on your user name and password or on your user authentication token. Authorization When you request an object in an application client, the Service Manager and some application services authorize the request based on your privileges, roles, and permissions. You can also use HTTPS for secure connection to the domain and the application services. The following application services provide HTTPS connection along with the Informatica domain:
• Data Integration Service
• Analyst Service
• Content Management Service
• Metadata Access Service
• Metadata Manager Service
• Web Service Hub Service
Encryption
Informatica encrypts passwords sent from application clients to the Service Manager. Informatica uses AES encryption with multiple 128-bit keys to encrypt passwords and stores the encrypted passwords in the domain configuration database. Configure HTTPS to encrypt passwords sent to the Service Manager from application clients.
Authentication
The Service Manager authenticates users who log in to application clients.
The first time you log in to an application client, you enter a user name, password, and security domain. A security domain is a collection of user accounts and groups in an Informatica domain.
User Security 97 The security domain that you select determines the authentication method that the Service Manager uses to authenticate your user account:
• Native. When you log in to an application client as a native user, the Service Manager authenticates your user name and password against the user accounts in the domain configuration database.
• Lightweight Directory Access Protocol (LDAP). When you log in to an application client as an LDAP user, the Service Manager passes your user name and password to the external LDAP directory service for authentication.
Single Sign-On After you log in to an application client, the Service Manager allows you to launch another application client or to access multiple repositories within the application client. You do not need to log in to the additional application client or repository.
The first time the Service Manager authenticates your user account, it creates an encrypted authentication token for your account and returns the authentication token to the application client. The authentication token contains your user name, security domain, and an expiration time. The Service Manager periodically renews the authentication token before the expiration time.
When you access multiple repositories within an application client, the application client sends the authentication token to the Service Manager for user authentication.
When you launch one web application client from another one, the application client passes the authentication token to the next application client. The next web application client sends the authentication token to the Service Manager for user authentication. You must log out of each web application client separately. For example, if you open the Analyst tool from the Administrator tool, you must log out of the Analyst tool and the Administrator tool separately.
Note: To use single sign-on between the Administrator tool, the Analyst tool, and the Monitoring tool, you must add their fully qualified domain names to the host file for every node.
You cannot use single sign-on to connect to a web application client from a client tool. For example, if you launch the Administrator tool from the Developer tool, you must log in to the Administrator tool.
Authorization
The Service Manager authorizes user requests for domain objects. Requests can come from the Administrator tool. The following application services authorize user requests for other objects:
• Data Integration Service
• Metadata Manager Service
• Model Repository Service
• PowerCenter Repository Service
When you create native users and groups or import LDAP users and groups, the Service Manager stores the information in the domain configuration database into the following repositories:
• Model repository
• PowerCenter repository
• PowerCenter repository for Metadata Manager
The Service Manager synchronizes the user and group information between the repositories and the domain configuration database when the following events occur:
• You restart the Metadata Manager Service, Model Repository Service, or PowerCenter Repository Service.
98 Chapter 7: Security Management in Informatica Administrator • You add or remove native users or groups.
• The Service Manager synchronizes the list of LDAP users and groups in the domain configuration database with the list of users and groups in the LDAP directory service.
When you assign permissions to users and groups in an application client, the application service stores the permission assignments with the user and group information in the appropriate repository.
When you request an object in an application client, the appropriate application service authorizes your request. For example, if you try to edit a project in Informatica Developer, the Model Repository Service authorizes your request based on your privilege, role, and permission assignments.
Security Tab
You administer Informatica security on the Security tab of the Administrator tool.
The Security tab has the following components:
• Search section. Search for users, groups, or roles by name.
• Navigator. The Navigator appears in the left pane and displays groups, users, and roles.
• Contents panel. The contents panel displays properties and options based on the object selected in the Navigator and the tab selected in the contents panel.
• Security Actions menu. Contains options to create or delete a group, user, or role. You can manage LDAP configurations and operating system profiles. You can also view users that have privileges for a service.
Using the Search Section
Use the Search section to search for users, groups, and roles by name. Search is not case sensitive.
1. In the Search section, select whether you want to search for users, groups, or roles. 2. Enter the name or partial name to search for. You can include an asterisk (*) in a name to use a wildcard character in the search. For example, enter “ad*” to search for all objects starting with “ad”. Enter “*ad” to search for all objects ending with “ad”. 3. Click Go. The Search Results section appears and displays a maximum of 100 objects. If your search returns more than 100 objects, narrow your search criteria to refine the search results. 4. Select an object in the Search Results section to display information about the object in the contents panel.
Using the Security Navigator
The Navigator appears in the contents panel of the Security tab. When you select an object in the Navigator, the contents panel displays information about the object.
The Navigator on the Security tab displays one of the following sections based on what you are viewing:
• Groups section. Select a group to view the properties of the group, the users assigned to the group, and the roles and privileges assigned to the group.
• Users section. Select a user to view the properties of the user, the groups the user belongs to, and the roles and privileges assigned to the user.
Security Tab 99 • Roles section. Select a role to view the properties of the role, the users and groups that have the role assigned to them, and the privileges assigned to the role.
• Operating Profiles section. Select an operating profile to view the properties of the operating system profile, and the permissions assigned to users and groups that use the operating system profile.
• LDAP Configuration section. Select a configuration to view the LDAP server connection details, the LDAP security domain that contains users and groups imported from the LDAP directory service, and the LDAP synchronization schedule. The Navigator provides different ways to complete a task. You can use any of the following methods to manage groups, users, and roles:
• Click the Actions menu. Each section of the Navigator includes an Actions menu to manage groups, users, roles, operating system profiles, or LDAP configurations.
• Right-click an object. Right-click an object in the Navigator to display the options available in the Actions menu.
• Use keyboard shortcuts. Use keyboard shortcuts to move to different sections of the Navigator.
Groups
A group is a collection of users and groups that can have the same privileges, roles, and permissions.
The Groups section of the Navigator organizes groups into security domain folders. A security domain is a collection of user accounts and groups in an Informatica domain. Native authentication uses the Native security domain which contains the users and groups created and managed in the Administrator tool. LDAP authentication uses LDAP security domains which contain users and groups imported from the LDAP directory service.
When you select a security domain folder in the Groups section of the Navigator, the contents panel displays all groups belonging to the security domain.
When you select a group in the Navigator, the contents panel displays the following tabs:
• Overview. Displays general properties of the group and users assigned to the group.
• Privileges. Displays the privileges and roles assigned to the group for the domain and for application services in the domain.
• Permissions. Displays the level of access that users within the group have perform tasks on domain objects, including nodes, grids and application services . Also displays the level of access that users within the group have to perform tasks on connection objects and operating system profiles.
Users
A user with an account in the Informatica domain can log in to the following application clients:
• Informatica Administrator
• PowerCenter Client
• Informatica Developer
• Informatica Analyst
• Metadata Manager The Users section of the Navigator organizes users into security domain folders. A security domain is a collection of user accounts and groups in an Informatica domain. Native authentication uses the Native security domain which contains the users and groups created and managed in the Administrator tool. LDAP
100 Chapter 7: Security Management in Informatica Administrator authentication uses LDAP security domains which contain users and groups imported from the LDAP directory service.
When you select a security domain folder in the Users section of the Navigator, the contents panel displays all users belonging to the security domain.
When you select a user in the Navigator, the contents panel displays the following tabs:
• Overview. Displays general properties of the user and all groups to which the user belongs.
• Privileges. Displays the privileges and roles assigned to the user for the domain and for application services in the domain.
• Permissions. Displays the level of access that the user has to perform tasks on domain objects, including nodes, grids and application services . Also displays the level of access that the user has to perform tasks on connection objects and operating system profiles.
Roles
A role is a collection of privileges that you assign to a user or group. Privileges determine the actions that users can perform. You assign a role to users and groups for the domain and for application services in the domain.
The Roles section of the Navigator organizes roles into the following folders:
• System-defined Roles. Contains roles that you cannot edit or delete. The Administrator role is a system- defined role.
• Custom Roles. Contains roles that you can create, edit, and delete. The Administrator tool includes some custom roles that you can edit and assign to users and groups. When you select a folder in the Roles section of the Navigator, the contents panel displays all roles belonging to the folder.
When you select a role in the Navigator, the contents panel displays the following tabs:
• Overview. Displays general properties of the role and the users and groups that have the role assigned for the domain and application services.
• Privileges. Displays the privileges assigned to the role for the domain and application services.
Operating System Profiles
An operating system profile is a security mechanism that the Data Integration Service and the PowerCenter Integration Service use to run mappings, workflows, and profiling jobs.
The Operating System Profiles section of the Navigator lists the operating system profiles configured in the domain.
When you select an operating system profile in the Navigator, the contents panel displays the following tabs:
• Properties. Displays general properties of the operating system profile configured for the Data Integration Service, for the PowerCenter Integration Service, or for both application services.
• Permissions. Displays the permissions assigned to users and groups that use the operating system profile. Also indicates whether the operating system profile is the default profile assigned to a user or group.
Security Tab 101 LDAP Configuration
You can configure an Informatica domain to enable users and groups imported from one or more LDAP directory services to log in to Informatica nodes, services, and application clients.
The LDAP Configuration section of the Navigator lists the LDAP configurations the domain uses.
When you select an LDAP configuration, the following tabs appear under the LDAP Configuration tab:
• Overview. Lists the connection details for the LDAP server that contains the directory service from which you want to import users and groups.
• Security Domains. Lists the details for the LDAP security domain that contains users and groups imported from the LDAP directory service.
• Schedule. Lists the details for the synchronization schedule specifying when the Service Manager updates the security domain with the users and groups in the LDAP directory service.
Account Management
To improve security in the Informatica domain, you can enforce lockout of user and administrator accounts after a specified number of failed login attempts.
The Account Lockout Configuration section of the Account Management page displays whether account lockout is enabled for user accounts and administrator accounts. The section also indicates the maximum number of failed login attempts allowed.
The Locked Out Native Users section of the page lists locked out user accounts in the native security domain. You can unlock a user account in the native security domain.
The Locked Out LDAP Users section of the page lists locked out user accounts in an LDAP security domain. You can unlock a user account in the Informatica domain. However, the LDAP administrator must unlock the user account in the LDAP server. The user cannot log in to the Informatica domain until the LDAP administrator unlocks the user account.
Audit Reports
Audit reports provide information about users and groups in the Informatica domain, and about the privileges, roles, and permissions assigned to each user or group.
You select the audit report to generate from the Select Report Type menu. You can generate the following audit reports:
User Personal Information Displays contact information and status details of user accounts in the domain. You can select the users or groups for which you want to generate the report.
User Group Association Displays information about users and the groups to which they belong. You can select the users or groups for which you want to generate the report. Privileges Displays information about privileges assigned to the users and groups in the domain. You can select the users or groups for which you want to generate the report. Roles Displays information about the roles assigned to the users and groups in the domain. You can select the roles for which you want to generate the report.
102 Chapter 7: Security Management in Informatica Administrator Domain Object Permissions Displays information about the domain objects for which users and groups have permission. You can select the users or groups for which you want to generate the report.
Password Management
You can change the password through the Change Password application.
You can open the Change Password application from the Administrator tool or with the following URL: http://
The Service Manager uses the user password associated with a worker node to authenticate the domain user. If you change a user password that is associated with one or more worker nodes, the Service Manager updates the password for each worker node. The Service Manager cannot update nodes that are not running. For nodes that are not running, the Service Manager updates the password when the nodes restart.
Note: For an LDAP user account, change the password in the LDAP directory service.
For a native user account, if you enable password complexity, use the following guidelines when you create or change a password:
• The length of the password must be at least eight characters.
• It must be a combination of an alphabet character, a numeric character and a non-alphanumeric character, such as: ! \ " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ ] ^ _ ` { | } ~ When you use special characters in a password, the shell sometimes interprets them differently. For example, $ is interpreted as a variable. In this case, use an escape character to escape the special character.
Changing Your Password
Change the password for a native user account at any time. For a user account created by someone else, change the password the first time you log in to the Administrator tool.
1. In the Administrator tool header area, click Manage > Change Password. The Change Password application opens in a new browser window. 2. Enter the current password in the Password box, and the new password in the New Password and Confirm Password boxes. 3. Click Update.
Domain Security Management
You can configure Informatica domain components to use the Secure Sockets Layer (SSL) protocol or the Transport Layer Security (TLS) protocol to encrypt connections with other components. When you enable SSL or TLS for domain components, you ensure secure communication.
You can configure secure communication in the following ways:
Password Management 103 Between services within the domain You can configure secure communication between services within the domain. Between the domain and external components You can configure secure communication between Informatica domain components and web browsers or web service clients. Each method of configuring secure communication is independent of the other methods. When you configure secure communication for one set of components, you do not need to configure secure communication for any other set.
Note: If you change a secure domain to a non-secure domain or from a non-secure domain to a secure domain, you must delete the domain configuration in the Developer tool and PowerCenter client tools and configure the domain again in the client.
User Security Management
You manage user security within the domain with privileges and permissions.
Privileges determine the actions that users can complete on domain objects. Permissions define the level of access a user has to a domain object. Domain objects include the domain, folders, nodes, grids, licenses, database connections, operating system profiles, and application services.
Even if a user has the domain privilege to complete certain actions, the user might also require permission to complete the action on a particular object. For example, a user has the Manage Services domain privilege which grants the user the ability to edit application services. However, the user also must have permission on the application service. A user with the Manage Services domain privilege and permission on the Development Repository Service but not on the Production Repository Service can edit the Development Repository Service but not the Production Repository Service.
To log in to the Administrator tool, a user must have the Access Informatica Administrator domain privilege. If a user has the Access Informatica Administrator privilege and permission on an object, but does not have the domain privilege that grants the ability to modify the object type, then the user can view the object. For example, if a user has permission on a node, but does not have the Manage Nodes and Grids privilege, the user can view the node properties but cannot configure, shut down, or remove the node.
If a user does not have permission on a selected object in the Navigator, the contents panel displays a message indicating that permission on the object is denied.
104 Chapter 7: Security Management in Informatica Administrator C h a p t e r 8
Users and Groups
This chapter includes the following topics:
• Users and Groups Overview, 105
• Default Groups, 106
• Understanding User Accounts, 107
• Managing Users, 109
• Managing Groups, 117
• Managing Operating System Profiles, 118
• Account Lockout, 126
Users and Groups Overview
To access the application services and objects in the Informatica domain and to use the application clients, you must have a user account.
During installation, a default administrator user account is created. Use the default administrator account to log in to the Informatica domain and manage application services, domain objects, and other user accounts. When you log in to the Informatica domain after installation, change the password to ensure security for the Informatica domain and applications.
User account management in Informatica involves the following key components:
• Users. You can set up different types of user accounts in the Informatica domain. Users can perform tasks based on the roles, privileges, and permissions assigned to them.
• Authentication. When a user logs in to an application client, the Service Manager authenticates the user account in the Informatica domain and verifies that the user can use the application client. The Informatica domain can use native or LDAP authentication to authenticate users. The Service Manager organizes user accounts and groups by security domain. It authenticates users based on the security domain the user belongs to.
• Groups. You can set up groups of users and assign different roles, privileges, and permissions to each group. The roles, privileges, and permissions assigned to the group determines the tasks that users in the group can perform within the Informatica domain.
• Privileges and roles. Privileges determine the actions that users can perform in application clients. A role is a collection of privileges that you can assign to users and groups. You assign roles or privileges to users and groups for the domain and for application services in the domain.
105 • Operating system profiles. If you run the Integration Service on UNIX or Linux, you can configure the Integration Service to use operating system profiles. Use operating system profiles to increase security and to isolate the run-time environment for users. You can create and manage operating system profiles on the Security tab of the Administrator tool.
• Account lockout. You can configure account lockout to lock a user account when the user specifies an incorrect login in the Administrator tool or any application clients, like the Developer tool and Analyst tool. You can also unlock a user account.
Default Groups
The Informatica domain has a set of user groups that are created during installation.
By default, the Informatica domain has the following user groups after installation:
• Administrator
• Everyone
• Operator
Administrator Group
The Informatica domain includes a default group named Administrator. The default administrator account created during installation belongs to this group.
The Administrator group has administrator permissions and privileges on the domain and all application services. You can add users to or remove users from the Administrator group. All users in the Administrator group have the same permissions and privileges as the default administrator created during installation.
You cannot delete the default administrator account from the Administrator group and you cannot delete the Administrator group.
Everyone Group
The Informatica domain includes a default group named Everyone. All users in the domain belong to the group.
By default, the Everyone group does not have any privileges. You can assign privileges, roles, and permissions to the Everyone group to grant the same access to all users.
You cannot perform the following tasks on the Everyone group:
• Edit or delete the Everyone group.
• Add users to or remove users from the Everyone group.
• Move a group to the Everyone group.
Operator Group
The Informatica domain includes a default group named Operator.
By default, the Operator group has permission on all of the objects in the domain. You can assign the Operator role to the Operator group and use it to manage the Operator users in the domain.
106 Chapter 8: Users and Groups You can perform the following tasks on the Operator group:
• Assign privileges and roles to the group.
• Add users to or remove users from the group.
• Move a group to the group.
• Edit or delete the group.
Understanding User Accounts
An Informatica domain can have the following types of accounts:
• Default administrator
• Domain administrator
• Application client administrator
• User
Default Administrator
When you install Informatica services, the installer creates the default administrator with a user name and password you provide. You can use the default administrator account to initially log in to the Administrator tool.
The default administrator has administrator permissions and privileges on the domain and all application services.
The default administrator can perform the following tasks:
• Create, configure, and manage all objects in the domain, including nodes, application services, and administrator and user accounts.
• Configure and manage all objects and user accounts created by other domain administrators and application client administrators.
• Log in to any application client.
You cannot disable or modify the user name or privileges of the default administrator. You can change the default administrator password.
Domain Administrator
A domain administrator can create and manage objects in the domain.
The domain administrator can log in to the Administrator tool and create and configure application services in the domain. However, by default, the domain administrator cannot log in to application clients. The default administrator must explicitly give a domain administrator full permissions and privileges to the application services so that they can log in and perform administrative tasks in the application clients.
To create a domain administrator, assign a user the Administrator role for a domain.
Understanding User Accounts 107 Application Client Administrator
An application client administrator can create and manage objects in an application client. You must create administrator accounts for the application clients. To limit administrator privileges and keep application clients secure, create a separate administrator account for each application client.
By default, the application client administrator does not have permissions or privileges on the domain. Without permissions or privileges on the domain, the application client administrator cannot log in to the Administrator tool to manage the application service.
You can set up the following application client administrators:
Informatica Analyst administrator
Has full permissions and privileges in Informatica Analyst. The Informatica Analyst administrator can log in to Informatica Analyst to create and manage projects and objects in projects and perform all tasks in the application client.
To create an Informatica Analyst administrator, assign a user the Administrator role for an Analyst Service and for the associated Model Repository Service.
Informatica Developer administrator
Has full permissions and privileges in Informatica Developer. The Informatica Developer administrator can log in to Informatica Developer to create and manage projects and objects in projects and perform all tasks in the application client.
To create an Informatica Developer administrator, assign a user the Administrator role for a Model Repository Service.
Metadata Manager administrator
Has full permissions and privileges in Metadata Manager. The Metadata Manager administrator can log in to Metadata Manager to create and manage Metadata Manager objects and perform all tasks in the application client.
To create a Metadata Manager administrator, assign a user the Administrator role for a Metadata Manager Service.
Test Data administrator
Has full permissions and privileges in Test Data Manager. The Test Data Manager administrator can log in to Test Data Manager to create and manage Test Data Manager objects and perform all tasks in the application client.
To create a Test Data administrator, assign a user the Administrator role for a Test Data Manager Service.
PowerCenter Client administrator
Has full permissions and privileges on all objects in the PowerCenter Client. The PowerCenter Client administrator can log in to the PowerCenter Client to manage the PowerCenter repository objects and perform all tasks in the PowerCenter Client. The PowerCenter Client administrator can also perform all tasks in the pmrep and pmcmd command line programs.
To create a PowerCenter Client administrator, assign a user the Administrator role for a PowerCenter Repository Service.
User
A user with an account in the Informatica domain can perform tasks in the application clients.
108 Chapter 8: Users and Groups Typically, the default administrator or a domain administrator creates and manages user accounts and assigns roles, permissions, and privileges in the Informatica domain. However, any user with the required domain privileges and permissions can create a user account and assign roles, permissions, and privileges.
Users can perform tasks in application clients based on the privileges and permissions assigned to them.
Managing Users
You can create, edit, and delete users in the native security domain. You cannot delete or modify the properties of user accounts in the LDAP security domains. You cannot modify the user assignments to LDAP groups.
You can assign roles, permissions, and privileges to a user account in the native security domain or an LDAP security domain. The roles, permissions, and privileges assigned to the user determines the tasks the user can perform within the Informatica domain.
You can also unlock a user account.
Creating Native Users
Add, edit, or delete native users on the Security tab.
1. In the Administrator tool, click the Security tab. 2. On the Security Actions menu, click Create User. 3. Enter the following details for the user:
Property Description
Login Name Login name for the user account. The login name for a user account must be unique within the security domain to which it belongs. The name is not case sensitive and cannot exceed 128 characters. It cannot include a tab, newline character, or the following special characters: , + " \ < > ; / * % ? & The name can include an ASCII space character except for the first and last character. All other space characters are not allowed.
Password Password for the user account. The password can be from 1 through 80 characters long.
Confirm Password Enter the password again to confirm. You must retype the password. Do not copy and paste the password.
Full Name Full name for the user account. The full name cannot include the following special characters: < > “
Description Description of the user account. The description cannot exceed 765 characters or include the following special characters: < > “
Managing Users 109 Property Description
Email Email address for the user. The email address cannot include the following special characters: < > “ Enter the email address in the format UserName@Domain.
Phone Telephone number for the user. The telephone number cannot include the following special characters: < > “
4. Click OK to save the user account. After you create a user account, the details panel displays the properties of the user account and the groups that the user is assigned to.
Editing General Properties of Native Users
You cannot change the login name of a native user. You can change the password and other details for a native user account.
1. In the Administrator tool, click the Security tab. 2. In the Users section of the Navigator, select a native user account and click Edit. 3. To change the password, select Change Password. The Security tab clears the Password and Confirm Password fields. 4. Enter a new password and confirm. 5. Modify the full name, description, email, and phone as necessary. 6. Click OK to save the changes.
Assigning Native Users to Native Groups
Assign native users to native groups on the Security tab.
1. In the Administrator tool, click the Security tab. 2. In the Users section of the Navigator, select a native user account and click Edit. 3. Click the Groups tab. 4. To assign a native user to a group, select a group name in the All Groups column and click Add. If nested groups do not display in the All Groups column, expand each group to show all nested groups. You can assign a native user to more than one group. Use the Ctrl or Shift keys to select multiple groups at the same time. 5. To remove a native user from a group, select a group in the Assigned Groups column and click Remove. 6. Click OK to save the group assignments.
110 Chapter 8: Users and Groups Assigning LDAP Users to Native Groups
You can assign LDAP user accounts to native groups. You cannot change the assignment of LDAP user accounts to LDAP groups.
1. In the Administrator tool, click the Security tab. 2. In the Groups section of the Navigator, select a native group, and then click Edit. 3. Click the Users tab. 4. To assign an LDAP user to a group, select an LDAP user in the All Users column, and then click Add. 5. To remove an LDAP user from a group, select an LDAP user in the Assigned Users column, and then click Remove. 6. Click OK to save the user assignments.
Enabling and Disabling User Accounts
Users with active accounts can log in to application clients and perform tasks based on their permissions and privileges. If you do not want users to access application clients temporarily, you can disable their accounts. You can enable or disable user accounts in the native or an LDAP security domain. When you disable a user account, the user cannot log in to the application clients.
To disable a user account, select a user account in the Users section of the Navigator and click Disable. When you select a disabled user account, the Security tab displays a message that the user account is disabled. When a user account is disabled, the Enable button is available. To enable the user account, click Enable.
You cannot disable the default administrator account.
Note: When the Service Manager imports a user account from the LDAP directory service, it does not import the LDAP attribute that indicates that a user account is enabled or disabled. The Service Manager imports all user accounts as enabled user accounts. You must disable an LDAP user account in the Administrator tool if you do not want the user to access application clients. During subsequent synchronization with the LDAP server, the user account retains the enabled or disabled status set in the Administrator tool.
Deleting Native Users
To delete a native user account, right-click the user account name in the Users section of the Navigator and select Delete User. Confirm that you want to delete the user account.
You cannot delete the default administrator account. When you log in to the Administrator tool, you cannot delete your user account.
Deleting Users of PowerCenter When you delete a user who owns objects in the PowerCenter repository, you remove any ownership that the user has over folders, connection objects, deployment groups, labels, or queries. After you delete a user, the default administrator becomes the owner of all objects owned by the deleted user.
When you view the history of a versioned object previously owned by a deleted user, the name of the deleted user appears prefixed by the word "deleted."
Deleting Users of Metadata Manager When you delete a user who owns shortcuts and folders, Metadata Manager moves the user's personal folder to a folder named Deleted Users owned by the default administrator. The deleted user's personal folder
Managing Users 111 contains all shortcuts and folders created by the user. Any shared folders remain shared after you delete the user.
If the Deleted Users folder contains a folder with the same user name, Metadata Manager names the additional folder "Copy (n) of
LDAP Users
You cannot add, edit, or delete LDAP users in the Administrator tool. You must manage the LDAP user accounts in the LDAP directory service.
Unlocking a User Account
The domain administrator can unlock a user account that is locked out of the domain. If the user is a native user, the administrator can request that the user reset their password before logging back into the domain.
The user must have a valid email address configured in the domain to receive notifications when their account password has been reset.
If the user is locked out of the LDAP authentication server, the LDAP administrator must unlock the user account in the LDAP server.
1. In the Administrator tool, click the Security tab. 2. Click Account Management. The Account Management page displays the following lists of locked-out users: Locked Out Native Users Includes user accounts in the Native security domain that are locked out. Locked Out LDAP Users Includes user accounts in LDAP security domains that are locked out. 3. Select the users that you want to unlock. 4. Select Unlock user and reset password to generate a new password for the user after you unlock the account. The user receives the new password in an email. 5. Click the Unlock selected users button.
Increasing System Memory for Many Users
Processing time for an Informatica domain restart, LDAP user synchronization, and some infacmd and infasetup commands increases proportionally with the number of users in the Informatica domain.
The number of users affects the processing time of the following commands:
• infasetup BackupDomain, DeleteDomain, and RestoreDomain
• infacmd isp ExportDomainObjects, ExportUsersandGroups, ImportDomainObjects, and ImportUsersandGroups
• infacmd tools ExportObjects and ImportObjects You may need to increase the system memory used by Informatica Services, infasetup, and infacmd when you have a large number of users in the domain. To increase the maximum heap size, configure the following environment variables and specify the value in megabytes:
• INFA_JAVA_OPTS. Determines the maximum heap size used by Informatica Services. Configure on each node where Informatica Services is installed.
112 Chapter 8: Users and Groups • ICMD_JAVA_OPTS. Determines the maximum heap size used by infacmd. Configure on each machine where you run infacmd.
• INFA_JAVA_CMD_OPTS. Determines the maximum heap size used by infasetup. Configure on each machine where you run infasetup. For example, to configure 2048 MB of system memory on UNIX for the INFA_JAVA_OPTS environment variable, use the following command: setenv INFA_JAVA_OPTS "-Xmx2048m" On Windows, configure the variables as system variables.
The following table lists the minimum requirement for the maximum heap size settings, based on the number of users and services in the domain:
Number of Domain Users Maximum Heap Size Maximum Heap Size (1-5 Services) (6-10 Services)
1,000 or less 512 MB (default) 1024 MB
5,000 2048 MB 3072 MB
10,000 3072 MB 5120 MB
20,000 5120 MB 6144 MB
30,000 5120 MB 6144 MB
Note: The maximum heap size settings in the table are based on the number of application services in the domain.
After you configure these environment variables, restart the node for the changes to take effect.
Viewing User Activity
Use the Logs tab of the Administrator tool to view user activity logs. View user activity logs to review login attempts from Informatica client applications. You can also view the logs to determine when a user created, updated, or removed services, nodes, users, groups, or roles.
See the Informatica Administrator Guide for more information about user activity logs and the Logs tab of the Administrator tool.
You can also use the infacmd isp getUserActivityLog command to view user activity log data. The infacmd isp getUserActivityLog command uses the following syntax: infacmd isp getUserActivityLog -dn domain_name -un user_name -pd password The infacmd isp getUserActivityLog command requires the Administrator role or membership in the Administrator group. For more information about the isp getUserActivityLog command, see the Informatica Command Reference.
The user activity log data includes successful and unsuccessful user login attempts from Informatica clients. If the client sets custom properties on login requests, the log data includes the custom properties.
Note: The user activity logs do not include user login attempts in a domain configured to use Kerberos authentication.
Managing Users 113 The user activity data includes the following properties for each login attempt from an Informatica client:
• Application name
• Application version
• Host name or IP address of the application host You can view log events based on the following optional filters:
• User name
• Security domain
• Date and time
• Chronological order
• Activity code
• Activity text
You can display the log events at the command prompt or write the events to a file in one the following formats:
• Binary
• Text
• XML
If you print a log in binary format, you can use the infacmd isp convertUserActivityLog command to convert it to text or XML format. See the Informatica Command Reference for more information on using the infacmd isp convertUserActivityLog command.
User Activity Codes User activity logs include codes that indicate the success or failure of each activity.
Valid activity codes include the following:
• CCM_10437. Indicates that an activity succeeded.
• CCM_10438. Indicates that an activity failed.
• CCM_10778. Indicates that a login attempt with custom properties succeeded.
• CCM_10779. Indicates that a login attempt with custom properties failed.
• CCM_10786. Indicates that a login attempt without custom properties succeeded.
• CCM_10787. Indicates that a login attempt without custom properties failed.
User Activity Log Filters Use one or more filters to retrieve log events for specific users, dates, or events.
Use one or more of the following parameters for the infacmd isp getUserActivityLog command to filter log events: Users and security domains
Optional. The list of users that you want to get log events for. Separate multiple users with a space. Use the wildcard symbol (*) to view logs for multiple users on a single security domain or all security domains. For example, the following strings are valid values for the option: user:Native "user:*" "user*" "*_users_*" "*:Native"
114 Chapter 8: Users and Groups Add the following parameter to the getUserActivityLog command to filter log events based on user or security domain: -usrs
If you enter an end date that is before the start date, the command returns no log events.
Enter the date and time in one of the following formats:
• MM/dd/yyyy
• MM/dd/yyyy HH:mm:ss
• yyyy-MM-dd
• yyyy-MM-dd HH:mm:ss
Add the following parameter to the getUserActivityLog command to filter the log by start date or end date: -sd
Optional. Returns log events based on the activity code.
Use the wildcard symbol (*) to retrieve log events for multiple activity codes. Valid activity codes include:
• CCM_10437. Indicates that an activity succeeded.
• CCM_10438. Indicates that an activity failed.
• CCM_10778. Indicates that a login attempt with custom properties succeeded.
• CCM_10779. Indicates that a login attempt with custom properties failed.
• CCM_10786. Indicates that a login attempt without custom properties succeeded.
• CCM_10787. Indicates that a login attempt without custom properties failed. Add the following parameter to the getUserActivityLog command to filter by activity code: -ac
Activity text
Optional. Returns log events based on a string found in the activity text.
Add the following parameter to the getUserActivityLog command to filter by activity text: -atxt
Managing Users 115 Use the wildcard symbol (*) to retrieve logs for multiple events. For example, the following parameter returns all log events that contain the phrase "Enabling service" in their description: -atxt "*Enabling service*" If you use the wildcard symbol, enclose the argument in quotation marks.
Chronological order
Optional. Prints log events in reverse chronological order. If you do not specify this parameter, the command displays log events in chronological order.
Add the following parameter to the getUserActivityLog command to print the most recent event first: -ro true
Writing and Viewing User Activity Log Events You can write user activity log events to a file or display it in the command line when you use the infacmd isp getUserActivityLog command. Write the user activity log events to the format based on how you plan to use the exported log events file. Writing and Viewing Log Files To write the user activity log events to a file, run the command with the output file parameter -lo: -lo output_file_name If you do not specify an output format, the command writes the log events to a text file. For example, run the following command to write log events to a file named log.txt: infacmd isp getUserActivityLog -dn TestDomain -un Administrator -pd Administrator -lo log.txt To specify an output format, run the command with the format parameter -fm: -fm output_format_BIN_TEXT_XML Valid formats include:
• Bin (binary). Use binary format to back up the log events in binary format. You might need to use this format to send log events to Informatica Global Customer Support
• Text. Use text format if you want to analyze the log events in a text editor.
• XML. Use XML format if you want to analyze log events in an external tool that uses XML or if you want to use XML tools, such as XSLT.
If you specify text or XML as the output format, but you do not specify an output file, the command displays the text or XML log on the command line.
If you specify binary as the output format, you must provide an output file name.
For example, run the following command to print log events to a file named log.xml: infacmd isp getUserActivityLog -dn TestDomain -un Administrator -pd Administrator -fm xml -lo log.xml Converting Log Files If you use the getUserActivity command to write log events to a binary file, you can convert the file to text or XML format.
Run the following command to convert a binary log you retrieved to text or XML format: infacmd isp convertUserActivityLogFile -in BIN_input_file_name -fm output_format_TEXT_XML -lo output_file_name
116 Chapter 8: Users and Groups For example, run the following command to convert a binary input file named log.bin to XML format and output it to a file named convertedLog.xml: infacmd isp convertUserActivityLogFile -in log.bin -fm XML -lo convertedLog.xml To display the log on the command line, omit the output file name.
If you omit the format, the command uses the text format.
Managing Groups
You can create, edit, and delete groups in the native security domain.
You can assign roles, permissions, and privileges to a group in the native or an LDAP security domain. You cannot delete or modify the properties of group accounts in the LDAP security domains. The roles, permissions, and privileges assigned to the group determines the tasks that users in the group can perform within the Informatica domain.
Adding a Native Group
Add, edit, or remove native groups on the Security tab.
A native group can contain native or LDAP user accounts or other native groups. You can create multiple levels of native groups. For example, the Finance group contains the AccountsPayable group which contains the OfficeSupplies group. The Finance group is the parent group of the AccountsPayable group and the AccountsPayable group is the parent group of the OfficeSupplies group. Each group can contain other native groups.
1. In the Administrator tool, click the Security tab. 2. On the Security Actions menu, click Create Group. 3. Enter the following information for the group:
Property Description
Name Name of the group. The name is not case sensitive and cannot exceed 128 characters. It cannot include a tab, newline character, or the following special characters: , + " \ < > ; / * % ? The name can include an ASCII space character except for the first and last character. All other space characters are not allowed.
Parent Group Group to which the new group belongs. If you select a native group before you click Create Group, the selected group is the parent group. Otherwise, Parent Group field displays Native indicating that the new group does not belong to a group.
Description Description of the group. The group description cannot exceed 765 characters or include the following special characters: < > “
4. Click Browse to select a different parent group. You can create more than one level of groups and subgroups. 5. Click OK to save the group.
Managing Groups 117 Editing Properties of a Native Group
After you create a group, you can change the description of the group and the list of users in the group. You cannot change the name of the group or the parent of the group. To change the parent of the group, you must move the group to another group.
1. In the Administrator tool, click the Security tab. 2. In the Groups section of the Navigator, select a native group and click Edit. 3. Change the description of the group. 4. To change the list of users in the group, click the Users tab. The Users tab displays the list of users in the domain and the list of users assigned to the group. 5. To assign users to the group, select a user account in the All Users column and click Add. 6. To remove a user from a group, select a user account in the Assigned Users column and click Remove. 7. Click OK to save the changes.
Moving a Native Group to Another Native Group
To organize the groups of users in the native security domain, you can set up nested groups and move a group to another group.
To move a native group to another native group, right-click the name of a native group in the Groups section of the Navigator and select Move Group.
Deleting a Native Group
To delete a native group, right-click the group name in the Groups section of the Navigator and select Delete Group.
When you delete a group, the users in the group lose their membership in the group and all permissions or privileges inherited from group.
When you delete a group, the Service Manager deletes all groups and subgroups that belong to the group.
LDAP Groups
You cannot add, edit, or delete LDAP groups or modify user assignments to LDAP groups in the Administrator tool. You must manage groups and user assignments in the LDAP directory service.
Managing Operating System Profiles
Create and manage operating system profiles on the Security tab of the Administrator tool or from the command line. You can create, edit, and delete operating system profiles. You can assign or change the default operating system profile to users and groups.
If the Data Integration Service is configured to use operating system profiles, it runs mappings, profiles, and workflows with the operating system profile. If the PowerCenter Integration Service is configured to use operating system profiles, it runs workflows with the operating system profile.
Create, edit, and delete operating system profiles in the Operating System Profiles view of the Security tab.
118 Chapter 8: Users and Groups Complete the following steps to create an operating system profile:
1. Enter an operating system profile name and a system user name. 2. Select the Integration Services and configure the operating system profile properties. 3. Optionally, assign permissions on the operating system profile. You can assign users and groups to operating system profiles and assign a default profile to users and groups after you create an operating system profile.
Operating System Profile Properties for the PowerCenter Integration Service
Service process variables that are set in session properties and parameter files override the operating system profile settings.
The following table describes the operating system profile properties for the PowerCenter Integration Service:
Property Description
Name Read-only name of the operating system profile. The name cannot exceed 128 characters. It cannot include spaces or the following special characters: \ / : * ? " < > | [ ] = + ; ,
System User Name Read-only name of an operating system user that exists on the machines where the PowerCenter Integration Service runs. The PowerCenter Integration Service runs workflows using the system access of the system user defined for the operating system profile.
$PMRootDir Root directory accessible by the node. This is the root directory for other service process variables. It cannot include the following special characters: * ? < > “ | ,
$PMSessionLogDir Directory for session logs. It cannot include the following special characters: * ? < > “ | , Default is $PMRootDir/SessLogs.
$PMBadFileDir Directory for reject files. It cannot include the following special characters: * ? < > “ | , Default is $PMRootDir/BadFiles.
$PMCacheDir Directory for index and data cache files. You can increase performance when the cache directory is a drive local to the PowerCenter Integration Service process. Do not use a mapped or mounted drive for cache files. It cannot include the following special characters: * ? < > “ | , Default is $PMRootDir/Cache.
$PMTargetFileDir Directory for target files. It cannot include the following special characters: * ? < > “ | , Default is $PMRootDir/TgtFiles.
$PMSourceFileDir Directory for source files. It cannot include the following special characters: * ? < > “ | , Default is $PMRootDir/SrcFiles.
Managing Operating System Profiles 119 Property Description
$PmExtProcDir Directory for external procedures. It cannot include the following special characters: * ? < > “ | , Default is $PMRootDir/ExtProc.
$PMTempDir Directory for temporary files. It cannot include the following special characters: * ? < > “ | , Default is $PMRootDir/Temp.
$PMLookupFileDir Directory for lookup files. It cannot include the following special characters: * ? < > “ | , Default is $PMRootDir/LkpFiles.
$PMStorageDir Directory for run-time files. Workflow recovery files save to the $PMStorageDir configured in the PowerCenter Integration Service properties. Session recovery files save to the $PMStorageDir configured in the operating system profile. It cannot include the following special characters: * ? < > “ | , Default is $PMRootDir/Storage.
Environment Name and value of environment variables used by the Integration Service at run time. Variables If you specify the LD_LIBRARY_PATH environment variable in the operating system profile properties, the Integration Service appends the value of this variable to its LD_LIBRARY_PATH environment variable. The Integration Service uses the value of its LD_LIBRARY_PATH environment variable to set the environment variables of the child processes generated for the operating system profile. If you do not specify the LD_LIBRARY_PATH environment variable in the operating system profile properties, the Integration Service uses its LD_LIBRARY_PATH environment variable.
Operating System Profile Properties for the Data Integration Service
The following table describes the operating system profile properties for the Data Integration Service:
Property Description
Name Read-only name of the operating system profile. The name cannot exceed 128 characters. It cannot include spaces or the following special characters: % * + \ / ? ; < >
System User Name Read-only name of an operating system user that exists on the systems where the Data Integration Service runs. The Data Integration Service runs mappings, workflows, and profiling jobs using the system access of the operating system user.
$DISRootDir Root directory accessible by the node. This is the root directory for other service process variables. It cannot include the following special characters: * ? < > " | , [ ]
120 Chapter 8: Users and Groups Property Description
$DISTempDir Directory for temporary files created when jobs are run. It cannot include the following special characters: * ? < > " | , [ ] Default is
$DISCacheDir Directory for index and data cache files for transformations. It cannot include the following special characters: * ? < > " | , [ ] Default is
$DISSourceDir Directory for source flat files used in a mapping. It cannot include the following special characters: * ? < > " | , [ ] Default is
$DISTargetDir Directory for target flat files used in a mapping. It cannot include the following special characters: * ? < > " | , [ ] Default is
$DISRejectedFilesDir Directory for reject files. Reject files contain rows that were rejected when running a mapping. It cannot include the following special characters: * ? < > " | , [ ] Default is
$DISLogDir Directory for logs. It cannot include the following special characters: * ? < > " | , [ ] Default is
Enable Hadoop Indicates that the Data Integration Service uses the Hadoop impersonation user to run Impersonation mappings, workflows, and profiling jobs in a Hadoop environment. Properties Default Hadoop impersonation user is the logged in user. To specify a different Hadoop impersonation user, select Use the Specified User as Hadoop Impersonation User and enter a user name.
Environment Variables Name and value of environment variables used by the Integration Service at run time. If you specify the LD_LIBRARY_PATH environment variable in the operating system profile properties, the Integration Service appends the value of this variable to its LD_LIBRARY_PATH environment variable. The Integration Service uses the value of its LD_LIBRARY_PATH environment variable to set the environment variables of the child processes generated for the operating system profile. If you do not specify the LD_LIBRARY_PATH environment variable in the operating system profile properties, the Integration Service uses its LD_LIBRARY_PATH environment variable. Note: On AIX, you must set the LD_LIBRARY_PATH environment variable to INFA_HOME/ services/shared/bin for the Data Integration Service to successfully run mappings, profiles, and workflows with operating system profiles.
Flat File Cache Directory of the flat file cache where the Analyst tool stores uploaded flat files. Directory If the Analyst Service connects to a Data Integration Service that uses operating system profiles, the operating system user specified in the operating system profile must have access to this flat file cache directory. When you import a reference table or flat file source, the Analyst tool uses the files from this directory to create a reference table or flat file data object. Restart the Analyst Service if you change the flat file location.
Managing Operating System Profiles 121 Operating System Profile Properties for the Metadata Access Service
The following table describes the operating system profile properties for the Metadata Access Service:
Property Description
Name Read-only name of the operating system profile. The name cannot exceed 128 characters. It cannot include spaces or the following special characters: % * + \ / ? ; < >
System User Name Read-only name of an operating system user that exists on the systems where the Metadata Access Service runs. The Metadata Access Service allows the Developer tool to access Hadoop connection information to import and preview metadata using the system access of the operating system user.
Enable Hadoop Indicates that the Metadata Access Service uses the Hadoop impersonation user to import and Impersonation preview metadata. Properties Default Hadoop impersonation user is the logged in user. To specify a different Hadoop impersonation user, select Use the Specified User as Hadoop Impersonation User and enter a user name.
Creating an Operating System Profile
Create an operating system profile and assign it to users and groups to increase security and to isolate the run-time user environment. You can create one or more operating system profiles. The PowerCenter Integration Service uses the operating system profile to run workflows. The Data Integration Service uses the operating system profile to run mappings, profiles, and workflows. The Metadata Access Service uses the operating system profile to access Hadoop connection information to import and preview metadata.
1. In the Administrator tool, click the Security tab. 2. On the Security Actions menu, click Create Operating System Profile. The Create Operating System Profile - Step 1 of 3 dialog box appears. 3. Enter the following general properties for the operating system profile:
Property Description
Name Name of the operating system profile. The name is not case sensitive and must be unique within the domain. It cannot exceed 128 characters or begin with @. It also cannot contain the following special characters: % * + \ / ? ; < > The name can contain an ASCII space character except for the first and last character. All other space characters are not allowed.
System User Name Name of an operating system user that exists on the machines where the Integration Service runs. The Integration Service runs workflows or jobs using the system access of the system user defined for the operating system profile. Note: When you create operating system profiles, you cannot specify the system user name as root or use a non-root user with uid==0.
4. Click Next.
122 Chapter 8: Users and Groups The Configure Operating System Profile - Step 2 of 3 dialog box appears. 5. Select the service that will use the operating system profile.
• PowerCenter Integration Service
• Data Integration Service
• Metadata Access Service 6. Configure the operating system profile properties for the selected services. To create an operating system profile for the Metadata Access Service, you must also select Data Integration Service along with Metadata Access Service and specify the $DISRootDir variable for the Data Integration Service. 7. If the services access a Hadoop environment at design time or at run time, configure the Hadoop impersonation properties as follows: a. Select Enable Hadoop Impersonation Properties. b. Choose to use the logged in user or specify a Hadoop impersonation user to run Hadoop jobs. 8. Optionally, configure the environment variables. 9. If the Analyst Service connects to a Data Integration Service that uses operating system profiles, configure the Analyst Service properties. 10. Click Next. The Assign Groups and Users to Operating System Profile - Step 3 of 3 dialog box appears. 11. In the Groups tab, assign groups to the operating system profile as follows: a. To assign specific groups to the operating system profile, select one or more groups and click Add. b. To assign all available groups to the operating system profile, click Add All. 12. Optionally, assign the operating system profile as the default profile to one or more groups. To assign a default profile, select Default Profile for the group in the Selected Group(s) list. 13. In the Users tab, assign users to the operating system profile as follows: a. To assign specific users to the operating system profile, select one or more users and click Add. b. To assign all available users to the operating system profile, click Add All. 14. Optionally, assign the operating system profile as the default profile to one or more users. To assign a default profile, select Default Profile for the user in the Selected User(s) list. 15. Click Finish. After you create the operating system profile, the details panel displays the properties of the operating system profile and the groups and users that the profile is assigned to.
Editing an Operating System Profile
You can edit an operating system profile to change the operating system profile properties.
You cannot edit the name or the system user name after you create an operating system profile. If you do not want to use the operating system user specified in the operating system profile, delete the operating system profile.
1. In the Administrator tool, click the Security tab. 2. Select the Operating System Profiles view. 3. Select the operating system profile. 4. In the Properties tab, click Edit. The Edit Properties dialog box appears.
Managing Operating System Profiles 123 5. Select the Data Integration Service, the PowerCenter Integration Service , or the Metadata Access Service that you want to configure. 6. Edit the service properties. 7. Click OK.
Assigning a Default Operating System Profile to a User or Group
When a user or group has access to more than one operating system profile, assign a default operating system profile that the Integration Service uses to run jobs and workflows. You can assign any operating system profile with direct permission as the default profile to a user or group. A user or group can have only one default operating system profile. However, you can assign the same operating system profile as the default profile to more than one user or group.
1. On the Security tab, select the Users or Groups view. 2. In the Navigator, select the user or group. 3. In the content panel, select the Permissions view. 4. Click the Operating System Profiles tab. 5. Click the Assign or Change the Default Operating System Profile button. The Assign or Change the Default Operating System Profile dialog box appears. 6. Select a profile from the Default Operating System Profile list. Or, select Do not assign a default operating system profile from the list to remove the default profile that is assigned to a user or group. 7. Click OK. In the details panel, the Default Profile column displays Yes (Direct) for the operating system profile.
Deleting an Operating System Profile
To delete an operating system profile, right-click the operating system profile name in the Operating System Profile section of the Navigator and select Delete Profile.
After you delete an operating system profile, assign another operating system profile to the users and groups that the operating system profile was assigned to as the default profile. If the PowerCenter Integration Service uses operating system profiles, assign another operating system profile to the repository folders and workflows that the operating system profile was assigned to.
124 Chapter 8: Users and Groups Working with Operating System Profiles in a Secure Domain
You can use operating system profiles in an Informatica domain that has secure communication enabled.
Consider the following rules and guidelines when you use operating system profiles in a domain that has secure communication enabled:
• You must set the following environment variable for the operating system profile: INFA_TRUSTSTORE Set the value to the directory that contains the truststore files for the SSL certificates for the secure domain. The directory must contain a truststore file named infa_truststore.pem. INFA_TRUSTSTORE_PASSWORD If you use a custom truststore, set the value to the password for the infa_truststore.pem that contains the SSL certificate for the secure domain. The password must be encrypted. Use the command line program pmpasswd to encrypt the password.
• Additionally, if the PowerCenter Integration Service uses the Session on Grid option, you must set the following environment variable for the operating system profile: INFA_KEYSTORE Set the value to the directory that contains the keystore files for the SSL certificates for the secure domain. The directory must contain a keystore file named infa_keystore.pem.
You can set the environment variables for the operating system profile in the Administrator tool. To set the environment variables for the operating system profile, click Security > Operating System Profiles. Edit the properties of the operating system profile and set the environment variables.
Working with Operating System Profiles in a Domain with Kerberos Authentication
You can use operating system profiles in an Informatica domain that runs on a network with Kerberos authentication.
Consider the following rules and guidelines when you use operating system profiles in a domain that runs on a network with Kerberos authentication:
• The user account for the operating system profile must be a principal in the Active Directory service used for Kerberos authentication and imported into an LDAP security domain in the Informatica domain.
• The user account must have a Kerberos credentials cache file that is accessible to the operating system profile user account. Each operating system profile user account must have a separate credentials cache file.
• The credentials cache file for the operating system profile user account must be forwardable. For example, if you use the kinit utility to create the credentials cache file, you must include the -f option.
• The credentials cache file for the operating system profile user account must be available when you run a workflow that uses an operating system profile.
• The credentials cache file for the operating system profile user account must always have the latest credentials. You can run a job scheduler utility, such as cron, to regularly update the user credentials in the credentials cache file.
Managing Operating System Profiles 125 • You must set the following environment variables for the operating system profile: INFA_OSPI_SECURITY_DOMAIN Set the value to the name of the security domain that contains the user account for the operating system profile. If the user account is in the user realm security domain for Kerberos, you do not need to set this variable. The user realm security domain for Kerberos is the security domain created during installation which has the same name as the Kerberos user realm. KRB5_CONFIG Set the value to the path and file name of the Kerberos configuration file. The name of the Kerberos configuration file is krb5.conf. KRB5CCNAME Set the value to the path and file name of the Kerberos credentials cache file for the operating system profile user account. You can set the environment variables for the operating system profile in the Administrator tool. To set the environment variables for the operating system profile, click Security > Operating System Profiles. Edit the properties of the operating system profile and set the environment variables.
Account Lockout
To improve security in the Informatica domain, an administrator can enforce lockout of domain user accounts, including other administrator users, after multiple failed logins.
The administrator can specify the number of failed login attempts a user can make before the user account is locked. If an account is locked out, the administrator can unlock the account in the Informatica domain.
When the administrator unlocks a user account, the administrator can select the "Unlock user and reset password" option to reset the user password. The administrator can send an email to the user to request that the user change the password before logging back into the domain. To enable the domain to send emails to users when their passwords are reset, configure the email server settings for the domain.
If the user is locked out of the Informatica domain and the LDAP server, the Informatica administrator can unlock the user account in the Informatica domain. The user cannot log in to the Informatica domain until the LDAP administrator also unlocks the user account in the LDAP server.
Note: If the Informatica domain uses Kerberos network authentication, you cannot configure lockout for user accounts. The Account Management view is not available in the Security tab of the Administrator tool.
Configuring Account Lockout
Select the account lockout options to lock out user accounts in the Informatica domain after multiple failed logins.
1. In the Administrator tool, click Security > Account Management. 2. In Account Lockout Configuration section, click Edit.
126 Chapter 8: Users and Groups 3. Set the following properties:
Property Description
Enable Account Enforces lockout of an Informatica domain user account after a specified number of failed Lockout logins. By default, this option does not enforce lockout of administrator user accounts. You must select the Enable Admin Account Lockout option to enforce lockout for administrator user accounts.
Enable Admin Enforces lockout of an Informatica domain administrator user account after a specified Account Lockout number of failed logins. You must select the Enable Account Lockout option before you can enforce lockout for administrator user accounts.
Maximum Login Specifies the maximum number of consecutive login failures allowed before a user account Attempts is locked out of the Informatica domain.
Rules and Guidelines for Account Lockout
Consider the following rules and guidelines when you enforce account lockout for Informatica users:
• If an application service runs under a user account and the wrong password is provided for the application service, the user account can become locked when the application service tries to start. The Data Integration Service, Web Services Hub Service, and PowerCenter Integration Service are resilient application services that use a user name and password to authenticate with the Model Repository Service or PowerCenter Repository Service. If the Data Integration Service, Web Services Hub Service, or PowerCenter Integration Service continually try to restart after a failed login, the domain eventually locks the associated user account.
• If an LDAP user account is locked out of the Informatica domain and the LDAP authentication server, the Informatica domain administrator can unlock the account in the Informatica domain. The LDAP administrator can unlock the user account in the LDAP server.
• If you enable account lockout in the Informatica domain and in the LDAP server, configure the same threshold for login failures in the Informatica domain and in the LDAP server to avoid confusion about the account lockout policy.
• If account lockout is not enabled in the Informatica domain but a user is locked out, verify that the user is not locked out in the LDAP server.
Account Lockout 127 C h a p t e r 9
Privileges and Roles
This chapter includes the following topics:
• Privileges and Roles Overview, 128
• Domain Privileges, 130
• Analyst Service Privileges, 137
• Content Management Service Privileges, 138
• Data Integration Service Privileges, 138
• Metadata Manager Service Privileges, 139
• Model Repository Service Privileges, 142
• PowerCenter Repository Service Privileges, 143
• PowerExchange Listener Service Privileges, 156
• PowerExchange Logger Service Privileges, 157
• Scheduler Service Privileges, 158
• Test Data Manager Service Privileges, 158
• Managing Roles, 161
• Assigning Privileges and Roles to Users and Groups, 165
• Viewing Users with Privileges for a Service, 166
• Troubleshooting Privileges and Roles, 166
Privileges and Roles Overview
You manage user security with privileges and roles.
Privileges
Privileges determine the actions that users can perform in application clients. Informatica includes the following privileges:
• Domain privileges. Determine actions that users can perform on the Informatica domain using the Administrator tool and the infacmd and pmrep command line programs.
• Analyst Service privilege. Determines actions that users can perform using Informatica Analyst.
• Content Management Service privilege. Determines actions that users can perform using reference tables in the Informatica Developer tool and the Informatica Analyst tool.
128 • Data Integration Service privilege. Determines actions on applications that users can perform using the Administrator tool and the infacmd command line program. This privilege also determines whether users can drill down and export profile results.
• Metadata Manager Service privileges. Determine actions that users can perform using Metadata Manager.
• Model Repository Service privilege. Determines actions on projects that users can perform using Informatica Analyst and Informatica Developer.
• PowerCenter Repository Service privileges. Determine PowerCenter repository actions that users can perform using the Repository Manager, Designer, Workflow Manager, Workflow Monitor, and the pmrep and pmcmd command line programs.
• PowerExchange application service privileges. Determine actions that users can perform on the PowerExchange Listener Service and PowerExchange Logger Service using the infacmd pwx commands.
• Scheduler Service privileges. Determine actions that users can perform using the Scheduler Service.
• Test Data Manager Service privileges. Determine data discovery, data masking, data subset, and test data generation tasks that users can perform using the Test Data Manager. You assign privileges to users and groups for application services. You can assign different privileges to a user for each application service of the same service type.
You assign privileges to users and groups on the Security tab of the Administrator tool.
The Administrator tool organizes privileges into levels. A privilege is listed below the privilege that it includes. Some privileges include other privileges. When you assign a privilege to users and groups, the Administrator tool also assigns any included privileges.
Privilege Groups The domain and application service privileges are organized into privilege groups. A privilege group is an organization of privileges that define common user actions. For example, the domain privileges include the following privilege groups:
• Tools. Includes privileges to log in to the Administrator tool.
• Security Administration. Includes privileges to manage users, groups, roles, and privileges.
• Domain Administration. Includes privileges to manage the domain, folders, nodes, grids, licenses, and application services.
Tip: When you assign privileges to users and user groups, you can select a privilege group to assign all privileges in the group.
Roles
A role is a collection of privileges that you assign to a user or group. Each user within an organization has a specific role, whether the user is a developer, administrator, basic user, or advanced user.
For example, the PowerCenter Developer role includes all the PowerCenter Repository Service privileges or actions that a developer performs.
You assign a role to users and groups for the domain and for application services in the domain.
Tip: If you organize users into groups and then assign roles and permissions to the groups, you can simplify user administration tasks. For example, if a user changes positions within the organization, move the user to another group. If a new user joins the organization, add the user to a group. The users inherit the roles and permissions assigned to the group. You do not need to reassign privileges, roles, and permissions. For more information, see the following Informatica How-To Library article: https://kb.informatica.com/h2l/HowTo%20Library/1/0236-GroupsAndRolesToManageAccessControl.pdf.
Privileges and Roles Overview 129 Domain Privileges
Domain privileges determine the actions that users can perform using the Administrator tool and the infacmd and pmrep command line programs.
The following table describes each domain privilege group:
Privilege Group Description
Security Administration Includes privileges to manage users, groups, roles, and privileges.
Domain Administration Includes privileges to manage the domain, folders, nodes, grids, licenses, application services, connections, and cluster configurations.
Monitoring Includes privileges to configure monitoring statistics and reports, view monitoring for integration objects, and access monitoring.
Tools Includes privileges to log in to the Administrator tool.
Cloud Administration Includes privileges to add Informatica Cloud organizations in the Administrator tool and view them.
Security Administration Privilege Group
Privileges in the Security Administration privilege group and domain object permissions determine the security management actions users can perform.
Some security management tasks are determined by the Administrator role, not by privileges or permissions. A user assigned the Administrator role for the domain can complete the following tasks:
• Create, edit, and delete operating system profiles.
• Grant permission on operating system profiles.
Note: To complete security management tasks in the Administrator tool, users must also have the Access Informatica Administrator privilege.
Grant Privileges and Roles Privilege Users assigned the Grant Privileges and Roles privilege can assign privileges and roles to users and groups.
The following table lists the required permissions and the actions that users can perform with the Grant Privileges and Roles privilege:
Permission On Description
Domain or application User is able to perform the following actions: service - Assign privileges and roles to users and groups for the domain or application service. - Edit and remove the privileges and roles assigned to users and groups.
Manage Users, Groups, and Roles Privilege Users assigned the Manage Users, Groups, and Roles privilege can configure LDAP authentication and manage users, groups, and roles.
The Manage Users, Groups, and Roles privilege includes the Grant Privileges and Roles privilege.
130 Chapter 9: Privileges and Roles The following table lists the required permissions and the actions that users can perform with the Manage Users, Groups, and Roles privilege:
Permission On Description
- User is able to perform the following actions: - Configure LDAP authentication for the domain. - Create, edit, and delete users, groups, and roles. - Import LDAP users and groups.
Operating system profile User is able to edit operating system profile properties.
Domain Administration Privilege Group
Domain management actions that users can perform depend on privileges in the Domain Administration group and permissions on domain objects.
Some domain management tasks are determined by the Administrator role, not by privileges or permissions. A user assigned the Administrator role for the domain can complete the following tasks:
• Configure domain properties.
• Configure cluster configurations.
• Grant permission on the domain.
• Manage and purge log events.
• Receive domain alerts.
• Run the License Report.
• View user activity log events.
• Shut down the domain.
• Access the service upgrade wizard. Users who are assigned domain object permissions but not privileges can complete some domain management tasks. The following table lists the actions that users can perform when they are assigned domain object permissions only:
Permission On Description
Domain User can perform the following actions: - View domain properties and log events. - Configure monitoring settings.
Folder User can view folder properties.
Application service User can view application service properties and log events.
License object User can view license object properties.
Grid User can view grid properties.
Node User can view node properties.
Web Services Hub User can run the Web Services Report.
Domain Privileges 131 Note: To complete domain management tasks in the Administrator tool, users must also have the Access Informatica Administrator privilege.
Manage Service Execution Privilege Users assigned the Manage Service Execution privilege can enable and disable application services and receive application service alerts.
The following table lists the required permissions and the actions that users can perform with the Manage Service Execution privilege:
Permission On Description
Application User is able to perform the following actions: service - Enable and disable application services and service processes. To enable and disable a Metadata Manager Service, users must also have permission on the associated PowerCenter Integration Service and PowerCenter Repository Service. - Receive application service alerts.
Manage Services Privilege
Users assigned the Manage Services privilege can create, configure, move, remove, and grant permission on application services and license objects.
The Manage Services privilege includes the Manage Service Execution privilege.
The following table lists the required permissions and the actions that users can perform with the Manage Services privilege:
Permission On Description
Domain or parent folder User is able to create license objects.
Domain or parent folder, User is able to create application services. node or grid where application service runs, license object, and any associated application service
Application service User is able to perform the following actions: - Configure application services. - Grant permission on application services.
Original and destination User is able to move application services or license objects from one folder to folders another.
Domain or parent folder and User is able to remove application services. application service
Analyst Service User is able to create and delete audit trail tables.
132 Chapter 9: Privileges and Roles Permission On Description
Metadata Manager Service User is able to perform the following actions: - Back up Metadata Manager repository content. - Delete Metadata Manager repository content. - Upgrade the content of the Metadata Manager Service. Note: To create or restore Metadata Manager repository content, the user must belong to the default Administrator group.
Metadata Manager Service User is able to restore the PowerCenter repository for Metadata Manager. PowerCenter Repository Service
Model Repository Service User is able to perform the following actions: - Create and delete Model repository content. - Create, delete, and re-index the search index. - Upgrade the content of the Model Repository Service from the Actions menu or from the command line. The user must also have the Create, Edit and Delete Projects privilege on the Model Repository Service and write permission on the projects.
PowerCenter Integration User is able to run the PowerCenter Integration Service in safe mode. Service
PowerCenter Repository User is able to perform the following actions: Service - Back up, restore, and upgrade the PowerCenter repository. - Configure data lineage for the PowerCenter repository. - Copy content from another PowerCenter repository. - Close user connections and release PowerCenter repository locks. - Create and delete PowerCenter repository content. - Create, edit, and delete reusable metadata extensions in the PowerCenter Repository Manager. - Enable version control for the PowerCenter repository. - Manage a PowerCenter repository domain. - Perform an advanced purge of object versions at the repository level in the PowerCenter Repository Manager. - Register and unregister PowerCenter repository plug-ins. - Run the PowerCenter repository in exclusive mode. - Send PowerCenter repository notifications to users. - Update PowerCenter repository statistics. - Upgrade the content of the PowerCenter Repository Service.
Test Data Manager Service User is able to perform the following actions: - Create and delete the Test Data Manager repository content. - Upgrade the content of the Test Data Manager Service.
License object User is able to perform the following actions: - Edit license objects. - Grant permission on license objects.
License object and User is able to assign a license to an application service. application service
Domain or parent folder and User is able to remove license objects. license object
Domain Privileges 133 Manage Nodes and Grids Privilege Users assigned the Manage Nodes and Grids privilege can create, configure, move, remove, shut down, and grant permission on nodes and grids.
The following table lists the required permissions and the actions that users can perform with the Manage Nodes and Grids privilege:
Permission On Description
Domain or parent folder User is able to create nodes.
Domain or parent folder and nodes assigned to the User is able to create grids. grid
Node or grid User is able to perform the following actions: - Configure and shut down nodes and grids. - Grant permission on nodes and grids.
Original and destination folders User is able to move nodes and grids from one folder to another.
Domain or parent folder and node or grid User is able to remove nodes and grids.
Manage Domain Folders Privilege Users assigned the Manage Domain Folders privilege can create, edit, move, remove, and grant permission on domain folders.
The following table lists the required permissions and the actions that users can perform with the Manage Domain Folders privilege:
Permission On Description
Domain or parent folder User is able to create folders.
Folder User is able to perform the following actions: - Edit folders. - Grant permission on folders.
Original and destination folders User is able to move folders from one parent folder to another.
Domain or parent folder and folder being removed User is able to remove folders.
Manage Connections Privilege Users assigned the Manage Connections privilege can create, edit, and delete connections in the Administrator tool, Analyst tool, Developer tool, and infacmd command line program. Users can also copy connections in the Developer tool and can grant permissions on connections in the Administrator tool and infacmd command line program.
Users assigned the Manage Connections privilege can also create, refresh, and delete cluster configurations and set and clear configuration properties in the Administrator tool and the infacmd command line program.
134 Chapter 9: Privileges and Roles Users assigned connection permissions but not the Manage Connections privilege can perform the following connection management actions:
• View all connection metadata, except passwords. Requires read permission on connection.
• Preview data or run a mapping, scorecard, or profile. Requires execute permission on connection. The following table lists the required permissions and the actions that users can perform with the Manage Connections privilege:
Permission Description
- User is able to create connections and cluster configurations.
Write on connection User is able to copy, edit, and delete connections.
Grant on connection User is able to grant and revoke permissions on connections.
Write on cluster configuration User is able to create, refresh, and delete cluster configurations. User is able to set and clear cluster configuration properties.
Monitoring Privilege Group
The privileges in the Monitoring privilege group determine which users can view and configure monitoring.
The following table lists the required permissions and the actions that users can perform with the privileges in the Manage Monitoring group:
Parent Privilege Privilege Permission Description On
Manage Monitoring Domain User can configure monitoring settings. Monitoring Configuration
Manage Report and Statistic Domain User can configure monitoring statistics and Monitoring Settings reports.
View View Jobs of All the Domain A user in a group can monitor the jobs run by other Users in the Groups the users in the group. If the user belongs to multiple User Belongs To groups, the user can see the jobs from all the groups.
View Jobs of All View Jobs of Other Domain User can view jobs of other users. the Users in the Users Groups the User Belongs To
View View Statistics Domain User can view the Summary Statistics view and statistics for domain objects. Note: In a domain that uses Kerberos authentication, users must also have the Administrator role for the monitoring Model Repository Service to view Summary Statistics view and statistics for the domain objects.
View View Reports Domain User can view reports for domain objects.
Domain Privileges 135 Parent Privilege Privilege Permission Description On
Access Access from Analyst Domain User can access the Job Status workspace in the Monitoring Tool Analyst tool.
Access Access from Developer Domain User can access the Monitoring tool from the Monitoring Tool Developer tool.
Access Access from Domain User can access the Monitor tab in the Monitoring Administrator Tool Administrator tool.
N/A Perform Actions on Domain User can perform the following actions: Jobs - Abort jobs. - Reissue mapping jobs. - View job logs.
Users do not need the Access Informatica Administrator privilege to access the Monitoring tool.
Tools Privilege Group
The privilege in the domain Tools group determines which users can access the Administrator tool.
The following table lists the required permissions and the actions that users can perform with the privilege in the Tools group:
Privilege Description
Access Informatica Administrator User is able to perform the following actions: - Log in to the Administrator tool. - Manage their own user account in the Administrator tool. - Export log events.
Users must have the Access Informatica Administrator privilege in order to complete tasks in the Administrator tool. Users do not need the Access Informatica Administrator privilege to run infacmd commands or access the Monitoring tool.
Cloud Administration Privilege Group
The privileges in the Cloud Administration group determine which users can view and configure Informatica Cloud organizations.
The following table lists the required permissions and the actions that users can perform with the privileges in the Cloud Administration group:
Privilege Permission On Description
View Organization Domain User can view the Informatica Cloud organizations and the associated Secure Agents and cloud connections.
Manage Organization Domain User can add Informatica Cloud organizations in the Administrator tool.
136 Chapter 9: Privileges and Roles Analyst Service Privileges
The Analyst Service privilege determines actions that licensed users can perform on projects using the Analyst tool.
The following table lists the privileges and permissions required to manage projects and objects in projects:
Privilege Permission Description
Run Profiles and Read on projects. User is able to run profiles and scorecards for licensed users in the Scorecards Execute on Analyst tool. relational data source connection.
Access Mapping Read on projects. User is able to access mapping specifications for licensed users in the Specifications Analyst tool.
Load Mapping Write on projects. User is able to load the results of a mapping specification for licensed Specification Results users to a table or flat file. Note: Selecting this privilege also grants the Access Mapping Specifications privilege by default.
Manage Glossaries - User is able to manage the business glossary.
View Glossaries - User is able to view published Business Glossary assets in the Library workspace. This is equivalent to providing read permission for glossaries and Glossary assets in the Glossary Security workspace.
Workspace Access - User is able to access the following workspaces in the Analyst tool: - Design workspace. - Discovery workspace. - Glossary workspace. - Scorecards workspace. Note: Selecting this privilege also grants access to projects in the Analyst tool. If the user does not have this privilege, the user must have either the Design Workspace, Discovery Workspace, Glossary Workspace, or Scorecards Workspace privilege to access projects.
Design Workspace - User is able to access the Design workspace.
Discovery Workspace - User is able to access the Discovery workspace.
Glossary Workspace - User is able to access the Glossary workspace.
Scorecards - User is able to access the Scorecards workspace. Workspace
Analyst Service Privileges 137 Content Management Service Privileges
The Content Management Service privileges determine actions that licensed users can perform on reference tables.
The following table lists the privileges and permissions required to manage reference tables:
Privilege Permission Description
Create Write on project - Create a reference table in the Analyst and Developer tool. Reference - Create a reference table with infacmd rtm import. Tables - Import a reference table object to the Model repository. - Copy a reference table in the Analyst and Developer tool. - Create a reference table from profile data. Note: The Create privilege also grants the Edit privilege by default.
Edit Reference Read on project - Edit reference table data values in the Developer tool and Analyst tool. Table Data and - Add profile data to a reference table. Metadata - Add or delete columns in a reference table. Change reference table metadata such as column names, descriptions, and default values.
Data Integration Service Privileges
The Data Integration Service privileges determine actions that users can perform on applications using the Administrator tool and the infacmd command line program. They also determine whether users can drill down and export profile results using the Analyst tool and the Developer tool.
The following table lists the actions that users can perform with the privilege in the Application Administration privilege group:
Privilege Name Description
Manage Applications User is able to perform the following actions: - Back up and restore an application to a file. - Deploy an application to a Data Integration Service and resolve name conflicts. - Start an application after deployment. - Find an application. - Start or stop objects in an application. - Configure application properties.
The following table lists the required permissions and the actions that users can perform with the privilege in the Profiling Administration privilege group:
Privilege Name Permission On Description
Drilldown and Read on project User is able to perform the following Export Results Execute on relational data source connection is actions: also required to drill down on live data - Drill down profiling results. - Export profiling results.
138 Chapter 9: Privileges and Roles Metadata Manager Service Privileges
Metadata Manager Service privileges determine the Metadata Manager actions that users can perform using Metadata Manager.
The following table describes each Metadata Manager privilege group:
Privilege Group Description
Catalog Includes privileges to manage objects in the Browse page of the Metadata Manager interface.
Load Includes privileges to manage objects in the Load page of the Metadata Manager interface.
Model Includes privileges to manage objects in the Model page of the Metadata Manager interface.
Security Includes privileges to manage objects in the Security page of the Metadata Manager interface.
Catalog Privilege Group
The privileges in the Catalog privilege group determine the tasks that users can perform on the Browse tab of the Metadata Manager application. A user with the privilege to perform a certain action also requires permissions to perform the action on a particular object. Configure permissions on the Security tab of the Metadata Manager application.
The following table lists the privileges in the Catalog privilege group and the permissions required to perform a task on an object:
Privilege Includes Permission Description Privileges
Share Shortcuts n/a Write User is able to share a folder that contains a shortcut with other users and groups.
View Lineage n/a Read User is able to perform the following actions: - Run data lineage analysis on metadata objects, categories, and business terms. - Run data lineage analysis from the PowerCenter Designer. Users must also have read permission on the PowerCenter repository folder.
View Related n/a Read User is able to view related catalogs. Catalogs
View Profile n/a Read User is able to view profiling information for metadata Results objects in the catalog from a relational source.
View Catalog n/a Read User is able to perform the following actions: - View resources and metadata objects in the metadata catalog. - Search the metadata catalog.
View n/a Read User is able to view relationships for metadata objects, Relationships categories, and business terms.
Metadata Manager Service Privileges 139 Privilege Includes Permission Description Privileges
Manage View Write User is able to create, edit, and delete relationships for Relationships Relationships custom metadata objects, categories, and business terms.
View Comments n/a Read User is able to view comments for metadata objects, categories, and business terms.
Post Comments View Comments Write User is able to add comments for metadata objects, categories, and business terms.
Delete Comments - Post Write User is able to delete comments for metadata objects, Comments categories, and business terms. - View Comments
View Links n/a Read User is able to view links for metadata objects, categories, and business terms.
Manage Links View Links Write User is able to create, edit, and delete links for metadata objects, categories, and business terms.
View Glossary n/a Read User is able to perform the following actions: - View business glossaries in the Glossary view. - Search business glossaries.
Manage Objects n/a Write User is able to perform the following actions: - Edit metadata objects in the catalog. - Create, edit, and delete custom metadata objects. Users must also have the View Model privilege. - Create, edit, and delete custom metadata resources. Users must also have the Manage Resource privilege.
Load Privilege Group
The privileges in the Load privilege group determine the tasks that users can perform on the Load tab of the Metadata Manager application. A user with the privilege to perform a certain action also requires
140 Chapter 9: Privileges and Roles permissions to perform the action on a particular object. Configure permissions on the Security tab of the Metadata Manager application.
The following table lists the privileges and permissions required to manage an instance of a resource in the Metadata Manager warehouse:
Privilege Includes Privileges Permission Description
View Resource - Read User is able to perform the following actions: - View resources and resource properties in the Metadata Manager warehouse. - Export resource configurations. - Download the Metadata Manager Agent installer.
Load Resource View Resource Write User is able to perform the following actions: - Load metadata for a resource into the Metadata Manager warehouse.* - Create links between objects in connected resources for data lineage. - Configure search indexing for resources. - Import resource configurations.
Manage Schedules View Resource Write User is able to perform the following actions: - Create and edit schedules. - Add schedules to resources.
Purge Metadata View Resource Write User is able to remove metadata for a resource from the Metadata Manager warehouse.
Manage Resource - Purge Metadata Write User is able to create, edit, and delete resources. - View Resource
* To load metadata for Business Glossary resources, the Load Resource, Manage Resource, and View Model privileges are required.
Model Privilege Group
The privileges in the Model privilege group determine the tasks that users can perform on the Model tab of the Metadata Manager application. You cannot configure permissions on a model.
The following table lists the privileges required to manage models:
Privilege Includes Permission Description Privileges
View Model - - User is able to open models and classes, and view model and class properties. View relationships and attributes for classes.
Manage Model View Model - User is able to create, edit, and delete custom models. Add attributes to packaged and universal models.
Export/Import View Model - User is able to import and export custom models. Import and Models export modified packaged and universal models.
Metadata Manager Service Privileges 141 Security Privilege Group
The privileges in the Security privilege group determines the tasks that users can perform on the Security tab of the Metadata Manager application.
By default, the Manage Catalog Permissions privilege in the Security privilege group is assigned to the Administrator, or a user with the Administrator role on the Metadata Manager Service. You can assign the Manage Catalog Permissions privilege to other users.
The following table lists the privilege and permission required to manage Metadata Manager security:
Privilege Includes Permission Description Privileges
Manage Catalog - Full control User is able to perform the following actions: Permissions - Assign users and groups permissions on resources, metadata objects, categories, and business terms. - Edit permissions on resources, metadata objects, categories, and business terms.
Model Repository Service Privileges
The Model Repository Service privileges determine actions that users can perform on projects using Informatica Analyst and Informatica Developer.
The Model repository object permissions determine the tasks that users can complete on objects in projects.
The following table lists the required permissions and the actions that users can perform with the Model Repository Service privileges:
Privilege Permission Description
N/A Read on project User can view projects and objects in projects.
N/A Write on project User can create, edit, and delete objects in projects.
N/A Grant on project User can grant and revoke permissions on projects for users and groups.
Access Analyst N/A User can access the Model repository from the Analyst tool.
Access Developer N/A User can access the Model repository from the Developer tool.
Create, Edit, and N/A User can create projects. Delete Projects
Create, Edit, and Write on projects User can perform the following actions: Delete Projects - Edit projects. - Delete projects if the user created the projects. - Upgrade the content of the Model Repository Service. To upgrade the service from the Actions menu or from the command line, the user must also have the Manage Service privilege for the domain and permission on the Model Repository Service. To upgrade the service using the service upgrade wizard, the user must also have the Administrator role for the domain.
142 Chapter 9: Privileges and Roles Privilege Permission Description
Manage Data N/A User can create, edit, and delete data domains in the data domain Domains glossary. This privilege is part of the Data Domain Administration privilege group.
Manage N/A User can configure scorecard notifications. This privilege is part of the Notifications Profiling Administration privilege group.
Manage Team- N/A User can manage the locked or unlocked states of Model repository based Development objects. If the Model repository is integrated with a version control system, the user can manage the checked out or checked in states of objects. The user can also manage the ownership of checked-out objects.
Show Security N/A User can view the following details: Details - Names of projects for which users do not have read permission. - Error and warning message details.
PowerCenter Repository Service Privileges
PowerCenter Repository Service privileges determine PowerCenter repository actions that users can perform using the PowerCenter Repository Manager, Designer, Workflow Manager, Workflow Monitor, and the pmrep and pmcmd command line programs.
The following table describes each privilege group for the PowerCenter Repository Service:
Privilege Group Description
Tools Includes privileges to access PowerCenter Client tools and command line programs.
Folders Includes privileges to manage repository folders.
Design Objects Includes privileges to manage business components, mapping parameters and variables, mappings, mapplets, transformations, and user-defined functions.
Sources and Targets Includes privileges to manage cubes, dimensions, source definitions, and target definitions.
Run-time Objects Includes privileges to manage session configuration objects, tasks, workflows, and worklets.
Global Objects Includes privileges to manage connection objects, deployment groups, labels, and queries.
Users must have the Manage Services domain privilege and permission on the PowerCenter Repository Service to perform the following actions in the Repository Manager:
• Perform an advanced purge of object versions at the PowerCenter repository level.
• Create, edit, and delete reusable metadata extensions.
Tools Privilege Group
The privileges in the PowerCenter Repository Service Tools privilege group determine the PowerCenter Client tools and command line programs that users can access.
PowerCenter Repository Service Privileges 143 The following table lists the actions that users can perform for the privileges in the Tools group:
Privilege Permission Description
Access Designer - User is able to connect to the PowerCenter repository using the Designer.
Access Repository - User is able to perform the following actions: Manager - Connect to the PowerCenter repository using the Repository Manager. - Run pmrep commands.
Access Workflow - User is able to perform the following actions: Manager - Connect to the PowerCenter repository using the Workflow Manager. - Remove a PowerCenter Integration Service from the Workflow Manager.
Access Workflow - User is able to perform the following actions: Monitor - Connect to the PowerCenter repository using the Workflow Monitor. - Connect to the PowerCenter Integration Service in the Workflow Monitor.
Note: When the PowerCenter Integration Service runs in safe mode, users must have the Administrator role for the associated PowerCenter Repository Service.
The appropriate privilege in the Tools privilege group is required for all users completing tasks in PowerCenter Client tools and command line programs. For example, to create folders in the Repository Manager, a user must have the Create Folders and Access Repository Manager privileges.
If users have a privilege in the Tools privilege group and permission on a PowerCenter repository object but not the privilege to modify the object type, they can still perform some actions on the object. For example, a user has the Access Repository Manager privilege and read permission on some folders. The user does not have any of the privileges in the Folders privilege group. The user can view objects in the folders and compare the folders.
Folders Privilege Group
Folder management actions are determined by privileges in the Folders privilege group, PowerCenter repository object permissions, and domain object permissions. Users perform folder management actions in the Repository Manager and with the pmrep command line program.
Some folder management tasks are determined by folder ownership and the Administrator role, not by privileges or permissions. The folder owner or a user assigned the Administrator role for the PowerCenter Repository Service can complete the following folder management tasks:
• Assign operating system profiles to folders if the PowerCenter Integration Service uses operating system profiles. Requires permission on the operating system profile.
• Change the folder owner.
• Configure folder permissions.
• Delete the folder.
• Designate the folder to be shared.
• Edit the folder name and description.
144 Chapter 9: Privileges and Roles Users assigned folder permissions but no privileges can perform some folder management actions. The following table lists the actions that users can perform when they are assigned folder permissions only:
Permission Description
Read on folder User is able to perform the following actions: - Compare folders. - View objects in folders.
Note: To perform actions on folders, users must also have the Access Repository Manager privilege.
Create Folders Privilege Users assigned the Create Folders privilege can create PowerCenter repository folders.
The following table lists the required permissions and the actions that users can perform with the Create Folders privilege:
Permission Description
- User is able to create folders.
Copy Folders Privilege Users assigned the Copy Folders privilege can copy folders within a PowerCenter repository or to another PowerCenter repository.
The following table lists the required permissions and the actions that users can perform with the Copy Folders privilege:
Permission Description
Read on folder User is able to copy folders within the same PowerCenter repository or to another PowerCenter repository. Users must also have the Create Folders privilege in the destination repository.
Manage Folder Versions If you have a team-based development option, assign users the Manage Folder Versions privilege in a versioned PowerCenter repository. Users can change the status of folders and perform an advanced purge of object versions at the folder level.
The following table lists the required permissions and the actions that users can perform with the Manage Folder Versions privilege:
Permission Description
Read and Write on folder User is able to perform the following actions: - Change the status of folders. - Perform an advanced purge of object versions at the folder level.
PowerCenter Repository Service Privileges 145 Design Objects Privilege Group
Privileges in the Design Objects privilege group and PowerCenter repository object permissions determine actions users can perform on the following design objects:
• Business components
• Mapping parameters and variables
• Mappings
• Mapplets
• Transformations
• User-defined functions Users assigned permissions but no privileges can perform some actions for design objects. The following table lists the actions that users can perform when they are assigned permissions only:
Permission Description
Read on folder User is able to perform the following actions: - Compare design objects. - Copy design objects as an image. - Export design objects. - Generate code for Custom transformation and external procedures. - Receive PowerCenter repository notification messages. - Run data lineage on design objects. Users must also have the View Lineage privilege for the Metadata Manager Service and read permission on the metadata objects in the Metadata Manager catalog. - Search for design objects. - View design objects, design object dependencies, and design object history.
Read on shared folder User is able to create shortcuts. Read and Write on destination folder
Note: To perform actions on design objects, users must also have the appropriate privilege in the Tools privilege group.
146 Chapter 9: Privileges and Roles Create, Edit, and Delete Design Objects Privilege Users assigned the Create, Edit, and Delete Design Objects privilege can create, edit, and delete business components, mapping parameters, mapping variables, mappings, mapplets, transformations, and user- defined functions.
The following table lists the required permissions and the actions that users can perform with the Create, Edit, and Delete Design Objects privilege:
Permission Description
Read on original folder User is able to perform the following actions: Read and Write on - Copy design objects from one folder to another. destination folder - Copy design objects to another PowerCenter repository. Users must also have the Create, Edit, and Delete Design Objects privilege in the destination repository.
Read and Write on User is able to perform the following actions: folder - Change comments for a versioned design object. - Check in and undo a checkout of design objects checked out by their own user account. - Check out design objects. - Copy and paste design objects in the same folder. - Create, edit, and delete data profiles and launch the Profile Manager. Users must also have the Create, Edit, and Delete Run-time Objects privilege. - Create, edit, and delete design objects. - Generate and clean SAP ABAP programs. - Generate business content integration mappings. Users must also have the Create, Edit, and Delete Sources and Targets privilege. - Import design objects using the Designer. Users must also have the Create, Edit, and Delete Sources and Targets privilege. - Import design objects using the Repository Manager. Users must also have the Create, Edit, and Delete Run-time Objects and Create, Edit, and Delete Sources and Targets privileges. - Revert to a previous design object version. - Validate mappings, mapplets, and user-defined functions.
Manage Design Object Versions If you have a team-based development option, assign users the Manage Design Object Versions privilege in a versioned PowerCenter repository. Users can change the status, recover, and purge design object versions. Users can also check in and undo checkouts made by other users.
The Manage Design Object Versions privilege includes the Create, Edit, and Delete Design Objects privilege.
PowerCenter Repository Service Privileges 147 The following table lists the required permissions and the actions that users can perform with the Manage Design Object Versions privilege:
Permission Description
Read and Write on folder User is able to perform the following actions: - Change the status of design objects. - Check in and undo checkouts of design objects checked out by other users. - Purge versions of design objects. - Recover deleted design objects.
Sources and Targets Privilege Group
Privileges in the Sources and Targets privilege group and PowerCenter repository object permissions determine actions users can perform on the following source and target objects:
• Cubes
• Dimensions
• Source definitions
• Target definitions Users assigned permissions but no privileges can perform some actions for source and target objects. The following table lists the actions that users can perform when they are assigned permissions only:
Permission Description
Read on folder User is able to perform the following actions: - Compare source and target objects. - Export source and target objects. - Preview source and target data. - Receive PowerCenter repository notification messages. - Run data lineage on source and target objects. Users must also have the View Lineage privilege for the Metadata Manager Service and read permission on the metadata objects in the Metadata Manager catalog. - Search for source and target objects. - View source and target objects, source and target object dependencies, and source and target object history.
Read on shared folder Create shortcuts. Read and Write on destination folder
Note: To perform actions on source and target objects, users must also have the appropriate privilege in the Tools privilege group.
148 Chapter 9: Privileges and Roles Create, Edit, and Delete Sources and Targets Privilege Users assigned the Create, Edit, and Delete Sources and Targets privilege can create, edit, and delete cubes, dimensions, source definitions, and target definitions.
The following table lists the required permissions and the actions that users can perform with the Create, Edit, and Delete Sources and Targets privilege:
Permission Description
Read on original User is able to perform the following actions: folder - Copy source and target objects to another folder. Read and Write on - Copy source and target objects to another PowerCenter repository. Users must also have destination folder the Create, Edit, and Delete Sources and Targets privilege in the destination repository.
Read and Write on User is able to perform the following actions: folder - Change comments for a versioned source or target object. - Check in and undo a checkout of source and target objects checked out by their own user account. - Check out source and target objects. - Copy and paste source and target objects in the same folder. - Create, edit, and delete source and target objects. - Import SAP functions. - Import source and target objects using the Designer. Users must also have the Create, Edit, and Delete Design Objects privilege. - Import source and target objects using the Repository Manager. Users must also have the Create, Edit, and Delete Design Objects and Create, Edit, and Delete Run-time Objects privileges. - Generate and execute SQL to create targets in a relational database. - Revert to a previous source or target object version.
Manage Source and Target Versions Privilege If you have a team-based development option, assign users the Manage Source and Target Versions privilege in a versioned PowerCenter repository. Users can change the status, recover, and purge versions of source and target objects. Users can also check in and undo checkouts made by other users.
The Manage Source and Target Versions privilege includes the Create, Edit, and Delete Sources and Targets privilege.
The following table lists the required permissions and the actions that users can perform with the Manage Source and Target Versions privilege:
Permission Description
Read and Write on folder User is able to perform the following actions: - Change the status of source and target objects. - Check in and undo checkouts of source and target objects checked out by other users. - Purge versions of source and target objects. - Recover deleted source and target objects.
PowerCenter Repository Service Privileges 149 Run-time Objects Privilege Group
Privileges in the Run-time Objects privilege group, PowerCenter repository object permissions, and domain object permissions determine actions users can perform on the following run-time objects:
• Session configuration objects
• Tasks
• Workflows
• Worklets Some run-time object tasks are determined by the Administrator role, not by privileges or permissions. A user assigned the Administrator role for the PowerCenter Repository Service can delete a PowerCenter Integration Service from the Navigator of the Workflow Manager.
Users assigned permissions but no privileges can perform some actions for run-time objects. The following table lists the actions that users can perform when they are assigned permissions only:
Permission Description
Read on folder User is able to perform the following actions: - Compare run-time objects. - Export run-time objects. - Receive PowerCenter repository notification messages. - Search for run-time objects. - Use mapping parameters and variables in a session. - View run-time objects, run-time object dependencies, and run-time object history.
Read and Execute Stop and abort tasks and workflows started by their own user account. on folder When the PowerCenter Integration Service runs in safe mode, users must have the Administrator role for the associated PowerCenter Repository Service.
Note: To perform actions on run-time objects, users must also have the appropriate privilege in the Tools privilege group.
150 Chapter 9: Privileges and Roles Create, Edit, and Delete Run-time Objects Privilege Users assigned the Create, Edit, and Delete Run-time Objects privilege can create, edit, and delete session configuration objects, tasks, workflows, and worklets.
The following table lists the required permissions and the actions that users can perform with the Create, Edit, and Delete Run-time Objects privilege:
Permission Description
Read on original folder User is able to perform the following actions: Read and Write on - Copy tasks, workflows, or worklets from one folder to another. destination folder - Copy tasks, workflows, or worklets to another PowerCenter repository. Users must also have the Create, Edit, and Delete Run-time Objects privilege in the destination repository.
Read and Write on User is able to perform the following actions: folder - Assign a PowerCenter Integration Service to a workflow in the workflow properties. - Assign a service level to a workflow. - Change comments for a versioned run-time object. - Check in and undo a checkout of run-time objects checked out by their own user account. - Check out run-time objects. - Copy and paste tasks, workflows, and worklets in the same folder. - Create, edit, and delete data profiles and launch the Profile Manager. Users must also have the Create, Edit, and Delete Design Objects privilege. - Create, edit, and delete session configuration objects. - Delete and validate tasks, workflows, and worklets. - Import run-time objects using the Repository Manager. Users must also have the Create, Edit, and Delete Design Objects and Create, Edit, and Delete Sources and Targets privileges. - Import run-time objects using the Workflow Manager. - Revert to a previous object version.
Read and Write on User is able to perform the following actions: folder - Create and edit tasks, workflows, and worklets. Read on connection - Replace a relational database connection for all sessions that use the connection. object
Manage Run-time Object Versions Privilege If you have a team-based development option, assign users the Manage Run-time Object Versions privilege in a versioned PowerCenter repository. Users can change the status, recover, and purge run-time object versions. Users can also check in and undo checkouts made by other users.
The Manage Run-time Object Versions privilege includes the Create, Edit, and Delete Run-time Objects privilege.
PowerCenter Repository Service Privileges 151 The following table lists the required permissions and the actions that users can perform with the Manage Run-time Object Versions privilege:
Permission Description
Read and Write on folder User is able to perform the following actions: - Change the status of run-time objects. - Check in and undo checkouts of run-time objects checked out by other users. - Purge versions of run-time objects. - Recover deleted run-time objects.
Monitor Run-time Objects Privilege Users assigned the Monitor Run-time Objects privilege can Monitor workflows and tasks in the Workflow Monitor.
The following table lists the required permissions and the actions that users can perform with the Monitor Run-time Objects privilege:
Permission Grants Users the Ability To
Read on folder User is able to perform the following actions: - View properties of run-time objects in the Workflow Monitor. - View session and workflow logs in the Workflow Monitor. - View run-time object and performance details in the Workflow Monitor. When the PowerCenter Integration Service runs in safe mode, users must have the Administrator role for the associated PowerCenter Repository Service.
Execute Run-time Objects Privilege Users assigned the Execute Run-time Objects privilege can start, cold start, and recover tasks and workflows.
The Execute Run-time Objects privilege includes the Monitor Run-time Objects privilege.
The following table lists the required permissions and the actions that users can perform with the Execute Run-time Objects privilege:
Permission Description
Read and Execute on folder User is able to assign a PowerCenter Integration Service to a workflow using the Service menu or the Navigator.
Read, Write, and Execute on User is able to debug a mapping by creating a debug session instance or by using an folder existing reusable session. Users must also have the Create, Edit, and Delete Run-time Read and Execute on Objects privilege. connection object When the PowerCenter Integration Service runs in safe mode, users must have the Administrator role for the associated PowerCenter Repository Service.
152 Chapter 9: Privileges and Roles Permission Description
Read and Execute on folder User is able to debug a mapping by using an existing non-reusable session. Read and Execute on When the PowerCenter Integration Service runs in safe mode, users must have the connection object Administrator role for the associated PowerCenter Repository Service.
Read and Execute on folder User is able to perform the following actions: Read and Execute on - Start, cold start, and restart tasks and workflows. connection object - Recover tasks and workflows started by their own user account. If the PowerCenter Integration Service uses operating system profiles, users must also have permission on the operating system profile. When the PowerCenter Integration Service runs in safe mode, users must have the Administrator role for the associated PowerCenter Repository Service.
Manage Run-time Object Execution Privilege Users assigned the Manage Run-time Object Execution privilege can schedule and unschedule workflows. Users can also stop, abort, and recover tasks and workflows started by other users.
The Manage Run-time Object Execution privilege includes the Execute Run-time Objects privilege and the Monitor Run-time Objects privilege.
The following table lists the required permissions and the actions that users can perform with the Manage Run-time Object Execution privilege:
Permission Description
Read and Execute on User is able to truncate workflow and session log entries. folder
Read and Execute on User is able to perform the following actions: folder - Stop and abort tasks and workflows started by other users. - Stop and abort tasks that were recovered automatically. - Unschedule workflows. When the PowerCenter Integration Service runs in safe mode, users must have the Administrator role for the associated PowerCenter Repository Service.
Read and Execute on User is able to perform the following actions: folder - Recover tasks and workflows started by other users. Read and Execute on - Recover tasks that were recovered automatically. connection object If the PowerCenter Integration Service uses operating system profiles, users must also have permission on the operating system profile. When the PowerCenter Integration Service runs in safe mode, users must have the Administrator role for the associated PowerCenter Repository Service.
Read, Write, and Execute User is able to perform the following actions: on folder - Create and edit a reusable scheduler from the Workflows > Schedulers menu. Read and Execute on - Edit a non-reusable scheduler from the workflow properties. connection object - Edit a reusable scheduler from the workflow properties. Users must also have the Create, Edit, and Delete Run-time Objects privilege. If the PowerCenter Integration Service uses operating system profiles, users must also have permission on the operating system profile. When the PowerCenter Integration Service runs in safe mode, users must have the Administrator role for the associated PowerCenter Repository Service.
PowerCenter Repository Service Privileges 153 Global Objects Privilege Group
Privileges in the Global Objects privilege group and PowerCenter repository object permissions determine actions users can perform on the following global objects:
• Connection objects
• Deployment groups
• Labels
• Queries Some global object tasks are determined by global object ownership and the Administrator role, not by privileges or permissions. The global object owner or a user assigned the Administrator role for the PowerCenter Repository Service can complete the following global object tasks:
• Configure global object permissions.
• Change the global object owner.
• Delete the global object. Users assigned permissions but no privileges can perform some actions for global objects. The following table lists the actions that users can perform when they are assigned permissions only:
Permission Description
Read on connection object User is able to view connection objects.
Read on deployment group User is able to view deployment groups.
Read on label User is able to view labels.
Read on query User is able to view object queries.
Read and Write on connection object User is able to edit connection objects.
Read and Write on label User is able to edit and lock labels.
Read and Write on query User is able to edit and validate object queries.
Read and Execute on query User is able to run object queries.
Read on folder User is able to apply labels and remove label references. Read and Execute on label
Note: To perform actions on global objects, users must also have the appropriate privilege in the Tools privilege group.
154 Chapter 9: Privileges and Roles Create Connections Privilege Users assigned the Create Connections privilege can create connection objects.
The following table lists the required permissions and the actions that users can perform with the Create Connections privilege:
Permission Description
- User is able to create and copy connection objects.
Manage Deployment Groups Privilege If you have a team-based development option, users assigned the Manage Deployment Groups privilege in a versioned PowerCenter repository can create, edit, copy, and roll back deployment groups. In a non-versioned repository, users can create, edit, and copy deployment groups.
The following table lists the required permissions and the actions that users can perform with the Manage Deployment Groups privilege:
Permission Description
- User is able to create deployment groups.
Read and Write on deployment group User is able to perform the following actions: - Edit deployment groups. - Remove objects from a deployment group.
Read on original folder User is able to add objects to a deployment group. Read and Write on deployment group
Read on original folder User is able to copy deployment groups. Read and Write on destination folder Read and Execute on deployment group
Read and Write on destination folder User is able to roll back deployment groups.
Execute Deployment Groups Privilege Users assigned the Execute Deployment Groups privilege can copy a deployment group without write permission on target folders.
The following table lists the required permissions and the actions that users can perform with the Execute Deployment Groups privilege:
Permission Description
Read on original folder User is able to copy deployment groups. Execute on deployment group
PowerCenter Repository Service Privileges 155 Create Labels Privilege If you have a team-based development option, users assigned the Create Labels privilege in a versioned PowerCenter repository can create labels.
The following table lists the required permissions and the actions that users can perform with the Create Labels privilege:
Permission Description
- User is able to create labels.
Create Queries Privilege Users assigned the Create Queries privilege can create object queries.
The following table lists the required permissions and the actions that users can perform with the Create Queries privilege:
Permission Description
- User is able to create object queries.
PowerExchange Listener Service Privileges
The PowerExchange Listener Service privileges determine the infacmd pwx commands that users can run.
The following table describes the PowerExchange Listener Service privilege in the Informational Commands privilege group:
Privilege Name Description
listtask Run the infacmd pwx ListTaskListener command.
The following table describes each PowerExchange Listener Service privilege in the Management Commands privilege group:
Privilege Name Description
close Run the infacmd pwx CloseListener command.
closeforce Run the infacmd pwx CloseForceListener command.
stoptask Run the infacmd pwx StopTaskListener command.
156 Chapter 9: Privileges and Roles PowerExchange Logger Service Privileges
The PowerExchange Logger Service privileges determine the infacmd pwx commands that users can run.
The following table describes each PowerExchange Logger Service privilege in the Informational Commands privilege group:
Privilege Name Description
displayall Run the infacmd pwx DisplayAllLogger command.
displaycpu Run the infacmd pwx DisplayCPULogger command.
displaycheckpoints Run the infacmd pwx DisplayCheckpointsLogger command.
displayevents Run the infacmd pwx DisplayEventsLogger command.
displaymemory Run the infacmd pwx DisplayMemoryLogger command.
displayrecords Run the infacmd pwx DisplayRecordsLogger command.
displaystatus Run the infacmd pwx DisplayStatusLogger command.
The following table describes each PowerExchange Logger Service privilege in the Management Commands privilege group:
Privilege Name Description
condense Run the infacmd pwx CondenseLogger command.
fileswitch Run the infacmd pwx FileSwitchLogger command.
shutdown Run the infacmd pwx ShutDownLogger command.
PowerExchange Logger Service Privileges 157 Scheduler Service Privileges
Scheduler Service privileges determine the actions that users can perform on schedules and scheduled jobs.
The following table describes the Scheduler Service privileges and required permissions:
Privilege Description Requires Permission On
Create Schedule User can create schedules. To create a schedule, the - Scheduler Service user must also have the Application Administration - Data Integration Service that runs privilege on the Data Integration Service. the jobs that the user wants to schedule
Edit Schedule User can edit, pause, and resume schedules. To edit a - Scheduler Service schedule, the user must also have the Application - Data Integration Service that runs Administration privilege on the Data Integration Service. the jobs that the user wants to schedule
Delete Schedule User can delete schedules. Scheduler Service
View Schedules User can view the Schedules view and schedules. Scheduler Service
Test Data Manager Service Privileges
Test Data Manager Service privileges determine the actions that users can perform using Test Data Manager. Configure privileges on the Security tab of the Administrator tool.
The following table describes each Test Data Manager privilege group:
Privilege Group Description
Administration Includes privileges to create and manage connections, pass phrases, roles and assign privileges to users and user groups from the Informatica Administrator, manage repositories, add licenses, and set up workflow and project attributes. Note: Before you can create users and groups, the default Informatica administrator user must assign Security Administration privileges to the Test Data Administrator user.
Data Domains Includes privileges to view and manage data domains in the Test Data Manager.
Data Masking Includes privileges to view and manage masking rules and policy assignments in the Test Data Manager.
Policies Includes privileges to view and manage policies in the Test Data Manager.
Projects Includes privileges to view and manage projects, audit and import metadata, and execute plans and workflows in the Test Data Manager.
158 Chapter 9: Privileges and Roles Administration Privilege Group
The privileges in the Administration privilege group determine the administration tasks that Test Data Administrators can perform.
The following table lists the privileges in the Administration privilege group and the permissions required to perform a task on an object:
Connections Privilege Group
The privileges in the Connections privilege group determine the tasks that users can perform on the Connections page of the TDM Workbench. The following table lists the privileges in the Connections privilege group and the permissions required to perform a task on an object:
Privilege Includes Permission Description Privileges
View Connections - Read User can view connections and test connections in the TDM Workbench.
Manage View Connections Write User can perform the following actions on the Connections Connections page in the TDM Workbench: - Create connections. - Edit connections. - Delete connections. - View connections. - Test connections.
Data Domains Privilege Group
The privileges in the Data Domains privilege group determine the tasks that users can perform on data domains on the Policies page of the Test Data Manager.
The following table lists the privileges in the Data Domains privilege group and the permissions required to perform a task on an object:
Privilege Includes Permission Description Privileges
View Data - Read User can view data domains in the Test Data Manager. Domains
Manage Data View Data Write User can perform the following actions on data domains in Domains Domains the Test Data Manager: - Create data domains. - Edit data domains. - Delete data domains. - View data domains.
Test Data Manager Service Privileges 159 Data Masking Privilege Group
The privileges in the Data Masking privilege group determine the tasks that users can perform on the Project | Define | Data Masking view of the Test Data Manager. You can assign rules and polices to table columns from this view.
The following table lists the privileges in the Data Masking privilege group and the permissions required to perform a task on an object:
Privilege Includes Permission Description Privileges
View Data - Read User can view data masking assignments in the Test Data Masking Manager.
Manage Data View Data Write User can perform the following data masking assignment Masking Masking actions in the Test Data Manager: - Add rule and policy assignments. - Delete rule and policy assignments. - Override rule properties. - View data masking assignments.
Data Subset Privilege Group
The privileges in the Data Subset privilege group determine the tasks that users can perform on data subset objects in the Test Data Manager.
The following table lists the privileges in the Data Subset privilege group and the permissions required to perform a task on an object:
Policies Privilege Group
The privileges in the Policies privilege group determine the tasks that users can perform on Policies in the Test Data Manager.
The following table lists the privileges in the Policies privilege group and the permissions required to perform a task on an object:
Privilege Includes Permission Description Privileges
View Policies - Read User can view policies in the Test Data Manager.
Manage Policies View Policies Write User can perform the following policy actions policies in the Test Data Manager: - Create policies. - Edit policies. - Delete policies. - View policies.
160 Chapter 9: Privileges and Roles Projects Privilege Group
The privileges in the Projects privilege group determine the tasks that users can perform on Projects in the Test Data Manager.
The following table lists the privileges in the Projects privilege group and the permissions required to perform a task on an object: Note: A user with Manage Project privilege must have at least the following levels of privileges to be able to create a plan with each component.
• View connection from the Administration privilege group. To create a plan.
• View data subset from the Data Subset privilege group. To create a plan with subset components.
• View masking rules from the Rules privilege group. To create a plan with masking components.
Rules Privilege Group
The following table lists the privileges in the Data Masking privilege group and the permissions required to perform a task on an object:
Data Generation Privilege Group
The privileges in the Data Generation privilege group determine the test data generation tasks that users can perform in the Test Data Manager.
The following table lists the privileges in the Data Generation privilege group and the permissions required to perform a task on an object:
Privilege Includes Permission Description Privileges
View Data - Read User can view data generation rule assignments in the Test Generation Data Manager.
Manage Data View Data Write User can perform the following actions on data generation in Generation Generation the Test Data Manager: - View data generation rule assignments - Add data generation rule assignments. - Delete data generation rule assignments. - Override data generation rule assignments.
Managing Roles
A role is a collection of privileges that you can assign to users and groups. You can assign the following types of roles:
• System-defined. Roles that you cannot edit or delete.
• Custom. Roles that you can create, edit, and delete. A role includes privileges for the domain or an application service type. You assign roles to users or groups for the domain or for each application service in the domain. For example, you can create a Developer role that includes privileges for the PowerCenter Repository Service. A domain can contain multiple PowerCenter Repository Services. You can assign the Developer role to a user for the Development PowerCenter
Managing Roles 161 Repository Service. You can assign a different role to that user for the Production PowerCenter Repository Service.
When you select a role in the Roles section of the Navigator, you can view all users and groups that have been directly assigned the role for the domain and application services. You can view the role assignments by users and groups or by services. To navigate to a user or group listed in the Assignments section, right- click the user or group and select Navigate to Item.
You can search for system-defined and custom roles.
System-Defined Roles
A system-defined role is a role that you cannot edit or delete. The Administrator role is a system-defined role.
When you assign the Administrator role to a user or group for the domain, Analyst Service, Data Integration Service, Mass Ingestion Service, Metadata Manager Service, Model Repository Service, or PowerCenter Repository Service, the user or group is granted all privileges for the service. The Administrator role bypasses permission checking. Users with the Administrator role can access all objects managed by the service.
Administrator Role When you assign the Administrator role to a user or group for the domain, Data Integration Service, or PowerCenter Repository Service, the user or group can complete some tasks that are determined by the Administrator role, not by privileges or permissions.
You can assign a user or group all privileges for the domain, Data Integration Service, or PowerCenter Repository Service and then grant the user or group full permissions on all domain or PowerCenter repository objects. However, this user or group cannot complete the tasks determined by the Administrator role.
For example, a user assigned the Administrator role for the domain can configure domain properties in the Administrator tool. A user assigned all domain privileges and permission on the domain cannot configure domain properties.
The following table lists the tasks determined by the Administrator role for the domain, Data Integration Service, Mass Ingestion Service, and PowerCenter Repository Service:
Service Tasks
Domain - Configure domain properties. - Configure cluster configurations. - Create operating system profiles. - Delete operating system profiles. - Grant permission on the domain and operating system profiles. - Manage and purge log events. - Receive domain alerts. - Run the License Report. - View user activity log events. - Shut down the domain. - Access the service upgrade wizard.
Data Integration Service - Upgrade the Data Integration Service using the Actions menu.
162 Chapter 9: Privileges and Roles Service Tasks
Mass Ingestion Service - Browse all mass ingestion specifications. - Edit a mass ingestion specification. - Run a mass ingestion specification. - Delete a mass ingestion specification.
PowerCenter Repository - Assign operating system profiles to repository folders if the PowerCenter Integration Service Service uses operating system profiles.* - Change the owner of folders and global objects.* - Configure folder and global object permissions.* - Connect to the PowerCenter Integration Service from the PowerCenter Client when running the PowerCenter Integration Service in safe mode. - Delete a PowerCenter Integration Service from the Navigator of the Workflow Manager. - Delete folders and global objects.* - Designate folders to be shared.* - Edit the name and description of folders.* *The PowerCenter repository folder owner or global object owner can also complete these tasks.
Custom Roles
A custom role is a role that you can edit or delete.
By default, the Administrator tool includes the following custom roles:
• Analyst Service custom role
• Metadata Manager Service custom roles
• Operator custom role
• PowerCenter Repository Service custom roles
• Test Data Manager Service custom roles
You can edit the privileges for these roles, or delete the roles. You can also create your own custom roles.
Creating Custom Roles When you create a custom role, you assign privileges to the role for the domain or for an application service type. A role can include privileges for one or more services.
1. In the Administrator tool, click the Security tab. 2. On the Security Actions menu, click Create Role. The Create Role dialog box appears.
Managing Roles 163 3. Enter the following properties for the role:
Property Description
Name Name of the role. The role name is case insensitive and cannot exceed 128 characters. It cannot include a tab, newline character, or the following special characters: , + " \ < > ; / * % ? The name can include an ASCII space character except for the first and last character. All other space characters are not allowed.
Description Description of the role. The description cannot exceed 765 characters or include a tab, newline character, or the following special characters: < > "
4. Click the Privileges tab. 5. Expand the domain or an application service type. 6. Select the privileges to assign to the role for the domain or application service type. 7. Click OK.
Editing Properties for Custom Roles When you edit a custom role, you can change the description of the role. You cannot change the name of the role.
1. In the Administrator tool, click the Security tab. 2. In the Roles section of the Navigator, select a role. 3. Click Edit. 4. Change the description of the role and click OK.
Editing Privileges Assigned to Custom Roles You can change the privileges assigned to a custom role for the domain and for each application service type.
1. In the Administrator tool, click the Security tab. 2. In the Roles section of the Navigator, select a role. 3. Click the Privileges tab. 4. Click Edit. The Edit Roles and Privileges dialog box appears. 5. Expand the domain or an application service type. 6. To assign privileges to the role, select the privileges for the domain or application service type. 7. To remove privileges from the role, clear the privileges for the domain or application service type. 8. Repeat the steps to change the privileges for each service type. 9. Click OK.
Deleting Custom Roles When you delete a custom role, the custom role and all privileges that it included are removed from any user or group assigned the role.
To delete a custom role, right-click the role in the Roles section of the Navigator and select Delete Role. Confirm that you want to delete the role.
164 Chapter 9: Privileges and Roles Assigning Privileges and Roles to Users and Groups
You determine the actions that users can perform by assigning the following items to users and groups:
• Privileges. A privilege determines the actions that users can perform in application clients.
• Roles. A role is a collection of privileges. When you assign a role to a user or group, you assign the collection of privileges belonging to the role. Use the following rules and guidelines when you assign privileges and roles to users and groups:
• You assign privileges and roles to users and groups for the domain and for each application service that is running in the domain. You cannot assign privileges and roles to users and groups for a Metadata Manager Service or PowerCenter Repository Service in the following situations:
•The application service is disabled.
•The PowerCenter Repository Service is running in exclusive mode.
• You can assign different privileges and roles to a user or group for each application service of the same service type.
• A role can include privileges for the domain and multiple application service types. When you assign the role to a user or group for one application service, privileges for that application service type are assigned to the user or group. If you change the privileges or roles assigned to a user, the changed privileges or roles take effect the next time that the user logs in.
Note: You cannot edit the privileges or roles assigned to the default Administrator user account.
Inherited Privileges
A user or group can inherit privileges from the following objects:
• Group. When you assign privileges to a group, all subgroups and users belonging to the group inherit the privileges.
• Role. When you assign a role to a user, the user inherits the privileges belonging to the role. When you assign a role to a group, the group and all subgroups and users belonging to the group inherit the privileges belonging to the role. The subgroups and users do not inherit the role. You cannot revoke privileges inherited from a group or role. You can assign additional privileges to a user or group that are not inherited from a group or role.
The Privileges tab for a user or group displays all the roles and privileges assigned to the user or group for the domain and for each application service. Expand the domain or application service to view the roles and privileges assigned for the domain or service. Click the following items to display additional information about the assigned roles and privileges:
• Name of an assigned role. Displays the role details on the details panel.
• Information icon for an assigned role. Highlights all privileges inherited with that role. Privileges that are inherited from a role or group display an inheritance icon. The tooltip for an inherited privilege displays which role or group the user inherited the privilege from.
Assigning Privileges and Roles to a User or Group by Navigation
1. In the Administrator tool, click the Security tab.
Assigning Privileges and Roles to Users and Groups 165 2. In the Navigator, select a user or group. 3. Click the Privileges tab. 4. Click Edit. The Edit Roles and Privileges dialog box appears. 5. To assign roles, expand the domain or an application service on the Roles tab. 6. To grant roles, select the roles to assign to the user or group for the domain or application service. You can select any role that includes privileges for the selected domain or application service type. 7. To revoke roles, clear the roles assigned to the user or group. 8. Repeat steps 5 through 7 to assign roles for another service. 9. To assign privileges, click the Privileges tab. 10. Expand the domain or an application service. 11. To grant privileges, select the privileges to assign to the user or group for the domain or application service. 12. To revoke privileges, clear the privileges assigned to the user or group. You cannot revoke privileges inherited from a role or group. 13. Repeat steps 10 through 12 to assign privileges for another service. 14. Click OK.
Viewing Users with Privileges for a Service
You can view all users that have privileges for the domain or an application service.
1. In the Administrator tool, click the Security tab. 2. On the Security Actions menu, click Service User Privileges. The Services dialog box appears. 3. Select the domain or an application service. The details panel displays all users that have privileges for the domain or application service. 4. Right-click a user name and click Navigate to Item to navigate to the user.
Troubleshooting Privileges and Roles
I cannot assign privileges or roles to users for an existing Metadata Manager Service or PowerCenter Repository Service.
You cannot assign privileges and roles to users and groups for an existing Metadata Manager Service or PowerCenter Repository Service in the following situations:
• The application service is disabled.
• The PowerCenter Repository Service is running in exclusive mode.
166 Chapter 9: Privileges and Roles I removed a privilege from a group. Why do some users in the group still have that privilege?
You can use any of the following methods to assign privileges to a user:
• Assign a privilege directly to a user.
• Assign a role to a user.
• Assign a privilege or role to a group that the user belongs to.
If you remove a privilege from a group, users that belong to that group can be directly assigned the privilege or can inherit the privilege from an assigned role.
I am assigned all domain privileges and permission on all domain objects, but I cannot complete all tasks in the Administrator tool. Some of the Administrator tool tasks are determined by the Administrator role, not by privileges or permissions. You can be assigned all privileges for the domain and granted full permissions on all domain objects. However, you cannot complete the tasks determined by the Administrator role.
I am assigned the Administrator role for an application service, but I cannot configure the application service in the Administrator tool.
When you have the Administrator role for an application service, you are an application client administrator. An application client administrator has full permissions and privileges in an application client.
However, an application client administrator does not have permissions or privileges on the Informatica domain. An application client administrator cannot log in to the Administrator tool to manage the service for the application client for which it has administrator privileges.
To manage an application service in the Administrator tool, you must have the appropriate domain privileges and permissions.
I am assigned the Administrator role for the PowerCenter Repository Service, but I cannot use the Repository Manager to perform an advanced purge of objects or to create reusable metadata extensions.
You must have the Manage Services domain privilege and permission on the PowerCenter Repository Service in the Administrator tool to perform the following actions in the Repository Manager:
• Perform an advanced purge of object versions at the PowerCenter repository level.
• Create, edit, and delete reusable metadata extensions.
My privileges indicate that I should be able to edit objects in an application client, but I cannot edit any metadata. You might not have the required object permissions in the application client. Even if you have the privilege to perform certain actions, you may also require permission to perform the action on a particular object.
I cannot use pmrep to connect to a new PowerCenter Repository Service running in exclusive mode. The Service Manager might not have synchronized the list of users and groups in the PowerCenter repository with the list in the domain configuration database. To synchronize the list of users and groups, restart the PowerCenter Repository Service.
Troubleshooting Privileges and Roles 167 I am assigned all privileges in the Folders privilege group for the PowerCenter Repository Service and have read, write, and execute permission on a folder. However, I cannot configure the permissions for the folder.
Only the folder owner or a user assigned the Administrator role for the PowerCenter Repository Service can complete the following folder management tasks:
• Assign operating system profiles to folders if the PowerCenter Integration Service uses operating system profiles. Requires permission on the operating system profile.
• Change the folder owner.
• Configure folder permissions.
• Delete the folder.
• Designate the folder to be shared.
• Edit the folder name and description.
I am assigned the Administrator role for the Metadata Manager Service, but I cannot create or restore the Metadata Manager repository. To create or restore the Metadata Manager repository, you must be in the default Administrator group. Users in the default Administrator group have more privileges than users that are assigned the Administrator role for an application service.
I am assigned the Load Resources privilege for the Metadata Manager Service, but I get an "insufficient privileges" error when I try to load Business Glossary resources. To load Business Glossary resources, the Load Resource, Manage Resource, and View Model privileges are required. You also need write permission on any business glossary resource that you want to load.
168 Chapter 9: Privileges and Roles C h a p t e r 1 0
Permissions
This chapter includes the following topics:
• Permissions Overview, 169
• Domain Object Permissions, 171
• Connection Permissions, 175
• Cluster Configuration Permissions, 178
• Application and Application Object Permissions, 178
• SQL Data Service Permissions, 180
• Web Service Permissions, 184
Permissions Overview
You manage user security with privileges and permissions. Permissions define the level of access that users and groups have to an object.
Even if a user has the privilege to perform certain actions, the user may also require permission to perform the action on a particular object.
For example, a user has the Manage Services domain privilege and permission on the Development PowerCenter Repository Service, but not on the Production PowerCenter Repository Service. The user can edit or remove the Development PowerCenter Repository Service, but not the Production PowerCenter Repository Service. To manage an application service, a user must have the Manage Services domain privilege and permission on the application service.
You use different tools to configure permissions on the following objects:
Object Type Tool Description
Applications and Administrator tool You can assign permissions on applications and application objects application objects such as mappings and workflows.
Connection objects Administrator tool You can assign permissions on connections defined in the Analyst tool Administrator tool, Analyst tool, or Developer tool. These tools share the connection permissions. Developer tool
Domain objects Administrator tool You can assign permissions on the following domain objects: domain, folders, nodes, grids, licenses, application services, and operating system profiles.
169 Object Type Tool Description
Metadata Manager Metadata Manager You can assign permissions on Metadata Manager folders and catalog objects catalog objects.
Model repository Analyst tool You can assign permissions on projects defined in the Analyst tool projects Developer tool and Developer tool. These tools share project permissions.
PowerCenter repository PowerCenter Client You can assign permissions on PowerCenter folders, deployment objects groups, labels, queries, and connection objects.
SQL data service Administrator tool You can assign permissions on SQL data objects, such as SQL data objects services, virtual schemas, virtual tables, and virtual stored procedures.
Web service objects Administrator tool You can assign permissions on web services or web service operations.
Types of Permissions
Users and groups can have the following types of permissions in a domain:
Direct permissions Permissions that are assigned directly to a user or group. When users and groups have permission on an object, they can perform administrative tasks on that object if they also have the appropriate privilege. You can edit direct permissions. Inherited permissions
Permissions that users inherit. When users have permission on a domain or a folder, they inherit permission on all objects in the domain or the folder. When groups have permission on a domain object, all subgroups and users belonging to the group inherit permission on the domain object. For example, a domain has a folder named Nodes that contains multiple nodes. If you assign a group permission on the folder, all subgroups and users belonging to the group inherit permission on the folder and on all nodes in the folder.
You cannot revoke inherited permissions. You also cannot revoke permissions from users or groups assigned the Administrator role. The Administrator role bypasses permission checking. Users with the Administrator role can access all objects.
You can deny inherited permissions on some object types. When you deny permissions, you configure exceptions to the permissions that users and groups might already have.
Effective permissions Superset of all permissions for a user or group. Includes direct permissions and inherited permissions. When you view permission details, you can view the origin of effective permissions. Permission details display direct permissions assigned to the user or group, direct permissions assigned to parent groups, and permissions inherited from parent objects. In addition, permission details display whether the user or group is assigned the Administrator role which bypasses permission checking.
170 Chapter 10: Permissions Permission Search Filters
When you assign permissions, view permission details, or edit permissions for a user or group, you can use search filters to search for a user or group.
When you manage permissions for a user or group, you can use the following search filters:
Security domain Select the security domain to search for users or groups. Pattern string Enter a string to search for users or groups. The Administrator tool returns all names that contain the search string. The string is not case sensitive. For example, the string "DA" can return "iasdaemon," "daph ne," and "DA_AdminGroup." You can also sort the list of users or groups. Right-click a column name to sort the column in ascending or descending order.
Domain Object Permissions
You configure privileges and permissions to manage user security within the domain. Permissions define the level of access a user has to a domain object. To log in to the Administrator tool, a user must have permission on at least one domain object. If a user has permission on an object, but does not have the domain privilege that grants the ability to modify the object type, then the user can only view the object.
For example, if a user has permission on a node, but does not have the Manage Nodes and Grids privilege, the user can view the node properties, but cannot configure, shut down, or remove the node.
You can configure permissions on the following types of domain objects:
Domain Object Description of Permission Type
Domain Enables Administrator tool users to access all objects in the domain. When users have permission on a domain, they inherit permission on all objects in the domain.
Folder Enables Administrator tool users to access all objects in the folder in the Administrator tool. When users have permission on a folder, they inherit permission on all objects in the folder.
Node Enables Administrator tool users to view and edit the node properties. Without permission, a user cannot use the node when defining an application service or creating a grid.
Grid Enables Administrator tool users to view and edit the grid properties. Without permission, a user cannot assign the grid to a Data Integration Service or PowerCenter Integration Service.
License Enables Administrator tool users to view and edit the license properties. Without permission, a user cannot use the license when creating an application service.
Domain Object Permissions 171 Domain Object Description of Permission Type
Application Enables Administrator tool users to view and edit the application service properties. Service
Operating Enables Informatica developers, analysts, and operators associated with the operating system System Profile profile to run mappings, profiles, and workflows. Enables PowerCenter users to run workflows associated with the operating system profile. If the user that runs a workflow does not have permission on the operating system profile assigned to the workflow, the workflow fails.
You can use the following methods to manage domain object permissions:
• Manage permissions by domain object. Use the Permissions view of a domain object to assign and edit permissions on the object for multiple users or groups.
• Manage permissions by user or group. Use the Manage Permissions dialog box to assign and edit permissions on domain objects for a specific user or group.
Note: You configure permissions on an operating system profile differently than you configure permissions on other domain objects.
Permissions by Domain Object
Use the Permissions view of a domain object to assign, view, and edit permissions on the domain object for multiple users or groups.
Assigning Permissions on a Domain Object When you assign permissions on a domain object, you grant users and groups access to the object.
1. On the Manage tab, select the Services and Nodes view. 2. In the Navigator, select the domain object. 3. In the contents panel, select the Permissions view. 4. Click the Groups or Users tab. 5. Click Actions > Assign Permission. The Assign Permissions dialog box displays all users or groups that do not have permission on the object. 6. Enter the filter conditions to search for users and groups, and click the Filter button. 7. Select a user or group, and click Next. 8. Select Allow, and click Finish.
Viewing Permission Details on a Domain Object When you view permission details, you can view the origin of effective permissions.
1. On the Manage tab, select the Services and Nodes view. 2. In the Navigator, select the domain object. 3. In the contents panel, select the Permissions view. 4. Click the Groups or Users tab.
172 Chapter 10: Permissions 5. Enter the filter conditions to search for users and groups, and click the Filter button. 6. Select a user or group and click Actions > View Permission Details. The Permission Details dialog box appears. The dialog box displays direct permissions assigned to the user or group, direct permissions assigned to parent groups, and permissions inherited from parent objects. In addition, permission details display whether the user or group is assigned the Administrator role which bypasses permission checking. 7. Click Close. 8. Or, click Edit Permissions to edit direct permissions.
Editing Permissions on a Domain Object You can edit direct permissions on a domain object for a user or group. You cannot revoke inherited permissions or your own permissions.
Note: If you revoke direct permission on an object, the user or group might still inherit permission from a parent group or object.
1. On the Manage tab, select the Services and Nodes view. 2. In the Navigator, select the domain object. 3. In the contents panel, select the Permissions view. 4. Click the Groups or Users tab. 5. Enter the filter conditions to search for users and groups, and click the Filter button. 6. Select a user or group and click Actions > Edit Direct Permissions. The Edit Direct Permissions dialog box appears. 7. To assign permission on the object, select Allow. 8. To revoke permission on the object, select Revoke. You can view whether the permission is directly assigned or inherited by clicking View Permission Details. 9. Click OK.
Permissions by User or Group
Use the Manage Permissions dialog box to view, assign, and edit domain object permissions for a specific user or group.
Viewing Permission Details for a User or Group When you view permission details, you can view the origin of effective permissions.
1. In the Administrator tool, click the Security tab. 2. Click the Groups tab or the Users tab. 3. Select a user or group. 4. Click the Permissions tab.
Domain Object Permissions 173 Assigning and Editing Permissions for a User or Group When you edit domain object permissions for a user or group, you can assign permissions and edit existing direct permissions. You cannot revoke inherited permissions or your own permissions.
You can view whether the permission is directly assigned or inherited by clicking View Permission Details. If you revoke a permission on the object, the user or group might still inherit the permission from a parent group or object.
1. In the Administrator tool, click the Security tab. 2. Click the Groups tab or the Users tab. 3. Select a user or group. 4. Click the Permissions tab. 5. Select a domain object, and then click Edit Direct Permissions. 6. To assign a permission on the object, select Allow. 7. To revoke permission on the object, select Revoke.
8. Click OK.
Operating System Profile Permissions
Assign, view, and edit permissions on operating system profiles in the Security page of the Administrator tool.
The Administrator group has permissions on all operating system profiles.
Assigning Permissions on an Operating System Profile When you assign permissions on an operating system profile, Informatica users run mappings, profiles, and workflows with the operating system profile. PowerCenter users run workflows assigned to the operating system profile.
1. In the Administrator tool, click the Security tab. 2. Click the Operating System Profiles tab. 3. Select an operating system profile, and then click the Permissions tab. 4. Click the Groups tab or the Users tab, and then select Edit Direct Permissions. 5. Select a domain object, and then click Edit Direct Permissions. 6. To assign a permission on the object, select Allow. 7. To revoke permission on the object, select Revoke.
8. Click OK.
Viewing Permission Details on an Operating System Profile When you view permission details, you can view the origin of effective permissions.
1. On the Security tab, select the Operating System Profiles view. 2. Select the operating system profile, and click the Permissions tab. 3. Select the Groups or Users view. 4. Enter the filter conditions to search for users and groups, and click the Filter button. 5. Select a user or group and click View Permission Details.
174 Chapter 10: Permissions The Permission Details dialog box appears. The dialog box displays direct permissions assigned to the user or group, direct permissions assigned to parent groups, and permissions inherited from parent objects. In addition, permission details display whether the user or group is assigned the Administrator role which bypasses permission checking. 6. Click Close. 7. Or, click Edit Permissions to edit direct permissions.
Editing Permissions on an Operating System Profile You can edit direct permissions on an operating system profile for a user or group. You cannot revoke inherited permissions or your own permissions.
Note: If you revoke direct permission on an object, the user or group might still inherit permission from a parent group or object.
1. On the Security tab, select the Operating System Profiles view. 2. Select the operating system profile, and click the Permissions tab. 3. Select the Groups or Users view. 4. Enter the filter conditions to search for users and groups, and click the Filter button. 5. Select a user or group and click Edit Direct Permissions. The Edit Direct Permissions dialog box appears. 6. To assign permission on the operating system profile, select Allow. 7. To revoke permission on the operating system profile, select Revoke. You can view whether the permission is directly assigned or inherited by clicking View Permission Details. 8. Click OK.
Connection Permissions
Permissions control the level of access that a user or group has on the connection.
You can configure permissions on a connection in the Analyst tool, Developer tool, or Administrator tool.
Any connection permission that is assigned to a user or group in one tool also applies in other tools. For example, you grant GroupA permission on ConnectionA in the Developer tool. GroupA has permission on ConnectionA in the Analyst tool and Administrator tool also.
Any connection permission that is assigned to a user or group in one tool also applies in other tools. For example, you grant GroupA permission on ConnectionA in the Developer tool. GroupA has permission on ConnectionA in the Administrator tool also.
The following Informatica components use the connection permissions:
• Administrator tool. Enforces read, write, and execute permissions on connections.
• Analyst tool. Enforces read, write, and execute permissions on connections.
• Informatica command line interface. Enforces read, write, and grant permissions on connections.
• Developer tool. Enforces read, write, and execute permissions on connections.
Connection Permissions 175 For SQL data services, the Developer tool does not enforce connection permissions. Instead, it enforces column-level and pass-through security to restrict access to data.
• Data Integration Service. Enforces execute permissions when a user tries to preview data or run a mapping, scorecard, or profile.
Note: You cannot assign permissions on the following connections: profiling warehouse, data object cache database, or Model repository.
Types of Connection Permissions
You can assign different permission types to users to perform the following actions:
Action Permission Types
View all connection metadata, except passwords, such as connection name, type, description, Read connection strings, and user names.
Edit all connection metadata, including passwords. Delete the connection. Users with Write Write permission inherit Read permission.
Access the physical data in the underlying data source defined by the connection. Users can Execute preview data, run a mapping, run a mapping in a workflow Mapping task, run a scorecard, or run a profile that uses the connection.
Grant and revoke permissions on connections. Grant
Default Connection Permissions
The domain administrator has all permissions on all connections. The user that creates a connection has read, write, execute, and grant permission on the connection. By default, all users have permission to perform the following actions on connections:
• View basic connection metadata, such as connection name, type, and description.
• Use the connection in mappings in the Developer tool.
• Create profiles in the Analyst tool on objects in the connection.
Assigning Permissions on a Connection
When you assign permissions on a connection, you define the level of access a user or group has to the connection.
1. On the Manage tab, select the Connections view. 2. In the Navigator, select the connection. 3. In the contents panel, select the Permissions view. 4. Click the Groups or Users tab. 5. Click Actions > Assign Permission. The Assign Permissions dialog box displays all users or groups that do not have permission on the connection. 6. Enter the filter conditions to search for users and groups, and click the Filter button.
176 Chapter 10: Permissions 7. Select a user or group, and click Next. 8. Select Allow for each permission type that you want to assign. 9. Click Finish.
Viewing Permission Details on a Connection
When you view permission details, you can view the origin of effective permissions.
1. On the Manage tab, select the Connections view. 2. In the Navigator, select the connection. 3. In the contents panel, select the Permissions view. 4. Click the Groups or Users tab. 5. Select a user or group and click Actions > View Permission Details. The View Permission Details dialog box appears. The dialog box displays direct permissions assigned to the user or group and direct permissions assigned to parent groups. In addition, permission details display whether the user or group is assigned the Administrator role which bypasses the permission check. 6. Click Close. 7. Or, click Edit Permissions to edit direct permissions.
Editing Permissions on a Connection
You can edit direct permissions on a connection for a user or group. You cannot revoke inherited permissions or your own permissions.
Note: If you revoke direct permission on an object, the user or group might still inherit permission from a parent group or object.
1. On the Manage tab, select the Connections view. 2. In the Navigator, select the connection. 3. In the contents panel, select the Permissions view. 4. Click the Groups or Users tab. 5. Enter the filter conditions to search for users and groups, and click the Filter button. 6. Select a user or group and click Actions > Edit Direct Permissions. The Edit Direct Permissions dialog box appears. 7. Choose to allow or revoke permissions.
• Select Allow to assign a permission.
• Clear Allow to revoke a single permission.
• Select Revoke to revoke all permissions. You can view whether the permission is directly assigned or inherited by clicking View Permission Details. 8. Click OK.
Connection Permissions 177 Cluster Configuration Permissions
Permissions control the level of access that a user or group has on a cluster configuration.
You can configure permissions on a cluster configuration in the Administrator tool and the Informatica command line interface.
A user or group can have the following permissions on a cluster configuration:
• Read. The user or group members can view the cluster configuration.
• Write. The user or group members can edit the cluster configuration. Includes read permission.
• Execute. The user or group members can run mappings in the Hadoop environment.
• Grant. The user or group members can grant permission on the cluster configuration to other users and groups. Includes read permission.
• All. The user inherits all allowed permissions. By default, all users have permission to view the cluster configuration name.
Application and Application Object Permissions
Permissions control the level of access that a user or group has on applications and application objects such as mappings and workflows.
You can configure application and application object permissions in the Administrator tool or from the command line.
Types of Application and Application Object Permissions
You can assign view, grant, and execute permissions to users and groups.
You can assign the following permissions to users and groups:
View permission View applications and application objects. Grant permission Grant and revoke permissions on the applications and application objects. Execute permission Run applications and application objects.
Note: To perform application operations such as start, stop, or back up in the Administrator tool or from the command line, the user must have execute permission and the Manage Applications privilege on the application.
Assigning Permissions on an Application or Application Object
When you assign permissions on an application or application object, you define the level of access a user or group has to the application or the application object.
1. On the Manage tab, select the Services and Nodes view. 2. In the Navigator, select a Data Integration Service.
178 Chapter 10: Permissions 3. In the contents panel, select the Applications view. 4. Select an application, a mapping, or a workflow. 5. In the details panel, select the Group Permissions or User Permissions view. 6. Click the Assign Permission button. The Assign Permissions dialog box displays all users or groups that do not have permission on the application or application object. 7. Enter the filter conditions to search for users and groups, and click the Filter button. 8. Select a user or group, and click Next. 9. Select Allow for each permission type that you want to assign. 10. Click Finish.
Viewing Permission Details on an Application or Application Object
When you view permission details, you can view the origin of effective permissions.
1. On the Manage tab, select the Services and Nodes view. 2. In the Navigator, select a Data Integration Service. 3. In the contents panel, select the Applications view. 4. Select the application, mapping, or workflow. 5. In the details panel, select the Group Permissions or User Permissions view. 6. Enter the filter conditions to search for users and groups, and click the Filter button. 7. Select a user or group and click the View Permission Details button. The Permission Details dialog box appears. The dialog box displays direct permissions assigned to the user or group, direct permissions assigned to parent groups, and permissions inherited from parent objects. In addition, permission details display whether the user or group is assigned the Administrator role which bypasses permission checking. 8. Click Close. 9. Or, click Edit Permissions to edit direct permissions.
Editing Permissions on an Application or Application Object
You can edit direct permissions on an application or application object for a user or group. You cannot revoke inherited permissions or your own permissions.
Note: If you revoke direct permission on an object, the user or group might still inherit permission from a parent group or object.
1. On the Manage tab, select the Services and Nodes view. 2. In the Navigator, select a Data Integration Service. 3. In the contents panel, select the Applications view. 4. Select the application or application object. 5. In the details panel, select the Group Permissions or User Permissions view. 6. Enter the filter conditions to search for users and groups, and click the Filter button. 7. Select a user or group and click the Edit Direct Permissions button. The Edit Direct Permissions dialog box appears.
Application and Application Object Permissions 179 8. Choose to allow or revoke permissions.
• Select Allow to assign a permission.
• Clear Allow to revoke a single permission.
• Select Revoke to revoke all permissions. You can view whether the permission is directly assigned or inherited by clicking View Permission Details. 9. Click OK.
Denying Permissions on an Application or Application Object
You can explicitly deny permissions on application and application objects. When you deny a permission, you are applying an exception to the effective permission.
SQL Data Service Permissions
End users can connect to an SQL data service through a JDBC or ODBC client tool. After connecting, users can run SQL queries against virtual tables in an SQL data service, or users can run a virtual stored procedure in an SQL data service. Permissions control the level of access that a user has to an SQL data service.
You can assign permissions to users and groups on the following SQL data service objects:
• SQL data service
• Virtual table
• Virtual stored procedure When you assign permissions on an SQL data service object, the user or group inherits the same permissions on all objects that belong to the SQL data service object. For example, you assign a user select permission on an SQL data service. The user inherits select permission on all virtual tables in the SQL data service.
You can deny permissions to users and groups on some SQL data service objects. When you deny permissions, you configure exceptions to the permissions that users and groups might already have. For example, you cannot assign permissions to a column in a virtual table, but you can deny a user from running an SQL SELECT statement that includes the column.
Types of SQL Data Service Permissions
You can assign the following permissions to users and groups:
• Grant permission. Users can grant and revoke permissions on the SQL data service objects using the Administrator tool or using the infacmd command line program.
• Execute permission. Users can run virtual stored procedures in the SQL data service using a JDBC or ODBC client tool.
• Select permission. Users can run SQL SELECT statements on virtual tables in the SQL data service using a JDBC or ODBC client tool. Some permissions are not applicable for all SQL data service objects.
180 Chapter 10: Permissions The following table describes the permissions for each SQL data service object:
Object Grant Permission Execute Permission Select Permission
SQL data Grant and revoke permission on the Run all virtual stored Run SQL SELECT statements service SQL data service and all objects procedures in the SQL on all virtual tables in the within the SQL data service. data service. SQL data service.
Virtual table Grant and revoke permission on the - Run SQL SELECT statements virtual table. on the virtual table.
Virtual stored Grant and revoke permission on the Run the virtual stored - procedure virtual stored procedure. procedure.
Assigning Permissions on an SQL Data Service
When you assign permissions on an SQL data service object, you define the level of access a user or group has to the object.
1. On the Manage tab, select the Services and Nodes view. 2. In the Navigator, select a Data Integration Service. 3. In the contents panel, select the Applications view. 4. Select the SQL data service object. 5. In the details panel, select the Group Permissions or User Permissions view. 6. Click the Assign Permission button. The Assign Permissions dialog box displays all users or groups that do not have permission on the SQL data service object. 7. Enter the filter conditions to search for users and groups, and click the Filter button. 8. Select a user or group, and click Next. 9. Select Allow for each permission type that you want to assign. 10. Click Finish.
Viewing Permission Details on an SQL Data Service
When you view permission details, you can view the origin of effective permissions.
1. On the Manage tab, select the Services and Nodes view. 2. In the Navigator, select a Data Integration Service. 3. In the contents panel, select the Applications view. 4. Select the SQL data service object. 5. In the details panel, select the Group Permissions or User Permissions view. 6. Enter the filter conditions to search for users and groups, and click the Filter button. 7. Select a user or group and click the View Permission Details button. The Permission Details dialog box appears. The dialog box displays direct permissions assigned to the user or group, direct permissions assigned to parent groups, and permissions inherited from parent objects. In addition, permission details display whether the user or group is assigned the Administrator role which bypasses permission checking. 8. Click Close.
SQL Data Service Permissions 181 9. Or, click Edit Permissions to edit direct permissions.
Editing Permissions on an SQL Data Service
You can edit direct permissions on an SQL data service for a user or group. You cannot revoke inherited permissions or your own permissions.
Note: If you revoke direct permission on an object, the user or group might still inherit permission from a parent group or object.
1. On the Manage tab, select the Services and Nodes view. 2. In the Navigator, select a Data Integration Service. 3. In the contents panel, select the Applications view. 4. Select the SQL data service object. 5. In the details panel, select the Group Permissions or User Permissions view. 6. Enter the filter conditions to search for users and groups, and click the Filter button. 7. Select a user or group and click the Edit Direct Permissions button. The Edit Direct Permissions dialog box appears. 8. Choose to allow or revoke permissions.
• Select Allow to assign a permission.
• Clear Allow to revoke a single permission.
• Select Revoke to revoke all permissions. You can view whether the permission is directly assigned or inherited by clicking View Permission Details. 9. Click OK.
Denying Permissions on an SQL Data Service
You can explicitly deny permissions on some SQL data service objects. When you deny a permission on an object in an SQL data service, you are applying an exception to the effective permission.
To deny permissions use one of the following infacmd commands:
• infacmd sql SetStoredProcedurePermissions. Denies Execute or Grant permissions at the stored procedure level.
• infacmd sql SetTablePermissions. Denies Select and Grant permissions at the virtual table level.
• infacmd sql SetColumnPermissions. Denies Select permission at the column level. Each command has options to apply permissions (-ap) and deny permissions (-dp). The SetColumnPermissions command does not include the apply permissions option.
Note: You cannot deny permissions from the Administrator tool.
The Data Integration Service verifies permissions before running SQL queries and stored procedures against the virtual database. The Data Integration Service validates the permissions for users or groups starting at the SQL data service level. When permissions apply to a parent object in an SQL data service, the child objects inherit the permission. The Data Integration Service checks for denied permissions at the column level.
182 Chapter 10: Permissions Column Level Security
An administrator can deny access to columns in a virtual table of an SQL data object. The administrator can configure the Data Integration Service behavior for queries against a restricted column.
The following results might occur when the user queries a column that the user does not have permissions for:
• The query returns a substitute value instead of the data. The query returns a substitute value in each row that it returns. The substitute value replaces the column value through the query. If the query includes filters or joins, the results substitute appears in the results.
• The query fails with an insufficient permission error.
For more information about configuring security for SQL data services, see the Informatica How-To Library article "How to Configure Security for SQL Data Services": https://kb.informatica.com/h2l/HowTo%20Library/1/0266_ConfiguringSecurityForSQLDataServices.pdf.
Restricted Columns When you configure column level security, set a column option that determines what happens when a user selects the restricted column in a query. You can substitute the restricted data with a default value. Or, you can fail the query if a user selects the restricted column.
For example, an Administrator denies a user access to the salary column in the Employee table. The Administrator configures a substitute value of 100,000 for the salary column. When the user selects the salary column in an SQL query, the Data Integration Service returns 100,000 for the salary in each row.
Run the infacmd sql UpdateColumnOptions command to configure the column options. You cannot set column options in the Administrator tool.
When you run infacmd sql UpdateColumnOptions, enter the following options:
ColumnOptions.DenyWith=option Determines whether to substitute the restricted column value or to fail the query. If you substitute the column value, you can choose to substitute the value with NULL or with a constant value. Enter one of the following options:
• ERROR. Fails the query and returns an error when an SQL query selects a restricted column.
• NULL. Returns null values for a restricted column in each row.
• VALUE. Returns a constant value in place of the restricted column in each row. Configure the constant value in the ColumnOptions.InsufficientPermissionValue option. ColumnOptions.InsufficientPermissionValue=value Substitutes the restricted column value with a constant. The default is an empty string. If the Data Integration Service substitutes the column with an empty string, but the column is a number or a date, the query returns errors. If you do not configure a value for the DenyWith option, the Data Integration Service ignores the InsufficientPermissionValue option. To configure a substitute value for a column, enter the command with the following syntax: infacmd sql UpdateColumnOptions -dn empDomain -sn DISService -un Administrator -pd Adminpass -sqlds employee_APP.employees_SQL -t Employee -c Salary -o ColumnOptions.DenyWith=VALUE ColumnOptions.InsufficientPermissionValue=100000 If you do not configure either option for a restricted column, default is not to fail the query. The query runs and the Data Integration Service substitutes the column value with NULL.
SQL Data Service Permissions 183 Adding Column Level Security Configure column level security with the infacmd sql SetColumnPermissions command. You cannot set column level security from the Administrator tool.
An Employee table contains FirstName, LastName, Dept, and Salary columns. You enable a user to access the Employee table but restrict the user from accessing the salary column.
To restrict the user from the salary column, disable the Data Integration Service and enter an infacmd similar to the following command: infacmd sql SetColumnPermissions -dn empDomain -sn DISService -un Administrator -pd Adminpass -sqlds employee_APP.employees -t Employee -c Salary gun -Tom -dp SQL_Select The following SQL statements return NULL in the salary column: Select * from Employee Select LastName, Salary from Employee The default behavior is to return null values.
Web Service Permissions
End users can send web service requests and receive web service responses through a web service client. Permissions control the level of access that a user has to a web service.
You can assign permissions to users and groups on the following web service objects:
• Web service
• REST web service resource
• SOAP web service operation
When you assign permissions on a web service object, the user or group inherits the same permissions on all objects that belong to the web service object. For example, you assign a user execute permission on a web service. The user inherits execute permission on web service operations in the web service.
You can deny permissions to users and groups on a web service operation. When you deny permissions, you configure exceptions to the permissions that users and groups might already have. For example, a user has execute permissions on a web service which has three operations. You can deny a user from running one web service operation that belongs to the web service.
Types of Web Service Permissions
An administrator assigns web service permissions to the following types of users and groups:
• Web service consumer. A native domain user that sends a request to the web service and receives a response from the web service. The user must have execute permission on the web service.
• Web service administrator. A user that can log into the Administrator, edit the web service properties, and grant permissions to other users.
• Web service operator. A user that can log into the Administrator, monitor a web service, and start or stop a web service.
184 Chapter 10: Permissions An administrator can assign the following permissions to users and groups:
• Grant permission. Users can manage permissions on the web service objects using the Administrator tool or using the infacmd command line program.
• Execute permission. Users can send web service requests and receive web service responses.
The following table describes the permissions for each SOAP web service object:
Object Grant Permission Execute Permission
SOAP Web Grant and revoke permission on the web Send web service requests and receive web service service and all web service operations service responses from all web service within the web service. operations within the web service.
SOAP Web Grant, revoke, and deny permission on the Send web service requests and receive web service operation web service operation. service responses from the web service operation.
The following table describes the permissions for each REST web service object:
Object Grant Permission Execute Permission
REST web Grant and revoke permission on the REST Send web service requests and receive web service service web service and all web service resources responses from all web service resources in the within the web service. REST web service.
REST resource Grant, revoke, and deny permission the REST Send web service requests and receive web service web service resource. responses from the REST web service resource.
Assigning Permissions on a Web Service
When you assign permissions on a web service object, you define the level of access a user or group has to the object.
1. On the Manage tab, select the Services and Nodes view. 2. In the Navigator, select a Data Integration Service. 3. In the contents panel, select the Applications view. 4. Select the web service object. 5. In the details panel, select the Group Permissions or User Permissions view. 6. Click the Assign Permission button. The Assign Permissions dialog box displays all users or groups that do not have permission on the SQL data service object. 7. Enter the filter conditions to search for users and groups, and click the Filter button. 8. Select a user or group, and click Next. 9. Select Allow for each permission type that you want to assign. 10. Click Finish.
Web Service Permissions 185 Viewing Permission Details on a Web Service
When you view permission details, you can view the origin of effective permissions.
1. On the Manage tab, select the Services and Nodes view. 2. In the Navigator, select a Data Integration Service. 3. In the contents panel, select the Applications view. 4. Select the web service object. 5. In the details panel, select the Group Permissions or User Permissions view. 6. Enter the filter conditions to search for users and groups, and click the Filter button. 7. Select a user or group and click the View Permission Details button. The Permission Details dialog box appears. The dialog box displays direct permissions assigned to the user or group, direct permissions assigned to parent groups, and permissions inherited from parent objects. In addition, permission details display whether the user or group is assigned the Administrator role which bypasses permission checking. 8. Click Close. 9. Or, click Edit Permissions to edit direct permissions.
Editing Permissions on a Web Service
You can edit direct permissions on a web service for a user or group. When you edit permissions on a web service object, you can deny permissions on the object. You cannot revoke inherited permissions or your own permissions.
Note: If you revoke direct permission on an object, the user or group might still inherit permission from a parent group or object.
1. On the Manage tab, select the Services and Nodes view. 2. In the Navigator, select a Data Integration Service. 3. In the contents panel, select the Applications view. 4. Select the web service object. 5. In the details panel, select the Group Permissions or User Permissionsview. 6. Enter the filter conditions to search for users and groups, and click the Filter button. 7. Select a user or group and click the Edit Direct Permissions button. The Edit Direct Permissions dialog box appears. 8. Choose to allow or revoke permissions.
• Select Allow to assign a permission.
• Select Deny to deny a permission on a web service object.
• Clear Allow to revoke a single permission.
• Select Revoke to revoke all permissions. You can view whether the permission is directly assigned or inherited by clicking View Permission Details. 9. Click OK.
186 Chapter 10: Permissions C h a p t e r 1 1
Audit Reports
This chapter includes the following topics:
• Audit Reports Overview, 187
• User Personal Information, 188
• User Group Association, 188
• Privileges, 189
• Roles Association, 190
• Domain Object Permission, 190
• Selecting Users for an Audit Report, 191
• Selecting Groups for an Audit Report , 191
• Selecting Roles for an Audit Report, 192
Audit Reports Overview
Use the audit reports to view information about users and groups in the Informatica domain and the privileges and permissions assigned to them.
You can generate the following audit reports: User Personal Information Displays information about the user accounts in the domain, including the user status. You can select the users or groups for which you want to generate the report. User Group Association Displays information about users and the groups to which they belong. You can select the users or groups for which you want to generate the report. Privileges Displays information about privileges assigned to the users and groups in the domain. You can select the users or groups for which you want to generate the report. Roles Displays information about the roles assigned the users and groups in the domain. You can select the roles for which you want to generate the report. Domain Object Permissions Displays information about the domain objects for which users and groups have permission. You can select the users or groups for which you want to generate the report.
187 You can generate the audit reports in different formats, including CSV, text, or PDF files. You can also view the report on the screen.
You can generate the audit reports from the Administrator tool or from the command line. To run the audit reports from the command line, run the infacmd aud command line program.
User Personal Information
The User Personal Information report displays the contact information and status of user accounts in the domain.
If you run the report for groups, the report organizes the list of users by group and displays the group name and security domain for each group. The report displays nested groups separately.
The User Personal Information report displays the following information: Login Name Login name for the user account. Full Name Full name for the user account. Security Domain Security domain to which the user belongs. Description Description of the user account. Email ID Email address for the user account. Phone Telephone number for the user account. Account Locked Indicates whether the account is locked or not. The report displays Yes if the account is locked and No if the account is not locked. Account Disabled Indicates whether the account is disabled or not. The report displays Yes if the account is disabled and No if the account is enabled.
User Group Association
The User Group Association report displays information about users and their associated groups.
If you run the report for users, the report displays the list of users and the groups to which they belong.
The User Group Association report displays the following information: Login Name Login name for the user account.
188 Chapter 11: Audit Reports Full Name Full name for the user account. Security Domain Security domain to which the user account belongs. Group Name Name of the group to which the user belongs. Group Path If the group is a single group, the group path shows the group name. If the group is a nested group, the group path shows position of the group within the hierarchy of the nested groups. Group Security Domain Security domain for the group to which the user belongs.
If you run the report for groups, the report organizes the list of users by group and displays the group name and security domain for each group. The report displays nested groups separately. For each group, the report shows the list of users and child groups that belong to the group.
The User Group Association report displays the following information for the users that belong to the group: Login Name Login name for the user account. Full Name Full name for the user account. Security Domain Security domain to which the user account belongs.
The User Group Association report displays the following information for the child groups that belong to the group: Group Name Name of the group. Security Domain Security domain to which the group belongs. Group Path If the group is a single group, the group path shows the group name. If the group is a nested group, the group path shows position of the group within the hierarchy of the nested groups.
Privileges
The Privileges report displays the users and groups and the privileges assigned to the users and groups.
If you run the report for users, the report shows the list of users and the privileges assigned to each user. If you run the report for groups, the report shows the list of groups and the privileges assigned to each group.
The Privileges report displays the following information: Privilege Name Name of the privilege.
Privileges 189 Privilege Path The hierarchy of the privilege group that contains the privilege. Object Name Name of the object on which the privilege is allowed. Object Type Type of the object on which the privilege is allowed.
Roles Association
The Roles Association report displays a list of roles and the users and groups to which the roles are assigned.
The Roles Association report displays the following information: Login Name Login name for the user account to which the role is assigned. Displays for the list of users. Full Name Full name for the user account to which the role is assigned. Displays for the list of users. Group Name Name of the group to which the role is assigned. Displays for the list of groups. Security Domain Security domain to which the user or group belongs. Object Name Name of the object on which the set of privileges in the role are allowed. Object Type Type of the object on which the set of privileges in the role are allowed.
Domain Object Permission
The Domain Object Permission report displays the users and groups and the objects to which the users and groups have permission.
If you run the report for users, the report shows the list of users and the objects to which the users have permissions. If you run the report for groups, the report shows the list of groups and the objects to which the groups have permissions.
The Domain Object Permission report displays the following information: Object Name Name of the object to which the user or group has permission. Object Type Type of the object to which the user or group has permission.
190 Chapter 11: Audit Reports Object Path Location of the object in the repository.
Selecting Users for an Audit Report
You can generate an audit report for multiple users.
1. In the Administrator tool, click Security > Audit Reports. 2. From the Select Report Type list, select the type of audit report that you want to run. 3. From the Generate Report For list, select Users and click Go. The Select Users dialog box appears. By default, the Users icon is selected and the list of all available users display. The list shows the full name of the user and the security domain to which the user belongs. 4. From the Available Users list, select the users for which you want to run the report. Use the Shift key or Ctrl key to select multiple users. 5. To select users by group, click the Groups icon. The Available Groups list displays all groups in the domain and the Members list displays the users who are members of the groups. From the Members list, select the users for which you want to run the report. You can select users from multiple groups. 6. Click Add. To run the report for all users, click the Users icon and then click Add All without selecting a user. To run the report for all users in a group, click the Groups icon. Select a group and click Add All without selecting a user from the Members list. The selected users move to the Selected Users list. 7. From the Report Output Format list, select the format in which you want to view the report. By default, the report displays on the screen. You can also view an audit report in one of the following formats:
• Text. Generates the audit report as a text file with values listed in columns.
• CSV. Generates the audit report as a text file with values separated by commas.
• PDF. Generates the audit report in .pdf format. You must install Acrobat Reader to view the report. 8. Click Generate Report.
Selecting Groups for an Audit Report
You can run audit reports for multiple groups.
1. In the Administrator tool, click Security > Audit Reports. 2. From the Select Report Type list, select the type of audit report that you want to run. 3. From the Generate Report For list, select Groups and click Go. The Select Groups dialog box appears. The list of groups are organized by security domain.
Selecting Users for an Audit Report 191 4. From the Available Groups list, select the groups for which you want to run the report. Use the Shift key or Ctrl key to select multiple groups. 5. Click Add. To run the report for all groups, do not select a group and click Add All. The selected groups move to the Selected Groups list. 6. From the Report Output Format list, select the format in which you want to view the report. By default, the reports displays on the screen. You can also run an audit report in one of the following formats:
• Text. Generates the audit report as a text file with values listed in columns.
• CSV. Generates the audit report as a text file with values separated by commas.
• PDF. Generates the audit report in .pdf format. You must install Acrobat Reader to view the report. 7. Click Generate Report.
Selecting Roles for an Audit Report
When you run the Roles Association report, you must select the roles for which you want to run the report.
1. In the Administrator tool, click Security > Audit Reports. 2. From the Select Report Type list, select the Roles Association report. 3. From the Generate Report For list, select Roles and click Go. The Select Roles dialog box appears. The list of system-defined roles display separately from the list of custom roles. 4. From the Available Roles list, select the roles for which you want to run the report. Use the Shift key or Ctrl key to select multiple roles. 5. Click Add. To run the report for all roles, do not select a role and click Add All. The selected roles move to the Selected Roles list. 6. From the Report Output Format list, select the format in which you want to view the report. By default, the reports displays on the screen. You can also run an audit report in one of the following formats:
• Text. Generates the audit report as a text file with values listed in columns.
• CSV. Generates the audit report as a text file with values separated by commas.
• PDF. Generates the audit report in .pdf format. You must install Acrobat Reader to view the report. 7. Click Generate Report.
192 Chapter 11: Audit Reports A p p e n d i x A
Command Line Privileges and Permissions
This appendix includes the following topics:
• infacmd as Commands, 193
• infacmd cluster Commands, 194
• infacmd dis Commands, 195
• infacmd dp Commands, 196
• infacmd es commands, 196
• infacmd ipc Commands, 197
• infacmd isp Commands, 197
• infacmd mas Commands, 206
• infacmd mrs Commands, 207
• infacmd ms Commands, 209
• infacmd tools Commands, 209
• infacmd ps Commands, 210
• infacmd pwx Commands, 210
• infacmd rms Commands, 211
• infacmd rtm Commands, 212
• infacmd sch commands, 212
• infacmd sql Commands, 213
• infacmd wfs Commands, 214
• pmcmd Commands, 214
• pmrep Commands, 217 infacmd as Commands
To run infacmd as commands, users must have one of the listed sets of domain privileges, Analyst Service privileges, and domain object permissions.
193 The following table lists the required privileges and permissions for infacmd as commands:
infacmd as Command Privilege Group Privilege Name Permission On...
CreateAuditTables Domain Administration Manage Service Domain or node where Analyst Service runs
CreateService Domain Administration Manage Service Domain or node where Analyst Service runs
DeleteAuditTables Domain Administration Manage Service Domain or node where Analyst Service runs
ListServiceOptions - - Analyst Service
ListServiceProcessOptions - - Analyst Service
UpdateServiceOptions Domain Administration Manage Service Domain or node where Analyst Service runs
UpdateServiceProcessOptions Domain Administration Manage Service Domain or node where Analyst Service runs infacmd cluster Commands
To run infacmd cluster commands, users must have one of the listed sets of domain privileges and cluster configuration permissions.
The following table lists the required privileges and permissions for infacmd cluster commands:
infacmd cluster Command Privilege Group Privilege Name Permission On...
clearConfigurationProperties Domain Manage Connections Write on cluster Administration configuration
createConfiguration Domain Manage Connections Write on cluster Administration configurations
deleteConfiguration Domain Manage Connections Write on cluster Administration configurations
exportConfiguration with sensitive - - Write on cluster properties configuration
exportConfiguration without sensitive - - Read on cluster properties configurations
listAssociatedConnections - - -
listConfigurations - - -
listConfigurationGroupPermissions - - -
194 Appendix A: Command Line Privileges and Permissions infacmd cluster Command Privilege Group Privilege Name Permission On...
listConfigurationProperties - - Read on cluster configurations
listConfigurationSets - - Read on cluster configurations
listConfigurationUserPermissions - - -
refreshConfiguration Domain Manage Connections Write on cluster Administration configurations
setConfigurationPermissions - - Grant on cluster configuration
setConfigurationProperties Domain Manage Connections Write on cluster Administration configurations infacmd dis Commands
To run infacmd dis commands, users must have one of the listed sets of domain privileges, Data Integration Service privileges, and domain object permissions.
The following table lists the required privileges and permissions for infacmd dis commands:
infacmd dis Command Privilege Group Privilege Name Permission On...
BackupApplication Application Administration Manage Applications Application
CancelDataObjectCacheRe - - - fresh
CreateService Domain Administration Manage Services Domain or node where Data Integration Service runs
DeployApplication Application Administration Manage Applications Application
ListApplicationObjects - - -
ListApplications - - -
ListComputeOptions Domain Administration Manage Services Data Integration Service
ListDataObjectOptions - - -
ListServiceOptions Domain Administration Manage Services Data Integration Service
ListServiceProcessOptions Domain Administration Manage Services Data Integration Service
PurgeDataObjectCache - - -
infacmd dis Commands 195 infacmd dis Command Privilege Group Privilege Name Permission On...
RefreshDataObjectCache - - -
RenameApplication Application Administration Manage Applications Application
RestoreApplication Application Administration Manage Applications Application
StartApplication Application Administration Manage Applications Application
StopApplication Application Administration Manage Applications Application
stopBlazeService Application Administration Manage Applications Application
UndeployApplication Application Administration Manage Applications Application
UpdateApplication Application Administration Manage Applications Application
UpdateApplicationOptions Application Administration Manage Applications Application
UpdateDataObjectOptions Application Administration Manage Applications -
UpdateComputeOptions Domain Administration Manage Services Data Integration Service
UpdateServiceOptions Domain Administration Manage Services Data Integration Service
UpdateServiceProcessOpti Domain Administration Manage Services Data Integration Service ons infacmd dp Commands
Users must be native users or be assigned the Administrator role to run the following infacmd dp commands:
• startSparkJobServer
• stopSparkJobServer infacmd es commands
Users must be assigned the Administrator role for the domain to run the following infacmd es commands:
• ListServiceOptions
• UpdateServiceOptions
• UpdateSMTPOptions
196 Appendix A: Command Line Privileges and Permissions infacmd ipc Commands
To run infacmd ipc commands, users must have one of the listed Model repository object permissions.
The following table lists the required privileges and permissions for infacmd ipc commands:
infacmd ipc Command Privilege Group Privilege Name Permission On...
ExportToPC - - Read on the folder that creates reference tables to be exported
genReuseReportFromPC Tools Access Repository - Manager infacmd isp Commands
To run infacmd isp commands, users must have one of the listed sets of domain privileges, service privileges, domain object permissions, and connection permissions.
The following table lists the required privileges and permissions for infacmd isp commands:
infacmd isp Command Privilege Group Privilege Name Permission On
AddAlertUser (for other users) Security Manage Users, - Administration Groups, and Roles
AddAlertUser (for your user account) - - -
AddConnectionPermissions - - Grant on connection
AddDomainLink* - - -
AddDomainNode Domain Manage Nodes and Domain and node Administration Grids
AddGroupPrivilege Security Grant Privileges and Domain, Metadata Administration Roles Manager Service, Model Repository Service, or PowerCenter Repository Service.
AddLicense Domain Manage Services Domain or parent folder Administration
AddNodeResource Domain Manage Nodes and Node Administration Grids
AddRolePrivilege Security Manage Users, - Administration Groups, and Roles
AddServiceLevel* - - -
infacmd ipc Commands 197 infacmd isp Command Privilege Group Privilege Name Permission On
AddUserToGroup Security Manage Users, - Administration Groups, and Roles
AssignGroupPermission (on application Domain Manage Services Application service or services or license objects) Administration license object
AssignGroupPermission (on domain)* - - -
AssignGroupPermission (on folders) Domain Manage Domain Folder Administration Folders
AssignGroupPermission (on nodes and Domain Manage Nodes and Node or grid grids) Administration Grids
AssignGroupPermission (on operating - - - system profiles)*
AssignISTOMMService Domain Manage Services Metadata Manager Administration Service
AssignLicense Domain Manage Services License object and Administration application service
AssignRSToWSHubService Domain Manage Services PowerCenter Repository Administration Service and Web Services Hub
AssignRoleToGroup Security Grant Privileges and Domain, Metadata Administration Roles Manager Service, Model Repository Service, or PowerCenter Repository Service.
AssignRoleToUser Security Grant Privileges and Domain, Metadata Administration Roles Manager Service, Model Repository Service, or PowerCenter Repository Service.
AssignUserPermission (on application Domain Manage Services Application service or services or license objects) Administration license object
AssignUserPermission (on domain)* - - -
AssignUserPermission (on folders) Domain Manage Domain Folder Administration Folders
AssignUserPermission (on nodes or Domain Manage Nodes and Node or grid grids) Administration Grids
AssignUserPermission (on operating - - - system profiles)*
198 Appendix A: Command Line Privileges and Permissions infacmd isp Command Privilege Group Privilege Name Permission On
AssignUserPrivilege Security Grant Privileges and Domain, Metadata Administration Roles Manager Service, Model Repository Service, or PowerCenter Repository Service.
AssignedToLicense Domain Manage Services License object and Administration application service
ConvertLogFile - - Domain or application service
CreateConnection* - - -
CreateFolder Domain Manage Domain Domain or parent folder Administration Folders
CreateGrid Domain Manage Nodes and Domain or parent folder Administration Grids and nodes assigned to grid
CreateGroup Security Manage Users, - Administration Groups, and Roles
CreateIntegrationService Domain Manage Services Domain or parent folder, Administration node or grid where PowerCenter Integration Service runs, license object, and associated PowerCenter Repository Service
CreateMMService Domain Manage Services Domain or parent folder, Administration node where Metadata Manager Service runs, license object, and associated PowerCenter Integration Service and PowerCenter Repository Service
CreateOSProfile* - - -
CreateRepositoryService Domain Manage Services Domain or parent folder, Administration node where PowerCenter Repository Service runs, and license object
CreateRole Security Manage Users, - Administration Groups, and Roles
CreateSAPBWService Domain Manage Services Domain or parent folder, Administration node or grid where SAP BW Service runs, license object, and associated PowerCenter Integration Service
infacmd isp Commands 199 infacmd isp Command Privilege Group Privilege Name Permission On
CreateUser Security Manage Users, - Administration Groups, and Roles
CreateWSHubService Domain Manage Services Domain or parent folder, Administration node or grid where Web Services Hub runs, license object, and associated PowerCenter Repository Service
DisableNodeResource Domain Manage Nodes and Node Administration Grids
DisableService (for Metadata Manager Domain Manage Service Metadata Manager Service) Administration Execution Service and associated PowerCenter Integration Service and PowerCenter Repository Service
DisableService (for all other application Domain Manage Service Application service services) Administration Execution
DisableServiceProcess Domain Manage Service Application service Administration Execution
DisableUser Security Manage Users, - Administration Groups, and Roles
EditUser Security Manage Users, - Administration Groups, and Roles
EnableNodeResource Domain Manage Nodes and Node Administration Grids
EnableService (for Metadata Manager Domain Manage Service Metadata Manager Service) Administration Execution Service, and associated PowerCenter Integration Service and PowerCenter Repository Service
EnableService (for all other application Domain Manage Service Application service services) Administration Execution
EnableServiceProcess Domain Manage Service Application service Administration Execution
EnableUser Security Manage Users, - Administration Groups, and Roles
ExportDomainObjects (for connections) Domain Manage Connections Read on connections Administration
ExportDomainObjects (for users, groups, Security Manage Users, - and roles) Administration Groups, and Roles
200 Appendix A: Command Line Privileges and Permissions infacmd isp Command Privilege Group Privilege Name Permission On
ExportUsersAndGroups Security Manage Users, - Administration Groups, and Roles
GetFolderInfo - - Folder
GetLastError - - Application service
GetLog - - Domain or application service
GetNodeName - - Node
GetServiceOption - - Application service
GetServiceProcessOption - - Application service
GetServiceProcessStatus - - Application service
GetServiceStatus - - Application service
GetSessionLog Run-time Objects Monitor Read on repository folder
GetWorkflowLog Run-time Objects Monitor Read on repository folder
Help - - -
ImportDomainObjects (for connections) Domain Manage Connections Write on connections Administration
ImportDomainObjects (for users, Security Manage Users, - groups, and roles) Administration Groups, and Roles
ImportUsersAndGroups Security Manage Users, - Administration Groups, and Roles
ListAlertUsers - - Domain
ListAllGroups - - -
ListAllRoles - - -
ListAllUsers - - -
ListConnectionOptions - - Read on connection
ListConnectionPermissions - - -
ListConnectionPermissions by Group - - -
ListConnectionPermissions by User - - -
ListConnections - - -
ListDomainLinks - - Domain
infacmd isp Commands 201 infacmd isp Command Privilege Group Privilege Name Permission On
ListDomainOptions - - Domain
ListFolders - - Folders
ListGridNodes - - -
ListGroupPermissions - - -
ListGroupPrivilege Security Grant Privileges and Domain, Metadata Administration Roles Manager Service, Model Repository Service, or PowerCenter Repository Service.
ListGroupsForUser - - Domain
ListLDAPConnectivity Security Manage Users, - Administration Groups, and Roles
ListLicenses - - License objects
ListNodeOptions - - Node
ListNodeResources - - Node
ListNodes - - -
ListPlugins - - -
ListRepositoryLDAPConfiguration - - Domain
ListRolePrivileges - - -
ListSMTPOptions - - Domain
ListSecurityDomains Security Manage Users, - Administration Groups, and Roles
ListServiceLevels - - Domain
ListServiceNodes - - Application service
ListServicePrivileges - - -
ListServices - - -
ListUserPermissions - - -
ListUserPrivilege Security Grant Privileges and Domain, Metadata Administration Roles Manager Service, Model Repository Service, or PowerCenter Repository Service.
202 Appendix A: Command Line Privileges and Permissions infacmd isp Command Privilege Group Privilege Name Permission On
MoveFolder Domain Manage Domain Original and destination Administration Folders folders
MoveObject (for application services or Domain Manage Services Original and destination license objects) Administration folders
MoveObject (for nodes or grids) Domain Manage Nodes and Original and destination Administration Grids folders
Ping - - -
PurgeLog* - - -
RemoveAlertUser (for other users) Security Manage Users, - Administration Groups, and Roles
RemoveAlertUser (for your user - - - account)
RemoveConnection - - Write on connection
RemoveConnectionPermissions - - Grant on connection
RemoveDomainLink* - - -
RemoveFolder Domain Manage Domain Domain or parent folder Administration Folders and folder being removed
RemoveGrid Domain Manage Nodes and Domain or parent folder Administration Grids and grid
RemoveGroup Security Manage Users, - Administration Groups, and Roles
RemoveGroupPrivilege Security Grant Privileges and Domain, Metadata Administration Roles Manager Service, Model Repository Service, or PowerCenter Repository Service.
RemoveLicense Domain Manage Services Domain or parent folder Administration and license object
RemoveNode Domain Manage Nodes and Domain or parent folder Administration Grids and node
RemoveNodeResource Domain Manage Nodes and Node Administration Grids
RemoveOSProfile* - - -
RemoveRole Security Manage Users, - Administration Groups, and Roles
infacmd isp Commands 203 infacmd isp Command Privilege Group Privilege Name Permission On
RemoveRolePrivilege Security Manage Users, - Administration Groups, and Roles
RemoveService Domain Manage Services Domain or parent folder Administration and application service
RemoveServiceLevel* - - -
RemoveUser Security Manage Users, - Administration Groups, and Roles
RemoveUserFromGroup Security Manage Users, - Administration Groups, and Roles
RemoveUserPrivilege Security Grant Privileges and Domain, Metadata Administration Roles Manager Service, Model Repository Service, or PowerCenter Repository Service.
RenameConnection - - Write on connection
ResetPassword (for other users) Security Manage Users, - Administration Groups, and Roles
ResetPassword (for your user account) - - -
RunCPUProfile Domain Manage Nodes and Node Administration Grids
SetConnectionPermission - - Grant on connection
SetLDAPConnectivity Security Manage Users, - Administration Groups, and Roles
SetRepositoryLDAPConfiguration - - Domain
ShowLicense - - License object
ShutdownNode Domain Manage Nodes and Node Administration Grids
SwitchToGatewayNode* - - -
SwitchToWorkerNode* - - -
UnAssignISMMService Domain Manage Services PowerCenter Integration Administration Service and Metadata Manager Service
UnAssignRoleFromGroup Security Grant Privileges and Domain, Metadata Administration Roles Manager Service, Model Repository Service, or PowerCenter Repository Service.
204 Appendix A: Command Line Privileges and Permissions infacmd isp Command Privilege Group Privilege Name Permission On
UnAssignRoleFromUser Security Grant Privileges and Domain, Metadata Administration Roles Manager Service, Model Repository Service, or PowerCenter Repository Service.
UnassignLicense Domain Manage Services License object and Administration application service
UnassignRSWSHubService Domain Manage Services PowerCenter Repository Administration Service and Web Services Hub
UnassociateDomainNode Domain Manage Nodes and Node Administration Grids
UpdateConnection - - Write on connection
UpdateDomainOptions* - - -
UpdateFolder Domain Manage Domain Folder Administration Folders
UpdateGatewayInfo* - - -
UpdateGrid Domain Manage Nodes and Grid and nodes Administration Grids
UpdateIntegrationService Domain Manage Services PowerCenter Integration Administration Service
UpdateLicense Domain Manage Services License object Administration
UpdateMMService Domain Manage Services Metadata Manager Administration Service
UpdateNodeOptions Domain Manage Nodes and Node Administration Grids
UpdateNodeRole Domain Manage Nodes and Node Administration Grids
UpdateOSProfile Security Manage Users, Operating system profile Administration Groups, and Roles
UpdateRepositoryService Domain Manage Services PowerCenter Repository Administration Service
UpdateSAPBWService Domain Manage Services SAP BW Service Administration
UpdateSMTPOptions* - - -
UpdateServiceLevel* - - -
infacmd isp Commands 205 infacmd isp Command Privilege Group Privilege Name Permission On
UpdateServiceProcess Domain Manage Services PowerCenter Integration Administration Service Each node added to the PowerCenter Integration Service
UpdateWSHubService Domain Manage Services Web Services Hub Administration
generateHadoopConnectionFromHiveCo - - - nection
listMonitoringOptions Monitoring Monitoring Domain Configuration
purgeMonitoringData Monitoring Monitoring Domain Configuration
updateMonitoringOptions Monitoring Monitoring Domain Configuration
*To run these commands, users must be assigned the Administrator role for the domain. infacmd mas Commands
To run infacmd mas commands, users must have one of the listed sets of domain privileges, Metadata Access Service privileges, and domain object permissions.
The following table lists the required privileges and permissions for infacmd mas commands:
infacmd dis Command Privilege Group Privilege Name Permission On...
CreateService Domain Administration Manage Services Domain or node where Metadata Access Service runs
ListServiceOptions Domain Administration Manage Services Metadata Access Service
ListServiceProcessOptions Domain Administration Manage Services Metadata Access Service
UpdateServiceOptions Domain Administration Manage Services Metadata Access Service
UpdateServiceProcessOpti Domain Administration Manage Services Metadata Access Service ons
206 Appendix A: Command Line Privileges and Permissions infacmd mrs Commands
To run infacmd mrs commands, users must have one of the listed sets of domain privileges, Model Repository Service privileges, and Model repository object permissions.
Users can run the following commands, which are related to locking and versioning operations, on objects they own. Running the commands on objects that other users own requires the Manage Team-based Development privilege:
• CheckInObject
• ListCheckedOutObjects
• ListLockedObjects
• UndoCheckout
• UnlockObject
The following table lists the required privileges and permissions for infacmd mrs commands:
infacmd mrs Command Privilege Group Privilege Name Permission On...
BackupContents Domain Administration Manage Service Domain or node where the Model Repository Service runs
CheckInObject Domain Administration Manage Team-based The Model Repository Development Service
CreateContents Domain Administration Manage Service Domain or node where the Model Repository Service runs
CreateFolder Domain Administration For Developer tool: The Model Repository - Access Developer Service For Analyst tool: - Access Analyst - Discovery workspace access
CreateProject Domain Administration Create, Edit and Delete The Model Repository Projects Service
CreateService Domain Administration Manage Service Domain or node where the Model Repository Service runs
DeleteContents Domain Administration Manage Service Domain or node where the Model Repository Service runs
DeleteFolder Domain Administration For Developer tool: The Model Repository - Access Developer Service For Analyst tool: - Access Analyst - Discovery workspace access
infacmd mrs Commands 207 infacmd mrs Command Privilege Group Privilege Name Permission On...
DeleteProject Domain Administration Create, Edit and Delete The Model Repository Projects Service
ListBackupFiles Domain Administration Manage Service Domain or node where the Model Repository Service runs
ListCheckedOutObjects Domain Administration Manage Team-based The Model Repository Development Service
ListFolders Domain Administration Manage Service Domain or node where the Model Repository Service runs
ListLockedObjects Domain Administration Manage Team-based The Model Repository Development Service
ListProjects Domain Administration For Developer tool: Domain or node where the - Access Developer Model Repository Service For Analyst tool: runs - Access Analyst - Discovery workspace access
ListServiceOptions - - The Model Repository Service
ListServiceProcessOptions - - The Model Repository Service
PopulateVCS Domain Administration Manage Team-based The Model Repository Development Service
ReassignCheckedOutObjec Domain Administration Manage Team-based The Model Repository t Development Service
RebuildDependencyGraph - - The Model Repository Service
RenameFolder Domain Administration For Developer tool: The Model Repository - Access Developer Service For Analyst tool: - Access Analyst - Discovery workspace access
RestoreContents Domain Administration Manage Service Domain or node where the Model Repository Service runs
UndoCheckout Domain Administration Manage Team-based The Model Repository Development Service
UnlockObject Domain Administration Manage Team-based The Model Repository Development Service
208 Appendix A: Command Line Privileges and Permissions infacmd mrs Command Privilege Group Privilege Name Permission On...
UpdateServiceOptions Domain Administration Manage Service The Model Repository Service
UpdateServiceProcessOpti Domain Administration Manage Service The Model Repository ons Service
UpgradeContents Model Repository Service Manage Service The Model Repository Administration Service infacmd ms Commands
To run infacmd ms commands, users must have one of the listed sets of domain object permissions.
The following table lists the required privileges and permissions for infacmd ms commands:
infacmd ms Command Privilege Group Privilege Name Permission On...
deleteMappingPersistedOutputs - - Execute on the application
getRequestLog - - -
listMappingParams - - -
listMappingPersistedOutputs - - View on the application
listMappings - - -
runMapping - - Execute on connection objects used by the mapping infacmd tools Commands
To run infacmd tools commands, users must have one of the listed Model repository object permissions.
The following table lists the required permissions for infacmd tools commands:
infacmd tools Command Privilege Group Privilege Name Permission On...
ExportObjects - - Read on project
ImportObjects - - Write on project
infacmd ms Commands 209 infacmd ps Commands
To run infacmd ps commands, users must have one of the listed sets of profiling privileges and domain object permissions.
The following table lists the required privileges and permissions for infacmd ps commands:
infacmd ps Command Privilege Group Privilege Name Permission On...
CreateWH - - -
DropWH - - -
Execute - - Read on project Execute on the source connection object
List - - Read on project
Purge - - Read and write on project infacmd pwx Commands
To run infacmd pwx commands, users must have one of the listed sets of PowerExchange application service permissions and privileges.
The following table lists the required privileges and permissions for infacmd pwx commands:
infacmd pwx Command Privilege Group Privilege Name Permission On...
CloseForceListener Management closeforce - Commands
CloseListener Management close - Commands
CondenseLogger Management condense - Commands
CreateListenerService Domain Administration Manage Service Domain or node where the PowerExchange application service runs
CreateLoggerService Domain Administration Manage Service Domain or node where the PowerExchange application service runs
DisplayAllLogger Informational displayall - Commands
210 Appendix A: Command Line Privileges and Permissions infacmd pwx Command Privilege Group Privilege Name Permission On...
DisplayCPULogger Informational displaycpu - Commands
DisplayEventsLogger Informational displayevents - Commands
DisplayMemoryLogger Informational displaymemory - Commands
DisplayRecordsLogger Informational displayrecords - Commands
DisplayStatusLogger Informational displaystatus - Commands
FileSwitchLogger Management fileswitch - Commands
ListTaskListener Informational listtask - Commands
ShutDownLogger Management shutdown - Commands
StopTaskListener Management stoptask - Commands
UpdateListenerService Domain Administration Manage Service Domain or node where the PowerExchange application service runs
UpdateLoggerService Domain Administration Manage Service Domain or node where the PowerExchange application service runs infacmd rms Commands
To run infacmd rms commands, users must have one of the listed sets of domain privileges and permissions
The following table lists the required privileges and permissions for infacmd rms commands:
infacmd rms Command Privilege Group Privilege Name Permission On
ListComputeNodeAttribute Domain Administration - Resource Manager Service s
ListServiceOptions Domain Administration - Resource Manager Service
infacmd rms Commands 211 infacmd rms Command Privilege Group Privilege Name Permission On
SetComputeNodeAttribute Domain Administration Manage Services Resource Manager Service s
UpdateServiceOptions Domain Administration Manage Services Resource Manager Service infacmd rtm Commands
To run infacmd rtm commands, users must have one of the listed sets of Model Repository Service privileges and domain object permissions.
The following table lists the required privileges and permissions for infacmd rtm commands:
infacmd rtm Command Privilege Group Privilege Name Permission On...
Deployimport - - -
Export - - Read on the project that contains reference tables to be exported
Import - - Read and Write on the project where reference tables are imported infacmd sch commands
To run infacmd sch commands, users must have one of the listed sets of privileges and permissions.
The following table lists the required privileges and permissions for infacmd sch commands:
infacmd sch Command Privilege Group Privilege Name Permission On
CreateSchedule Scheduler Privileges Create Schedule Scheduler Service
DeleteSchedule Scheduler Privileges Delete Schedule Scheduler Service
ListSchedule Scheduler Privileges View Schedules Scheduler Service
ListServiceOptions Domain Privileges Manage Services Scheduler Service
ListServiceProcessOptions Domain Privileges Manage Services Scheduler Service
PauseAll Scheduler Privileges Edit Schedule Scheduler Service
PauseSchedule Scheduler Privileges Edit Schedule Scheduler Service
212 Appendix A: Command Line Privileges and Permissions infacmd sch Command Privilege Group Privilege Name Permission On
ResumeAll Scheduler Privileges Edit Schedule Scheduler Service
ResumeSchedule Scheduler Privileges Edit Schedule Scheduler Service
UpdateSchedule Scheduler Privileges Edit Schedule Scheduler Service
UpdateService Domain Privileges Manage Services Scheduler Service
UpdateServiceProcess Domain Privileges Manage Services Scheduler Service
Upgrade Domain Privileges Manage Services Scheduler Service infacmd sql Commands
To run infacmd sql commands, users must have one of the listed sets of domain privileges, Data Integration Service privileges, and domain object permissions.
The following table lists the required privileges and permissions for infacmd sql commands:
infacmd sql Command Privilege Group Privilege Name Permission On...
ExecuteSQL - - Based on objects that you want to access in your SQL statement
ListColumnPermissions - - -
ListSQLDataServiceOptions - - -
ListSQLDataServicePermissions - - -
ListSQLDataServices - - -
ListStoredProcedurePermissions - - -
ListTableOptions - - -
ListTablePermissions - - -
PurgeTableCache - - -
RefreshTableCache - - -
RenameSQLDataService Application Manage Applications - Administration
SetColumnPermissions - - Grant on the object
SetSQLDataServicePermissions - - Grant on the object
infacmd sql Commands 213 infacmd sql Command Privilege Group Privilege Name Permission On...
SetStoredProcedurePermissions - - Grant on the object
SetTablePermissions - - Grant on the object
StartSQLDataService Application Manage Applications - Administration
StopSQLDataService Application Manage Applications - Administration
UpdateColumnOptions Application Manage Applications - Administration
UpdateSQLDataServiceOptions Application Manage Applications - Administration
UpdateTableOptions Application Manage Applications - Administration infacmd wfs Commands
To run infacmd wfs commands, users do not require any privileges or permissions. pmcmd Commands
To run pmcmd commands, users must have the listed sets of PowerCenter Repository Service privileges and PowerCenter repository object permissions.
When the PowerCenter Integration Service runs in safe mode, users must have the Administrator role for the associated PowerCenter Repository Service to run the following commands:
• aborttask
• abortworkflow
• getrunningsessionsdetails
• getservicedetails
• getsessionstatistics
• gettaskdetails
• getworkflowdetails
• recoverworkflow
• scheduleworkflow
• starttask
• startworkflow
214 Appendix A: Command Line Privileges and Permissions • stoptask
• stopworkflow
• unscheduleworkflow The following table lists the required privileges and permissions for pmcmd commands:
pmcmd Command Privilege Group Privilege Name Permission
aborttask (started by own - - Read and Execute on folder user account)
aborttask (started by other Run-time Objects Manage Execution Read and Execute on folder users)
abortworkflow (started by - - Read and Execute on folder own user account)
abortworkflow (started by Run-time Objects Manage Execution Read and Execute on folder other users)
connect - - -
disconnect - - -
exit - - -
getrunningsessionsdetails Run-time Objects Monitor -
getservicedetails Run-time Objects Monitor Read on folder
getserviceproperties - - -
getsessionstatistics Run-time Objects Monitor Read on folder
gettaskdetails Run-time Objects Monitor Read on folder
getworkflowdetails Run-time Objects Monitor Read on folder
help - - -
pingservice - - -
recoverworkflow (started by Run-time Objects Execute Read and Execute on folder own user account) Read and Execute on connection object Permission on operating system profile (if applicable)
recoverworkflow (started by Run-time Objects Manage Execution Read and Execute on folder other users) Read and Execute on connection object Permission on operating system profile (if applicable)
pmcmd Commands 215 pmcmd Command Privilege Group Privilege Name Permission
scheduleworkflow Run-time Objects Manage Execution Read and Execute on folder Read and Execute on connection object Permission on operating system profile (if applicable)
setfolder - - Read on folder
setnowait - - -
setwait - - -
showsettings - - -
starttask Run-time Objects Execute Read and Execute on folder Read and Execute on connection object Permission on operating system profile (if applicable)
startworkflow Run-time Objects Execute Read and Execute on folder Read and Execute on connection object Permission on operating system profile (if applicable)
stoptask (started by own user - - Read and Execute on folder account)
stoptask (started by other Run-time Objects Manage Execution Read and Execute on folder users)
stopworkflow (started by own - - Read and Execute on folder user account)
stopworkflow (started by Run-time Objects Manage Execution Read and Execute on folder other users)
unscheduleworkflow Run-time Objects Manage Execution Read and Execute on folder
unsetfolder - - Read on folder
version - - -
waittask Run-time Objects Monitor Read on folder
waitworkflow Run-time Objects Monitor Read on folder
216 Appendix A: Command Line Privileges and Permissions pmrep Commands
Users must have the Access Repository Manager privilege to run all pmrep commands except for the following commands:
• Run
• Create
• Restore
• Upgrade
• Version
• Help To run pmrep commands, users must have one of the listed sets of domain privileges, PowerCenter Repository Service privileges, domain object permissions, and PowerCenter repository object permissions.
Users must be the object owner or have the Administrator role for the PowerCenter Repository Service to run the following commands:
• AssignPermission
• ChangeOwner
• CreateQuery
• DeleteConnection
• DeleteDeploymentGroup
• DeleteFolder
• DeleteLabel
• DeleteQuery
• ModifyFolder (to change owner, configure permissions, designate the folder as shared, or edit the folder name or description) The following table lists the required privileges and permissions for pmrep commands:
pmrep Command Privilege Group Privilege Name Permission
AddToDeploymentGroup Global Objects Manage Deployment Read on original folder Groups Read and Write on deployment group
ApplyLabel - - Read on folder Read and Execute on label
AssignPermission - - -
BackUp Domain Administration Manage Services Permission on PowerCenter Repository Service
ChangeOwner - - -
CheckIn (for your own Design Objects Create, Edit, and Read and Write on folder checkouts) Delete
pmrep Commands 217 pmrep Command Privilege Group Privilege Name Permission
CheckIn (for your own Sources and Targets Create, Edit, and Read and Write on folder checkouts) Delete
CheckIn (for your own Run-time Objects Create, Edit, and Read and Write on folder checkouts) Delete
CheckIn (for others’ Design Objects Manage Versions Read and Write on folder checkouts)
CheckIn (for others’ Sources and Targets Manage Versions Read and Write on folder checkouts)
CheckIn (for others’ Run-time Objects Manage Versions Read and Write on folder checkouts)
CleanUp - - -
ClearDeploymentGroup Global Objects Manage Deployment Read and Write on deployment Groups group
Connect - - -
Create Domain Administration Manage Services Permission on PowerCenter Repository Service
CreateConnection Global Objects Create Connections -
CreateDeploymentGroup Global Objects Manage Deployment - Groups
CreateFolder Folders Create -
CreateLabel Global Objects Create Labels -
CreateQuery Global Objects Create Queries -
Delete Domain Administration Manage Services Permission on PowerCenter Repository Service
DeleteConnection - - -
DeleteDeploymentGroup - - -
DeleteFolder - - -
DeleteLabel - - -
DeleteObject Design Objects Create, Edit, and Read and Write on folder Delete
DeleteObject Sources and Targets Create, Edit, and Read and Write on folder Delete
DeleteObject Run-time Objects Create, Edit, and Read and Write on folder Delete
218 Appendix A: Command Line Privileges and Permissions pmrep Command Privilege Group Privilege Name Permission
DeleteQuery - - -
DeployDeploymentGroup Global Objects Manage Deployment Read on original folder Groups Read and Write on destination folder Read and Execute on deployment group
DeployFolder Folders Copy on original Read on folder repository Create on destination repository
ExecuteQuery - - Read and Execute on query
Exit - - -
FindCheckout - - Read on folder
GetConnectionDetails - - Read on connection object
Help - - -
KillUserConnection Domain Administration Manage Services Permission on PowerCenter Repository Service
ListConnections - - Read on connection object
ListObjectDependencies - - Read on folder
ListObjects - - Read on folder
ListTablesBySess - - Read on folder
ListUserConnections Domain Administration Manage Services Permission on PowerCenter Repository Service
ModifyFolder (to change - - - owner, configure permissions, designate the folder as shared, or edit the folder name or description)
ModifyFolder (to change Folders Manage Versions Read and Write on folder status)
Notify Domain Administration Manage Services Permission on PowerCenter Repository Service
ObjectExport - - Read on folder
ObjectImport Design Objects Create, Edit, and Read and Write on folder Delete
pmrep Commands 219 pmrep Command Privilege Group Privilege Name Permission
ObjectImport Sources and Targets Create, Edit, and Read and Write on folder Delete
ObjectImport Run-time Objects Create, Edit, and Read and Write on folder Delete
PurgeVersion Design Objects Manage Versions Read and Write on folder Read, Write, and Execute on query if you specify a query name
PurgeVersion Sources and Targets Manage Versions Read and Write on folder Read, Write, and Execute on query if you specify a query name
PurgeVersion Run-time Objects Manage Versions Read and Write on folder Read, Write, and Execute on query if you specify a query name
PurgeVersion (to purge Folders Manage Versions Read and Write on folder objects at the folder level)
PurgeVersion (to purge Domain Administration Manage Services Permission on PowerCenter objects at the repository Repository Service level)
Register Domain Administration Manage Services Permission on PowerCenter Repository Service
RegisterPlugin Domain Administration Manage Services Permission on PowerCenter Repository Service
Restore Domain Administration Manage Services Permission on PowerCenter Repository Service
RollbackDeployment Global Objects Manage Deployment Read and Write on destination Groups folder
Run - - -
ShowConnectionInfo - - -
SwitchConnection Run-time Objects Create, Edit, and Read and Write on folder Delete Read on connection object
TruncateLog Run-time Objects Manage Execution Read and Execute on folder
UndoCheckout (for your own Design Objects Create, Edit, and Read and Write on folder checkouts) Delete
UndoCheckout (for your own Sources and Targets Create, Edit, and Read and Write on folder checkouts) Delete
UndoCheckout (for your own Run-time Objects Create, Edit, and Read and Write on folder checkouts) Delete
220 Appendix A: Command Line Privileges and Permissions pmrep Command Privilege Group Privilege Name Permission
UndoCheckout (for others’ Design Objects Manage Versions Read and Write on folder checkouts)
UndoCheckout (for others’ Sources and Targets Manage Versions Read and Write on folder checkouts)
UndoCheckout (for others’ Run-time Objects Manage Versions Read and Write on folder checkouts)
Unregister Domain Administration Manage Services Permission on PowerCenter Repository Service
UnregisterPlugin Domain Administration Manage Services Permission on PowerCenter Repository Service
UpdateConnection - - Read and Write on connection object
UpdateEmailAddr Run-time Objects Create, Edit, and Read and Write on folder Delete
UpdateSeqGenVals Design Objects Create, Edit, and Read and Write on folder Delete
UpdateSrcPrefix Run-time Objects Create, Edit, and Read and Write on folder Delete
UpdateStatistics Domain Administration Manage Services Permission on PowerCenter Repository Service
UpdateTargPrefix Run-time Objects Create, Edit, and Read and Write on folder Delete
Upgrade Domain Administration Manage Services Permission on PowerCenter Repository Service
Validate Design Objects Create, Edit, and Read and Write on folder Delete
Validate Run-time Objects Create, Edit, and Read and Write on folder Delete
Version - - -
pmrep Commands 221 A p p e n d i x B
Custom Roles
This appendix includes the following topics:
• Analyst Service Custom Role, 222
• Metadata Manager Service Custom Roles, 223
• Operator Custom Role, 224
• PowerCenter Repository Service Custom Roles, 225
• Test Data Manager Custom Roles, 226
Analyst Service Custom Role
The Analyst Service Business Glossary Consumer is a custom Analyst Service role.
The following table lists the default privilege assigned to the Analyst Service Business Glossary Consumer custom role:
Privilege Group Privilege Name
Workspace Access Glossary Workspace
222 Metadata Manager Service Custom Roles
Metadata Manager Service custom roles include the Metadata Manager Advanced User, Metadata Manager Basic User, and Metadata Manager Intermediate User roles.
Metadata Manager Advanced User The following table lists the default privileges assigned to the Metadata Manager Advanced User custom role:
Privilege Group Privilege Name
Catalog - Share Shortcuts - View Lineage - View Related Catalogs - View Reports - View Profile Results - View Catalog - View Relationships - Manage Relationships - View Comments - Post Comments - Delete Comments - View Links - Manage Links - View Glossary - Manage Objects
Load - View Resource - Load Resource - Manage Schedules - Purge Metadata - Manage Resource
Model - View Model - Manage Model - Export/Import Models
Security Manage Catalog Permissions
Metadata Manager Basic User The following table lists the default privileges assigned to the Metadata Manager Basic User custom role:
Privilege Group Privilege Name
Catalog - View Lineage - View Related Catalogs - View Catalog - View Relationships - View Comments - View Links
Model View Model
Metadata Manager Service Custom Roles 223 Metadata Manager Intermediate User The following table lists the default privileges assigned to the Metadata Manager Intermediate User custom role:
Privilege Group Privilege Name
Catalog - View Lineage - View Related Catalogs - View Reports - View Profile Results - View Catalog - View Relationships - View Comments - Post Comments - Delete Comments - View Links - Manage Links - View Glossary
Load - View Resource - Load Resource
Model View Model
Operator Custom Role
The Operator custom role includes privileges for managing, scheduling, and monitoring application services.
The following table lists the default privileges assigned to the Operator custom role:
Privilege Group Privilege Name
Application Manage Applications Administration
Domain Administration Manage Service Execution
Model Repository Manage Team-based Development Service Administration
Monitoring The Monitoring privilege group includes the following privileges: - View: View Jobs of Other Users - View: View Statistics - View: View Reports - Access Monitoring: Access from Analyst Tool - Access Monitoring: Access from Developer Tool - Access Monitoring: Access from Administrator Tool - Perform Actions on Jobs Note: In a domain that uses Kerberos authentication, users must also have the Administrator role for the Model Repository Service that is configured for monitoring.
224 Appendix B: Custom Roles Privilege Group Privilege Name
Scheduler The Scheduler privilege group includes the following privileges: - Manage Scheduled Jobs: Create Schedule - Manage Scheduled Jobs: Delete Schedule - Manage Scheduled Jobs: Edit Schedule - Manage Scheduled Jobs: View Schedules
Tools Access Informatica Administrator
PowerCenter Repository Service Custom Roles
The PowerCenter Repository Service custom roles include the PowerCenter Connection Administrator, PowerCenter Developer, PowerCenter Operator, and PowerCenter Repository Folder Administrator.
PowerCenter Connection Administrator The following table lists the default privileges assigned to the PowerCenter Connection Administrator custom role:
Privilege Group Privilege Name
Tools Access Workflow Manager
Global Objects Create Connections
PowerCenter Developer The following table lists the default privileges assigned to the PowerCenter Developer custom role:
Privilege Group Privilege Name
Tools - Access Designer - Access Workflow Manager - Access Workflow Monitor
Design Objects - Create, Edit, and Delete - Manage Versions
Sources and Targets - Create, Edit, and Delete - Manage Versions
Run-time Objects - Create, Edit, and Delete - Execute - Manage Versions - Monitor
PowerCenter Repository Service Custom Roles 225 PowerCenter Operator The following table lists the default privileges assigned to the PowerCenter Operator custom role:
Privilege Group Privilege Name
Tools Access Workflow Monitor
Run-time Objects - Execute - Manage Execution - Monitor
PowerCenter Repository Folder Administrator The following table lists the default privileges assigned to the PowerCenter Repository Folder Administrator custom role:
Privilege Group Privilege Name
Tools Access Repository Manager
Folders - Copy - Create - Manage Versions
Global Objects - Manage Deployment Groups - Execute Deployment Groups - Create Labels - Create Queries
Test Data Manager Custom Roles
The Test Data Manager custom roles include the Test Data Administrator, Test Data Developer, Test Data Project DBA, Test Data Project Developer, Test Data Project Owner, Test Data Risk Manager, Test Data Specialist, and Test Engineer. Test Data Administrator The following table lists the default privileges assigned to the Test Data Administrator custom role:
Privilege Group Privilege Name
Projects Audit Project
Administration - View Connections - Manage Connections - Manage Preferences
226 Appendix B: Custom Roles Test Data Developer The following table lists the default privileges assigned to the Test Data Developer custom role:
Privilege Group Privilege Name
Policies - View Policies - Manage Policies
Data Domains - View Data Domains - Manage Data Domains
Projects Audit Project
Test Data Project DBA The following table lists the default privileges assigned to the Test Data Project DBA custom role:
Privilege Group Privilege Name
Projects - View Project - Execute Project - Monitor Project - Audit Project
Administration - View Connections - Manage Connections
Test Data Project Developer The following table lists the default privileges assigned to the Test Data Project Developer custom role:
Privilege Group Privilege Name
Policies View Policies
Data Domains View Data Domains
Projects - View Project - Discover Project - Execute Project - Monitor Project - Audit Project - Import Metadata
Data Masking - View Data Masking - Manage Data Masking
Data Subset - View Data Subset - Manage Data Subset
Administration - View Connections - Manage Connections
Test Data Manager Custom Roles 227 Test Data Project Owner The following table lists the default privileges assigned to the Test Data Project Owner custom role:
Privilege Group Privilege Name
Policies View Policies
Data Domains View Data Domains
Projects - View Project - Manage Project - Discover Project - Execute Project - Monitor Project - Audit Project - Import Metadata
Data Masking - View Data Masking - Manage Data Masking
Data Subset - View Data Subset - Manage Data Subset
Administration - View Connections - Manage Connections
Test Data Risk Manager The following table lists the default privileges assigned to the Test Data Risk Manager custom role:
Privilege Group Privilege Name
Policies View Policies
Data Domains View Data Domains
Projects Audit Project
Test Data Specialist The following table lists the default privileges assigned to the Test Data Specialist custom role:
Privilege Group Privilege Name
Policies View Policies
Data Domains - View Data Domains - Manage Data Domains
228 Appendix B: Custom Roles Privilege Group Privilege Name
Projects - View Project - Manage Project - Discover Project - Execute Project - Monitor Project - Audit Project - Import Metadata
Data Masking - View Data Masking - Manage Data Masking
Data Subset - View Data Subset - Manage Data Subset
Administration - View Connections - Manage Connections
Test Engineer The following table lists the default privileges assigned to the Test Engineer custom role:
Privilege Group Privilege Name
Projects - View Project - Monitor Project
Test Data Manager Custom Roles 229 A p p e n d i x C
Default List of Cipher Suites
By default, the Informatica domain uses the following cipher suites for secure communication within the domain and secure client connections:
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
• TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
• TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
• TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
230 • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
231 I n d e x
client configuration A secure domain 77 account management Cloud Administration privilege group overview 102 domain 136 accounts cluster changing the password 103 permissions by command 194 Administrator privileges by command 194 role 162 column level security administrators restricting columns 183 application client 108 command line programs default 107 privileges 193 domain 107 connection objects Analyst Service privileges for PowerCenter 154 custom roles 222 connections privileges 137 default permissions 176 application permission types 176 permissions 178 permissions 175 application services Content Management Service authorization 98 privileges 138 permissions 171 convertUserActivityLog user synchronization 98 user activity logs 113 as Create Reference Tables permissions by command 193 privilege 138 privileges by command 193 custom roles audit reports Analyst Service 222 description 187 assigning to users and groups 165 for groups 191 creating 163 for users 191, 192 deleting 164 overview 102 description 161, 163 authentication editing 164 Kerberos 19 Metadata Manager Service 223 LDAP 18, 23, 97 Operator 224 native 18, 97 PowerCenter Repository Service 225 Service Manager 97 privileges, assigning 164 authorization application services 98 Data Integration Service 98 Metadata Manager Service 98 D Model Repository Service 98 Data Integration Service PowerCenter Repository Service 98 authorization 98 Service Manager 98 privileges 138 default administrator description 107 modifying 107 B passwords, changing 107 Browse privilege group deployment groups description 139 privileges for PowerCenter 154 design objects description 146 privileges 146 C Design Objects privilege group cacerts truststore file 28 description 146 changing direct permission password for user account 103 description 170 cipher suites dis configuring 86 permissions by command 195
232 dis (continued) groups (continued) privileges by command 195 parent group 117 domain privileges, assigning 165 administration privileges 131 roles, assigning 165 administrator 107 synchronization 98 Administrator role 162 valid name 117 privileges 130 security administration privileges 130 user security 104 user synchronization 98 I users with privileges 166 identity provider Domain Administration privilege group configuring for single sign-on 63 description 131 Informatica Administrator domain administrator Navigator 99 description 107 overview 96 domain objects searching 99 permissions 171 Security page 99 domain permissions tabs, viewing 96 direct 170 Informatica Analyst effective 170 administrator 108 inherited 170 Informatica Developer administrator 108 Informatica domain permissions 104 E privileges 104 Edit Reference Table Metadata user security 104 privilege 138 users, managing 109 effective permission inherited permission description 170 description 170 environment variables inherited privileges INFA_TRUSTSTORE 77 description 165 INFA_TRUSTSTORE_PASSWORD 77 ipc es permissions by command 197 permissions by command 196 privileges by command 197 privileges by command 196 isp Everyone group permissions by command 197 description 106 privileges by command 197
F K filters Kerberos authentication getUserActivityLog 114 cross realm authentication 32 folders description 19 permissions 171 keytab 38 privileges 144 LDAP synchronization 55 Folders privilege group node level 33 description 144 overview 29, 30 process level 33 service principal accounts 37 service principal name 38 G SPN keytab format file 41 getUserActivityLog keytool utility 28 filters 114 user activity logs 113 global objects privileges for PowerCenter 154 L Global Objects privilege group labels description 154 privileges for PowerCenter 154 grids LDAP authentication permissions 171 Azure Active Directory 22 group description description 18, 97 invalid characters 117 directory services 23 groups nested groups 27 default Everyone 106 self-signed SSL certificate 28 invalid characters 117 setting up 23 managing 117 supported directory services 21 overview 100
Index 233 LDAP configurations native groups (continued) deleting 28 managing 117 LDAP directory service moving to another group 118 nested groups 27 users, assigning 110 LDAP groups native security domain importing 23 description 18 managing 117 native users LDAP security domain adding 109 description 18, 19 assigning to groups 110 LDAP users deleting 111 assigning to groups 111 editing 110 enabling 111 enabling 111 importing 23 managing 109 managing 109 passwords 109 licenses Navigator permissions 171 Security page 99 Load privilege group nested groups description 141 LDAP authentication 27 login activity LDAP directory service 27 viewing 113 nodes permissions 171 M mapping O inherited permissions 178 object queries permissions 178 privileges for PowerCenter 154 mas operating system profile permissions by command 206 creating 122 privileges by command 206 default 124 Metadata Manager deleting 124 administrator 108 editing 119 Metadata Manager Service managing 118 authorization 98 properties, Data Integration Service 119, 120 custom roles 223 properties, Metadata Access Service 122 privileges 139 properties, PowerCenter Integration Service 119 user synchronization 98 operating system profiles users with privileges 166 overview 101 Metadata Manager Service privileges permissions 171, 174 Browse privilege group 139 Operator} Load privilege group 141 custom roles 224 Model privilege group 141 Security privilege group 142 Model privilege group description 141 P Model Repository Service parent groups authorization 98 description 117 privileges 142 password user synchronization 98 changing for a user account 103 users with privileges 166 passwords Monitoring privilege group changing for default administrator 107 domain 135 native users 109 mrs requirements 109 permissions by command 207 permissions privileges by command 207 application 178 ms application services 171 permissions by command 209 as commands 193 privileges by command 209 cluster commands 194 connections 175 description 169 direct 170 N dis commands 195 native authentication domain objects 171 description 18, 97 effective 170 native groups es commands 196 adding 117 folders 171 deleting 118 grids 171 editing 118 inherited 170
234 Index permissions (continued) privileges ipc commands 197 Analyst Service 137 isp commands 197 as commands 193 licenses 171 assigning 165 mapping 178 cluster commands 194 mas commands 206 command line programs 193 mrs commands 207 Content Management Service 138 ms commands 209 Data Integration Service 138 nodes 171 description 128 operating system profiles 171, 174 design objects 146 pmcmd commands 214 dis commands 195 pmrep commands 217 domain 130 ps commands 210 domain administration 131 pwx commands 210 domain tools 136 rms commands 211 es commands 196 rtm commands 212 folders 144 sch commands 212 Informatica Cloud Administration 136 search filters 171 inherited 165 sql commands 213 ipc commands 197 SQL data service 180 isp commands 197 tools commands 209 mas commands 206 types 170 Metadata Manager Service 139 virtual schema 180 Model Repository Service 142 virtual stored procedure 180 monitoring 135 virtual table 180 mrs commands 207 web service 184 ms commands 209 web service operation 184 pmcmd commands 214 wfs commands 214 pmrep commands 217 workflow 178 PowerCenter global objects 154 working with privileges 169 PowerCenter Repository Service 143 pmcmd PowerCenter Repository Service tools 143 permissions by command 214 PowerExchange Listener Service 156 privileges by command 214 PowerExchange Logger Service 157 pmrep ps commands 210 permissions by command 217 pwx commands 210 privileges by command 217 rms commands 211 PowerCenter Client rtm commands 212 administrator 108 run-time objects 150 PowerCenter Repository Service sch commands 212 Administrator role 162 Scheduler Service 158 authorization 98 security administration 130 custom roles 225 sources 148 privileges 143 sql commands 213 user synchronization 98 targets 148 users with privileges 166 tools commands 209 PowerCenter security troubleshooting 166 managing 99 wfs commands 214 PowerExchange Listener Service working with permissions 169 privileges 156 ps PowerExchange Logger Service permissions by command 210 privileges 157 privileges by command 210 privilege groups pwx Browse 139 permissions by command 210 description 129 privileges by command 210 Design Objects 146 Domain Administration 131 Folders 144 Global Objects 154 R Informatica Cloud Administration 136 rms Load 141 permissions by command 211 Model 141 privileges by command 211 Monitoring 135 roles Run-time Objects 150 Administrator 162 Security 142 assigning 165 Security Administration 130 custom 163 Sources and Targets 148 description 129 Tools 136, 143 managing 161 overview 101
Index 235 roles (continued) system memory troubleshooting 166 increasing 112 rtm system-defined roles permissions by command 212 Administrator 162 privileges by command 212 assigning to users and groups 165 run-time objects description 161 description 150 privileges 150 Run-time Objects privilege group description 150 T targets privileges 148 Test Data Manager S administrator 108 sch tools permissions by command 212 permissions by command 209 privileges by command 212 privileges by command 209 Scheduler Service Tools privilege group privileges 158 domain 136 search filters PowerCenter Repository Service 143 permissions 171 Search section Informatica Administrator 99 secure domain U client configuration 77 UpdateColumnOptions security substituting column values 183 passwords 109 user accounts permissions 104 changing the password 103 privileges 104, 128, 130 created during installation 107 roles 129 default 107 Security Administration privilege group enabling 111 description 130 overview 107 Security Assertion Markup Language (SAML) user activity logs support for 60 activity codes 114 security domains convertUserActivityLog 113 deleting LDAP 28 getUserActivityLog 113 LDAP 18, 19 output formats 113 native 18 user description Security page invalid characters 109 Informatica Administrator 99 user security Navigator 99 description 97 Security privilege group users description 142 assigning to groups 110 Service Manager invalid characters 109 authentication 97 large number of 112 authorization 98 managing 109 single sign-on 98 overview 100 single sign-on privileges, assigning 165 configuring 61 roles, assigning 165 description 98 synchronization 98 overview 60 system memory 112 sources valid name 109 privileges 148 Sources and Targets privilege group description 148 sql V permissions by command 213 valid name privileges by command 213 groups 117 SQL data service user account 109 inherited permissions 180 virtual schema permission types 180 inherited permissions 180 permissions 180 permissions 180 SSL certificate virtual stored procedure LDAP authentication 28 inherited permissions 180 synchronization permissions 180 LDAP users 23 virtual table users 98 inherited permissions 180 permissions 180
236 Index wfs (continued) W privileges by command 214 web service workflow permission types 184 inherited permissions 178 permissions 184 permissions 178 web service operation permissions 184 web service resource permissions 184 wfs permissions by command 214
Index 237