Beruflich Dokumente
Kultur Dokumente
10.2
Security Guide
Informatica Security Guide
10.2
September 2017
© Copyright Informatica LLC 2013, 2019
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.
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, including without limitation: Copyright DataDirect Technologies. All rights
reserved. Copyright © Sun Microsystems. All rights reserved. Copyright © RSA Security Inc. All Rights Reserved. Copyright © Ordinal Technology Corp. All rights
reserved. Copyright © Aandacht c.v. All rights reserved. Copyright Genivia, Inc. All rights reserved. Copyright Isomorphic Software. All rights reserved. Copyright © Meta
Integration Technology, Inc. All rights reserved. Copyright © Intalio. All rights reserved. Copyright © Oracle. All rights reserved. Copyright © Adobe Systems Incorporated.
All rights reserved. Copyright © DataArt, Inc. All rights reserved. Copyright © ComponentSource. All rights reserved. Copyright © Microsoft Corporation. All rights
reserved. Copyright © Rogue Wave Software, Inc. All rights reserved. Copyright © Teradata Corporation. All rights reserved. Copyright © Yahoo! Inc. All rights reserved.
Copyright © Glyph & Cog, LLC. All rights reserved. Copyright © Thinkmap, Inc. All rights reserved. Copyright © Clearpace Software Limited. All rights reserved. Copyright
© Information Builders, Inc. All rights reserved. Copyright © OSS Nokalva, Inc. All rights reserved. Copyright Edifecs, Inc. All rights reserved. Copyright Cleo
Communications, Inc. All rights reserved. Copyright © International Organization for Standardization 1986. All rights reserved. Copyright © ej-technologies GmbH. All
rights reserved. Copyright © Jaspersoft Corporation. All rights reserved. Copyright © International Business Machines Corporation. All rights reserved. Copyright ©
yWorks GmbH. All rights reserved. Copyright © Lucent Technologies. All rights reserved. Copyright © University of Toronto. All rights reserved. Copyright © Daniel
Veillard. All rights reserved. Copyright © Unicode, Inc. Copyright IBM Corp. All rights reserved. Copyright © MicroQuill Software Publishing, Inc. All rights reserved.
Copyright © PassMark Software Pty Ltd. All rights reserved. Copyright © LogiXML, Inc. All rights reserved. Copyright © 2003-2010 Lorenzi Davide, All rights reserved.
Copyright © Red Hat, Inc. All rights reserved. Copyright © The Board of Trustees of the Leland Stanford Junior University. All rights reserved. Copyright © EMC
Corporation. All rights reserved. Copyright © Flexera Software. All rights reserved. Copyright © Jinfonet Software. All rights reserved. Copyright © Apple Inc. All rights
reserved. Copyright © Telerik Inc. All rights reserved. Copyright © BEA Systems. All rights reserved. Copyright © PDFlib GmbH. All rights reserved. Copyright ©
Orientation in Objects GmbH. All rights reserved. Copyright © Tanuki Software, Ltd. All rights reserved. Copyright © Ricebridge. All rights reserved. Copyright © Sencha,
Inc. All rights reserved. Copyright © Scalable Systems, Inc. All rights reserved. Copyright © jQWidgets. All rights reserved. Copyright © Tableau Software, Inc. All rights
reserved. Copyright© MaxMind, Inc. All Rights Reserved. Copyright © TMate Software s.r.o. All rights reserved. Copyright © MapR Technologies Inc. All rights reserved.
Copyright © Amazon Corporate LLC. All rights reserved. Copyright © Highsoft. All rights reserved. Copyright © Python Software Foundation. All rights reserved.
Copyright © BeOpen.com. All rights reserved. Copyright © CNRI. All rights reserved.
This product includes software developed by the Apache Software Foundation (http://www.apache.org/), and/or other software which is licensed under various
versions of the Apache License (the "License"). You may obtain a copy of these Licenses at http://www.apache.org/licenses/. Unless required by applicable law or
agreed to in writing, software distributed under these Licenses is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express
or implied. See the Licenses for the specific language governing permissions and limitations under the Licenses.
This product includes software which was developed by Mozilla (http://www.mozilla.org/), software copyright The JBoss Group, LLC, all rights reserved; software
copyright © 1999-2006 by Bruno Lowagie and Paulo Soares and other software which is licensed under various versions of the GNU Lesser General Public License
Agreement, which may be found at http:// www.gnu.org/licenses/lgpl.html. The materials are provided free of charge by Informatica, "as-is", without warranty of any
kind, either express or implied, including but not limited to the implied warranties of merchantability and fitness for a particular purpose.
The product includes ACE(TM) and TAO(TM) software copyrighted by Douglas C. Schmidt and his research group at Washington University, University of California,
Irvine, and Vanderbilt University, Copyright (©) 1993-2006, all rights reserved.
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (copyright The OpenSSL Project. All Rights Reserved) and
redistribution of this software is subject to terms available at http://www.openssl.org and http://www.openssl.org/source/license.html.
This product includes Curl software which is Copyright 1996-2013, Daniel Stenberg, <daniel@haxx.se>. All Rights Reserved. Permissions and limitations regarding this
software are subject to terms available at http://curl.haxx.se/docs/copyright.html. Permission to use, copy, modify, and distribute this software for any purpose with or
without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.
The product includes software copyright 2001-2005 (©) MetaStuff, Ltd. All Rights Reserved. Permissions and limitations regarding this software are subject to terms
available at http://www.dom4j.org/ license.html.
The product includes software copyright © 2004-2007, The Dojo Foundation. All Rights Reserved. Permissions and limitations regarding this software are subject to
terms available at http://dojotoolkit.org/license.
This product includes ICU software which is copyright International Business Machines Corporation and others. All rights reserved. Permissions and limitations
regarding this software are subject to terms available at http://source.icu-project.org/repos/icu/icu/trunk/license.html.
This product includes software copyright © 1996-2006 Per Bothner. All rights reserved. Your right to use such materials is set forth in the license which may be found at
http:// www.gnu.org/software/ kawa/Software-License.html.
This product includes OSSP UUID software which is Copyright © 2002 Ralf S. Engelschall, Copyright © 2002 The OSSP Project Copyright © 2002 Cable & Wireless
Deutschland. Permissions and limitations regarding this software are subject to terms available at http://www.opensource.org/licenses/mit-license.php.
This product includes software developed by Boost (http://www.boost.org/) or under the Boost software license. Permissions and limitations regarding this software
are subject to terms available at http:/ /www.boost.org/LICENSE_1_0.txt.
This product includes software copyright © 1997-2007 University of Cambridge. Permissions and limitations regarding this software are subject to terms available at
http:// www.pcre.org/license.txt.
This product includes software copyright © 2007 The Eclipse Foundation. All Rights Reserved. Permissions and limitations regarding this software are subject to terms
available at http:// www.eclipse.org/org/documents/epl-v10.php and at http://www.eclipse.org/org/documents/edl-v10.php.
This product includes software licensed under the terms at http://www.tcl.tk/software/tcltk/license.html, http://www.bosrup.com/web/overlib/?License, http://
www.stlport.org/doc/ license.html, http://asm.ow2.org/license.html, http://www.cryptix.org/LICENSE.TXT, http://hsqldb.org/web/hsqlLicense.html, http://
httpunit.sourceforge.net/doc/ license.html, http://jung.sourceforge.net/license.txt , http://www.gzip.org/zlib/zlib_license.html, http://www.openldap.org/software/
release/license.html, http://www.libssh2.org, http://slf4j.org/license.html, http://www.sente.ch/software/OpenSourceLicense.html, http://fusesource.com/downloads/
license-agreements/fuse-message-broker-v-5-3- license-agreement; http://antlr.org/license.html; http://aopalliance.sourceforge.net/; http://www.bouncycastle.org/
licence.html; http://www.jgraph.com/jgraphdownload.html; http://www.jcraft.com/jsch/LICENSE.txt; http://jotm.objectweb.org/bsd_license.html; . http://www.w3.org/
Consortium/Legal/2002/copyright-software-20021231; http://www.slf4j.org/license.html; http://nanoxml.sourceforge.net/orig/copyright.html; http://www.json.org/
license.html; http://forge.ow2.org/projects/javaservice/, http://www.postgresql.org/about/licence.html, http://www.sqlite.org/copyright.html, http://www.tcl.tk/
software/tcltk/license.html, http://www.jaxen.org/faq.html, http://www.jdom.org/docs/faq.html, http://www.slf4j.org/license.html; http://www.iodbc.org/dataspace/
iodbc/wiki/iODBC/License; http://www.keplerproject.org/md5/license.html; http://www.toedter.com/en/jcalendar/license.html; http://www.edankert.com/bounce/
index.html; http://www.net-snmp.org/about/license.html; http://www.openmdx.org/#FAQ; http://www.php.net/license/3_01.txt; http://srp.stanford.edu/license.txt;
http://www.schneier.com/blowfish.html; http://www.jmock.org/license.html; http://xsom.java.net; http://benalman.com/about/license/; https://github.com/CreateJS/
EaselJS/blob/master/src/easeljs/display/Bitmap.js; http://www.h2database.com/html/license.html#summary; http://jsoncpp.sourceforge.net/LICENSE; http://
jdbc.postgresql.org/license.html; http://protobuf.googlecode.com/svn/trunk/src/google/protobuf/descriptor.proto; https://github.com/rantav/hector/blob/master/
LICENSE; http://web.mit.edu/Kerberos/krb5-current/doc/mitK5license.html; http://jibx.sourceforge.net/jibx-license.html; https://github.com/lyokato/libgeohash/blob/
master/LICENSE; https://github.com/hjiang/jsonxx/blob/master/LICENSE; https://code.google.com/p/lz4/; https://github.com/jedisct1/libsodium/blob/master/
LICENSE; http://one-jar.sourceforge.net/index.php?page=documents&file=license; https://github.com/EsotericSoftware/kryo/blob/master/license.txt; http://www.scala-
lang.org/license.html; https://github.com/tinkerpop/blueprints/blob/master/LICENSE.txt; http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/
intro.html; https://aws.amazon.com/asl/; https://github.com/twbs/bootstrap/blob/master/LICENSE; https://sourceforge.net/p/xmlunit/code/HEAD/tree/trunk/
LICENSE.txt; https://github.com/documentcloud/underscore-contrib/blob/master/LICENSE, and https://github.com/apache/hbase/blob/master/LICENSE.txt.
This product includes software licensed under the Academic Free License (http://www.opensource.org/licenses/afl-3.0.php), the Common Development and
Distribution License (http://www.opensource.org/licenses/cddl1.php) the Common Public License (http://www.opensource.org/licenses/cpl1.0.php), the Sun Binary
Code License Agreement Supplemental License Terms, the BSD License (http:// www.opensource.org/licenses/bsd-license.php), the new BSD License (http://
opensource.org/licenses/BSD-3-Clause), the MIT License (http://www.opensource.org/licenses/mit-license.php), the Artistic License (http://www.opensource.org/
licenses/artistic-license-1.0) and the Initial Developer’s Public License Version 1.0 (http://www.firebirdsql.org/en/initial-developer-s-public-license-version-1-0/).
This product includes software copyright © 2003-2006 Joe WaInes, 2006-2007 XStream Committers. All rights reserved. Permissions and limitations regarding this
software are subject to terms available at http://xstream.codehaus.org/license.html. This product includes software developed by the Indiana University Extreme! Lab.
For further information please visit http://www.extreme.indiana.edu/.
This product includes software Copyright (c) 2013 Frank Balluffi and Markus Moeller. All rights reserved. Permissions and limitations regarding this software are subject
to terms of the MIT license.
DISCLAIMER: Informatica LLC provides this documentation "as is" without warranty of any kind, either express or implied, including, but not limited to, the implied
warranties of noninfringement, merchantability, or use for a particular purpose. Informatica LLC does not warrant that this software or documentation is error free. The
information provided in this software or documentation may include technical inaccuracies or typographical errors. The information in this software and documentation
is subject to change at any time without notice.
NOTICES
This Informatica product (the "Software") includes certain drivers (the "DataDirect Drivers") from DataDirect Technologies, an operating company of Progress Software
Corporation ("DataDirect") which are subject to the following terms and conditions:
1. THE DATADIRECT DRIVERS ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
2. IN NO EVENT WILL DATADIRECT OR ITS THIRD PARTY SUPPLIERS BE LIABLE TO THE END-USER CUSTOMER FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, CONSEQUENTIAL OR OTHER DAMAGES ARISING OUT OF THE USE OF THE ODBC DRIVERS, WHETHER OR NOT INFORMED OF THE POSSIBILITIES
OF DAMAGES IN ADVANCE. THESE LIMITATIONS APPLY TO ALL CAUSES OF ACTION, INCLUDING, WITHOUT LIMITATION, BREACH OF CONTRACT, BREACH
OF WARRANTY, NEGLIGENCE, STRICT LIABILITY, MISREPRESENTATION AND OTHER TORTS.
The information in this documentation is subject to change without notice. If you find any problems in this documentation, please report them to us in writing at
Informatica LLC 2100 Seaport Blvd. Redwood City, CA 94063.
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.
4 Table of Contents
Preparing to Enable Kerberos Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Step 1. Determine the Kerberos Service Principal Level. . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Step 2. Configure the Kerberos Configuration File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Step 3. Create Kerberos Principal Accounts in Active Directory. . . . . . . . . . . . . . . . . . . . . 34
Step 4. Generate the Service Principal Name and Keytab File Name Formats. . . . . . . . . . . . . 35
Step 5. Generate the Keytab Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Step 6. Enable Delegation for the Kerberos Principal User Accounts in Active Directory. . . . . . 44
Enabling Kerberos Authentication in a Domain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Step 1. Enable Kerberos Authentication in the Domain. . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Step 2. Update the Nodes in the Domain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Enabling Kerberos on Informatica Nodes and Client Hosts. . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Step 1. Copy the Keytab Files to the Informatica Nodes. . . . . . . . . . . . . . . . . . . . . . . . . . 48
Step 2. Enable Kerberos Authentication for Informatica Clients. . . . . . . . . . . . . . . . . . . . . 49
Enabling User Accounts to Use Kerberos Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Step 1. Import User Accounts from Active Directory into an LDAP Security Domain. . . . . . . . . 50
Step 2. Migrate Native User Privileges and Permissions to the Kerberos Security Domain. . . . 55
Table of Contents 5
SAML Authentication Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Web Application User Experience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
SAML Authentication Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Before You Enable SAML Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Step 1. Create a Security Domain for Web Application User Accounts. . . . . . . . . . . . . . . . . 84
Step 2. Export the Certificate from AD FS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Step 3. Import the Certificate into the Truststore Used for SAML Authentication. . . . . . . . . . 90
Step 4. Configure Active Directory Federation Services. . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Step 5. Add Informatica Web Application URLs to AD FS. . . . . . . . . . . . . . . . . . . . . . . . . . 98
Step 6. Enable SAML Authentication in the Domain. . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Step 7: Enable SAML Authentication on the Gateway Nodes. . . . . . . . . . . . . . . . . . . . . . . 103
6 Table of Contents
Assigning Native Users to Native Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Assigning LDAP Users to Native Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Enabling and Disabling User Accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Deleting Native Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
LDAP Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Unlocking a User Account. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Increasing System Memory for Many Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Viewing User Activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Managing Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Adding a Native Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Editing Properties of a Native Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Moving a Native Group to Another Native Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Deleting a Native Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
LDAP Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Managing Operating System Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Operating System Profile Properties for the PowerCenter Integration Service . . . . . . . . . . . 128
Operating System Profile Properties for the Data Integration Service. . . . . . . . . . . . . . . . . 130
Creating an Operating System Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Editing an Operating System Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Assigning a Default Operating System Profile to a User or Group. . . . . . . . . . . . . . . . . . . 133
Deleting an Operating System Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Working with Operating System Profiles in a Secure Domain. . . . . . . . . . . . . . . . . . . . . . 133
Working with Operating System Profiles in a Domain with Kerberos Authentication. . . . . . . . 134
Account Lockout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Configuring Account Lockout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Rules and Guidelines for Account Lockout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Table of Contents 7
Model Privilege Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Security Privilege Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Model Repository Service Privileges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
PowerCenter Repository Service Privileges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Tools Privilege Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Folders Privilege Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Design Objects Privilege Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Sources and Targets Privilege Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Run-time Objects Privilege Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Global Objects Privilege Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
PowerExchange Listener Service Privileges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
PowerExchange Logger Service Privileges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Scheduler Service Privileges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Test Data Manager Service Privileges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Administration Privilege Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Connections Privilege Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Data Domains Privilege Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Data Masking Privilege Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Data Subset Privilege Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Policies Privilege Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Projects Privilege Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Rules Privilege Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Data Generation Privilege Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Managing Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
System-Defined Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Custom Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Assigning Privileges and Roles to Users and Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Inherited Privileges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Assigning Privileges and Roles to a User or Group by Navigation. . . . . . . . . . . . . . . . . . . 182
Viewing Users with Privileges for a Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Troubleshooting Privileges and Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
8 Table of Contents
Assigning Permissions on a Connection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Viewing Permission Details on a Connection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Editing Permissions on a Connection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Cluster Configuration Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Application and Application Object Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Types of Application and Application Object Permissions. . . . . . . . . . . . . . . . . . . . . . . . 195
Assigning Permissions on an Application or Application Object. . . . . . . . . . . . . . . . . . . . 196
Viewing Permission Details on an Application or Application Object. . . . . . . . . . . . . . . . . 196
Editing Permissions on an Application or Application Object. . . . . . . . . . . . . . . . . . . . . . 196
Denying Permissions on an Application or Application Object. . . . . . . . . . . . . . . . . . . . . . 197
SQL Data Service Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Types of SQL Data Service Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Assigning Permissions on an SQL Data Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Viewing Permission Details on an SQL Data Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Editing Permissions on an SQL Data Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Denying Permissions on an SQL Data Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Column Level Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Web Service Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Types of Web Service Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Assigning Permissions on a Web Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Viewing Permission Details on a Web Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Editing Permissions on a Web Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Table of Contents 9
infacmd oie Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
infacmd ps Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
infacmd pwx Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
infacmd rms Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
infacmd rtm Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
infacmd sch commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
infacmd sql Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
infacmd wfs Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
pmcmd Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
pmrep Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
10 Table of Contents
Preface
The Informatica Security Guide contains information about security in the Informatica domain. It contains
information that you need to manage security for the Informatica domain and the Informatica clients that
connect to the domain. This book assumes that you have knowledge of the Informatica domain and the
Informatica Administrator. It also assumes that you are familiar with the authentication servers and
processes for your network.
Informatica Resources
Informatica Network
Informatica Network hosts Informatica Global Customer Support, the Informatica Knowledge Base, and other
product resources. To access Informatica Network, visit https://network.informatica.com.
To access the Knowledge Base, visit https://kb.informatica.com. If you have questions, comments, or ideas
about the Knowledge Base, contact the Informatica Knowledge Base team at
KB_Feedback@informatica.com.
Informatica Documentation
To get the latest documentation for your product, browse the Informatica Knowledge Base at
https://kb.informatica.com/_layouts/ProductDocumentation/Page/ProductDocumentSearch.aspx.
If you have questions, comments, or ideas about this documentation, contact the Informatica Documentation
team through email at infa_documentation@informatica.com.
11
Informatica Product Availability Matrixes
Product Availability Matrixes (PAMs) indicate the versions of operating systems, databases, and other types
of data sources and targets that a product release supports. If you are an Informatica Network member, you
can access 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. Developed from the real-world experience of hundreds of data management projects, Informatica
Velocity represents the collective knowledge of our consultants who have worked with organizations from
around the world to plan, develop, deploy, and maintain successful data management solutions.
If you are an Informatica Network member, you can access Informatica Velocity resources at
http://velocity.informatica.com.
If you have questions, comments, or ideas about Informatica Velocity, contact Informatica Professional
Services at ips@informatica.com.
Informatica Marketplace
The Informatica Marketplace is a forum where you can find solutions that augment, extend, or enhance your
Informatica implementations. By leveraging any of the hundreds of solutions from Informatica developers
and partners, you can improve your productivity and speed up time to implementation on your projects. You
can access Informatica Marketplace at https://marketplace.informatica.com.
To find your local Informatica Global Customer Support telephone number, visit the Informatica website at
the following link:
http://www.informatica.com/us/services-and-training/support-services/global-support-centers.
If you are an Informatica Network member, you can use Online Support at http://network.informatica.com.
12 Preface
Chapter 1
Introduction to Informatica
Security
This chapter includes the following topics:
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:
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
13
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.
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.
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.
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
Use keytool to create an SSL certificate or a Certificate Signing Request (CSR) as well as keystores and
truststores in JKS format.
For more information about keytool, see the documentation on the following website:
http://docs.oracle.com/javase/7/docs/technotes/tools/windows/keytool.html
OpenSSL
You can use OpenSSL to create an SSL certificate or CSR as well as convert a keystore in JKS format to
PEM format.
For more information about OpenSSL, see the documentation on the following website:
https://www.openssl.org/docs/
The type of connection that you secure determines the files required.
Infrastructure Security 15
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.
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.
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.
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.
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.
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.
Security Domain 17
Chapter 2
User Authentication
This chapter includes the following topics:
The Informatica domain can use the following types of authentication to authenticate users in the
Informatica domain:
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.
18
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.
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.
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.
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.
Informatica does not support cross or multi-realm Kerberos authentication. The server host, client machines,
and Kerberos authentication server must be in the same 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.
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)
2.0 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.
Configure the LDAP security domains to store the list of users from an LDAP directory service that you want
to allow access to the Informatica domain and client applications. The LDAP security domain does not store
user account credentials. When a user logs in to an Informatica client, the Service Manager verifies that the
user account is in a security domain. If the user account belongs to an LDAP security domain, the Service
Manager authenticates the user with the LDAP directory service.
When you install Informatica services and you do not enable Kerberos authentication, the Informatica
installer creates the native security domain by default. After installation, you can add users and groups to the
native security domain. If you have users in an LDAP directory service that you want to give access to
Informatica client applications, you can set up LDAP security domains in addition to the native security
domain. Configure a connection to the LDAP server and import the users and groups into the LDAP security
domains.
When you install Informatica services and enable Kerberos authentication, the Informatica installer creates
an LDAP security domain with the name of the Kerberos realm that you specify during installation. After
installation, you can configure a connection to the LDAP server and import users and groups from the LDAP
directory service into the LDAP security domain. If you use Kerberos authentication, you cannot use the
Native security domain.
21
Setting Up an LDAP Security Domain
You can create an LDAP security domain for user accounts that you import from an LDAP directory service.
To organize different groups of users, you can create multiple LDAP security domains.
You create and manage LDAP users and groups in the LDAP directory service. Set up a connection to the
LDAP server and use search filters to specify the users and groups that can have access to the Informatica
domain. Then import the user accounts into LDAP security domains. If the LDAP server uses the SSL
protocol, you must also specify the location of the SSL certificate.
You can import users from the following LDAP directory services:
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, 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. You can also use the LDAP Configuration dialog box to set up a synchronization
schedule.
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.
If the LDAP server uses SSL, you must import the certificate into the cacerts truststore file on every gateway
node within the Informatica domain. See “Using a Self-Signed SSL Certificate” on page 26 for details.
To set up a connection to the LDAP directory service, perform the following tasks:
Property Description
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.
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. Leave blank for anonymous
login. For more information, see the documentation for the LDAP directory service.
Password Password for the principal user. Leave blank for anonymous login.
Not available if you use Kerberos authentication.
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.
To enable the Service Manager to recognize a self-signed certificate as valid, specify
the truststore file and password to use.
Not Case Sensitive Indicates that the Service Manager must ignore case sensitivity for distinguished
name attributes when assigning users to groups. Enable this option.
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 of100 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.
5. Click Test Connection to verify that the connection to the LDAP server is valid.
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: Unlike native user names, LDAP user names can be case-sensitive.
When you set up the LDAP directory service, you can use different attributes for the unique ID (UID). The
Service Manager requires a particular UID to identify users in each LDAP directory service. Before you
configure the security domain, verify that the LDAP directory service uses the required UID.
The following table lists the required UID for each LDAP directory service:
OpenLDAP uid
The Service Manager does not import the LDAP attribute that indicates that a user account is enabled or
disabled. You must enable or disable an LDAP user account in the Administrator tool. The status of the user
account in the LDAP directory service affects user authentication in application clients. For example, a user
account is enabled in the Informatica domain but disabled in the LDAP directory service. If the LDAP
directory service allows disabled user accounts to log in, then the user can log in to application clients. If the
LDAP directory service does not allow disabled user accounts to log in, then the user cannot log in to
application clients.
Note: 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.
Property Description
Security Domain Name of the LDAP security domain. The name is not case sensitive and must be
unique within the domain. It 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.
6. 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.
7. To add another LDAP security domain, repeat steps 4 through 6.
8. 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.
9. Click OK to save the security domains.
Important: Before you start the synchronization process, verify that the /etc/hosts file contains an entry for
the host name of the LDAP server. If the Service Manager cannot resolve the host name for the LDAP server,
the user synchronization can fail.
During synchronization, the Service Manager imports users and groups from the LDAP directory service. The
Service Manager deletes any user or group from the LDAP security domain that is no longer included in the
search filters used for the import.
Note: During synchronization, the Service Manager locks the user account that it synchronizes. When the user
account is locked, the Service Manager cannot authenticate the user account. Users might not be able to log
in to application clients. If users are logged in to application clients when synchronization starts, the users
might not be able to perform tasks. The duration of the synchronization process depends on the number of
users and groups to be synchronized. To avoid usage disruption, synchronize the security domains during
times when most users are not logged in. To synchronize more than 100 users or groups, enable paging on
the LDAP directory service before you run the synchronization. If you do not enable paging on the LDAP
directory service, the synchronization can fail.
To set up a schedule to synchronize the LDAP security domains with the LDAP directory service, perform the
following steps:
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.
1. In the LDAP Configuration dialog box, click the Security Domains tab.
The LDAP Configuration dialog box displays the list of security domains.
2. To ensure that you are deleting the correct security domain, click the security domain name to view the
filter used to import the users and groups and verify that it is the security domain you want to delete.
3. Click the Delete button next to a security domain to delete the security domain.
4. Click OK to confirm that you want to delete the security domain.
Kerberos Authentication
This chapter includes the following topics:
• Kerberos Overview, 28
• How Kerberos Works in an Informatica Domain, 29
• Preparing to Enable Kerberos Authentication, 31
• Enabling Kerberos Authentication in a Domain, 45
• Enabling Kerberos on Informatica Nodes and Client Hosts, 48
• Enabling User Accounts to Use Kerberos Authentication, 50
Kerberos Overview
Kerberos is a computer network authentication protocol that enables Informatica nodes 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.
You must complete multiple tasks before you enable Kerberos authentication. The tasks you must
complete include the following tasks:
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
Kerberos authentication during installation, you can use the Informatica command line programs to
configure the domain to use Kerberos authentication.
28
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.
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.
The Kerberos authentication protocol uses keytab files to authenticate Informatica clients with services that
run within the domain, including node processes, web application processes, and Informatica application
services. A keytab contains the service principal name (SPN) that identifies the service within the Kerberos
realm. The keytab also contains the encrypted 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
same key is stored in a keytab file on the node on which the service runs. The requested service uses the key
to decrypt the service ticket.
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.
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.
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.
1. Configure the following Kerberos library properties in the libdefaults section of the file.
Property Description
default_realm Name of the Kerberos realm to which the Informatica domain services belong. The realm
name must be in uppercase. 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.
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.
Property Description
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 content of a Kerberos configuration file with the required properties:
[libdefaults]
default_realm = COMPANY.COM
forwardable = true
rdns = false
renew_lifetime = 7d
ticket_lifetime = 24h
udp_preference_limit = 1
[realms]
KERBREALM.COM = {
admin_server = KDC01.COMPANY.COM:749
kdc = KDC01.COMPANY.COM:88
}
[domain_realm]
.company.com = COMPANY.COM
company.com = COMPANY.COM
For more information about the Kerberos configuration file, see the Kerberos network authentication
documentation.
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 following image shows the AES 128-bit encryption option selected in the account properties dialog box
for the nodeuser01 user account in Active Directory:
The accounts that you create depend on whether you enable Kerberos at the node level or at the process
level.
Create the following Kerberos principal accounts in Active Directory if you enable Kerberos at the node level:
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.
Create an LDAP bind user account that you use to synchronize the LDAP security domain that contains
Kerberos user accounts with Active Directory.
Create the following Kerberos principal accounts in Active Directory if you enable Kerberos at the process
level:
Node processes
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.
Create an account for the Administrator tool on each gateway node in the domain.
Create an account for every Informatica application service that runs on each node in the domain.
Create an LDAP user account that you use to synchronize the LDAP security domain that contains
Kerberos user accounts with Active Directory.
Step 4. 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.
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:
<Informatica installation directory>\tools\Kerberos
On a UNIX Informatica node host, go to the directory that contains the SPNFormatGenerator.sh shell file:
<Informatica installation directory>/tools/Kerberos
2. Run SPNFormatGenerator.bat or SPNFormatGenerator.sh.
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 as defined in the Kerberos configuration file. The realm name
Name must be in uppercase.
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.
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.
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 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:
<Informatica installation directory>\tools\Kerberos
On a UNIX Informatica node host, go to the directory that contains the SPNFormatGenerator.sh shell file:
<Informatica installation directory>/tools/Kerberos
2. Run SPNFormatGenerator.bat or SPNFormatGenerator.sh.
3. Click Next.
4. Select Process 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 as defined in the Kerberos configuration file. The realm name
Name must be in uppercase.
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.
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.
Entity Name
Identifies the node or service associated with the process.
Format for the name of the keytab file to be created for the associated SPN. The keytab file name is
case sensitive.
NODE_AC_SPN _AdminConsole.keytab
NODE_HTTP_SPN webapp_http.keytab
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.
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.
-mapuser The Active Directory user account to associate with the SPN.
-pass The password set in Active Directory for the Active Directory user account, if applicable.
The keytab files you generate depends on whether you enable Kerberos at the node level or at the process
level.
The following table shows the association between the Kerberos principal user accounts and the SPNs
shown in the example SPNKeytabFormat.txt file:
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.
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/US001DEV.company.com@COMPANY.COM -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 <principal name>@KERBEROS_REALM. The file name of the
keytab file must be infa_ldapuser.keytab.
The following example creates a keytab file for a service principal user account named ldapuser:
ktpass.exe -out infa_ldapuser.keytab -princ ldapuser@COMPANY.COM -mapuser ldapuser -
crypto all -ptype KRB5_NT_PRINCIPAL
The following table shows the association between the Kerberos principal user accounts and the SPNs
shown in the example SPNKeytabFormat.txt file:
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.
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/US001DEV.company.com@COMPANY.COM -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.
The following example creates a keytab file for a Kerberos principal user account named
admintooluser01:
ktpass.exe -out _AdminConsole.keytab -princ _AdminConsole/node01/InfaDomain@COMPANY.COM -
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/US001DEV.company.com@COMPANY.COM -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 principal_name@KERBEROS_REALM. The file name of the
keytab file must be infa_ldapuser.keytab.
The following example creates a keytab file for a service principal user account named ldapuser:
ktpass.exe -out infa_ldapuser.keytab -princ ldapuser@COMPANY.COM -mapuser ldapuser -
crypto all -ptype KRB5_NT_PRINCIPAL
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.
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 <keytab file name>
The following output example shows the principals in a keytab file:
Keytab name: FILE:node01.keytab
KVNO Timestamp Principal
---- ----------------- --------------------------------------------------------
3 12/31/16 19:00:00 MRS_dev/node01/InfaDomain@COMPANY.COM
3 12/31/16 19:00:00 MRS_dev/node01/InfaDomain@COMPANY.COM
3 12/31/16 19:00:00 MRS_dev/node01/InfaDomain@COMPANY.COM
3 12/31/16 19:00:00 MRS_dev/node01/InfaDomain@COMPANY.COM
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.
The following image shows the Delegation tab in the nodeuser01 account properties dialog box:
For information on how to enable Kerberos authentication when you install the Informatica services, see the
Informatica 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.
You run the infasetup switchToKerberosMode command on a gateway node within the domain to change the
authentication to Kerberos network authentication.
The infasetup command creates an administrator user account in an LDAP security domain with the name
_infaInternalNamespace. Specify one of the user accounts you created in Active Directory as the
administrator account. You use the account to log in to your Windows network after you enable Kerberos
authentication in the domain.
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:
<Informatica installation directory>\isp\bin
3. Run the following command:
infasetup switchToKerberosMode -ad <administrator name> -srn <Kerberos realm name> -
urn <Kerberos realm name> -spnSL <service principal level>
The following table describes the options and arguments for the infasetup switchToKerberosMode
command:
The following example changes the domain authentication to Kerberos and sets the nodeuser01 user
account as the administrator account:
infasetup switchToKerberosMode -ad nodeuser01 -srn EXAMPLE.COM -urn EXAMPLE.COM –
spnSL NODE
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:
<Informatica installation directory>\isp\bin
2. To set the Kerberos authentication parameters on a gateway node, run the following command:
infasetup UpdateGatewayNode -krb <true|false> -srn <Kerberos realm name> -urn
<Kerberos realm name>
To set the Kerberos authentication parameters on a worker node, run the following command:
infasetup UpdateWorkerNode -krb <true|false> -srn <Kerberos realm name> -urn
<Kerberos realm name>
The keytab files you copy depends on whether you enable Kerberos authentication at the node level or at the
process level.
The following table shows the node to which to copy each keytab file:
<application service name>.keytab Copy each file to the corresponding node on which the Informatica application
service runs.
After you configure the Informatica domain to run with Kerberos authentication, perform the following tasks
on the Informatica client tools:
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 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.
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.
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.
1. Start the domain and all Informatica services. Start the services in the following order:
• Model Repository Service
• Data Integration Service
• Analyst Service
• Content Management Service
• PowerCenter® Repository Service
• PowerCenter® Integration Service
• Metadata Manager Service
Property Description
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.
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.
The following image shows the ldapuser user account specified with the connection details for an Active
Directory server set in the LDAP Connectivity panel of the LDAP Configuration dialog box:
8. In the LDAP Configuration dialog box, click the Security Domains tab.
9. Click Add.
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.
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.
Option Description
-SecurityDomain LDAP security domain of the administrator account used to connect to the domain.
-sdn Specify _infaInternalNamespace.
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_<date>_<time>.txt in the
directory where you run the command.
Domain Security
This chapter includes the following topics:
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.
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
57
• 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, and the
browser
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.
After you secure the domain, configure the Informatica client applications to work with a secure domain.
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:
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 must have a keystore in PEM format named infa_keystore.pem and a keystore in JKS format
named infa_keystore.jks.
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 must have a truststore in PEM format named infa_keystore.pem and a keystore in JKS format
named infa_keystore.jks.
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:
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.
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.
-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.
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:
-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.
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: <Informatica installation directory>\clients
\shared\security
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:
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.
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.
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.
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
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:
-DatabaseTruststoreLocation database_truststore_l Required. Path and file name of the truststore file
-dbtl ocation that contains the SSL certificate for the database.
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.
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.
-DatabaseTlsEnabled database_tls_enabled Required. Indicates the database used for the domain
-dbtls configuration repository is a secure database. Set
this option to True.
If you have multiple gateway nodes in the domain, run infasetup UpdateGatewayNode on each gateway
node.
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.
The Model Repository Service connects to the Model repository database through JDBC drivers.
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: <InformaticaInstallationDirectory>/tomcat/bin
TrustStorePassword
Required. Password for the truststore file for the secure database.
Note: Informatica appends the secure JDBC parameters to the JDBC connection string. If you include the
secure JDBC parameters directly to the connection string, do not enter any parameter in the Secure
JDBC Parameters field.
5. Test the connection to verify that the connection to the secure repository database is valid.
6. Complete the process to create a Model Repository Service.
In addition, if you run PowerCenter sessions on a grid, you can enable an option to secure the data
communication between the DTM processes.
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.
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.
You can secure the connection between the Administrator tool and the browser.
You can secure the connection between the following web application services and the browser:
• Analyst Service
• Metadata Manager Service
• Test Data Manager Service
• Web Services Hub Console Service
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.
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 must be in a directory that is accessible to the Administrator tool and the command line
programs.
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
-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.
If you have multiple gateway nodes in the domain, run the command on each gateway node.
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.
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.
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.
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 249
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.
• 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.
1. Download the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 8 archive.
2. Shut down the domain.
3. Go to the following directory on the domain node:
<Informatica installation directory>\java\jre\lib\security\
4. Replace the following JAR files with the JAR files extracted from the archive:
• local_policy.jar
• US_export_policy.jar
5. Restart the domain.
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
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.
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:
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
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.
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.
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.
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.
By default, the installer creates the following directory within the Informatica installation directory to store
the encryption key: <INFA_HOME>/isp/config/keys
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:
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 <Informatica
installation directory>/isp/config directory to assign the following permissions: rwx-wx---. You can
then copy the encryption key file from the /keys subdirectory to another directory.
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.
Use the infasetup command to generate an encryption key and configure the domain to use the new
encryption key.
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:
-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
-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.
-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.
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 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:
Analyst Service (HTTPS) No default port. Enter the required port number when you create the service.
The following table lists the default port associated with the Content Management Service:
Content Management Service (HTTPS) No default port. Enter the required port number when you create the
service.
The following table lists the default port associated with the Data Integration Service:
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.
Human Task database No default port. Enter the database port number.
The following table lists the default port associated with the Metadata Manager Service:
Metadata Manager Service (HTTPS) No default port. Enter the required port number when you create the
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.
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.
The following table lists the default port associated with the Web Services Hub Service:
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)
2.0 is the identity provider, which authenticates web application users with your organization's LDAP or
Active Directory identity store.
Note: SAML authentication cannot be used in an Informatica domain configured to use Kerberos
authentication.
82
4. AD FS creates a session for the user and sends a SAML assertion token containing security-related
information about the user to the web application.
5. The application validates the assertion.
A user logs in to an Informatica web application enabled to use SAML authentication through an LDAP
security domain containing Informatica web application user accounts. The user's credentials are sent in a
SAML authentication request to AD FS, which authenticates the user.
Subsequent authentication is managed through session cookies set in the web browser during the initial
authentication. The authenticated user can access another Informatica web application configured to use
SAML authentication in the same browser session by selecting the LDAP security domain on the application
log in page. The user does not need to supply a user name or password.
When authentication is complete, the user remains logged in to all Informatica web applications that are
running in the same browser session. If AD FS is configured to issue persistent cookies, the user remains
logged in after closing and restarting the browser.
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.
Users not enabled to use SAML authentication select the native security domain on the web application log in
page, and then provide the user name and password for the native account.
To configure SAML authentication for supported Informatica web applications, perform the following tasks:
1. Create an LDAP security domain for Informatica web application user accounts, and then import the
users into the domain from Active Directory.
2. Export the Identity Provider Assertion Signing Certificate from AD FS.
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.
4. Add Informatica as a relying party trust in AD FS and map LDAP attributes to the corresponding types
used in security tokens issued by AD FS.
5. Add the URL for each Informatica web application to AD FS.
6. Enable SAML authentication in the Informatica domain.
7. Enable SAML authentication on every gateway node in the domain.
To ensure that the Informatica domain can use SAML authentication, validate the following requirements:
Verify that the required services are deployed and configured on the Windows network.
Ensure the Informatica web application services use secure HTTPS connections.
By default, AD FS requires that web application URLs use the HTTPS protocol.
Ensure that the system clocks on the AD FS host and all gateway nodes in the domain are synchronized.
The lifetime of SAML tokens issued by AD FS is set according to the AD FS host system clock. Ensure
that the system clocks on the AD FS host and all gateway nodes in the domain are synchronized.
To avoid authentication issues, 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 120 seconds of a gateway node's system time by default.
You must import the LDAP accounts for all users that use SAML authentication to access the Administrator
tool, the Analyst tool, and the Monitoring tool into the security domain. After importing the accounts into the
domain, assign the appropriate Informatica domain roles, privileges and permissions to the accounts within
the LDAP security domain.
1. In the Administrator tool, click the Users tab, and then select the Security view.
2. Click the Actions menu and select LDAP Configuration.
The LDAP Configuration dialog box opens.
3. Click the LDAP Connectivity tab.
4. Configure the connection properties for the Active Directory server.
The following table describes the server connection properties:
Property Description
Port Listening port for the server. The default value is 389.
Name Distinguished name (DN) for the principal LDAP 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 directory service.
Use SSL Indicates that the LDAP server uses the Secure Socket Layer (SSL) protocol.
Certificate If the LDAP server uses SSL, you must import the certificate into a truststore file on every
gateway node within the Informatica domain. You must also set the INFA_TRUSTSTORE and
INFA_TRUSTSTORE_PASSWORD environment variables if you do not import the certificate
into the default Informatica truststore.
Trust LDAP Determines whether the Service Manager can trust the SSL certificate of the LDAP server. If
Certificate 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 Indicates that the Service Manager must ignore case sensitivity for distinguished name
Sensitive attributes when assigning users to groups. Enable this option.
Group Name of the attribute that contains group membership information for a user. This is the
Membership attribute in the LDAP group object that contains the distinguished names (DNs) of the users
Attribute 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.
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.
The default value is 1000.
5. Click Test Connection to verify that the connection to the Active Directory server is valid.
6. Click the Security Domains tab.
7. Click Add to create a security domain.
8. Enter the security domain properties.
The following table describes the security domain properties:
Property Description
Security Name of the LDAP security domain. The name is not case sensitive and must be unique within the
Domain domain. The name 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 Distinguished name (DN) of the entry that serves as the starting point to search for user names in
search the LDAP directory service. The search finds an object in the directory according to the path in the
base distinguished name of the object.
In 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 Active Directory. The
filter can specify attribute types, assertion values, and matching criteria.
For Active Directory, format the query sting as:
sAMAccountName=<account>
Group Distinguished name (DN) of the entry that serves as the starting point to search for group names
search in Active Directory.
base
Group filter An LDAP query string that specifies the criteria for searching for groups in the directory service.
The following image shows the properties for an LDAP security domain named SAML_USERS set in the
Security Domains panel of the LDAP Configuration dialog box. The user filter is set to import all users
beginning with the letter "s".
The certificate is a standard X.509 certificate used to sign the assertions within the SAML tokens that AD FS
issues to Informatica web applications. You can generate a self-signed Secure Sockets Layer (SSL)
certificate for AD FS, or you can get a certificate from a certificate authority and import it into AD FS.
6. Click Next.
7. Enter the certificate file name and the location to export it to, and click Next.
8. Click OK, and then click Finish to complete the export.
Step 3. Import the Certificate into the Truststore Used for SAML
Authentication
Import the assertion signing certificate 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.
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:
<Informatica installation directory>\java\jre\bin
3. From the command line, run the following command:
keytool -importcert -alias <certificate alias name> -file <certificate path>\<certificate
filename> -keystore <path to infa_truststore.jks> -storepass <keystore password>
Include the password for the truststore file.
4. Restart the node.
• Add Informatica as a relying party trust in AD FS. The relying party trust definition enables AD FS to accept
authentication requests from Informatica web applications.
• 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 AD FS.
6. Click Next
7. Enter "Informatica" as the display name, and then click Next.
9. Click Next.
Skip the certificate configuration panel in the wizard.
You provide the URL for an Informatica web application to enable AD FS to accept authentication requests
sent by the application. Providing the URL also enables AD FS to send the SAML token to the application after
authenticating the user.
You do not need to add the URL for the Administrator tool, because you already entered it as part of
configuring AD FS.
6. Enter the complete URL for a supported Informatica web application, and then click OK.
Repeat this procedure for each web application.
You can enable SAML authentication and specify the identity provider URL when you configure the
domain as part of the installation process.
Use the infasetup defineDomain command to enable SAML authentication when you create a domain.
Specify the identity provider URL as the value for the -iu option. The following example shows the command
usage:
-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.
- clock_skew_toler Optional. The allowed time difference between the Active Directory
ClockSkewToleran ance_in_seconds Federation Services (AD FS) host system clock and the master gateway
ce node's system clock.
-cst The lifetime of SAML tokens issued by AD FS by is set according to the AD
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.
The following example shows the SAML options as the final six options at the command prompt:
-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.
- clock_skew_toler Optional. The allowed time difference between the Active Directory
ClockSkewToleran ance_in_seconds Federation Services (AD FS) host system clock and the master gateway
ce node's system clock.
-cst The lifetime of SAML tokens issued by AD FS by is set according to the AD
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.
You set this URL as the value for the -iu option when you run the infasetup updateDomainSamlConfig
command or the infasetup defineDomain command. Use Windows PowerShell on the AD FS server to get the
URL.
1. Open the Windows PowerShell command prompt window on the AD FS server. Select the Run as
administrator option when you open the command prompt.
2. Type the following command at the Windows PowerShell command prompt:
Get-ADFSEndpoint
3. Find the FullUrl value returned for the SAML 2.0/WS-Federation protocol, as shown in the following
image:
Select one of the following options to configure SAML authentication on a gateway node:
Use the infasetup DefineGatewayNode command to enable SAML authentication on the gateway node.
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.
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:
- 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.
Security Management in
Informatica Administrator
This chapter includes the following topics:
• 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.
• Domain administrative tasks. Manage logs, domain objects, and user permissions.
• Security administrative tasks. Manage users, groups, roles, and privileges.
• 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.
• Monitor. View the status of profile jobs, preview jobs, mapping jobs, SQL data services, and web services
for each Data Integration Service.
• Monitor. View and monitor Ultra Messaging deployments.
• Logs. View log events for the domain and services within the domain.
• Reports. Run a Web Services Report or License Management Report.
104
• Security. Manage users, groups, roles, and privileges.
• Cloud. View information about your Informatica Cloud® organization.
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 some application services control user security in
application clients. Application clients include Informatica Administrator and Informatica Developer. The
Service Manager and some application services control user security in application clients. Application client
includes Informatica Administrator.
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:
You can also use HTTPS for secure connection to the domain and the application services. The following
application services support HTTPS connection along with the Informatica domain:
You can also use HTTPS for secure connection to the domain and the application services.
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.
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.
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.
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.
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.
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:
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.
• 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.
The Service Manager synchronizes the user and group information between the repositories and the domain
configuration database when the following events occur:
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.
Note: If you have PowerCenter Express Personal Edition, you do not have access to the Security tab
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.
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.
• 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.
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,
or roles. Select an object in the Navigator and click the Actions menu to display the create, delete, and
move options.
• Right-click an object. Right-click an object in the Navigator to display the create, delete, and move 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
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.
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.
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
• Metadata Manager
• Informatica Developer
• Informatica Analyst
A user with an account in the Informatica domain can log in to the following application clients:
• Informatica Administrator
• Informatica Developer
A user with an account in the Informatica domain can log in to Informatica Administrator.
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
authentication uses LDAP security domains which contain users and groups imported from the LDAP
directory service.
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.
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.
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.
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.
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://<fully qualified host name>:<port>/passwordchange/
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.
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.
You can configure secure communication between services within the domain.
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.
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.
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, node, license, database
connections, 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.
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.
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
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.
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.
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.
Note: If you install PowerCenter Express Personal Edition you must use the default administrator account for
all operations. You cannot create users or groups and manage permissions.
• 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.
• 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.
113
• 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.
• 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.
• 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.
• Account lockout. You can configure account lockout to lock a user account when the user specifies an
incorrect login in the Administrator tool or the Developer tool. You can also unlock a user account.
• Account lockout. You can configure account lockout to lock a user account when the user specifies an
incorrect login in the Administrator 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.
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.
• Default administrator
• Domain administrator
• Application client administrator
• User
An Informatica domain can have the following types of accounts:
• Default administrator
• Domain administrator
• Application client administrator
• User
The Informatica domain has a default administrator account.
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.
• Create, configure, and manage all objects in the domain, including nodes, application services, and
administrator and user accounts.
The default administrator is a user account in the native security domain. You cannot create a default
administrator. 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.
The domain administrator can log in to the Administrator tool 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.
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.
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.
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.
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.
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.
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.
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 create, edit, and delete users depending on the type of PowerCenter Express license. You can assign
roles, permissions, and privileges to a user account. The roles, permissions, and privileges assigned to the
user determines the tasks the user can perform within the Informatica domain. If you have the PowerCenter
Express Personal Edition, you cannot create users or groups. You must use the default Administrator user to
perform all tasks.
You can create, edit, and delete users depending on the type of license. You can assign roles, permissions,
and privileges to a user account. The roles, permissions, and privileges assigned to the user determines the
tasks the user can perform within the Informatica domain.
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.
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:
<>“
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:
<>“
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. 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 delete the default administrator account. When you log in to the Administrator tool, you cannot
delete your user account.
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."
If the Deleted Users folder contains a folder with the same user name, Metadata Manager names the
additional folder "Copy (n) of <username>."
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.
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.
Includes user accounts in the Native security domain that are locked out.
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.
The number of users affects the processing time of the following commands:
• INFA_JAVA_OPTS. Determines the maximum heap size used by Informatica Services. Configure on each
node where Informatica Services is installed.
• 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:
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.
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.
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
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.
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"
Add the following parameter to the getUserActivityLog command to filter log events based on user or
security domain:
-usrs <UserName>:<SecurityDomain>
For example, add the following parameter to retrieve user activity for a user named User1 on all security
domains:
-usrs "User1:*"
Date and time
Optional. The range of dates you want to view log events for.
If you enter an end date that is before the start date, the command returns no log events.
• MM/dd/yyyy
• MM/dd/yyyy HH:mm:ss
• yyyy-MM-dd
Add the following parameter to the getUserActivityLog command to filter the log by start date or end
date:
-sd <start_date> -ed <end_date>
For example, add the following parameter to retrieve user activity between January 1, 2014 and February
3, 2014:
-sd 01/01/2014 -ed 02/03/2014
Activity code
Use the wildcard symbol (*) to retrieve log events for multiple activity codes. Valid activity codes include:
Add the following parameter to the getUserActivityLog command to filter by activity code:
-ac <activity_code>
For example, add the following parameter to retrieve log events that succeeded:
-ac CCM_10437
If you use the wildcard symbol, enclose the argument in quotation marks.
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 <activity_text>
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
• 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
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
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.
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.
You can assign roles, permissions, and privileges to a group. The roles, permissions, and privileges assigned
to the group determines the tasks that users in the group can perform within the Informatica domain.
You can assign roles, permissions, and privileges to a group. The roles, permissions, and privileges assigned
to the group determines the tasks that users in the group can perform within the Informatica domain.
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.
A native group can contain 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.
A native group can contain 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.
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:
<>“
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.
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.
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.
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.
$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.
$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.
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:
*?<>"|,[]
$DISTempDir Directory for temporary files created when jobs are run. It cannot include the following
special characters:
*?<>"|,[]
Default is <root directory>/disTemp.
$DISCacheDir Directory for index and data cache files for transformations. It cannot include the following
special characters:
*?<>"|,[]
Default is <root directory>/cache.
$DISSourceDir Directory for source flat files used in a mapping. It cannot include the following special
characters:
*?<>"|,[]
Default is <root directory>/source.
$DISTargetDir Directory for target flat files used in a mapping. It cannot include the following special
characters:
*?<>"|,[]
Default is <root directory>/target.
$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 <root directory>/reject.
$DISLogDir Directory for logs. It cannot include the following special characters:
*?<>"|,[]
Default is <root directory>/disLogs.
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.
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.
The Configure Operating System Profile - Step 2 of 3 dialog box appears.
5. Select one or both of the Integration Services that will use the operating system profile.
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.
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.
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.
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.
• 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.
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.
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.
• 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.
You can modify privileges and roles depending on the type of PowerCenter Express license.
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.
• Domain privileges. Determine actions on the Informatica domain that users can perform using the
Administrator tool.
137
• 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.
• 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.
• Data Integration Service privilege. Determines actions on applications that users can perform using the
Administrator tool. 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.
• Model Repository Service privilege. Determines actions on projects that users can perform using
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.
Privileges determine the actions that users can perform in application clients. Informatica includes domain
privileges that determine actions that users can perform using the Administrator tool.
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:
• 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.
• Tools. Includes privileges to log in to the Administrator tool.
• Monitoring. Includes privileges to monitor Ultra Messaging deployments and view statistics.
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.
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.
Domain Privileges
Domain privileges determine the actions that users can perform using the Administrator tool and the infacmd
and pmrep command line programs.
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.
Cloud Administration Includes privileges to add Informatica Cloud organizations in the Administrator tool and
view them.
Security Administration Includes privileges to manage users, groups, roles, and privileges.
Domain Administration Includes privileges to manage the domain, application services, connections, and cluster
configurations.
Some security management tasks are determined by the Administrator role, not by privileges or permissions.
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:
Note: To complete security management tasks in the Administrator tool, users must also have the Access
Informatica Administrator privilege.
The following table lists the required permissions and the actions that users can perform with the Grant
Privileges and Roles privilege:
Permission On Description
The Manage Users, Groups, and Roles privilege includes the Grant Privileges and Roles privilege.
Permission On Description
Operating system profile User is able to edit operating system profile properties.
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:
Permission On Description
Application service User can view application service properties and log events.
Web Services Hub User can run the Web Services Report.
The following table lists the required permissions and the actions that users can perform with the Manage
Service Execution privilege:
Permission On Description
Permission On Description
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
Original and destination User is able to move application services or license objects from one folder to
folders another.
Analyst Service User is able to create and delete audit trail tables.
Metadata Manager Service User is able to restore the PowerCenter repository for Metadata Manager.
PowerCenter Repository
Service
PowerCenter Integration User is able to run the PowerCenter Integration Service in safe mode.
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.
Permission On Description
Domain where application service runs, and any associated User is able to create application services.
application service
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 and nodes assigned to the User is able to create grids.
grid
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.
The following table lists the required permissions and the actions that users can perform with the Manage
Domain Folders privilege:
Permission On Description
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.
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.
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
Write on cluster configuration User is able to create, refresh, and delete cluster configurations. User is able to set
and clear cluster configuration properties.
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 Model Repository
Service that is configured for monitoring.
View View Reports Domain User can view reports for domain objects.
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 Jobs Domain User can perform the following actions:
- Abort jobs.
- Reissue mapping jobs.
- View job logs.
Users do not need the Access Informatica Administrator privilege to access the Monitoring tool.
The following table lists the required permissions and the actions that users can perform with the privilege in
the Tools group:
Privilege Description
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.
The following table lists the required permissions and the actions that users can perform with the privileges
in the Cloud Administration group:
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.
The following table lists the privileges and permissions required to manage projects and objects in projects:
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.
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.
The following table lists the privileges and permissions required to manage reference tables:
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.
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 Developer tool.
The following table lists the actions that users can perform with the privilege in the Application
Administration privilege group:
The following table lists the required permissions and the actions that users can perform with the privilege in
the Profiling Administration privilege group:
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.
The following table lists the privileges in the Catalog privilege group and the permissions required to perform
a task on an object:
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 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.
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.
The following table lists the privileges and permissions required to manage an instance of a resource in the
Metadata Manager warehouse:
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.
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.
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:
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.
The Model Repository Service privileges determine actions that users can perform on projects using
Informatica Developer.
The Model repository object permissions determine the tasks that users can complete on objects in projects.
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 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.
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.
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 Developer N/A User can access the Model repository from the Developer tool.
Create, Edit, and Delete N/A User can perform the following actions:
Projects - Create projects.
- Upgrade the Model Repository Service.
Create, Edit, and Delete Write on project User can perform the following actions:
Projects - Edit projects.
- Delete projects if the user created the projects.
Show Security Details N/A User can view the following details:
- Names of projects for which users do not have read permission.
- Error and warning message details.
The following table describes each privilege group for the PowerCenter Repository Service:
Tools Includes privileges to access PowerCenter Client tools and command line programs.
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:
Access Designer - User is able to connect to the PowerCenter repository using the Designer.
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.
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.
Permission Description
Note: To perform actions on folders, users must also have the Access Repository Manager privilege.
The following table lists the required permissions and the actions that users can perform with the Create
Folders privilege:
Permission Description
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.
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.
• 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
Note: To perform actions on design objects, users must also have the appropriate privilege in the Tools
privilege group.
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
The Manage Design Object Versions privilege includes the Create, Edit, and Delete Design Objects 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.
• 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
Note: To perform actions on source and target objects, users must also have the appropriate privilege in the
Tools privilege group.
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
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.
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 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.
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
The Manage Run-time Object Versions privilege includes the Create, Edit, and Delete Run-time Objects
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.
The following table lists the required permissions and the actions that users can perform with the Monitor
Run-time Objects privilege:
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.
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.
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, 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.
• 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:
Permission Description
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 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.
The following table lists the required permissions and the actions that users can perform with the Create
Connections privilege:
Permission Description
The following table lists the required permissions and the actions that users can perform with the Manage
Deployment Groups privilege:
Permission Description
Read and Write on deployment group User is able to perform the following actions:
- Edit deployment groups.
- Remove objects from a deployment group.
Read and Write on destination folder User is able to roll back deployment groups.
The following table lists the required permissions and the actions that users can perform with the Execute
Deployment Groups privilege:
Permission Description
The following table lists the required permissions and the actions that users can perform with the Create
Labels privilege:
Permission Description
The following table lists the required permissions and the actions that users can perform with the Create
Queries privilege:
Permission Description
The following table describes the PowerExchange Listener Service privilege in the Informational Commands
privilege group:
The following table describes each PowerExchange Listener Service privilege in the Management Commands
privilege group:
The following table describes each PowerExchange Logger Service privilege in the Informational Commands
privilege group:
The following table describes each PowerExchange Logger Service privilege in the Management Commands
privilege group:
The following table describes the Scheduler Service privileges and required permissions:
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
View Schedules User can view the Schedules view and schedules. Scheduler Service
The following table describes each Test Data Manager privilege group:
Administration Includes privileges to create and manage connections, 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.
Data Subset Includes privileges to view and manage subset objects including entities, groups and templates 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.
Rules Includes privileges to view and manage masking and generation rules in the Test Data Manager.
Data Generation Includes privileges to view and manage test data generation in the Test Data Manager.
The following table lists the privileges in the Administration privilege group and the permissions required to
perform a task on an object:
Manage - Write User can perform the following actions on the Informatica
Preferences Administrator and Test Data Manager:
- Create roles.
- Edit roles.
- Delete roles.
- View roles.
- Associate roles to users.
- Associate privileges to users.
- Associate roles to user groups.
- Associate privileges to user groups.
- Add licenses.
- Set up the TDM repository.
- Set up the PowerCenter repository.
- Set up data domain sensitivity levels.
- Configure a test data warehouse repository.
- Configure a test data warehouse.
- Set up project custom attributes.
- Set up workflow generation attributes.
- Enable data discovery.
- Set up profiling services.
- View administration objects.
- Configure keyword search indexing options.
View - Read User can perform the following actions on the Connections page in
Connections the Test Data Manager:
- View connections.
- Test connections.
Manage View Write User can perform the following actions on the Connections page in
Connections Connections the Test Data Manager:
- Create connections.
- Edit connections.
- Delete connections.
- View connections.
- Test connections.
- Configure a test data warehouse repository.
- Configure a test data warehouse.
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.
The following table lists the privileges in the Data Domains privilege group and the permissions required to
perform a task on an object:
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.
The following table lists the privileges in the Data Masking privilege group and the permissions required to
perform a task on an object:
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.
The following table lists the privileges in the Data Subset privilege group and the permissions required to
perform a task on an object:
View Data - Read User can perform the following data subset actions in the Test Data
Subset Manager:
- View groups.
- View templates
- View entities.
- View recent project objects.
Manage Data View Data Write User can perform the following data subset actions in the Test Data
Subset Subset Manager:
- Create groups.
- Edit groups.
- Delete groups.
- Add group parameters.
- Create templates.
- Edit templates.
- Delete templates.
- Add template parameters.
- Create entity.
- Edit entity.
- Delete entity.
- Add entity criteria.
- Enable relationships.
- Disable relationships.
- Edit relationships
- Review and act on changes.
- Mark change review as complete.
The following table lists the privileges in the Policies privilege group and the permissions required to perform
a task on an object:
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.
The following table lists the privileges in the Projects privilege group and the permissions required to perform
a task on an object:
View Project - Read User can perform the following actions on projects in the Test Data
Manager:
- View projects.
- View plans.
- View plan detail reports.
- View plan audit reports.
- View recent projects.
- Create test data warehouse plans
- Manage test data warehouse plans
- Generate test data warehouse plans
- Execute test data warehouse plans
Manage View Project Write User can perform the following actions on projects in the Test Data
Project Manager:
- Create projects
- Edit projects.
- Delete projects
- View projects.
- Create parameters
- Edit parameters
- Delete parameters
- Associate users to projects.
- Associate user groups to projects.
- Associate or remove rules to projects.
- Associate or remove policies to projects
- Create plans.
- Edit plans.
- Delete plans.
- Generate plans.
Discover - Write User can perform the following discover actions on projects in the Test
Project Data Manager:
- Classify tables.
- Mark discovery as complete.
- Associate data domains to columns.
- Mark columns as restricted.
- Mark columns as sensitive
- Set similar value column
- Remove similar value columns
- Add primary keys
- Remove primary Keys
- Create logical constraints
- View logical constraints
- Edit logical Constraints
- Delete Logical Constraints
- View projects.
- View profiled data domains.
- Approve or reject profile data domains.
- Mark data domain classification as complete.
- View profiled primary keys.
- Approve or reject profiled primary keys.
- Mark primary key discovery as complete.
- View profiled entities.
- Approve or reject profiled entities.
- Mark entity discovery as complete.
- View project risk analysis.
- View recent project sensitive data distribution.
- Delete tables.
Generate - Write User can generate workflows in the Test Data Manager.
Project
Execute - Write User can perform the following execute actions on projects in the Test
Project Data Manager:
- Execute plans.
- Execute workflows.
- Stop workflows.
- Abort workflows.
- Recover workflows.
- View plan execution.
Monitor - Read User can perform the following monitor actions on projects in the Test
Project Data Manager:
- Monitor project jobs.
- View project job logs.
- Monitor jobs across projects.
- View job logs across projects.
Audit - Read User can view recent activity on projects and plans in the Test Data
Project Manager.
Import - Write User can perform the following actions on projects in the Test Data
Metadata Manager:
- Import sources.
- Delete sources.
- Delete tables.
The following table lists the privileges in the Data Masking privilege group and the permissions required to
perform a task on an object:
Manage Masking Rules View Masking Rules Write User can perform the
following actions on data
masking rules in the Test
Data Manager:
- Create masking rules.
- Edit masking rules.
- Delete masking rules.
- View masking rules.
Manage Generation Rules View Generation Rules Write User can perform the
following actions on data
generation rules in the
Test Data Manager:
- Create generation rules.
- Edit generation rules.
- Delete generation rules.
- View generation rules.
The following table lists the privileges in the Data Generation privilege group and the permissions required to
perform a task on an object:
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:
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.
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.
• Administrator. This is a system-defined role that has privileges to administer the Administrator tool. With
this role, you can create and manage user accounts, create the Ultra Messaging Service and configure it,
configure UMSM components, and UM deployments.
• Operator. This is a custom role that has privileges to monitor UM deployments.
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.
When you assign the Administrator role to a user or group for the domain, Analyst Service, Data Integration
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.
When you assign the Administrator role to a user or group for the domain, Data Integration Service, Model
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.
When you assign the Administrator role to a user or group for the domain or Ultra Messaging 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.
When you assign the Administrator role to a user or group for the domain or Ultra Messaging 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.
You can assign a user or group all privileges for the domain or Ultra Messaging Service and then grant the
user or group full permissions on all domain 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, and PowerCenter Repository Service:
Service Tasks
Data Integration Service - Upgrade the Data Integration Service using the Actions menu.
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.
Service Tasks
Custom Roles
A custom role is a role that you can edit or delete.
You can edit the privileges for these roles, or delete the roles. You can also create your own custom roles.
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: < > "
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.
• 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
• 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.
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:
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:
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 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.
Permissions
This chapter includes the following topics:
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.
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
185
Object Type Tool Description
Domain objects Administrator tool You can assign permissions on the following domain objects:
domain, folders, nodes, grids, licenses, application services, and
operating system profiles.
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.
Connection objects Administrator tool You can assign permissions on connections defined in the
Developer tool Administrator tool or Developer tool. These tools share the connection
permissions.
Domain objects Administrator tool You can assign permissions on the following domain objects: domain,
folders, node, and application services.
Model repository Developer tool You can assign permissions on projects defined in the Developer tool.
projects
You can use the Administrator tool to configure permissions on a domain object. You can assign permissions
on the following domain objects:
• domain
• node
• application services
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,
Permissions that users inherit. When users have permission on a domain, they inherit permission on all
objects in the domain. When groups have permission on a domain object, all subgroups and users
belonging to the group inherit permission on the domain object.
Permissions that users inherit. When users have permission on a domain, they inherit permission on all
objects in the domain. When groups have permission on a domain object, all subgroups and users
belonging to the group inherit permission on the domain object.
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.
When you manage permissions for a user or group, you can use the following search filters:
Security domain
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 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.
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.
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.
Node Enables Administrator tool users to view and edit the node properties.
Application Service Enables Administrator tool users to view and edit the application service properties.
License Enables Administrator tool users to view and edit the license properties.
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.
Node Enables Administrator tool users to view and edit the node properties.
Application Service Enables Administrator tool users to view and edit the application service properties.
License Enables Administrator tool users to view and edit the license properties.
• 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.
Note: If you revoke direct permission on an object, the user or group might still inherit permission from a
parent group or object.
Note: If you revoke direct permission on an object, the user or group might still inherit permission from a
parent group or object.
Note: If you revoke direct permission on an object, the user or group might still inherit permission from a
parent group or object.
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.
Note: You cannot assign permissions on the following connections: profiling warehouse, data object cache
database, or Model repository.
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.
Access the physical data in the underlying data source defined by the connection. Users can
preview data, run a mapping, run a mapping in a workflow Mapping task, or run a profile that uses
the connection.
• 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.
Note: If you revoke direct permission on an object, the user or group might still inherit permission from a
parent group or object.
You can configure permissions on a cluster configuration in the Administrator tool and the Informatica
command line interface.
• 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.
For information about cluster configuration permissions, refer to the Informatica Big Data Management
Administrator Guide.
You can configure application and application object permissions in the Administrator tool or from the
command line.
View permission
Grant permission
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.
Note: If you revoke direct permission on an object, the user or group might still inherit permission from a
parent group or object.
You can assign permissions to users and groups on the following SQL data service objects:
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.
• 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.
The following table describes the permissions for each SQL data service object:
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.
Note: If you revoke direct permission on an object, the user or group might still inherit permission from a
parent group or object.
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 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
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.
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.
• 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.
• 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:
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:
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.
Note: If you revoke direct permission on an object, the user or group might still inherit permission from a
parent group or object.
Audit Reports
This chapter includes the following topics:
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.
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.
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.
204
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.
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.
Full Name
Security Domain
Description
Email ID
Phone
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.
If you run the report for users, the report displays the list of users and the groups to which they belong.
Security Domain
Group Name
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.
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
Full Name
Security Domain
The User Group Association report displays the following information for the child groups that belong to the
group:
Group Name
Security Domain
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.
Object Name
Object Type
Roles Association
The Roles Association report displays a list of roles and the users and groups to which the roles are
assigned.
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
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.
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.
Object Type
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.
210
The following table lists the required privileges and permissions for infacmd as commands:
The following table lists the required privileges and permissions for infacmd cluster commands:
listAssociatedConnections - - -
listConfigurations - - -
listConfigurationGroupPermissions - - -
listConfigurationUserPermissions - - -
The following table lists the required privileges and permissions for infacmd dis commands:
CancelDataObjectCacheRe - - -
fresh
ListApplicationObjects - - -
ListApplications - - -
ListDataObjectOptions - - -
PurgeDataObjectCache - - -
RefreshDataObjectCache - - -
infacmd es commands
Users must be assigned the Administrator role for the domain to run the following infacmd es commands:
• ListServiceOptions
• UpdateServiceOptions
• UpdateSMTPOptions
Users must be assigned the Administrator role for the domain to run the following commands:
• AddDomainLink
• AssignGroupPermission (on domain)
• AssignGroupPermission (on operating system profiles)
• AddServiceLevel
• AssignUserPermission (on domain)
• AssignUserPermission (on operating system profiles)
• CreateConnection
• CreateOSProfile
• PurgeLog
• RemoveDomainLink
• RemoveOSProfile
• RemoveServiceLevel
• SwitchToGatewayNode
• SwitchToWorkerNode
• UpdateDomainOptions
• UpdateGatewayInfo
• UpdateServiceLevel
• UpdateSMTPOptions
The following table lists the required privileges and permissions for infacmd isp commands:
AddDomainLink - - -
AssignGroupPermission (on nodes and grids) Domain Manage Nodes Node or grid
Administration and Grids
AddServiceLevel - - -
ConvertLogFile - - Domain or
application service
CreateConnection - - -
CreateOSProfile - - -
DisableService (for Metadata Manager Service) Domain Manage Service Metadata Manager
Administration Execution Service and
associated
PowerCenter
Integration Service
and PowerCenter
Repository Service
DisableService (for all other application services) Domain Manage Service Application service
Administration Execution
EnableService (for Metadata Manager Service) Domain Manage Service Metadata Manager
Administration Execution Service, and
associated
PowerCenter
Integration Service
and PowerCenter
Repository Service
EnableService (for all other application services) Domain Manage Service Application service
Administration Execution
generateHadoopConnectionFromHiveConection - - -
GetFolderInfo - - Folder
GetLog - - Domain or
application service
GetNodeName - - Node
Help - - -
ListAlertUsers - - Domain
ListAllGroups - - -
ListAllRoles - - -
ListAllUsers - - -
ListConnections - - -
ListConnectionPermissions - - -
ListConnectionPermissions by Group - - -
ListConnectionPermissions by User - - -
ListDomainLinks - - Domain
ListDomainOptions - - Domain
ListFolders - - Folders
ListGridNodes - - -
ListGroupsForUser - - Domain
ListGroupPermissions - - -
ListNodeOptions - - Node
ListNodes - - -
ListNodeResources - - Node
ListPlugins - - -
ListRepositoryLDAPConfiguration - - Domain
ListRolePrivileges - - -
ListServiceLevels - - Domain
ListServicePrivileges - - -
ListServices - - -
ListSMTPOptions - - Domain
ListUserPermissions - - -
MoveObject (for application services or license Domain Manage Services Original and
objects) Administration destination folders
Ping - - -
PurgeLog - - -
RemoveDomainLink - - -
RemoveOSProfile - - -
RemoveServiceLevel - - -
SetRepositoryLDAPConfiguration - - Domain
SwitchToGatewayNode - - -
SwitchToWorkerNode - - -
UpdateDomainOptions - - -
UpdateGatewayInfo - - -
UpdateServiceLevel - - -
UpdateSMTPOptions - - -
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:
CreateProject Domain Administration Create, Edit and Delete The Model Repository
Projects Service
DeleteProject Domain Administration Create, Edit and Delete The Model Repository
Projects 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
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:
GetRequestLog - - -
ListMappings - - -
ListMappingParams - - -
The following table lists the required permissions for infacmd oie commands:
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:
CreateWH - - -
DropWH - - -
CreateWH - - -
DropWH - - -
The following table lists the required privileges and permissions for infacmd pwx commands:
The following table lists the required privileges and permissions for infacmd rms commands:
The following table lists the required privileges and permissions for infacmd rtm commands:
Deployimport - - -
The following table lists the required privileges and permissions for infacmd sch commands:
The following table lists the required privileges and permissions for infacmd sql commands:
ListColumnPermissions - - -
ListSQLDataServiceOptions - - -
ListSQLDataServicePermissions - - -
ListSQLDataServices - - -
ListStoredProcedurePermissions - - -
ListTableOptions - - -
ListTablePermissions - - -
PurgeTableCache - - -
RefreshTableCache - - -
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
• stoptask
• stopworkflow
• unscheduleworkflow
The following table lists the required privileges and permissions for pmcmd commands:
aborttask (started by other Run-time Objects Manage Execution Read and Execute on folder
users)
abortworkflow (started by Run-time Objects Manage Execution Read and Execute on folder
other users)
connect - - -
disconnect - - -
exit - - -
getserviceproperties - - -
help - - -
pingservice - - -
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)
setnowait - - -
setwait - - -
showsettings - - -
stoptask (started by other Run-time Objects Manage Execution Read and Execute on folder
users)
stopworkflow (started by Run-time Objects Manage Execution Read and Execute on folder
other users)
version - - -
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
AssignPermission - - -
ChangeOwner - - -
CheckIn (for your own Design Objects Create, Edit, and Read and Write on folder
checkouts) Delete
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 - - -
Connect - - -
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
DeleteQuery - - -
Exit - - -
Help - - -
ModifyFolder (to change Folders Manage Versions Read and Write on folder
status)
ObjectImport Design Objects Create, Edit, and Read and Write on folder
Delete
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 Sources and Targets 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)
Run - - -
ShowConnectionInfo - - -
SwitchConnection Run-time Objects Create, Edit, and Read and Write on folder
Delete Read on connection object
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
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)
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
UpdateTargPrefix Run-time Objects Create, Edit, and Read and Write on folder
Delete
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 - - -
Custom Roles
This appendix includes the following topics:
The following table lists the default privilege assigned to the Analyst Service Business Glossary Consumer
custom role:
240
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.
The following table lists the default privileges assigned to the Operator custom role:
PowerCenter Developer
The following table lists the default privileges assigned to the PowerCenter Developer custom role:
Folders - Copy
- Create
- Manage Versions
Test Engineer
The following table lists the default privileges assigned to the Test Engineer custom role:
• 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
249
• 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
B privileges 149
default administrator
Browse privilege group description 115
description 150 modifying 115
passwords, changing 115
deployment groups
251
dis groups (continued)
permissions by command 212 overview 108
privileges by command 212 parent group 126
domain privileges, assigning 181
administration privileges 141 roles, assigning 181
administrator 116 synchronization 107
Administrator role 178 valid name 126
privileges 139
security administration privileges 140
user security 111
user synchronization 107
I
users with privileges 182 IBM Tivoli Directory Server
Domain Administration privilege group LDAP authentication 22
description 141 Informatica Administrator
domain administrator Navigator 108
description 116 overview 104
domain objects searching 108
permissions 187 Security page 107
domain permissions tabs, viewing 104
direct 186 Informatica Analyst
effective 186 administrator 116
inherited 186 Informatica Developer
administrator 116
Informatica domain
E permissions 111
privileges 111
Edit Reference Table Metadata user security 111
privilege 148 users, managing 117
effective permission inherited permission
description 186 description 186
environment variables inherited privileges
INFA_TRUSTSTORE 63 description 181
INFA_TRUSTSTORE_PASSWORD 63 ipc
es permissions by command 213
permissions by command 213 privileges by command 213
privileges by command 213 isp
Everyone group permissions by command 214
description 114 privileges by command 214
F K
filters Kerberos authentication
getUserActivityLog 123 description 20
folders keytab 35
permissions 187 LDAP synchronization 50
privileges 155 node level 31
Folders privilege group overview 28, 29
description 155 process level 31
service principal accounts 34
service principal name 35
252 Index
LDAP directory service (continued) native groups (continued)
nested groups 26 editing 127
LDAP groups managing 126
importing 22 moving to another group 127
managing 126 users, assigning 119
LDAP security domain native security domain
description 19, 20 description 19
LDAP security domains native users
configuring 23 adding 118
deleting 27 assigning to groups 119
description 21 deleting 120
LDAP users editing 118
assigning to groups 119 enabling 119
enabling 119 managing 117
importing 22 passwords 118
managing 117 Navigator
licenses Security page 108
permissions 187 nested groups
Load privilege group LDAP authentication 26
description 151 LDAP directory service 26
login activity nodes
viewing 122 permissions 187
Novell eDirectory
LDAP authentication 22
M
mapping
inherited permissions 195
O
permissions 195 object queries
Metadata Manager privileges for PowerCenter 165
administrator 116 oie
Metadata Manager Service permissions by command 227
authorization 107 privileges by command 227
custom roles 241 OpenLDAP
privileges 149 LDAP authentication 22
user synchronization 107 operating system profile
users with privileges 182 creating 131
Metadata Manager Service privileges default 133
Browse privilege group 150 deleting 133
Load privilege group 151 editing 128
Model privilege group 152 managing 128
Security privilege group 152 properties, Data Integration Service 128, 130
Microsoft Active Directory properties, PowerCenter Integration Service 128
LDAP authentication 22 operating system profiles
Model privilege group permissions 187, 191
description 152 Operator}
Model Repository Service custom roles 242
authorization 107
privileges 152
user synchronization 107
users with privileges 182
P
Monitoring privilege group parent groups
domain 145 description 126
mrs password
permissions by command 224 changing for a user account 110
privileges by command 224 passwords
ms changing for default administrator 115
permissions by command 226 native users 118
privileges by command 226 requirements 118
permissions
application 195
Index 253
permissions (continued) privilege groups (continued)
domain objects 187 Security 152
effective 186 Security Administration 140
es commands 213 Sources and Targets 159
folders 187 Tools 147, 154
grids 187 privileges
inherited 186 Analyst Service 147
ipc commands 213 as commands 210
isp commands 214 assigning 181
licenses 187 cluster commands 211
mapping 195 command line programs 210
mrs commands 224 Content Management Service 148
ms commands 226 Data Integration Service 149
nodes 187 description 137
oie commands 227 design objects 157
operating system profiles 187, 191 dis commands 212
pmcmd commands 232 domain 139
pmrep commands 234 domain administration 141
ps commands 227 domain tools 147
pwx commands 228 es commands 213
rms commands 229 folders 155
rtm commands 230 Informatica Cloud Administration 147
sch commands 230 inherited 181
search filters 187 ipc commands 213
sql commands 231 isp commands 214
SQL data service 197 Metadata Manager Service 149
types 186 Model Repository Service 152
virtual schema 197 monitoring 145
virtual stored procedure 197 mrs commands 224
virtual table 197 ms commands 226
web service 201 oie commands 227
web service operation 201 pmcmd commands 232
wfs commands 232 pmrep commands 234
workflow 195 PowerCenter global objects 165
working with privileges 185 PowerCenter Repository Service 154
pmcmd PowerCenter Repository Service tools 154
permissions by command 232 PowerExchange Listener Service 167
privileges by command 232 PowerExchange Logger Service 168
pmrep ps commands 227
permissions by command 234 pwx commands 228
privileges by command 234 rms commands 229
PowerCenter Client rtm commands 230
administrator 116 run-time objects 161
PowerCenter Repository Service sch commands 230
Administrator role 178 Scheduler Service 169
authorization 107 security administration 140
custom roles 243 sources 159
privileges 154 sql commands 231
user synchronization 107 targets 159
users with privileges 182 troubleshooting 183
PowerCenter security wfs commands 232
managing 107 working with permissions 185
PowerExchange Listener Service ps
privileges 167 permissions by command 227
PowerExchange Logger Service privileges by command 227
privileges 168 pwx
privilege groups permissions by command 228
Browse 150 privileges by command 228
description 138
Design Objects 157
Domain Administration 141
Folders 155
R
Global Objects 165 rms
Informatica Cloud Administration 147 permissions by command 229
Load 151 privileges by command 229
Model 152 roles
Monitoring 145 Administrator 178
Run-time Objects 161 assigning 181
254 Index
roles (continued) SSL certificate
custom 179 LDAP authentication 26
description 139 LDAP user authentication 22
managing 177 Sun Java System Directory Server
overview 110 LDAP authentication 22
troubleshooting 183 synchronization
rtm LDAP users 22
permissions by command 230 times for LDAP directory service 25
privileges by command 230 users 107
run-time objects system memory
description 161 increasing 121
privileges 161 system-defined roles
Run-time Objects privilege group Administrator 178
description 161 assigning to users and groups 181
description 177
S
sch
T
permissions by command 230 targets
privileges by command 230 privileges 159
Scheduler Service Test Data Manager
privileges 169 administrator 116
search filters Tools privilege group
permissions 187 domain 147
Search section PowerCenter Repository Service 154
Informatica Administrator 108
secure domain
client configuration 63
security
U
passwords 118 UpdateColumnOptions
permissions 111 substituting column values 200
privileges 111, 137, 140 user accounts
roles 139 changing the password 110
Security Administration privilege group created during installation 115
description 140 default 115
Security Assertion Markup Language (SAML) enabling 119
support for 82 overview 115
security domains user activity logs
configuring LDAP 23 activity codes 123
deleting LDAP 27 convertUserActivityLog 122
LDAP 19–21 getUserActivityLog 122
native 19 output formats 122
Security page user description
Informatica Administrator 107 invalid characters 118
Navigator 108 user security
Security privilege group description 105
description 152 users
Service Manager assigning to groups 119
authentication 106 invalid characters 118
authorization 107 large number of 121
single sign-on 106 managing 117
single sign-on overview 109
configuring 83 privileges, assigning 181
description 106 roles, assigning 181
overview 82 synchronization 107
sources system memory 121
privileges 159 valid name 118
Sources and Targets privilege group
description 159
sql
permissions by command 231
V
privileges by command 231 valid name
SQL data service groups 126
inherited permissions 197 user account 118
permission types 197 virtual schema
permissions 197 inherited permissions 197
permissions 197
Index 255
virtual stored procedure web service (continued)
inherited permissions 197 permissions 201
permissions 197 web service operation
virtual table permissions 201
inherited permissions 197 web service resource
permissions 197 permissions 201
wfs
permissions by command 232
256 Index