Teradata Database. Security Administration

Teradata Database Security Administration Release 13.0 B035-1100-098A November 2009

The product or products described in this book are licensed products of Teradata Corporation or its affiliates. Teradata, BYNET, DBC/1012, DecisionCast, DecisionFlow, DecisionPoint, Eye logo design, InfoWise, Meta Warehouse, MyCommerce, SeeChain, SeeCommerce, SeeRisk, Teradata Decision Experts, Teradata Source Experts, WebAnalyst, and You ve Never Seen Your Business Like This Before are trademarks or registered trademarks of Teradata Corporation or its affiliates. Adaptec and SCSISelect are trademarks or registered trademarks of Adaptec, Inc. AMD Opteron and Opteron are trademarks of Advanced Micro Devices, Inc. BakBone and NetVault are trademarks or registered trademarks of BakBone Software, Inc. EMC, PowerPath, SRDF, and Symmetrix are registered trademarks of EMC Corporation. GoldenGate is a trademark of GoldenGate Software, Inc. Hewlett-Packard and HP are registered trademarks of Hewlett-Packard Company. Intel, Pentium, and XEON are registered trademarks of Intel Corporation. IBM, CICS, RACF, Tivoli, and z/os are registered trademarks of International Business Machines Corporation. Linux is a registered trademark of Linus Torvalds. LSI and Engenio are registered trademarks of LSI Corporation. Microsoft, Active Directory, Windows, Windows NT, and Windows Server are registered trademarks of Microsoft Corporation in the United States and other countries. Novell and SUSE are registered trademarks of Novell, Inc., in the United States and other countries. QLogic and SANbox are trademarks or registered trademarks of QLogic Corporation. SAS and SAS/C are trademarks or registered trademarks of SAS Institute Inc. SPARC is a registered trademark of SPARC International, Inc. Sun Microsystems, Solaris, Sun, and Sun Java are trademarks or registered trademarks of Sun Microsystems, Inc., in the United States and other countries. Symantec, NetBackup, and VERITAS are trademarks or registered trademarks of Symantec Corporation or its affiliates in the United States and other countries. Unicode is a collective membership mark and a service mark of Unicode, Inc. UNIX is a registered trademark of The Open Group in the United States and other countries. Other product and company names mentioned herein may be the trademarks of their respective owners. THE INFORMATION CONTAINED IN THIS DOCUMENT IS PROVIDED ON AN AS-IS BASIS, WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSION MAY NOT APPLY TO YOU. IN NO EVENT WILL TERADATA CORPORATION BE LIABLE FOR ANY INDIRECT, DIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS OR LOST SAVINGS, EVEN IF EXPRESSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. The information contained in this document may contain references or cross-references to features, functions, products, or services that are not announced or available in your country. Such references do not imply that Teradata Corporation intends to announce such features, functions, products, or services in your country. Please consult your local Teradata Corporation representative for those features, functions, products, or services available in your country. Information contained in this document may contain technical inaccuracies or typographical errors. Information may be changed or updated without notice. Teradata Corporation may also make improvements or changes in the products or services described in this information at any time without notice. To maintain the quality of our products and services, we would like your comments on the accuracy, clarity, organization, and value of this document. Please e-mail: teradata-books@lists.teradata.com Any comments or materials (collectively referred to as Feedback ) sent to Teradata Corporation will be deemed non-confidential. Teradata Corporation will have no obligation of any kind with respect to Feedback and will be free to use, reproduce, disclose, exhibit, display, transform, create derivative works of, and distribute the Feedback and derivative works thereof without limitation on a royalty-free basis. Further, Teradata Corporation will be free to use any ideas, concepts, know-how, or techniques contained in such Feedback for any purpose whatsoever, including developing, manufacturing, or marketing products or services incorporating Feedback. Copyright 2000 2009 by Teradata Corporation. All Rights Reserved.

Preface Purpose The purpose of this book is to assist administrators in formulating, implementing, and auditing security policy for a Teradata Database system. Use it to: Understand the basic components of Teradata Database system security. Determine a security policy appropriate for your system and the business environment in which it operates. Prevent unauthorized users from gaining access to the system. Limit the access of legitimate Teradata Database users to only those resources (databases, tables, views, stored procedures, and macros) they are authorized to use. Monitor security events and take corrective action. Understand the structure and content of the Teradata Database security mechanisms that create session security context, and how to modify them. Enable linking of the directory users with Teradata Database users, external roles, and profiles. Audience This book is intended for those who plan and implement system security measures including: Security administrators Database administrators System administrators Others involved in data management and operations Supported Software Release This book supports Teradata Database 13.0. Security Administration 3

Preface Changes to This Book Changes to This Book This book includes the following changes to support the current release: Release Teradata Database 13.0 November 2009 Teradata Database 13.0 April 2009 Teradata Database 12.00.00.12 March 2008 Description Revised the following topics in Chapter 5. Tdpid LDAP Authcid Logons LDAP UPN Logons for Mapped Directory Users UPN Credential Format Restricting Logons by Host Group Revised Chapters 5 and 8 to describe the differences in configuration requirements for the SPNEGO mechanism for Teradata Database running on various operating systems. Added information on trusted sessions and proxy users to Chapters 2 and 3. Added information on SSL/TLS protection options to Chapters 4, 7, 8, 9, and Appendix F. Extensively revised the content of Chapter 7 to include more comprehensive coverage of access logging. Added information to Chapters 8 and 9 in support of new binding options. Added new entries to the list of certified directories to Chapter 9. Added new information on changing the TDGSS configuration for Windows.Net clients to Appendix C. Added new Appendix G: Setting up Kerberos Authentication on Unix Nodes. Added a new limit on use of IP-based access restrictions to Appendix I. Added information about the new SPNEGO mechanism, which supports logons through Windows.Net clients, to Chapters 5 and 8. Revised requirements for external authentication logons in Chapter 5 and added the GenerateCredentialsFromLogon property to Chapter 8. 4 Security Administration

Preface Additional Information Release Teradata Database 12.0 September 2007 Description Added information on support for kerberos authentication on Teradata Database systems running MP-RAS and SUSE Linux Enterprise Server to Chapter 2 and new Appendix F. Added information on password control enhancements to Chapter 2 and new Appendix E. Added information on internationalization to Chapter 2. Revised the section on automatically inherited rights in Chapter 3. Added set up instructions for specification of backup directory servers in Chapter 5. Extensively revised the material on IP logon restrictions in Chapter 6 and Appendix D. Added a warning about continued use of Append Domain Name in Chapter 2. Additional Information URL http://www.info.teradata.com/ Description Use the Teradata Information Products Publishing Library site to: View or download a manual: 1 Under Online Publications, select General Search. 2 Enter your search criteria and click Search. Download a documentation CD-ROM: 1 Under Online Publications, select General Search. 2 In the Title or Keyword field, enter CD-ROM, and click Search. Order printed manuals: Under Print & CD Publications, select How to Order. http://www.teradata.com http://www.teradata.com/t/ten/ The Teradata home page provides links to numerous sources of information about Teradata. Links include: Executive reports, case studies of customer experiences with Teradata, and thought leadership Technical information, solutions, and expert advice Press releases, mentions and media resources Teradata Customer Education designs, develops and delivers education that builds skills and capabilities for our customers, enabling them to maximize their Teradata investment. Security Administration 5

Preface References to Microsoft Windows and Linux To maintain the quality of our products and services, we would like your comments on the accuracy, clarity, organization, and value of this document. Please e-mail: teradatabooks@lists.teradata.com References to Microsoft Windows and Linux This book refers to Microsoft Windows and Linux. For Teradata Database 13.0, these references mean: Windows is Microsoft Windows Server 2003 64-bit. Linux is SUSE Linux Enterprise Server 9 and SUSE Linux Enterprise Server 10. 6 Security Administration

Table of Contents Preface.....................................................................3 Purpose.......................................................................3 Audience......................................................................3 Supported Software Release.......................................................3 Changes to This Book............................................................4 Additional Information..........................................................5 References to Microsoft Windows and Linux........................................6 Chapter 1: Introduction to Teradata Database System Security.................................................................. 21 Teradata Database Security Principles............................................ 21 Security Controls.............................................................. 22 Controlling Physical Access................................................. 22 Controlling Database Access................................................. 23 Transmitting Secure Logons and Data......................................... 23 Monitoring Database Activity................................................ 23 Determining Security Requirements.............................................. 24 Business Value of Security................................................... 24 Identifying Users and Their Needs............................................... 25 Common User Groups..................................................... 25 Determining the Required Level of Security....................................... 26 Minimal Security.......................................................... 26 Moderate Security......................................................... 27 High Security............................................................. 27 Advantages and Disadvantages of Security Levels................................ 27 Formulating Security Policy..................................................... 28 Site-specific Teradata Database Security Policy................................. 28 Re-evaluating Security Policy................................................ 29 Security Administration........................................................ 29 Duties of the Security Administrator.......................................... 29 Security Administration 7

Table of Contents Chapter 2: Creating Users and Defining Access Privileges...31 Users and Databases............................................................31 System Generated Users.....................................................31 Guidelines for Creating Users.................................................32 Administrative Users........................................................33 Security Administrator Responsibilities.........................................34 Creating the Security Administrator User.......................................35 Database Administrator User.................................................36 Controlling Access to the Operating System.....................................36 Controlling Access to Teradata Dynamic Workload Manager......................37 Database Users.............................................................37 Directory Managed Users....................................................41 Proxy Users................................................................41 Database Privileges.............................................................43 Ownership Privileges...........................................................44 Giving Ownership..........................................................44 Related Topics.............................................................45 Explicit Privileges..............................................................45 Granting and Revoking Explicit Privileges..........................................45 Forms of the GRANT and REVOKE Statements.................................45 Revoking Privileges from PUBLIC or ALL DBC.....................................48 Automatic Privileges............................................................49 User DBC Automatic Privileges...............................................49 Creator/Modifier Automatic Privileges.........................................49 Optional Methods for Limiting Database Access.....................................50 Views.....................................................................50 Macros....................................................................50 Stored Procedures..........................................................50 Related Topics.............................................................50 Chapter 3: User Identification and Authentication.............51 User Identification.............................................................51 Teradata Database Authentication................................................51 External Authentication.........................................................52 System Requirements for External Authentication...............................53 Other Setup Options for External Authentication................................54 External Authentication with Delegated Credentials..............................55 External Authentication for Channel-Attached Clients............................55 8 Security Administration

Table of Contents Accessing the Database Through a Middle-tier Application.......................... 56 Establishing Trusted Sessions................................................ 56 Granting Privileges to Establish and Use Trusted Sessions........................ 57 Security Considerations for Trusted Sessions................................... 58 Chapter 4: Protection................................................ 61 Logon Encryption............................................................. 61 Password Encryption....................................................... 62 SASL Protection for Systems Using DIGEST-MD5 Binds......................... 62 SSL/TLS Protection for Systems Using Simple Binds............................. 62 Data Encryption.............................................................. 63 Data Integrity............................................................. 63 Related Topics............................................................ 63 BAR Encryption.............................................................. 63 Chapter 5: Logon Requirements and Controls.................. 65 Logon Elements............................................................... 65 Security Mechanism........................................................ 65 Database User Names...................................................... 66 Directory User Names...................................................... 67 Domain User Names....................................................... 67 Domain/Realm............................................................ 67 Appended Domain Name................................................... 68 Passwords................................................................ 69 Tdpid.................................................................... 69 Account String............................................................ 70 Using UTF-16 Characters in the Logon String.................................. 70 Network Logon Formats....................................................... 72 Logon Requirements Determined by Authentication Type........................ 72 Logon Syntax............................................................. 72 Command Line Logons........................................................ 73 Logons Using Teradata Database Authentication................................ 73 Logons Using External Authentication........................................ 74 Single Sign-on............................................................. 74 LDAP Logons............................................................. 75 LDAP Authcid Logons...................................................... 76 LDAP UPN Logons for Mapped Directory Users................................ 79 UPN Credential Format.................................................... 79 Security Administration 9

Table of Contents Common Errors with LDAP UPN Logons......................................80 Sign-on As................................................................81 Explanation of Example 1....................................................82 Explanation of Example 2....................................................83 Common Errors with UPN Logons............................................84 GUI Logons...................................................................84 Logons Through Teradata Query Director..........................................85 Logons from Channel-Attached Systems...........................................86 Logons from Teradata Database Nodes............................................86 Replication Logons.............................................................86 Encryption of Replication Sessions............................................87 Logons from Fully Managed.Net Clients...........................................87 Logon Errors..................................................................87 Logon Error Handling Options...............................................88 Logon Controls................................................................88 Granting Logons...........................................................88 Revoking Logons...........................................................88 Precedence of Clauses.......................................................89 Restricting Logons by Host Group.............................................89 Restricting Logons by IP Address..............................................91 Chapter 6: Creating and Managing Passwords..................93 Creating Passwords.............................................................93 Related Topics.............................................................93 Password Format Requirements...............................................93 Forgotten Passwords and Password Lockouts.......................................95 Tracking Changes to Passwords...............................................96 Password Control Options.......................................................97 Controlling Passwords With Multibyte Characters...............................97 Password Controls Located in DBC.SysSecDefaults...............................97 Viewing Current Password Control Settings.....................................98 Using UPDATE to Manage Global Password Controls in DBC.SysSecDefault.........98 Using CREATE or MODIFY PROFILE to Password Controls for Specific Users.......99 Comparing Methods of Password Control Management.........................101 Setting Password Controls......................................................102 ExpirePassword...........................................................102 MaxLogonAttempts........................................................103 PasswordReuse............................................................105 LockedUserExpire (Password Lockout Time)...................................106 10 Security Administration

Table of Contents PasswordMinChar........................................................ 107 PasswordMaxChar........................................................ 107 PasswordDigits........................................................... 108 PasswordSpecChar........................................................ 108 PasswordRestrictWords.................................................... 110 Error Messages........................................................... 112 Chapter 7: Monitoring Database Activity....................... 113 Monitoring Options and Objectives............................................. 113 Access Logging of Database Users............................................... 113 Default Logging.......................................................... 113 Requirements for Using BEGIN/END LOGGING Statements.................... 114 Using BEGIN LOGGING to Enable Logging Functions......................... 114 General Rules for Using DDL Statements in Access Logging..................... 114 DBC.AccLogRuleTbl Entries................................................ 115 DBC.AccLogTbl Entries................................................... 115 Database Level Logging.................................................... 116 Table Level Logging....................................................... 116 Using BEGIN LOGGING With GRANT...................................... 117 Logging MODIFY Statements............................................... 117 BEGIN/END Logging Errors................................................ 117 Disabling Access Logging with the END LOGGING Statement................... 117 Access Logging of Directory Users.............................................. 118 Setting up the Gateway to Identify Directory Users in Access Logs................ 119 Access Logging of Proxy Users.................................................. 119 Monitoring Security Related Tables and Views.................................... 120 Viewing Log Entries....................................................... 122 Deleting Aged Log Entries.................................................. 122 Querying Systems Views....................................................... 123 MONITOR Related Queries................................................ 123 Querying Session-Related Views................................................ 123 Chapter 8: TDGSS Administration................................ 127 TDGSS Standards............................................................ 127 TDGSS Installation and Maintenance............................................ 128 TDGSS for Channel-Attached Clients........................................ 128 Versions and Version Switching............................................. 128 Security Administration 11

Table of Contents Locating TDGSS Files......................................................129 TDGSS File Contents.......................................................129 TDGSS Site File...........................................................130 TDGSS File Maintenance Tools..............................................130 tdgsspkgrm...............................................................130 tdgssversion..............................................................131 TDGSS Configuration Files.....................................................133 C/C++ and Java Application Sharing of TDGSS Configuration Files...................134 Setting the Java Application Classpath.........................................134 Using the Jar Update Command.............................................134 TDGSS Security Mechanisms...................................................135 Mechanism Selection.......................................................135 Default Mechanism........................................................136 Mechanism Handling......................................................136 Mechanism Configurations.....................................................137 TD2 Mechanism...........................................................138 KRB5 Mechanism.........................................................139 NTLM Mechanism.........................................................140 LDAP Mechanism.........................................................141 SPNEGO Mechanism......................................................143 Mechanism Properties.........................................................144 Special Handling for New Properties..........................................144 Basic Functional Properties.....................................................145 AuthenticationSupported...................................................145 AuthorizationSupported....................................................146 GenerateCredentialFromLogon..............................................147 SingleSignOnSupported....................................................148 Mechanism Status Properties....................................................149 DefaultMechanism.........................................................149 MechanismEnabled........................................................150 MechanismRank..........................................................151 Operational Properties.........................................................152 DelegateCredentials........................................................152 MutualAuthentication......................................................153 ReplayDetection...........................................................154 OutOfSequenceDetection...................................................155 ConfidentialityDesired.....................................................156 IntegrityDesired...........................................................157 AnonymousAuthentication..................................................158 DesiredContextTime.......................................................159 DesiredCredentialTime.....................................................160 CredentialUsage...........................................................161 12 Security Administration

Table of Contents Directory User Authentication Properties........................................ 162 LdapServerName......................................................... 162 Set up for LDAP Server Failover Protection................................... 163 LdapServerPort........................................................... 164 LdapServerRealm......................................................... 165 LdapSystemFQDN........................................................ 166 LdapBaseFQDN.......................................................... 166 LdapGroupBaseFQDN.................................................... 167 LdapUserBaseFQDN...................................................... 168 LdapClientDebug......................................................... 169 LdapClientDeref.......................................................... 170 LdapClientRebindAuth.................................................... 171 LDAP Binding Properties...................................................... 172 LdapClientMechanism.................................................... 172 LdapServiceBindRequired.................................................. 173 LdapServiceFQDN........................................................ 174 LdapServicePassword...................................................... 175 LDAP Protection Properties................................................... 176 SSL/TLS Protection....................................................... 176 Avoiding Conflicts with OpenLDAP Tunables................................. 176 LdapClientTlsCACert..................................................... 177 LdapClientTlsCACertDir.................................................. 178 LdapClientTlsCert........................................................ 179 LdapClientTlsCipherSuite.................................................. 180 LdapClientTlsCRLCheck................................................... 180 LdapClientTlsKey......................................................... 182 LdapClientTlsRandFile.................................................... 183 LdapClientTlsReqCert..................................................... 184 LdapClientUseTLS........................................................ 185 SASL Protection.......................................................... 186 LdapClientSASLSecProps.................................................. 186 Confidentiality Properties..................................................... 187 VerifyDHKey............................................................ 187 DHKeyPand DHKeyG..................................................... 188 Changing the TDGSS Configuration............................................ 190 Differences in Function for Client and Server Configuration Files................. 191 General Rules for Editing.................................................. 192 Adding New Mechanisms or Properties to the User Configuration File............ 193 Effects of Upgrade and Migration on TDGSS Configuration Changes............. 194 Making Changes to the User Configuration Files.................................. 195 Planning a Configuration Change........................................... 195 Security Administration 13

Table of Contents Chapter 9: Directory Management of Database Users.......197 Supported Directories..........................................................197 LDAP Binding Options........................................................198 Directory User Binding Options..............................................198 Service Binds..............................................................199 Directory User Identification Options............................................202 Identity Mapping.........................................................202 Configuring an Identity Map................................................203 Identity Searches..........................................................205 Using <IdentityMap> and <IdentitySearch> in Combination.....................206 Using <IdentityMap> and <IdentitySearch> with DIGEST-MD5..................209 Directory User Management Options.............................................209 Option 1: Authentication Only--No Directory Schema Changes...................210 Option 2: Directory Authorization of Database Users............................211 Related Topics............................................................212 Directory User Characteristics...................................................212 Characteristics of Unmapped Directory Users..................................213 Characteristics of Directory Users Mapped to Permanent Users...................213 Ownership of Database Objects Created by Directory Users.......................214 Roles and Profiles for Directory Users............................................215 Database Administration of External Roles....................................215 Directory Administration of External Roles....................................215 Session Role Hierarchy and Role Switching....................................216 Effects of Drop External Role on Directory User Roles..........................216 Effects of Changing Directory Role Assignments................................216 Profiles for Directory Users..................................................216 Related Topics............................................................216 Access Logging of Directory Users...............................................217 Configuring a Directory to Manage Database Users.................................217 Directory Schema Overview.....................................................217 Teradata Schema Extensions.................................................217 Attribute Usage Requirements...............................................220 Special Objects and Attributes Required for Active Directory and ADAM...........223 System Evaluation.............................................................224 Optimization of Directory Searches..............................................224 Appendix A: System Level Security...............................227 Maintaining Physical Security...................................................227 14 Security Administration

Table of Contents Setting Physical Security Policy............................................. 227 Enforcing Security Policy.................................................. 228 Controlling Access to Dump Files............................................... 228 Controlling Access to the Operating System...................................... 228 Controlling Access to Outside Devices........................................... 228 Appendix B: Running a Secure Teradata Database.......... 229 Securing a System to the Common Criteria Evaluated Configuration................. 229 Common Criteria Level Security Procedure................................... 229 Avoiding Potential Security Hazards............................................. 232 Appendix C: Changing the TDGSS Configuration.............. 233 Using dumpcfg to Check the Current TDGSS Configuration......................... 233 Changing the TDGSS Configuration on SUSE Linux Enterprise Server Nodes.......... 235 Changing the TDGSS Configuration on MP-RAS Nodes............................ 236 Changing the TDGSS Configuration on Windows Nodes........................... 237 tdgss Configuration Errors..................................................... 238 Making TDGSS Configuration Changes on Teradata Clients........................ 238 Changing the TDGSS Configuration on Windows Clients....................... 239 Changing the TDGSS Configuration on Windows.Net Clients................... 240 Changing the TDGSS Configuration on Linux Clients.......................... 242 Changing the TDGSS Configuration on non-linux UNIX Clients................ 243 Reversion Procedure...................................................... 243 Appendix D: System Evaluation Tasks for Directory Integration............................................................ 245 Checking the Network........................................................ 245 From a Teradata Client.................................................... 245 From Teradata Database Server Nodes....................................... 246 Testing the Directory Server................................................... 246 The RootDSE Object...................................................... 246 Authenticating a Real User................................................. 249 Common Errors with Active Directory and ADAM................................ 250 DNS Naming Issue........................................................ 250 Security Administration 15

Table of Contents Server Down: As Seen from Windows.........................................250 Server Down: As Seen from MP-RAS.........................................251 Invalid User, Password, or Realm.............................................251 Common Errors with Sun Java Directory Server....................................252 Server Down..............................................................252 Bad Canonicalization.......................................................252 Bad User.................................................................253 Bad Password.............................................................253 Appendix E: Configuring a Directory to Manage Teradata Database Users........................................................255 Installing Teradata Schema Extensions in a Supported Directory......................255 Schema Installation Options.................................................256 Installation on Active Directory or ADAM from Teradata Database on Windows.....256 Installation on Active Directory or ADAM from Teradata Database on MP-RAS or SUSE Linux Enterprise Server...................................................258 Installation on Sun Java System Directory Server................................260 Installation on Novell edirectory.............................................261 Directory Information Tree.....................................................262 Teradata Database Objects in the DIT Hierarchy................................262 Populating the Directory Information Tree........................................265 tdatrootnode Object.......................................................265 tdatsystem Object.........................................................265 Creating Containers and Inserting Objects........................................266 Naming Conventions.......................................................266 Entering Container and Object Information in the Directory.....................266 Users....................................................................267 Roles....................................................................267 Profiles..................................................................267 IP Filters.................................................................268 Mapping Directory Users to Teradata Database Objects.............................269 Mapping Directory Users to Database Users....................................269 Mapping Directory Users to Database External Roles............................270 Mapping Directory Users to Database Profiles..................................270 Mapping IPFilters to Database Users..........................................271 Testing Mapped Directory Users.................................................271 Using BTEQ to Verify Directory User Mapping.................................272 tdsbind......................................................................274 Running tdsbind..........................................................274 Output from tdsbind.......................................................277 16 Security Administration

Table of Contents Explanation of Example 1.................................................. 277 Explanation of Example 2.................................................. 279 Diagnosing Logon Failure Due to Incorrect Realm Information.................. 281 tdsbind Error Output...................................................... 281 ldapsearch.................................................................. 282 Running ldapsearch...................................................... 282 Usage Notes for ldapsearch................................................. 284 Finding User Information with ldapsearch.................................... 285 Determining the schemanamingcontext Value................................ 290 Other LDAP Tools....................................................... 291 Appendix F: Setting Up SSL/TLS Options....................... 293 Requirements................................................................ 293 Supported Versions....................................................... 293 Installation of OpenSSL.................................................... 294 Basic SSL/TLS Support Required to Support Advanced Options.................. 294 Configuring Basic SSL/TLS Functions........................................... 294 SSL Protection........................................................... 295 TLS Protection........................................................... 295 Preparing to Configure Advanced Options....................................... 295 Directory Server Certificate Requirements.................................... 296 Authentication of the Directory Server by Teradata Database........................ 298 Verifying the Directory Server Certificate Chain................................... 298 Step 1: Obtaining the Directory Server Certificate Chain........................ 298 Step 2: Creating the CA Certificate Hashes.................................... 302 Step 3: Configuring TDGSS and TeraGSS..................................... 303 Step 4: Testing the Connection.............................................. 304 Mutual Authentication of the Directory Server and Teradata Database................ 305 Installing Certificates and Private Keys....................................... 305 Installing the Private Key................................................... 305 Installing the Certificate................................................... 306 Repeat the Installations for the Entire Database................................ 307 Updating the TDGSS or TeraGSS Configuration............................... 307 Troubleshooting............................................................. 308 Hostname Does Not Match CN in Peer Certificate............................. 308 SSL: Certificate Verify Failure............................................... 309 TLS: Self-signed Certificate Offered or Is Part of the Certificate Chain............. 309 TLS: Unable to Get Local Issuer Certificate.................................... 309 Security Administration 17

Table of Contents Appendix G: Setting up Kerberos Authentication on Unix Nodes....................................................................313 Active Directory Setup.........................................................313 Task 1: Create a Computer Component for Each Teradata Database Node..........314 Task 2: Add Unix Nodes to the Domain Name System (DNS).....................314 Task 3: Create an Active Directory User for Each Unix Node......................315 Task 4: Determine the Service Principal Name..................................316 Task 5: Run ktpass to Create the Kerberos Keys.................................317 Task 6: Move the Kerberos Keys to the Teradata Database System.................318 Teradata Database Node Setup..................................................319 Task 7: Install Kerberos on All Teradata Database Nodes.........................319 Task 8: Setup krb5.conf Kerberos Configuration File............................320 Task 9: Verify That a Unix Node Can Find the Name Server......................327 Task 10: Install the Kerberos Keys............................................327 Task 11: Synchronize Time Between the Domain and the Nodes...................330 Task 12: Check the Kerberos Synchronization Setup.............................334 Appendix H: Controlling User Access by IP Address..........337 Principals of IP AccessRestriction................................................337 Usage Constraints.........................................................337 Ensuring Security..........................................................338 Creating an XML IP Restriction Document........................................339 Saving the Completed XML IP Restriction Document...........................339 Designing IP Restrictions.......................................................339 IP Restriction Concepts.....................................................340 Element Descriptions.......................................................340 IP Filters.................................................................342 Effects of Filter Type on allow and deny Elements...............................344 Addresses and Mask Structure...............................................345 How Masks Affect Filters....................................................345 Important Masking Properties...............................................346 Forms of Interaction Between Primary and Secondary Masked IPs.................347 Permissive Filters..........................................................350 Restrictive Filters..........................................................352 Applying a Filter to a User...................................................355 Application of IP Restrictions................................................357 Applying a Filter to All Users................................................358 Directory Implementation of IP Restrictions.......................................359 18 Security Administration

Table of Contents Loading Directory Schema Extensions for IP Restriction of Directory Users........ 359 Creating IP Restriction Schema Objects in the Directory........................ 359 Standard Teradata Database Schema Objects.................................. 359 IP Filter Schema Objects................................................... 360 Mapping IP Filters to Database Users........................................ 362 Data Conversion Utilities...................................................... 363 ipxml2bin............................................................... 363 ipdir2bin................................................................ 364 Appendix I: Password Restricted Words....................... 367 Default Restricted Words...................................................... 367 Frequently Used Words.................................................... 367 Frequently Used Names.................................................... 377 Glossary................................................................ 381 Index.................................................................... 385 Security Administration 19

Table of Contents 20 Security Administration

CHAPTER 1 Introduction to Teradata Database System Security The information in this book is intended help security administrators to understand and perform the following security functions: Authenticate users at logon to prevent outsiders from gaining access to the system. Manage logon and password controls to ensure secure authentication. Authorize users to access only those objects and resources for which they have permission. Employ and modify security mechanisms to facilitate the user authentication and authorization strategy. Manage Teradata Database users externally using a directory. Enable encryption to secure message transmissions between client and server. Monitor security events and, where necessary, take corrective action. Create a site security policy based on site requirements, Teradata Database capabilities, and the chosen implementation strategy. Teradata Database Security Principles Teradata Database security is based on the following principles. Security Principle Database User Database Privileges Logon Description A database user is an individual defined in the database and identified by a username and password. The user definition also includes provisions to define the space available to the user for creating database objects, the accounts to which the user can charge jobs, and membership in a profile, which can determine a number of system parameters that apply to the user. A user can access and interact with the database only as defined in the database privileges assigned to the user. These privileges can be granted explicitly to a user, or to a role of which the user is a member. Users acquire some privileges implicitly or automatically as part of other privileges, or as a result of creating database objects. Users accessing Teradata Database must logon with a username and password. They may choose to logon to the database directly or through a middle-tier application. The logon also defines the security mechanism that will be used to authenticate the user. Security Administration 21

Chapter 1: Introduction to Teradata Database System Security Security Controls Security Principle Authentication Authorization Security Mechanisms Access Logging Protection Description At logon, the username and password are compared with a list valid users to verify that the user is authentic. Authentication can be performed by Teradata Database or by an external agent, such as a directory. Users are authorized database privileges based on: Privileges explicitly or implicitly granted in the database. Mapping of directory-based users to database users, roles, and profiles. Selectable database objects that define how the user will be authenticated, and in some cases, authorized. Logons use the mechanism specified in the logon string, or if no mechanism is specified, the current default mechanism. The database can be configured to log all user attempts to access the database, as well as the database objects that are accessed. Network transmissions between the database and its clients are protected as follows: By default, logon strings are encrypted. Network traffic between Teradata Database and its clients can be optionally encrypted. Additional protection is available for directory user logons, including obfuscation of the logon string and peer authentication of the directory and database. Security Controls You must define and implement effective security controls to establish and maintain optimal database security. You can control database security in the following ways. Restrict physical access to database system hardware. Use logon controls to limit access to the database. Define database privileges for each user to restrict activity within the database. Secure data transmissions to and from the database using encryption. Monitor user activity to detect security threats and violations. The following sections provide an overview of how to exercise these controls. Controlling Physical Access The most basic level of security is to limit access by unauthorized persons to the physical components of the Teradata Database system. These components include processor nodes, disk storage units, and the Administration Workstation (AWS). Controlling access to physical components involves the following elements: Protect the system against deliberate damage by locating it in a secure room. 22 Security Administration

Chapter 1: Introduction to Teradata Database System Security Security Controls Control access to external devices used to connect to the system, such as remote terminals. For detailed suggestions, see Appendix A: System Level Security. Controlling Database Access Users may access Teradata Database internally, by way of system nodes and administrative work stations (AWS), or externally by way of connected clients. The administrator controls access to the system by assigning a unique username and password to each user. Each database user must submit a username and password at logon. Once the system verifies that the username and the password are valid, it establishes a session with the user and assigns a unique session number. The session then runs under the combined identifier of the session number and the username until the user logs off. The user is the basis for ownership of all databases, objects (tables, views, stored procedures, and macros), and other users created during a session. The system provides users certain database privileges. In addition, the administrator can explicitly and selectively grant other privileges to users or groups of users. For information on how to regulate user access, see Chapter 2: Creating Users and Defining Access Privileges. Transmitting Secure Logons and Data Data transmitted between the database and clients is secured using encryption. There are two types of encryption: Logon strings are automatically encrypted to ensure the security of passwords transmitted from clients to the database. SSL and TLS are available to protect the token exchange during the authentication sequence. Users can selectively enable or disable encryption of data transmissions between the clients and the database. For additional information, see Chapter 4: Protection. Monitoring Database Activity The administrator can periodically audit security-related events on Teradata Database to detect the following security hazards: Logon irregularities and attempted break-ins Attempts to gain unauthorized access to database resources Attempts to alter security monitoring parameters Teradata Database automatically audits and logs all user logon and logoff activity. The security administrator can also specify auditing of attempts to access data by configuring the system to log one or more of the following additional parameters: All access requests made (for all or specific users) Security Administration 23

Chapter 1: Introduction to Teradata Database System Security Determining Security Requirements All access requests denied (for all or specific users) Specific types of access request made (for all or specific users) The security administrator can examine or print the audit data during normal system operations, or archive the data to review offline and generate reports. To select data from the audit log during normal operations, the security administrator composes statements with Teradata Structured Query Language (SQL). If security administrators identify unauthorized or undesirable activity, they can take one of the following remedial actions to address the problem: Initiate further monitoring of offending users Modify database access privileges Change compromised passwords Deny the offending users access to Teradata Database (in extreme cases) Change the security policy Related Topics For detailed information see, Chapter 7: Monitoring Database Activity. Determining Security Requirements Business Value of Security Teradata Database offers a wide array of security features. In order to make the correct choices about which security features to use, you should balance the cost of setting up and maintaining available security tools and procedures against your actual security needs. Evaluate your existing security policy, its effectiveness, and how it may need to change with the introduction of Teradata Database. Consider the business value of database security including government requirements, industry standards, and the business disruption that could result from a security breach. Identify the types of data in the database and the level of access required by users. Identify the ways in which Teradata Database will be accessed and the security concerns associated with each one. Define the level of security that is appropriate for your data and users. Employ the security options that best fit your implementation of Teradata Database and your existing security policy. Creating and maintaining a security policy costs money. The security policy you decide to use should be based on sound business decisions. How important is security to your business? Industry Standards Most businesses retain a large amount of proprietary customer and supplier data. Customers and suppliers expect that data to remain confidential. Industries respond to this need for 24 Security Administration

Chapter 1: Introduction to Teradata Database System Security Identifying Users and Their Needs confidentiality by defining and maintaining customer-acceptable levels of data security. Businesses that do not meet industry-standard levels of security may have trouble competing with those businesses that do. Government Standards Some businesses work directly on government contracts that contain contract-specific security requirements. Some are part of industries such as defense, financial, or medical that may be subject to a wide variety of local, state, and national government regulations, both foreign and domestic, in which they do business. Administrators should become acquainted with all applicable government security regulations before finalizing security policy. Possibility of Business Disruption How likely is it that someone would want to damage system hardware; to steal or corrupt your data? How would it affect your business if this happened? If the risk is moderate to high, your company has probably already initiated a security policy. Even if the risk of a serious security breach appears to be low, the losses your business might suffer if something did happen probably dictate that system security be taken seriously. Some kind of formal statement of security policy is needed by most businesses. What security policy will adequately protect your system without negatively impacting the users? Identifying Users and Their Needs Common User Groups Teradata Database security requirements are directly influenced by the needs of its users and the security risks they represent. With carefully screened users who are highly trusted, and with strict controls on physical access to Teradata Database, you might be able to establish a high degree of security without significant restrictions on user privileges and without resorting to frequent and detailed audits. However, for all but the smallest user communities, the time required to adequately screen all users and the cost of physical access controls may make this an undesirable security policy. For these reasons, a comprehensive and cost-effective security policy should be based on use of software-enforced Teradata Database security constraints and monitoring procedures. When formulating a security policy, you must balance the access needs of database users with the need to provide database security. Database users have different access needs based on the job functions they perform and the ways they use the data. Most Teradata Database users fall into one or more of the groups listed in Table 1. Security Administration 25

Chapter 1: Introduction to Teradata Database System Security Determining the Required Level of Security Table 1: User Groups User Group Duties Suggested Access Administrators Application Programmers End Users Responsible for the installation, setup, maintenance, performance, and availability of Teradata Database. Create databases, tables, views, stored procedures, and macros on behalf of the end users. Make Teradata SQL requests to Teradata Database to view, add, or change data. Principal administrators usually require full access to the database, including all privileges. Secondary or assistant administrators may be given more restricted access. Programmers may need wide access to create or restructure databases and objects, but should be restricted from adding or changing data. Limit user access to only the data and data manipulation functions users need to perform their assigned duties. Some high-level end users may require special privileges. For information on regulating database user access, see Chapter 2: Creating Users and Defining Access Privileges. Generally, users should be granted access privileges based on the needs of the work they perform. However, strict adherence to this concept may not result in the most efficient or economical security policy. Before making a final decision on establishing user access privileges, you should consider the threat users may pose, and the effects of their unauthorized access. Determining the Required Level of Security Minimal Security Once you understand the security risks for your database, the likelihood of them occurring, and the consequences of their occurrence, you must determine the appropriate level of security to counter the possible threats. Under minimal security, anyone who has successfully logged on to the system has unrestricted access to all data and Teradata Database resources. No one performs security-related auditing and no formal security policy exists. This approach may be attractive for small Teradata Database systems, including test systems, that have a small number of trusted administrative users who can access the system directly. Under a minimal security policy, the only security-related access restriction is on the initial logon to a client mainframe or PC that is capable of communicating with Teradata Database. Teradata Database can be configured to use the client directory for user authentication and authorization. For more information on interfacing with directories, see Chapter 9: Directory Management of Database Users. 26 Security Administration

Chapter 1: Introduction to Teradata Database System Security Determining the Required Level of Security Moderate Security High Security Under moderate security, the database administrator performs security administration duties, grouping users according to their needs and trustworthiness, and assigning access privileges accordingly. Only a small, privileged subgroup has unlimited access. The security administrator performs only occasional auditing of security-related events. Security administration policy is documented for administrators, but no formal security policy exists for the users. High security requires that the security administrator formally establish and maintain Teradata Database security. The security administrator is responsible for following securityrelated actions: Careful control of physical access to system processors, disk storage units, and terminals. Approval of those username/client system combinations Teradata Database allows to establish a session. Definition and control of the auditing of security-related events. Review of the results of security-related audits and initiation of corrective action. Creation of a detailed security policy document for administrators, application programmers, and end users. Each user should receive a document that states the security policy, explains the importance of security, outlines the role of the user in supporting that policy, and defines the guidelines for protecting passwords and data. Each administrator should receive a document that explains their role in supporting the security policy. Administrator awareness is important to early detection of potential security violations. Advantages and Disadvantages of Security Levels Each level of security has both advantages and disadvantages. You should consider whether the advantages of a level are worth their cost, or if the disadvantages make it impractical. Security Administration 27

Chapter 1: Introduction to Teradata Database System Security Formulating Security Policy Table 2: Advantages and Disadvantages of Data Security Levels Category Minimal security... Moderate security... High security... Advantages makes sharing information extremely simple. allows an environment of trusted users with unrestricted access to all database resources to realize a high level of productivity. requires few security enforcement activities that might impact system performance. Disadvantages allows anyone accessing Teradata Database the opportunity to steal, destroy, or corrupt data. provides anyone accessing Teradata Database access to all information stored under its control. allows no private or secret data. lets unauthorized users gain access to Teradata Database. might degrade system performance by allowing unauthorized use or misuse of the system. protects the system from casual attempts to circumvent security. requires little or no additional effort for users to perform their work. employs security practices that have little or no effect on system performance. can leave serious security violations undetected for extended periods. provides no guidelines for user security practices such as setting passwords, possibly allowing users to choose passwords that others can easily guess. affords a high level of protection to data and processing resources. gives users confidence that their data is safe from unauthorized disclosure, corruption, or deletions. uses an auditing policy that detects unauthorized access attempts and permits the implementation of corrective measures. requires significant additional effort for administrators to precisely define and authorize user data-access privileges. may degrade system performance depending on the frequency and scope of auditing and the demands of other required security practices. Formulating Security Policy After you define the security needs of the system and balance those with the needs of system users, you can formulate the security policy. Site-specific Teradata Database Security Policy System-enforced security features are relatively easy to implement. However, Teradata Database offers many security options, and it is not possible for the administrator and user documentation to identify the specific combination your site will choose to employ. To make sure administrators and users at your site understand and follow site-specific security procedures, the security administrator should create and distribute a security handbook. It should summarize your overall security policy, as well as highlighting Teradata Database security features and how they are to be used for your database. 28 Security Administration

Chapter 1: Introduction to Teradata Database System Security Security Administration The security policy document should include explanations of the following topics: An overview of your company s security needs and how they are being met Benefits that will be derived from a secure system Teradata Database security policy, including: A brief overview of Teradata Database security functions. Required security actions for users, such as logon and password regulations. Explanation of security mechanisms, their selection, and how they are to be employed by users and groups. Logon options, such as external authentication; especially use of single sign-on and directory sign-on. Database access privileges and restrictions. Security restrictions and management policy for security violations. A list of contacts who can answer security questions. Re-evaluating Security Policy Your security policy should not remain static. You should conduct periodic reviews to reevaluate whether the existing policy meets the current needs of the system, the users, and the company. The following factors may make changes to the security policy necessary: Addition of new access points and users. Changes in the profiles and needs of existing users. Changes in business focus that raise or lower the security requirements. Discovery of security violations, potential violations, or attempted violations that require procedural changes. New releases of Teradata Database software that introduce new security features. Security Administration One or more individuals should assume responsibility for the duties of Teradata Database security administrator. For small systems or those with low-level security needs, security administration duties may be handled by the system or database administrator. Larger, more complex systems, may require a separate security administrator or even a security administration team. Duties of the Security Administrator The designated security administrator is responsible for defining and documenting security policy. A security administrator typically performs the following duties: Establishes and modifies logon rules. Grants, monitors, and if necessary, revokes logon privileges. Security Administration 29

Chapter 1: Introduction to Teradata Database System Security Security Administration Sets and manages password controls. Identifies the users, objects, and SQL functions to be audited. Monitors security incidents and initiates corrective action. Coordinates Teradata Database security concerns with other administrators. For example, working with the database administrator in the creation and maintenance of users, roles, and profiles. Develops, documents, and distributes site security policy to administrators and users. For detailed information on best practice for setting up the security administrator user, see Administrative Users on page 33 and Appendix B: Running a Secure Teradata Database. 30 Security Administration

CHAPTER 2 Creating Users and Defining Access Privileges This chapter provides an overview of critical tasks required to create database users and define the privileges they have to access, add, change, or delete data. For detailed information on how to create users and databases, and grant database privileges, see Database Administration. Users and Databases System Generated Users Teradata Database users and databases are permanent storage spaces that can contain and own objects such as tables, indexes, procedures, triggers, functions, and other databases and users. However, whereas a database is a passive container, a user with the required privileges can logon to Teradata Database, establish a session, and perform actions in a database. To establish and maintain database security, it is important that users and databases be properly created and administered. The following sections explain the user and database security concerns. Most database users must be actively created using the CREATE USER statement. However, a few system generated users are created by the DIP scripts, which execute by default as part of the Teradata Database software installation process. System generated users automatically perform a number of basic system-level tasks in the database with no setup. Some options exist for employing these users to accomplish specialized tasks. For further information, see Database Administration. User DBC The top level system user, DBC, is the owner or parent of all other databases, objects, and users. By default, user DBC has all possible privileges for interacting with the database, and can grant privileges to lower level users. Initially, user DBC contains: All Teradata Database-managed disk space available to the database. Data Dictionary system tables. A series of system views that allow retrieval of data from the underlying system tables. Security Administration 31

Chapter 2: Creating Users and Defining Access Privileges Users and Databases Because user DBC owns all of the disk space managed by Teradata Database it is the parent of all other users, including the administrative users. Once created, the administrative users own most of the disk space and are responsible for creating and managing all other users, databases, and objects. Warning: Warning: User DBC Security Warnings! Because of the wide range of database privileges available to user DBC, only the most trusted administrative personnel should have access to the user DBC password. Never alter the database privileges for user DBC. Changing DBC privileges may cause installation, upgrade, maintenance, archive, or other procedures to end abnormally and consequently require Teradata Support Center assistance to correct the problem. Other System Generated Users User DBC owns all databases and users including those created by the DIP script during installation. The following additional system generated users are automatically created by the DIP scripts. SysAdmin SystemFE ALL CRASHDUMPS DEFAULT PUBLIC TDPUSER Note: System generated users may have access to sensitive data and functions within the database, therefore, Teradata recommends assigning new passwords in place of the default passwords for all system generated users. Warning: System generated users perform important system-level functions. Do not alter the database privileges for a these users unless specifically directed to do so in Teradata Database documentation. Access to system generated users should be limited to trusted administrators. For further information on the function and use of system generated users, see Database Administration. Guidelines for Creating Users Users not generated by the system, i.e. administrative users and database end users, must be actively created using the CREATE USER statement. Teradata suggests that you adhere to the following security guidelines when you create users and grant them privileges in the database. Create separate users for the security administrator and database administrator functions, even on small systems where both sets of tasks will be done by the same person. This separation of functions helps to clarify and emphasize security concerns. Ensure that all users are uniquely identified, so that monitoring of database access accurately reflects the activity of individuals. Avoid allowing multiple users to log on using the same username whenever possible, to maintain access log specificity. 32 Security Administration

Chapter 2: Creating Users and Defining Access Privileges Users and Databases Administrative Users Grant only the minimum number of privileges to users required for the jobs they perform. Even administrative users should not necessarily have every privilege available to user DBC. Granting users more access than they need causes unnecessary privilege checks, puts users at risk of unintentionally modifying or deleting unfamiliar objects and data, and could allow unwarranted user access to proprietary data. Grant CREATE and GRANT privileges only to administrators and other high level users who understand the security implications of these actions. Wherever possible, use roles to control and manage privileges of groups of users according to their job description or responsibility rather than granting privileges to individuals. This approach helps to simplify user management and provides a consistent level of privileges to users with similar jobs. Make sure that site-specific rules for creating users and granting user privileges are clearly spelled out in your site security policy. For information about creating users and granting privileges, see Database Administration. For a description of other methods of limiting database access, see Optional Methods for Limiting Database Access on page 50. Administration of a particular Teradata Database site should always be done according to sitespecific administrative needs. However, all sites should have at least one administrator with clearly defined administrative duties who manages the database and the user community. Administrative users should have sufficient database privileges to perform their function, while taking care to restrict the privileges of the general user community to prevent them from accessing administrative databases and functions. Teradata recommends that you divide administrative duties into two functional groups, the security administrator and the database administrator, regardless of the number of persons acting as administrators. Where necessary, create lower level administrative users in the space owned by the administrative group to which they belong. User DBC should create both the database and security administrator users. Disk space owned by user DBC that is not needed for system tables should be allocated to administrative users-- the database administrator, security administrator, and if necessary, other assistant administrators. The administrators can allocate space to the users and databases they create. Security Administration 33

Chapter 2: Creating Users and Defining Access Privileges Users and Databases As administrators create users and databases, a hierarchical relationship evolves, as follows: DBC A B C D E DBC directly creates the database administrator (A) and security administrator (B) users. DBC is the immediate owner (parent) of A and B, and owns everything in the hierarchy. The database administrator (A) owns database (C) and assistant administrator (D), and then creates user (F) in database (C). A is the immediate owner, or parent, of C and D. C is the immediate owner, or parent, of F. The security administrator (B) creates assistant security administrator (E). B is the immediate owner, or parent, of E. Owners of objects have implicit privileges on those objects. For more detailed information on the effects of object ownership, see Ownership Privileges on page 44. Security Administrator Responsibilities F FF07A002 Teradata recommends that security administrators assume the following responsibilities: Work with the database administrator to evaluate site security requirements, determine the level of protection needed for adequate security, and define the security features that will both support security requirements and allow users to efficiently do their job. Develop a security policy based on how the site will use Teradata Database capabilities to meet security needs. Distribute the policy to administrators. Create a set of user-level security rules and distribute them to users. Set up and manage the TDGSS configuration to support site security policy. Coordinate with the database administrator in creation and maintenance of users, roles, and profiles. Coordinate with the database administrator and directory administrator to set up optional directory management of database users. Manage user logon permissions and password controls. Set up optional access restrictions by IP address. Set up database access logging and monitor the output for security violations. Take action to repel security threats, including revising user privileges, revoking logons, and dropping users. Enforcement actions should only be taken with the knowledge and participation of the database administrator. 34 Security Administration

Chapter 2: Creating Users and Defining Access Privileges Users and Databases Creating the Security Administrator User Provide the security administrator with the privileges required to carry out administrative duties. For sites that require more than one security administrator, especially where duties vary among administrators, use roles to define administrator database privileges. Perform the following steps to create the security administrator user and grant the minimum privileges necessary to carry out security administration duties: 1 Log on to Teradata Database as user DBC. 2 Update the value for ExpirePassword in DBC.SysSecDefaults to a non-zero value so the temporary password assigned to the security administrator user will expire at first logon, and require creation of a private password. UPDATE DBC.SysSecDefaults SET ExpirePassword = 30 ; 3 Create the security administrator user with a CREATE USER statement. The example that follows employs the user name SECADMIN. The CREATE USER statement should assign a temporary security administrator password and set the size of the PERMANENT, SPOOL, and TEMPORARY space. For details on how to determine space requirements, see Database Administration. CREATE USER SECADMIN AS PASSWORD = xxx, PERMANENT = xxx, SPOOL = xxx,temporary = XXX FALLBACK ; You can specify other user attributes in the initial CREATE USER statement or later with a MODIFY USER statement. For further information, see Database Administration 4 After creating user SECADMIN, enter the following SQL statements to grant user SECADMIN the basic privileges recommended by Teradata for security administrators. GRANT USER ON SECADMIN TO SECADMIN /* maintain users */ ; GRANT ROLE TO SECADMIN /* maintain roles */ ; GRANT PROFILE TO SECADMIN /* maintain profiles */ ; GRANT SELECT ON DBC TO SECADMIN /* select on dictionary tables */ ; GRANT UPDATE ON DBC.SysSecDefaults TO SECADMIN /* password characteristics */ ; GRANT EXECUTE ON DBC.LogonRule TO SECADMIN /* logon rules */ ; GRANT EXECUTE ON DBC.AccLogRule TO SECADMIN /* access logging */ ; GRANT DELETE ON DBC.AccLogTbl TO SECADMIN /* delete audit entries */ ; GRANT DELETE ON DBC.DeleteAccessLog TO SECADMIN /* delete audit entries */ ; GRANT DELETE ON DBC.EventLog TO SECADMIN /* delete event log */ ; 5 Next, provide the security administrator the authority to control and monitor user logons, using the GRANT/REVOKE LOGON and BEGIN/END LOGGING statements, as follows: GRANT EXECUTE ON DBC.LogonRule TO SECADMIN ; GRANT EXECUTE ON DBC.AccLogRule TO SECADMIN ; 6 Log off Teradata Database as user DBC. Security Administration 35

Chapter 2: Creating Users and Defining Access Privileges Users and Databases 7 Immediately log back onto Teradata Database as username SECADMIN. Create a personal password at the prompt. 8 Enter the following Teradata SQL statement to initiate an audit trail on the execution of any BEGIN/END LOGGING or GRANT/REVOKE LOGON statement: BEGIN LOGGING WITH TEXT ON EACH ALL ON MACRO DBC.LogonRule, MACRO DBC.AccLogRule ; Executing this statement generates audit entries for all subsequent Teradata SQL statements that control auditing of actions on, and the source of logons to, the database. 9 Log off Teradata Database. You can assign other privileges to the security administrator depending on system needs. Database Administrator User Employ user DBC to create the database administrator user. Teradata recommends that database administrators be granted privileges sufficient to carry out the following responsibilities: Create and manage users, profiles (except password controls), databases, tables, views, query logs, stored procedures, and journals. Grant database privileges to users and roles. The database administrator should work closely with the security administrator to develop guidelines for granting user privileges based on an evaluation of site security requirements and user needs. Manage space and allocate it to users and databases. Create and manage accounts, and assign them to users. Manage data checking and protection. Monitor and tune system performance. Troubleshoot user problems. Manage periodic maintenance tasks. Manage extract and load utilities, such as FastLoad, MultiLoad, and Teradata Parallel Transporter. For information on creating the database administrator user and performing the various administration tasks, see Database Administration. Controlling Access to the Operating System It is important to restrict access to the operating system to only administrators with special privileges. Establish operating system and network security controls to secure Teradata Database. Restrict users without special privileges from accessing the LAN through the operating system to prevent inadvertent corruption of Teradata Database data files. In addition, all Teradata systems can be set up with operating system-level security hardening. Hardening for systems running on SUSE Linux Enterprise Server Enterprise Server is enabled at the factory. Security hardening prevents users with access to Teradata Database from using this access to perform unauthorized activities at the operating system level. 36 Security Administration

Chapter 2: Creating Users and Defining Access Privileges Users and Databases Controlling Access to Teradata Dynamic Workload Manager Database Users Teradata Dynamic Workload Manager (Teradata DWM) is a Teradata Database tool for managing database resources. Access to Teradata DWM requires submitting a special username and password. Because of the powerful effects of this tool, allow as few users as is practical to access the Teradata DWM username and password. For information on Teradata DWM, see Teradata Dynamic Workload Manager User Guide. Each database user is defined by the database administrator with a CREATE USER statement: CREATE USER USERXYZ AS PASSWORD = xxx Database administrators should observe the following security guidelines when creating users: Create database users in the space owned by the principal database they will use. Grant privileges directly to users, or to roles that will in turn be granted to the users, in accordance with guidelines set out in the site security policy, as developed by the security administrator. The following sections present an overview of the elements of the CREATE USER statement from a security perspective. For details on creating users and granting privileges, see Database Administration. User Name Specification of the username in a CREATE USER statement must take into account the following security concerns. Must be unique within the database. Should represents a single person. Teradata recommends not allowing more than one person to logon with the same username. Such an approach eliminates the ability to monitor the database activities of individuals. User Password A CREATE USER statement submitted without a password specification will be rejected by the system. The password specified in the CREATE USER statement is only temporary, and therefore it need not be unique. By default the PasswordChgDate parameter for each newly created user is set to 0 in DBC.Users. This value requires that the user create a personal password at first logon. Thereafter, the user will be periodically prompted by the system to create a new password at intervals defined by password expiration settings. For information on password controls, see Chapter 5: Logon Requirements and Controls. Space Allocation From a security perspective, user space allocation should be based on the user privileges and responsibilities in the database. Ownership of permanent space automatically provides database privileges on all objects in the space. Allocate permanent space only to users that can be trusted with the attendant privileges and responsibilities. Security Administration 37

Chapter 2: Creating Users and Defining Access Privileges Users and Databases For detailed information on allocating space to users, see Database Administration. User Accounts User accounts identify the account to be charged for the space used during a session. There are no specific security concerns associated with user accounts. Because multiple users can logon using the same account, all security monitoring is tracked by unique username. For detailed information on about how to set up and manage user accounts, see Database Administration. Roles Administrators can assign privileges to individual users with the GRANT statement, as shown in Granting and Revoking Explicit Privileges on page 45. For efficient administration of database privileges, grant privileges to a role, and then grant the role to groups of users with similar database needs. Roles are also important in that they standardize the privileges given to users with a particular job description. The following example shows a typical implementation of roles: 1 Create roles for groups of users, based on common job requirements, using the form: CREATE ROLE role_name 2 Assign one or more privileges to each role, as follows: GRANT SELECT ON table_name TO role_name Construct each role based on the privileges required by a type of user such as accounting, purchasing, or development. Users that are members of one or more roles can then access all the objects on which the roles assigned to them have privileges. 3 Assign the access privileges defined in each role to one or more users by naming a default role as part of the CREATE USER (or MODIFY USER) statement, as follows: CREATE USER USERXYZ AS PASSWORD = xxx, DEFAULT ROLE = role_name 4 Administrators can also assign roles to users using the GRANT statement, as follows: GRANT role1, role2, TO user_name; After logging on and establishing a session, users can submit a SET ROLE statement to switch from the default role to any role of which they are member, or use a SET ROLE ALL statement to invoke all assigned roles. For detailed information on setting up and using roles, see Database Administration. For the syntax required to CREATE, DROP, or SET a role, or to assign a default role to a user as part of a CREATE USER statement, see SQL Data Definition Language. For the syntax required to GRANT or REVOKE a role, see SQL Data Control Statements. 38 Security Administration

Chapter 2: Creating Users and Defining Access Privileges Users and Databases Roles for Directory Users Directory users have access to role-based privileges as follows: If the LDAP AuthorizationSupported property is set to no, a directory user with a username that matches a username defined in the database can exercise any roles granted to the matching database user. If the LDAP AuthorizationSupported property is set to yes and directory users are mapped, a directory user can exercise: any external role to which the user is mapped. Note: Directory users cannot be mapped directly to a role. Directory users are members of groups. Groups can be mapped to external roles. any role belonging to a database user to which it is mapped For information on the application of roles to directory-based users, including the special rules for creating an external role, see Roles and Profiles for Directory Users on page 215. Roles for Proxy Users Proxy users have access to role-based privileges assigned with the GRANT CONNECT THROUGH statement that initially creates the proxy user, as follows: For users already defined in the database (permanent users): GRANT CONNECT THROUGH trusted_user_name TO PERMANENT perm_user_name [,perm_user_name] WITH ROLE role_name [, role_name] WITHOUT ROLE; For application users not known to the database: GRANT CONNECT THROUGH trusted_user_name TO app_user_name [, app_user_name] WITH ROLE role_name [,role_name]; Observe the following when using the GRANT CONNECT THROUGH statement to assign roles to proxy users: Proxy users defined in a GRANT CONNECT THROUGH statement that are not also permanent database users must be assigned at least one role, using WITH ROLE. Proxy users that are permanent database users have the following role-based privileges: If WITH ROLE is specified, the permanent user has access to only the proxy user role(s) defined in the GRANT CONNECT THROUGH statement. If WITHOUT ROLE is specified, the permanent user has access to only the roles granted to the permanent user in the database. Other limitations may apply. For additional information on specifying roles in GRANT CONNECT THROUGH and conditional limits to role usage, see Proxy Users on page 41. Note: All roles specified in the GRANT CONNECT THROUGH statement must first be created in the database. Security Administration 39

Chapter 2: Creating Users and Defining Access Privileges Users and Databases Profiles Administrators can define profiles and assign them to a groups of users who share the same needs, using the CREATE or MODIFY PROFILE statement. Profiles define values for the following system parameters: Default database Spool space Temporary space Account strings Password controls All parameters are normally assigned by the database administrator, except the password controls, which should be the duty of the security administrator. Using Profiles to Control User-Level Password Security Teradata Database stores the system-wide password control options in the DBC.SysSecDefaults table. Using a profile, the administrator can specify values for the password control attributes that override the global values stored in DBC.SysSecDefaults, and apply only to the user members of the profile. Password controls are available to specify: the minimum and maximum number of characters in a password string the number of incorrect logon attempts allowed before locking a user out of the database the number of minutes before unlocking a locked user, or a lock without specified length the number of days before passwords expire the number of days before password can be reused whether to allow, disallow, or require digits and special characters in the password string. whether or not to deny passwords containing restricted words. For a list of standard password restricted words, as well as instructions for adding words to the restricted words list, see Appendix E: Configuring a Directory to Manage Teradata Database Users.. Note: Changes to password attribute settings in a profile do not require a system restart to take effect. The new settings take effect at the next logon for a user assigned to the profile. Related Topics For detailed information on using password controls, see Chapter 5: Logon Requirements and Controls. For the syntax required for a CREATE or MODIFY PROFILE statement to define or change password controls and other profile options, see SQL Data Definition Language. For information on the non-security aspects of profiles, see Database Administration. 40 Security Administration

Chapter 2: Creating Users and Defining Access Privileges Users and Databases Directory Managed Users Sites with a large, network-attached user community have probably already defined users in a directory, such as Active Directory. Administrators have two options for managing directory users who access the database: Create a database user with a username to match each directory user that requires database access. The directory user then inherits all privileges granted to the matching database user, when the LDAP mechanism AuthorizationSupported property is set to No. Map directory users (in the directory information tree) to users, profiles, and roles defined in the database. Directory users inherit all privileges of the database objects to which they are mapped when the LDAP AuthorizationSupported property is set to Yes. For information on administering directory-based users, see Chapter 9: Directory Management of Database Users. Proxy Users By default, all users logging on to Teradata Database through a middle-tier application assume a single user identity, that of the application, and can exercise only the database access privileges available to that user. A middle-tier application can be configured for trusted sessions, which allows users to be uniquely identified and granted specific database privileges, using roles. For a top-level discussion of trusted sessions, including a complete list of required setup tasks, see Accessing the Database Through a Middle-tier Application on page 56. Creating Proxy Users Proxy users are defined in terms of the middle-tier application through which they will connect to Teradata Database. Use the GRANT CONNECT THROUGH statement to identify proxy users that will logon to the database through the application, as follows. For users already defined in the database (permanent users): GRANT CONNECT THROUGH trusted_user_name TO PERMANENT perm_user_name [,perm_user_name] WITH ROLE role_name [, role_name] WITHOUT ROLE; For application users not known to the database: GRANT CONNECT THROUGH trusted_user_name TO app_user_name [, app_user_name] WITH ROLE role_name [,role_name]; The GRANT CONNECT THROUGH statement specifies the following elements: Syntax Element trusted_user_name Description The permanent username that the application employs to log on to Teradata Database. This user must be created in the database before the it is referenced in a GRANT CONNECT THROUGH statement. Security Administration 41

Chapter 2: Creating Users and Defining Access Privileges Users and Databases Syntax Element perm_user_name app_user_name WITH ROLE WITHOUT ROLE Description The name of a permanent user being granted proxy logon privileges. Must be preceded by a TO PERMANENT clause to identify the user as a permanent user. This user must be created in the database before it is referenced in a GRANT CONNECT THROUGH statement. Each GRANT CONNECT THROUGH statement can specify up to 25 perm_user_names. There is no limit to the number of perm_user_names that can be granted proxy logon privileges for a particular trusted_user_name. The name of an application user being granted proxy logon privileges. Must be preceded by the TO clause to identify the user as not being a permanent user. Users associated with app_user_names are not defined in the database, but the names must follow Teradata Database object naming conventions. Each GRANT CONNECT THROUGH statement can specify up to 25 app_user_names. There is no limit to the number of app_user_names that can be granted for a particular trusted_user_name. The list of role names available to the proxy user(s) defined in the containing GRANT CONNECT THROUGH statement. Role_name must identify a role already defined in the database. In this context, ALL, NONE, and NULL are not valid role names. All proxy users defined with an app_user_name must have at least one role name. Each GRANT CONNECT THROUGH statement can specify up to 15 role names. Fifteen is also the maximum number of role names that can be set for each proxy user. If the CONNECT THROUGH privilege for a particular trusted user already exists for the perm_user_name or app_user_name, newly granted roles will be added to the existing roles. If the addition of roles causes the number of roles for a proxy user/trusted user name pair exceed 15, the statement aborts. Use REVOKE CONNECT THROUGH to remove a role from the proxy user for a particular trusted user. By default, or if the proxy connect sets PROXYROLE=ALL, all role_names in the WITH ROLE clause are active. If the proxy connect specifies a PROXYROLE=role_name, it must be one of the role_names from the WITH ROLE clause, and will be the only active role for the proxy user. Role=NONE and Role=NULL are not permitted. If the proxy_user_name is a permanent user, the WITHOUT ROLE clause can be used to indicate that the access privileges of the permanent user, including roles, should be used. If the proxy connect omits specifying a PROXYROLE, the active role for the proxy user will be the default role for the permanent user. Note: The trusted user application must employ SET QUERY BAND options to fully implement the trusted sessions feature. These settings can include the PROXYROLE= clause, which greatly affect the roles available to proxy users, whether perm_users or app_users. These effects should be included as part of site security policy and made known to proxy users. For information, see SQL Data Definition Language. 42 Security Administration

Chapter 2: Creating Users and Defining Access Privileges Database Privileges Database Privileges After users have logged on to Teradata Database and have been authenticated, they are authorized access to only those objects allowed by their database privileges. A privilege (also referred to as a right, access right, or permission) is the right to access or manipulate an object within Teradata Database. Privileges control user activities such as creating, executing, inserting, viewing, modifying, deleting, or tracking database objects and data. Privileges may also include the ability to grant privileges to other users in the database. If a user does not have the appropriate privileges for a particular SQL request, Teradata Database denies the request and generates an access violation informing the requesting user, and the access log, of the violation. Privileges are either explicit or implicit. Implicit privileges result from ownership and cannot be revoked. Explicit privileges result from direct GRANTs or object creation, and can be revoked. Privilege Description Implicit Privileges Ownership Privileges implicitly granted by Teradata Database to the owner of the space in which database objects are created. For example, the user that creates a database owns that database and all lower-level objects subsequently created in it, whether they are created by the owning user or by other lower level users. Explicit Privileges GRANT Inherited Privileges assigned directly to a user or database using a GRANT statement: GRANT privileges directly to a user or database. GRANT privileges to a role, then GRANT the role to one or more users. GRANT privileges to an external role, then map the external role to one or more groups of directory users. Privileges that are passed on indirectly to a user in one of the following ways: All users inherit the privileges of PUBLIC, a role-like collection of privileges available to all users by default whether or not they have any other privileges. A user inherits all the privileges granted to each role to which the user has been granted membership. Directory users inherit the privileges of the database users to which they are mapped. Directory users that are members of one or more directory groups also inherit the privileges defined in all external roles to which the groups are mapped. Security Administration 43

Chapter 2: Creating Users and Defining Access Privileges Ownership Privileges Privilege Automatic Description Privileges provided automatically by the system as the result of the creation of a database object: to the creator of a database, user, or other database object to a newly created user or database The syntax for the GRANT and REVOKE statements used to control privileges are detailed in the chapter titled SQL Data Control Language Statement Syntax in SQL Data Control Language. Ownership Privileges The owner of the space in which a database or another user is created is implicitly granted ownership of the space it occupies. The owning user is considered the parent and created users are considered child users. In turn, a child becomes the parent of any new users it creates. All owners or parents within the resulting hierarchy implicitly possess certain privileges on all objects created in the space they own. Privileges implicitly available to an owner are not all inclusive, but a parent may grant itself additional privileges on any objects owned by any of its child users. Ownership is also granted to all indirect owners (parents), that is, those in the hierarchy above the immediate owner. Ownership is subject to the following additional rules: A user does not own itself. Creating a user does not grant to the newly created user any ownership privileges, however, newly created users do possess other automatic privileges. Ownership privileges cannot be revoked. Although ownership privileges are implicit, they are subject to access logging if specified. For information on logging, see Chapter 7: Monitoring Database Activity. Site security policy must take into account the ownership hierarchy and resulting implicit privileges in setting guidelines for creating databases and users. For further information on creating databases and users, see Database Administration. Giving Ownership You can use the Teradata SQL GIVE statement to transfer ownership of a database or user to a new owner, who may or may not be part of the current parent-child hierarchy. The GIVE statement transfers to the recipient not only the specified database or user space, but also all of the databases, users, and objects owned by that database or user. Therefore, transferring ownership affects space allocation and should be used with caution. 44 Security Administration

Chapter 2: Creating Users and Defining Access Privileges Explicit Privileges Related Topics For information on ownership of users, databases, and objects created by directory-based users, see Directory User Characteristics on page 212. Explicit Privileges Explicit privileges result from using the GRANT or REVOKE statement to explicitly provide or retract one or more privileges for a database object. For example, DBC is the initial user in the system. It has all privileges except CREATE PROCEDURE and EXECUTE PROCEDURE. When creating other users, DBC has the right to grant any or all of these privileges to itself or any other users, including granting itself CREATE PROCEDURE and EXECUTE PROCEDURE privileges. It is recommended that DBC first create and grant all privileges to one or more administrative users, and then the administrator can create and grant privileges to all other users. Privileges for directory-based users are handled differently. For information, see Directory User Management Options on page 209. Granting and Revoking Explicit Privileges A user submitting a GRANT or REVOKE statement must be an owner of the object to which the privileges refer, or must have the GRANT privilege (WITH GRANT OPTION), plus all of the privileges that are to be given or revoked on the object. If the object is a view, stored procedure, or macro, the owner of the view or macro must also have the GRANT privilege (WITH GRANT OPTION), plus all other applicable privileges, on the objects referenced by the view, stored procedure, or macro. Teradata recommends that administrators make sure that non-administrative users do not have direct access to data tables unless they are performing batch operations. GRANT users access to databases that contain only views, macros, stored procedures, or functions and not the tables containing the actual data. For information on GRANT and REVOKE, see SQL Data Control Language. For information on the administration of user privileges, see Database Administration. Forms of the GRANT and REVOKE Statements The GRANT statement has the following forms: Security Administration 45

Chapter 2: Creating Users and Defining Access Privileges Granting and Revoking Explicit Privileges Statement GRANT/REVOKE (SQL Form) GRANT/REVOKE (Monitor Form) GRANT LOGON/ REVOKE LOGON GRANT ROLE/REVOKE ROLE (Role Form) GRANT CONNECT THROUGH/REVOKE CONNECT THROUGH Description Directly grants or revokes privileges on Teradata Database objects in a specified location, for a user, role, or external role. Privileges can be granted on databases, tables, table columns, and views. Grants or revokes system-wide performance monitoring privileges for a user. Grants or revokes database logon privileges for a user. Grants or revokes membership in a role for users or other roles. Grants or revokes the following: Trusted user status to an application associated with a Teradata Database user. CONNECT THROUGH privileges to specified proxy users, while identifying whether or not the proxy user is a permanent Teradata Database user or an external application user. Membership in roles to specified proxy users. For detailed syntax and usage information for GRANT and REVOKE, see SQL Data Control Language. Database Privileges for Directory Users and EXTUSER You cannot use GRANT or REVOKE database privileges for directory users, or the systemgenerated pseudo-user, EXTUSER. Mapped directory users receive database privileges as follows: Privileges granted to database users to which they are mapped, including roles they have been granted. Privileges granted to external roles that are mapped to a group of which the directory user is a member. Directory users can also be mapped to EXTUSER, which by default has a very limited set of database privileges. Note: You cannot GRANT additional privileges to EXTUSER beyond the defaults. EXTUSER is useful when: Mapping to permanent database users, external roles, or profiles provides an inappropriate level of access to a directory user. Note: Directory users that have been mapped to EXTUSER can subsequently be mapped to additional users, external roles, and profiles. In such cases, the directory user can exercise all the privileges to which it has been mapped. Creating new permanent database users, external roles, and profiles to provide limited access is not worth the effort involved. 46 Security Administration

Chapter 2: Creating Users and Defining Access Privileges Granting and Revoking Explicit Privileges For information on the use of mapping to provide database privileges to directory users, see Chapter 9: Directory Management of Database Users. Security Administration 47

Chapter 2: Creating Users and Defining Access Privileges Revoking Privileges from PUBLIC or ALL DBC Revoking Privileges from PUBLIC or ALL DBC For some systems, administrators may have granted privileges to PUBLIC (all users) that are no longer appropriate. In such cases, administrators may find it necessary to REVOKE these privileges from PUBLIC or from a large number of users. The methods for revoking PUBLIC privileges vary according to when the privilege was originally granted. In general, it is best to avoid granting privileges on DBC tables to PUBLIC. You should not make DBC tables that widely available and only grant privileges on the DBC tables to system administrators or trusted users. Because the method for granting privileges to PUBLIC changed during V2R5.0, the method required to REVOKE those privileges depends on when the privilege was originally granted. Privileges to be Revoked Release Granted Applicable REVOKE Statement and Explanation Non-DBC table privilege granted to PUBLIC or ALL DBC DBC table privileges granted to PUBLIC or ALL DBC that were not converted over to new PUBLIC privileges after upgrading from pre-v2r5.0 to V2R5.0 or later. If the conversion was done, use REVOKE <privilege> FROM PUBLIC; Non-DBC or DBC table privilege granted to PUBLIC or ALL DBC Before V2R5.0 Before V2R5.0 V2R5.0 and after REVOKE <privilege> FROM ALL DBC; Revokes a particular privilege from PUBLIC. Use one of the following: REVOKE <privilege> FROM <user>; REVOKE <privilege> FROM <list of users>; REVOKE <privilege> FROM ALL <non-dbc user>; Use of these statements means that the specified user and all its descendents no longer have that privilege. Contact the Teradata Support Center for assistance if you need to revoke a DBC table privilege granted before V2R5.0 from a very large number of users and cannot use REVOKE <privilege> FROM ALL <non-dbc user>; Warning: Do not use REVOKE <privilege> FROM ALL DBC! This statement also removes user DBC privileges on DBC tables. Once revoked, only the Teradata Support Center can help re-grant these privileges. REVOKE <privilege> FROM PUBLIC; 48 Security Administration

Chapter 2: Creating Users and Defining Access Privileges Automatic Privileges Automatic Privileges Automatic privileges are granted by the Teradata Database system as follows: Type of Automatic Privilege User DBC The creator (and in some cases, the modifier) of a database, user, or object. A newly created user or database Accompanying privilege Explanation The initial user in the system, user DBC, automatically has all database privileges. User DBC then uses these privileges to create the administrative users and explicitly grant privileges to them. Administrative users can then pass these privileges down to the users, roles, and databases they create. When a user with the CREATE DATABASE or the CREATE USER privilege creates a new database or user, Teradata Database automatically grants to that user a series of creator privileges on the created object and any space that it owns. The newly created users, too, automatically receive a set of privileges within their defined user space. The automatic privileges provided to newly created users can be explicitly revoked from the new user by an owner or by the creator of the user. A user granted one privilege may automatically receive another complimentary privilege. For instance, a user that is GRANTed the CREATE AUTHORIZATION privilege automatically receives the DROP AUTHORIZATION privilege. For a detailed list of automatic privileges, see Database Administration. User DBC Automatic Privileges The initial user in the system, user DBC, automatically has all database privileges. User DBC then uses these privileges to create the administrative users and explicitly grant privileges to them. Administrative users can then pass these privileges down to other objects they create. Creator/Modifier Automatic Privileges When a user with the CREATE DATABASE or the CREATE USER privilege creates a new database or user, Teradata Database automatically grants to that user a series of creator privileges on the created object and any space that it owns. Creator privileges differ from ownership privileges because the FROM dbname option of the CREATE DATABASE or CREATE USER statement allows use of space owned by another user. The newly created users, too, automatically receive a set of privileges within their defined user space. The automatic privileges provided to newly created users can be explicitly revoked from the new user by an owner or by the creator of the user. Security Administration 49

Chapter 2: Creating Users and Defining Access Privileges Optional Methods for Limiting Database Access In some cases, the creator of a new user or database is not the owner of the space in which the object was created. This is because the CREATE DATABASE/USER statement offers a FROM option that allows creation of new database objects from the space of another specified owner. For information on available CREATE options, see SQL Data Definition Language. Optional Methods for Limiting Database Access Granting database privileges may not always be the best way to restrict database access. Teradata Database also provides the following optional methods for limiting access. Views Macros Database tables may contain some information that is needed by the general user population along with other information to which access must be highly restricted. Administrators can create views to separate out portions of a table that require different levels of user restriction and then grant privileges on each view to define user access. Some users can be allowed to retain the right to access the entire table. A view may be used to either include or exclude proprietary data. Where more than two levels of table access are needed, views can be created from other views (nested views). Use macros to limit the actions a user can perform on a database object. The actions can include DCL, DDL, and DML statements. Macros are useful for repetitive data entry tasks, where the user needs access to a proprietary database with neither the privilege to review existing data nor delete data. The user has only the right to provide values for common attributes, for instance name, address, and phone number. You can also use macros to insert records in an audit trail table to monitor system use, and to record this use for accounting purposes. A user with the EXECUTE privilege on such a macro and INSERT privilege on the database or table can EXECUTE the macro to add new data to the database. The immediate owner of the macro must have privileges on the objects referenced by the macro. Stored Procedures Related Topics Stored procedures limit the actions a user can perform to what is defined in the procedure. Use of stored procedures to control user access is very similar to that of macros. For information on application and administration of views, macros, and stored procedures for access control, see Database Administration. For information on the privileges and syntax elements required to create views, macros, and stored procedures, see SQL Data Definition Language. 50 Security Administration

CHAPTER 3 User Identification and Authentication All users that log on to Teradata Database must be identified and then authenticated before accessing database objects. Authentication validates the user name and password submitted in the logon string as recognized database user. Authentication is performed by the security agent identified in the security mechanism that is specified in the logon string. Once authenticated, the user is authorized access to only the database objects to which it has been implicitly or explicitly granted access privileges. For information on authorizing user privileges, see Chapter 2: Creating Users and Defining Access Privileges. For information on specifying security mechanisms in a logon string, see Network Logon Formats on page 72. User Identification All users logging on to Teradata Database are identified by a username and password. At logon, the authentication process compares the submitted username and password to a list of valid users. This user information is created and stored in either the database or a directory. Teradata Database Authentication By default, Teradata Database is set up to authenticate users logging on to the database. Teradata Database authentication requires the following: The user must be defined and granted privileges in the database The logon must specify the TD2 mechanism (or it must be set as the default) For detailed information on creating users and granting database privileges, see Chapter 2: Creating Users and Defining Access Privileges. For information on the content and format of the logon string, see Chapter 5: Logon Requirements and Controls. Security Administration 51

Chapter 3: User Identification and Authentication External Authentication External Authentication External authentication allows Teradata Database users logging on from network-attached clients to be authenticated by a supported external agent rather than by Teradata Database. Note: A Teradata Database system can be connected to its clients by both a network and one or more channels. External authentication for channel attached clients functions very differently from external authentication on network attached systems. For information on external authentication for channel-attached systems, see External Authentication for Channel-Attached Clients on page 55. There are two types of external authentication for network attached systems: 1 Logon to Teradata Database without resubmitting user credentials (Single Sign-on): Users are authenticated during their initial logon to the network. They do not need to resubmit their credentials when logging on to the database. SSO users must logon to the client Windows domain with a username that matches a Teradata Database username. During a later logon to Teradata Database, SSO users must still select an SSO compatible mechanism to initiate a session. The authenticating agent forwards the network user credentials to the database, where it authorizes the privileges associated with the matching database username. Observe the following SSO logon restrictions: SSO logons to Teradata Database on SUSE Linux Enterprise Server or MP-RAS must use the KRB5 mechanism. SSO logons through a fully managed.net client must use the SPNEGO mechanism. 2 Logon to Teradata Database with User Credentials: The user submits credentials as part of the logon string when accessing on to the database, but is actually authenticated by a directory or other supported external security application. Directory Sign-on (mapped directory users): Directory users logon with the LDAP mechanism and are authenticated using their directory username. The directory can also be set up to authorize database privileges based on directory user mappings to Teradata Database users, roles, and profiles. For information on mapping directory users to Teradata Database users, roles, and profiles, see Chapter 9: Directory Management of Database Users. Sign-on AsusingKRB5, NTLM, LDAP, or SPNEGO Authentication: The sign-on As authentication option requires that users log on with a username known by the external authenticating agent and Teradata Database. After authentication, the user can exercise all privileges granted to the matching database user. For detailed information on logon format requirements for external authentication, see Network Logon Formats on page 72. 52 Security Administration

Chapter 3: User Identification and Authentication External Authentication System Requirements for External Authentication The administrator must ensure that the following conditions exist to enable external authentication for network-attached clients: External Authentication Type Requirements Single Sign-on (SSO) The client must be running on Windows. When Teradata Database runs on SUSE Linux Enterprise Server Release 10 or MP- RAS 3.03, SSO requires a special set-up in addition to the tasks listed in the section. For more information, see Appendix H Controlling User Access by IP Address on page 337. The user must logon to the domain with a username that matches a database username. The matching Teradata Database user must have been granted LOGON WITH NULL PASSWORD privileges. One or more mechanisms that support SSO must be enabled, and must be either set as the default or selected by the user at logon: For standard Windows client logons, select the KRB5 or NTLM mechanism, depending on client system configuration. For Windows clients logons through fully managed.net client, select the SPNEGO mechanism. Note: You must manually enable the SPNEGO mechanism on all nodes and on the Query Director (if used). If any client runs CliV2 version 8.2.x or earlier, there is a limit of four active mechanisms. Because of this limit you must disable a mechanism if you enable SPNEGO. Sign-on As The client must be running on Windows. When Teradata Database runs on SUSE Linux Enterprise Server Release 10 or MP- RAS 3.03, SSO requires a special set-up in addition to the tasks listed in the section. For detailed information, see Appendix H Controlling User Access by IP Address on page 337. The user must logon with a username that matches a database username. The matching Teradata Database user must have been granted LOGON WITH NULL PASSWORD privileges. One or more mechanisms that support UPN logons must be enabled, and must be either set as the default or selected by the user at logon. For Kerberos authentication, select the KRB5 mechanism. For NTLM authentication, select the NTLM mechanism. For Kerberos authentication when logging through fully managed.net client, select the SPNEGO mechanism. Note: You must manually enable the SPNEGO mechanism on all nodes and on the Query Director (if used). If any client runs CliV2 version 8.2.x or earlier, there is a limit of four active mechanisms. Because of this limit you must disable a mechanism if you enable SPNEGO. For authentication by a directory, select the LDAP mechanism. Note: The LDAP AuthorizationSupported property must be set to No. Security Administration 53

Chapter 3: User Identification and Authentication External Authentication External Authentication Type Requirements Directory Sign-on (mapped directory users) All directory users must be defined in the directory. For a list of certified directories, see Supported Directories on page 197. The directory must be set up to map directory users to Teradata Database users, roles, and/or profiles. For detailed information, see Chapter 9: Directory Management of Database Users. The LDAP mechanism contains a number of properties that must be evaluated for the site configuration, and a determination made as to whether or not editing of the property values is required. For detailed information see General Rules for Editing on page 192. The LDAP AuthorizationSupported property must be set to yes or the system will ignore all mapping to Teradata Database users, roles, and profiles. The database user must have the LOGON WITH NULL PASSWORD privilege, except EXTUSER, which automatically has this privilege. The LDAP mechanism must be enabled, and must be either set as the default or selected by the user at logon. Other Setup Options for External Authentication All network logons access Teradata Database through the Teradata Gateway. Network-based external authentication must be explicitly enabled by the administrator using the DBS Control utility or the Gateway Control utility for all supported operating systems. You can set these External Authentication controls to: Disable external authentication and allow only Teradata authentication. Enable external authentication in addition to Teradata authentication; users have the option of being externally authenticated. Allow only external authentication, while disabling Teradata authentication; all users must be externally authenticated. Since you can set the DBS Control and Gateway Control utilities individually, you should take care to understand how each one is used to control external authentication, and the results of possible conflicts in their settings. The DBS Control utility affects all logons to the database. The Gateway Control utility affects only logons through a particular Teradata Gateway, and can be set for all host groups or an individual host group. If you want to control external authentication for all users set external authentication flag using the DBS Control utility. If you want to control external authentication for only users that log on through a particular gateway, set external authentication flag associated with that gateway using the Gateway Control utility. For a particular gateway: if either utility is set to disable external authentication, while the other utility is set to enable external authentication, then external authentication is disabled and users entering through that gateway cannot be externally authenticated. 54 Security Administration

Chapter 3: User Identification and Authentication External Authentication if either utility is set to allow only external authentication, while the other utility is set to enable external authentication, then users entering through that gateway can only be authenticated externally. You can also use the Database Window interface to manage external authentication. The SET EXTAUTH command toggles the same internal control switches used by the DBS Control utility. Whichever method you use last controls the current external authentication setting. Use GET EXTAUTH to check whether or not external authentication is enabled. Use SET EXTAUTH to enable or disable external authentication globally. Related Topics For information on enabling external authentication using the DBS Control and Gateway Control utilities, see Utilities. For information on enabling external authentication using DBW, see Database Window (xdbw) in Utilities. External Authentication with Delegated Credentials Some systems pass user logon credentials (i.e. delegate the credentials) through Teradata Query Directory to one of multiple database systems. Users logging on through Query Director can still be authenticated externally, but the following exceptions apply: Use only the KRB5, LDAP, or SPNEGO (only on logons through a Windows.Net application) mechanism for external authentication that requires delegated credentials. Query Director must be running on SUSE Linux Enterprise Server or Windows. The following software is required: The Teradata Database software must be at V2R6.2 or higher (Release 12.00.10 for SPNEGO). Teradata Tools and Utilities software must be at 12.00.11 of higher. Teradata.Net Data Provider version 12.0 or greater must be installed on all clients using the SPNEGO mechanism. Check to make sure the DelegateCredentials property value is set to yes (the default) on both the Client and the Query Director for the authentication mechanisms to be used. For further information on how to edit mechanism property values, see General Rules for Editing on page 192. External Authentication for Channel-Attached Clients Users can also be externally authenticated when logging on from channel attached clients, but this type of external authentication requires a different setup procedure from that of network based external authentication. If you decide to use any of the external authentication functions provided by the TDP, you must make sure to enable external authentication in the database. Since logons from channel attached systems do not go through the Teradata Gateway, you can t use the Gateway Control Security Administration 55

Chapter 3: User Identification and Authentication Accessing the Database Through a Middle-tier Application utility to enable external authentication. However, you can use DBS Control or Database Window functions to manage external authentication for channel-attached clients in much the same way they are used for network attached clients. For further information on set up of authentication options such as security exits, see Teradata Director Program Reference. Accessing the Database Through a Middle-tier Application Middle-tier applications may stand between end-users and Teradata Database; accepting requests from users, constructing queries from those requests, passing the queries to the database, and then returning results to the users. The middle-tier application logs on to the database, is authenticated as a permanent database user, and establishishes a connection pool. The application then authenticates the individual application end-users, some of whom may request access to the database through the connection pool. By default, all end-users accessing the database through a middle-tier application are authorized database privileges, and are audited in access logs, based on the single permanent database user identity of the application. For sites that require end-users to be individually identified, authorized, and audited, the middle-tier application can be configured to offer trusted sessions. Application end-users that access the database through a trusted session must be set up as proxy users and assigned one or more database roles, which determine their access rights in the database. When a proxy user requests database access, the application forwards the user identity and applicable role information to the database. Establishing Trusted Sessions The following sequence describes the steps involved in establishing Trusted Sessions: 1 Since the application authenticates its users, a SET QUERY BAND statement must be used to send relevant user information to the database, including: Username: Used to associate the session with a proxy user to define the user privileges and identify the proxy user in query and access logging. Role information: Used to define the proxy user privileges for the session. The duration of the query band. Developers or application programmers must embed code in the middle-tier application program to derive the required information, insert it into a SET QUERY_BAND SQL statement, and then forward the statement to the database. For detailed information on using SET QUERY BAND in a middle-tier application to facilitate trusted sessions, see SQL Data Definition Language and the Teradata Orange Book, Using Query Banding, Including Trusted Sessions. 56 Security Administration

Chapter 3: User Identification and Authentication Accessing the Database Through a Middle-tier Application 2 User DBC grants the CTCONTROL privilege to one or more administrators, allowing them to grant trusted user status to middle-tier applications, and to define proxy users and their database privileges. 3 A system administrator with the CTCONTROL privilege uses the GRANT CONNECT THROUGH statement to grant the right to establish trusted sessions to a particular middle-tier application, for selected users. 4 An application with the right to establish trusted sessions logs on to Teradata Database as a permanent database user. Once authenticated, the application creates a connection pool for servicing end user requests. 5 A proxy user logs on and is authenticated by the application. When the proxy user requests a service involving access to Teradata Database, the application gets a connection from the pool and issues a SET QUERY_BAND to set the PROXYUSER. 6 The database authorizes database privileges based on the role(s) defined for the proxy user. A trusted session persists for the life of the query band. Database access privileges in a trusted session are determined by the proxy user role declared in the query band, or if WITHOUT ROLE is specified, by the privileges granted to the matching database user. During a trusted session, the proxy user identity is recorded in all access and query log entries. Granting Privileges to Establish and Use Trusted Sessions The implementation of trusted sessions requires the following database privileges. CTCONTROL Privilege The CTCONTROL privilege links an administrator to a middle-tier application that is being set up to conduct trusted sessions. The CTCONTROL privilege is required for any administrator that will later use the GRANT CONNECT THROUGH statement to complete the setup of trusted sessions on the application. The CTCONTROL privilege can be granted only to permanent Teradata Database users. It cannot be granted to roles or to any other type of database objects. The general form of the GRANT CTCONTROL statement is: GRANT CTCONTROL ON trusted_user TO security_administrator where: trusted_user is the Teradata Database user name for the middle-tier application being set up for trusted sessions. security_administrator is the Teradata Database user name for the administrator being given privilege to administer proxy users and associated roles for the application. Note: The GRANT CTCONTROL statement can specify only one trusted user, but up to 25 administrator users, per statement. For details on use of the GRANT CTCONTROL statement, see SQL Data Control Language. Security Administration 57

Chapter 3: User Identification and Authentication Accessing the Database Through a Middle-tier Application Example The following example grants user Admin_01 the privilege to grant the CONNECT THROUGH privilege to users of a specific middle-tier application, which uses mta as its logon username. GRANT CTCONTROL ON mta TO Admin_01 CONNECT THROUGH Privilege Use the GRANT CONNECT THROUGH statement to grant the privilege to establish trusted sessions to a middle-tier application, for a proxy user. The GRANT CONNECT THROUGH statement also defines the role or roles available to the user. Database users (administrators) that have been granted the CTCONTROL privilege can execute a GRANT CONNECT THROUGH statement only for the application (trusted_user) specified in the original GRANT CTCONTROL statement. Note: The administrator issuing the GRANT CONNECT THROUGH privilege to a permanent database user must have the DROP USER privilege on the permanent user. The GRANT CONNECT THROUGH statement uses the following form: GRANT CONNECT THROUGH trusted_user TO proxy_user WITH ROLE role(s) where: trusted user specifies the permanent user that the middle-tier application uses to login to Teradata Database. proxy user identifies the end-user(s) of the middle-tier application who can gain access to Teradata Database through a trusted session. Proxy users can be application end users who are unknown to Teradata Database, or they can be permanent users already defined in Teradata Database. role(s) specifies the database roles that are available to be assigned to the proxy users when they connect to the database through the trusted_user application. Note: The SET QUERY BAND statement sent by the application to Teradata Database initiates the session and specifies which of the roles available to the proxy user are operant for the session or transaction. For additional information, see Proxy Users on page 41 and Roles for Proxy Users on page 39. Security Considerations for Trusted Sessions Consider the following developing security policy for trusted sessions. It is the responsibility of the middle-tier application to authenticate end users before connecting them to Teradata Database through a trusted session. Once a trusted session has been established for the application user, Teradata Database controls access to database objects based on the privileges granted to the proxy user. Teradata recommends that middle-tier applications not permit end users to submit SQL during a trusted session. If proxy users are permitted to submit SQL, the application needs 58 Security Administration

Chapter 3: User Identification and Authentication Accessing the Database Through a Middle-tier Application to prevent them from adding a SET QUERY_BAND statement that would enable the user to assume the identity of another proxy user and utilize that set of user privileges. The application can detect this by issuing an EXPLAIN against the SQL and searching for the QUERY_BAND keyword. If logon controls have been set, such as restricting logons by IP address, the system enforces them only for the middle-tier application trusted user logon, not for the application end-user proxy users. Use of SET ROLE is not permitted in a trusted session. In a proxy connection, the role is determined by the roles specified in the CONNECT THROUGH privileges granted to the proxy user, along with any role limitations specified in the contents of the SET QUERY BAND statement that is submitted by the application to initiate the session or transaction. Trusted sessions established under a username assumable by more than one end user (a group user) will not be able to trace database activity back to the end user in the database access logs. To do this, the SET QUERY BAND statement must be constructed to include the username of the end user. Security Administration 59

Chapter 3: User Identification and Authentication Accessing the Database Through a Middle-tier Application 60 Security Administration

CHAPTER 4 Protection Communication between the database and its network-attached clients may be vulnerable to access by unauthorized users, interception, and/or corruption. Teradata Database provides the following features to enhance data protection: By default, the logon string is encrypted to maintain the confidentiality of the username and password employed to log on to Teradata Database. Optional data encryption of messages maintains confidentiality of the data transmitted to and from Teradata Database. Automatic integrity checking insures that the data is not corrupted during the encryption/ transmission/decryption cycle. Optional BAR encryption provides confidentiality of data backup transmissions between the BAR server and the storage device. Optional SSL/TLS protection for systems using directory authentication, including: Obfuscation of the LDAP authentication exchange between Teradata Database and the directory server. An additional level of protection to require the database to authenticate itself to the directory or that the database and directory mutually authenticate. Optional SASL protection for systems using LDAP authentication with DIGEST-MD5 binding: Protection of the LDAP authentication token exchange sequence between Teradata Database and the directory server. Note: Most of the features described in this chapter are applicable only to sessions logged on from network-attached clients. Logon Encryption By default, all logons to Teradata Database are automatically transmitted and stored in encrypted form. Encryption of logon strings ensures the confidentiality of passwords transmitted over the network. Client applications cannot enable or disable encryption of the logon string. Security Administration 61

Chapter 4: Protection Logon Encryption Password Encryption Teradata Database uses two levels of password encryption as shown in the following table. Encryption Algorithm Encryption Strength Defaults Setting Usage SHA-256 256-bit For V2R6.2 and above (new installations only) DES 56-bit V2R6.1 and before V2R6.2 and above (upgrades only) Very secure Used automatically for all passwords created or changed after upgrade to Release 12.0 or greater. Secure Legacy password encryption level for: All systems upgrading to Teradata Database 12.0 or greater from V2R6.1 and before All systems upgrading to Release 12.0 or greater from V2R6.2, if SHA-256 encryption was not employed Used by the system only until the first time the password expires after an upgrade to Release 12.0. Thereafter, all new or changed passwords will be encrypted using SHA-256. SASL Protection for Systems Using DIGEST-MD5 Binds By default, Teradata Database uses DIGEST-MD5 binding for directory user authentication. When a directory user logs on to the database, the SASL token exchange between the directory server and Teradata Database or the Query Directory is not encrypted because the password and other information are sent as hashes. However, for some directories the token exchange the directory server and the database server could be compromised by a man-in-the-middle attack and the Quality of Protection (QOP) reset to send the exchange in clear text. SASL protection allows resetting of the minssf property to thwart such attacks. To change the minssf setting and add extra protection for the DIGEST-MD5 token exchange on supporting directory types, set the value of the LdapClientSaslSecProps property as shown in LdapClientSASLSecProps on page 186. SSL/TLS Protection for Systems Using Simple Binds Site security policy may require the use of the optional simple bind protocol instead of DIGEST-MD5 binding (the default) for directory user authentication. Simple binds transmit the authentication exchange between the database and the directory in plain text form. Therefore, Teradata recommends that systems using simple binds also implement optional SSL or TLS protection, which maintains the confidentiality of the exchange. SSL/TLS also affords an extra level of protection for systems that do use DIGEST-MD5 binding. For detailed information on SSL/TLS, see Appendix G: Setting up Kerberos Authentication on Unix Nodes. For a discussion on selecting a binding method, see LDAP Binding Options on page 198. 62 Security Administration

Chapter 4: Protection Data Encryption Data Encryption Data Integrity Related Topics Users have the option of encrypting data transmitted between Teradata Database and its clients. Although encryption of transmitted data is desirable, you should not use this feature indiscriminately. Depending on the application and the type of session being run, encryption may significantly reduce performance. Users should only encrypt a session if the value of the security outweighs the potential performance losses. Published security policy should clearly state when data encryption should or should not be used. Both of the following parameters must be properly set before session data will be encrypted: The ConfidentialityDesired property of the security mechanism being used for the session must be set to yes to support encryption. The ConfidentialityDesired property is factory preset to yes for all standard Teradata Database security mechanisms. Encryption must be enabled via the client application used to logon to Teradata Database. The details of how to enable encryption varies among client applications. Setting of either one of these parameters to encrypt the session will not, by itself, cause a session to be encrypted. Teradata Database is set by default to check all received encrypted messages against what was sent to ensure that data has not been corrupted during transmission. For details on enabling encryption, see the users guides for Teradata client products. For details on how to view or edit security mechanism property settings, see General Rules for Editing on page 192. For details on how encryption affects system performance, see Performance Management. BAR Encryption A variety of administrative scenarios may require that the data in Teradata Database be backed up on external media and restored at a later date. Once out of the database environment and on the network, the data may be vulnerable to attack. Software-based solutions are available for securing data in BAR environments, which are integrated with ARCMAIN and which provide strong data encryption capabilities. Solutions such as Defiance BAR Encryption include a secure key management system through which keys are encrypted in a secure data repository, and access restricted to selected security administrators. Such solutions are integrated with the Teradata BAR Server and support a wide range of backup devices and Open Teradata Backup (OTB) compatible platforms including BakBone NetVault 7.1 or later and Symantec NetBackup 5.0 or later. For details, see Teradata Archive/Recovery Utility Reference. Security Administration 63

Chapter 4: Protection BAR Encryption 64 Security Administration

CHAPTER 5 Logon Requirements and Controls This chapter describes how to set up, use, and maintain the security features that manage user logons to Teradata Database. Logon Elements Security Mechanism To access the database, users must submit their username, password, and other related information as part a logon request. Upon successful logon, Teradata Database associates the username with a unique session number under which the session runs until the user logs off. The size of these logon string items cannot exceed a total of 128 bytes. Although relatively large, this limit can become an issue for logons with long usernames and passwords expressed in UTF-16 (double-byte) characters. Upon receipt of the logon string, the selected security mechanism authenticates the user and establishes a session based on the user privileges. Logon strings must include some or all of the following elements, depending on system configuration and security policy: Note: Teradata Database may provide some of these elements by default, or transfer them from other sources, depending on the authentication method defined in the logon. Security mechanism Username Domain or Realm Password Tdpid Account string Teradata Database provides several preset security mechanisms to define the network security context in which a session will operate, including whether the user will be authenticated by Teradata Database or an external security application. The administrator can individually enable or disable security mechanisms, and can set one security mechanism as the default so users can initiate a session without having to decide on a mechanism. If users require a different security context than that provided by the default mechanism, they may choose among several alternate mechanisms during the logon sequence. The method of choosing a mechanism varies among client applications. Security Administration 65

Chapter 5: Logon Requirements and Controls Logon Elements Database User Names Data Encryption All standard Teradata Database security mechanisms are factory preset to support encryption of data transmitted during a session for which they have been selected. However, because there are significant resource costs associated with encrypting a session, encryption is disabled by default for all applications and must be explicitly enabled at logon from within the application. The method for enabling and disabling encryption also varies with the application used. Related Topics For a detailed description of available Teradata Database security mechanisms, see TDGSS Security Mechanisms on page 135. For information on how to enable/disable data encryption from within a Teradata application, see the users guide for the application you plan to employ. For information on how to select a mechanism, see Network Logon Formats on page 72. For logon procedures for a specific application, see the users guide for that application. Each database user must be created using the Teradata SQL CREATE USER statement. The Teradata Database security administrator must execute a separate CREATE USER statement for each authorized user to establish the username, define an associated password, and allocate user disk space. A system table named DBC.DBase stores usernames and resides in the space allocated to the system user. You can retrieve information on Teradata Database usernames from DBC.DBase by querying the system view DBC.UsersX. CREATE USER requires that you define: A unique username, limited to 30 characters: A simple user name in the form username A username with distinguishing information, in the form user@xxxx A password A permanent space allocation in which the user can create other database objects You can also optionally use the CREATE USER statement to specify other security-related user attributes, such as: Default database A profile and/or role of which the user is a member Account string You can set up your system to allow some users to be authenticated by external security applications. These users do not need to submit usernames and passwords when logging on to the database. Related Topics For detailed instructions on how administrators can create users and specify related security attributes, see the section on setting up users in Database Administration. 66 Security Administration

Chapter 5: Logon Requirements and Controls Logon Elements Directory User Names Domain User Names Domain/Realm For specific instructions on how to construct and use variations of the CREATE USER statement, see SQL Data Definition Language. For information on password format requirements and controls, see Chapter 5: Logon Requirements and Controls. Directory users are defined in a directory that is not part of Teradata Database. Directory users log on using the LDAP mechanism and their directory user names and passwords. Note: If the directory is Sun Java System Directory Server, the value used by Teradata Database for the AuditTrailID is limited to 30 characters. Therefore, Sun Java System Directory Server usernames should be unique within the first 30 characters. Directory users must observe the following rules when executing an LDAP logon: If a directory is not configured to map directory users to Teradata Database objects, the directory username must match a database username and the LDAP AuthorizationSupported property must be set to no on the client from which the directory user is logging on. If the directory is configured to map directory users to Teradata Database objects, directory users must log on with their directory user names, and the LDAP AuthorizationSupported property must be set to yes on the client from which the user is logging on. For detailed information, see LDAP Logons on page 75 and Chapter 9: Directory Management of Database Users. Users must logon with a domain username that matches a Teradata Database username for the Single Sign-on and Sign-on As logon options. The name of either the domain or realm (depending on the directory) is required for logons using the LDAP mechanism where both of the following are true: The site elects to use SASL/DIGEST-MD5 authentication The authenticating directory server offers more than one SASL realm. If the logon does not specify a domain/realm value and a value is required, the system will default to the value stored in the LdapServerRealm property of the LDAP mechanism. Normally the default value is correct, but the security administrator must check to make sure. If the LdapServerRealm property value is not correct, the administrator can change the value in the configuration file or require that users enter the correct value as part of the logon. If the system defaults to an incorrect LdapServerRealm property value or if the user submits an invalid value as part of the logon string, the system will return an error message. Security Administration 67

Chapter 5: Logon Requirements and Controls Logon Elements Related Topics For information on LDAP mechanism properties and how to set them, see Mechanism Properties on page 144 For information on how to specify the realm/domain value in a logon string, see Network Logon Formats on page 72. Appended Domain Name Appending the domain name to the username may be necessary to ensure that every logon name is unique across all domains for users that are authenticated externally. For example, without the domain name, joe@domain1 has the same username as joe@domain2. Teradata Database can be configured to append the domain name for external authentication for mechanisms that provide domain information, including the following: KRB5 SPNEGO NTLM LDAP, if all of the following are true: The directory is Active Directory Teradata Database is running on Windows The value of the LdapServerRealm property is set to a value other than. For further information, see LdapServerRealm on page 165. Warning: Teradata strongly recommends that you do not begin using Append Domain Name in Release 13.0, because it will be discontinued in a future release. If you are already using this feature it will continue to work for Release 13.0, but you should discontinue use as soon as it is convenient to do so. To check on whether the Append Domain Name feature has been set up, do the following: 1 Query the Append Domain Name value of the Gateway Control GDO -d option to determine what name will be used to identify the user. If Append Domain is set to no, username will be used. If Append Domain is set to yes, the name used depends on the logon mechanism: If the mechanism does not provide a domain name, username will be used. If the mechanism provides a domain name, username@domainname will be used. 2 To change the current value, toggle it by entering the -F option for the gtwcontrol command. For further information about the gtwcontrol utility, see Utilities. gtwcontrol -F 3 The database will accept appended domain names only if the corresponding usernames are defined in the database as username@domainname. For example, for user joe for domain domain1, you must define the user something like the following: CREATE USER "joe@domain1" AS PERM=10000000, PASSWORD=pw1234; GRANT LOGON ON ALL TO "joe@domain" WITH NULL PASSWORD; 68 Security Administration

Chapter 5: Logon Requirements and Controls Logon Elements Note: Use this special format only for users that require an appended domain name. Passwords Users accessing Teradata Database are authenticated by the system when it determines that their username and password match. Although the username is the basis for identification, it is not usually protected information. It is openly displayed during interactive logon, on printer listings, and when session information is queried. The password, however, is stored in an encrypted form in Teradata Database. Because of its value to system security, you should never write down or compromise your password. Encourage all users to do the same. Submitting a Password for External Authentication Users that are externally authenticated submit their username and password to the external authentication agent rather than directly to Teradata Database. External authentication requires the following setup tasks: A GRANT LOGON statement containing the WITH NULL PASSWORD option must be submitted for each username that will request external authentication. Set either the gtwcontrol or dbscontrol flag to enable external authentication. For mainframe channel-connected systems, a security exit in the TDP must acknowledge that the logon string for this username is valid without a password. Related Topics For information on password format requirements and controls, see Password Format Requirements on page 93 and Password Control Options on page 97. For further information about authentication of users by external security applications, see External Authentication on page 52. For further information about security exits, see Teradata Director Program Reference. Tdpid In a Teradata Database logon string, the term tdpid refers to the name of the Teradata database system. Note: A Teradata database system can have more than one tdpid. Connections to the database can be subdivided into multiple tdpids, each one connecting to a separate host group. For information, see Restricting Logons by Host Group on page 89. The tdpid originates from one or more of the following sources depending on system configuration: In logons from network attached clients, the tdpid is the alias by which a Teradata Database system is known to the network, for example TDATSYS1. When connections to the database are set up directly within individual clients, tdpid is determined as follows: Security Administration 69

Chapter 5: Logon Requirements and Controls Logon Elements Account String For ODBC-based client applications, such as Teradata SQL Assistant, the tdpid is the value of the Name field in the ODBC driver setup. For Teradata CLIv2-based applications, such as BTEQ, the tdpid is the value of the dbcname parameter in the setup for the Teradata Call Level Interface (CLI). For logons from a channel-attached mainframe, the tdpid is the name of a Teradata Director Program that connects the mainframe to the database. System resource accounting requires the use of an account string to identify which account is to be charged for the space used by the user. Users can specify an account string at logon. If the logon does not include an account string, the system assigns a default value. You can assign accounts to users as part of the CREATE/MODIFY USER statement. Each username may have one or more associated account strings. The first account string assigned becomes the default. The account string may also be set up to include a priority-level Performance Group prefix code, which establishes the session priority. Priorities are useful when interactive users are competing for system resources with long-running batch applications. Related Topics For additional information on set up and use of account strings, see Database Administration. For details on the syntax needed to specify an account string for a user, see CREATE USER in SQL Data Definition Language. Using UTF-16 Characters in the Logon String Teradata Database supports the use of UTF-16 character sets in the logon string for the following authentication mechanisms: Teradata Method 1 (legacy systems) and Method 2 KRB5 (Kerberos) Lightweight Directory Access Protocol (LDAP) Microsoft Windows NT LAN Manager (NTLM) SPNEGO UTF-16 Logon Usage Notes The Teradata Gateway converts the logon character information to the specified session character set. Therefore, all of the Unicode characters used in the UTF-16 logon string must be in the repertoire of the session character set. For example: If a Chinese user specifies the session character set as ASCII, but enters CJK characters (not part of ASCII) for the username, a translation error will occur and the logon will fail even though they are valid UTF-16 characters. 70 Security Administration

Chapter 5: Logon Requirements and Controls Logon Elements Solution: Use the TD2 authentication method, which does not use session character set translations. Note: Teradata Database may still report an error if illegal characters are present in the logon string. For non-kanji systems, the workaround is for the user to enclose any non- ANSI compliant object names (such as username or password) in quotation marks. If a user specifies KanjiSJIS as the session character set but logs on with KanjiEUC characters that are not in the set, a translation error will occur and the logon will fail. Solution: Make sure that the logon characters are present in the session character set. Security Administration 71

Chapter 5: Logon Requirements and Controls Network Logon Formats Network Logon Formats You can gain access to Teradata Database through a Teradata client using one of three logon methods: Command Line logon Enter logon elements as shown in the following sections. GUI logon Enter the logon string elements as prompted by a GUI interface. Script logon (for scripts that do not contain a command line) Enter logon elements as script components. For instance, Teradata Parallel Transporter scripts submit logon elements as operator attribute values. Logon Requirements Determined by Authentication Type Logon Syntax The format and content required of a logon string are dependent on the selected authentication mechanism and its properties. The following authentication methods and logon variations are available to users logging on to Teradata Database: Teradata Database Authentication: Credentials submitted in the.logon statement External Authentication: Without resubmitting user credentials (Single Sign-on) Credentials in submitted in the.logon statement (UPN format only) Credentials in submitted in the.logdata statement (Authcid or UPN format) For detailed information on the requirements for setting up External Authentication, see External Authentication on page 52. Logon string information is comprised of three syntax elements. Use of these syntax elements is dependent on the authentication method being used. The three logon syntax elements and associated parameters are as follows:.logmech: Specifies the security mechanism, which defines the security context under which the session will operate. If the user does not specify this parameter,.logmech will use the default security mechanism. If no default is set, the logon will fail..logdata: Specifies the user credentials, username and password, for Authcid and UPN format external authentication logons. Note: LDAP logons allow specification of user=, profile=, and realm=, in cases where the directory user can be associated with multiple database users, profiles, or realms. These specifications require use of the.logdata statement to submit user credentials..logon: Can be used for both Teradata Database authentication or external authentication logons. 72 Security Administration

Chapter 5: Logon Requirements and Controls Command Line Logons Teradata Database authentication: Contains the tdpid, the Teradata Database username and password, and optional account string information. External authentication (except single sign-on): Contains the tdpid, the domain or directory username and password, and optional account string. Single sign-on: Contains only the tdpid and optional account string. The detailed content of the logon string depends on the agent that will authenticate the user and whether or not the agent will also authorize user privileges in the database. Command Line Logons Logons Using Teradata Database Authentication This type of logon sends user credentials directly to the database for user authentication. The TD2 mechanism sets the security context. Use the logon shown in Example 1 for all logons from a network-attached client that do not require external authentication. Example 1: Teradata Database Authentication.logmech TD2.logon tdpid/rhh,password The following table explains the logon terms used in Example 1. Logon Parameter Term Description.logmech TD2 Teradata Database Mechanism 2. This mechanism is used to initiate the security context using Teradata Database as the authenticating agent. The system will automatically defer to the TD1 mechanism, even if TD 2 is specified in the.logon command, in cases where the logon is done through Teradata Query Director in a replication system (dual active) and one of the replication destination systems is at V2R5.1. Logons authenticated by Teradata Database automatically defer to TD 2 (or TD 1, where appropriate), so users do not need to specify the.logmech parameter in the logon string for Teradata Database authentication..logon tdpid The tdpid identifies a specific Teradata Database system to which the logon will connect. rhh password A Teradata Database username. The password for the Teradata Database username. Security Administration 73

Chapter 5: Logon Requirements and Controls Command Line Logons Logons Using External Authentication External authentication allows network attached users to be authenticated by an external agent rather than by Teradata Database. Channel attached users cannot use this type of external authentication. Teradata Database must be properly configured to support external authentication and users must select a mechanism that supports it. For detailed information on the requirements for setting up external authentication, see External Authentication on page 52. Warning: The special username dbc cannot be used with external authentication since dbc cannot be granted the required LOGON WITH NULL PASSWORD privilege. If userdbc tries to log on using external authentication, the database will return error 3790. Single Sign-on Single sign-on allows users that have logged on to a client Windows domain to subsequently logon to Teradata Database without the need to resubmit their username and password. The domain username must match a Teradata Database username. The logon to the database must specify a security mechanism that supports single sign-on, and a tdpid. When the user subsequently logs on to the database, the authenticating agent passes the user credentials, which it has held since the original network logon, to the database so it can authorize the access privileges recorded in the database for that user. Single sign-on requires that the user select a supporting mechanism, which varies depending on how the client system is set up. It also requires that the SingleSignOn property be set to yes (the default) for the supporting mechanism. Example: Single Sign-on Variations.logmech mech_name.logon tdpid/,,"account" The following explains logon terms used in the Single Sign-on example on the preceding page: Logon Parameter Term Description.logmech mech_name The name of the security mechanism that specifies the authenticating agent. is shown as an example, but users can also specify the NTLM mechanism for single sign-on from clients that are configured for NTLM authentication. Specify KRB5 or NTLM for Single Sign-on from standard Windows clients, depending on which agent authenticates the user. Specify the SPNEGO for Single Sign-on from a.net managed Windows client. For information system on the set-up required to support single sign-on, see External Authentication on page 52. 74 Security Administration

Chapter 5: Logon Requirements and Controls Command Line Logons Logon Parameter Term Description.logdata Not required The.logdata field is not required for single sign-on. Credential information from the earlier user domain logon automatically passes to the database to authorize specific privileges associated with that user in the database..logon tdpid The tdpid is the name of the Teradata Database system to which the logon will connect.,, You do not need to submit the Teradata Database username and password as part of the.logon command for single sign-on. However, the username originally used to log on to the domain must match a Teradata Database username. The,, is required as a place holder if an account string is used. account Optional account string information LDAP Logons Directory users must log on to the database using a valid LDAP logon (also known as directory sign-on) and must specify the LDAP security mechanism. Users that do not use a valid logon will receive an error message if they select the LDAP mechanism. Note: Use of LDAP logons require that the system be set up for external authentication. For information, see System Requirements for External Authentication on page 53. The directory will authenticate directory users and authorize privileges to them according to the following rules: When the directory is not configured to map directory users to database objects: The LDAP mechanism AuthorizationSupported property must be set to no. Directory users can log on only if their usernames match a database username. A directory user can only exercise the privileges granted to the matching database user. Note: This configuration requires a Sign-on As formatted logon string. For information, see Sign-on As on page 81. When the directory is configured to map directory users to database objects: The LDAP mechanism AuthorizationSupported property must be set to yes. Note: If the LDAP AuthorizationSupported property is set to no, LDAP will ignore directory user mapping to database objects, even if such mapping exists. Directory users can log on only if they have at least one mapping to one or more Teradata Database objects. Directory users mapped to a Teradata Database user inherit the database user privileges. If the directory user is mapped to any additional profiles or external roles, those privileges take precedence over the privileges inherited from the database user. Security Administration 75

Chapter 5: Logon Requirements and Controls Command Line Logons Directory users not mapped to database users, roles, or profiles, and who only require limited database access, can be mapped to the system-generated EXTUSER to provide a low level of database access without the need for additional administrative tasks. Note: Directory users mapped to database profiles or roles, and not mapped to a database user, automatically receive PUBLIC privileges. The directory can only authorize privileges that have been defined in the database. Submittal of directory user credentials is unaffected by the AppendDomainName DBSControl GDO. LDAP Logon Formats The LDAP mechanism supports two logon formats: Authcid logons UPN logons LDAP Authcid Logons Examples in this section cover the authcid logon format. For information on use of the UPN format for LDAP logons, see LDAP UPN Logons for Mapped Directory Users on page 79. Related Topics For information on how to setup directory users for external authentication and authorization, see Directory User Management Options on page 209. For information on uses of the AuthorizationSupported property and how to edit its value, see AuthorizationSupported on page 146. For further information about directory user privileges (including EXTUSER) and how to map directory users to database users, roles, and profiles, see Chapter 9: Directory Management of Database Users. Directory users can use the authcid form of LDAP logon. Contrary to what is allowed for UPN logons, authcid logons only allow entry of user credentials in the.logdata statement. Example.logmech ldap.logdata authcid=diruser password=directorypassword user=databaseusername profile=profile realm=realmname.logon tdpid/,,"account" The following explains the logon terms used in Example 1: Logon Parameter Term Description/Usage.logmech ldap LDAP is the only mechanism that supports authentication by a directory. 76 Security Administration

Chapter 5: Logon Requirements and Controls Command Line Logons Logon Parameter Term Description/Usage.logdata authcid=diruser The directory username. All valid directory username formats are supported, including common variations where the directory user name is a complex name that includes an @ or @@. For example: authcid=diruser@@password authcid=diruser@domain authcid=diruser@domain@@password Note: The system interprets everything to the right of the = as the username. The password must still be entered separately in the form password=dirpassword, as shown below. password=dirpassword user=databaseusername profile=profilename The directory user password. The following conditions impose additional requirements for the content of the.logdata statement to accurately define user characteristics: As shown in the example, individual specifications within the.logdata statement must be separated by white spaces. If the directory is not configured to map directory users to database objects and the AuthorizationSupported property of the LDAP mechanism is set to no, the directory username must match a Teradata Database username. If the directory user is mapped to more than one database user, include the following to specify the user privileges in force for the session. user=<databaseusername> If the directory user is mapped to two database users and one of them is the system generated EXTUSER, include the additional term user=extuser in the.logdata statement only if you want to employ EXTUSER. If the user= term is not used, the logon will defer to the mapped database user and ignore EXTUSER. If the directory user is mapped to one or more database users and also to a profile, the session will defer to the separately mapped profile instead of the profile belonging to the database user. If a directory user is mapped to more than one profile, add profile=<profilename> to the.logdata statement to specify the session profile. If the directory is Sun Java System Directory Server and the database tracks audit tail IDs, note that the value used for AuditTrailID is limited to 30 characters. If the authcid exceeds 30 characters in length, the AuditTrailID is truncated at 30 characters. Therefore it is recommended that all authcids be unique for their first 30 characters. For further information about auditing user access to the database, see Chapter 7: Monitoring Database Activity. Security Administration 77

Chapter 5: Logon Requirements and Controls Command Line Logons Logon Parameter Term Description/Usage.logdata (continued) realm=domain (also realm=realm) In some situations, users may need to specify a realm value as part of the.logdata statement. To be valid, the realm must offered by the directory. A realm specification is not required if: The LDAP mechanism is not setup for SASL/DIGEST-MD5 authentication. The LDAP mechanism is set for SASL/DIGEST-MD5 authentication (the default) and any of the following is true: The directory offers only one SASL realm, and the LdapServerRealm property is set to the default, or the name of the SASL realm offered. The directory offers more than one SASL realm, and the LdapServerRealm property is set to the name of one of the SASL realms offered. A realm specification is required if: The LDAP mechanism is set for SASL/DIGEST-MD5 authentication (the default), the directory offers more than one realm, and the value of the LdapServerRealm property is to (the default). Note: Users will not normally know the configuration of system parameters affecting realm specification. Administrators should create a security handbook to help inform users about logon requirements and other site-specific security conventions. Realm Specification: The realm specification must match the name of a realm advertised by the directory. For most directories this is fully qualified DNS name of the directory, in the form: realm=fqdnsname. However, some directories may advertise the realm differently. Processing the Specified Realm: If the logon does not specify a realm and the LdapServerRealm property value does not yield a valid realm, the logon will fail. If the realm specified in the logon is not offered by the directory, the logon will fail. If the realm specification is not needed but is specified in the logon anyway, the logon will succeed if it is a valid specification. For information on LDAP mechanism properties and how to set them, see Mechanism Properties on page 144..logon tdpid The tdpid specifies the name of the Teradata Database system to which the logon will connect.,, Substitute,, for Teradata Database username and password, which are not required for an LDAP logon. The,, is required only if an account string is used. account Optional account string information 78 Security Administration

Chapter 5: Logon Requirements and Controls Command Line Logons LDAP UPN Logons for Mapped Directory Users Mapped directory users can logon with UPN formatted credentials submitted in either the.logon or.logdata statement, with some limitations. Many of the logon requirements for UPN logons are the same as those for Authcid logons, and are not repeated in this section. For details on logon elements common to all LDAP forms of logons, see LDAP Logons on page 75. Note: Unmapped directory users logging on with UPN credentials must use the Sign-on As format. Sign-on As is also required when the LDAP AuthorizationSupported property is set to no, whether or not directory users are mapped. For information, see Sign-on As on page 81. UPN Credential Format UPN credentials can be entered in either of two places in the logon string: the.logdata statement the.logon statement UPN Credentials in the.logdata Statement You can enter UPN format user credentials in the.logdata statement as either: dirusername@@password username password=password When entering UPN credentials in a.logdata statement, the following rules apply: A UPN logon must contain a username. Where @@ is used: The entry immediately to the left of the @@ must be a username. The entry immediately to the right of the @@ must be a password. Additional logon elements such as profile=profilename must follow the UPN and must be separated by white spaces. UPN Credentials in the.logon Statement Enter user credentials in UPN format in the.logon statement as follows: dirusername,password Additional logon elements such as profile=profilename are not allowed in the.logon statement. Therefore, logons that require such statements cannot use the.logon form. Example 1: LDAP UPN Logons Using the.logdata Statement The following example shows how to enter UPN credentials for mapped directory users in the.logdata statement of an LDAP logon string..logmech ldap.logdata dirusername@@dirpassword user=databaseusername profile=profilename realm=domain.logon tdpid/,,"account" Security Administration 79

Chapter 5: Logon Requirements and Controls Command Line Logons The following table explains the logon terms used in Example 1: Logon Parameter Term Description.logmech ldap The authenticating mechanism. LDAP is the only mechanism that supports logons by mapped directory users..logdata dirusername The directory user name. The directory username and password can also be entered in the form: username password=password @@dirpassword user=databaseusername profile=profilename The directory user password. The following additional requirements apply to the.logdata statement: If the logon must specify user=, profile=, or realm= in the.logdata to select among multiple users, profiles, or realms, enter the specification in the.logdata as follows: user=<databaseusername> Specifications must be separated by white spaces within the.logdata statement, and must follow the UPN credentials. This table includes only the descriptions that are unique to UPN-style LDAP logons. For explanations of those elements common to both authcid and UPN logons (there are many), see the explanatory table in LDAP Authcid Logons on page 76..logon tdpid/ The tdpid identifies the network alias of the Teradata Database system to which the logon will connect.,, Substitute,, for Teradata Database username and password, which are not required for an LDAP logon. The,, is required only if an account string is used. account Optional account string information. Common Errors with LDAP UPN Logons The following table shows some common format errors that are not allowed in the.logdata statement of a UPN logon: 80 Security Administration

Chapter 5: Logon Requirements and Controls Command Line Logons Example of Format Error diruser@@dirpassword authcid=diruser diruser@@dirpassword password=dirpassword user=teradatauser diruser@@dirpassword Reason not Allowed Duplicate user information Duplicate password information UPN token must be the first token Example 2: LDAP UPN Logons Using the.logon Statement The following example shows how to enter UPN credentials for mapped directory users in the.logon statement of an LDAP logon string. Note: Directory users that must specify realm=, user=, or profile= to unambiguously define the session realm, user, or profile cannot specify UPN credentials in the.logon statement..logmech ldap.logon tdpid/diruser,password,"account" The following table explains the logon terms used in Example 2: Logon Parameter Term Description.logmech ldap The authenticating mechanism. LDAP is the only mechanism that supports logons by mapped directory users..logdata Not applicable When specifying user credentials in the.logon statement, specifying.logdata is not allowed..logon tdpid/ The tdpid identifies the network alias of the Teradata Database system to which the logon will connect. dirusername dirpassword account The directory username. Note: If the directory is not configured to map directory users to database objects, and/or the LDAP AuthorizationSupported property is set to no, directory users must logon using the Sign-on As UPN protocol. For details, see Sign-on As on page 81. The directory user password. Optional account string information. Sign-on As If a user is identified with the same username by both the external authenticating agent and the database, the user can sign-on as the database user. Use of Sign-on As requires completion of the set up tasks shown in System Requirements for External Authentication on page 53. The user must select a mechanism that corresponds to the external agent that will do the authentication from among the following mechanisms: Security Administration 81

Chapter 5: Logon Requirements and Controls Command Line Logons KRB5 SPNEGO NTLM LDAP (if the LDAP AuthorizationSupported property is set to no) Once the external agent has authenticated the user, it passes the user s credentials to the database so for authorization of user access privileges associated with the database username. The examples that follow are from a BTEQ script. Interactive logons prompt the user to enter.logdata information on a separate line from the.logdata command. For more detailed information on logon for a specific client application, see the users guide for that application Example 1: Sign-on As with UPN Credentials in the.logdata Statement The following example shows how to execute a Sign-on As logon using UPN credentials in the.logdata statement of the logon string..logmech mech_name.logdata username@@password.logon tdpid/,,"account" Explanation of Example 1 The following explains the logon terms used in Example 1: Parameter Term Description.logmech mech_name The name of the authenticating mechanism. UPN logons must specify the mechanism that supports the external security agent that authenticates the user. Observe the following requirements: The KRB5, NTLM, LDAP and SPNEGO mechanisms support Sing-on As. When executing a Sign-on As logon through a.net managed application, you cannot use the KRB5 or NTLM mechanism. When specifying the LDAP mechanism for a Sign-on As logon, the LDAP AuthorizationSupported property must be set to no..logdata username A network or directory user name that matches a Teradata Database username. You can also use the form username password=password for Kerberos, NTLM, and SPNEGO Sign-on As logons. LDAP does not support this option. @@password The user password for the authenticating agent, not the Teradata Database password. 82 Security Administration

Chapter 5: Logon Requirements and Controls Command Line Logons Parameter Term Description.logon tdpid/ The tdpid identifies the network alias of the Teradata Database system to which the logon will connect.,, The,, is a place-holder for UPN credentials that appear in the.logdata, and are only required if an account string is specified. account Optional account string information Example 2: Sign-on As with UPN Credentials in a.logon Statement The following example shows how to execute a Sign-on As logon using UPN credentials in the.logon statement of the logon string..logmech mech_name.logon tdpid/username,password,"account" Explanation of Example 2 Logon Parameter Term Description.logmech mech_name UPN logons must specify the mechanism that supports the external security agent that will authenticate the user. Observe the following requirements: The KRB5, NTLM, LDAP and SPNEGO mechanisms support Sign-on As. When executing a Sign-on As logon through a.net managed application, you cannot use the KRB5 or NTLM mechanism. When specifying the LDAP mechanism for a Sign-on As logon, the LDAP AuthorizationSupported property must be set to no. Note: Sign-on As LDAP logons ignore any mapping to Teradata Database users, roles, and profiles. For LDAP logons that consider mapping of directory users, see LDAP UPN Logons for Mapped Directory Users on page 79..logon tdpid/ The tdpid identifies the network alias of the Teradata Database system to which the logon will connect. username password account Submit a username that matches a Teradata Database username. The expression username,password replaces the,, that is present when user credentials are submitted in the.logdata statement. The user password for the authenticating agent, not the Teradata Database password. Optional account string information Security Administration 83

Chapter 5: Logon Requirements and Controls GUI Logons Common Errors with UPN Logons The following table shows some common format errors that are not allowed in the.logdata statement of a UPN logon. Example of Format Error diruser@realm@@dirpassword authcid=diruser diruser@realm@@dirpassword password=dirpassword profile=teradataprofile diruser@realm@@dirpassword user=teradatauser diruser@realm@@dirpassword Reason not Allowed Duplicate user information Duplicate password information UPN style token must be the first token UPN style token must be the first token GUI Logons GUI applications provide logon dialog boxes to allow users to specify logon data and a security mechanism. A following is a typical logon dialog box. Figure 1: Typical Client Logon Dialog Box The parameter values required by the dialog box are the same as those required for the command line logons listed in the previous section. 84 Security Administration

Chapter 5: Logon Requirements and Controls Logons Through Teradata Query Director After entering the required information, click the Mechanism button and the Mechanism dialog box will be displayed as shown below: Note: If you do not specify a mechanism, the system will use the default mechanism. Figure 2: Authentication Mechanism Dialog Box Once the dialog box appears, do the following: 1 Select the authentication mechanism to be used during the session. 2 Enter your authentication string. 3 Click the OK button to complete the logon task. For detailed information about logon requirements for a specific Teradata Database client application, see the user manual for that application. Logons Through Teradata Query Director If your network contains multiple Teradata Database systems, it may be set up so that logons pass through Teradata Query Director. Query Director routes the logon request to the Teradata Database system that will most efficiently process the query. As part of this process, the user credentials are delegated to Query Directory, which then passes them on to the database system it selects. Logons through Query Director require exactly the same logon information as normal logons, but you can only use the following security mechanisms: TD2 KRB5 Query Director must be running on Windows SPNEGO (Required for users logging on through a fully managed.net client) Query Director must be running on Windows LDAP Set mechanism property values as follows to support Query Director: Set the MechanismEnabled property value to yes in the client, the intermediary, and the database node TDGSS User Configuration files, for any of the mechanisms you plan to use for Query Director logons. Security Administration 85

Chapter 5: Logon Requirements and Controls Logons from Channel-Attached Systems Make sure the DelegateCredentials property value is set to yes only in the client system tdgssuserconfigfile.xml, for any of the following mechanisms you plan to use for Query Director logons: KRB5 (or SPNEGO for logons through fully managed.net clients) LDAP The TD2 mechanism does not require this change Ensure that the MutualAuthentication property value is set to yes for the KRB5 or SPNEGO mechanism on the client system TDGSS User Configuration file for single signon or UPN logons using Kerberos authentication. All other system setup requirements are the same as for normal use of these mechanisms. For details on editing mechanism properties, see General Rules for Editing on page 192. Logons from Channel-Attached Systems Channel-attached systems do not support network security features such as security mechanisms, encryption, or directory integration. Unless you have made modifications using the security functions in the Teradata Director Program (TDP), logons from a channelattached clients use only the.logon command, and are similar to the logon shown in Example1: Teradata Database Authentication on page 73. If you have made any TDP based changes to system security function the logon format you use may vary from the standard Teradata Authentication format. For information on the use of TDP functions to alter logon security requirements in a mainframe environment, see the chapter on security in Teradata Director Program Reference. Logons from Teradata Database Nodes In some cases, administrators may need to log on to Teradata Database from a database node, such as when using a utility to do internal system maintenance. Although communication among Teradata Database nodes is done across a network using TCP/IP, you probably will not need to exercise network security functions. Logons from a Teradata Database node are similar to the logon shown in Example1: Teradata Database Authentication on page 73, and should use only the.logon command. Replication Logons Some Teradata Databases may use the Replication feature, which ensures that changes to data on one database system are automatically captured and sent through an intermediary server (that directs the replication process) to another database system. Such automatic updates allow replication to maintain data equivalency between two separately addressable databases. 86 Security Administration

Chapter 5: Logon Requirements and Controls Logons from Fully Managed.Net Clients Each transfer of data requires that the intermediary server logon to both the initiator (source) system and the target (destination) system. The logon process is automatic for properly configured systems, and replication will use the following mechanisms: TD1 if the destination system is running V2R5.1. TD2 if the destination system is running V2R6.0 or above. Make sure the mechanisms you need are enabled in the TDGSS User Configuration files of both the database system(s) and the intermediary if you plan to use the Replication feature. Encryption of Replication Sessions You can choose whether or not to encrypt both control message transmissions and data transmissions when using the replication feature. Because many of the replication transmissions are automatic, choosing to encrypt replication transmissions cannot be done at logon, but must be done as part of the replication setup process, using the tam.ini file. For details about replication security options, see Golden Gate Operations Guide, Version 7.3 and Teradata Replication Solutions. Logons from Fully Managed.Net Clients Use the following rules for logons to Teradata Database from fully managed.net clients: Teradata Database must be at release 12.00.00.12 or greater. The client must be running.net Data Provider for Teradata version 12.0 or greater. Note: Installation of.net Data Provider only as required for compatibility with Teradata SQL Assistant 13.0 does not by itself constitute a fully managed.net client. The user must select from among the following mechanisms: TD2 LDAP (For all single sign-on and non-ldap Sign-on As logons) Note: Sites that require NTLM authentication for SSO and Sign-on As logons (instead of Kerberos) may be restricted in their use of.net applications, because NTLM is not supported for.net managed clients. Logon Errors In the event a user submits an erroneous logon string, the Gateway will, by default, return the following generic error message to the client: The User Id, Password, or Account is invalid This generic message is used by the Gateway instead of a failure-specific message to prevent unauthorized users from getting hints about why an attempted break-in has failed. Security Administration 87

Chapter 5: Logon Requirements and Controls Logon Controls Logon Error Handling Options Use the Gateway Control -n option to determine whether or not users will receive specific information about logon errors. When set to no (the default), all logon errors will return the same message to the client: The User Id, Password, or Account is invalid When set to yes, logon errors will return a message that describes the specific error encountered, such as: Invalid user password Teradata recommends use of the default generic message (the -n no setting) instead of failurespecific messages (the -n yes setting) to prevent unauthorized users from getting hints about why an attempted break-in to the system has failed. To aid administrators in debugging logon failures, the Gateway writes failure-specific error messages to the DBC.AccLog table regardless of how the -n option is set. This information is available to help administrators debug logon failures for authorized users and to detect attempted security breaches by unauthorized users. All tdgss-related errors are also written to the gateway log. For information on accessing the gateway log, see tdgss Configuration Errors on page 238. Logon Controls Granting Logons Revoking Logons The following controls are available to modify user logon privileges. Revoke logons from users who no longer require access to the database. Grant logons to users whose logon privileges were previously revoked. Grant and revoke logons to users only on specific host groups. Restrict logons by client IP address. Teradata Database automatically grants logon permission to all created users from all client system connections by default. Granting logon privileges is only necessary for users whose logon privileges were previously revoked. A usernames must exist in Teradata Database before it can be the subject of a GRANT/ REVOKE LOGON statement. Revoke logons using the REVOKE LOGON statement, in the form: REVOKE LOGON ON hostid FROM userid You can revoke: all logons for a user or list of users 88 Security Administration

Chapter 5: Logon Requirements and Controls Logon Controls Precedence of Clauses all logons to a host group or list of host groups logons for a user or list of users to a host group or list of host groups A REVOKE LOGON statement inhibits only future logon attempts; it does not affect users who are currently logged on. Use the GRANT LOGON statement to reinstate logon privileges for a user with revoked logon privileges. For GRANT and REVOKE statement options, see SQL Reference: Data Definition Statements. Rules created by a GRANT LOGON or REVOKE LOGON statement are enforced according to the host group and user ID clauses in the statement. More specific clauses contained in a current GRANT or REVOKE statement take precedence over the more general clauses in a previous GRANT or REVOKE statement, based on the following hierarchy: ON ALL AS DEFAULT (most general) ON hostid AS DEFAULT ON ALL TO userid ON hostid TO userid (most specific) For example: GRANT LOGON ON ALL TO A is superseded by: REVOKE LOGON ON hostid TO userid Restricting Logons by Host Group You can control access to Teradata Database for a large group of users by disabling logons for a host group associated with a set of connections to the database. Clients that connect through the disabled host groups are subsequently denied access to the database. Clients using other connections are not affected. Note: The database defaults to a single host group, HGID 1. Strategy for Use Use the following strategy to set up the system to allow disabling of logons by host group. 1 Configure PDE to define multiple host groups using the Vconfig utility. Each host group is shown as a separate HGID in the vconfig.txt file. Note: This step is normally done by a Teradata Customer Service representative (CSR). 2 Configure the database to define multiple hosts using the Configuration utility ADD HOST command. Each host must include the same vprocs as the corresponding host group in Vconfig. You can verify the current host configuration using the LIST command. Note: This step is normally done by a Teradata Customer Service representative (CSR). Security Administration 89

Chapter 5: Logon Requirements and Controls Logon Controls 3 The network administrator must assign multiple aliases (tdpids) to the Teradata Database system, with each tdpid mapped to a set of COP names and IP addresses, which corresponds to a configured host group. 4 The network administrator then assigns a Teradata client or group of clients to a single tdpid corresponding to a host group. The host group and tdpid can later be disabled without affecting clients assigned to other tdpids. 5 Make sure you understand the relationship between the host group (HostNo), tdpid, and networked clients so you disable the correct host group. 6 You can then disable a particular host group in either of two ways: a b To revoke all logons to a host group, use the REVOKE LOGON statement in the form: REVOKE LOGON ON hostid AS DEFAULT where hostid corresponds to a host group (HostNo value). You can limit the restriction to a user or comma-separated list of users with the clause: FROM userid Use the Gateway Global utility DISABLE LOGONS as follows: i ii Use the SELECT HOST command to identify the host group to be disabled. Use the DISABLE LOGONS command to disable logons through the selected host. Usage Notes Controlling database access by host groups is subject to these constraints: REVOKE LOGON ON hostid is meant for use with networked clients. Teradata recommends using REVOKE LOGON FROM username for controlling access by mainframe users. By default a client can log on to the database through all tdpids to which the client is connected. For Teradata Database nodes on Windows and Linux: All COP connections assigned to the same tdpid should be in the same host group. A LAN card can be part of more than one host group, but each host group must have a separate IP address. By default each LAN card connects to only a single IP address. Each LAN card allows multiple parallel sessions. Teradata recommends that you do not define individual IP address connections or COP connections in such places as the Teradata ODBC driver or the client host file. These connections will override DNS assignments and could compromise the setup for REVOKE LOGON ON hostid. Related Topics For information on setting up client host connections, see: ODBC Driver for Teradata User Guide Teradata Call Level Interface Version 2 Teradata Director Program Reference 90 Security Administration

Chapter 5: Logon Requirements and Controls Logon Controls For details about host setup using the Configuration utility, or enabling and disabling of logons by host using the Gateway Global utility, see Utilities. For syntax and options for the REVOKE LOGON statement, see SQL Data Control Language. Restricting Logons by IP Address Teradata Database provides the capability for administrators to restrict access to the database based on the IP address of the machine from which a user logs on. You can impose restrictions on users defined in the database and on directory users mapped to them. IP restrictions can restrict database access: to some or all users logging on from a particular IP address to users logging on from some IP addresses, while allowing the same users access from other IP addresses Note: Logon restriction by IP address is not practical for users who logon through Teradata Query Director or other middle-tier applications because the Gateway will only see the IP of the middle-tier application. Creating IP Access Restrictions To restrict user logons by IP address, you must execute a unique setup for each IP restriction. The data that defines the IP restriction can be created in either of two ways: as a structure of schema objects in a supported, LDAP-compliant directory as an XML flat file describing the restrictions on users, which resides in the database To complete the setup, you must transfer the data from either the directory or the XML document to a GDO, which is read by the Gateway when checking a user IP address. The directory based solution also requires that you load IP related Teradata Database schema extensions into the directory. Related Topics For information on creating and using IP address restrictions, see Appendix I Password Restricted Words on page 367. For details about loading IP-related schema extensions into a directory and setting attributes of schema objects, see Chapter 9: Directory Management of Database Users. Security Administration 91

Chapter 5: Logon Requirements and Controls Logon Controls 92 Security Administration

CHAPTER 6 Creating and Managing Passwords Teradata Database provides a number of controls to aid in password administration and enhance password security. Creating Passwords You must assign a password when you submit a CREATE USER statement. The format of the password must conform to system enforced password format requirements, as well as the password format control parameters maintained in the DBC.SysSecDefaults dictionary table. When you create a new user, the PasswordChgDate parameter in DBC.SysSecDefaults is set to 0 by default. The zero value indicates that the password initially assigned to the user is a temporary password, so it need not be unique. Temporary passwords expire at the first logon users are prompted to create their own passwords, which are likely to be easier for them to remember than passwords created for them by others. Note: The system will not recognize a password as temporary unless passwords are set to expire. Set password expiration using either the global ExpirePassword attribute or the EXPIRE parameter of the user profile. For information on setting password expiration, see Password Control Options on page 97. The system validates each new or modified password against default format requirements and settable format control parameters when the administrator submits the SQL statement that creates it, and when users create new passwords to replace their temporary passwords. An error message results whenever a password violates a password format rule. Caution: Users should never write down passwords or share them with other users. Related Topics For CREATE/MODIFY USER syntax, see SQL Data Definition Language. For information on password encryption, see Logon Encryption on page 61. Password Format Requirements Teradata Database accepts any string for a password as long as it conforms to the default, system requirements. Some password rules may only make sense in a multibyte environment. The following password format requirements affect all users unless the administrator exercises one or more password control options that supersede them: Allowable Password Characters The following characters are allowed in a password: Security Administration 93

Chapter 6: Creating and Managing Passwords Creating Passwords 1 to 30 characters (UTF-8 or UTF-16 characters) Letters A through Z and/or a through z Digits 0 through 9 in single-byte or multi-byte form Note: A password can be all-numeric only if it is enclosed in quotes as shown in the following example: password= 12341234 The following special characters, in either single-byte or multi-byte form: $ (dollar sign) _ (underscore) # (pound sign) Other special characters may be used if they are not specifically prohibited by the rules in the following section and if the password is enclosed in quotes ( ). Password Characters Not Allowed The following characters are not allowed in a password: Katakana symbols Multibyte spaces Special characters other than $ (dollar sign), # (pound sign), or _ (underscore) that are not enclosed in quotes. The error character for both Kanji1 and Latin Digits 0 through 9 when they are the first character in the name, unless the entire the password is enclosed in quotes as shown in the following example: password= 78password Greek and Cyrillic characters User-defined characters The first character cannot be a digit unless the password is enclosed in double quotes. The password cannot consist entirely of blank characters The NULL character (U+0000) CHARACTER TABULATION (U+0009) LINE FEED (U+000A) LINE TABULATION (U+000B) FORM FEED (U+000C) CARRIAGE RETURN (U+000D) SPACE (U+0020) Password Differences Between Japanese and Non-Japanese Systems These additional system-specific rules for Japanese and Non-Japanese systems also apply: On Japanese Systems For Japanese sessions (KatakanEBCDIC and those with names ending in _0I, _0S, _0U): The rules are the same as those noted above in the basic rules. 94 Security Administration

Chapter 6: Creating and Managing Passwords Forgotten Passwords and Password Lockouts For non-japanese sessions: Object names can only have characters in the following inclusive ranges: U+0001 through U+000D U0015 through U+005B U+005D through U+007D or U+007F Note: In particular, do not use REVERSE SOLIDUS (U+005C) and TILDE (U+007E). On Non-Japanese Systems For all sessions, any character translatable to Teradata Database Latin can be used in object names, except as noted in the basic rules. Related Topics For detailed requirements on object names, see SQL Fundamentals. For details on the supported Kanji character sets, Teradata Database internal JIS encoding, and the valid character ranges for Kanji object names and data, see International Character Set Support. Password Sharing Among Character Sets Prior to Teradata Database 12.0, a password could only be shared with systems using the character set in which it was created. From Release 12.0 forward, all passwords are converted to Unicode before being encrypted and are sharable among all supported character sets. Related Topics For detailed requirements on object names, see SQL Fundamentals. For details on supported Kanji character sets, Teradata Database internal JIS encoding, and valid characters for Kanji object names and data, see International Character Set Support. Forgotten Passwords and Password Lockouts If a user forgets his password, or you set a maximum for erroneous logon attempts and a valid user becomes locked out, submit a MODIFY USER or MODIFY PROFILE statement with the RELEASE PASSWORD LOCK option. To replace a forgotten password, use the MODIFY USER statement with the FOR USER option to provide a new temporary password. MODIFY USER JDoe AS PASSWORD = mysecret FOR USER; The old password is replaced by mysecret, and the FOR USER specification causes the system to reset the value for the PasswordChgDate parameter in the DBC system table to 0. The 0 value then causes the existing password to expire at the next logon. Security Administration 95

Chapter 6: Creating and Managing Passwords Forgotten Passwords and Password Lockouts Note: Resetting to a temporary password does not update the DBC.OldPasswords table and the password string is not verified with password reuse rules. However, it is updated when the user changes his own password. The user will not be prompted to replace the temporary password unless passwords are set to expire. For a password to expire, a non-zero value must appear for: ExpirePassword in DBC.SysSecDefaultsV or if profiles are used, EXPIRE in the profile of which the user is a member Password expiration is a basic security protocol that should be in use for all Teradata Database systems. Teradata recommends that password expiration be set for between 90 and 270 days. If you are unsure whether or not passwords are set to expire on your system, execute one of the following SQL statements to check the value: SELECT ExpirePassword FROM DBC.SecurityDefaultsV; This global value affects all users. If the value is 0, you can reset it to a non-zero value. Teradata recommends that password expiration be set for between 90 and 270 days. Reset the value as follows: UPDATE DBC.SysSecDefaults SET ExpirePassword=90; Note: You must restart the database for this change to take effect. SELECT <ProfileName>, ExpirePassword FROM DBC.ProfileInfoV; This value affects only users that are members of the profile. If the value for EXPIRE is 0 or NULL, MODIFY the profile to specify a non-zero value, as follows: MODIFY PROFILE <profile_name> AS PASSWORD = (EXPIRE = 90); Keep in mind that changing the expiration value in either the profile or the system table will cause all affected user passwords to expire. Caution: Do not lose the password for user DBC! User DBC could be locked out because of exceeding the MaxLogonAttempts setting and only user DBC can modify user DBC! If this happens, contact Teradata Support Center to unlock DBC. Tracking Changes to Passwords The DBC.DBase table stores the date and time a password was last changed by a user. Query the DBC.UsersX view, which references the DBC.DBase table and other system tables, selecting the columns PasswordLastModDate and PasswordLastModTime, to see the latest activities against passwords. For example: SELECT UserName, PasswordLastModDate, PasswordLastModTime FROM DBC.Users; *** Query completed. 6 total rows found. 3 columns returned. *** Total elapsed time was 1 second. UserName PasswordLastModDate PasswordLastModTime 96 Security Administration

Chapter 6: Creating and Managing Passwords Password Control Options ------------------------------ ------------------- ------------------- DBC 07/06/25 12:15:27 TDPUSER 07/06/25 12:24:25 SystemFe 07/06/25 12:24:31 SysAdmin 07/06/25 12:24:31 Crashdumps 07/06/25 12:29:01 Sys_Calendar 07/06/25 12:29:0 Password Control Options Teradata Database offers several options for controlling password format and usage requirements to help administrators customize password security to meet individual needs. This section provides information on the following password control topics: A list of available password controls Location of password control tables and methods for editing: global password controls in the SysSecDefaults table using UPDATE password controls for particular groups of users by creating or modifying a profile A detailed review of each password control option, including: Description/purpose Usage strategies Default setting, range, and editing instructions Error messages related to password controls Teradata recommends that all sites maintain strong password controls. The following represents a best-practice approach, as shown in Appendix B: Running a Secure Teradata Database. Passwords must be at least 8 characters in length and not exceed 30 characters. Passwords must use a combination of alpha, numeric, and special characters. The username will be locked after 3 unsuccessful logons and stay locked for 5 minutes. The username cannot be part of the password. Passwords should expire at least every 90 days. Restrict reuse of passwords for at least 270 days. Controlling Passwords With Multibyte Characters Teradata Database 12.0 and up automatically converts all passwords to Unicode prior to applying password controls. Therefore, all character sets are subject to password controls. Password Controls Located in DBC.SysSecDefaults The DBC.SysSecDefaults table contains a set of global controls that restrict the usage and content of passwords for all users, as shown in the following table: Security Administration 97

Chapter 6: Creating and Managing Passwords Password Control Options Field Name Description Usage Controls ExpirePassword MaxLogonAttempts LockedUserExpire PasswordReuse The number of days that must elapse before a password expires. The number of erroneous logons allowed before the user is locked out. The number of minutes to elapse before a locked user is unlocked. The number of days that must elapse before a password can be reused. Format Controls PasswordMinChar PasswordMaxChar PasswordDigits PasswordSpecChar PasswordRestrictedWords Sets the minimum number of characters required in a password. Sets the maximum number of characters allowed in a password. Determines whether ASCII digits are: allowed in a password not allowed in a password required in a password Indicates whether or not ASCII special characters are: allowed in a password not allowed in a password required in a password You can place tight restrictions on passwords to require that: passwords must contain at least one ASCII alpha character passwords must contain a mixture of ASCII upper/lower case letters no password can contain a database username Determines whether or not passwords are rejected if they contain words in the Restricted Words list. Viewing Current Password Control Settings To see the current global default password control settings, SELECT all columns of the system view DBC.SecurityDefaults which shows the settings in the DBC.SysSecDefaults table: SELECT * FROM DBC.SecurityDefaultsV Using UPDATE to Manage Global Password Controls in DBC.SysSecDefault You can set global password control options in the SysSecDefaults table using an UPDATE statement as shown in the following example: UPDATE DBC.SysSecDefaults SET PasswordMinChar = 8 ; 98 Security Administration

Chapter 6: Creating and Managing Passwords Password Control Options For further information on password control strategies and allowable values when using UPDATE to change password control parameters, see Setting Password Controls on page 102. Using CREATE or MODIFY PROFILE to Password Controls for Specific Users You can use a CREATE or MODIFY PROFILE statement to override global password control parameters defined in SysSecDefaults and apply a password control only to those users assigned to the profile, as shown in the following example: CREATE PROFILE profile_name [ AS parameter_setting [...,parameter_setting ] ] ; MODIFY PROFILE profile_name AS parameter_setting [...,parameter_setting ]; The following is the existing PASSWORD parameter_setting: PASSWORD [ATTRIBUTES] = { (attribute = <val> NULL, [...,attribute = <val> NULL]) NULL } where attribute is one of the following in any order: EXPIRE = n MINCHAR = n MAXCHAR = n DIGITS = c SPECCHAR = c RESTRICTWORDS = c MAXLOGONATTEMPTS = n LOCKEDUSEREXPIRE = n REUSE = n For further information on password control strategies and allowable values for use with CREATE or MODIFY PROFILE, see Setting Password Controls on page 102. Effectivity of Password Controls Defined Within Profiles Password controls take effect differently when applied in a profile than when the controls are modified directly in the DBC.SysSecDefault table, as shown in the following table: Password Control Parameter EXPIRE Effectivity of Password Controls Applies to first level user to which the profile is assigned; effective immediately. Security Administration 99

Chapter 6: Creating and Managing Passwords Password Control Options Password Control Parameter MINCHAR and MAXCHAR DIGITS REUSE SPECCHAR RESTRICTWORDS MAXLOGONATTEMPTS LOCKEDUSEREXPIRE Effectivity of Password Controls Does not apply to first level user to which the profile is assigned, rather it applies only to the children of that user. Controls take effect at the first child user logon after the child is created or modified. Use an UPDATE statement to apply password controls to individual primary users that will CREATE/MODIFY the password controls of other users. Applies to first level user to which the profile is assigned, at the next logon attempt. Related Topics For the location of other information related to profiles, including the application of password controls to users, see the following: For more Information on... See... Administrative procedures for using profiles Detailed syntax and rules for creating, dropping, or modifying profiles and assigning them to users The special attributes of profiles that are applied to directory-based users Database Administration SQL Data Definition Language Roles and Profiles for Directory Users on page 215 100 Security Administration

Chapter 6: Creating and Managing Passwords Password Control Options Comparing Methods of Password Control Management The security administrator can reset the password control parameters shown in the SysSecDefaults table in two ways. Note: Password controls do not affect externally authenticated users because their passwords are validated outside the database. Reset Method Effects Guidelines for Use Change a parameter value using an UPDATE statement CREATE/MODIFY PROFILE Resets password control parameter(s) globally Warning: Since this is a global reset, it will undo all default control values for the parameters affected. Resets global password control parameter(s) only for members of the profile Note: Does not require a database restart-- all changes take effect at the next logon for the affected user Global password controls apply to all users logging on to Teradata Database regardless of the logical client system from which the logon is received. Teradata Database reads the DBC.SysSecDefaults table only at database startup. You must restart the database to allow it to read the DBC.SysSecDefaults table and make changed values take effect. After a database restart, changes to DBC.SysSecDefaults only take effect: When a new user is created with a CREATE USER statement. When an existing user password is modified with a MODIFY USER statement. When an existing user password expires and the user creates a new password in response to a system prompt. Password controls defined in a profile apply only to the children of users that are members of the profile, in order to separate administrator password controls from those of the users they create. To assign password controls to administrator level users, assign a profile that contains the controls to a super administrator that can then pass the controls down to the administrators. For information on the effectivity of individual controls when defined in a profile, see Effectivity of Password Controls Defined Within Profiles on page 99. Security Administration 101

Chapter 6: Creating and Managing Passwords Setting Password Controls Setting Password Controls ExpirePassword Teradata Database provides options to edit default password control parameters found in the DBC.SysSecDefaults table. The table contains default values, which are created by the dictionary initialization and conversion utilities along with the table itself when the Teradata Database software is installed. Note: Password control rules apply to both quoted and un-quoted passwords. The ExpirePassword parameter specifies the number of days a password is valid. Teradata Database automatically adds this value to the password change date value maintained in the database row for each created user. It then compares the result to the current date to determine if the password is still valid. Default Setting The default setting for the ExpirePassword parameter is 0: Passwords do not expire. Allowable Values The range of allowable values (in days) for ExpirePassword is 0 to 32767. If you enter a negative value, the system will accept the UPDATE, but the value will revert to the default 0 value at the next restart and will write an error message to the event log: 3698: SysSecDefaults table has a negative value in an integer column. Strategy Consider the value of data in the database and the likelihood of a security breach in determining a suitable password lifetime for your system. The United States Department of Defense recommends a maximum password lifetime of no more than one year. Administrators commonly set this parameter at three to six months (90 to 180 days). To set a temporary password, you must assign a non zero value to ExpirePassword. UPDATE Statement The following example shows how to use the UPDATE statement to reset the duration of password acceptance to 30 days: UPDATE DBC.SysSecDefaults SET ExpirePassword = 30 ; Expired Password Effects on a Session When a user attempts a logon with an expired password: The database will still establish a session for the first logon after expiration if the logon string contains the correct expired password. The session is limited to the use of MODIFY USER statement to establish a new password. After the password is modified, normal Teradata SQL activity is permitted in the session. 102 Security Administration

Chapter 6: Creating and Managing Passwords Setting Password Controls A second attempt to logon with an expired password will not be successful. If the user already has a session logged on and the password expires, the user can submit a MODIFY USER statement to establish a new password. If the current session is for a utility such as MultiLoad, which does not offer the MODIFY USER statement, the user must end the current session. The user must log off and log on again through a utility such as BTEQ, which allows use of the MODIFY USER statement. Using MODIFY USER to Replace an Expired Password Use the following SQL statement to establish a new password: MODIFY USER username AS PASSWORD = passwordname; The password is immediately valid for the number of days indicated in the ExpirePassword field of the DBC.SysSecDefaults table. For details, see the MODIFY USER syntax in SQL Data Definition Language. MaxLogonAttempts The MaxLogonAttempts parameter restricts the number of successive logon attempts allowed to a user who submits an incorrect password. If the number of erroneous logon attempts reaches the value specified in DBC.SysSecDefaults.MaxLogonAttempts, the system locks out the User ID from further attempts for the duration of the password lockout time, described later in this section. Further erroneous attempts during the password lockout time cause Event log entries containing User Locked as the event type. Default Value The default value of the MaxLogonAttempts parameter is 0: Allow unlimited logon attempts. The security administrator enters the number of allowable failed logon attempts into the DBC.SysSecDefaults table MaxLogonAttempts column. If you enter a negative value, the system will accept the UPDATE, but the value will revert to the default 0 value at the next restart and will write an error message to the event log: 3698: SysSecDefaults table has a negative value in an integer column Note: If user DBC exceeds maximum allowable logon attempts, user DBC could be locked out. In the event that this happens, the only way user DBC can log on is through the TSTSQL console. Contact your Teradata support representative for more information about TSTSQL console. Allowable Values The range of allowable values for MaxLogonAttempts is 0 to 127. A negative value is not allowed and will return an error message. Security Administration 103

Chapter 6: Creating and Managing Passwords Setting Password Controls UPDATE Statement The following example shows how to use the UPDATE statement to set the maximum number of failed logon attempts to three: UPDATE DBC.SysSecDefaults SET MaxLogonAttempts = 3 ; The system does not accept a null. A zero value prevents locking, but a negative value causes the system to write an error message to the event logan at the next restart. You must have the DROP USER privilege to execute the MODIFY USER statement. This privilege is usually made available to security administrators and system administrators as an option of the GRANT statement. For the discussion of the GRANT statement, see Chapter 2: Creating Users and Defining Access Privileges. Strategy When specifying the number of failed logon attempts to allow before locking out the user, consider the following alternatives: Allowing a greater number of failed attempts increases exposure to unauthorized access by means of sophisticated, repetitive logon methods. People make keyboard mistakes and forget passwords. Allowing too few failed logons may increase the number of legitimate user calls to the security administrator requesting password lock release. If shorter passwords are used, fewer erroneous attempts should be allowed. If longer passwords are used, more attempts can be allowed. Valuable or sensitive data may justify fewer allowed failures (for example, two or only one in extreme cases). Less sensitive data may allow more attempts (for example, three or four, or no lockout at all). Rescuing Locked-Out Users To break through the password lockout before the allotted time has elapsed, use the MODIFY USER statement to release the lock on the user, as shown in the following example: MODIFY USER username AS RELEASE PASSWORD LOCK; For details, see the MODIFY USER syntax in SQL Data Definition Language. 104 Security Administration

Chapter 6: Creating and Managing Passwords Setting Password Controls PasswordReuse The PasswordReuse parameter defines a time span during which a user cannot reuse a previously used password. When a user changes a password, Teradata Database records the old password and the current date. The next time the user attempts to change a password, Teradata Database compares the new password to the current password. If they are equal, the system rejects the new password. If they are not equal, the list of passwords previously assigned to the user is searched for one equal to the one being proposed. If a match is found and the number of days between the date when the old password was modified (last available for use) and the current date are less than the site specified reuse time, then Teradata Database does not allow the password change. Teradata Database keeps track of previously used passwords for at least the time over which reuse is denied. Default Value The default value for the PasswordReuse parameter in 0: Allow immediate password reuse. Allowable Values The range of allowable values (in days) for PasswordReuse is 0 to 32767. A zero value allows an immediate reuse of the password. If you enter a negative value, the system will accept the UPDATE, but the value will revert to the default 0 value at the next restart and will write an error message to the event log: 3698: SysSecDefaults table has a negative value in an integer column Strategy The United States Department of Defense recommends that passwords not be reused for at least six months after expiration. Furthermore, the reuse denial period should be at least as long as the password lifetime. UPDATE Statement The following example shows how to use an UPDATE statement to set the PasswordReuse lock duration to 60 days: UPDATE DBC.SysSecDefaults SET PasswordReuse = 60 ; Password History To aid in researching password reuse status, Teradata Database saves all previously used passwords in a dictionary table (DBC.OldPasswords) defined under user DBC. When users successfully change their password: A row containing the current password is written to DBC.OldPasswords when the password is created. DBC.OldPasswords also contains all previous passwords that cannot currently be reused based on PasswordReuse rules. Teradata Database automatically deletes old password rows for the user with a date earlier than the current date minus the PasswordReuse time span. Security Administration 105

Chapter 6: Creating and Managing Passwords Setting Password Controls Note: If an administrator resets a user password, the system will not enforce any PasswordReuse restriction that might normally apply to that password. PasswordReuse restrictions only apply when users reset their own passwords. The DBC.OldPassword table contains the following information: Table 3: OldPasswords Column Descriptions Column UserName PasswordDate EncryptionFlag PasswordSalt EncryptedPassword EncryptedPassword Length Description Identity of the user to which the password was assigned. Date the password was changed for the user. Identifies whether the password is encrypted by DES or SHA-256. SHA Standard seed needed to encrypt the password. Encrypted password string. DES encrypted passwords = 8 bytes SHA-256 passwords created in V2R6.2 = 27 bytes SHA-256 passwords created in Teradata Database 12.0 and up = 32 bytes LockedUserExpire (Password Lockout Time) The LockedUserExpire parameter sets the length of time a user is locked out for exceeding the maximum number of logon attempts (MaxLogonAttempts). Default Value The default value for LockedUserExpire is 0: Do not lock user on erroneous password. Allowable values The acceptable range of values for the LockedUserExpire parameter is 0 to 32,000 minutes (about 23 days). The administrator can specify an indefinite lockout by entering a value of -1. Strategy When specifying the password lockout time, consider the following: Legitimate users sometimes make mistakes entering passwords. They should not be locked out for long periods if they make one or two erroneous attempts. Legitimate users could be locked out by a malicious process that initiated erroneous logons. If the lockout time is long, such a process could quickly lock out all users. The administrator can also specify an indefinite lockout by entering a value of -1. A zero value can be used for immediate lock release, which disables the password lockout time feature until the value is reset. UPDATE Statement The following UPDATE statement to sets the duration of user lock to two minutes: UPDATE DBC.SysSecDefaults SET LockedUserExpire = 2 ; 106 Security Administration

Chapter 6: Creating and Managing Passwords Setting Password Controls PasswordMinChar The PasswordMinChar parameter sets the minimum required characters for a valid password. Default Value The default value of PasswordMinChar is 1: The password must have at least one character. Allowable Values Set the value for PasswordMinChar in the range from 1 to 30, and not less than the minimum number of characters implied by other rules. For instance, if at least one digit, one special character, and a mixture of upper and lower case letters is required by other option settings, then the PasswordMinChar setting must be at least four. If you enter a 0 or negative value, the system replaces the value with the system default value and writes an error message to the event log at the next restart. Strategy The United States Department of Defense recommends that passwords consist of eight or more characters. When specifying a password length, consider a longer password if security is critical. However, keep in mind that because it is more difficult to remember a longer password, the user is more likely to write it down rather than memorize it--and it is strongly recommended that users do not write passwords down. UPDATE Statement Use the following form to set the minimum number of characters in a password: UPDATE DBC.SysSecDefaults SET PasswordMinChar = 6 ; PasswordMaxChar The PasswordMaxChar parameter sets the maximum characters allowed for a valid password. Default Value The default value of PasswordMaxChar is 30; a maximum of 30 characters in a valid password. Allowable Values Set the value for PasswordMaxChar within the range from 1 to 30, and greater than or equal to the maximum number of characters implied by other option settings. For instance, if at least one digit, one special character, and a mixture of upper and lower case letters is required by other option settings, then the PasswordMaxChar setting must be at least four. If you enter a 0 or negative value, the system replaces it with the system default value and writes an error message to the event log at the next restart. Strategy When specifying the maximum password length, keep in mind that some users may try to create a password of maximum length. Users are more likely to write long, hard-to-memorize passwords, posing a security risk. Security Administration 107

Chapter 6: Creating and Managing Passwords Setting Password Controls UPDATE Statement Use the following form to set the maximum number of characters in a password: UPDATE DBC.SysSecDefaults SET PasswordMaxChar = 8 ; PasswordDigits The PasswordDigits parameter determines how ASCII digits may be used in a password. Default Value The default value for the PasswordDigits parameter is Y: Digits are allowed in a password. Allowable Values The acceptable values for the PasswordDigits parameter are: Y = Digits are allowed N = Digits are not allowed R = At least one digit is required The values are not case sensitive. If you enter a value other than Y, N, or R, the system reverts to the default value and writes an error message to the event log: 3699: SysSecDefaults table has an invalid character value in a char column Note: You cannot use the digits 0 through 9 as the first character in a password unless the entire password is enclosed in quotes, as shown in the following example: password= 78password Strategy Many passwords would be relatively easy for an intruder to guess, especially if some of the letters are known. Forcing users to create passwords with one or more digits enhances password security. UPDATE Statement Use the following form to set the option for digits in a password: UPDATE DBC.SysSecDefaults SET PasswordDigits = R ; PasswordSpecChar The PasswordSpecChar parameter determines how ASCII special characters can be used in a password. It includes the following options: special characters are allowed/not allowed/required passwords must contain at least one alpha character no password can contain the database username passwords must contain a mixture of upper/lower case letters 108 Security Administration

Chapter 6: Creating and Managing Passwords Setting Password Controls Default Value The default value of the PasswordSpecChar parameter is Y: special characters are allowed in a password username is allowed in the password string alpha characters are allowed but not required mixed upper and lower case characters are allowed but not required Allowable Values Teradata Database has simplified the set up of special character options by allowing a single character to represent each valid combination of the four options. The values are not case sensitive. The PasswordSpecChar setting applies to both quoted and unquoted passwords. Use the following rule key when choosing the combination of special character options you want to use from the table that follows: Status Indicator Y N R Description Allowed but not required Not Allowed Required If you enter a value other than Y, N, or R, the system reverts to the default value and writes an error message to the event log: 3699: SysSecDefaults table has an invalid character value in a char column The following table shows the available SPECCHAR options: If you enter this Password SPECCHAR Option... You get this combination Special Character Option rules UserName Mixture of Upper and Lower Case letters At least One Alpha Character Special Characters N, n Y Y Y N Y, y Y Y Y Y A, a Y Y Y R B, b Y Y R N C, c Y Y R Y D, d Y Y R R Security Administration 109

Chapter 6: Creating and Managing Passwords Setting Password Controls If you enter this Password SPECCHAR Option... You get this combination Special Character Option rules UserName Mixture of Upper and Lower Case letters At least One Alpha Character Special Characters E, e Y R R N F, f Y R R Y G, g Y R R R H, h N Y Y N I, i N Y Y Y J, j N Y Y R K, k N Y R N L, l N Y R Y M, m N Y R R O, o N R R N P, p N R R Y R, r N R R R Strategy Forcing users to create passwords with one or more of the special character options enhances password security. It also may make the password harder for the user to remember and to type in at logon. Consider these two factors when deciding how elaborate the password special character requirements should be for your system. UPDATE Statement Use the following form to set the option for digits in a password: UPDATE DBC.SysSecDefaults SET PasswordSpecChar = R ; PasswordRestrictWords The PasswordRestrictWords parameter determines whether or not a password is subject to the content restrictions defined in the RestrictedWords list. A default set of Restricted Words is automatically installed when a system is upgraded to Teradata Database 12.0 or greater. For a list of the restricted words automatically added to the system when upgrading to Teradata Database 12.0 or greater, see Appendix I: Password Restricted Words. Default Value The default value for the PasswordRestrictWords parameter is N: Do not restrict any words from being contained within a password string. 110 Security Administration

Chapter 6: Creating and Managing Passwords Setting Password Controls Allowable Values The acceptable values for the PasswordRestrictWords parameter are: Y = Words in the Restricted Words list are not allowed in a password string. N = Words in the Restricted Words list have no effect on the content of a password string. The values are not case sensitive. UPDATE Statement Use the following form to set the option to restrict words in a password: UPDATE DBC.SysSecDefaults SET PasswordRestrictWords = Y ; If you enter a value other than Y or N, the system reverts to the default value and writes an error message to the event log: 3699: SysSecDefaults table has an invalid character value in a char column Strategy Many passwords would be relatively easy for an intruder to guess, especially if they contain common words or names. Forcing users to create passwords that do not use common words or names enhances password security. Adding and Removing Restricted Words You can add words to the Restricted Words list, using the following form: INSERT into PasswordRestrictions values ( newrestrictedword ) Note: Although the default Restricted Words list is composed of English words, the words you add can be in any supported character set. You can also remove words from the list using the following form: DELETE from PasswordRestrictions WHERE (RestrictedWords= wordtobedeleted ) Determining if a Password Contains a Restricted Word Use the following procedure to determine if a password contains a restricted word: 1 Remove all ASCII numbers and ASCII special characters from the beginning and end of the password string. 2 Use the resulting string (the stripped password) in the query: SELECT*FROM DBC.PasswordRestrictions WHERE UPPER(RestrictWords)=UPPER( StrippedPassword ) Security Administration 111

Chapter 6: Creating and Managing Passwords Setting Password Controls Error Messages The following error messages are associated with password control parameters. Message Number Description 3684 The password submitted contains too few characters. 3685 The password submitted contains too many characters. 3686 Digits may not be used in passwords. 3687 Special characters may not be used in passwords. 3698 SysSecDefaults table has a negative value in an integer column. 3699 SysSecDefaults table has an invalid character value in the char column. 6988 The password submitted must contain at least one alpha character. 6989 The password submitted must contain at least one numeric character. 6990 The password submitted must contain at least one special character. 6991 The password submitted must contain at least one lower case character and at least one upper case character. 6992 The password submitted cannot contain the user name. 7948 A significant part of the password submitted contains a restricted word. 112 Security Administration

CHAPTER 7 Monitoring Database Activity Breaches of database security can easily pass unnoticed unless data is corrupted. To maintain adequate security you should set up logging of database activity and conduct regular audits of the logs. Monitoring Options and Objectives The following summarizes Teradata Database logging and monitoring options and objectives: Use Teradata Database logging functions to provide an audit trail of database events that can be used to monitor security violations. The system automatically generates a log for all database logons and logoffs. You can enable additional logging functions to track user activity within the database, including the database objects accessed and the actions requested. Data dictionary views automatically provide a complete listing of database user attributes and privileges for use in security investigations. Session-related views track user access by session. Establish procedures for regular monitoring of all access logs. Regularly monitor access logs to ensure that users are only performing activities that they have been explicitly authorized to do. Determine the frequency of log reviews based on risk factors such as the value, sensitivity, and criticality of the data, past experiences of system compromise or misuse, and the extent to which the system is accessible through non-secure networks. Periodically archive aged log data to keep the logs from growing too large, while retaining logging history for use in security investigations. Access Logging of Database Users Default Logging By default, the database logs user logon and logoff activity by user defined in the database. All other logging must be explicitly enabled using the BEGIN LOGGING statement. Logging of externally managed users, such as directory users, may require setup tasks in addition to those listed in this section. Security Administration 113

Chapter 7: Monitoring Database Activity Access Logging of Database Users For additional setup tasks required for logging... See... directory users Access Logging of Directory Users on page 118 proxy users Access Logging of Proxy Users on page 119 Requirements for Using BEGIN/END LOGGING Statements The BEGIN and END LOGGING statements enable and disable logging. You can execute these statements only if: The DIPACC DBCSQL script, included the Teradata Database software, was run to create the special security macro DBC.AccLogRule and the system was reset to initialize the macro. These activities are standard during installation of the Teradata Database software. The user executing the BEGIN/END LOGGING statement was granted the privilege to EXECUTE the DBC.AccLogRule macro. Using BEGIN LOGGING to Enable Logging Functions Use the BEGIN LOGGING statement to start the logging of user requests to access the database. Each time a user attempts to execute an action against a database object, Teradata Database performs one or more database privilege checks. The rules defined in the DBC.AccLogRuleTbl table, using the BEGIN LOGGING statement, determine which of these checks should be logged in the DBC.AccLogTbl table. The BEGIN LOGGING statement can request logging of one, all, or any combination of the following items: A particular action (for example, CREATE TABLE, DELETE TABLE, GRANT, SELECT) The complete text of the SQL request Frequency of access Name of the requesting user Objects referenced Use the END LOGGING statement to terminate logging for an action, user, or object for which log entries are currently active. For further information, see Disabling Access Logging with the END LOGGING Statement on page 117. General Rules for Using DDL Statements in Access Logging The BEGIN LOGGING and END LOGGING statements are DDL statements, and must follow these general rules for DDL statement usage: You cannot combine a DDL statement with other statements as part of a multi-statement request. 114 Security Administration

Chapter 7: Monitoring Database Activity Access Logging of Database Users You can only include a DDL statement in an explicit transaction, that is, one or more requests bracketed by BEGIN TRANSACTION and END TRANSACTION statements, if the DDL is: the only statement in the transaction or, structured as a single-statement request that appears as the last request in the transaction In addition, access logging must specify database objects, such as tables, by name. The system generates log entries only when a subsequent user request specifies the object by the same name. For example, a BEGIN LOGGING statement specifying: FIRST SELECT ON DatabaseA.Table1 causes a log entry to be generated only if the access statement specifies the object by name: SELECT... FROM Table1 Logging will not occur if the object is specified in a view, macro, or stored procedure, such as: SELECT... FROM View1_of_Table1 EXECUTE MACRO1 where Macro1 contains the following statement: SELECT... FROM Table1 CALL SpSample1 where SpSample1 contains the following statement: SELECT... FROM Table1 For details on the BEGIN LOGGING statement, see SQL Data Definition Language. DBC.AccLogRuleTbl Entries DBC.AccLogTbl Entries When you execute a BEGIN LOGGING statement it creates logging rules, which are stored in the DBC.AccLogRuleTbl table. When logging is enabled, Teradata Database looks in DBC.AccLogRuleTbl to determine which privilege checks will generate log entries for a specified database user, action, or object. Using the END LOGGING statement terminates access logging on the database objects specified in the statement. If the END LOGGING statement terminates all logging rules for a particular user, database, or object, the system deletes the row from DBC.AccLogRuleTbl. The system generates a log entry only if a logging rule is present and active for the object, action, or user whose privilege is being checked. When Teradata Database finds one or more active rules, it logs the specified privilege checks in the DBC.AccLogTbl table. Security Administration 115

Chapter 7: Monitoring Database Activity Access Logging of Database Users Database Level Logging A logging entry does not necessarily indicate that a statement was executed; rather, it indicates that the system checked on the privileges necessary to execute the statement. The corresponding row in DBC.AccLogTbl will show either a denied or a granted entry. Log entries may contain one or two names: The user logon name is always present in a log entry. If the access right being checked is for other than the logon name, the second name is also present in the log entry as the owner name. For example, if a user submits an EXECUTE statement for a macro, the system checks the database privileges of the logon username for the EXECUTE statement. The system also checks the database privileges for individual statements within the macro for the owner of the macro. When a BEGIN LOGGING statement specifies logging at the database level, actions requested against all objects in that database will generate log entries. To illustrate this, assume that DatabaseA contains several tables, and that the INSERT privilege was granted to PUBLIC on Table1 only. Note: PUBLIC (meaning everyone) is a keyword that allows you to retrieve information using the SELECT statement. Assume also that a current statement specifies: BEGIN LOGGING ON FIRST INSERT ON DatabaseA Subsequently, if users other than the owner submit INSERT statements against tables in DatabaseA, the log entries are: A granted entry for the first insert into Table1 A denied entry for the first attempt at an insert into any other table in DatabaseA The logging rules consider the sequence when multiple actions take place in one session. Therefore, requests that apply the same action to two separate tables in database might not be logged as separate actions. For example, assume that DatabaseA contains Table1 and Table2, and a current BEGIN LOGGING statement specifies logging on FIRST INSERT for DatabaseA. Even if rows are inserted into both Table1 and Table2 in the same session, the logging results in a single entry identifying the table that was the object of the first insert. Table Level Logging If the access right is at the database level but the logging specification is at the table level, only actions against the table are considered for logging entries. Therefore, the absence of a database privilege at the table level may not always result in a log entry. The system generates a single log entry for the table according to the results of privilege checks at both the table level and the database level as follows: If either check succeeds the system generates a granted entry. 116 Security Administration

Chapter 7: Monitoring Database Activity Access Logging of Database Users If both checks fail the system generates a denied entry. Using BEGIN LOGGING With GRANT The following statement begins logging and saves the statement text for each occurrence throughout the entire system of CREATE or DROP USER, or CREATE or DROP DATABASE statements that also use GRANT: BEGIN LOGGING WITH TEXT ON EACH USER, DATABASE, GRANT ; Logging MODIFY Statements Users can employ the MODIFY statement in the following ways: MODIFY DATABASE MODIFY PROFILE MODIFY USER While most SQL statements require database privilege checks and therefore generate log entries, MODIFY is not a privilege that can be granted, so the MODIFY privilege is never checked. However, users must have the DROP privilege to use MODIFY. To log MODIFY operations, specify the DROP privilege in BEGIN LOGGING statements for DATABASE, PROFILE, and USER. BEGIN/END Logging Errors For further information on using MODIFY statements, see SQL Data Definition Language. If the system identifies a syntactic or semantic error in a BEGIN or END LOGGING statement, then it returns an error message to the user with no logging of the statement. Disabling Access Logging with the END LOGGING Statement Use the END LOGGING statement to terminate access logging on any user, action, or object for which one or more logging rules are currently active. An END LOGGING statement generates an error if a corresponding BEGIN LOGGING is not currently in effect for the database name specified in the END LOGGING. Also observe the following: Logging begun for specific usernames cannot be ended by simply omitting the BY username option in an attempt to apply the END LOGGIN generally. The END LOGGING statement erases text flags for the specified actions in relation to a user or object. However, the frequency syntax cannot be included in END LOGGING statements because it is restricted. To disable access logging, use the following procedure: 1 Query the DBC.AccLogRules view to display the list of BEGIN LOGGING statements currently in effect: SELECT * FROM DBC.AccLogRulesV; Security Administration 117

Chapter 7: Monitoring Database Activity Access Logging of Directory Users 2 Submit an END LOGGING statement for each BEGIN LOGGING statement in the list that you want to end. Note: To stop all log activity, you must issue one END LOGGING statement for every rule displayed, and then complete Steps 3 and 4. 3 Issue a DROP MACRO for DBC.AccLogRule macro if you are ending all logging. 4 Do a TPA reset to set the change. Note: If you do not issue END LOGGING statements for every rule currently shown in DBC.AccLogRules, access logging continues even after you drop the DBC.AccLogRule macro and reset the database Access Logging of Directory Users Access logging of directory users generally conforms to the rules for logging of database users set forth in the preceding sections, except as follows. For the purpose of access logging, directory users are identified and logged by their directorybased identifiers. The identifier is supplied by the Gateway when a session is established and stored in DBC.SessionTbl.AuditTrailId view. The identifier stored depends on the type of directory, as follows: Directory Active Directory Active Directory Application Mode (ADAM) Novell edirectory Sun Java System Directory Server ID Supplied for Access Logging The AuditTrailID that is returned is a packed version of the Global Unique Identifier (GUID). The AuditTrailID has the following characteristics: 27 characters in length First character is A The remainder of the AuditTrailID may be composed of: the letters of the alphabet the numbers 0 through 5 This directory does not support GUIDs, so the AuditTrailID is the value of the authcid property in the logon string used to bind to the directory. The value used for AuditTrailID is limited to 30 characters. If the authcid exceeds 30 characters in length, it is truncated at 30 characters. Therefore it is recommended that all authcids be unique for their first 30 characters. The use of directory-based identifiers affects system monitoring in the following ways: A SELECT USER request normally returns the current user for a session. When a directory-based user is logged on, a SELECT USER request returns either: the name of the permanent user to which the directory user is mapped the authcid of the directory user (if not mapped to a permanent user) 118 Security Administration

Chapter 7: Monitoring Database Activity Access Logging of Proxy Users A SELECT ROLE request returns the current role for the session. If the directory user is mapped only to the system-generated pseudo user, EXTUSER, the initial current role for a directory-based logon is a dummy role called EXTERNAL. Any time the directoryassigned roles are enabled, a SELECT ROLE request returns EXTERNAL as its result. Setting up the Gateway to Identify Directory Users in Access Logs Users from several directories or domains may have access to the same database. To help clarify which directory user has actually logged on, you can also set the GTWControl utility -f option to append the domain name from which the logon originated onto the username specified in the logon string. This feature works for mapped directory users only, and is available where the directory is Active Directory or Sun Java Directory Server and Teradata Database is running on Windows. Note: The append domain name feature is deprecated beginning with Teradata Database 12.0 and will be removed in a future release. Teradata recommends that you do not initiate use of this feature for Release 12.0 and higher. Sites that began using the feature before Release 12.0 can continue to use it until it is removed. As an alternative, directory users can log on using the LDAP UPN logon format, which includes the domain name as part of the username. For information on... See... LDAP UPN logons LDAP UPN Logons for Mapped Directory Users on page 79 directory user access logging Access Logging of Directory Users on page 217 Access Logging of Proxy Users A trusted session occurs when a middle-tier application that is configured as a trusted user logs on to Teradata Database. Subsequently, proxy users can request services from the application that involve access to the database. If access or query logging are enabled, Teradata Database records activities of the proxy user in any records inserted into the associated log tables and views, as follows: If the end user is a proxy user and employs the username of an individual, the logs will contain records of individual activities. If the proxy user employs a group user identity, the log cannot differentiate individual activities. In these cases the application can submit name:value pairs in the Set Query Band statement to provide information about the end user. In addition to storing the entire query band string that is in effect at the time of the access or query, log records include a ProxyUser column, which can be queried for purposes of access and query auditing. Note: If the middle-tier application and associated end users are not set up for trusted sessions, all application users that log on to Teradata Database through the application appear Security Administration 119

Chapter 7: Monitoring Database Activity Monitoring Security Related Tables and Views Example 1 in the logs as the same user, that is, the username employed to authenticate the application when it logged on. For more on trusted sessions, see Accessing the Database Through a Middle-tier Application on page 56. The following examples show typical access and query logs for proxy user activity. SEL ProxyUser(FORMAT 'X(10)'), QueryBand(FORMAT 'X(45)'), StatementText(FORMAT 'X(25)') from DBC.AccessLogV order by LogDate, LogTime; *** Query completed. 3 rows found. 3 columns returned. *** Total elapsed time was 1 second. ProxyUser QueryBand StatementText -------------------------------------------------------- ---------------------------- DG708 =S> PROXYUSER=DG708;PROXYROLE=web;App=eCRM SEL * from table5; DG708 =S> PROXYUSER=DG708;PROXYROLE=web;App=eCRM INS table5(c1val,c2val); DG708 =S> PROXYUSER=DG708;PROXYROLE=web;App=eCRM SEL * from table5; +--------+---------+--------+--------+--------+--------+--------+------+------+------ Note: =S> indicates that this is a session query band. Example 2 SEL ProxyUser(FORMAT 'X(10)'), ProxyRole(FORMAT 'X(10)'), querytext(format 'X(40)') from DBC.QryLogV where username='ecrm' order by StartTime, queryid; *** Query completed. 4 rows found. 3 columns returned. *** Total elapsed time was 1 second. ProxyUser ProxyRole QueryText ---------- ---------- -------------------------------------------------------------- DG708 Web SET QUERY_BAND = 'PROXYUSER=DG708 DG708 Web SEL * FROM table5; DG708 Web INS table5(c1val,c2val); DG708 Web SEL * FROM table5; +--------+--------+--------+--------+--------+---------+--------+------+------+------ Monitoring Security Related Tables and Views Teradata Database stores various types of security information in data dictionary tables residing in the DBC system database. Views derived from these tables contain access logs and related security data, including user, role, and profile information. Although the views are generated as part of system setup, most of them require execution of an SQL statement such as BEGIN LOGGING before they are populated with data. The following describes the security-related views available from the data dictionary. View Name Description Access Logging Views 120 Security Administration

Chapter 7: Monitoring Database Activity Monitoring Security Related Tables and Views View Name DBC.AccessLogV DBC.AccLogRulesV DBC.DeleteAccessLogV DBC.LogOnOffX DBC.LogonRulesV DBC.SecurityLogX Description The underlying table for this view is DBC.AccLogTbl. Each entry in AccLogTbl indicates the results of a privilege check performed against a Teradata SQL request. Privilege checks are based on the criteria defined in a BEGIN LOGGING statements. Lists the logging rules defined in BEGIN LOGGING statements that the system uses to determine which privilege checks should result in entries being generated in the DBC.AccLogTbl table. Lists the entries from the access log by date and time to aid in removing aged data. You can only remove entries more than 30 days old. For example, to remove all entries over 30 days old, type the statement: DELETE FROM DBC.DELETEACCESSLOG ALL ; Lists logon and logoff activity, the associated user, session number, and attempted logon events. Event data indicates why a logon attempt was unsuccessful. For unsuccessful logons, the table stores the string Non-existent User, instead of the username used in the logon. Lists users that were subjects of a previous GRANT LOGON or REVOKE LOGON statements. Also indicates the users that were granted WITH NULL PASSWORD privileges, which allows them to be externally authenticated. These entries are used by the system to determine whether to allow or prevent system access. Lists a subset of the data on privilege checking from DBC.AccLogTbl, limited to username, table, database, logon time, and account. Privilege checks are based on the criteria defined in a BEGIN LOGGING statements. User and Privilege Views DBC.AllRightsX DBC.AllRoleRightsV DBC.RoleInfoX DBC.RoleMembersX DBC.UsersV DBC.UserGrantedRightsV DBC.UserRightsV Lists all automatically or explicitly granted privileges for a user or database, and the objects on which the privileges were granted. Lists all privileges granted to each role. Lists the name of the creator for each role. Lists each role and all of its members. The RoleMembersX view lists each role directly granted to the user, and which one, if any, is the default role. Lists information about all users defined in the database. The information is derived from system table DBC.DBase. Lists the explicit privileges that a user has granted to other users. Lists all database privileges explicitly granted to each user. It does not list the implicit privileges for the users. Security Administration 121

Chapter 7: Monitoring Database Activity Monitoring Security Related Tables and Views View Name DBC.UserRoleRightsV Description Lists all roles, including any nested roles, available to each user, along with the privileges granted to each role. Does not list directory users or any external roles to which they may be mapped. Password Control Views DBC.ProfileInfoX DBC.RestrictedWordsV DBC.SecurityDefaultsV Lists all profiles and associated parameter settings. Use this view to check the password control settings for a profile. Lists words that cannot be included in a password string when the RestrictedWords control is enabled. Lists the current global password controls and associated values. Viewing Log Entries Deleting Aged Log Entries You can query the Access Log records and include a join to the DBC.LogOnOffX view. The following query would display SQL statements executed by user DBADMIN along with the IP address and OS user account for the logon that created the associated session: SELECT a.username, a.logdate, a.logtime, StatementText, LogonSource FROM DBC.AccessLogV AS a, DBC.LogOnOffX AS b WHERE a.username = 'DBADMIN' AND a.sessionno = b.sessionno ORDER BY 2, 3 ; Include a WHERE clause in the DELETE statement to purge aged log entries. Use the view name DBC.DeleteAccessLogV in the DELETE statement. For example, to delete entries older than 90 days, type the statement: DELETE FROM DBC.DELETEACCESSLOGV WHERE LogDate < (Date - 90) ; If you do not specify the WHERE LogDate option, the statement deletes all entries older than 30 days by default. The view contains logic to retain a 30-day minimum of logging entries. For more information on the DELETE statement, see SQL Data Manipulation Language. 122 Security Administration

Chapter 7: Monitoring Database Activity Querying Systems Views Querying Systems Views MONITOR Related Queries You can use system views to review information concerning security settings, user privileges, and user activities using SQL in the following form: SELECT * FROM <view_name> ; You can use all parameters of the SELECT statement to query system views. For example: SELECT * FROM DBC.AccLogRulesV ; SELECT * FROM DBC.AccessLogV WHERE AccessType = CP ; You can monitor the use of production control features using SELECT queries. Example 1: Identifying Which Users Can Force Other Users Off the System Use this query to identify users that have the ABORT SESSION (AS) privilege, which allows them to force other users off the system: SELECT DISTINCT UserName FROM DBC.AllRightsX WHERE AccessRight = AS ; Example 2: Identifying Users Recently Forced Off the System Use this query to identify users that were forced off the system in the past two days: SELECT DISTINCT UserName FROM DBC.LogOnOffX WHERE Event = Forced Off AND LogDate > DATE - 3 ; Example 3: Identifying Current MONITOR Function Users Use this query to identify users currently using the MONITOR function: SELECT UserName, IFPNo FROM DBC.SessionInfoX WHERE Partition = MONITOR ; Querying Session-Related Views You can monitor database access at the session level using one or more of these session-related views: DBC.LogOnOffX DBC.LogonRulesV DBC.SessionInfoX For more information on all system views, see Data Dictionary. Security Administration 123

Chapter 7: Monitoring Database Activity Querying Session-Related Views DBC.LogOnOffX DBC.LogonRulesV This view provides information about the success and duration of user sessions, in addition to LogonSource information. This view is helpful when you need to know about failed attempts to log on. This query returns a list of failed logon attempts that occurred in the last seven days: SELECT LogDate,LogTime,UserName (FORMAT 'X(10)'),Event FROM DBC.LogOnOffX WHERE Event NOT LIKE ('%Logo%') AND LogDate GT DATE - 7 ORDER BY LogDate, LogTime ; LogDate LogTime UserName Event --------------------------------------------------------- 07/07/30 08:55:22 Unknown Non-existent User 07/10/21 08:59:53 BRM BAD ACCOUNT This view is derived from the DBC.LogonRuleTbl table. It contain the results of each successfully processed GRANT LOGON statement and returns the current logon rules, including whether or not the user has WITH NULL PASSWORD privileges. This query requests all logon rule entries, sorted by username: SELECT * FROM DBC.LogonRulesV ORDER BY UserName ; The response shows that user SQL19 cannot log on using host ID 207, and that users SQL18 and SQL20 can log on without a password. User Name -------------- SQL18 SQL19 SQL20 LogicalHostId --------------- 1024 207 207 LogonStatus ------------ G R G NullPassword ----------- T F T DBC.SessionInfoX This view provides information about users who are currently logged on, including the session source (host connection, logon name, and application), query band, the current partition, collation, role, password status, type of transaction, LDAP status, and audit trail ID. For information about collections of sessions initiated under the same logon, use the DISPLAY POOL command. For details, see Teradata Director Program Reference. If you use a multi-tier client architecture, the LogonSource field of this view can provide distinct source identification as it originated from the server tier, including the user ID and application name. Note: Data strings for TCP/IP sessions are inserted into the LogonSource field by CLIv2, which truncates strings exceeding 128 bytes. 124 Security Administration

Chapter 7: Monitoring Database Activity Querying Session-Related Views Example: Querying Session DBC.SessionInfoX Using BTEQ Teradata BTEQ 13.00.00.00 for MVS. Enter your logon or BTEQ command:.logon tdpv/socal.logon tdpv/socal Password: *** Default Character Set Name 'EBCDIC ' *** Logon successfully completed. *** Transaction semantics are BTET. *** Total elapsed time was 0.58 seconds. BTEQ -- Enter your DBC/SQL request or BTEQ command: sel logonsource from dbc.sessiontbl; sel logonsource from dbc.sessiontbl; *** Query completed. 5 rows found. One column returned. *** Total elapsed time was 0.44 seconds. LogonSource -------------------------------------------------------------------- (TCP/IP) 05BF 155.64.116.42 IETTST 818 DBADMIN BTEQ 01 LSS (TCP/IP) 06F9 208.199.59.157 NAG2N2 1396 POINT BTEQ 01 LSS (TCP/IP) 04DC 10.243.71.25 PW_OLD 2462 ROOT ARCMAIN 01 LSS MVS TDRT D48734 BATCH CS210041 SOCAL BTQMAIN MVS TDPV AN1005 TSO AN1005 SOCAL IKJFT01 The first three lines report network-connected sessions. The last two lines report channelconnected sessions. The fields are described in the following table. Field Description Value in Example 1 First Connection name or type (literal) (TCP/IP) (TCP/IP) (TCP/IP) Second Port or socket identifier 05BF 06F9 04DC Third IP address of the client (host) 155.64.116.42 208.199.59.137 10.243.71.25 Fourth Teradata Director Program Identifier (TDPID) IETTST NAG2N2 PW_OLD Fifth Client process/thread identifier 818 1396 2462 Security Administration 125

Chapter 7: Monitoring Database Activity Querying Session-Related Views Field Description Value in Example 1 Sixth Username used in this session DBADMIN POINT ROOT Seventh Name of the application through which the session was initiated BTEQ BTEQ ARCMAIN Eighth All network sessions (literal) 01 01 01 Ninth All network sessions (literal) LSS LSS LSS 126 Security Administration

CHAPTER 8 TDGSS Administration Teradata Database security features are bundled into security mechanisms, which can be selected by the user at logon, and which are administered by the Teradata Database Generic Security Services (TDGSS) library. TDGSS provides a number of security options that are usable with little or no administrator intervention, as installed with each Teradata Database release. Administrators can optionally edit mechanism properties and perform other setup procedures to meet more complex, site-specific security requirements. Note: The TDGSS features are primarily applicable to sessions logged on from networkattached clients. This is because channel-attached clients inhabit a closed system, and are not susceptible to the same threats as networked clients. For information on specifying a security mechanism in a logon string, see Chapter 5: Logon Requirements and Controls. TDGSS Standards The basis for Teradata Database network security is the Teradata Database Generic Security Services library (TDGSS). TDGSS is a general purpose, configurable, extendable security interface that is used by both the Teradata Gateway and the client. TDGSS is an extension of the industry-standard GSS-API, as defined by Internet Engineering Task Force (IETF) Request for Comments (RFC) 2743, Generic Security Service Application Program Interface Version 2, Update 1. TDGSS supports popular security frameworks, such as GSS-API (UNIX) and SSPI (Windows), as well as internal Teradata Database security methods. The TDGSS library provides a common interface so that security applications do not have to be written to interface directly with Teradata Database code. TDGSS helps to simplify the setup and maintenance of network security by providing security administrators with the following features: Pre-configured security mechanisms that each defines a set of security functions Editable configuration files that allow you to set mechanism property values to meet your unique security needs A set of tools for configuring and managing network security functions Security Administration 127

Chapter 8: TDGSS Administration TDGSS Installation and Maintenance TDGSS Installation and Maintenance TDGSS is part of the Teradata Database and Teradata Client software and must be installed on every client station and every server node, as follows: On every client machine: One copy of TeraGSS (the TDGSS client package) For Windows clients, TeraGSS is compatible with both FAT and NTFS file formats. Note: For TDGSS installation purposes set up peripheral computers, such as the administrative work station (AWS) and non-tpa nodes, as clients. Windows clients running Windows.Net applications require the installation of.net Data Provider for Teradata. A separate copy of TeraGSS, necessary for security functions on sessions originating from Windows.Net applications, is automatically installed with.net Data Provider for Teradata. On every server node: One copy of TDGSS (the TDGSS server package) One copy of TeraGSS (the server also uses some of the client security functions when an administrator logs on to the database from a node) TDGSS for Channel-Attached Clients Teradata Client software for channel-attached systems does not include TeraGSS because TDGSS-related security features are only available to network-attached clients. However, all Teradata Database nodes, even if they only talk to channel-attached clients, still must have both TDGSS and TeraGSS installed to enable network communication among nodes. Versions and Version Switching You are not required to update the TDGSS or TeraGSS packages when you upgrade Teradata Database or Teradata Tools and Utilities to a new version. However, upgrading of these packages to the latest version is part of the normal upgrade process for Teradata Database. Note: If the client and server are not updated to the latest version of TDGSS and TeraGSS, you will only be able to use the security features common to the active versions. For a particular release, the TDGSS version number matches the Teradata Database version number. The TeraGSS versions on the client and server may be revised independently and may or may not match the TDGSS version number for a particular Teradata Database release. Do not make any edits to the TDGSS User Configuration file (tdgssuserconfigfile.xml) that are new to a version of Teradata Database until you are sure that you will not need to back down (switch back) to a previous version. Some edits that are required to enable functions in a new version of Teradata Database may not be compatible with previous versions. For detailed information on installation of TeraGSS on a client system, see Teradata Tools and Utilities Installation Guide for Microsoft Windows, or a similar title (depending on your client operating system) for the Teradata Tools and Utilities release used by your system. 128 Security Administration

Chapter 8: TDGSS Administration TDGSS Installation and Maintenance Locating TDGSS Files For detailed information on installation of TDGSS or TeraGSS on the Teradata Database server, see the Parallel Upgrade Tool or the Upgrade manual for the specific Teradata Database release and operating system. Unless the system administrator chooses an alternate location during installation, the TDGSS files are located in the following default directories: Note: The server file locations are automatically determined by the Parallel Upgrade Tool (PUT), as shown in the table above. Since client files are installed manually, the location will vary from what is shown if the client software was not installed in the recommended location. System OS Client System File Location Server System File Location SUSE Linux Enterprise Server /opt/teradata/tdat/teragss/ /opt/teradata/tdgss/<tdgss file name> Other Unix /usr/teragss/<tdgss file name> /usr/tdgss/server/<tdgss file name> Windows Windows.Net C:\Program Files\Teradata\ Teradata GSS\<TDGSS file name> C:\Program Files\Teradata\.Net Data Provider for Teradata\version\ config\<tdgss file name> C:\Program Files\Teradata\TDAT\ TDGSS\LSERVER\<TDGSS file name> Not applicable TDGSS File Contents Note: Both the Windows and Windows.Net TDGSS files exist on Windows clients that run.net Data Provider for Teradata. The Windows.Net installation contains an abbreviated set of files, which includes only the basic interface software, configuration files, and the TdgssNetConfig tool. TDGSS is fully functional upon installation. TDGSS files include the following: /bin executable files: Libraries containing callable TDGSS functions Administrator tools, such as dumpcfg, tdgssconfig, tdsbind, tdgsspkgrm,tdgssversion, and several OpenLdap directory management tools /doc/man1 files: Documentation for OpenLdap directory management tools /etc files: TDGSS Library Configuration file TDGSS User Configuration file Teradata Database directory schema extensions /inc files: Application programmer interface /lib files: Library of routines used by Teradata in mechanism development Security Administration 129

Chapter 8: TDGSS Administration TDGSS Installation and Maintenance TDGSS Site File The TDGSS site file contains the working version of the tdgssuserconfigfile.xml that the system uses to create tdgssconfig.bin. The site file is located separately, as follows: Operating System On each server node On each client SUSE Linux Enterprise Server /opt/teradata/tdat/tdgss/site /opt/teradata/teragss/site MP-RAS /usr/tdgss/site usr/teragss/site Windows C:\Program Files\Teradata\TDAT\TDGSS\site C:\Program Files\Teradata\Teradata GSS\site Note: A special set of configuration files exists for clients running.net Data Provider for Teradata. For the location of these files, see Locating TDGSS Files on page 129. TDGSS File Maintenance Tools It may not be practical to install or upgrade all parts of a system to the latest version of TDGSS at the same time. Teradata Database allows multiple versions of TDGSS to be installed on the system at one time, for version compatibility. TDGSS is only installed on the Teradata Database server. To manage TDGSS versions on the server, use one of the following: the Windows Add/Remove Programs feature the tdpkgrm utility in the Parallel Upgrade Tool (PUT) TeraGSS, the client version of TDGSS, is installed on both the client system and the server. TeraGSS provides two utilities, tdgsspkgrm and tdgssversion, to facilitate the management of multiple TeraGSS versions. Note: Version management utilities are not applicable to Windows.Net versions of TeraGSS. tdgsspkgrm Tdgsspkgrm is included only with TeraGSS for Unix platforms, and can be used to: Determine the current active version of TeraGSS Determine the TeraGSS version(s) available for removal Remove unwanted versions of TeraGSS For Windows platforms, use the Add/Remove Programs panel to manage TDGSS versions. View TeraGSS Versions To view the active version of TeraGSS and versions available for removal, do the following: 1 From the command prompt, cd to the directory where tdgsspkgrm is located. For example, on a Unix system, cd to: /usr/teragss/bin 130 Security Administration

Chapter 8: TDGSS Administration TDGSS Installation and Maintenance Note: For a list of typical TDGSS file locations on various operating systems, see Locating TDGSS Files on page 129. 2 Enter the following: tdgsspkgrm 3 The system will return TeraGSS version information similar to the following example: TeraGSS current version: 06.00.00.0x TeraGSS versions available for removal: 06.00.00.0w 4 To remove one of the versions shown as available for removal, use the procedure to Remove a TeraGSS Version that follows. Remove a TeraGSS Version To remove an unneeded version of TeraGSS, do the following: 1 From the Unix command prompt, cd to the directory where tdgsspkgrm is located: /usr/teragss/bin Note: For a list of typical TDGSS file locations on various operating systems, see Locating TDGSS Files on page 129. 2 Enter: tdgsspkgrm [version to remove, e.g. 06.00.00.0w] 3 To ensure that the proper version has been removed, use the procedure from the previous section to review TeraGSS versions. tdgssversion The tdgssversion utility is included with TeraGSS on all operating systems. Use tdgssversion to survey the available versions of TeraGSS, and to switch from the current version to a different version to maintain version compatibility or to access features that are not available on the current version. View Available TeraGSS Versions To get a list of available versions, do the following: 1 From the command prompt, cd to the directory where tdgssversion is located, as shown below: Operating System SUSE Linux Enterprise Server MP-RAS Windows Location /opt/teradata/teragss/redhatlinux-i386/client/bin /usr/teragss/mpras-i386/client/bin C:\Program Files\Teradata\Teradata GSS\nt-i386\<TeraGSS version>\bin Security Administration 131

Chapter 8: TDGSS Administration TDGSS Installation and Maintenance 2 Enter the following to display the current version: tdgssversion 3 The system will return information similar to the following example: The Teradata GSS Client available versions for mp-rasi386 are: Note: Note: An * denotes the current version 06.00.00.0w 06.02.00.0x* 4 If you want to switch from the current active version or TeraGSS to one of the other available versions, use the procedure contained in the following section. Change the TeraGSS Version To switch from the current version of TeraGSS to another available version, do the following: 1 From the command prompt, cd to the directory where the available TeraGSS versions are located, as shown in the location table in View Available TeraGSS Versions on page 131. 2 Enter the command to switch versions: For Windows systems: tdgssversion /switch [the TeraGSS version number you want to switch to, such as 06.00.00.0w] For UNIX systems: tdgssversion -switch [the TeraGSS version number you want to switch to, such as 06.00.00.0w] 3 To verify the switch has occurred, rerun the procedure to view the current version. 132 Security Administration

Chapter 8: TDGSS Administration TDGSS Configuration Files TDGSS Configuration Files The TDGSS Configuration files contain the mechanisms and properties that define Teradata Database network security functions. There are two types of configuration files: TDGSS Library Configuration files TDGSS User Configuration files The configuration files are plain text files, stored in xml format. You can read both files or edit the tdgssuserconfigfile.xml at any time using a plain text editor such as vi on Unix systems, or Notepad on Windows systems. Both sets of configuration files have the same standard preset attributes, properties, and values when first installed, but they perform different functions: TDGSS File Type Description Library Configuration file The standard-preset configuration that defines the security attributes, properties and values available on the system for that installed release of TDGSS. The system uses this file to determine what attributes, properties, values are allowable. This file changes only when a new release of TDGSS is installed. When new mechanisms and properties are added to TDGSS they appear in the Library Configuration file. User Configuration file Displays only editable mechanism properties. Properties in the User Configuration file initially have the same values as they do in the Library Configuration file. To avoid changing any edits made to the User Configuration, this file is not overwritten by an upgrade to a new release of TDGSS. The following rules apply: No action is necessary to use the default values of new mechanisms or properties shown in the Library Configuration file. To change the value of a new mechanism property, for instance to disable LDAP, you must manually transfer the mechanism from the Library Configuration file to the User Configuration file. Then you must edit the value of the property, in this case changing the value of the MechanismEnabled property to No. For new properties that require site-specific values, you must manually transfer the property from the Library Configuration file to the User Configuration file to edit the values. For information on editing the TDGSS User Configuration files and using the TDGSS Configuration Tool, see Changing the TDGSS Configuration on page 190. All new properties are optional, so editing is not required unless you choose to exercise the associated option. The system defers from what is shown in the Library Configuration file to any changes that it finds in the User Configuration file to determine current security function. Security Administration 133

Chapter 8: TDGSS Administration C/C++ and Java Application Sharing of TDGSS Configuration Files C/C++ and Java Application Sharing of TDGSS Configuration Files C/C++ client applications that communicate with the Teradata Database use the TeraGSS security library. If C/C++ and Java applications are deployed to the same client machine, the Java applications must be configured to use the TeraGSS User Configuration file. This can be done in one of two ways, depending on your system configuration: Set the Java Application Classpath Use the Jar Update command Setting the Java Application Classpath When C/C++ and Java applications are deployed to the same client machine, Java applications do not use the tdgssconfig.jar file that is included in the Teradata JDBC Driver download package. Instead, you must set the classpath for Java applications to include the client directory that contains the TeraGSS User Configuration file, TdgssUserConfigFile.xml. The following items must be included in the classpath for standalone Java applications, and in the Data Source classpath for JDBC Driver components in an application server environment. terajdbc4.jar tdgssjava.jar The directory containing TdgssUserConfigFile.xml Note: This deployment technique can only be used with classloaders that support the specification of a directory on the classpath. Some application servers, such as SAP Web Application Server, only support the use of jar files when defining the classpath for a JDBC Data Source. If the application server or environment does not support the specification of a directory on the classpath, then C/C++ and Java applications cannot directly share the same TeraGSS User Configuration file. Refer to the application server compatibility documentation included in the Teradata JDBC Driver download package for instructions on using the Teradata JDBC Driver with each supported application server. Using the Jar Update Command For application servers or environments that do not support the specification of a directory on the classpath, the TeraGSS User Configuration file can only be shared indirectly, by performing an extra step to enable this indirect sharing. Execute a jar update" command to move the User Configuration file from the TeraGSS directory into the tdgssconfig.jar file found in the JDBC Driver download package, as follows: jar uvf tdgssconfig.jar TdgssUserConfigFile.xml Note: Rerun the jar update command again each time you modify the TeraGSS User Configuration file. Then restart the application server to activate the modified tdgssconfig.jar. 134 Security Administration

Chapter 8: TDGSS Administration TDGSS Security Mechanisms TDGSS Security Mechanisms Mechanism Selection Network logons require that the user employ one of several selectable security mechanisms to define the network security context for each session. Security mechanisms allow the security administrator to: Provide users with a choice of authentication methods Define a default mechanism for some or all users Separately enable and disable mechanisms Edit the values of individual mechanism properties to change mechanism function Set up and customize interfaces with external security applications For detailed information on the description and use of Teradata Database security mechanisms, see Mechanism Configurations on page 137. Note: Security Administrators may find it useful to create a security handbook for database users that explains the site-specific implementation of Teradata Database security features, including a description of available mechanisms and a rationale for mechanism selection. At logon from supported client applications, users can select from among several available security mechanisms. However, the logon can fail unless both server and client TDGSS User Configuration Files (tdgssuserconfigfiles.xml) support the selected mechanism. A mechanism may be unavailable for the following reasons: Some mechanisms are not available on all operating systems. For example, the NTLM mechanism is available only on Windows systems. The NTLM mechanism does not appear in configuration files or GUI applications on non-windows systems. The mechanism may be disabled. While all standard mechanisms are factory preset to enabled, it is possible to edit the tdgssuserconfigfile.xml to disable (and also to reenable) a mechanism. Make sure you fully understand the effects of changing a mechanism s availability status before you try to enable/disable a mechanism. Restrictions Users being externally authenticated can only choose mechanisms that support external authentication. Most applications allow selection of any available mechanism. However, some applications have restrictions on which mechanism can be selected. For instance: Teradata Query Director: Allows use of only TD2, KRB5, SPNEGO, and LDAP mechanisms. Teradata Replication Services: Allows use of only TD1 or TD2, depending on the destination system. Note: Use of external authentication mechanisms requires completion of the set up tasks shown in the sections beginning with System Requirements for External Authentication on page 53. Security Administration 135

Chapter 8: TDGSS Administration TDGSS Security Mechanisms Default Mechanism Mechanism Handling Related Topics For an overview of mechanism selection within the logon sequence, see Network Logon Formats on page 72. For the detailed information on the security mechanism selection procedure for a particular client application, consult that application s user manual. For information on the methods and rationale for editing mechanism properties, including the MechanismEnabled property, see MechanismEnabled on page 150. To relieve users of the necessity of selecting a security mechanism at logon, Teradata Database also allows the administrator to designate a default security mechanism. If a user does not select a mechanism at logon the system uses the designated default mechanism. The server version of the tdgssuserconfigfile.xml is factory preset with a default mechanism (TD2) and the system will automatically use it. The client version of the file does have a factory preset default, to allow for differences in requirements among client groups. You can edit the to tdgssuserconfigfile.xml: designate a default mechanism where none exists change to a different default mechanism For more information on designating or changing the default security mechanism, see DefaultMechanism on page 149. Network security involves communication between the client and server, so both must support the security mechanism used for a session. Since the TDGSS files can be installed and edited separately on the client and server, conflicts may arise. When a client application specifies a mechanism, the system must compare it against a merged list of mechanisms supported by both the client and server. Two principal rules apply to mechanism processing: The default mechanism defined on the client from which a logon originates always takes precedence over the default server mechanism. Note: The client Configuration files do not contain a factory preset default mechanism. You must edit the client version of the tdgssuserconfigfile.xml to designate a default mechanism. The server Configuration files do contain a factory preset default mechanism, but you can edit the Configuration to define a new default if required. A user-selected mechanism takes precedence over the default mechanism. The following scenarios describe how the system processes a request to use a mechanism, whether it is the default mechanism or one selected by the user. The user selects a mechanism; the system finds the mechanism on the merged list of mechanisms supported by both the client and the database; the logon is successful and the system uses the specified mechanism. 136 Security Administration

Chapter 8: TDGSS Administration Mechanism Configurations The user selects a mechanism; the system does not find the mechanism on the merged list; the logon fails and the system returns error message CLI507. The user does not select a mechanism; the client does not define a default mechanism; the server default mechanism applies, but the client doesn t support that mechanism so it is not on the merged list; the logon fails and the system returns error message CLI507. The user does not select a mechanism; the client does not define a default mechanism; the server default mechanism applies; the client also supports that mechanism, so it is on the merged list; the logon succeeds using the server default mechanism. The user does not select a mechanism; the client defines a default mechanism; the system ignores the server default mechanism, but the server doesn t support the client default mechanism and it does not appear on the merged list; the logon fails and the system returns error message CLI507. The user does not select a mechanism; the client defines a default mechanism; the system ignores the server default mechanism; if the server supports the client default mechanism and the system finds it on the merged list, the logon succeeds using the client default. For further information on editing the tdgssuserconfigfile.xml, see Changing the TDGSS Configuration on page 190. Mechanism Configurations Teradata Database currently provides the following pre-defined security mechanisms. Standard mechanisms: Teradata Method 2 (TD2) KRB5 NTLM LDAP SPNEGO Note: The NTLM mechanism does not appear in TDGSS files installed for non-windows nodes. The KRB5, NTLM, and SPNEGO mechanisms do not appear on non-windows clients. Mechanisms for support of legacy systems: Teradata Method 1 (TD1) KRB5C NTLMC Note: These legacy support mechanisms are not enabled for new installations of Teradata Database 12.0 and up, but they can be enabled by setting the MechanismEnabled property to yes. The mechanisms remain enabled for systems upgrading to Release 13.0. However, use of these mechanisms is not encouraged because they will be eliminated in a future release. For detailed information on Mechanism Properties, see the section beginning with Mechanism Properties on page 144. Security Administration 137

Chapter 8: TDGSS Administration Mechanism Configurations TD2 Mechanism Teradata Method 2 (TD2) provides for authentication by Teradata Database, and the capability for encryption of data (confidentiality) and integrity checking. It is the default mechanism for systems where both the following are true: the client is running Teradata Tools and Utilities 8.0 or later, and the server is running V2R6.0 or later The TD2 mechanism appears in the TDGSS Library Configuration file as presented in the following example, which shows the standard preset value for each mechanism property. Example: TD2 Configuration </Mechanism> <!-- Teradata Method 2 (uses AES) --> <Mechanism Name="TD2" ObjectId="1.3.6.1.4.1.191.1.1012.1.1.9" LibraryName="gssp2td2" Prefix="TD2" InterfaceType="teradata"> <MechanismProperties AuthenticationSupported="no" AuthorizationSupported="no" SingleSignOnSupported="no" DefaultMechanism="yes" MechanismEnabled="yes" MechanismRank="20" GenerateCredentialFromLogon="yes" DelegateCredentials="no" MutualAuthentication="yes" ReplayDetection="yes" OutOfSequenceDetection="yes" ConfidentialityDesired="yes" IntegrityDesired="yes" AnonymousAuthentication="no" DesiredContextTime="" DesiredCredentialTime="" CredentialUsage="0" VerifyDHKey="no" DHKeyP="E4BE0A78F54C4A0B17E7E9249A78BCC08868C17281D8463C880937853E73DDC7 87E41580A8AFE2594D984C9E0814C590790354ECCD1BE8EA85961E5E0974B32EFE178335 F061E80189B4BDAA20F67B47" DHKeyG="0500000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000" /> <MechQop Value="0"> GLOBAL_QOP_1 </MechQop> </Mechanism> 138 Security Administration

Chapter 8: TDGSS Administration Mechanism Configurations KRB5 Mechanism Teradata Database employs the KRB5 mechanism to provide confidentiality and integrity while supporting external authentication (Single Sign-on and UPN logon) by Kerberos, when Teradata Database runs on SUSE Linux Enterprise Server (release 10 only), MP-RAS (version 3.03 only), and Windows. Use of the KRB5 mechanism requires the completion of set up procedures described in the sections starting with System Requirements for External Authentication on page 53. Note: Clients running Teradata.Net Data Provider cannot select the KRB5 mechanism, but must instead use the SPNEGO mechanism. Kerberos Multiple LAN Adapter Restriction Use of the KRB5 mechanism may fail when client users attempt to connect to servers having more than one LAN adapter. In order to use the KRB5 mechanism, the servers addressed by a client application must have a maximum of one LAN adapter and the machine name must correspond to the host name (hostid) associated with the target adapter. If you decide to continue use of multiple LAN adapters, you may find it useful to disable the KRB5 mechanism to avoid the error message that will be generated if a user selects the mechanism. Note that disabling KRB5 could eliminate the use of Kerberos- dependent logon features such as Single Sign-on and UPN logons (Sign-on As) on many systems. For further information on disabling KRB5, see MechanismEnabled on page 150 and Changing the TDGSS Configuration on page 190. Example: KRB5 Configuration The KRB5 mechanism appears in the TDGSS Library Configuration file as shown in the following examples, which also shows the standard preset value for each mechanism property: </Mechanism> <!-- SSPI: Kerberos --> <Mechanism Name="KRB5" ObjectId="1.2.840.113554.1.2.2" LibraryName="gssp2sspi" Prefix="SSPI" InterfaceType="sspi"> <MechanismProperties AuthenticationSupported="yes" AuthorizationSupported="no" SingleSignOnSupported="yes" DefaultMechanism="no" GenerateCredentialFromLogon="yes" MechanismEnabled="yes" MechanismRank="40" DelegateCredentials="no" MutualAuthentication="yes" ReplayDetection="yes" OutOfSequenceDetection="yes" ConfidentialityDesired="yes" Security Administration 139

Chapter 8: TDGSS Administration Mechanism Configurations IntegrityDesired="yes" AnonymousAuthentication="no" DesiredContextTime="" DesiredCredentialTime="" CredentialUsage="0" /> <MechQop Value="0"> GLOBAL_QOP_0 </MechQop> </Mechanism> NTLM Mechanism Teradata Database employs the NTLM mechanism to provide confidentiality and integrity while supporting external authentication by NTLM on Windows systems. Use of the NTLM mechanism requires the completion of set up procedures described in the sections starting with System Requirements for External Authentication on page 53. Note: TDGSS configuration files on non-windows clients do not contain the NTLM mechanism. Clients running Teradata.Net Data Provider applications cannot use NTLM, but must instead use the SPNEGO mechanism. The NTLM mechanism appears in the TDGSS Library Configuration file as shown in the following examples, which also show the standard preset value for each mechanism property. Example: NTLM Configuration </Mechanism> <!-- SSPI: NTLM --> <Mechanism Name="NTLM" ObjectId="1.3.6.1.4.1.191.1.1012.1.1.4" LibraryName="gssp2sspi" Prefix="SSPI" InterfaceType="sspi"> <MechanismProperties AuthenticationSupported="yes" AuthorizationSupported="no" SingleSignOnSupported="yes" DefaultMechanism="no" GenerateCredentialFromLogon="yes" MechanismEnabled="yes" MechanismRank="60" DelegateCredentials="no" MutualAuthentication="yes" ReplayDetection="yes" OutOfSequenceDetection="yes" ConfidentialityDesired="yes" IntegrityDesired="yes" AnonymousAuthentication="no" DesiredContextTime="" DesiredCredentialTime="" CredentialUsage="0" /> 140 Security Administration

Chapter 8: TDGSS Administration Mechanism Configurations <MechQop Value="0"> GLOBAL_QOP_0 </MechQop> </Mechanism> LDAP Mechanism The LDAP mechanism is used to support external authentication and authorization of users defined in an LDAP-compliant directory. Use of the LDAP mechanism requires the completion of set up procedures described in the sections starting with System Requirements for External Authentication on page 53. Most applications of the LDAP mechanism also require the execution of extensive setup procedures in the directory, as described in Chapter 9: Directory Management of Database Users and Appendix E: Configuring a Directory to Manage Teradata Database Users. Note: A number of the properties shown were introduced after the initial release of TDGSS, and do not appear in the TDGSS User Configuration file. Many of theses properties require special handling, as shown in Special Handling for New Properties on page 144, and Adding New Mechanisms or Properties to the User Configuration File on page 193. Example: LDAP Configuration The LDAP mechanism appears in the TDGSS Library Configuration file as follows: </Mechanism> <!-- LDAP --> <Mechanism Name="ldap" ObjectId="1.3.6.1.4.1.191.1.1012.1.20" LibraryName="gssp2ldap" Prefix="ldapv3" InterfaceType="custom"> <MechanismProperties AuthenticationSupported="yes" AuthorizationSupported="yes" SingleSignOnSupported="no" DefaultMechanism="no" GenerateCredentialFromLogon="yes" MechanismEnabled="yes" MechanismRank="70" DelegateCredentials="no" MutualAuthentication="yes" ReplayDetection="yes" OutOfSequenceDetection="yes" ConfidentialityDesired="yes" IntegrityDesired="yes" AnonymousAuthentication="no" DesiredContextTime="" DesiredCredentialTime="" CredentialUsage="0" LdapServerName="" LdapServerPort="389" LdapServerRealm="" LdapSystemFQDN="" Security Administration 141

Chapter 8: TDGSS Administration Mechanism Configurations LdapBaseFQDN="" LdapGroupBaseFQDN="" LdapUserBaseFQDN="" LdapClientReferrals="off" LdapClientDeref="never" LdapClientDebug="0" LdapClientRebindAuth="yes" LdapClientRandomDevice="/dev/urandom" LdapClientmechanism="SASL/DIGEST-MD5" LdapClientUseTls="no" LdapClientTlsCACert="" LdapClientTlsCACertDir="" LdapClientTlsCert="" LdapClientTlsKey="" LdapClientTlsRandFile="" LdapClientTlsReqCert="never" LdapClientTlsCipherSuite="" LdapClientTlsCRLCheck="none" LdapServiceFQDN="" LdapServicePassword="" LdapServiceBindrequired="no" VerifyDHKey="no" DHKeyP="E4BE0A78F54C4A0B17E7E9249A78BCC08868C17281D8463C880937853E73DDC7 87E41580A8AFE2594D984C9E0814C590790354ECCD1BE8EA85961E5E0974B32EFE178335 F061E80189B4BDAA20F67B47" DHKeyG="0500000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000" /> </Mechanism> <MechQop Value="0"> GLOBAL_QOP_0 </MechQop> 142 Security Administration

Chapter 8: TDGSS Administration Mechanism Configurations SPNEGO Mechanism The SPNEGO mechanism provides functionality similar to the KRB5 mechanism. Use SPNEGO instead of KRB5 for fully managed.net clients. Note: The SPNEGO mechanism, like KRB5, is subject to the multiple LAN adapter restriction. For information, see Kerberos Multiple LAN Adapter Restriction on page 139. SPNEGO appears in the tdgsslibraryconfig.xml for all installations of Teradata Database 13.00.00 and above, but does not appear in the tdgssuserconfig.xml. On Windows the SPNEGO mechanism is enabled and ready for use. On Linux and MP-RAS systems you must do the following: a Copy the SPNEGO mechanism from the tdgsslibraryconfig.xml into the tdgssuserconfigfile.xml on all database nodes, and on the Query Director (if used). b Enable SPNEGO by setting the MechanismEnabled property to Yes on all on all database nodes, and on the Query Director (if used). Clients running CliV2 version 8.2.x or before have a limit of four active mechanisms. You must disable one other mechanism in the tdgssuserconfigfile.xml to use SPNEGO. The following example shows the standard preset value for each mechanism property. Example: SPNEGO Configuration </Mechanism> <!-- SSPI: SPNEGO --> <Mechanism Name="SPNEGO" ObjectId="1.3.6.5.5.2" LibraryName="gssp2sspi" Prefix="SSPI" InterfaceType="sspi"> <MechanismProperties AuthenticationSupported="yes" AuthorizationSupported="no" SingleSignOnSupported="yes" DefaultMechanism="no" GenerateCredentialFromLogon="yes" MechanismEnabled="no" MechanismRank="65" DelegateCredentials="no" MutualAuthentication="yes" ReplayDetection="yes" OutOfSequenceDetection="yes" ConfidentialityDesired="yes" IntegrityDesired="yes" AnonymousAuthentication="no" DesiredContextTime="" DesiredCredentialTime="" CredentialUsage="0" /> <MechQop Value="0"> GLOBAL_QOP_0 </MechQop> </Mechanism> Security Administration 143

Chapter 8: TDGSS Administration Mechanism Properties Mechanism Properties All TDGSS mechanisms contain a group of attributes, called properties, that define how the mechanism will function, based on the value of each property. Most mechanisms will function optimally for most applications without the need to change property values. Property values exhibit the following characteristics: All properties have a default value. For many standard applications, no editing of default property values is required. Properties that require a site-specific value carry a default value of. Specification of a real value is optional for some of these. For others, you must substitute a real value for to enable the containing mechanism to function properly Some properties with a default value of will automatically refer to a value specified elsewhere if a real value is not specified. For optional properties, the value can remain as if the property will not be used. Some property values are hard coded and cannot be edited. Many properties, such as MechanismEnabled, are common to all mechanisms. Others, such as the LDAP Configuration properties, are used only by a a single mechanism. Be sure you fully understand the function of a property, as described in the following sections, before you consider changing the default property value. For detailed guidelines on editing property values, see Changing the TDGSS Configuration on page 190. Special Handling for New Properties TDGSS was originally released in Teradata Database V2R6.0. All mechanisms and properties existing at that time were provided in both the Library Configuration file and the User configuration file, to be used as follows: Library Configuration: Contains the default settings for all mechanisms and properties. The system executes security policy based on the Library Configuration unless changes have been to the User Configuration. User Configuration: Contains default settings defined in the Library Configuration file as modified by any user-specified changes. Properties introduced in the releases subsequent to V2R6.0 may require special action before they are available for editing. For details see, Changing the TDGSS Configuration on page 190. For the procedure required to copy new mechanisms and properties from the Library Configuration to the User Configuration and subsequently edit the values, see Making Changes to the User Configuration Files on page 195 and Making TDGSS Configuration Changes on Teradata Clients on page 238. 144 Security Administration

Chapter 8: TDGSS Administration Basic Functional Properties Basic Functional Properties AuthenticationSupported The following three properties, from AuthenticationSupported through SingleSignOnSupported, describe basic capabilities of the mechanisms in which they are found. This property indicates whether or not the mechanism supports external (non-teradata Database) authentication of users. Default Property Value The value of this property is factory preset to yes for all supporting mechanisms and no for others. Supporting Mechanisms The AuthenticationSupported property is supported by the following mechanisms: Mechanism Property Supported? Property Editable? TD1, TD2 No No KRB5, KRB5C Yes No NTLM, NTLMC SPNEGO LDAP Editing Guidelines Use the following guidelines when editing the value of the AuthenticationSupported property: This property is not editable. The value of this property is only an indication of the property s function. The function is built into the mechanism code. Resetting the property value does not change that function. Security Administration 145

Chapter 8: TDGSS Administration Basic Functional Properties AuthorizationSupported This property determines whether or not the mechanism supports non-teradata Database user authorization. Default Property Value The value of this property is factory preset to no for all mechanisms except LDAP. Supporting Mechanisms The AuthenticationSupported property is supported by the following mechanisms: Mechanism Property Supported? Property Editable? TD1, TD2 No No KRB5, KRB5C NTLM, NTLMC SPNEGO LDAP Yes Yes Editing Guidelines Use the following guidelines when editing the value of the AuthenticatedSupported property: Edit this property only on client machines. When the value of this property is set to yes, the Gateway looks for authorization information from the directory. Set this property to yes if you have mapped directory users to Teradata Database users, roles, or profiles. When the value of this property is set to no, the Gateway ignores authorization information from the directory. Setting this property to no facilitates use of the LDAP for authentication of directory users without having to map directory users to Teradata Database users, roles, or profiles. To use this method of authentication the directory user must have a user name that matches a Teradata Database username and must have been granted WITH NULL PASSWORD privileges. 146 Security Administration

Chapter 8: TDGSS Administration Basic Functional Properties GenerateCredentialFromLogon The GenerateCredentialFromLogon property tells TDGSS where to look for user credential information. Some CLIv2-based third-party applications or scripts, such as a BTEQ script, do not allow use of the.logdata statement in a logon string. When GenerateCredentialFromLogon is set to yes, the Gateway will first look in.logdata for credential information. If it does not find a.logdata statement, the Gateway will use the credential information found in the.logon statement. Note: GenerateCredentialFromLogon is included only in the TDGSS Library Configuration file Teradata Database 12.00.00.11 and greater. However, it is fully functional and you do not need to add it to the UserConfigurationFile.xml to use it. Default Property Value The value of this property is factory preset in the TDGSS Library Configuration file to yes (enabled) for all mechanisms. Supporting Mechanisms The GenerateCredentialFromLogon property is supported by the following mechanisms: Mechanism Property Supported? Property Editable? TD1, TD2 Yes No KRB5, KRB5C NTLM, NTLMC SPNEGO LDAP Editing Guidelines Do not edit the value of the GenerateCredentialFromLogon property. Editing may result in logon failures and other adverse consequences. Security Administration 147

Chapter 8: TDGSS Administration Basic Functional Properties SingleSignOnSupported This property indicates whether or not the mechanism supports Single Sign-on. Default Property Value The value of this property is factory preset to yes for all mechanisms that support single signon. Supporting Mechanisms The SingleSignOnSupported property is supported by the following mechanisms: Mechanism Property Supported? Property Editable? TD1, TD2 No No KRB5, KRB5C Yes No NTLM, NTLMC The property value is hard coded to yes for all mechanisms that SPNEGO support it. LDAP No No Editing Guidelines Do not edit the preset values of the SingleSignOn property: Do not use this property to enable or disable single sign-on. For further information on acceptable methods of enabling and disabling single sign-on, see External Authentication on page 52. This property is only an indicator of mechanism capability. The value is not editable. The system will ignore the value of this property if it differs from the preset value. 148 Security Administration

Chapter 8: TDGSS Administration Mechanism Status Properties Mechanism Status Properties DefaultMechanism The following three properties indicate the status of the mechanism. The default security mechanism is used by the system if a mechanism is not specified by the user at logon. TD2 is the standard preset default mechanism for the server. Default Property Value TD2 is the standard preset default mechanism in the server TDGSS Configuration files. For all other mechanisms, the DefaultMechanism property is factory preset to no. The client TDGSS User Configuration files have no preset default mechanism. Supporting Mechanisms The DefaultMechanism property is supported by the following mechanisms: Mechanism Property Supported? Property Editable? TD1, TD2 Yes Yes KRB5, KRB5C NTLM, NTLMC SPNEGO LDAP Editing Guidelines Use the following guidelines when editing the value of the DefaultMechanism property: The DefaultMechanism property is editable for all standard mechanisms. Only one mechanism at a time can be the default mechanism. You can designate different default mechanisms for individual clients or client groups. In cases where the client and server define different default mechanisms, and no mechanism is selected by the user, the client default mechanism always takes precedence. If the client does not define a default, the logon uses the server default mechanism. If a default mechanism is not designated, the user must select a mechanism or the logon will fail. Editing Suggestions The following are common editing scenarios for DefaultMechanism: Set this property to yes for a mechanism if you expect the majority of users to employ it. If you designate a default mechanism other than TD2, reset this property to no for TD2. Security Administration 149

Chapter 8: TDGSS Administration Mechanism Status Properties MechanismEnabled This property determines whether or not a mechanism is available for use. Default Property Value The value of this property is factory preset to yes (enabled) for all mechanisms with the exception of SPNEGO, which is disabled by default on Teradata Database for Linux and MP- RAS. To enable SPNEGO on these operating systems, follow the procedure shown in SPNEGO Mechanism on page 143. Supporting Mechanisms The MechanismEnabled property is supported by the following mechanisms: Mechanism Property Supported? Property Editable? TD1, TD2 Yes Yes KRB5, KRB5C NTLM, NTLMC SPNEGO LDAP Editing Guidelines Use the following guidelines when editing the value of the MechanismEnabled property: MechanismEnabled is editable for all supporting mechanisms. Mechanisms that are not enabled will not appear as choices in GUI drop-down menus. Set the value of this property to no to disable mechanisms not in use. Users who select a disabled mechanism receive an error message directing them to select another mechanism. Set the value of this property to no for the LDAP mechanism unless you plan to use a directory to perform external authentication of users. Do not re-enable LDAP until: you have done the necessary editing to the LDAP properties shown later in this section you have installed the Teradata Database-related directory schema extensions and done any required mapping of directory users to Teradata Database objects The system does not require that you disable unused mechanisms. Ensure that all mechanisms enabled on any client are also enabled on all server nodes. If you disable a mechanism on the server it is automatically disabled on all clients, even if the mechanism is enabled in the client User Configuration files. 150 Security Administration

Chapter 8: TDGSS Administration Mechanism Status Properties MechanismRank The MechanismRank property defines the order of preference of listing mechanisms for user selection. Default Property Values The default settings for this property on the standard preset mechanisms are as follows: TD1 = 10 TD2 = 20 KRB5C = 30 KRB5 = 40 NTLMC = 50 NTLM = 60 SPNEGO = 65 LDAP = 70 Note: Mechanism rank values shown in the previous example are for reference only and need not be in increments of 10. The system will rank them in order of preference from low to high, with the lowest numbers having the highest preference. Supporting Mechanisms The MechanismRank property is not currently active for any mechanism. Editing Guidelines Use the following guidelines when editing the value of the MechanismRank property: This property is not currently used by the system, but is reserved for future use. The system will ignore the value of this property for all mechanisms. Security Administration 151

Chapter 8: TDGSS Administration Operational Properties Operational Properties DelegateCredentials Use the operation properties to set flags requesting that certain operational options be employed by the system when authenticating users and transmitting data. This property indicates whether or not to delegate credentials to a remote peer. Default Property Value The value of this property is factory preset to no for all mechanisms. Supporting Mechanisms The DelegateCredentials property can be employed to facilitate the use of Query Director to route a query to the Teradata Database system with the most processing capacity available to handle it. In such a scenario the Query Director acts as both a client and a server, passing the user credentials on to the selected database system. DelegateCredentials is supported by the following mechanisms: Mechanism Property Supported? Property Editable? TD1 No No TD2 Yes Yes KRB5 Yes Yes KRB5C No No NTLM, NTLMC No No SPNEGO Yes Yes LDAP Yes Yes Editing Guidelines Use the following guideline when editing DelegateCredentials: Set the DelegateCredentials property to yes if user requests will be routed through Teradata Query Director, for mechanisms that support the application. For a list of mechanisms that can be used with Teradata Query Director, see Logons Through Teradata Query Director on page 85. 152 Security Administration

Chapter 8: TDGSS Administration Operational Properties MutualAuthentication This property indicates whether or not the client requests that the server authenticate itself. Mutual authentication is used to avoid man-in-the-middle attacks that might allow diversion of a transmission to an unauthenticated third party. When this property is set to yes on a supporting mechanism, Mutual Authentication takes place automatically, out of view of the user. Kerberos, the supporting external security application, requires no special set up to facilitate Mutual Authentication and produces no records to indicate that such authentication has taken place. Default Property Value The value of this property is factory preset to yes for all mechanisms, including those that don t currently support it, in the event they are revised to support MutualAuthentication in a future release of Teradata Database. Supporting Mechanisms MutualAuthentication is supported by the following mechanisms: Mechanism Property Supported? Property Editable? TD1, TD2 No No KRB5, KRB5C Yes Yes NTLM, NTLMC No No SPNEGO Yes Yes LDAP No No Editing Guidelines Use the following guidelines when editing the MutualAuthentication property: Any edits to the preset values for this property for mechanisms that don t support it will be ignored by the system. You can edit this property value to no for KRB5 to slightly enhance performance. However, because the performance effects of MutualAuthentication are extremely small, such editing is not really useful. If Teradata Database is running on MP-RAS or SUSE Linux Enterprise Server and users will only have the option of employing the KRB5 mechanism if MutualAuthentication is set to yes. Security Administration 153

Chapter 8: TDGSS Administration Operational Properties ReplayDetection This property determines whether the mechanism supports tracking and identifying requests that have been transmitted more than once. The property value is provided for reference only. Replay detection is a built-in function for the mechanisms that support it. If a replayed message is detected when a mechanism that supports this property is being used, the system will automatically reject the replayed message and will log an error message. Default Property Value The value of this property is factory preset to yes for all mechanisms, including those that don t actually support replay detection in the event they are revised to support the feature in a future release of Teradata Database. Supporting Mechanisms Replay detection is supported for the following mechanisms: Mechanism Property Supported? Property Editable? TD1, TD2 No No KRB5 KRB5C NTLM NTLMC SPNEGO LDAP Yes No Yes No Yes No Editing Guidelines Editing the ReplayDetection property is not allowed. Any edits to this property will be ignored by the system. 154 Security Administration

Chapter 8: TDGSS Administration Operational Properties OutOfSequenceDetection This property determines whether the mechanism supports tracking and identifying requests that have been transmitted out of sequence. The property value is provided for reference only. Out-of-sequence detection is a built-in function for the mechanisms that support it. If an out-of-sequence message is detected when a mechanism that supports this property is being used, the system will automatically reject the out-of-sequence message and will log an error message. Default Property Value The value of this property is factory preset to yes for all mechanisms. Supporting Mechanisms OutOfSequenceDetection is supported for the following mechanisms. Mechanism Property Supported? Property Editable? TD1, TD2 No No KRB5 KRB5C NTLM NTLMC SPNEGO LDAP Yes No Yes No Yes No Editing Guidelines Editing the OutOfSequenceDetection property is not allowed. Any edits to this property will be ignored by the system. Security Administration 155

Chapter 8: TDGSS Administration Operational Properties ConfidentialityDesired This property indicates whether or not the mechanism supports confidentiality (encryption of transmitted data). All Teradata Database standard mechanisms are set to support encryption. Default Property Value The ConfidentialityDesired property is preset to yes for all standard mechanisms. Supporting Mechanisms ConfidentialityDesired is supported by all standard mechanisms. Mechanism Property Supported? Property Editable? TD1, TD2 Yes No KRB5, KRB5C NTLM, NTLMC SPNEGO LDAP Yes Yes Yes Yes Editing Guidelines All standard preset mechanisms support data encryption, so the default value of this property is yes. Encryption does have a performance impact, so many client applications allow for the enabling/disabling of encryption at logon depending on whether or not secure transmission is required for the session. Do not edit this property--use the client application to choose whether or not to encrypt a session. For further information on how to choose to encrypt on a session-by-session basis, see the users guide for the client application you plan to use. 156 Security Administration

Chapter 8: TDGSS Administration Operational Properties IntegrityDesired This property indicates whether or not the client requests integrity checking of messages by the receiver. Default Property Value The value of this property is factory preset to yes for all mechanisms. Supporting Mechanisms IntegrityDesired is supported by the following mechanisms: Mechanism Property Supported? Property Editable? TD1, TD2 Yes No KRB5, KRB5C NTLM, NTLMC SPNEGO LDAP Editing Guidelines Editing the IntegrityDesired property is not allowed. Any edits to this property will be ignored by the system. Security Administration 157

Chapter 8: TDGSS Administration Operational Properties AnonymousAuthentication This property indicates whether or not to reveal the initiator s identity to the acceptor. Default Property Value The value of this property is factory preset to no for all mechanisms. Supporting Mechanisms The AnonymousAuthentication property is not currently supported for any mechanisms, but is reserved for future use. Mechanism Property Supported? Property Editable? TD1, TD2 No No KRB5, KRB5C NTLM, NTLMC SPNEGO LDAP Editing Guidelines Editing the AnonymousAuthentication property is not allowed. Any edits to this property will be ignored by the system. 158 Security Administration

Chapter 8: TDGSS Administration Operational Properties DesiredContextTime The DesiredContextTime property indicates the time duration, in seconds, that the security context defined by the mechanism will remain in effect. Default Property Value The value of this property is factory preset to, that is, the security context cannot expire. Supporting Mechanisms The DesiredContextTime property is not currently supported for any mechanism, but is reserved for future use. Mechanism Property Supported? Property Editable? TD1, TD2 No No KRB5, KRB5C NTLM, NTLMC SPNEGO LDAP Editing Guidelines Use the following guidelines when editing the value of the DesiredContextTime property: Teradata Database standard mechanisms do not support setting a time limit on the security context. Any edits made to the value of this property will be ignored by the system. Security Administration 159

Chapter 8: TDGSS Administration Operational Properties DesiredCredentialTime The DesiredCredentialTime property indicates the time duration, in seconds, that the security credential submitted by the user, and authenticated by the system, will remain in effect. Default Property Value This property is factory preset to, that is, the credential cannot expire. Supporting Mechanisms The DesiredCredentialTime property is supported by the following mechanisms: Mechanism Property Supported? Property Editable? TD1, TD2 No No KRB5, KRB5C NTLM, NTLMC SPNEGO LDAP Editing Guidelines Use the following guidelines when editing the value of the DesiredCredentialTime property: The Teradata Database standard preset mechanisms do not currently support setting a time limit on the user credentials. Any edits to the value of this property will be ignored by the system. 160 Security Administration

Chapter 8: TDGSS Administration Operational Properties CredentialUsage This property indicates how the credential will be used by the system. 0 = Credential may be used to initiate or accept 1 = Credential may be used only to initiate 2 = Credential may be used only to accept Default Property Value This property is preset to 0 for all standard mechanisms. That is, the credential may be used by the system to either initiate or accept a request. Supporting Mechanisms The CredentialUsage property interacts with the standard mechanisms in the following ways: Mechanism Property Supported? Property Editable? TD1, TD2 Yes No KRB5, KRB5C NTLM, NTLMC SPNEGO LDAP Yes Yes Yes Yes Editing Guidelines Use the following guidelines when editing the value of the CredentialUsage property: Currently, this property is only read by the client. This property is reserved for future use, to enable a mechanism to differentiate between initiator and acceptor functions. Security Administration 161

Chapter 8: TDGSS Administration Directory User Authentication Properties Directory User Authentication Properties LdapServerName The directory user authentication properties apply only to use of the LDAP mechanism to authenticate directory users. The LdapServerName tells TDGSS which directory server or servers can be used for authentication. The value can be one of the following: the directory server DNS name a space-separated server URI specifying a scheme, name, and port a DNS service resource name that begins with _ldap._tcp or _ldaps._tcp Note: Use of a DNS service resource name that begins with _ldaps._tcp is required to enable SSL protection. Default Property Value This property is factory preset to, indicating that the system will use _ldap._tcp to locate directory servers in the default DNS domain, and that SSL protection is not enabled. Supporting Mechanisms This property appears only in the LDAP mechanism. Editing Guidelines Use the following guidelines when editing the value of the LdapServerName property: Edit this property only for the LDAP mechanism. Only the server requires LdapServerName information. The client ignores this property. Set the value to the DNS name of the network interface where the LDAP server is listening, or to the IP address of the LDAP server, to identify a single LDAP server. or, Specify more than one LDAP server to provide failover protection. For information on the special set-up of LdapServerName and related LDAP properties required for failover protection, see Set up for LDAP Server Failover Protection on page 163. Also see LdapServerPort on page 164 and LdapServerRealm on page 165. 162 Security Administration

Chapter 8: TDGSS Administration Directory User Authentication Properties Set up for LDAP Server Failover Protection Teradata Database provides failover protection for directory user logons in the event the primary directory server fails. Use the following procedure to configure LDAP to provide directory server failover protection. Step 1: Configure the LdapServerName Property The LdapServerName property can be configured in one of the following ways, depending on system requirements. For centralized management of multiple directory servers in a single domain, use the DNS SRV Resource Records method. If it is necessary to name one or more failover servers, make a list using the explicit LDAP Uniform Resource Identifiers (URI) method. An authentication will contact servers in the order listed. The system uses the first viable server it encounters. To Set the Value of LdapServerName LdapServerName Value Description Using DNS SRV Resource Records The DNS domain SVR Resource Records must be set up according to IETF RFC 2782 to communicate with LDAP. Teradata Database supports all options described in this specification. For details on RFC 2782, go to: http://www.ietf.org/rfc/rfc2782.txt Note: Configuring SSL protection affects the use of the DNS SRV Resource Records form. For details, see Configuring Basic SSL/TLS Functions on page 294. Using Explicit LDAP Uniform Resource Identifiers (URI) Use one of the following values: LdapServerName= LdapServerName= _ldap._tcp LdapServerName= _ldaps._tcp Use one of the following values: LdapServerName= _ldap._tcp. dnsdomain LdapServerName= _ldaps._tcp. dnsdomain LdapServerName= ldap://server1. mydom.com:389/ldap: // server2.mydom. com:389/ where: ldap://server1. mydom.com is the name of a directory server. Note: Do not use an IP address for the server name with Active Directory and DIGEST-MD5 binding. :389 is the LDAP service port. TDGSS will attempt to obtain a list of directories for the default DNS domain. The default domain must be defined on the client network. Substitute the name of the DNS domain that contains the SRV Resource Records of the directory servers to be used. TDGSS will attempt to obtain a list of directories for the specified DNS domain, dnsdomain. Use the fully qualified DNS name of each available directory server, beginning with the primary server. Server DNS names must be separated by a space. There is no specific limit to the number of alternate servers that can be listed, but LdapServerName is limited to 256 characters. Step 2: Re-Configure the LdapServerPort Property A specific value for the LdapServerPort is not required. Port information will be gathered from the source identified by the LdapServerName property value as shown in Step 1. Set the LdapServerPort value in the tdgssuserconfig.xml as follows: LdapServerPort= 0 Security Administration 163

Chapter 8: TDGSS Administration Directory User Authentication Properties LdapServerPort This property identifies the port designation for the LDAP service port. Warning: Do not use LdapServerPort for new implementations of LDAP. This property is deprecated and remains available only to support legacy configurations. Best practice configuration of the LdapServerName property (as shown in the previous section) eliminates the need for setting an LdapServerPort value. Legacy systems that have configured this property should update the configuration for LdapServerName and reset LdapServerPort to 0. Default Property Value This property is factory preset to 389, the default LDAP service port. Supporting Mechanisms This property appears only in the LDAP mechanism. Editing Guidelines Use the following guidelines when editing the value of the LdapServerPort property: Edit this property only for the LDAP mechanism. Only the server requires LdapServerPort information. The client ignores this property. If the directory server is already listening on port 389 do not edit this property. If the directory server is not listening on port 389 you must edit the LdapServerPort property value to indicate the port your LDAP server is actually using. If the LdapServerName property has been set up for failover protection, set LdapServerPort= 0. 164 Security Administration

Chapter 8: TDGSS Administration Directory User Authentication Properties LdapServerRealm This property identifies the name of the SASL realm to be used by the directory server for authentication. Directory users logging on to Teradata Database must inhabit the realm specified in the logon string. Realm information comes from one of two sources: If the logon string does not specify a realm, then TDGSS uses the value of the LdapServerRealm property. If the logon string does specify a valid realm, that realm value will override the value of the LdapServerRealm property. Note: This property is not considered if the directory uses non-sasl binding for user authentication. Default Property Value This property is factory preset to, that is, no realm is specified. Supporting Mechanisms This property appears only in the LDAP mechanism. Editing Guidelines Use the following guidelines when editing the value of the LdapServerRealm property: The client ignores this property. This information is required only by the tdgssuserconfig.xml files on the Teradata Database server. If the value is set to and the directory server offers only a single SASL realm for authentication, TDGSS will use the realm offered by the directory. Any realm name set as the value for this property must be a SASL realm offered by the authenticating directory server. If the directory server offers multiple SASL realms, set one of the realms as the default value for LdapServerRealm. This configuration allows directory users to be authenticated in the default realm without specifying the realm in the logon string. When multiple realms are offered by the directory and the user cannot employ the default realm, the user must specify a realm in the logon string using realm=<realm name> in the.logdata statement. For more information, see beginning with LDAP Logons on page 75. If LdapServerName is configured for failover protection, set the value of LdapServerRealm as shown in Step 3 of Set up for LDAP Server Failover Protection. Security Administration 165

Chapter 8: TDGSS Administration Directory User Authentication Properties LdapSystemFQDN LdapBaseFQDN This property identifies the fully qualified distinguished name (FQDN) of the directory object that contains the description of the Teradata Database server. This information helps to locate the system without resorting to a deep search of the directory. Default Property Value This property is initially factory preset to, that is, no system FQDN is specified. Supporting Mechanisms The LdapSystemFQDN property only appears in the LDAP mechanism. Editing Guidelines Use the following guidelines when editing the value of the LdapSystemFQDN property: Edit this property only for the LDAP mechanism. Only the server requires LdapSystemFQDN information. The client ignores this property. The value of this property must be the FQDN of the tdatsystem object that contains user, profile, role, and IP restriction information that apply to the database. The LdapBaseFQDN property contains the fully qualified distinguished name of a directory object that contains the User and Group objects, allowing them to be easily located. It constitutes the search base for objects relevant to the Teradata configuration. Note: This property is deprecated in favor of the LdapGroupBaseFQDN and LdapUserBaseFQDN properties. If the values of either LdapGroupBaseFQDN or LdapUserBaseFQDN are set (preferred), they will replace LdapBaseFQDN. The value of LdapBaseFQDN will serve as the default value for LdapGroupBaseFQDN and LdapUserBaseFQDN until such time as they are configured. Default Property Value This property is initially standard preset to, that is, no name is specified. Supporting Mechanisms The LdapBaseFQDN property only appears in the LDAP mechanism. Editing Guidelines Use the following guidelines when editing the value of the LdapBaseFQDN property: Edit this property only for the LDAP mechanism. Only the Teradata Database server requires LdapBaseFQDN information. The client ignores this property. You can use any object name that meets the criteria as long as it is can generate a unique, fully qualified distinguished name. 166 Security Administration

Chapter 8: TDGSS Administration Directory User Authentication Properties LdapGroupBaseFQDN The LdapGroupBaseFQDN property contains the fully qualified distinguished name of a directory object that contains the group objects relevant to the Teradata environment. When a value is specified, this property helps narrow and speed the search of the directory during user authorization, for directory groups that are mapped to one or more external roles. Default Property Value This property is initially standard preset to, that is, no name is specified. Supporting Mechanisms The LdapGroupBaseFQDN property has meaning only for the server version of the LDAP mechanism. The client version of the LDAP mechanism will not recognize this property. Note: This property only appears in the TDGSS Library Configuration file after an installation of, or an upgrade to, Teradata Database V2R6.2 or higher. It does not appear in the TDGSS User Configuration file. It must be manually inserted into the User Configuration file to make this feature available. For more information on LDAP referrals, see Optimization of Directory Searches on page 224. For information on how to insert this property into the LDAP mechanism, see Making Changes to the User Configuration Files on page 195. Editing Guidelines Use the following guidelines when editing the value of the LdapGroupBaseFQDN property: A value is required for this property if the LDAP AuthorizationSupported property is set to Yes, that is, where the directory contains mappings to Teradata Database objects. If you don t edit the default value for this property ( ), directory searches will use the value of the LdapBaseFQDN. However, because LdapBaseFQDN is depricated, this approach is not recommended. Only the server can use LdapGroupBaseFQDN information. Teradata clients ignore this property. For optimum efficiency in using this value as a search criterion, the LdapGroupBaseFQDN should be the FQDN of an object one level higher in the directory tree than the highest level group object that contains mappings to Teradata Database external role objects. Keeping this value at the lowest possible level that includes relevant information will speed the search. Security Administration 167

Chapter 8: TDGSS Administration Directory User Authentication Properties LdapUserBaseFQDN The LdapUserBaseFQDN property contains the fully qualified distinguished name of a directory object that contains the user objects. When set, this property helps narrow the search when a directory user is being authenticated by LDAP. Note: This property only has meaning when the directory is Active Directory or ADAM. Default Property Value This property is initially standard preset to, that is, no name is specified. Supporting Mechanisms The LdapUserBaseFQDN property has meaning only in the server version of the LDAP mechanism. The client version of the LDAP mechanism will not recognize this property. Note: This property only appears in the TDGSS Library Configuration file after an installation of, or an upgrade to, Teradata Database V2R6.2 or higher. It does not appear in the TDGSS User Configuration file. It must be manually inserted into the User Configuration file to make this feature available. For more information on LDAP referrals, see Optimization of Directory Searches on page 224. For information on how to insert this property into the LDAP mechanism, see Making Changes to the User Configuration Files on page 195. Editing Guidelines Use the following guidelines when editing the value of the LdapUserBaseFQDN property: A value is required for this property for all LDAP authentication on Active Directory or ADAM directories, regardless of the presence of mappings to Teradata Database objects or the setting of the AuthorizationSupported property. Edit this property only for the LDAP mechanism. Only the server can use LdapUserBaseFQDN information. The client ignores this property. Optimally, the LdapUserBaseFQDN is the FQDN of an object one level above the parent object that contains users. The value of the LdapUserBaseFQDN property usually corresponds to the value of the <Identity Search> Base attribute, if <Identity Search> is used, because both values should optimize search criteria. However, <Identity Search> is not a substitute for the LdapUserBaseFQDN property, as each performs a separate function. For information about the <Identity Search> function, see Identity Searches on page 205. 168 Security Administration

Chapter 8: TDGSS Administration Directory User Authentication Properties LdapClientDebug When set properly, the LdapClientDebug property assists the TSC in debugging LDAP directory issues. This property is not user-settable. Default Property Value This property is initially preset to 0, that is, no debugging parameters are specified. Supporting Mechanisms The LdapClientDebug property applies only to the LDAP mechanism. This property does not function when Teradata Database is running on Windows. Note: This property appears in the TDGSS Library Configuration file after an installation of, or an upgrade to, V2R6.2 or higher. It does not appear in the TDGSS User Configuration file. It must be manually inserted into the User Configuration file and replicated on all nodes to make this feature available for use. For more information on LDAP referrals, see Optimization of Directory Searches on page 224. For information on how to insert this property into the LDAP mechanism, see Making Changes to the User Configuration Files on page 195. Editing Guidelines Use the following guidelines when editing the value of the LdapClientDebug property: Only the TSC can properly set a correct value. Do not attempt to set this value without TSC assistance. Security Administration 169

Chapter 8: TDGSS Administration Directory User Authentication Properties LdapClientDeref The LdapClientDeref property contains information that allows LDAP to determine what kinds of referrals to chase. Note: This property only has meaning if the LdapClientReferrals property is set to yes or client referrals are being chased by default. The LdapClientDeref property has five valid settings: always never (the default) finding searching Default Property Value This property is initially preset to never, that is, LDAP will not chase any kind of referrals. Supporting Mechanisms The LdapClientDeref property applies only to the LDAP mechanism. Note: This property appears in the TDGSS Library Configuration file after an installation of, or an upgrade to, V2R6.2 or higher. It does not appear in the User Configuration file. It must be manually inserted into the TDGSS User Configuration file on each server node to make this feature available for use. For more information on LDAP referrals, see Optimization of Directory Searches on page 224. For information on how to insert this property into the LDAP mechanism, see Making Changes to the User Configuration Files on page 195. Editing Guidelines Use the following guidelines when editing the value of the LdapClientDeref property: Only the server can use LdapClientDeref information. The server ignores this property. Set the value to always to chase all referrals. Set the value to never (the default) to prevent all referral chasing. Set the value to finding to specify that only referrals generated while finding objects are to be chased. Set the value to searching to specify that only referrals generated while searching for a specific object are to be chased. 170 Security Administration

Chapter 8: TDGSS Administration Directory User Authentication Properties LdapClientRebindAuth When the LdapClientReferrals property is set to chase referrals, a new connection is established to the directory server and searches continue on that connection. The LdapClientRebindAuth property tells LDAP how to deal with (bind with) authentication on the new connections. Default Property Value This property is initially standard preset to yes, that is, LDAP will use the users credentials to rebind. Supporting Mechanisms The LdapClientRebindAuth property applies only to the LDAP mechanism. This property does not function when Teradata Database is running on Windows. Note: This property appears in the TDGSS Library Configuration file after an installation of, or an upgrade to, V2R6.2 or higher. It does not appear in the TDGSS User Configuration file. It must be manually inserted into the User Configuration file and replicated to all server nodes to make this feature available for use. For more information on LDAP referrals, see Optimization of Directory Searches on page 224. For information on how to insert this property into the LDAP mechanism, see Making Changes to the User Configuration Files on page 195. Editing Guidelines Edit LdapClientRebindAuth in the TDGSS User Configuration file to specify the how authentication should be handled when referrals are chased, according to the following guidelines: Setting the value of this property to yes (the default) tells LDAP to use the user credential info to authenticate on the new connection before searching. Setting the value of this property to no tells LDAP not to authenticate using the user credential info. Use an anonymous connection to do the search. This property has no meaning unless the LdapClientReferrals property is set to yes. Security Administration 171

Chapter 8: TDGSS Administration LDAP Binding Properties LDAP Binding Properties LdapClientMechanism Configuring the LDAP binding properties is required to enable service binds, when the default SASL/DIGEST-MD5 binding does not meet site security policy. The LdapClientMechanism property specifies the bind type to use during authentication. The LdapClientMechanism property has two valid settings: sasl/digest-md5 simple Default Property Value The default property value is SASL/DIGEST-MD5. Supporting Mechanisms The LdapClientMechanism property is supported by the following mechanisms: Mechanism Property Supported? Property Editable? TD1, TD2 No No KRB5, KRB5C No No NTLM, NTLMC No No SPNEGO No No LDAP Yes Yes Editing Guidelines Use the following guidelines when editing the value of the LdapClientMechanism property to specify the type of bind that will be used at authentication: Use the default setting, sasl/digest-md5, for standard LDAP binds. Change the setting to simple to support simple binds, which allows LDAP authentication for sites with a security policy that does not permit user identification and passwords to be stored in reversibly encrypted form. Note: If LdapClientMechanism is set to simple, Teradata strongly recommends concurrent setup and use of the LdapClientUseTLS property. Simple binds do not encrypt the user ID and password, and use of TLS is necessary to insure these logon elements against discovery. For further information, see LdapClientUseTLS on page 185. 172 Security Administration

Chapter 8: TDGSS Administration LDAP Binding Properties LdapServiceBindRequired Specifies whether or not the service bind will be done unconditionally. Default Property Value This property is preset to no for all mechanisms, indicating that a service bind will be performed only if an identity search is configured. Supporting Mechanisms Support for the LdapServiceBindRequired property is as follows: Mechanism Property Supported? Property Editable? TD1, TD2 No No KRB5, KRB5C No No NTLM, NTLMC No No SPNEGO No No LDAP Yes Yes Editing Guidelines Use the following guidelines when editing the value of the LdapServiceBindRequired property: Set the LdapServiceBindRequired property to yes to specify that a service bind will be performed unconditionally. Set the LdapServiceBindRequired property to no to specify that a service bind will be performed only if an identity search is configured. Security Administration 173

Chapter 8: TDGSS Administration LDAP Binding Properties LdapServiceFQDN The configured value of the LdapServiceFQDN property is a distinguished name (DN) that identifies a bindable object in the directory, which represents a service or application identity. Note: This property is required to enable simple bind authorization. Default Property Value The default property value for LdapServiceFQDN is, which specifies an anonymous bind. Supporting Mechanisms The LdapServiceFQDN property is supported by the following mechanisms: Mechanism Property Supported? Property Editable? TD1, TD2 No No KRB5, KRB5C No No NTLM, NTLMC No No SPNEGO No No LDAP Yes Yes Editing Guidelines Use the following guidelines when editing the value of the LdapServiceFQDN property to specify the DN of a bindable object in the directory, which represents a service or application identity. Specify the distinguished name (DN) of the bindable directory object that represents the service (Teradata Database). If this property contains a zero length string, the service bind will be an anonymous bind. For detailed information on binding, see Directory User Binding Options on page 198. 174 Security Administration

Chapter 8: TDGSS Administration LDAP Binding Properties LdapServicePassword If a password is required by the service FQDN, specify the password as the value of the LdapServicePassword property. Default Property Value The default property value is, that is, no password is required. Supporting Mechanisms The LdapServiceFQDN property is supported by the following mechanisms: Mechanism Property Supported? Property Editable? TD1, TD2 No No KRB5, KRB5C No No NTLM, NTLMC No No SPNEGO No No LDAP Yes Yes Editing Guidelines Use the following guidelines when editing the value of the LdapServicePassword property to specify the password for the FQDN specified in the LdapServiceFQDN property. If no password is specified, LDAP will use the default value and assume that no password is required. Security Administration 175

Chapter 8: TDGSS Administration LDAP Protection Properties LDAP Protection Properties SSL/TLS Protection LDAP supports two types of protection properties that are described in the following sections: SSL/TLS protection SASL protection LDAP protection properties are configurable only on Teradata Database nodes, and are not applicable to Teradata clients. SSL/TLS protection is recommended for systems that use simple binding. The LdapClientMechanism property sets the binding type to either SASL/DIGEST-MD5 (the default) or simple binding. For a description of SSL/TLS options, see Chapter 3: User Identification and Authentication. Basic SSL support is enabled using the LdapServerName property. Basic TLS support is enabled using the LdapClientUseTLS property. Use of advanced protection features also requires execution of the setup procedures shown in Appendix G: Setting up Kerberos Authentication on Unix Nodes. Avoiding Conflicts with OpenLDAP Tunables The protection properties perform the same functions as corresponding OpenLdap tunables. The TDGSS values will usually preempt the OpenLdap tunable settings for logons to Teradata Database, but to avoid unexpected results Teradata suggests using only the TDGSS properties to enable advanced protection features. The following table describes the correspondences. TDGSS LDAP Protection Property LdapClientTlsCACert LdapClientTlsCACertDir LdapClientTlsCert LdapClientTlsCipherSuite LdapClientTlsCRLCheck LdapCleintTlsKey LdapClientTlsRandFile LdapCleintTlsReqCert LdapClientUseTls OpenLdap Tunable TLS_CACERTFILE TLS_CACERTDIR TLS_CERT TLS_CIPHER_SUITE TLS_CRLCHECK TLS_KEY TLS_RANDFILE TLS_REQCERT No related OpenLdap tunable 176 Security Administration

Chapter 8: TDGSS Administration LDAP Protection Properties LdapClientTlsCACert The LdapClientTlsCACert property specifies the file name of the PEM-format file that contains all of the Certificate Authorities (CAs) TDGSS, TeraGSS, and OpenLdap tools will trust. Default Property Value The default value of the LdapClientTlsCACert property is, meaning that no cert file is specified. Supporting Mechanisms The LdapClientTlsCACert property is supported by the following mechanisms: Mechanism Property Supported? Property Editable? TD1, TD2 No No KRB5, KRB5C No No NTLM, NTLMC No No SPNEGO No No LDAP Yes Yes Editing Guidelines Use the following guidelines when editing the value of the LdapClientTlsCACert property to specify the file location that contains certificates for all of the Certificate Authorities the client will recognize. Set the value to a valid file name on each Teradata Database node, and on the Query Director, if used. This file must include the certificate for the CA that signed the directory server certificate. If the signing CA was not a top-level (root) CA, certificates for the entire sequence of CAs from the signing CA to the top-level CA should be present. Multiple certificates are simply appended to the file; the order is not significant. Security Administration 177

Chapter 8: TDGSS Administration LDAP Protection Properties LdapClientTlsCACertDir The LdapClientTlsCACertDir property specifies the path of a directory that contains individual CA certificates in separate files. LdapClientTlsCACertDir is meant to be used interchangeably with the LdapClientTlsCACert property, to support SSL/TLS protection for systems using simple binds. Configuration is needed for only one of them. For further information, see LdapClientTlsCACert on page 177. If you choose to configure LdapClientTlsCACertDir, the directory specified for the property value must be specially managed using the OpenSSL c_rehash utility. When using this feature, the OpenSSL library will attempt to locate certificate files based on a hash of their name and serial number. The c_rehash utility is used to generate symbolic links with the hashed names that point to the actual certificate files. Because of this, LdapClientTlsCACertDir can only be used with a file system that actually supports symbolic links. In general, it is simpler to use the TLS_CACERTFILE or LdapClientTlsCACert directive instead. For information on use of the OpenSSL c_rehash utility, see Creating Hashes Using c_rehash on page 303. Default Property Value The default value of the LdapClientTlsCACertDir property is, meaning that no cert directory is specified. Supporting Mechanisms The LdapClientTlsCACertDir property is supported by the following mechanisms: Mechanism Property Supported? Property Editable? TD1, TD2 No No KRB5, KRB5C No No NTLM, NTLMC No No SPNEGO No No LDAP Yes Yes Editing Guidelines Edit the value of the LdapClientTlsCACertDir property to specify the file location that contains certificates for all of the Certificate Authorities the client will recognize. 178 Security Administration

Chapter 8: TDGSS Administration LDAP Protection Properties LdapClientTlsCert The LdapClientTlsCert property specifies the file that contains the TDGSS or OpenLdap client certificate that will be used by the directory server to authenticate the database. Note: Specification of a cert file name for the value of this property is required for TLS mutual authentication of the directory and Teradata Database. Default Property Value The default value of the LdapClientTlsCert property is, meaning that no cert file is specified. Supporting Mechanisms The LdapClientTlsCert property is supported by the following mechanisms: Mechanism Property Supported? Property Editable? TD1, TD2 No No KRB5, KRB5C No No NTLM, NTLMC No No SPNEGO No No LDAP Yes Yes Editing Guidelines Edit LdapClientTlsCert in the TDGSS User Configuration file to specify the file location that contains the certificate. Security Administration 179

Chapter 8: TDGSS Administration LDAP Protection Properties LdapClientTlsCipherSuite The LdapClientTlsCipherSuite property specifies the ciphers and the cipher preference order that will be accepted from OpenSSL for use in the token exchange during directory user authentication. Note: This property is optional and should not be used without a full understanding of the effect of specifying a particular cipher. If you are not sure of the effect of configuring this property, contact Teradata Professional Services for assistance. Default Property Value The default value of the LdapClientTlsCipherSuite property is, meaning that no ciphers are specified. Supporting Mechanisms The LdapClientTlsCipherSuite property is supported by the following mechanisms: Mechanism Property Supported? Property Editable? TD1, TD2 No No KRB5, KRB5C No No NTLM, NTLMC No No SPNEGO No No LDAP Yes Yes LdapClientTlsCRLCheck Editing Guidelines Use the following guidelines when editing the value of the LdapClientTlsCipherSuite property to specify the cipher suite. Before configuring this property, use the command openssl ciphers -v ALL to obtain a list of ciphers available from OpenSSL. Specify a list of ciphers in preference order. Each item on the list must be separated by a colon. Instead of using cipher names, you can specify HIGH, MEDIUM, LOW, EXPORT, or EXPORT40 to indicate a strength range for acceptable ciphers. Specify TLSv1, SSLv3, or SSLv2 to indicate a cipher suite. For further information on cipher options available for use with this property, visit the following web site: http://www.openssl.org/docs/apps/ciphers.html The LdapClientTlsCRLCheck property specifies how the Certificate Revocation List (CRL) of the CA should be used to verify that the server certificates have not been revoked. This 180 Security Administration

Chapter 8: TDGSS Administration LDAP Protection Properties requires TLS_CACERTDIR parameter to be set. The argument can be specified with one of the keywords none, peer or all. Default Property Value The default value of the LdapClientTlsCRLCheck property is none none, meaning that no CRL checks will be performed. Supporting Mechanisms The LdapClientTlsCRLCheck property is supported by the following mechanisms: Mechanism Property Supported? Property Editable? TD1, TD2 No No KRB5, KRB5C No No NTLM, NTLMC No No SPNEGO No No LDAP Yes Yes Editing Guidelines Use the following guidelines when editing the value of the LdapClientTlsCRLCheck property to specify the required level of checking. Edit the value of the LdapClientTlsCRLCheck to none to specify that no CRL checks will be performed. Edit the value of the LdapClientTlsCRLCheck to peer to specify that the CRL of the server certificate will be checked. Edit the value of the LdapClientTlsCRLCheck to all to specify that the CRLs of the entire certificate chain will be checked. Security Administration 181

Chapter 8: TDGSS Administration LDAP Protection Properties LdapClientTlsKey The LdapClientTlsKey property specifies the file that contains the private key that matches the certificate stored in the file named in LdapClientTlsCert. Note: Specifying a value for this property is required when a value is specified for the LdapClientTlsCert property. Default Property Value The default value of the LdapClientTlsKey property is, meaning that no key file is specified. Supporting Mechanisms The LdapClientTlsKey property is supported by the following mechanisms: Mechanism Property Supported? Property Editable? TD1, TD2 No No KRB5, KRB5C No No NTLM, NTLMC No No SPNEGO No No LDAP Yes Yes Editing Guidelines Edit LdapClientTlsKey in the TDGSS User Configuration file to specify the file location that contains the key for the certificate specified in the LdapClientTlsCert property. 182 Security Administration

Chapter 8: TDGSS Administration LDAP Protection Properties LdapClientTlsRandFile The LdapClientTlsRandFile property specifies the file that provides random bits when /dev/ [u]random (a built in random number generator) is not available. Default Property Value The default value of the LdapClientTlsRandFile property is, meaning that no random bits file is specified. Supporting Mechanisms The LdapClientTlsRandFile property is supported by the following mechanisms: Mechanism Property Supported? Property Editable? TD1, TD2 No No KRB5, KRB5C No No NTLM, NTLMC No No SPNEGO No No LDAP Yes Yes Editing Guidelines Use the following guidelines when editing the value of the LdapClientTlsRandFile property to specify an alternate random number generator: Specify a value for the LdapClientTlsRandFile only when /dev/[u]random (a built in random number generator) is not available. Note: Availability of this file varies by operating system. SUSE Linux Enterprise Server systems provide the need file by default. Some operating systems do not provide /dev/ [u]random. In these cases, you must install a copy of EGD or PRNGD to provide the need function. When /dev/[u]random is not provided, set the value of the this the name of the EGD or PRNGD socket. Security Administration 183

Chapter 8: TDGSS Administration LDAP Protection Properties LdapClientTlsReqCert The LdapClientTlsReqCert property specifies what checks to perform on directory server certificates (if any) in a TLS-protected session. This property is required for authentication of the directory server by Teradata Database. Allowable Values The allowable values for the LdapClientTlsCert property are as follows: never -- The database will ask the directory server for a certificate allow -- The database will ask the directory server for a certificate. If no certificate is provided or an invalid certificate is sent, the connection will proceed normally. try -- The database will ask the server for a certificate. If no certificate is provided the connection proceeds normally. If an invalid certificate is provided, the connection is terminated. demand -- The value demand causes Teradata Database to ask the directory server for a certificate. If a certificate is not provided or an invalid certificate is sent, the connection is terminated. Default Property Value The default value of the LdapClientTlsCert property is never ; no cert file is specified. Supporting Mechanisms The LdapClientTlsReqCert property is supported by the following mechanisms: Mechanism Property Supported? Property Editable? TD1, TD2 No No KRB5, KRB5C No No NTLM, NTLMC No No SPNEGO No No LDAP Yes Yes Editing Guidelines Use the following guidelines when editing the value of the LdapClientTlsReqCert property to define the level to which directory server certificates will be checked by specifying one of the following keywords: For a value of never the directory server certificate is not requested. For a value of allow the directory server certificate is requested, optional, and not checked. For a value of try the directory server certificate is requested, optional, and checked. For a value of demand (the default) the directory server certificate is requested, required, and checked. 184 Security Administration

Chapter 8: TDGSS Administration LDAP Protection Properties LdapClientUseTLS The LdapClientUseTLS property specifies whether or not TLS protection (obfuscation) is enabled. Note: This property must be set to yes to enable advanced TLS capabilities, such as verifying the directory server certificate, that are dependent on other properties in this section. Default Property Value The default value of the LdapClientUseTls property is no, meaning that TLS protection is disabled. Supporting Mechanisms The LdapClientUseTLS property is supported by the following mechanisms: Mechanism Property Supported? Property Editable? TD1, TD2 No No KRB5, KRB5C No No NTLM, NTLMC No No SPNEGO No No LDAP Yes Yes Editing Guidelines Use the following guidelines when editing the value of the LdapClientUseTLS property to specify the type of bind that will be used at authentication: Set the property value to no (the default) to disable TLS. Set the property value to yes to enable basic TLS capabilities and allow configuration of advanced TLS options, such as Ldap client-server certificate authentication. For detailed procedures for configuring basic advanced TLS options, see Appendix G: Setting up Kerberos Authentication on Unix Nodes. Security Administration 185

Chapter 8: TDGSS Administration LDAP Protection Properties SASL Protection LdapClientSASLSecProps When a directory user logs on to a database, and the SASL token exchange between the directory server and Teradata Database or the Query Directory uses DIGEST-MD5 binding, the token exchange could be challenged and redirected to send the exchange in clear text. Use the LdapClientSaslSecProps property to set the set the security level to provide extra protection for the token exchange. The LdapClientSaslSecProps property specifies the security level for the token exchange. Default Property Value The default value of the LdapClientSaslSecProps property is minssf=0, meaning that the security level is compatible with all supported directory types and configurations. Supporting Mechanisms The LdapClientSaslSecProps property is supported by the following mechanisms: Mechanism Property Supported? Property Editable? TD1, TD2 No No KRB5, KRB5C No No NTLM, NTLMC No No SPNEGO No No LDAP Yes Yes Editing Guidelines Use the following guidelines when editing the value of the LdapClientSaslSecProps property to specify the bind protection that will be used at authentication: Set the property value to minssf=0 to avoid possible conflicts with directory types and configurations that cannot use a higher security level. Set the property value to a value of minssf=1 to require integrity checking of the token exchange. Integrity checking prevents a man-in-the-middle attack that could reset the QOP level and require transmission of the password in clear text. This setting is sufficient for most implementations. Set the property value as follows to encrypt the token exchange as follows: minssf=56 allows use of DES or other low-level ciphers minssf=112 allows use of triple DES and other strong ciphers minssf=128 allows use of the strongest ciphers, such as RC4 and Blowfish Note: minssf values above 1 require support of the corresponding encryption level by the directory, and cannot exceed the setting of the directory maxssf property. 186 Security Administration

Chapter 8: TDGSS Administration Confidentiality Properties Confidentiality Properties The following properties define the mechanism parameters that support confidentiality. VerifyDHKey This property indicates whether or not the mechanisms requests that the system perform an integrity check to verify that the DH Key is the same for both initiator and acceptor. Default Property Value This property is initially standard preset to no for all mechanisms, indicating that the system will not verify the integrity of the DH Key. This has been done to maximize system performance. Supporting Mechanisms The VerifyDHkey property is supported by the following mechanisms: Mechanism Property Supported? Property Editable? TD1 No No TD2 Yes Yes KRB5, KRB5C No No NTLM, NTLMC No No SPNEGO No No LDAP Yes No Editing Guidelines Edit the TDGSS User Configuration file to change the VerifyDHKey setting according to the following guidelines: You can set this property to yes for supported mechanisms to provide the user with early notification of whether or not the encryption will be successful. A yes setting will result in a modest performance degradation of the encryption sequence because the initiator and acceptor must exchange an extra message. Editing this property has meaning only for the client-side TdgssUserConfigFile.xml. Security Administration 187

Chapter 8: TDGSS Administration Confidentiality Properties DHKeyPand DHKeyG The Diffie-Hellman encryption key (DH Key) is made up of two values P and G. They both work together to insure the confidentiality of the encryption key when it is exchanged between initiator and acceptor. The Diffie-Hellman Method for key agreement, also called the Exponential Key Exchange, allows two hosts to create and share a secret key. The P and G parameters are both public to the system. P is a large prime number, and G is chosen so it is a small primitive root of P, that is, G is a primitive root if and only if G^((P-1)/q) mod P > 1 for all prime divisors q of P-1. The basic calculation is: G^X mod (P). The variable X is a private number that each user keeps to themselves. Each uses their private key X to calculate their public key, such that: PublicKeyUser1 = G^x mod (P) PublicKeyUser2 = G^y mod (P) Each user transmits their Public keys, so that User 2 has PublicKeyUser1 and User 1 has PublicKeyUser2. User1 computes: K1 = (PublicKeyUser2) ^x mod (P) User2 computes: K2 = (PublicKeyUser1) ^y mod (P) Default Property Value for DHKeyP This property is preset to a standard 640 bit DH Key supplied with Teradata Database. The following is a hex representation of a standard key: DHKeyP="E4BE0A78F54C4A0B17E7E9249A78BCC08868C17281D8463C880937853E73DDC7 87E41580A8AFE2594D984C9E0814C590790354ECCD1BE8EA85961E5E0974B32EFE178335 F061E80189B4BDAA20F67B47" Default Property Value for DHKeyG This property is preset to a standard DH base key, such as: DHKeyG="0500000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000" Supporting Mechanisms The DHKey P and DHKey G properties are currently supported by the following mechanisms: Mechanism Property Supported? Property Editable? TD1 No No TD2 Yes Yes KRB5, KRB5C No No NTLM, NTLMC No No SPNEGO No No 188 Security Administration

Chapter 8: TDGSS Administration Confidentiality Properties Mechanism Property Supported? Property Editable? LDAP Yes Yes Editing Guidelines Edit the TDGSS User Configuration file to change the DHKeyP and DHkey G according to the following: In high security environments, administrators may choose to replace the preset key and/or rotate keys periodically to minimize the chance that the key will be compromised. If you edit DHKeyP, you should also edit DHKeyG. Editing this property has meaning only for the TdgssUserConfigFile.xml on Teradata Database nodes, and on the Query Director, if used. Any DH Key with a supported key length may be used. Supported key lengths are as follows: 640 bit TDGSS does not currently support longer DH Key lengths Security Administration 189

Chapter 8: TDGSS Administration Changing the TDGSS Configuration Changing the TDGSS Configuration The TDGSS User Configuration file contains the editable portion of the TDGSS mechanisms. You can change the function of Teradata Database security mechanisms and customize them to meet your system-specific needs by editing the security mechanism property values. There are only two reasons to edit the User Configuration files: To change the value of an existing mechanism property. To add a mechanism or property to the tdgssuserconfiguration.xml so it can be edited. For details on how to add mechanisms and properties that may not be in your User Configuration file, see Adding New Mechanisms or Properties to the User Configuration File on page 193. The files are in plain text file, stored in xml format. You can read or edit the file at any time using a plain text editor such as vi on Unix systems, or Notepad on Windows systems. The Teradata Client also contains the TDGSS User Configuration File, which performs the same function on the Client system and is edited in the same way. Note: For most property values, you only need to edit the client-side User Configuration files. Some properties listed in the TDGSS User Configuration file are not currently editable for existing mechanisms, and may not even be used by the system. They are listed in the configuration files to: provide compatibility with GSS standards allow for future Teradata Database development Note: When you edit the TDGSS User Configuration file, make sure that the edits are correct and compatible with the version of TDGSS currently in use. Teradata Database will not check the validity of your edits, but will return error messages in the event it encounters an invalid configuration. Do not make any edits that are new to a version of Teradata Database until you are sure that you will not need to back down to a previous version. Some edits that function with a new version of Teradata Database may not be compatible with previous versions. Related Topics Editing suggestions and restrictions are noted in the Editing Guidelines section for each mechanism property, beginning with MechanismEnabled on page 150. For specific instructions on how to locate and edit the TDGSS User Configuration files, see Locating TDGSS Files on page 129. For more about version switching, see Versions and Version Switching on page 128. For information about saving the existing TDGSS configuration during a migration, see Migrating Data to Teradata Database 13.0. 190 Security Administration

Chapter 8: TDGSS Administration Changing the TDGSS Configuration Differences in Function for Client and Server Configuration Files Teradata provides two separate sets of Configuration files--one for the server and one for the client. Each tdgss configuration element is used in a different way: Configuration File Type Software Module Rationale for Editing Packages Installed on Each Server Node tdgssuserconfigurationfile TDGSS Edit these files to: Enable the mechanisms and capabilities available to all clients, by setting the MechanismEnabled property. Specify they type of directory authentication to be used by setting the AuthorizationSupported property. Provide site-specific values for some optional LDAP properties. Note: Property value settings must be the same for all server nodes. tdgsslibraryconfigurationfile Do not edit the Library Configuration File. These files contain the current default configuration, including mechanism properties that are not editable. tdgssuserconfigurationfile TeraGSS Edit these files to restrict the mechanisms and capabilities available to administrators logging on from database nodes. Will not affect administrator logons from clients. tdgsslibraryconfigurationfile Do not edit the Library Configuration File. These files contain the current default configuration, including mechanism properties that are not editable. Packages Installed on Each Network-Attached Client tdgssuserconfigurationfile TeraGSS Edit these files to restrict the mechanisms and capabilities available on individual clients. The configuration may or may not match from one client to the next depending client requirements. Note: Both Windows and Windows.Net configuration files exist simultaneously on Windows clients that run.net Data Provider for Teradata. Generally, edits will apply only to one file or the other, depending on the property value being edited. tdgsslibraryconfigurationfile Do not edit the Library Configuration File. These files contain the current default configuration, including mechanism properties that are not editable. Security Administration 191

Chapter 8: TDGSS Administration Changing the TDGSS Configuration General Rules for Editing When editing mechanism property values, keep in mind the following general rules: Before you edit a mechanism, refer to the editing guidelines for each property, as shown later in this section. Some mechanism properties are not active for some mechanisms, and some property values are only valid with their default settings. Do not edit the values of these properties. The system will pay no attention to such edits unless the properties are revised to allow editing and you install them as part of a later software release. If you make prohibited edits and they still exist in the TdgssUserConfigFile.xml when you install a new version of TDGSS, they may cause unexpected problems. For information on the mechanisms showing which properties are active and whether you can usefully and safely edit them, see the Editing Guidelines for each property in the sections that follow this one. You can make any one mechanism the default mechanism. The system will automatically use this mechanism so users do not need to select a mechanism at logon. Note: In cases where the client and server define different default mechanisms, and no mechanism is selected by the user, the client default mechanism always takes precedence for the session. If the client does not define a default mechanism, the system defers to the server-defined default mechanism. For detailed information on how the system handles mechanisms, see Mechanism Handling on page 136. You can individually enable or disable mechanisms. Note: A logon will fail if the selected mechanism is not enabled on both the server and client. This is true for both system-selected (default) and user-selected mechanisms. Security requirements may vary from one client station or group to another. You may find it useful to enable a different set of mechanisms and/or define a different default mechanism on one client than on another. You must determine whether or not to edit all LDAP-specific properties if you plan to enable directory-based user authentication. These properties begin all with Ldap, for example, LdapServerRealm. For a complete listing of these properties, see the section beginning with LdapServerName on page 162. Some optional LDAP properties do not appear in the LDAP mechanism. To be usable, you must add them manually to the server-side TdgssUserConfigFile.xml. For a discussion of the rationale for editing these properties, see Adding New Mechanisms or Properties to the User Configuration File on page 193. Edited values must conform to the editing guidelines listed for each property as shown in the sections that follow. To determine allowable values for a particular property, refer to Appendix D: System Evaluation Tasks for Directory Integration.. If you edit the Teradata Database server configuration, you must make the change in the tdgssuserconfiguration file on every node in the server system. Similarly, if you want to 192 Security Administration

Chapter 8: TDGSS Administration Changing the TDGSS Configuration change the client configuration, you must edit the user configuration file on every client machine that requires access to the change. Editing mechanism property values in the TdgssUserConfigurationFile.xml on the server does not result in changes to the user configuration files on the client--you must edit the files individually. Note: Remember, there are two sets of client files--one for client stations, and one for the Teradata Database server. The server-side client files are used by the system whenever an application is run from a Teradata Database node or an AWS. After you complete an edit of the tdgssuserconfiguration files, you must run the TDGSSConfig tool to make the system aware of the changes. Adding New Mechanisms or Properties to the User Configuration File A number of new mechanisms and properties have been or will be introduced into the TDGSS Library Configuration since the initial release of TDGSS in V2R6.0. These new mechanisms and properties do not appear in the TDGSS User Configuration File, though some will function using the default property values without further actions. To change the default functionality, or to activate properties that do not function with their default values, you must edit the TdgssUserConfigFile.xml by adding the new mechanism or property and changing the property value(s). For information on how to manually add these properties to the LDAP mechanism in the tdgssuserconfiguration file, see Making Changes to the User Configuration Files on page 195. The following list shows the mechanisms and properties that must be manually added to the TdgssUserConfigFile.xml before editing can be performed. Name Editing Rationale Mechanisms SPNEGO Edit to enable/disable the mechanism or to set the DelegateCredentials property. Properties LdapClientDebug LdapClientDeref LdapClientRebindAuth LdapClientMechanism Not user-settable. For use by TSC only. Used only for setup of referral chasing. For details, see Optimization of Directory Searches on page 224. Edit only to change the binding type from the default DIGEST-MD5 simple binding. For more information, see Directory User Binding Options on page 198. Security Administration 193

Chapter 8: TDGSS Administration Changing the TDGSS Configuration Name LdapClientSaslSecProps LdapClientTlsCACert LdapClientTlsCACertDir LdapClientTlsCert Editing Rationale Provides protection for the exchange TDGSS messages during directory user authentication, which some directory types allow to be sent in clear text. For information, see Chapter 4: Protection. Edit these properties to enable TLS protection options. For details, see Appendix G: Setting up Kerberos Authentication on Unix Nodes.. LdapClientTlsCipherSuite LdapClientTlsCRLCheck LdapClientTlsKey LdapClientTlsRandFile LdapClientTlsReqCert LdapClientUseTLS LdapGroupBaseFQDN LdapUserBaseFQDN LdapServiceBindRequired LdapServiceFQDN LdapServicePassword Edit these properties to narrow the search base for directory user authentication. For more information, see the text beginning with LdapGroupBaseFQDN on page 167. Edit only to setup the directory for service binds, wherein the directory authenticates Teradata Database. For details, see Service Binds on page 199. For detailed information on property characteristics and editing suggestions, see Mechanism Properties on page 144. Effects of Upgrade and Migration on TDGSS Configuration Changes Upgrading a system to a new release of Teradata Database will not overwrite the TdgssUserConfigFile.xml. The upgrade will retain the existing configuration, including any edits made up to that point. Migration of Teradata Database data to new hardware, or to the same hardware after a change of operating system, initially sets all TDGSS mechanism properties to default values. In order to retain any edits made to the User Configuration file, copy the TdgssUserConfigFile.xml from the source system and save it in place of the default configuration file on the destination system. 194 Security Administration

Chapter 8: TDGSS Administration Making Changes to the User Configuration Files Making Changes to the User Configuration Files Planning a Configuration Change Teradata Database provides administrators the ability to customize security functions to meet site-specific security needs by editing security mechanisms and properties. Before you begin the change process, make sure you fully understand the rationales and methods for editing mechanism properties. For basic editing criteria, including the differences between editing the TDGSS User Configuration file (tdgssuserconfigfile.xml) on the server and on clients, see Changing the TDGSS Configuration on page 190 and General Rules for Editing on page 192. For a detailed explanation of the rationale for editing individual mechanism properties, see Confidentiality Properties on page 187. The configuration change process has minor differences among operating systems. See Appendix C: Changing the TDGSS Configuration, for step-by-step instructions on changing the TDGSS configuration on Windows, SUSE Linux Enterprise Server, and MP-RAS Teradata Database nodes, and on client systems. Check the Current Configuration Before you Make a Change An important part of planning for a TDGSS configuration change is to make sure you know the current configuration before beginning the configuration change process. Use the dumpcfg utility to review the current configuration before you begin making changes. For detailed instructions on how to use the dumpcfg utility, see Using dumpcfg to Check the Current TDGSS Configuration on page 233. Security Administration 195

Chapter 8: TDGSS Administration Making Changes to the User Configuration Files 196 Security Administration

CHAPTER 9 Directory Management of Database Users Directory-based management of database users simplifies user management by providing centralized user control. Information about database users is normally created and maintained in the database. However, many potential database users may already be defined in a directory. In order to minimize the amount of duplication between these two user-management systems and provide the maximum flexibility, Teradata Database allows administrators to delegate some user-management tasks to a supported directory. Two types of user credential information are processed by the database at logon: A unique user identity, including username and password, allows the database to authenticate the user as valid A defined set of database privileges allows the database to authorize which privileges the user can exercise within the database Authentication and authorization of directory users is mediated by the LDAP security mechanism, which must be selected by directory users when logging on to the database. By means of its property settings, the LDAP mechanism tells the Teradata Gateway which usermanagement tasks have been delegated to the directory. Note: Directory-based management of Teradata Database users requires completion of a number of setup tasks in the database. For information, see the sections beginning with System Requirements for External Authentication on page 53. For information on setting up users in the database, see Database Administration. For information on configuring a directory to manage database users, see Configuring a Directory to Manage Database Users on page 217. Supported Directories Teradata Database interfaces with all LDAP-compliant directories. However, it has only been fully certified with the directories in the following table. Note that support varies slightly with the binding method specified in the LdapClientMechanism property: Security Administration 197

Chapter 9: Directory Management of Database Users LDAP Binding Options With DIGEST-MD5 Binding Active Directory on Windows 2003 only. Sun Java System Directory Server 5.2 or later. Novell edirectory SP2. With Simple Binding Active Directory (All versions). Active Directory Application Mode (ADAM), all versions; on Windows Server Release 2 or later. Novell edirectory SP2. Sun Java System Directory Server version 5.2 or later. Notes: 1 The operating system on which Teradata Database runs has no effect on directory support. 2 Teradata clients are not subject to the support requirements shown above. 3 Support for other LDAP-compliant directories is available through Teradata Professional Services. 4 Teradata Database systems running Windows Server 2003 and using SASL/DIGEST-MD5 binding must install Windows Service Pack 1 (SP1) to support Sun Java System Directory Server. LDAP Binding Options Once a directory authenticates a user it must bind the user to the service connection prior to allowing the user to access the service, such as Teradata Database. The LDAP mechanism provides two options for binding the user: SASL/DIGEST-MD5 binding Simple binding The choice of a binding method is primarily a matter of site policy, but simple binding is the preferred method because it is more secure, when used with SSL/TLS protection enabled. In addition to user binding, Teradata Database also provides these service binding options: Authentication of the service bind by the directory Mutual authentication of the service and the directory. Each binding option requires the completion of one or more setup tasks, as shown in the following sections. Directory User Binding Options DIGEST-MD5 Binds DIGEST-MD5 is the default binding scheme for use with Teradata Database LDAP authentication. 198 Security Administration

Chapter 9: Directory Management of Database Users LDAP Binding Options Implementing DIGEST-MD5 Binds To use DIGEST-MD5 binding, set the LdapClientMechanism property to sasl/digest-md5 (the default). For information, see LDAP Binding Properties on page 172. Simple Binds The main reasons to use simple binding are as follows: The directory does not support DIGEST-MD5 binding. Implementation of DIGEST-MD5 is difficult. Site policy requires simple binding for security reasons. The site uses an LDAP-compliant directory that is not certified by Teradata, for example: IBM z/os ApacheDS Oracle Internet Directory Implementing Simple Binds To implement simple binding, do the following: Set the LdapClientMechanism property to simple. By default, a simple bind usually requires authentication of the entire DN as the user identity, although some directories such as Active Directory and ADAM extend simple binding to allow a less complex name to be entered at logon. For directories that require simple binds and do not support simple user names in the logon, do one of the following: If the directory is set up with a precise, centralized user location scheme, implement the <IdentityMap> option to link the simple username to the DN in the directory. For information, see Identity Mapping on page 202. If the directory is set up with a divergent user location scheme, implement the <IdentitySearch> option, which allows Teradata Database to search the directory for the DN. For information on identity searches, see Identity Searches on page 205. Note: The <IdentitySearch> option also requires configuration of service binding. For information, see Service Binds on page 199. Service Binds When a directory user logs on to Teradata Database, the LDAP mechanism queries the directory to gain information about the user before allowing the logon to proceed. In such cases Teradata Database, and the Query Director when used, are clients of the directory. Many sites require that a directory client, that is, the service, must be identified to the directory before authentication and authorization of the directory user takes place. The directory employs a service bind to authenticate the service. Service binds are required for the following reasons: To comply with site policy that requires that any directory client must identify itself to the directory. Security Administration 199

Chapter 9: Directory Management of Database Users LDAP Binding Options To ensure that identity searches of the directory to locate a directory user DNs are being performed by a fully authenticated directory client. When service binds are employed, the LDAP mechanism will open a connection to the directory server normally, but will inject a service bind, and optionally, a search for the user DN before rebinding using the user credentials. LDAP Mechanism Properties that Support Service Binds Evaluate all the LDAP mechanism properties that support service binds. You may need to configure some or all of them when implementing service binds on your system. Property Data Type Property Value Setting LdapServiceBindRequired Yes/No A setting of yes means that a service bind is performed unconditionally. A setting of no means that a service bind is performed only if an identity search is performed. For information on identity searches, see Identity Searches on page 205. LdapServiceFQDN Distinguished name A DN that identifies a bindable object in the directory that represents a service or application identity in this case Teradata Database, or Query Directory, if used. If this property contains a zero length string, the service bind will be an anonymous bind. LdapServicePassword String If a password is required for the service FQDN, the password is configured as the value of this property. For detailed information on these properties, see LDAP Binding Properties on page 172. The following sections show how to configure the LDAP binding properties for common variations of mandatory service binds, that is when the LdapServiceBindRequired property is set to yes and the bind is performed unconditionally. Authenticated User Service Binds Authenticated user service binds are made between the username (and password, where required) submitted by the service and a directory object. All directories certified to operate with Teradata Database support bindable objects. Creating bindable objects varies among directories, but all such objects include a userpassword attribute. A normal directory user identity will function adequately as a bindable service DN, but it may be more convenient to create one or more special objects to represent services that must access the directory. Such bindable objects are easier to set up because they do not require things like common names, email addresses, user IDs, and other attributes that directories normally require of user objects. Teradata Database requires that the service DN for the object be 200 Security Administration

Chapter 9: Directory Management of Database Users LDAP Binding Options bindable. In situations where the site has installed Teradata schema, it may be convenient to make the tdatsystem object be bindable, although it is not required. Configuration Requirements Configuring an authenticated user service bind requires two activities: Updating the TdgssUserConfigFile.xml Creating a bindable object in the directory to represent the service Note: When a service bind is performed and an <IdentitySearch> is configured, the identity used to authenticate the service (Teradata Database or Query Director) must have the permission to search the portion of the directory where users are defined. If an <IdentitySearch> is not configured, no ability to search the directory is required. TdgssUserConfigFile.xml for Service Binds The following example shows the TdgssUserConfigFile.xml configuration required to accomplish an authenticated service bind: <Mechanism Name="ldap"> <MechanismProperties... LdapServiceBindRequired="yes" LdapServiceFQDN="cn=serviceid,ou=services,dc=domain,dc=com" LdapServicePassword="secret"... /> </Mechanism> Directory Configuration for Sun Java Directory Server Service Binds Configuration of a bindable directory object for the service is identical for Sun Java Directory Server and OpenLdap because they both support the simplesecurityobject class of directory objects. Use the following example to configure a bindable directory object: dn: cn=dataone,cn=tdat,ou=production,dc=division,dc=company,dc=com objectclass: top objectclass: tdatsystem objectclass: simplesecurityobject cn: dataone userpassword: secret Directory Configuration for Active Directory and ADAM Service Binds Configuration of a bindable directory object for the service is identical for Sun Java Directory Server and OpenLdap because they both support the msds-bindableobject class of directory objects. Use the following example to configure a bindable directory object: dn: cn=dataone,cn=tdat,ou=production,dc=division,dc=company,dc=com objectclass: top objectclass: tdatsystem objectclass: msds-bindableobject cn: dataone userpassword: secret Security Administration 201

Chapter 9: Directory Management of Database Users Directory User Identification Options Anonymous Service Binds An anonymous service bind may be used when the directory allows read access for unidentified services. This variation is rare since most directory information is considered to be private. The following technique may be employed in the TdgssUserConfigFile.xml file for sites that allow an anonymous bind of the service. <Mechanism Name="ldap"> <MechanismProperties... LdapServiceBindRequired="yes" LdapServiceFQDN="" LdapServicePassword=""... /> </Mechanism> Note: Because the bind is anonymous, a corresponding bindable directory object is not required. Directory User Identification Options Directories store information about users in directory objects. Binds (except anonymous binds) locate the user by the distinguished name of the directory user object. A distinguished name (DN) is a very long string that is normally unknown to users, and would be difficult to remember even if it was known. For example, a typical user name looks something like ab111222, while the actual name of the user object might be something like: cn=ab111222,ou=northamerica,ou=useraccounts,dc=div,dc=corp,dc=com To alleviate the need for directory-based users to enter the entire DN string most directories, and Teradata Database, allow use of logon usernames that are much shorter and simpler than a DN. However, the authentication process still requires binding to the DN, so there must be some linkage between the simple username in the logon string and the DN. LDAP user identification options include Identity Mapping and Identity Search, which provide the following benefits: Allow directory users to employ a simple username instead of a full DN during logon. Increase the efficiency for the process of binding the simple username to the DN. Identity Mapping Identity mapping provides a way to assist the binding process in converting a simple user name into a distinguished name (DN). The <IdentityMap> option is useful only if the directory user DN may be canonically created from the user authcid without requiring a directory search. 202 Security Administration

Chapter 9: Directory Management of Database Users Directory User Identification Options The identity map defines a pattern relationship between the simple username and the full DN. With this pattern LDAP can extrapolate the user DN from the information in the simple username. Configuring an Identity Map Identity mapping requires adding an <IdentityMap> element to the TdgssUserConfigFile.xml just below the <MechanismProperties> element, in the TDGSS (Teradata Database) or TeraGSS (Query Director) for the LDAP mechanism. Identity mapping uses the following basic form to change the LDAP configuration in the TdgssUserConfigFile.xml: <Mechanism Name="ldap"> <MechanismProperties... /> <IdentityMap Match="<Posix regular expression-encoded matching rule>" Pattern="<Substitution rule>"/> </Mechanism> The form in which the username is entered in the logon string determines the identity mapping strategy. For examples of common LDAP username logon forms, see the section beginning with LDAP Logons on page 75. The <IdentityMap> element has two attributes, Match and Pattern. Both attributes are required. The function of each attribute is described in the following table, which corresponds to the Example Identity Map for the UPN Form shown later in this section. Attribute Name Attribute Value Description Match "([^@]+)@([^\.]+)\.([^\.]+)\.([^\.]+)" A Posix regular expression representing a matching rule that shows how the username is divided into sub-strings. The individual substrings are enclosed by ( ). Pattern "uid=${1},ou=people,dc=${2},dc=${3},dc=${4}" The substitution rule that determines how a DN is extrapolated from the username substrings defined in the Match attribute. Note: For username formats that do not include domain information, such information is expressed in the Pattern as values for ${2}, ${3}, and ${4}. Security Administration 203

Chapter 9: Directory Management of Database Users Directory User Identification Options Note: A service bind is not needed for identity mapping because it does not require the service to freely search the directory. Example Identity Map for the UPN Form To create an identity map for usernames that will logon using only the UPN form, user@dom1.dom2.dom3, configure the LDAP mechanism as follows: <Mechanism Name="ldap"> <MechanismProperties... /> <IdentityMap Match="([^@]+)@([^\.]+)\.([^\.]+)\.([^\.]+)" Pattern="uid=${1},ou=users,dc=${2},dc=${3},dc=${4}"/> </Mechanism> The Pattern attribute contains a substitution schema. The values refer to the four substrings created from the username by the Match attribute. The term ${1} pertains to the userid, which is found in the first substring of the username. Unlike the authcid form, a UPN username includes domain information, so the Pattern attribute does not contain complete values for the terms ${2}, ${3}, and ${4}. When one of these values is encountered, the identity map substitutes the corresponding substring from the username, as shown in the following table: User Name ${1} ${2} ${3} ${4} Result ab111222@div.corp.com ab111222 div corp com uid=ab111222,ou=users,dc=div,dc=corp,dc=com adminuser@sales.corp.com adminuser sales corp com uid=adminuser,ou=users,dc=sales,dc=corp,dc=com Example Identity Map for the Authcid Form The following <IdentityMap> can be used for any valid authcid logon. This map allows a much wider variation in usernames and can be used for authcid and UPN formats. a simple username in the form: ab111222 a complex username in the form: ab111222@div.com or ab111222@div.corp.com An authcid identity map treats the entire string as the username, ignoring any domain information to the right of the @ sign, so domain information sufficient to construct the DN must appear as part of the Pattern attribute. For example: <Mechanism Name="ldap"> <MechanismProperties... /> <IdentityMap Match="(.*)" Pattern="cn=${1},ou=people,dc=div,dc=corp,dc=com"/> 204 Security Administration

Chapter 9: Directory Management of Database Users Directory User Identification Options </Mechanism> Example of an Identity Map for NT Logons The following <IdentityMap> can be used for usernames in a Windows NT logon (NTLM), expressed in a form such as td\ab111222. <Mechanism Name="ldap"> <MechanismProperties... /> <IdentityMap Match="[Tt][Dd]\\(.+)" Pattern="cn=${1},ou=users,dc=td,dc=teradata,dc=com"/> </Mechanism> Similar to the authcid form, this identity map extracts no domain information from the username, but instead uses information provided in the Pattern attribute to construct the DN. Identity Searches An identity search allows the directory to be searched for a user identity based on the username (authcid) provided in the logon string. The search uses information in the directory to provide the user distinguished name (DN) for all LDAP logons, whether or not the directory maps users to Teradata Database objects. The identity search function is only usable where user authentication uses simple binding. Example Configuration for <IdentitySearch> You can use the NT logon manager name format to obtain the DN of users in the Teradata TD Windows domain by employing an <Identity Search>. The LDAP configuration for an <IdentitySearch> in the TdgssUserConfigFile.xml uses the following form: <Mechanism Name="ldap"> <MechanismProperties... /> <IdentitySearch Match="[Tt][Dd]\\(.+)" Base="ou=user accounts,dc=td,dc=teradata,dc=com" Scope="subtree" Filter="(&(objectClass=user)(sAMAccountName=${1}))"/> </Mechanism> Explanation The <IdentitySearch> element contains four attributes, all of which must be present. These attributes define the parameters of a directory search that TDGSS will conduct for each logon by a directory user. The attributes are described in the following table: Security Administration 205

Chapter 9: Directory Management of Database Users Directory User Identification Options Attribute Name Attribute Value Description Match "[Tt][Dd]\\(.+)" A regular Posix expression that matches the username (authcid). Base "ou=user accounts,dc=td,dc=teradata,dc=com" A pattern into which substrings from the Match attribute's value are substituted resulting in construction of the DN used as the search base Scope "subtree" A string representing the search scope. The value base requests that the object named in the Base attribute is to be searched. The value onelevel requests that the children of the Base object are searched. The value subtree requests that the entire subtree starting with Base is to be searched. Filter "(&(objectclass=user)(samaccountname=${1}))" A pattern into which substrings from the Match attribute's value are substituted resulting in an expression used as the search filter as defined in IETF RFC 2254. Search Results Using a Windows domain, TD, and the specified search scope of subtree, and search base of ou=user accounts,dc=td,dc=corp,dc=com. from the preceding example, the following identity searches and results occur. Username Filter Result td\ab111222 td\xy333444 td\user1234 (&(objectclass=user) (samaccountname=${1} )) CN=ab111222,OU=NorthAmerica,OU=User Accounts,DC=TD, DC=CORP,DC=COM CN=xy333444,OU=NorthAmerica,OU=User Accounts,DC=TD, DC=CORP,DC=COM Search returns no results, indicating that the user is not defined in the directory. Using <IdentityMap> and <IdentitySearch> in Combination Many companies may define users in more than one directory subtree, and also want to allow users to employ any of a variety of username formats. Configuring the system to meet these diverse needs probably will require a combination <IdentityMap> and <IdentitySearch> specifications. Observe the following configuration characteristics when setting up complex directory user identification strategies: 206 Security Administration

Chapter 9: Directory Management of Database Users Directory User Identification Options Any number of <IdentityMap> and <IdentitySearch> elements may be added to the LDAP configuration. The elements may be mixed and may be provided in any order. The <IdentityMap> and <IdentitySearch> elements are processed in the order they appear in the configuration. The first <IdentityMap> or <IdentitySearch> element whose Match expression completely consumes the user name (authcid) is used. If no <IdentityMap> or <IdentitySearch> completely consumes the user's name (authcid), the user's name (authcid) is used as it was originally specified. If an <IdentitySearch> is selected and the <IdentitySearch> does not return exactly one object, authentication fails. If an <IdentityMap> is selected and the mapped identity does not exist in the directory, authentication fails. Note: An additional substitution pattern, ${0}, contains the entire user name (authcid). This substitution string is always present and usable. Use Case for Combined <IdentityMap> and <IdentitySearch> Suppose a company employs a directory with two trees. Each tree defines its own set of users, but the users in this environment can be authenticated in either tree. Tree A is named dc=div,dc=corp,dc=com and is in Windows domain DOM1. Tree B is named dc=newyork,dc=corp,dc=com and is in Windows domain DOM2. The Administrator wants to allow use of any of the following username formats in the logon: the user NTLM identity, such as div\cc444555 the user UPN, such a as cc444555@div.com the user DN, such as cc444555@\newyork Further, if the domain name is not provided, the search must use the DOM1 tree by default. This approach will authenticate the following username forms: cc444555 div\cc444555 cc444555@div.corp.com _DOM2\cc444555 cc444555@newyork.corp.com Configuration for Combined Usage Case The following example shows the configuration for the scenario described in the previous section. <Mechanism Name="ldap"> <MechanismProperties... /> Security Administration 207

Chapter 9: Directory Management of Database Users Directory User Identification Options <IdentitySearch Match="([^\\=]+)\\([^=]+)" Base="dc=${1},dc=corp,dc=com" Scope="subtree" Filter="(&(objectClass=user)(sAMAccountName=${1}))"/> <IdentitySearch Match="([^@=]+)@([^\.=]+)\.([^\.=]+)\.([^\.=]+)" Base="dc=${2},dc=${3},dc={4}" Scope="subtree" Filter="(&(objectClass=user)(userPrincipalName=${0}))"/> <IdentitySearch Match="([^\\@=]+)" Base="dc=div,dc=corp,dc=com" Scope="subtree" Filter="(&(objectClass=user)(sAMAccountName=${1}))"/> </Mechanism> Search Results for Combined Usage Case The configuration for the typical use case shown in the previous section yields the search results shown in the following table. User Name Identity Search Resulting Search Base Resulting Search Filter cc444555 3rd dc=div,dc=corp,dc=com (&(objectclass=user)(samaccountname=cc444 555)) div\cc444555 1st dc=div,dc=corp,dc=com (&(objectclass=user)(samaccountname=cc444 555)) DOM2\cc444555 1st dc=dom2,dc=corp,dc=com (&(objectclass=user)(samaccountname=cc444 555)) cc444555@div.corp.com 2nd dc=div,dc=corp,dc=com (&(objectclass=user)(userprincipalname=cc444 555@div.corp.com)) cc444555@dom2\corp.com 2nd dc=dom2,dc=corp,dc=com (&(objectclass=user)(userprincipalname=cc444 555@DOM2.corp.com)) Search Variations If the configuration shown in the previous section processed a username entered in DN form cn=dl160010,ou=northamerica,ou=user accounts,dc=td,dc=teradata,dc=com no filter would be engaged because every filter excludes the equal-sign character, and this form of user name contains equal signs. Because of this, no matches occurred and the username is used without change. Note the use of ${0} in the second configured <IdentitySearch>. This substitution variable refers to the entire username (authcid) string. Since our pattern has enforced the naming 208 Security Administration

Chapter 9: Directory Management of Database Users Directory User Management Options convention used in the DOM1 and DOM2 domains for the userprincipalname attribute, use of the entire authcid is adequate. This example does not work in the Teradata environment because the two trees, dc=dom2,dc=teradata,dc=com and dc=td,dc=teradata,dc=com exist in separate directory environments. In order for this kind of configuration to work, the trees would have to be managed by the same directory service. The preceding example is overly complex. Most customers will have one and only one way of identifying users so one <IdentitySearch> or <IdentityMap> element is all that will typically be required. The example is present primarily to illustrate the flexibility of <IdentitySearch> and <IdentityMap> elements. Using <IdentityMap> and <IdentitySearch> with DIGEST-MD5 The <IdentityMap> and <IdentitySearch> elements are generic string manipulators and, although they are most often used with simple binding, they can also be used with the default DIGEST-MD5 binding. Most directory servers accept a user name (authcid) for DIGEST-MD5 binding as the user DN if preceded by the string dn:. An <IdentityMap> can be used to automatically prepend the dn:. Some directory servers accept a user name (from the uid or userprincipalname attribute) preceded with a u:, which can also be prepended by means of an <IdentityMap>. Example <IdentityMap> Configuration for DIGEST-MD5 The following is a typical configuration for an <IdentityMap> to be used with DIGEST-MD5 binding. <Mechanism Name="ldap"> <MechanismProperties... /> <IdentityMap Match="([^=]+)" Pattern="u:${1}"/> <IdentityMap Match="(.+)" Pattern="dn:${1}"/> </Mechanism> Directory User Management Options Teradata Database provides several alternatives for using a supported directory to manage database users. Integrating a directory into your overall user-management strategy may or may not reduce user administration activities, depending on how you decide to use the Security Administration 209

Chapter 9: Directory Management of Database Users Directory User Management Options directory capabilities. The main advantage to be gained from directory management of users is the centralization of user administration. To access the database, directory users must select the LDAP mechanism at logon. Users are then authenticated by the directory, and can also authorized database privileges based on mapping of directory users to database users, roles, and profiles. Directory users can also be mapped to restrict the IP addresses from which they can log on to the database. Set up the database to enable external authentication of users. For information, see the sections beginning with System Requirements for External Authentication on page 53. Perform any editing of LDAP mechanism properties required to facilitate your directory user management strategy. For information, see the sections on specific LDAP options, and the editing instructions for LDAP properties beginning with LdapServerName on page 162. Perform directory setup required for your directory user management strategy, as shown in this chapter, and Appendixes E, F, G, and I. Directory management of users requires the completion of the following groups of set up tasks: Note: In the event of security problems, you can quickly cut off directory user access by disabling the LDAP mechanism or by setting the dbscontrol or gtwcontrol external authentication flag (depending on which is enabled) to off. Option 1: Authentication Only--No Directory Schema Changes The authentication-only option allows any directory user with a username that matches a username stored in the database to log on to the database and inherit the privileges of the matching database user. This option is most useful when: the benefits gained from mapping directory users to database users, roles, and profiles is not worth the required setup effort. some or all directory users have names that already match usernames in the database and the privileges available to the database users are sufficient for the matching directory users. Advantages Requires no directory configuration tasks No loading of Teradata-related directory schema extensions No new or modified Directory Information Tree elements Limitations Directory users only have the privileges already granted to matching database users. If you grant new privileges to a database user, the matching directory user will automatically have access to them. 210 Security Administration

Chapter 9: Directory Management of Database Users Directory User Management Options Set-up Requirements The authentication-only option requires minimal setup: Verify that the TdgssUserConfigFile.xml for the LDAP mechanism contains the following property values: MechanismEnabled = yes AuthorizationSupported = no Verify that the database contains a username that matches the username of each directory user that you want to be authenticated by the directory. Enable external authentication in the database. For information on how to set up external authentication, see External Authentication on page 52. Verify that the matching database user has LOGON WITH NULL PASSWORD privileges. Option 2: Directory Authorization of Database Users If directory users do not have matching usernames in the database, you can map the directory users to database users, roles, and profiles. Mapping is particularly useful when directory users are new to Teradata Database, because it avoids the need to create a database instance for every user. Instead, you can map directory user groups to database users that have approximately the same database access needs. If the needs of a directory user aren t met by any single database user, you can map to multiple users, or to roles and profiles other than those granted to the database user. Directory users with very limited access needs can be mapped to the system generated pseudouser, EXTUSER, which already has a limited set of defined database privileges. Note: Directory users mapped to one or more Teradata Database roles or profiles--and not mapped to a database user--automatically gain EXTUSER privileges in addition to those privileges acquired from the roles/profiles. Advantages Mapped directory users have the potential for access to a wider variety database privileges than unmapped users. Mapped directory users inherit all the privileges available to the database users to which they are mapped. Mapped directory users have access to any additional privileges associated with other profiles and external roles to which they are mapped. Multiple directory usernames can be mapped to the same database user, role, or profile. A single directory user can be mapped to multiple database users, roles, and profiles. Limitations Mapping requires a complex and time consuming setup process. Security Administration 211

Chapter 9: Directory Management of Database Users Directory User Characteristics Related Topics Once the Teradata schema objects on which mappings are based are installed in Active Directory, you can not remove them, although you can change individual mappings. Other directory types allow removal of schema objects. Set-up Requirements The option to map directory users to Teradata Database users, roles, and profiles requires a significant amount of set-up in the database and the directory. The administrator must: Install the Teradata-related schema extensions in the directory. Create external roles and additional profiles in the database for directory users in cases where no database user to which they could be mapped has the required roles or profiles. Populate the directory schema to map directory users to Teradata Database users, roles, and/or profiles. Unmapped directory users can still log on to the database, but will only have PUBLIC privileges. Verify that the TDGSSUserConfiguration file for the LDAP mechanism on the client machine from which the LDAP logon will take place contains the following: MechanismEnabled = yes (on both the server and the client from which the LDAP logon will take place) AuthorizationSupported= yes Note: If AuthorizationSupported is not set to yes, the system will ignore all mapping information in the directory. Enable external authentication in the database. For information on LDAP logons and directory authentication of users, see LDAP Logons on page 75. For information on checking or editing the MechanismEnabled or AuthorizationSupported properties, see Changing the TDGSS Configuration on page 190. For information on the default database privileges available to directory users, see Characteristics of Unmapped Directory Users on page 213. For information on mapping directory users to Teradata Database users, roles, and profiles, see Mapping Directory Users to Teradata Database Objects on page 269. For information on enabling external authentication, see External Authentication on page 52. Directory User Characteristics Directory users have different characteristics and database privileges depending on whether or not you make changes to the directory schema and map them to Teradata Database users, roles, and profiles. 212 Security Administration

Chapter 9: Directory Management of Database Users Directory User Characteristics Characteristics of Unmapped Directory Users If Authorization is not Supported If the AuthorizationSupported property of the LDAP mechanism is set to no, un-mapped directory users having a username that matches a Teradata Database username: can log on and be authenticated by the directory inherit all the database privileges of the matching database user Directory users whose usernames are not duplicated in the database cannot access the database. If Authorization is Supported If the AuthorizationSupported property of the LDAP mechanism is set to yes, it is usually because at least some directory users are mapped to Teradata Database users, roles, or profiles. Directory users not mapped to a Teradata Database user can be mapped to the systemgenerated pseudo-user EXTUSER, which allows them limited database access privileges. Characteristics of Directory Users Mapped to Permanent Users Mapped directory users function in much the same way as the permanent Teradata Database users to which they are mapped. Note: The AuthorizationSupported property of the LDAP mechanism must be set to yes or the system will ignore all directory mapping information. Directory users mapped to permanent Teradata Database users: Inherit the spool and temp space available to the permanent user, as stored in DBC.Dbase, unless another profile has been assigned. Inherit access privileges, roles, and profile settings from the permanent user. Can be assigned profiles and external roles in addition to those they inherit. The assigned profiles and roles are enabled at logon, and take precedence over those inherited. Must use the SET ROLE statement (within a session) to enable the roles inherited from the permanent users to which they are mapped if other roles have been assigned to that user. You can also map directory users to roles and profiles other than those they inherit from the database users to which they are mapped. Mapped roles and profiles take precedence over the inherited roles and profiles. Security Administration 213

Chapter 9: Directory Management of Database Users Directory User Characteristics Directory users mapped only to the pseudo user, EXTUSER, have the following privileges: No perm space, default database, default role, or profile. Can set the default database using a SET SESSION DATABASE statement, if no default database has been assigned. Has the same default spool and temp space allocations as user DBC, which is created without spool and temp space limitations. However, you can create a profile that sets limits on spool and temp space usage and assign it to a directory user that is mapped to EXTUSER. Has only PUBLIC privileges and therefore can only perform SELECT operations. However, you can create one or more external roles that grant additional database privileges and assign those roles to a directory user that is mapped to EXTUSER. Cannot CREATE or DROP databases, users, roles, or profiles. However, you can create an external role that provides the right to create and drop databases and assign it to a directory user that is mapped to EXTUSER. If a directory user mapped to EXTUSER is subsequently mapped to one or more Teradata Database roles or profiles, the privileges defined by those roles and profiles are added to the privileges inherited from EXTUSER. Ownership of Database Objects Created by Directory Users Directory users can create users and databases if permitted by the privileges granted to users or roles to which they are mapped. However, ownership of these objects follows different rules than those applied to permanent users. Mapped Directory users do not have database identifiers and therefore cannot themselves be owners or creators of database objects. Unmapped directory users with matching database usernames have the same ownership privileges as the matching database users for sessions initiated while the AuthorizationSupported property is set to no. The users and databases created by directory users are registered in DBC.Dbase, with the the permanent user to which they are mapped listed as their owner and creator. Databases can be created by directory users that are not mapped to permanent users. In such cases, databases and database objects such as tables, views, and macros, will be owned by the containing databases. 214 Security Administration

Chapter 9: Directory Management of Database Users Roles and Profiles for Directory Users Roles and Profiles for Directory Users Whether users are managed by the database or the directory, the database administrator must use ANSI-defined DDL statements to CREATE or DROP roles and GRANT them to, or REVOKE them from, database users. Each GRANT may also include a WITH ADMIN option that allows the role grantee to drop the role or grant role to another user or role. Roles for directory-managed users function differently than for database-managed users. Use the keyword prefix EXTERNAL with the CREATE/DROP ROLE syntax to create roles for directory users. Then, instead of GRANTing the role to the directory user, you must assign the role to the user by making changes to the Directory Information Tree. Directory users inherit roles from Teradata Database users to which they are mapped. External roles assigned to a directory user take precedence over any inherited roles. Database Administration of External Roles Use the following statements to create and drop external roles: CREATE EXTERNAL ROLE <rolename> DROP EXTERNAL ROLE <rolename> Note: Dropping an internal database role while including EXTERNAL in the syntax, or dropping an external role without including the EXTERNAL term, results in the following error messages being returned: DROP EXTERNAL ROLE dbrole; Failure 5933: Role being dropped is not an external role DROP ROLE extrole; Failure 5934: Role being dropped is an external role Follow these guidelines when creating and dropping external roles: The user must have been granted CREATE ROLE and DROP ROLE privileges. External roles share the same name space as database roles. External roles cannot include a WITH ADMIN option. An external role cannot be GRANTed--a directory user must be mapped to an external role to use it. A role may be set up in the directory to apply to more than one database server. Directory Administration of External Roles Assign external roles according to the following rules: Although there is no limit on the number of external roles you can assign to a directory user, the system can only handle a maximum of 15. If the number of external roles assigned exceeds 15, it is indeterminate which roles will activate for a particular session. External roles are mapped to security groups. Directory users that are members of a group have access to all the roles assigned to that group. Security Administration 215

Chapter 9: Directory Management of Database Users Roles and Profiles for Directory Users Assigned external roles do not have a corresponding row in DBC.RoleGrants, because the database has no knowledge of the directory users to which they have been assigned. Session Role Hierarchy and Role Switching Permanent database users are restricted to a single default role. They have access to other roles to which they have membership by using the SET ROLE <rolename> or SET ROLE ALL. For a directory user logon, the system automatically enables all assigned external roles. If the directory user has no assigned external roles, the default role granted to its mapped permanent user is enabled. Directory users can also use the SET ROLE <rolename> or SET ROLE ALL requests to enable their mapped permanent user roles in addition to their external roles. After changing the active roles for a session, users can revert back to the initial set of directory-assigned roles by issuing a new request, SET ROLE EXTERNAL. In cases where a directory user is assigned a large number of roles, performance may be enhanced by selecting a single role using the SET ROLE <rolename> request, thus simplifying system of authorizing user privileges. Effects of Drop External Role on Directory User Roles If an external role is dropped, logged-on users to which that role is mapped will immediately cease to have use of the privileges defined in the role. Effects of Changing Directory Role Assignments Once a directory-based session is established, changes in role assignments in the directory will not affect existing sessions. Unlike database role grants and revokes, assigning or un-assigning directory roles does not affect a session in progress. All sessions that log on after a change in role assignments has been made are affected by the change. Profiles for Directory Users Related Topics Mapped directory users inherit the profile assigned to any permanent user to which they are mapped. Additional profiles mapped to the directory user and will take precedence over inherited profiles. Profiles can also be assigned to users that are mapped to EXTUSER. Note: If a directory user is mapped to more than one profile defined on the system specified in the.logon, then include the profile=profilename in the.logdata portion of the logon string to specify which profile to associate with the session. For further information on... Creating external roles See... Database Administration Assigning profiles and external roles to directory users Populating the Directory Information Tree on page 265 216 Security Administration

Chapter 9: Directory Management of Database Users Access Logging of Directory Users Access Logging of Directory Users For the purpose of access logging, directory users are identified and logged by their directorybased identifiers, whether or not they are mapped to any database objects. The identifier is supplied by the Gateway when a session is established and stored in DBC.SessionTbl.AuditTrailId. Configuring a Directory to Manage Database Users A directory user can log on to the database without the need for changes to the directory if the directory username matches a database username, and if the AuthorizationSupported property is set to no on the client from which the logon takes place. For directory users that require more or different privileges than those that can be inherited from a matching database user, you must make changes to the directory to link (map) them to Teradata Database users, roles, and/or profiles. Mapping requires the following changes to the directory: Load Teradata schema extensions into the directory. Populate the directory information tree with objects that link directory users and user groups with database users, roles, and profiles. Read the rest of this chapter to understand the tasks required to configure the directory to link directory users with Teradata Database objects. Then, before you proceed with configuring the directory, you should evaluate your system to see if it will support the re-configuration. For information on the system evaluation tasks to help prepare for configuring the directory integration, see Appendix C: Changing the TDGSS Configuration. Directory Schema Overview All directories contain a schema that defines the objects that can inhabit the directory and what attributes each object must or may contain. The directory checks any new objects you add to it against the schema to ensure that the objects conform to schema rules. Teradata Schema Extensions In addition to the pre-defined schema that is native to each supported directory, Teradata provides schema extensions that must be loaded into the directory to link directory users to Teradata Database users, roles, and profiles. Security Administration 217

Chapter 9: Directory Management of Database Users Directory Schema Overview Teradata Directory Object Classes The Teradata schema extensions add two object classes to the standard directory schema. Required: Must appear in the Directory Information Tree hierarchy. Optional: Need not be present if the function of the object is not used. For further information on where objects appear in the hierarchy, see Teradata Database Objects in the DIT Hierarchy on page 262. Teradata Directory Objects Installing Teradata schema extensions in a supported directory allow for the creation of a number of objects that enable the mapping of directory users to Teradata Database users, roles, and profiles. The following table shows both required and optional Teradata schema objects: Object Type Description Class Supporting Directory tdatrootnode Parent object for all tdatsystem objects; value for cn attribute is up to directory administrator (DA). Required All directories tdatsystem Container/parent object for the Teradata Database system; cn=system name. tdatsystem is the parent object for all tdatcontainer objects. tdatcontainer When cn=users, this object is a container/parent for Teradata Database Users (tdatuser objects). When cn=roles, this object is a container/parent for Teradata Database Roles (tdatrole objects). When cn=profiles, this object is a container/ parent for Teradata Database Profiles (tdatprofile objects). When cn=ipfilters, this object is a container/ parent for Teradata Database IP filters (tdatipfilter objects). Optional tdatuser Describes a Teradata Database user cn=a database user name (including the systemgenerated pseudo-user, EXTUSER). tdatrole Describes a Teradata Database role cn=a database role name tdatprofile Describes a Teradata Database profile cn=a database profile name tdatipfilter Describes a Teradata Database IP filter cn=a unique filter name, such as filter1 218 Security Administration

Chapter 9: Directory Management of Database Users Directory Schema Overview Requirements for Teradata Directory Object Attributes in the Directory Information Tree The Teradata extensions to the directory schema include attributes that Teradata directory objects can or must contain. There are three types of attributes shown in the table that follows: Required: Attributes that must appear in the objects that can contain them. Optional: Attributes that may be required if certain conditions are present. Generated: Attributes automatically generated by Active Directory and ADAM. Users and Administrators have no direct control over the content of this type of attribute. Attribute Name Description Type Directory cn The common name of the particular object of which it is an attribute. Simple text One occurrence required per tdat object. All directories For usage, see Attribute Usage Requirements on page 220. description This attribute provides the administrator a place to enter a description of the containing object, how it is used, or other wording to help place the object within its overall context. It may contain whatever information is useful to the directory administrator. Simple text Optional For usage, see Attribute Usage Requirements on page 220. tdatusermember tdatrolemember FQDN of a directory user that maps to the Teradata Database User named in the cn attribute of the tdatuser object. FQDN of a directory group that maps to the Teradata Database role named in the cn attribute of the tdatrole object. Optional For usage, see Attribute Usage Requirements on page 220. tdatprofilemember FQDN of a directory profile that maps to the Teradata Database profile named in the cn attribute of the tdatprofile object. tdatallowdeny This attribute is a boolean switch. When set to TRUE, this attribute causes the IP filter to be a restrictive filter. When set to FALSE the attribute causes the filter to be a permissive filter. Security Administration 219

Chapter 9: Directory Management of Database Users Directory Schema Overview Attribute Name Description Type Directory tdatallowedip tdatdeniedip These attributes correspond to the allow and deny tags defined in the XML-based IP filter. Optional All directories The attributes contain the IP address and mask defined in the parent ipfilter object. tdatipfiltermember FQDN of a directory profile that maps to the Teradata Database profile named in the cn attribute of the tdatprofile object. tdatipfiltermemberof tdatusermemberof tdatrolememberof tdatprofilememberof The FQDN of an IP filter named in an ipfilters object. FQDN of a Teradata Database user in an Active Directory or ADAM user object. FQDN of a Teradata Database role in an Active Directory or ADAM group object. FQDN of a Teradata Database profile in an Active Directory or ADAM user object. Generated For further information on generated objects and attributes, see Special Objects and Attributes Required for Active Directory and ADAM on page 223. Active Directory and ADAM only Attribute Usage Requirements You must define values for object attributes according to the rules contained in the schema. Note: All objects have an optional description attribute that allows you to enter any plain text description that might help you to clarify the purpose or usage of the object. The following table describes how attributes are to be used for each Teradata directory object class. Object and Usage tdatuser Member TdatRole Member tdatprofile Member tdatipfilter Member Common Name (cn) All Applicable only for some objects. Applicable only for some objects. Applicable only for some objects. Applicable only for some objects. Required. Each instance of each object must have a common name. The common name used in the directory must match the name used in Teradata Database for tdatuser, tdatrole, and tdatprofile. For other objects, the only requirement is that cn be unique among sibling objects. 220 Security Administration

Chapter 9: Directory Management of Database Users Directory Schema Overview Object and Usage tdatuser Member TdatRole Member tdatprofile Member tdatipfilter Member Common Name (cn) tdatrootnode This is the toplevel Teradata Database object. It can be located anywhere in the directory. tdatsystem A Teradata Database system to which directory users can connect. This object is always the child of a tdatrootnode object. tdatcontainer These objects must be children of a tdatsystem object. Not applicable Not applicable Not applicable Not applicable No naming restrictions. Not applicable Not applicable Not applicable Not applicable The name of the Teradata Database system. There are no restrictions on the name. Note: When there is more than one Teradata Database system, it may be advantageous to point all of the systems to the same directory object. That way, when the children of the object (users, roles, or profiles) are altered, all the systems that point to the object will know about it simultaneously. Not applicable Not applicable Not applicable Not applicable There are only four valid tdatcontainer objects: Users Roles Profiles IPFilter Do not create any other containers. tdatuser These objects are children of a tdatcontainer object whose cn value is users. If a directory user is mapped to a Teradata Database user, the FQDN of the directory user must appear in this attribute. Not applicable Not applicable Not applicable The name of a valid Teradata Database user, as it appears in the database. There is no limit to the length of a tdatuser cn, but only the first 30 characters will be recognized by Teradata Database, so they should be unique. Security Administration 221

Chapter 9: Directory Management of Database Users Directory Schema Overview Object and Usage tdatuser Member TdatRole Member tdatprofile Member tdatipfilter Member Common Name (cn) tdatrole These objects are children of a tdatcontainer object whose cn value is roles. Not Applicable If a directory group is mapped to a Teradata Database role, the FQDN of the directory group must appear in this attribute. Not applicable Not applicable The name of a valid Teradata Database role, as it appears in the database. There is no limit to the length of a tdatrole cn, but only the first 30 characters will be recognized by Teradata Database, so they should be unique. tdatprofile These objects are children of a tdatcontainer object whose cn value is profiles. Not applicable Not applicable If a directory user is mapped to a Teradata Database Profile, the FQDN of the directory user must appear in this attribute. Not applicable The name of a valid Teradata Database profile, as it appears in the database. There is no limit to the length of a tdatprofile cn, but only the first 30 characters will be recognized by Teradata Database, so they should be unique. tdatipfilter These objects are children of a tdatcontainer object whose cn value is ipfilters Not applicable Not applicable Not applicable If a directory user is mapped to a Teradata Database IP filter, the FQDN of the database user must appear in this attribute The name of a valid Teradata Database IP filter. 222 Security Administration

Chapter 9: Directory Management of Database Users Directory Schema Overview Special Objects and Attributes Required for Active Directory and ADAM To fully utilize the objects in the Teradata schema extensions, LDAP implementations using Active Directory or ADAM require the configuration of three additional objects, along with associated attributes and values. These objects must appear in the directory, but the directory administrator does not need to do anything to make them function, as the data that goes into them is generated by the directory. The following table shows the special Active Directory/ADAM objects and associated attributes: Attributes Object tdatusermemberof tdatrolememberof tdatprofilememberof tdatipfiltermemberof tdatuserext Optional Not applicable Optional Not applicable tdatgroupext Not applicable Optional Not applicable Not applicable tdatipfilterext Not applicable Not applicable Not applicable Optional The attributes of these special Active Directory/ADAM objects are linked to other attributes common to all directories: This common attribute... tdatusermember tdatrolemember tdatprofilemember tdatipfiltermember Links to this special Active Directory or ADAM attribute... tdatusermemberof tdatrolememberof tdatprofilememberof tdatipfiltermemberof The following example shows how the linked attributes function: When a Teradata Database user is mapped to a directory user through the tdatusermemeber attribute in the tdatuser object, you set the value in the tdatusermember attribute to the FQDN of the directory user. Because the two attributes, tdatusermember and tdatusermemberof are linked, the directory automatically creates a tdatusermemberof attribute in the directory user object that points back to the tdatuser object. The other attributes function in a similar way. Removing attributes also has some automatic consequences: When a tdatusermember attribute is removed from a tdatuser object, the corresponding tdatusermemberof in Active Directory (or ADAM) is automatically removed as well. If the user object is removed from the directory, the corresponding tdatusermember attribute is removed from the corresponding tdatuser object. Security Administration 223

Chapter 9: Directory Management of Database Users System Evaluation System Evaluation Before beginning the complex and time-consuming task of integrating directory users with Teradata Database users, roles, and profiles, you should run some basic checks of the system to determine if it is ready for directory integration. To fully evaluate the readiness of your system for directory integration, you need to do the following: Check the network from both the client and server to ensure that connections are properly made and defined. Query the directory server from the database server to ensure that it can communicate with the directory server and use it to authenticate directory users. Familiarize yourself with the meaning of common error messages that may be returned by the system during system checking, and what you should do if you encounter them. Check the properties of LdapServerName, LdapServerPort, and LdapServerRealm in the LDAP mechanism to make sure that they are set properly for your system. If any of the property values are not correct, you must edit the properties with the correct value. For a description of the LDAP properties you must examine and instructions on how to edit them, see Making Changes to the User Configuration Files on page 195. For detailed information on evaluating your system for directory integration compatibility, see Appendix C: Changing the TDGSS Configuration. Once you have successfully completed these tasks, your system will be ready for directory integration. Optimization of Directory Searches When LDAP authenticates a directory user, it initiates a search of the directory to find the user and determine user qualifications and authorizations. Depending on how the directory is set up, this search may be done inefficiently unless you reconfigure the default LDAP mechanism to optimize the search. If the directory is large, LDAP may make an unnecessarily wide searches to find and authorize users. If the directory is set up to chase referrals, LDAP may initiate several searches of the directory (based on directory-generated referrals) to find a user when only one search is necessary. Teradata Database provides the capability to improve directory search efficiency in the following ways: Add optional properties to the LDAP mechanism and configuring them for optimal directory searching. Configure an <Identity Search>. For information, see Identity Searches on page 205. 224 Security Administration

Chapter 9: Directory Management of Database Users Optimization of Directory Searches Optional LDAP properties are available to perform the following search optimization functions: Property Function Optional LDAP properties for use in narrowing the directory search base when AuthorizationSupported=yes all bind types LdapGroupBaseFQDN LdapUserBaseFQDN The LdapGroupBaseFQDN property contains the fully qualified distinguished name of a directory object that contains the Group objects. When its value is edited to contain an appropriate FQDN, this property narrows the search base of the directory to the children of the parent object that contains the Group in which directory users reside. The LdapUserBaseFQDN property contains the fully qualified distinguished name of a directory object that contains the group of objects in which the users object resides. When its value is edited to contain an appropriate FQDN, this property narrows the search base of the directory to the children of the parent object that contains the Users object. Optional LDAP properties for use in controlling directory referral chasing For all searches and bind types LdapClientDeref LdapClientDebug The LdapClientDeref property contains information that allows LDAP to determine what kinds of referrals to chase. The value of this property can be edited to chase no referrals, a specific type of referrals, or all types of referrals. The LdapClientDebug property instructs LDAP how to help the TSC to debug any problems that may exist between LDAP and the directory. For instructions on the use of these properties how to edit them, see the sections beginning with LdapGroupBaseFQDN on page 167. For instructions on how to add these optional properties to the LDAP mechanism, see Making Changes to the User Configuration Files on page 195. Security Administration 225

Chapter 9: Directory Management of Database Users Optimization of Directory Searches 226 Security Administration

APPENDIX A System Level Security An important part of protecting Teradata Database is to secure access to the system and its surroundings. Maintaining Physical Security Physical security requires controlling access to the physical components of the computer system to avoid the following: Physical damage to the system and its components. Unauthorized access to Administration Workstation (AWS), system console, BAR server, or other sensitive system components. It is outside the scope of this book to describe fire protection and disaster planning, security screening of personnel, plant security, and the structural requirements of a secure (TEMPEST) building. These subjects are not specific to Teradata systems, and information on them can be obtained from government publications. The computer system requires a controlled environment, such as a machine or computer room. A computer room houses processors, disks, consoles, printers, and tape drives. Setting Physical Security Policy At sites where security is a concern, even a minimal security policy should include the following procedure: 1 Restrict access to the computer room to authorized personnel only. Either escort or deny unauthorized personnel access. 2 Maintain a log of all escorted visitors to the computer room. 3 When it is not possible to escort unauthorized personnel to the computer room, take the following precautions: Log off any administrator users in the computer room. Physically power down the entire computer system. 4 When long-term access is required for personnel not involved in normal operations, screen them as if they were joining your operations staff. 5 Review the computer room access list and keep it current. Delete names of personnel who no longer require access. 6 Instruct the operations staff to challenge any strangers encountered in the computer room. 7 Store media that contains sensitive data in a controlled area such as the computer room. Security Administration 227

Appendix A: System Level Security Controlling Access to Dump Files Enforcing Security Policy 8 Remove all sensitive data from all media before removing it from the controlled area or releasing it to unsecured personnel. To effectively enforce the security policy, all operators must be knowledgeable about the current security policy. Controlling Access to Dump Files When the system restarts, it produces a dump file. A database named CRASHDUMPS stores the dump file. The system user DBC owns the CRASHDUMPS database. The system initialization scripts explicitly grant user SYSTEMFE SELECT access to dump data. It is important that you carefully guard the password to user SYSTEMFE, because a dump is the image of physical memory at the time the dump occurred and is therefore highly sensitive data. Controlling Access to the Operating System Restrict access to the operating system to only system administrators with special privileges. Establish operating system and network security controls to secure Teradata Database running on the Teradata server platform. Restrict users without special privileges from accessing the LAN through the operating system to prevent inadvertent corruption of Teradata Database data files. Controlling Access to Outside Devices Enforcement of access control for devices outside the computer room is generally less stringent than for devices located inside the computer room. Administrators of devices that have remote access to the system must always be aware of security and report any suspected unauthorized use of such equipment. Site security policy should include procedures audit security logs for access by outside devices in order to detect any attempted security violations. 228 Security Administration

APPENDIX B Running a Secure Teradata Database This appendix details the requirements for running a secure Teradata Database, as formerly suggested by the National Computer Security Center (NCSC) and now defined by the Common Criteria international standard. Teradata has implemented enhancements to Teradata Database using the guidelines originally provided by the NCSC to create a product that complies with the Trusted Database Interpretation (TDI) at the C2 level. However, Teradata makes no claim that the release of Teradata Database described in this manual has been evaluated at the C2 level nor that this Teradata Database release will comply with the TDI. Some Teradata Databases releases have been evaluated to the Common Criteria International Security Standard ISO/IEC 15408. This standard provides a common set of requirements for the security functions of IT products and systems and for assurance measures applied to them during a security evaluation. The evaluation process establishes a level of confidence that the security functions of such products and systems and the assurance measures applied to them meet these requirements. Securing a System to the Common Criteria Evaluated Configuration This section describes how to secure your system to the equivalent of a Common Criteria evaluated configuration. Common Criteria Level Security Procedure You must implement the following critical steps to operate the system at a level of security equivalent to the Common Criteria evaluated configuration: 1 Establish a system security policy. For suggestions on creating a site-specific security policy, see Formulating Security Policy on page 28. 2 Establish the physical security controls for the system. 3 Establish operating system and network security controls for the Teradata Database server. 4 Install the system hardware and software following Teradata-supplied installation documentation. Be sure to use the documentation that corresponds to the applicable hardware, software, and operating system versions. Security Administration 229

Appendix B: Running a Secure Teradata Database Securing a System to the Common Criteria Evaluated Configuration 5 Make sure to run the DIPACC script (provided on Teradata Database software release media) to allow access logging. This script creates the AccLogRule macro in system user DBC. The software that controls logging only looks for the presence of this macro during its initialization. If you don t run the script to create the macro, and then reset the system, the system will not allow access logging. For instructions on use of the Database Initialization Program (DIP), see Utilities. 6 Change the password control parameters as defined in the DBC.SysSecDefaults table to the recommended default values, using the following SQL statement: UPDATE DBC.SysSecDefaults SET /* password must be at least 8 characters in length */ PasswordMinChar = 8, /* password cannot exceed 30 characters */ PasswordMaxChar = 30, /* digits required in a password */ PasswordDigits = 'r', /* alpha, special characters required in a password */ PasswordSpecChar = 'r', /* user name will be locked after 3 failed logons */ MaxLogonAttempts = 3, /* user name will remain locked for 5 minutes */ LockedUserExpire = 5, /* passwords will expire in 90 days */ ExpirePassword = 90, /* a password cannot be reused for 270 days */ PasswordReuse = 270 /* dictionary words cannot be used in a password */ PasswordRestrictWords = 'Y' WHERE PrimeIndex = 1; For detailed information on the password controls in the DBC.SysSecDefaults table, including their default values, see Password Control Options on page 97. 7 Change the default PASSWORD parameter for usernames DBC, SYSTEMFE, and SYSADMIN (via MODIFY USER), and protect the new passwords in accordance with your security policy. The following example shows the SQL you can use to modify user DBC: MODIFY USER DBC AS PASSWORD = xxx; 8 Chapter 3 User Identification and Authentication contains a recommended process for establishing a user named SECADMIN to carry out the administrative duties required for security. These duties normally include: maintaining the password characteristics maintaining the set of users defined in the system maintaining the set of roles and profiles defined in the system assigning individual users to the defined roles and profiles auditing of access privileges control of logon rules Use the following SQL statement to create user SECADMIN: CREATE USER SECADMIN AS PASSWORD = xxx, PERMANENT = 40E6 BYTES, /* 40M */ 230 Security Administration

Appendix B: Running a Secure Teradata Database Securing a System to the Common Criteria Evaluated Configuration SPOOL = 25E6 BYTES, /* 25M */ ACCOUNT = 'SecAdmin', FALLBACK; Please note that Chapter 3 User Identification and Authentication recommends that you move all PERM space from user DBC to user ADMIN. If you follow that recommendation, then user SECADMIN must use the FROM username option of the CREATE USER statement when creating users. The SQL statements for granting the necessary privileges to user SECADMIN are as follows: /* select on dictionary tables */ GRANT SELECT ON DBC TO SECADMIN; /* manage password controls */ GRANT UPDATE ON DBC.SysSecDefaults TO SECADMIN; /* manage logon rules */ GRANT EXECUTE ON DBC.LogonRule TO SECADMIN; /* maintain users */ GRANT USER ON SECADMIN TO SECADMIN; /* maintain roles */ GRANT ROLE TO SECADMIN; /* maintain profiles */ GRANT PROFILE TO SECADMIN; /* manage access logging */ GRANT EXECUTE ON DBC.AccLogRule TO SECADMIN; /* delete audit entries */ GRANT DELETE ON DBC.AccLogTbl TO SECADMIN; GRANT DELETE ON DBC.DeleteAccessLog TO SECADMIN; /* delete event log */ GRANT DELETE ON DBC.EventLog TO SECADMIN; 9 Restart the system to activate access logging and the revised password controls. 10 Initiate auditing of all attempts to access the security administrator macros, including those accessed by the security administrator, to check for possible attempts to learn or compromise system security measures. Use the following SQL statement: BEGIN LOGGING WITH TEXT ON EACH ALL ON MACRO DBC.LogonRule, MACRO DBC.AccLogRule; 11 Establish any additional security auditing as required by your security policy. 12 Establish any logon rules required by your security policy. 13 Define and implement an analysis and reporting structure for the output of access logging. Security Administration 231

Appendix B: Running a Secure Teradata Database Avoiding Potential Security Hazards Avoiding Potential Security Hazards Take notice of the following warnings to eliminate possible confusion on the part of the security administrator: 1 Use caution when considering whether to include the WITH NULL PASSWORD option in a GRANT LOGON statement. This option splits the function of the Trusted Computing Base (TCB). Although the Teradata Director Program security exit must validate a null password parameter in a particular logon string, Teradata Database itself cannot adhere to the logon policy of username/password verification. 2 Never use the GRANT... WITH GRANT OPTION construct for databases or users. This will help prevent ambiguous structuring of the security network. This construct should be omitted when granting privileges on objects. Although this will require more work for the system or security administrator, it will force the administrative staff to be involved in all GRANT requests by non-owners. 3 Never define SESSION POOLING to the Teradata Director Program. Session pooling offers faster logons, but prevents Teradata Database from identifying and authenticating users without ambiguity. 4 Never alter privileges for user DBC. Doing so may cause installation, upgrade, maintenance, or archive procedures to end abnormally and consequently require TSC support to correct the problem. 232 Security Administration

APPENDIX C Changing the TDGSS Configuration The following sections describe detailed procedures for checking the current TDGSS configuration and then changing the configuration where necessary--that is editing the TdgssUserConfigFile.xml, on Teradata Database nodes and on client machines. The procedures vary by operating system. Using dumpcfg to Check the Current TDGSS Configuration An important part of planning for a TDGSS configuration change is to review the current configuration to see how each mechanism is configured before you begin making changes. Use the dumpcfg utility with the following optional syntax elements to view the current tdgss configuration: dumpcfg [-g TDGSSCONFIG IPFILTER ] [-f <bin file> ] where: -g IPFILTER Reads the ipfilter gdo (server only) -g TDGSSCONFIG Reads the tdgssconfig gdo (server only) -f <bin file> Reads the specified bin file (client only) -? Produces this help message (server and client) Note: Use the -f option only to retrieve IP filter information not stored in GDO format. If no arguments are specified, dumpcfg reads the tdgssconfig gdo. Examples of dumpcfg Input on the Server The following examples show typical output for dumpcfg run on the server: dumpcfg (displays TDGSSCONFIG GDO) dumpcfg -g TDGSSCONFIG (displays TDGSSCONFIG GDO) dumpcfg -g IPFILTER (displays IPFILTER GDO) dumpcfg -f v2r6.0.0.0/etc/tdgssconfig.bin (display old style binary configuration file) Examples of dumpcfg Input on a Client The dumpcfg utility works differently on client systems because the configuration files are not stored as GDOs. Also, the IPFilter cannot be selected because it exists only on the server. Security Administration 233

Appendix C: Changing the TDGSS Configuration Using dumpcfg to Check the Current TDGSS Configuration Example dumpcfg Output The following examples show typical output for dumpcfg run on a client: dumpcfg (displays./tdsgsconfig.bin dumpcfg -f v2r6.0.0.0/etc/tdgssconfig.bin (displays file specified) The following example of dumpcfg output shows only the configuration for the TD1 mechanism. Actual output will show the current configuration for all mechanisms. After you review the configuration, go on to the following sections for detailed instructions on making the configuration change. Note: Some mechanisms are compatible only with Windows. Running dumpcfg from Teradata Database on MP-RAS shows fewer mechanisms than when it runs on Windows. C:\Documents and Settings\ta122382>dumpcfg dumpcfg: Reading TDGSSCONFIG GDO file... Header: Version 2 48 Elements at offset 2c (44) 261 Attributes at offset 710 (1808) 22 Data items at offset f40 (3904) Level 00: TdgssConfigFile (Element 0) Level 01: Header (Element 1) ATTR: "Version"="1" ATTR: "ConfigFileType"="User" Level 01: Mechanisms (Element 2) Level 02: Mechanism (Element 6) ATTR: "Name"="TD1" ATTR: "ObjectId"="1.3.6.1.4.1.191.1.1012.1.1.8" ATTR: "LibraryName"="gssp2td1" ATTR: "Prefix"="TD1" ATTR: "InterfaceType"="teradata" Level 03: MechanismProperties (Element 13) ATTR: "AuthenticationSupported"="no" ATTR: "AuthorizationSupported"="no" ATTR: "SingleSignOnSupported"="no" ATTR: "DefaultMechanism"="no" ATTR: "MechanismEnabled"="yes" ATTR: "MechanismRank"="10" ATTR: "DelegateCredentials"="no" ATTR: "MutualAuthentication"="yes" ATTR: "ReplayDetection"="yes" ATTR: "OutOfSequenceDetection"="yes" ATTR: "ConfidentialityDesired"="yes" ATTR: "IntegrityDesired"="yes" ATTR: "AnonymousAuthentication"="no" ATTR: "DesiredContextTime"="" ATTR: "DesiredCredentialTime"="" ATTR: "CredentialUsage"="0" Level 03: MechQop (Element 14) ATTR: "Value"="0" DATA: "GLOBAL_QOP_0" Level 02: Mechanism (Element 7) ATTR: "Name"="TD2" ATTR: "ObjectId"="1.3.6.1.4.1.191.1.1012.1.1.9" ATTR: "LibraryName"="gssp2td2" 234 Security Administration

Appendix C: Changing the TDGSS Configuration Changing the TDGSS Configuration on SUSE Linux Enterprise Server Nodes ATTR: "Prefix"="TD2" ATTR: "InterfaceType"="teradata" Level 03: MechanismProperties (Element 15) ATTR: "AuthenticationSupported"="no" ATTR: "AuthorizationSupported"="no" ATTR: "SingleSignOnSupported"="no" ATTR: "DefaultMechanism"="yes" ATTR: "MechanismEnabled"="yes" ATTR: "MechanismRank"="20" ATTR: "DelegateCredentials"="no" ATTR: "MutualAuthentication"="yes" ATTR: "ReplayDetection"="yes" ATTR: "OutOfSequenceDetection"="yes" ATTR: "ConfidentialityDesired"="yes" ATTR: "IntegrityDesired"="yes" ATTR: "AnonymousAuthentication"="no" ATTR: "DesiredContextTime"="" ATTR: "DesiredCredentialTime"="" ATTR: "CredentialUsage"="0" ATTR: "VerifyDHKey"="no" ATTR: "DHKeyP"="E4BE0A78F54C4A0B17E7E9249A78BCC08868C17281D8463C880937853E73DD C787E41580A8AFE2594D984C9E0814C590790354ECCD1BE8EA85961E5E0974B32EFE1783 35F061E80189B4BDAA20F67B47" ATTR: "DHKeyG"="05000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000" Level 03: MechQop (Element 16) ATTR: "Value"="0" DATA: "GLOBAL_QOP_1" Changing the TDGSS Configuration on SUSE Linux Enterprise Server Nodes To change the TDGSS configuration on SUSE Linux Enterprise Server, do the following: 1 On the Package Distribution Node (PDN), navigate to the directory that provides access to TdgssUserConfigFile.xml. cd /opt/teradata/tdat/tdgss/site 2 Make a backup copy of tdgssuserconfigurationfile.xml and save it according to your site s standard backup procedures. 3 Open a valid text editor, such as vi and bring up a working copy of the TDGSS User Configuration file. vi TdgssUserConfigFile.xml 4 Edit the properties in the file by deleting the old values and entering new values in accordance with the Editing Guidelines for each property listed earlier in this chapter. Note: Most mechanism properties work best using their factory preset values. Make sure of your reason for wanting to change a property value before edit it. Security Administration 235

Appendix C: Changing the TDGSS Configuration Changing the TDGSS Configuration on MP-RAS Nodes You can add optional properties to the LDAP mechanism and edit their default values. Copy only the optional properties you want to use from the LDAP mechanism in the TdgssLibraryConfigFile.xml and paste them into the LDAP mechanism in the copy of the TdgssUserConfigFile.xml you are editing. 5 Run the tdgssconfig tool to update the TDGSSCONFIG GDO. /opt/teradata/tdgss/bin/run_tdgssconfig 6 Run tpareset to activate the changes to the TDGSS configuration. tpareset -f use updated TDGSSCONFIG GDO Changing the TDGSS Configuration on MP-RAS Nodes To change the TDGSS configuration for Teradata Database on MP-RAS, do the following: 1 On the Package Distribution Node (PDN), navigate to the MP-RAS directory that provides access to the TdgssUserConfigFile.xml. cd /usr/tdgss/site 2 Make a backup copy of TdgssUserConfigurationFile.xml and save it according to your site s standard backup procedures. 3 Open a valid text editor, such as vi, and bring up the working copy of the TDGSS User Configuration file. vi TdgssUserConfigFile.xml 4 Edit the properties in the file by deleting the old values and entering new values in accordance with the Editing Guidelines for each property listed earlier in this chapter. Note: Most mechanism properties work best using their factory preset values. Make sure of your reason for wanting to change a property value before you proceed with the edit. You can also add optional LDAP properties to the LDAP mechanism and edit their default values. To do this you must copy only the optional properties you want to use from the LDAP mechanism in the tdgsslibraryconfigfile.xml and paste them into the LDAP mechanism in the copy of the TDGSS User Configuration file you are editing. For a description of the optional LDAP properties and how to use them to optimize directory searches, see Optimization of Directory Searches on page 224. 5 Run the tdgssconfig tool to update the TDGSSCONFIG GDO. /usr/tdgss/server/bin/run_tdgssconfig 6 Run tpareset to activate the changes to the TDGSS configuration. tpareset -f use updated TDGSSCONFIG GDO 236 Security Administration

Appendix C: Changing the TDGSS Configuration Changing the TDGSS Configuration on Windows Nodes Changing the TDGSS Configuration on Windows Nodes To change the TDGSS configuration on Windows, do the following: Note: Drive letters and file paths may vary from those shown in the procedure below depending on where the Teradata Database software is installed. 1 In a Teradata Command Prompt window on the Package Distribution Node (PDN), navigate to the Windows directory that provides access to the TdgssUserConfigFile.xml. cd c:\program Files\Teradata\TDAT\TDGSS\site Note: The PDN is the lowest number node as defined by the xmppconfig utility. Do not run this process from any other node! For more information about the PDN, see Utilities. 2 Make a backup copy of TdgssUserConfigurationFile.xml and save it according to your standard backup procedures. 3 Open a valid text editor, such as Notepad, and bring up a working copy of the TDGSS User Configuration file. notepad TdgssUserConfigFile.xml 4 (Optional) If you plan to use optional LDAP mechanism properties for referral chasing, bring up a copy of the TDGSS Library Configuration file and copy only the optional properties you want to use into the LDAP mechanism section of the TDGSS User Configuration file, after the LdapBaseFQDN property. notepad TdgssLibraryConfigFile.xml 5 Edit the properties in the file by deleting the old values and entering new values in accordance with the Editing Guidelines for each property listed earlier in this chapter. If you have added optional referral chasing properties to the LDAP mechanism, be sure to determine if they require editing for use on your system and edit their default values. For a description of the optional LDAP properties and how to use them to optimize directory searches, see Optimization of Directory Searches on page 224. Note: Most mechanism properties work best using their factory preset values. Make sure of your reason for wanting to change a property value before you proceed with the edit. 6 Run the tdgssconfig tool to update the TDGSSCONFIG GDO. run_tdgssconfig 7 Run tpareset to activate the changes to the TDGSS configuration. tpareset -f use updated TDGSSCONFIG GDO Security Administration 237

Appendix C: Changing the TDGSS Configuration tdgss Configuration Errors tdgss Configuration Errors If tgdss initialization fails after changing the configuration due to a configuration error, diagnostic messages will be written to the gateway log. The location of the log varies by the operating system on which Teradata Database runs. For Teradata Database on SUSE Linux Enterprise Server and Windows, the gateway log is located in the tdtemp directory. The log file is named GTW_*.log. For Teradata Database on MP-RAS the gateway log is located in /tmp/g[ac]*log. Making TDGSS Configuration Changes on Teradata Clients The basic steps for making TDGSS configuration changes on Teradata clients are very similar to those for servers, but such things as file locations and methods of file replication may differ. Note: Make sure you fully understand the rationales and methods for editing TDGSS mechanism properties before you begin the change process. For basic editing criteria, including the differences between editing the TDGSS User Configuration file on the server and on clients, see Changing the TDGSS Configuration on page 190 and General Rules for Editing on page 192. For a detailed explanation of the editing rationale for each mechanism property, see the sections devoted to mechanism property editing, beginning with AuthenticationSupported on page 145. Changing the TDGSS configuration on Teradata clients requires that you complete the following activities: 1 Make a backup copy of the TdgssUserConfigFile.xml. 2 Edit the copy of the TdgssUserConfigFile.xml and save to a temporary file. 3 Run the tdgssconfig tool to create a new tdgssconfig.bin. 4 Copy the revised TdgssUserConfigFile.xml and tdgssconfig.bin to other clients running Windows that require the same security mechanism property edits. 5 If C/C++ and Java applications are deployed to the same physical client machine, then Java applications must be configured to use the TeraGSS User Configuration File. If you have chosen to use the Jar Update Method to link Java client applications to TDGSS on the client system where TDGSS User Configuration file edits have been made, you must rerun the jar update command so the system will pick up the edits. For more detailed information about the Jar Update method, see Using the Jar Update Command on page 134. 6 The client machine will pick up the configuration changes (including the jar update command) the next time an application logs on and uses the edited mechanism. 238 Security Administration

Appendix C: Changing the TDGSS Configuration Making TDGSS Configuration Changes on Teradata Clients The configuration change process differs among client operating systems. The following examples provide typical step-by-step instructions for changing the tdgss configuration on Windows, SUSE Linux Enterprise Server, and other UNIX systems. However, these procedures for editing mechanism properties on your client stations are for reference only and may vary depending on: the configuration of individual client machines the method you use for distributing software changes among networked clients Note: In several places in the instructions below, an asterisk ( * ) will appear in a file path. This asterisk should be replaced with the appropriate platform name (e.g. nt-i386). Changing the TDGSS Configuration on Windows Clients To change the TDGSS configuration on Windows clients, do the following: Note: Drive letters and file paths may vary from those shown in the procedure below, depending on where the Teradata Database software is installed. 1 Navigate to the Windows directory that provides access to the TdgssUserConfigFile.xml. cd c:\program Files\Teradata\Teradata GSS 2 Make a backup copy of site\tdgssuserconfigfile.xml from the \site directory according to your standard system backup procedures. Do not copy the TDGSS Library Configuration file! 3 Open a valid text editor, such as Notepad and bring up the TDGSS User Configuration file. notepad site\tdgssuserconfigfile.xml 4 Edit the properties in the file by deleting the old values and entering new values in accordance with the Editing Guidelines for each property listed earlier in this chapter. Note: Most mechanism properties work best using their factory preset values. Make sure of your reason for wanting to change a property value before you proceed with the edit. 5 Run the tdgssconfig tool to create a new tdgssconfig.bin file. *\LCLIENT\bin\run_tdgssconfig 6 Distribute the updated copies of the TdgssUserConfigFile.xml and tdgssconfig.bin only to Windows client machines that require the same changes. Substitute them for the existing files in the following locations: For TdgssUserConfigFile.xml: c:\program Files\Teradata\Teradata GSS\site\TdgssUserConfigFile.xml For tdgssconfig.bin: c:\program Files\Teradata\Teradata GSS\*\LCLIENT\etc\tdgssconfig.bin 7 If C/C++ and Java applications are deployed to the same physical client machine where TdgssUserConfigFile edits have been made and you have chosen to use the Jar Update Method to link Java client applications to TDGSS, you must rerun the jar update command so the system will pick up the edits. jar uvf tdgssconfig.jar TdgssUserConfigFile.xml Security Administration 239

Appendix C: Changing the TDGSS Configuration Making TDGSS Configuration Changes on Teradata Clients 8 The client machine will pick up the configuration changes (including the jar update command) the next time a Teradata application logs on after tdgssconfig has been run and uses the edited mechanism. Changing the TDGSS Configuration on Windows.Net Clients Changing the TDGSS configuration on Windows.Net-enabled clients requires additional steps not common to configuration changes on other platforms: use of the tdgssnetconfig tool instead of the tdgssconfig tool intermediate building of the Teradata.Net.Security.TdgssExtensions assembly instead of a.bin file to link the configuration changes to the Windows.Net environment TdgssNetConfig is a simplified version of the Windows.Net Al.exe tool. Use the information in the following table to help determine which tdgssnetconfig options are needed for a particular configuration change. Syntax Element Description Required Options for Changing the TdgssConfigFile.xml /out /schema /xml:<path> Specifies the path to where the Teradata.Net.Security.TdgssExtensions assembly will be written. Specifies the path to the SDKExtensions.xsd file, which is used in the configuration change process. Specifies the path to the TdgssUserConfigFile.xml file, which will be edited during the configuration change process. Other Options /? or /help Displays available TdgssNetConfig options. /delay[sign] [+ -] /keyf[ile]:<filename> /productv[ersion]: <version> /v[ersion] Delay signs this TdgssExtensions assembly. The /delaysign and /keyfile can be used to strongly sign the TdgssExtensions assembly. File containing the key that will sign the assembly. This option is required if the /delaysign option is specified. Version Overrides the TdgssNetConfig version and allows the site to define the product version. If this option is not used, the version will default to the version of the TdgssNetConfig executable. Specifies the version of the Teradata.Net.Security.TdgssExtensions assembly in cases where multiple versions exist. Use * to auto-generate remaining numbers. Sources 240 Security Administration

Appendix C: Changing the TDGSS Configuration Making TDGSS Configuration Changes on Teradata Clients Syntax Element <filename> [,<targetfile>] /embed[resource]: <filename> [,<name>[private]] /link[resource]: <filename> [,<name>[private]] Description Adds the file to the assembly. Embeds the file as a resource in the Teradata.Net.Security.TdgssExtensions assembly. Links the file as a resource to the Teradata.Net.Security.TdgssExtensions assembly. Configuration Change Procedure for Windows.Net Clients Use the following procedure to make changes to the tdgssconfigfile.xml on each affected Windows.Net client: Note: File paths shown in the following procedure are defaults and may vary from the actual paths on your system. 1 Navigate to the Windows directory that provides access to the TdgssUserConfigFile.xml for the Windows.Net environment. Note: This file is separate from the TdgssUserConfigFile.xml contained in the TeraGSS files, which may have existed on the machine before.net Data Provider for Teradata was enabled. cd c:\program Files\Teradata\Net Provider for Teradata\version\config\tdgssUserConfigFile.xml 2 Make a backup copy of tdgssuserconfigfile.xml according to your standard system backup procedures. 3 Open a valid text editor, such as Notepad and bring up the TdgssUserConfigFile.xml. notepad config\tdgssuserconfigfile.xml 4 Edit the properties in the file by deleting the old values and entering new values in accordance with the Editing Guidelines for each property listed in Mechanism Properties on page 144. Note: Most mechanism properties work best using their factory preset values. Make sure of your reason for wanting to change a property value before you proceed with the edit. 5 Save the edited version of the TdgssUserConfigFile.xml to overwrite the pre-edited version. The new (saved) version of TdgssUserConfigFile.xml will be used by the TdgssNetConfig tool in the next step. 6 Run the TdgssNetConfig tool from the /config directory to create a new Teradata.Net.Security.TdgssExtensions assembly file using the following syntax: \TdgssNetConfig /schema:sdkextensions.xsd /xml:tdgssuserconfigf ile.xml /out:teradata.net.security.tdgssextensions.dll Teradata TdgssNetConfig version 12.0.0.99 Output will look something like the following, indicating that the command has executed: Executing command: C:\windows\Microsoft.NET\Framework\V2.0.50727 Security Administration 241

Appendix C: Changing the TDGSS Configuration Making TDGSS Configuration Changes on Teradata Clients \Al.exe /target: library /embed:sdkextensions.xsd / embed:tdgssuserconfigfile.xml /out:teradata.net.security.tdgssextensions.dll / productversion:12.0.0.99 7 The client machine will pick up the configuration changes the next time a Teradata application logs on after TdgssNetConfig has been run, and will use the latest edits. Changing the TDGSS Configuration on Linux Clients To change the TDGSS Configuration on Linux clients, do the following: 1 Navigate to the directory that provides access to TdgssUserConfigFile.xml. cd /opt/teradata 2 Make a backup copy the TdgssUserConfigFile.xml from the teragss/site directory according to your standard system backup procedures. Do not copy the Library Configuration file! 3 Open a valid text editor, such as vi and bring up the TDGSS User Configuration file. vi teragss/site/tdgssuserconfigfile.xml 4 Edit the properties in TdgssUserConfigFile.xml by deleting the old values and entering new values in accordance with the Editing Guidelines for each property listed earlier in this chapter. Note: Most mechanism properties work best using their factory preset values. Make sure of your reason for wanting to change a property value before you proceed with the edit. 5 Run the tdgssconfig tool to create a new tdgssconfig.bin file. teragss/*/client/bin/run_tdgssconfig 6 Distribute the updated copies of the TdgssUserConfigFile.xml and tdgssconfig.bin only to Linux client machines that require the same changes. Substitute them for the existing files in the following locations. For TdgssUserConfigFile.xml: /opt/teradata/teragss/site/tdgssuserconfigfile.xml For tdgssconfig.bin: /opt/teradata/teragss/*/client/etc/tdgssconfig.bin 7 If C/C++ and Java applications are deployed to the same physical client machine where TDGSS User Configuration file edits have been made and you have chosen to use the Jar Update Method to link Java client applications to TDGSS, you must rerun the jar update command so the system will pick up the edits. jar uvf tdgssconfig.jar TdgssUserConfigFile.xml 8 All Teradata applications that log on after tdgssconfig (and jar update, if required) runs will be subject to the new TDGSS configuration. Sessions in progress when the configuration is changed are not affected. 242 Security Administration

Appendix C: Changing the TDGSS Configuration Making TDGSS Configuration Changes on Teradata Clients Changing the TDGSS Configuration on non-linux UNIX Clients To change the TDGSS configuration on non-linux UNIX clients, do the following: 1 Navigate to the UNIX directory that provides access to TdgssUserConfigFile.xml. cd usr/teragss 2 Make a backup copy of TdgssUserConfigFile.xml from the /site directory according to your site backup procedures. Do not copy the Library Configuration file! 3 Open a valid text editor, such as vi and bring up a copy of TdgssUserConfigFile.xml. vi teragss/site/tdgssuserconfigfile.xml 4 Edit the properties in the file by deleting the old values and entering new values in accordance with the Editing Guidelines for each property listed earlier in this chapter. Note: Most mechanism properties work best using their factory preset values. Make sure of your reason for wanting to change a property value before you proceed with the edit. 5 Run the tdgssconfig tool to create a new tdgssconfig.bin file. */client/bin/run_tdgssconfig 6 Distribute the updated copies of the TdgssUserConfigFile.xml and tdgssconfig.bin only to non-linux UNIX client machines that require the same changes. Substitute them for the existing files in the following locations: For TdgssUserConfigFile.xml: usr/teragss/site/tdgssuserconfigfile.xml For tdgssconfig.bin: usr/teragss/*/client/etc/tdgssconfig.bin 7 If C/C++ and Java applications are deployed to the same physical client machine where TdgssUserConfigFile edits have been made and you have chosen to use the Jar Update Method to link Java client applications to TDGSS, you must rerun the jar update command so the system will pick up the edits. For information, see Setting the Java Application Classpath on page 134. jar uvf tdgssconfig.jar TdgssUserConfigFile.xml 8 All Teradata applications that log on after tdgssconfig (and jar update, if required) runs will be subject to the new TDGSS configuration. Sessions in progress when the configuration is changed are not affected. Reversion Procedure If you make a TDGSS configuration change on either a client or server and it does not work the way you had planned, or if for any other reason you want to go back to the original configuration, do the following: 1 Retrieve the backup copy of the TdgssUserConfigFile.xml you made in Step 2 of the Changing the TDGSS Configuration procedure. 2 Use the backup file as is, or change it again. Either way, you must rerun the Changing the TDGSS Configuration procedure to replace the changed configuration with the backup. Note: If you revert to and stay with the original configuration, skip the editing step. Security Administration 243

Appendix C: Changing the TDGSS Configuration Making TDGSS Configuration Changes on Teradata Clients 244 Security Administration

APPENDIX D System Evaluation Tasks for Directory Integration Before beginning the complex and time-consuming task of integrating directory users with Teradata Database users, roles, and profiles, you should run some basic checks of the system to determine that it is ready for directory integration. Evaluation a system involves: Check the network from both the Teradata Client and Teradata Database server to ensure that connections are properly made and defined. Query the directory server from the Teradata Database server to ensure that it can communicate with the directory server and use it to authenticate directory users. Familiarize yourself with the meaning of common error messages that may be returned by the system during system checking. The system evaluation tasks presented in this appendix require use of the ldapsearch and tdsbind tools. For further information on these tools, see tdsbind on page 274 and Running ldapsearch on page 282. Checking the Network Do the following to check the network from both the client and server sides. From a Teradata Client The Teradata Client expects network interfaces to be identified in a very specific way. If the Teradata Database system name is xyz and this system has four network interfaces, the DNS configuration (or hosts file) must bind each interface s IP address to one of the names; xyzcop1, xyzcop2, xyzcop3, and xyzcop4. Example 1 demonstrates a workable addition to the hosts file, while assuming the four IP addresses to be used for network interfaces are 192.168.1.50 through 192.168.1.53. Example 1: Server Configuration in Client Machine s Host File 192.168.1.50 xyzcop1 192.168.1.51 xyzcop2 192.168.1.52 xyzcop3 192.168.1.53 xyzcop4 Note: The KRB5 mechanism has special DNS requirements (not required for LDAP) that you must observe if you plan to use the KRB5 mechanism. These DNS requirements for KRB5 will in no way impact the configuration needed for the LDAP method. If you plan to use both the Security Administration 245

Appendix D: System Evaluation Tasks for Directory Integration Testing the Directory Server KRB5 and LDAP methods, Teradata strongly recommends that you set up the DNS to accommodate KRB5. From Teradata Database Server Nodes The DNS host and domain names of the directory server on each of the nodes that make up the Teradata Database server must be identical to the DNS host and domain name that the directory server sees for itself. Failure to consistently define the directory server in DNS will result in authentication failures on each and every logon attempt with the LDAP method. The nslookup utility for MP-RAS machines and the ping utility for Windows machines may be used to see the DNS names. On every node of the Teradata Database server system, use ping on Windows or nslookup on MP-RAS to see the fully qualified DNS name of the directory server. On the directory server use an appropriate tool to find the DNS name of the directory server itself. The names obtained from the directory server and the Teradata Database server nodes must agree. Since the directory server will in all likelihood exist and since the customer will be using pre-existing directory based applications, any DNS name disagreements should be fixed on each node of the Teradata Database server--that is, the database nodes should be made to agree with the directory server. The way the directory server sees itself must not be changed. Testing the Directory Server The RootDSE Object After you finish checking the network, you can query the directory server to ensure that the Teradata Database server can communicate with the directory server and authenticate directory users. You must run the procedures outlined in this section on all nodes of the Teradata Database server. These procedures are especially important for Teradata Database servers running on MP-RAS, because MP-RAS has no built-in relationship to any type of directory server. On the Teradata Database server, locate the TDGSS bin directory. In this directory, find the ldapsearch tool. Use this tool to perform the necessary basic directory explorations as shown in the following sections. Note: Make sure that the tdgss.bin directory appears somewhere in your PATH environment variable or the scripted examples that follow will not work. All directories contain an object known as the RootDSE. This object has no name and contains information about the particular directory server that allows a user, if authorized, to fully explore that server. The directory server must volunteer this information if asked, without requiring the user to be authenticated. Therefore, this is a good directory object to display, or search, to test the basic communications between the Teradata Database server and the directory server. 246 Security Administration

Appendix D: System Evaluation Tasks for Directory Integration Testing the Directory Server Finding the RootDSE on Active Directory or ADAM Example 2 demonstrates the use of the ldapsearch tool to fetch and display the contents of the RootDSE object from an Active Directory or ADAM directory server. In the example, the phrase...snipped... indicates that content has been removed so that the example fits on a single page. For detailed information on the use of the ldapsearch tool, see Running ldapsearch on page 282. The command appears on the top line of the example. The -h option takes a single argument that identifies the directory server. The -b option takes an argument that identifies the search base. The search base is the name of the directory object where we want to begin our search. Since we need to look for the RootDSE object, and since RootDSE objects are unnamed, we pass a zero length string as the argument. The -s option specifies the scope of the search. The -s option requires an argument that may be one of base, one or sub. The base setting we use in these examples specifies that we want only the object we name as the base of the search. Of particular interest are the values contained in a few attributes in the RootDSE. To meet Teradata s requirements for inter-operability with MP-RAS, the RootDSE object must contain an attribute named supportedldapversion and the attribute must contain a value of 3. Additionally, the RootDSE object must also contain an attribute named supportedsaslmechanisms and the attribute must contain a value of DIGEST-MD5. The most interesting attribute is the dnshostname attribute. This attribute contains a value that is the directory server s fully qualified DNS name. All nodes of the Teradata Database server must resolve the host name of the directory through the system s name resolution/ lookup service in a way that exactly matches the data in this attribute. Example 2: Using ldapsearch to Find the RootDSE in Active Directory or ADAM $ ldapsearch -h esroot -b "" -s base dn: currenttime: 20040820001616.0Z subschemasubentry: CN=Aggregate,CN=Schema,CN=Configuration, DC=esrootdom,DC=esdev,DC=tdat dsservicename: CN=NTDS Settings,CN=ESROOT,CN=Servers, CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=esrootdom, DC=esdev, DC=tdat namingcontexts: DC=esrootdom,DC=esdev,DC=tdat namingcontexts: CN=Configuration,DC=esrootdom,DC=esdev,DC=tdat namingcontexts: CN=Schema,CN=Configuration,DC=esrootdom,DC=esdev, DC=tdat namingcontexts: DC=DomainDnsZones,DC=esrootdom,DC=esdev,DC=tdat namingcontexts: DC=ForestDnsZones,DC=esrootdom,DC=esdev,DC=tdat defaultnamingcontext: DC=esrootdom,DC=esdev,DC=tdat schemanamingcontext: CN=Schema,CN=Configuration,DC=esrootdom,DC=esdev, DC=tdat configurationnamingcontext: CN=Configuration,DC=esrootdom,DC=esdev, DC=tdat rootdomainnamingcontext: DC=esrootdom,DC=esdev,DC=tdat supportedcontrol: 1.2.840.113556.1.4.319...snipped... supportedldapversion: 3 Security Administration 247

Appendix D: System Evaluation Tasks for Directory Integration Testing the Directory Server...snipped... supportedsaslmechanisms: DIGEST-MD5 dnshostname: esroot.esrootdom.esdev.tdat ldapservicename: esrootdom.esdev.tdat:esroot$@esrootdom.esdev.tdat servername: CN=ESROOT,CN=Servers,CN=Default-First-Site-Name,CN=Sites, CN=Configuration,DC=esrootdom,DC=esdev,DC=tdat...snipped... domaincontrollerfunctionality: 2 $ Finding the RootDSE on Sun Java System Directory Server Example 3 demonstrates the use of ldapsearch to obtain the RootDSE from a Sun Java System Directory Server. Note that the only difference between this command and the command in the previous Active Directory example is the name of the directory server. Of note in this object are the same attributes described for the Active Directory RootDSE object. Both the supported SASLMechanisms and supportedldapversion attributes are set appropriately. One interesting detail about the RootDSE object is that the LDAP standard requires it to contain a basic set of attributes. Directory vendors are free to add additional attributes of their own. This is clearly shown in the previous examples. Sun includes a vendorname and vendorversion attribute (among others) while Microsoft includes a larger set of added attributes, such as dnshostname. On the Sun server, the dnshostname attribute is entirely absent. One would have to see the fully qualified DNS name of the directory server on the directory server s machine to know what this DNS name is. Like Active Directory, if the Teradata Database server sees the directory server differently than the directory server sees itself, the database server will never authenticate a user successfully. Example 3: Using ldapsearch to Find the RootDSE in Sun Java Directory Server $ ldapsearch -h djltnt -b "" -s base dn: objectclass: top namingcontexts: dc=elsegundoca,dc=teradata,dc=com namingcontexts: o=netscaperoot supportedextension: 2.16.840.1.113730.3.5.7...snipped... supportedcontrol: 2.16.840.1.113730.3.4.2...snipped... supportedsaslmechanisms: DIGEST-MD5...snipped... supportedldapversion: 3 vendorname: Sun Microsystems, Inc. vendorversion: Sun-ONE-Directory/5.2 dataversion: 020040814221707020040814221707 netscapemdsuffix: cn=ldap:// dc=djltnt,dc=elsegundoca,dc=teradata,dc=com:389 $ 248 Security Administration

Appendix D: System Evaluation Tasks for Directory Integration Testing the Directory Server Authenticating a Real User If a RootDSE object can be obtained on all nodes of the Teradata Database system, you can try to authenticate a real user using ldapsearch. Provided that there are no DNS issues to resolve, this should be a fairly straightforward process. Authenticating an Active Directory or ADAM User Example 4 demonstrates the command to cause the Administrator user on a Windows network to be authenticated with Active Directory or ADAM. For demonstration purposes, the example uses a -u option to name the user. In the example, this command is being run from an MP-RAS system, in an attempt to obtain the RootDSE object as an authenticated user. However, the example input only asks for the namingcontext attribute rather than all attributes as shown in previous examples. If this command was to be run from a Windows machine, a -d option that names the Windows domain where the authentication is to occur may be included in the options. The success of this command indicates that you may proceed to configure TDGSS. If the command fails, there are a variety of failure modes which indicate problems that will need to be resolved before continuing with the TDGSS LDAP configuration. Example 4: Using ldapsearch to Authenticate an Active Directory or ADAM User $ ldapsearch -h esroot -b "" -s base -u administrator namingcontexts Enter LDAP password: dn: namingcontexts: DC=esrootdom,DC=esdev,DC=tdat namingcontexts: CN=Configuration,DC=esrootdom,DC=esdev,DC=tdat namingcontexts: CN=Schema,CN=Configuration,DC=esrootdom,DC=esdev, DC=tdat namingcontexts: DC=DomainDnsZones,DC=esrootdom,DC=esdev,DC=tdat namingcontexts: DC=ForestDnsZones,DC=esrootdom,DC=esdev,DC=tdat $ Authenticating a Sun Java Directory Server User Example 5 demonstrates the command to cause a user to be authenticated against the Sun Java System Directory Server. You may find it beneficial to consult your directory administrator for the proper syntax of user names accepted by your particular installation. In our test environment, the name diperm01@testing is a valid user. Example 5: Using ldapsearch to Authenticate a Sun Java Directory Server User $ ldapsearch -h djltnt -b "" -s base -u diperm01@testing namingcontexts Enter LDAP password: dn: namingcontexts: dc=elsegundoca,dc=teradata,dc=com namingcontexts: o=netscaperoot $ Security Administration 249

Appendix D: System Evaluation Tasks for Directory Integration Common Errors with Active Directory and ADAM Common Errors with Active Directory and ADAM DNS Naming Issue This subsection lists the more common errors a customer may encounter when using ldapsearch or other directory utilities to verify information in Active Directory and ADAM. Example 6 demonstrates the error that occurs when an Active Directory or ADAM server sees itself differently in DNS than the Teradata server. This error may be seen on any node in the Teradata Database server system. To correct this problem, make the DNS configuration on the failing database node yield the fully qualified DNS name of the directory server as seen from the directory server. This can be accomplished by either adding a line in the node s hosts file that provides what looks like the correct fully qualified DNS name for the server or by modifying the actual DNS server and suffix search order on the node. Correcting the problem in the DNS configuration is the preferred remediation. If your Teradata Database node runs on Windows, it will be necessary to either reboot the node after the DNS configuration has been changed or restart the DNS client service if a reboot must be avoided. To restart the DNS client, do the following: 1 Click Start->Settings->Control Panel->Administrative Tools->Services 2 Right click DNS Client 3 Click Restart Once the erroneous name resolution has been corrected, either ping (Windows) or nslookup (MP-RAS) may be used to verify that the Teradata node sees the directory server correctly. If the problem cannot be corrected, it may be necessary to ask your network, DNS or domain administrator for help. Example 6: Error -- Mismatched DIGEST-uri and LDAP SPN $ ldapsearch -u administrator -h esroot -b "" -s base Enter LDAP password: Can t tds_bind: tds_bind: Directory error - Invalid credentials additional info: 80090303: LdapErr: DSID-0C0903FB, comment: The digest-uri does not match any LDAP SPN s registered for this server., data 0, vece $ Server Down: As Seen from Windows Example 7 demonstrates the server down error as seen from a Teradata Database node running on Windows. This error has two possible causes. Either the server name specified in the -h option is not defined, or the server named in the -h option has rejected the attempt to 250 Security Administration

Appendix D: System Evaluation Tasks for Directory Integration Common Errors with Active Directory and ADAM establish a connection. From Windows, these two errors are indistinguishable and one must further probe with a utility like telnet to separate one from the other. In the case of a name lookup failure, ping will respond with the message: Ping request could not find host esroot. Please check the name and try again. If the name is found, the ping request will proceed normally. If an answer is not received from the server, then the server most likely is not alive. If an answer is received from the server, then the directory server is most likely not running. Example 7: Error -- Server Down as Seen from Windows $ ldapsearch -u administrator -h esroot -b "" -s base Enter LDAP password: Can t tds_bind: tds_bind: Directory error - Server Down $ Server Down: As Seen from MP-RAS Example 8 demonstrates the server down error as seen from a Teradata node running on MPRAS. See the preceding section for additional information on isolating the cause of this error. Example 8: Error -- Server Down Seen from MP-RAS $ ldapsearch -u administrator -h esroot -b "" -s base Enter LDAP password: Can t tds_bind: tds_bind: Directory error - Can t contact LDAP server $ Invalid User, Password, or Realm Example 9 demonstrates the effect of a bad directory user name, password or realm name. The remedy is to correct the user name, password or realm and try the request again. Note that the realm name may be specified in the -d option on a Windows machine that uses Active Directory. All other uses of -d are ignored. Example 9: Error -- Invalid User, Password, or Realm $ ldapsearch -u administrator -h esroot -b "" -s base Enter LDAP password: Can t tds_bind: tds_bind: Directory error - Invalid credentials additional info: 8009030C: LdapErr: DSID-0C090419, comment: AcceptSecurityContext error, data 0, vece $ Security Administration 251

Appendix D: System Evaluation Tasks for Directory Integration Common Errors with Sun Java Directory Server Common Errors with Sun Java Directory Server This subsection lists the more common errors a customer may encounter when using ldapsearch or other directory utilities to verify information in Sun Java Directory Server. Server Down Server down errors for Sun Java Directory Server will show up the same way as described for Active Directory. For information on server down errors, see Server Down: As Seen from Windows on page 250 and Server Down: As Seen from MP-RAS on page 251. Bad Canonicalization Example 10 demonstrates an error that occurs when the directory server fails to translate the user name specified in the -u option to a fully qualified distinguished name (FQDN). In the directory is an object located by the FQDN cn=digest-md5,cn=identity mapping,cn=config. The children of this object contain configuration information that assists the directory server in transforming the user name into an FQDN. In order to view the identity mappings, you must search the directory as the directory administrator. The identity mappings found in the directory take one of two forms. The most efficient form is the one that uses pattern matching and substitutions. The other form executes a directory search based on the form of the user name. Example 10: Detecting Bad Canonicalization $ ldapsearch -u diperm01@testing -h djltnt -b "" -s base Enter LDAP password: Can t tds_bind: tds_bind: Directory error - Invalid credentials additional info: SASL(-1): generic failure: unable canonify user and get auxprops $ Example 11 illustrates an identity mapping object that transforms a user name of the form user@realm to an appropriate FQDN. The content of the dsmatching-pattern specifies that the user name obtained from the -u option be transformed to an FQDN. The user name is then matched against the expression contained in the dsmatching-regexp attribute. Substitutions will be made in the substitution pattern contained in dsmappeddn attribute. Then if you run the user name diperm01@testing through this identity mapping rule, the FQDN uid=diperm01,ou=people,ou=testing,dc=elsegundoca,dc=teradata,dc=com. Before designing or changing identity mappings, you should consult the directory and security administrators since these objects represent closely guarded configuration information that could adversely affect other directory users and potentially compromise the directory s security. For further information on identity mappings, please consult the Server Administration Guide for the Sun Java System Directory Server. This guide can be found on the following web site: http://docs.sun.com/app/docs 252 Security Administration

Appendix D: System Evaluation Tasks for Directory Integration Common Errors with Sun Java Directory Server Example 11: Identity Mapping dn: cn=test mapping,cn=digest-md5,cn=identity mapping,cn=config objectclass: top objectclass: nscontainer objectclass: dsidentitymapping objectclass: dspatternmatching cn: test mapping dsmatching-pattern: ${Principal} dsmappeddn: uid=$1,ou=people,ou=$2,dc=elsegundoca,dc=teradata,dc=com dsmatching-regexp: ([ˆ:]*)@(.*) Bad User Example 12 demonstrates the error that occurs when either the identity mapping yields a FQDN that identifies an object that does not exist, or the userpassword attribute in the mapped directory object is missing or contains something other than cleartext data. If the mapped FQDN does not identify an existing object, either the user name was entered incorrectly, or the object does not exist in the directory. If the user name was entered incorrectly, try the command again with a correct user name. If the problem persists, have the directory administrator either create or replace the contents of the userpassword attribute in the mapped object with a cleartext value and retry your command using the new password. Bad Password Example 12: Bad User Error $ ldapsearch -u diperm01@testing -h djltnt -b "" -s base Enter LDAP password: Can t tds_bind: tds_bind: Directory error - Invalid credentials additional info: SASL(-13): user not found: no secret in database $ The SASL (Simple Authentication and Security Layer) DIGEST-MD5 mechanism, used in LDAP authentication, works using a shared secret. The directory server stores this secret in a database. In the case of the Sun server, this secret is stored in a protected attribute in the directory objects that represent users. The LDAP client obtains this shared secret from the user. Under the boards, DIGEST-MD5 on the directory server will issue a challenge to the LDAP client. The client builds a response based on data in the server challenge and the secret obtained from the user and sends that response back to the server. At no time does the password appear in the communications between the client and server. The server also generates a response based on its stored secret. If the client s response to the server s challenge does not match what the server generated as a proper response, this error occurs. Example 13 demonstrates the error that occurs when the user has been successfully mapped to an FQDN that references an existing object in the directory and the password stored in the directory doesn t match what the user specified. To remedy, correct the password on the client or have the directory administrator change the password on the directory server and retry the failed command. Security Administration 253

Appendix D: System Evaluation Tasks for Directory Integration Common Errors with Sun Java Directory Server Example 13: Bad Password Error $ ldapsearch -u diperm01@testing -h djltnt -b "" -s base Enter LDAP password: Can t tds_bind: tds_bind: Directory error - Invalid credentials additional info: SASL(-13): authentication failure: client response doesn t match what we generated $ 254 Security Administration

APPENDIX E Configuring a Directory to Manage Teradata Database Users Directory management of users accessing Teradata Database takes one of two forms. Authentication only: The directory user is authenticated by the directory, but authorized database privileges by the database. Authentication and Authorization: The directory users is authenticated and authorized database privileges by the directory. To enable directory management of users you must do the following to configure the Directory: Install Teradata schema extensions in the directory. Populate the directory information tree with Teradata objects. Map directory users to Teradata Database users, roles, and profiles. For information on the database tasks required for directory authentication and authorization of Teradata Database users, see the following: External authentication must be enabled on Teradata Database to exercise directory management of database users. For information on the setup requirements for external authentication, see External Authentication on page 52. Some LDAP mechanism properties may require editing to implement your directory user management strategy. For information on editing these properties, see the sections beginning with Directory User Authentication Properties on page 162. For background information on directory authentication and authorization of users, see Chapter 9: Directory Management of Database Users. Installing Teradata Schema Extensions in a Supported Directory Before configuring a directory to manage Teradata Database users, you must install Teradata extensions to the directory schema. The schema extensions allow the directory to recognize the Teradata Database-related objects that will be added to the directory information tree. Warning: Teradata schema extensions installed on Active Directory or ADAM, along with associated directory changes, cannot be undone without re-initializing the directory server. Because of this, you should make sure you fully understand the schema extensions, their contents, and the consequences of their use before you install them and begin adding objects and mappings to the Directory Information Tree. Security Administration 255

Appendix E: Configuring a Directory to Manage Teradata Database Users Installing Teradata Schema Extensions in a Supported Directory This is especially important on large replicated directory services. These servers use a built-in replication feature to duplicate schema and the data they contain on all servers in the system. If your system uses this feature, Teradata schema extensions installed on one server will be replicated on all other Active Directory or ADAM servers in the system. These changes cannot be undone without re-initializing all directory servers. Schema Installation Options There are two types of Teradata directory schema extensions contained in the TDGSS files for each supported directory: Schema Type tdat.<dir type>.schema ipfilter.<dir type>.schema Description The base schema This schema extension enables mapping of directory users to Teradata Database users, roles, and profiles. The IP restriction schema This schema extension enables IP access restrictions. Note: You cannot use the ipfilter.<dir type>.schema unless the tdat.<dir type>.schem is also installed. While the installation processes for the two types of schema is nearly identical, you may not need to install all the available schema depending on how you decide to implement directory management of database users at your site. If you do not plan to use a supported directory to manage database users, installation of the schema extensions is unnecessary. If you do plan to use a supported directory to manage database users: For new systems, or existing systems that are just beginning to implement directory management of database users, install both the base and IP restriction schema. For existing systems that have already installed the base schema: Add the IP restriction schema if you plan implement IP restrictions. Installation on Active Directory or ADAM from Teradata Database on Windows You can use the LDIFDE.EXE tool (provided with Active Directory and ADAM) to retrieve the Teradata schema extensions from the server and install them on Active Directory or ADAM. Teradata Database contains two types of schema extensions for use with Active Directory/ ADAM, as follows: Schema Type tdat.actdir.schema Description Use this schema extension to enable mapping directory users to Teradata Database users, roles, and profiles. 256 Security Administration

Appendix E: Configuring a Directory to Manage Teradata Database Users Installing Teradata Schema Extensions in a Supported Directory Schema Type ipfilter.actdir.schema Description Use this schema extension to enable IP-based database access restrictions for directory users. The example LDIFDE syntax in the procedure below makes these assumptions: TDGSS, including the tdat.actdir.schema and ipfilter.actdir.schema files, has already been installed on the Teradata Database server. The directory sever is named k1 The administrator for k1 is doing the installation. The -c argument says to change the string CN=Schema to match the schemanamingcontext of the server. The example shows installation of tdat.actdir.schema,but installation of ipfilter.actdir.schema is similar. Since you cannot remove Teradata schema extensions from Active Directory or ADAM after you ve installed them, don t install the schema unless you plan to use them. Do the following to install the Active Directory or ADAM schema extensions: 1 Using ldapsearch, determine the value to use for the schema naming context. For information on using ldapsearch to determine this value, see Determining the schemanamingcontext Value on page 290. 2 Using LDIFDE.EXE, enter the following syntax for installation of the base schema: C> ldifde -b administrator k1dns * -i -s k1 -c "CN=Schema" "CN=Schema,CN=Configuration,DC=k1dns,DC=systemone,DC=com" -f tdat.actdir.schema Note: If you want to implement access restrictions by IP address, substitute the ipfilter.actdir.schema for the tdat.actdir.schema shown in the -f portion of the example syntax above. The following table explains the LDIFDE syntax: Syntax Element Description -b administrator k1dns * The directory administrator's login. 'administrator' is the user, 'k1dns' is the domain and '*' requests ldifde to prompt securely for the password. -i Import mode. Data will be taken from the file named in -f and be imported into the directory. -s k1 The name of the directory server. -c "CN=Schema""CN=Schema,CN=Configuratio n, DC=k1dns,DC=systemone,DC=com" Changes the CN=Schema to the actual schema Naming Context. Note: Your actual schemanamingcontext may vary. Security Administration 257

Appendix E: Configuring a Directory to Manage Teradata Database Users Installing Teradata Schema Extensions in a Supported Directory Syntax Element -f tdat.actdir.schema or -f ipfilter.actdir.schema Description The file LDIFDE is importing You must import the files individually. 3 Type the password for the administrator login when prompted. 4 You will get a messages that reads approximately like the following: Connecting to K1 Logging in as administrator in domain K1dns using SSPI Importing directory from file tdat.actdir.schema <or ipfilter.actdir.schema > Loading entries xx entries successfully modified 5 If the installation is not successful, one of the following may have happened: The ldifde syntax may not be correct. For a complete set of options, see the Microsoft LDIFDE documentation. The logon used does not allow the administrative privileges required for this activity. Note: If the schema installation produces an error message and the output shows that some of the schema was loaded, do the following: 1 Examine the ldifde command syntax that you submitted, compare it to the example in Step 2, and make any necessary corrections. 2 Add the '-k' option to the ldifde command syntax. The -k option will cause it to ignore any schema that have already been loaded. 3 Rerun the command. Installation on Active Directory or ADAM from Teradata Database on MP- RAS or SUSE Linux Enterprise Server The best way to install Teradata schema extensions from an MP-RAS or SUSE Linux Enterprise Server server into Active Directory or ADAM is to use a script. The TDGSS/.bin directory contains the ldapmodify tool. Use it as follows to install the schema on Active Directory from Teradata Database on MP-RAS or SUSE Linux Enterprise Server: Note: You can use the following example for installations from Teradata Database running on either SUSE Linux Enterprise Server or MP-RAS, except that in Step 7, the SUSE Linux Enterprise Server file path is different from MP-RAS and should read as follows: Example cd /opt/teradata/tdat/tdgss/server/site/etc 1 - #!/bin/sh # # usage: loadschema <server> # # <server> names an Active Directory or ADAM server where schema 258 Security Administration

Appendix E: Configuring a Directory to Manage Teradata Database Users Installing Teradata Schema Extensions in a Supported Directory # is to be loaded. # 2 - if [ $#!= 1 ]; then 3 - echo "Wrong # args" 4 - echo "usage: $0 <server>" 5 - exit 1 6 - fi 7 - cd /usr/tdgss/server/etc 8 - SNC= ldapsearch -h $1 -b "" -s base schemanamingcontext \ 9 - grep -i schemanamingcontext \ 10 - cut -d -f2 11 - if [ "$SNC" = "" ]; then 12 - echo "Schema naming context not found on server $1" 13 - exit 1 14 - fi 15 - cat tdat.actdir.schema ipfilter.actdir.schema \ 16 - sed -e "s/cn=schema/$snc/" \ 17 - ldapmodify -h $1 -Y DIGEST-MD5 -U administrator You can use the script as shown above based on the following assumptions: TDGSS, which includes the tdat.actdir.schema file, has already been installed on the Teradata Database server. The name of the administrator for the directory is administrator. If not, you must edit the script with the name you want to use. Active Directory/ADAM is running on a Windows 2003-based directory server. If you have already installed the base schema and only want to add the IP restriction schema, omit the tdat.actdir.schema from step 15. Do the following to use the script to install schema from Teradata Database running on MP- RAS or SUSE Linux Enterprise Server to Active Directory or ADAM running on system esroot: 1 From the Teradata Database Command prompt, run the Install Script by entering:./loadschema esroot 2 The system returns the following to indicate that the administrator submitting the script is being authenticated, depending on the current setting for the LdapClientMechanism property: SASL/DIGEST-MD5 authentication started Note: If simple binding is employed, the bind runs silently, and does not report the authentication. 3 You will be prompted for your password with the following: Please enter your password: Note: The password you submit must be the correct password for the username shown in the script. 4 If you have submitted the proper password for the username listed in the script, you will see the following message confirming the password is correct for the username: SASL username: administrator SASL SSF: 0 Security Administration 259

Appendix E: Configuring a Directory to Manage Teradata Database Users Installing Teradata Schema Extensions in a Supported Directory 5 The system will then return the following output, showing that the Teradata schema has been installed to the directory: Note: The output shown below is not complete. It has been edited to provide a brief example of what you would see at the completion of schema installation. adding entry "cn=tdatprofilemember,cn=schema,cn=configuration, DC=esrootdom,DC=esdev,DC=tdat" adding entry "cn=tdatprofilememberof,cn=schema,cn=configuration, DC=esrootdom,DC=esdev,DC=tdat"...snipped... adding entry "cn=tdatuser,cn=schema,cn=configuration, DC=esrootdom,DC=esdev,DC=tdat" adding entry "cn=tdatrole,cn=schema,cn=configuration, DC=esrootdom,DC=esdev,DC=tdat" modifying entry "" $ Installation on Sun Java System Directory Server The server contains two types of schema extensions for use with Sun Java System Directory Server, as shown in the following table. Schema Type tdat.sunone.schema ipfilter.sunone.schema Description Use this schema extension to enable mapping of directory users to Teradata Database users, roles, and profiles. Use this schema extension to enable mapping of directory users to IP-based access restrictions. To install the Teradata schema extensions on a directory server running Sun Java System Directory Server, do the following: 1 Retrieve the tdat.sunone.schema or ipfilter.sunone.schema from the Teradata Database server. They are located in the /TDGSS/Site/etc directory. 2 Copy the schema extensions to the directory server schema directory as follows: Copy the tdat.sunone.schema file as 75tdat.ldif Copy the ipfilter.sunone.schema file as 75tdat01.ldif Note: To locate the schema directory, consult the Sun Java System Directory Server Administration Guide. 3 Restart the directory server. 4 Consult the Sun Java System Directory Server Administration Guide to determine whether or not additional directory setup action is required for your site. 260 Security Administration

Appendix E: Configuring a Directory to Manage Teradata Database Users Installing Teradata Schema Extensions in a Supported Directory Installation on Novell edirectory The server contains two types of schema extensions for use with Novell edirectory, as shown in the following table. Schema Type tdat.edir.schema ipfilter.edir.schema Description Use this schema extension to enable mapping of directory users to Teradata Database users, roles, and profiles. Use this schema extension to enable mapping of directory users to IP-based access restrictions. Use the ldapmodify utility, bundled with TDGSS, to install the Teradata schema extensions on a directory server running Novell edirectory. Like Active Directory and ADAM, ediectory uses dynamic schema updates, so the system does not require a restart after installation of the extensions. edirectory also automatically updates all directories in a replicated environment. Note: In most cases, edirectory does not allow simple binding on an unprotected connection. To use TLS protection, enter the following: ldapmodify -x -Z -H ldap://server/ -D binddn -W -f tdat.edir.schema To use SSL protection, enter the following: ldapmodify -x -H ldaps://server/ -D binddn -W -f tdat.edir.schema where: Syntax Element Explanation -x Specifies simple binding. -Z Specifies TLS protection. -H Specifies the ldap server naming convention according to binding type: For TLS protection (requires concurrent use of the -Z option): ldap://server/ For SSL protection (not compatible with concurrent use of the -Z option): ldaps://server/ -D binddn Specifies the DN of a user with administrative privileges on the directory. -W Causes ldapmodify to prompt for the password of the user identified in -D. -f Specifies the name of the schema extension file, in this case, tdat.edir.schema. Note: Standard LDAP tools such as ldapmodify are entirely independent of TDGSS and require no TDGSS configuration changes to operate. Security Administration 261

Appendix E: Configuring a Directory to Manage Teradata Database Users Directory Information Tree Directory Information Tree The directory information tree (DIT) is a structural representation of the hierarchical relationship between objects defined in the directory. Higher level objects are containers for lower-level objects, which are considered children of the objects above them. Before a supported directory can perform authentication and authorization of users wanting to access Teradata Database, you must add the Teradata schema objects into the DIT to fix their place within the hierarchy. Teradata Database Objects in the DIT Hierarchy Teradata Database-related directory objects must be placed in the DIT according to their hierarchical relationship to other directory objects. For specific information on defining and formatting the Teradata directory objects so they will appear at the proper level in the DIT structure, see Populating the Directory Information Tree on page 265. The following figures show a typical directory structure: Figure 3: Typical DIT Structure with Teradata Directory Objects Added Figure 3 shows a typical directory information tree structure, along with the top level objects added by the Teradata Database schema (the three objects at the right of the diagram). Note: The object labeled cn=tdat (the tdatrootnode) may be placed as shown or anywhere else in the hierarchy, whereas all the objects directly below it in the hierarchy must appear where they are shown in Figures 3 and 4. 262 Security Administration

Appendix E: Configuring a Directory to Manage Teradata Database Users Directory Information Tree The following table describes the object hierarchy: Row DN Object Class Description Object Class Defined by Top dc=domain, dc=com dcobject Top-level directory object Standard directory schema Middle ou=people organizationalunit Directory object that contains individual person objects ou=groups organizationalunit Directory object that contains user and database objects Standard directory schema Standard directory schema Middle (continued) cn=tdat tdatrootnode Directory object that defines the Teradata Database Root Node Note: This is a suggested location for the Teradata Database Root Node. However, it can be located anywhere in the directory. Teradata directory schema extensions Bottom uid=bwq person Directory object that defines an individual person uid=jcm person Directory object that defines an individual person cn=dbas groupofnames Directory object that contains a number of database objects Standard directory schema Standard directory schema Standard directory schema cn=administrators groupofnames Directory object that Standard directory schema cn=systemone tdatsystem Directory object that defines a Teradata Database system to which directory users can logon cn=systemtwo tdatsystem Directory object that defines a Teradata Database system to which directory users can logon Teradata directory schema extensions Teradata directory schema extensions Security Administration 263

Appendix E: Configuring a Directory to Manage Teradata Database Users Directory Information Tree Figure 4: Lower-level Teradata Directory Objects in the DIT Hierarchy cn=systemone cn=users cn=profiles cn=roles cn=ipfilters cn=jcm cn=bwq cn=jcmprof cn=bwqprof cn=administrator cn=user cn=ipfilter1 cn=ipfilter2 1100A001 Figure 4 shows the lower-level Teradata directory objects that are children of the cn=systemone object shown in Figure 3. The structure of Figure 3 implies that a secondlevel tree, similar to the one shown in Figure 4, also exists under the systemtwo object. Note: The structure of the sub-trees contained by the tdatrootnode (cn=tdat) is rigid and must be defined exactly as shown. The following table describes the objects in Figure 4: Row DN Object Class Description Object Class Defined by Top cn=systemone tdatsystem A Teradata Database system to which directory users can connect Teradata directory schema extensions Middle cn=users tdatcontainer Teradata directory object that contains individual user objects cn=roles tdatcontainer Teradata directory object that contains individual role objects cn=profiles tdatcontainer Teradata directory object that contains individual profile objects cn=ipfilters tdatcontainer Teradata directory object that contains individual IP filter objects Bottom cn=bwq tdatuser Teradata Database user cn=jcm tdatuser Teradata Database user cn=bqwprofile tdatprofile Teradata Database profile cn=jcmprofile tdatprofile Teradata Database profile 264 Security Administration

Appendix E: Configuring a Directory to Manage Teradata Database Users Populating the Directory Information Tree Row DN Object Class Description Object Class Defined by Bottom cn=administrator tdatrole Teradata Database role Teradata directory cn=user tdatrole Teradata Database role schema extensions cn=filter1 tdatipfilters IP restriction filter cn=filter2 tdatipfilters IP restriction filter Populating the Directory Information Tree tdatrootnode Object tdatsystem Object To link directory users to Teradata Database users, roles, profiles, and IP filters you need to create the related objects in the directory information tree (DIT). Refer to Figures 3 and 4 to understand how the examples shown in this section support the required hierarchical arrangement of Teradata directory objects within the DIT. Note: The structure of the DIT must be exactly as shown in Figures 3 and 4, with the exception of the tdatrootnode, which may be located anywhere in the DIT. The users, profiles, roles, and IP filters shown in the examples below all access an imaginary Teradata Database system called systemone. The examples are in a format called LDIF which is directly consumable as source by tools, such as LDIFDE.EXE (Windows) and the more common ldapadd and ldapmodify tools (UNIX). For information on LDAP tools, see Other LDAP Tools on page 291. The tdatarootnode is the primary Teradata directory object to be defined in the DIT. It contains all other Teradata directory objects. Create the tdatrootnode object by entering the following information in the DIT: Example 1: tdatrootnode dn: cn=tdat,dc=domain,dc=com objectclass: tdatrootnode objectclass: top cn: tdat A tdatsystem object is required for every Teradata Database system directory users will access. Create tdatsystem objects by entering the following information in the DIT. Example 2: tdatsystem dn: cn=systemone,cn=tdat,dc=domain,dc=com objectclass: top objectclass: tdatsystem cn: systemone Security Administration 265

Appendix E: Configuring a Directory to Manage Teradata Database Users Creating Containers and Inserting Objects Creating Containers and Inserting Objects All Teradata directory objects below the level of the tdatsystem object must be held in a tdatcontainer object. You must create tdatcontainer objects for Teradata Database users, roles, profiles, and ipfilters in the directory and then create and insert the individual objects into those containers. Be sure to save the containers and objects you create. Naming Conventions Naming conventions for tdatcontainer objects and the objects they contain are as follows: Object Class tdatcontainer tdatuser, tdatrole, tdatprofile, or tdatipfilter Naming Convention The common name (cn:) for a tdatcontainer object must be one of the following: users roles profiles ipfilters Warning: Only the tdatuser, tdatrole, tdatprofile, and tdatipfilter objects may appear as children of the tdatsystem object. The structure of the DIT starting at the tdatrootnode is controlled entirely by the Teradata schema extensions. Placement of any other objects in this part of the directory may result in inappropriate behavior of the Teradata Database server and may jeopardize the use of future directory related enhancements provided by Teradata. Individual objects that are children of tdatcontainer objects must carry the same name as the parent container. Example: Objects that are children of tdatcontainer (Users) must all indicate cn=users. The tdatcontainer (Users) object must not contain any other kind of objects. Entering Container and Object Information in the Directory Creation of containers and objects involves entering correctly formatted descriptions of them in the directory. The following examples show the syntax for creating containers for users, roles, profiles, and IP filters and inserting individual user, role, profile, and IP filter objects. 266 Security Administration

Appendix E: Configuring a Directory to Manage Teradata Database Users Creating Containers and Inserting Objects Users Example 3a: tdatcontainer (Users) Use the following syntax to construct a users container in the directory to hold individual user objects. dn: cn=users,cn=systemone,cn=tdat,dc=domain,dc=com objectclass: top objectclass: tdatcontainer cn: users Example 3b: tdatuser Use the following syntax to create user objects based on Teradata Database usernames. dn: cn=jcm,cn=users,cn=systemone,cn=tdat,dc=domain,dc=com objectclass: top objectclass: tdatuser cn: jcm Roles Example 4a: tdatcontainer (Roles) Use the following syntax to construct a roles container in the directory to contain tdatrole objects. dn: cn=roles,cn=systemone,cn=tdat,dc=domain,dc=com objectclass: top objectclass: tdatcontainer cn: roles Examples 4b and 4c: tdatrole Use the following syntax to create tdatrole objects based on Teradata Database external role names. dn: cn=adminrole,cn=roles,cn=systemone,cn=tdat,dc=domain,dc=com objectclass: top objectclass: tdatrole cn: adminrole dn: cn=user,cn=roles,cn=systemone,cn=tdat,dc=domain,dc=com objectclass: top objectclass: tdatrole cn: userrole Profiles Example 5a: tdatcontainer (Profiles) Use the following syntax to construct a profiles container in the directory to tdatprofile objects. dn: cn=profiles,cn=systemone,cn=tdat,dc=teradata,dc=com objectclass: top objectclass: tdatcontainer cn: profiles Security Administration 267

Appendix E: Configuring a Directory to Manage Teradata Database Users Creating Containers and Inserting Objects Examples 5b and 5c: tdatprofile Use the following syntax to create tdatprofile objects based on Teradata Database profile names. dn: cn=profileone,cn=profiles,cn=systemone,cn=tdat,dc=domain,dc=com objectclass: top objectclass: tdatprofile cn: profileone dn: cn=profiletwo,cn=profiles,cn=systemone,cn=tdat,dc=domain,dc=com objectclass: top objectclass: tdatprofile cn: profiletwo IP Filters IP filters are used to allow or deny directory user access to Teradata Database from particular IP addresses. There are two types of IP filters, which function as follows: IP Filter Type and Setting Restrictive Set tdatallowdeny to TRUE Permissive Set tdatallowdeny to FALSE Function Denies all IP addresses except those specifically allowed. Processes the tdatallowedip filter first, to determine the IP address or range of addresses that are allowed access. Then processes the tdatdeniedip for any exceptions to the allowed IP addresses. Allows all IP addresses except those specifically denied. Processes the tdatdeniedip filter first, to determine the IP address or range of addresses that are denied access. Then processes the tdatallowedip for any exceptions to the denied IP addresses. Note: Do not implement IP filters without first reading Appendix D: System Evaluation Tasks for Directory Integration. Example 6a: tdatcontainer (IPFilters) Use the following syntax to construct an ipfilters container in the directory to hold tdatipfilter objects. dn: cn=ipfilters,cn=systemone,cn=tdat,dc=teradata,dc=com objectclass: top objectclass: tdatcontainer cn: ipfilters Examples 6b: tdatipfilter (User-specific) Use the following example to construct IP filters that will inhabit the ipfilters container. Observe that the tdatipfiltermember attribute is present in the filter object definition. You can use this attribute to specify individual user names to which the filter will be applied. Note: For information on the rules governing the specification of users with the tdatipfiltermember attribute, see Mapping IPFilters to Database Users on page 271. dn: cn=filter1,cn=ipfilters,cn=systemone,cn=tdat,dc=domain,dc=com 268 Security Administration

Appendix E: Configuring a Directory to Manage Teradata Database Users Mapping Directory Users to Teradata Database Objects objectclass: top objectclass: tdatipfilter tdatallowdeny: TRUE tdatallowedip: 141.206.0.0/16 tdatdeniedip: 141.206.35.0/24 tdatipfiltermember: cn=user17,cn=users,cn=systemone,cn=tdat,dc=domain,dc=com tdatipfiltermember: cn=extuser,cn=users,cn=systemone,cn=tdat,dc=domain,dc=com cn: filter1 dn: cn=filter2,cn=ipfilters,cn=systemone,cn=tdat,dc=domain,dc=com objectclass: top objectclass: tdatipfilter tdatallowdeny: FALSE tdatallowedip: 141.206.35.175/32 tdatdeniedip: 141.206.35.0/24 tdatipfiltermember: cn=user7,cn=users,cn=systemone,cn=tdat,dc=domain,dc=com tdatipfiltermember: cn=user9,cn=users,cn=systemone,cn=tdat,dc=domain,dc=com cn: filter2 Examples 6c: tdatipfilter (All users) The following example shows how to assign an IP filter to all users. dn: cn=filter1,cn=ipfilters,cn=systemone,cn=tdat,dc=domain,dc=com objectclass: top objectclass: tdatipfilter tdatallowdeny: TRUE tdatallowedip: 141.206.0.0/255.255.0.0 tdatdeniedip: 141.206.35.0/255.255.255.0 tdatipfiltermember: cn=users,cn=systemone,cn=tdat,dc=domain,dc=com tdatipfiltermember: cn=users,cn=systemone,cn=tdat,dc=domain,dc=com cn: filter1 Mapping Directory Users to Teradata Database Objects After you have created the containers and objects for all Teradata Database users, roles, profiles, and IP filters that directory users will need, you must map directory users to these objects before they will perform their intended functions. Note: Be sure to save all new directory entries. Mapping Directory Users to Database Users Place the fully qualified distinguished name (FQDN) of the user object the directory user in a tdatusermember attribute of the tdatuser object, as shown in Example 7, based on the following rules: Security Administration 269

Appendix E: Configuring a Directory to Manage Teradata Database Users Mapping Directory Users to Teradata Database Objects Presence of a directory user FQDN in a tdatusermember attribute maps the directory user to the permanent Teradata user named in the tdatuser object cn attribute. Absence of a directory user FQDN in any tdatusermember attribute will default the user to EXTUSER privileges, if the directory user is mapped to a database user, role, or profile. Example 7: Mapped User dn: cn=jcm,cn=users,cn=systemone,cn=tdat,dc=domain,dc=com changetype: modify add: tdatusermember tdatusermember: uid=jcm,ou=people,dc=domain,dc=com Mapping Directory Users to Database External Roles To map a Teradata Database external role to a directory group object, place the FQDN of a group object in a tdatrolemember attribute of a tdatrole object, as shown in Examples 8a and 8b, based on the following rules: Presence of a group object FQDN in a tdatrolemember attribute of a tdatrole object gives the group members access to that role. Absence of a group object FQDN in any tdatrolemember attribute of a tdatrole object means that no directory users can access that role. Examples 8a and 8b: Mapped Roles dn: cn=adminrole,cn=roles,cn=systemone,cn=tdat,dc=domain,dc=com changetype: modify add: tdatrolemember tdatrolemember: cn=dbas,ou=groups,dc=domain,dc=com dn: cn=userrole,cn=roles,cn=systemone,cn=tdat,dc=domain,dc=com changetype: modify add: tdatrolemember tdatrolemember: cn=users,ou=groups,dc=domain,dc=com Mapping Directory Users to Database Profiles To map a Teradata Database profile to a directory user object, place the FQDN of a user object in a tdatprofilemember attribute of a tdatprofile object, as shown in Examples 9a and 9b, based on the following rules: Presence of a user object FQDN in a tdatprofilemember attribute of a tdatprofile object gives the user access to that profile. Absence of a user object FQDN in any tdatprofilemember attribute of a tdatprofile object means that no directory user can access that profile. Examples 9a and 9b: Mapped Profiles dn: cn=profileone,cn=profiles,cn=systemone,cn=tdat,dc=domain,dc=com changetype: modify add: tdatprofilemember tdatprofilemember: uid=jcm,ou=people,dc=domain,dc=com dn: cn=profiletwo,cn=profiles,cn=systemone,cn=tdat,dc=domain,dc=com 270 Security Administration

Appendix E: Configuring a Directory to Manage Teradata Database Users Testing Mapped Directory Users changetype: modify add: tdatprofilemember tdatprofilemember: uid=bwq,ou=people,cn=domain,cn=com Mapping IPFilters to Database Users To impose IP restrictions on a directory user, you must map the IP filter to a database user to which the directory user is already mapped. Mapping requires that you place the FQDN of the database user in a tdatipfiltermember attribute of a tdatipfilter object. Note: You can specify the users effected by a filter (i.e. map them to the filter) as part of creating the filter, as shown in Examples 6b: tdatipfilter (User-specific) on page 268 and Examples 6c: tdatipfilter (All users) on page 269. The mapping shown in the following Example 10 is primarily for adding additional users, and is based on the following rules: Presence of a user FQDN in a tdatipfiltermember attribute of a tdatipfilter object links the user to that filter. Specify the affected users in any of the following ways: A Teradata Database user to which a directory user is mapped, in the form: cn=jcm,cn=users...(one specification per tdatipfiltermember attribute instance) The pseudo-user EXTUSER, using the form: cn=extuser,cn=users... All users, using the form: cn=users... (an individual user is not specified) Absence of a user FQDN in any tdatipfiltermember attribute of a tdatipfilter object means that no directory user is affected by the filter. Example 10: Mapped IPFilters dn: cn=filter1,cn=ipfilters,cn=systemone,cn=tdat,dc=domain,dc=com changetype: modify add: tdatipfiltermember tdatipfiltermember: cn=jcm,cn=users,cn=systemone,cn=tdat,cn=domain,cn=com dn: cn=filter2,cn=ipfilters,cn=systemone,cn=tdat,dc=domain,dc=com changetype: modify add: tdatipfiltermember tdatipfiltermember: cn=bwq,cn=users,cn=systemone,cn=tdat,cn=domain,cn=com Testing Mapped Directory Users Once you ve populated the DIT and mapped directory users to Teradata Database users, roles, profiles and IP filters, you should check the results for accuracy and completeness. You can use one or more of the following methods to check Teradata Database-related directory entries either as a spot check upon completion of directory integration, or later to investigate user problems: Security Administration 271

Appendix E: Configuring a Directory to Manage Teradata Database Users Testing Mapped Directory Users Teradata Tools and Utilities applications: Directory users can log on through an application, such as BTEQ, and verify that their user credentials have been set up correctly in the directory. Tdsbind tool: Use the tdsbind tool to verify whether or not the desired mapping exists between directory users and Teradata Database users, roles, profiles, and IP filters. Ldapsearch tool: Use ldapsearch to examine directory user attributes when investigating the source of user problems. Using BTEQ to Verify Directory User Mapping To test the new directory configuration using BTEQ, set up a script that contains a valid directory logon (may vary according to system configuration). For example:.logmech ldap.logdata authcid=jcm password=secret.logon systemone/.quit The.logmech directive requests the ldap authentication method. The.logdata directive contains the LDAP credential information. This credential area is a space-separated list of property values: authcid=diruser (required) password=password (required) realm=realm user=tdatuser profile=tdatprofile The.logon directive simply directs the connection to the systemone system. For detailed information about acceptable LDAP logon formats and the content of the logon string, see LDAP Logons on page 75. If the directory integration tasks have been done correctly, the logon should be successful. If it is not successful, one of the following may have occurred: One or more of the parameters used for the logon are not in the directory information tree. One or more of the parameters used for the logon have not been mapped to the directory user. The directory failed to authenticate the authcid and password contained in.logdata. The.logdata specified a user and/or profile mapping that the directory user is not authorized to access. The user specified an un-trusted domain in the realm property (Teradata Database server on Windows with Active Directory only). The LDAP portion of the TDGSS configuration on the Teradata Database server is not correct. Common BTEQ Error Messages Indicate Possible Directory 272 Security Administration

Appendix E: Configuring a Directory to Manage Teradata Database Users Testing Mapped Directory Users Problems If you run BTEQ to check for directory integration problems, you may get one or more of the following common errors messages: Error Message Problem Solution CLI error: External authentication failed by gateway. Gateway error: User, account, or password information is invalid. DBS error: User identification is not authorized. DBS error: Profile xxx does not exist. User could not be externally authenticated with the information provided in the logon. User, account, or password is invalid. The most common reason for this problem is that the logon used a Teradata Database user name in the.logon statement. The Teradata Database user to which the directory user is mapped doesn t exist in the database. Mapped Teradata profile (xxx) does not exist. Use tdsbind to determine whether or not the directory user mapping implied in the logon actually exists in the directory. Do not use Teradata Database usernames and passwords in the.logon statement of a directory logon. Do either one of the following: Remap the directory user to a user who does appear in the database, or Create the non-existent user in the database. Use ldapsearch to verify that the profile specified in the logon is present in the directory information tree. If it isn t present, create the profile add it to the DIT. If it is present, it probably still requires proper mapping to the user. Security Administration 273

Appendix E: Configuring a Directory to Manage Teradata Database Users tdsbind tdsbind Tdsbind is a diagnostic tool that allows you to determine the mappings between Teradata Database objects (users, roles, and profiles) and directory users. It performs the same LDAP bind and queries that the LDAP authentication method performs to authenticate directory users. Tdsbind provides users and administrators the capability to examine their Teradata Database user, role, and profile properties defined in the directory. The output of tdsbind displays user properties for both unmapped directory users and those mapped to permanent Teradata Database users. Tdsbind is automatically installed on all Teradata Database servers as part of TDGSS. Running tdsbind You can run tdsbind from the Teradata Database Command Prompt by entering the tdsbind input options in any order. For clarity, the input example that follows shows the options in approximately the order they would appear in.logdata statement of a logon string: tdsbind u user [-w pswd] [-B basedn] [-S sysdn] [-h sys] [-p port] [-d realm] [-s] Note: The tdsbind input is case sensitive. For example, the meaning of -u is completely different than -U. In some cases, [-c] or [-t testdir] may be used in place of [-s] as described in the tdsbind option table below. The following table shows the tdsbind options in alphabetical order and summarizes how to use each one of them. tdsbind Option Description -B The fully qualified distinguished name of the directory object that contains the directory user and group objects. Valid Settings: By default, tdsbind uses the value configured for the LdapBaseFQDN property in the TDGSS LDAP mechanism. -c Including this attribute causes the system to initialize TDGSS as if it was a configured client. This attribute is for future use only, and is not currently valid. You cannot use this option if you use either the -s or -t option. 274 Security Administration

Appendix E: Configuring a Directory to Manage Teradata Database Users tdsbind tdsbind Option Description -D Specifies the type of referrals that will be chased. If this property is omitted, tdsbind uses the value of the LdapClientDeref property from the TDGSS user Configuration file. Valid Settings: never=no referrals are chased searching= finding= always=all referrals are chased. -d The Windows domain used to authenticate the directory user. Use this option only if the Teradata Database server runs on Windows and the directory server application is Active Directory. By default, tdsbind uses the value configured for the LdapServerRealm property in the LDAP mechanism. -G The fully qualified distinguished name of any object in the directory that is the base of a subtree which contains the group objects. If omitted, tdsbind uses the LdapGroupBaseFQDN property of the LDAP method in the TDGSS configuration. If the LdapGroupBaseFQDN property is not set, the value defined in the -B option (otherwise deprecated) is used. -h The DNS name of a system where the LDAP server runs. By default, tdsbind uses the value configured for the LdapServerName property in the TDGSS LDAP mechanism. -I ipadd Specifies the name of the binary file to use for restriction by IP address. If -U is not specified, the bind operation proceeds and arguments are taken from the properties of the user as stored in the directory. If the -U option is specified, the bind operation is skipped and the named user and IP address are tested for validity. -p The port where the LDAP server listens. The value can be a decimal number in the range from 1 to 65535. By default, tdsbind uses the value configured for the LdapServerPort property in the TDGSS LDAP mechanism. -R Specifies whether referral chasing is enabled or disabled. If this property is omitted, tdsbind uses the value of the LdapClientReferrals property from the TDGSS USer Configuration file. Valid Settings: on=referral chasing is enabled. off=referral chasing is disabled. Security Administration 275

Appendix E: Configuring a Directory to Manage Teradata Database Users tdsbind tdsbind Option Description -S The fully qualified distinguished name of the directory object that defines the Teradata Database server. By default, tdsbind uses the value configured for the LdapSystemFQDN property in the LDAP mechanism. -s Including this attribute causes the system to initialize TDGSS as if it was a configured server. This is the default if no TDGSS initializing criteria is defined. By default, tdsbind will use server initialization unless it is reset. You cannot use this option if you use either the -c or -t option. -t Causes the system to initialize TDGSS in a test environment. This argument specifies a directory containing the TDGSS installation. You cannot use this option if you use either the -c or -s option. -U tduser Specifies the Teradata Database username. If this option is provided, the bind process will not take place. When this option is specified, the -I option is required. -u The authentication identifier for the directory user. This option must be specified. There is no default. Valid Settings: A valid directory user authcid -V Specifies the debug flags to be passed to the OpenLDAP client API. This property is only available for use when Teradata Database is running on MP-RAS or SUSE Linux Enterprise Server. If this property is omitted, tdsbind uses the value of the LdapClientDebug property from the TDGSS User Configuration file. Valid Settings: For more information regarding the values that can be set, consult documentation from the following web site: http://www.openldap.org Warning!: This property is allowed as an override to the LdapClientDebug property only for use with tdsbind. Do not use the values available to tdsbind to set the LdapClientDebug property in the TDGSS User Configuration file. Any value other than the default that is set for LdapClientDebug property in the configuration files may cause system malfunction. -w The password for the directory user. By default, tdsbind interactively prompts the user and does a secure read of the submitted password. Valid Settings: A valid password for the user specified in -u 276 Security Administration

Appendix E: Configuring a Directory to Manage Teradata Database Users tdsbind tdsbind Option Description -X The fully qualified distinguished name of any object in the directory that is the base of a subtree which contains the user objects. If this property is omitted, tdsbind uses the value of the LdapUserBaseFQDN property from the TDGSS User Configuration file. If the value of the LdapUserBaseFQDN property has not been set, the value passed in the -B option (otherwise deprecated) is used. Note: This option only has meaning when the directory server is Active Directory and is ignored for all other directories. Output from tdsbind The output of tdsbind in the examples below is based on the information contained in the directory information tree (DIT). The following example is taken from the DIT configuration done in the previous section, Populating the Directory Information Tree on page 265. The output in the examples was generated when tdsbind was run specifying the name of a configured directory user. Example 1: Unmapped Directory User Explanation of Example 1 The following example shows the tdsbind input and output for a typical unmapped directory user: 1 C:\>tdsbind -u drct01 2 Enter LDAP password: 3 LdapBaseFQDN: dc=esrootdom,dc=esdev,dc=tdat 4 LdapSystemFQDN: cn=end2end,cn=tdat,ou=testing,dc=esrootdom,dc=esdev,dc=tdat 5 LdapServerName: esroot 6 LdapServerPort: 389 7 LdapServerRealm: esrootdom 8 FQDN: CN=Directory User 1,CN=Users,DC=esrootdom,DC=esdev,DC=tdat 9 GUID: 9c16f286-f287-0541-92db-14e4d511d915 10 Audit trail ID: ATQLPFBXS4KDQKQMSSLNRJZGV0 11 Profiles: profxu1 12 Roles: extrole01xu1, extrole02xu1, extrole03xu1 The following table describes the meaning of each of the lines in Example 1: Line Number Description tdsbind Input 1 Requests that directory user 'drct01' be authenticated 2 In this example, the -w option was not used and no password was entered. If this happens, the user gets a password prompt, enters the password, and then presses the ENTER key. Security Administration 277

Appendix E: Configuring a Directory to Manage Teradata Database Users tdsbind Line Number Description tdsbind Output 3 By default tdsbind uses the values configured for the corresponding LDAP mechanism property. Any substitute values submitted as part of the tdsbind 4 request (-B, -S, and -h) will take precedence over the default mechanism values. 5 6 The LDAP server port (-p) is set to the default, so this attribute value has not been changed. If this value is set to other than the default, it will override the default. 7 By default tdsbind uses the value configured for the corresponding LDAP mechanism property. Any substitute values submitted as part of the tdsbind request (-d) will take precedence over the default mechanism value. Note: The values of rows 3-7 are output because no values were entered and they reverted to default values. If you want to use other than the default values for any of these rows, you can input alternate values. For further information on allowable LDAP mechanism property values, see LDAP Mechanism on page 141. 8 The directory user's fully qualified distinguished name (FQDN). If the bind operation was successful, the FQDN will appear. If the bind operation was unsuccessful, an error message appears at this point and tdsbind exits 9 The user's globally unique identifier (GUID) for directories that support GUIDs 10 The audit trail identifier. This value is derived from the GUID, and only appears if the directory supports GUIDs. 11 A value for this attribute only appears when the directory user has one or more profiles assigned. 12 A value for this attribute only appears when the directory user has one or more roles assigned. 278 Security Administration

Appendix E: Configuring a Directory to Manage Teradata Database Users tdsbind Example 2: Mapped Directory User Explanation of Example 2 The following example shows tdsbind input and output for a typical mapped directory user: 1 C:\jeff>tdsbind -u diperm01 2 Enter LDAP password: 3 LdapBaseFQDN: dc=esrootdom,dc=esdev,dc=tdat 4 LdapSystemFQDN:cn=end2end,cn=tdat,ou=testing,dc=esrootdom,dc=esdev,d c=tdat 5 LdapServerName: esroot 6 LdapServerPort: 389 7 LdapServerRealm: esrootdom 8 FQDN: CN=Permanent User 1,CN=Users,DC=esrootdom,DC=esdev,DC=tdat 9 GUID: f072ab6c-617a-e743-a098-1ef083e2dfb1 10 Audit trail ID: TBD 11 Profiles: profperm01 12 Roles: extrole01perm01, extrole02perm01, extrole03perm01 13 Users: perm01 For a mapped directory user, lines 1 through 12 have meanings similar to those for the unmapped directory user in Example 1. The only difference is that for a mapped directory user, tdsbind returns line 13. If the directory user maps to a permanent Teradata Database user, the permanent user name appears on line 13. Example 3: Checking IP Access Restrictions If you set up the directory for restricting user access by IP address, you can use tdsbind to check whether the system is actually applying the restrictions to the correct users. The IP restrictions in this example are shown in the XML format to simplify the example. In an actual directory implementation of IP access restrictions, the filters and users shown must be added to the directory as schema objects with properly set tag and attribute values. Suppose the IP access restrictions are as follows: <?xml version="1.0" encoding="utf-8"?> <tdat name="tdat"> <system name="tnt38"> <users tag="allusers"> <user name="drct01"/> <user name="drct02"/> <user name="perm01" tag="tagperm01"/> </users> <ipfilters> <ipfilter name="filter1" type="restrictive"> <allow ip="141.206.36.0/24"/> <allow ip="141.206.35.0/24"/> <deny ip="141.206.35.88/32"/> <appliesto tagref="allusers"/> </ipfilter> </ipfilters> </system> </tdat> Based on the IP restrictions shown above, you can use tdsbind to test user restrictions without binding and see which restrictions apply. Security Administration 279

Appendix E: Configuring a Directory to Manage Teradata Database Users tdsbind The tdsbind input and output that follows identifies applicable restrictions for the IP addresses from which user djl normally logs on: $ tdsbind -U djl -I 141.206.35.87 LdapGroupBaseFQDN: ou=groups,ou=testing,dc=domain,dc=com LdapUserBaseFQDN: ou=people,ou=testing,dc=domain,dc=com LdapSystemFQDN: cn=end2end,cn=tdat,ou=testing,dc=domain,dc=com LdapServerName: esroot LdapServerPort: 389 LdapServerRealm: esrootdom Logon by user <djl> from IP <141.206.35.87> is allowed $ tdsbind -U djl -I 141.206.35.88 LdapGroupBaseFQDN: ou=groups,ou=testing,dc=domain,dc=com LdapUserBaseFQDN: ou=people,ou=testing,dc=domain,dc=com LdapSystemFQDN: cn=end2end,cn=tdat,ou=testing,dc=domain,dc=com LdapServerName: esroot LdapServerPort: 389 LdapServerRealm: esrootdom Logon by user <djl> from IP <141.206.35.88> is not allowed $ tdsbind -U djl -I 141.206.35.89 LdapGroupBaseFQDN: ou=groups,ou=testing,dc=domain,dc=com LdapUserBaseFQDN: ou=people,ou=testing,dc=domain,dc=com LdapSystemFQDN: cn=end2end,cn=tdat,ou=testing,dc=domain,dc=com LdapServerName: esroot LdapServerPort: 389 LdapServerRealm: esrootdom Logon by user <djl> from IP <141.206.35.89> is allowed $ You can also use tdsbind to test an LDAP logon for a particular IP address (with binding). $ tdsbind -u diperm01 -I 141.206.35.88 Enter LDAP password: LdapGroupBaseFQDN: ou=groups,ou=testing,dc=doman,dc=com LdapUserBaseFQDN: ou=people,ou=testing,dc=doman,dc=com LdapSystemFQDN: cn=end2end,cn=tdat,ou=testing,dc=doman,dc=com LdapServerName: esroot LdapServerPort: 389 LdapServerRealm: esrootdom FQDN: CN=diperm01,OU=people,OU=testing,DC=domain,DC=com GUID: 535cbe8b-3bc7-ff4a-a1f1-3c56886b7858 Audit trail ID: AKNOL3CZ1Y55UVIPRHRLIQ01YLA Profiles: profperm01 Roles: extrole01perm01, extrole02perm01, extrole03perm01 Users: perm01 Logon by user <perm01> from IP <141.206.35.88> is not allowed $ 280 Security Administration

Appendix E: Configuring a Directory to Manage Teradata Database Users tdsbind Diagnosing Logon Failure Due to Incorrect Realm Information tdsbind Error Output Directory users may receive the generic error message, SSO logon failed by gateway. This message is often related to entry of (or defaulting to) an invalid directory server realm name. To help diagnose the problem, the security administrator can run the same tdsbind -u input shown in Example 2 above. If the following error message is produced, then the LdapServerRealm property in the TDGSS User Configuration File contains an invalid realm name: tds_bind: Directory error - Invalid Credentials additional info: SASL(-1): generic failure: realm changed: authentication aborted If this error is detected, the administrator may need to edit the value of the LdapServerRealm property, as shown in LdapServerRealm on page 165. Once the value of the LdapServerRealm has been corrected, reboot the server to cause the change to take effect. If you cannot reboot the server, instruct end users to enter the correct realm information as part of logon, as shown in LDAP Logons on page 75. Any error output that occurs will generally happen around line 8. The errors are produced by the ldap client and server and are frequently specific to the server. The LDAP administrator or LDAP documentation relevant to the site's directory installation can, in many cases, help identify the root cause of bind failures. Security Administration 281

Appendix E: Configuring a Directory to Manage Teradata Database Users ldapsearch ldapsearch Running ldapsearch ldapsearch is a standard LDAP tool. It allows an administrator or user to explore the directory assignments for a user to gain an understanding of user privileges and to help resolve questions about failed logon attempts or difficulties with data access. Note: Security settings in the directory may prevent you from accessing the data you want without having first logged in using a legitimate directory user name. You can run ldapsearch from the Teradata Database Command Prompt by entering the following ldapsearch attributes in any order: Syntax for Use of DIGEST-MD5 Binding ldapsearch -Y DIGEST-MD5 U user -w password -s [base one sub}] [ b basedn] [-H ldap://host:port/] [filter] [attr1 [attr2 ]] Syntax for Use of Simple Binding ldapsearch -x D user -w password -s [base one sub}] [ b basedn] [-H ldap://host:port/] [filter] [attr1 [attr2 ]] ldapsearch Options The following provides definitions for the options available when configuring an ldapsearch statement: ldapsearch Attribute Description -x Specifies that the search request should be authenticated using simple binding, if offered by the directory. -D user Passes the user identity when the search is authenticated using a simple bind, that is when -x is specified. -Y DIGEST-MD5 Specifies that the search request should be authenticated using DIGEST- MD5 binding, if offered by the directory. -U user Passes the user identity when the search is authenticated using a DIGEST- MD5 bind, that is when -Y DIGEST-MD5 is specified. -w <password> Specifies the directory user password in the ldapsearch command. -W Specifies that the ldapsearch user be prompted for the password after submittal of the ldapsearch command. -R<Realm> A SASL realm offered by the directory server. Specify only when the directory server offers more than one realm. The rules for setting up the -R option are the same as those for setting up the LdapServerRealm property. For information, see LdapServerRealm on page 165. 282 Security Administration

Appendix E: Configuring a Directory to Manage Teradata Database Users ldapsearch ldapsearch Attribute Description -b -b specifies the FQDN of the of the directory object that will constitute the search base. The search base is the starting point in the directory for the search. If this option is omitted, the configured defaults are used. -s Use this option to specify the scope of the search. The value of this option may be: one: Specifies that the children of the object identified by the search base (-b option) are to be searched. base: Specifies that the object identified by the search base (-b option) is the only target of the search. sub: Specifies that a subtree search (or deep search) is to be performed. A deep search includes object names used for the -b option, and extends throughout the subtree named by the search base. Note: Naming the root node of the entire directory as the search base (the usual default) with a scope of sub will search the entire directory. -H Identifies the URI for the Ldap server, in the form: -H scheme://<server><:port>/ where: <scheme>= one of the following: ldap for normal LDAP, or ldaps for LDAP with SSL protection <server>=the name of the directory server. If omitted, ldapsearch assumes a value of localhost, that is the machine from which the search is run. <port>=the port where the directory server listens. The value can be a decimal number in the range from 1 to 65535. If omitted, ldapsearch uses a value based on the value of <scheme>. If <scheme>=ldap, ldapsearch uses a <port> value of 389. If <scheme>=ldaps, ldapsearch uses a <port> value of 636. -Z Requests that TLS protection be used for the search authentication token exchange. If TLS is not available, an error message is returned, but the search continues. -ZZ Requests that TLS protection be used for the search authentication token exchange. If TLS is not available, an error message is returned, and the search aborts. Security Administration 283

Appendix E: Configuring a Directory to Manage Teradata Database Users ldapsearch ldapsearch Attribute filter attr Description Specifies the filter for the search. This argument is approximately equivalent to an SQL WHERE clause. Filters require use of a unique syntax, in accordance with IETF RFC 2254. For detailed information about search filter syntax, go to: http://www.faqs.org/rfcs/rfc2254.html If you don t specify a filter, the search uses (objectclass=*). Note: Search filters are easily distinguished from attribute names in that all search filters begin with a ( character., which is not legal in an attribute name. The optional attr# arguments list the names of attributes to be returned. If no attributes are defined, the search returns all user defined attributes for each object that matches the search criteria, for most directory types. For some directory servers, such as OpenLDAP, you can use + and * to request all user attributes and all system attributes, respectively. A search always returns the FQDN of the object. Usage Notes for ldapsearch 1 Some supported directory servers make a distinction between operational and user attributes. Common operational attributes include creation and modification times. Servers that draw such distinctions frequently specify special attribute names that mean all user attributes and all operational attributes. Neither Sun Java Directory server, Active Directory, nor ADAM support special attribute names. Other servers may allow the name * to mean all user attributes and + to mean all operational attributes. When using ldapsearch to examine an entire OpenLdap RootDSE object, you must use the following commands: When run from this operating system Use this command Windows ldapsearch -H ldap://<host>:<port>/ -b -s base * MP-RAS and SUSE Linux Enterprise Server ldapsearch -H ldap://<host>:<port>/ -b -s base \* 2 When a system name is specified in a ldapsearch command, the system where the ldapsearch command is run must resolve the DNS name of the directory in the same way the directory server resolves the name. If the Teradata Database server does not resolve it in the same way, directory authentication will not work. 284 Security Administration

Appendix E: Configuring a Directory to Manage Teradata Database Users ldapsearch For example: If directory server dirsvr1 resolves to dirsvr1.teradata.com on the directory server system, the dirsvr1 must also resolve to dirsvr1.teradata.com on the where the ldapsearch is run. Be sure to make the server names resolve in the same way or ldapsearch will not run. Finding User Information with ldapsearch The following is a typical situation in which ldapsearch could be used to search an Active Directory or ADAM directory server: For directory server esroot running Active Directory or ADAM, run ldapsearch to find information about a configured directory user drct01, as follows: Note: The ldapsearch output is returned in standard LDIF format, in accordance with IETF RFC 2849. For further information on the LDIF format, go to: http://www.faqs.org/rfcs/rfc2849.html Step 1: Obtain the defaultnamingcontext You must first determine the defaultnamingcontext to understand the location of the Users container that contains user drct01. The defaultnamingcontext is found in the RootDSE object. Search Input To find the defaultnamingcontext, do the following search: C> ldapsearch -x -b "" -s base -H ldap://k1/ defaultnamingcontext Search Output The following information is returned: dn: defaultnamingcontext: DC=esrootdom,DC=esdev,DC=tdat Explanation of defaultnamingcontext Search The following table describes the meaning of each of the lines in Example 1: Search Criteria Description ldapsearch Input -b Specifies a search base (-b) of and a scope (-s) of base -s base obtains the ROOTDSE object. -H ldap://<host>:<port>/ Identifies the URI for the Ldap server. For details, see Running ldapsearch on page 282. defaultnamingcontext Specifies an attribute name limits the search. If you don t specify any attribute names, the search will return values for all available attributes. ldapsearch Output Security Administration 285

Appendix E: Configuring a Directory to Manage Teradata Database Users ldapsearch Search Criteria dn: defaultnamingcontext: DC=esrootdom, DC=esdev, DC=tdat Description The FQDN of the object. Since the search base was and the scope was base, this returns the ROOTDSE object, whose name is a zero length string. The actual value contained in the schemanamingcontext attribute Step 2: Search for User drct01 You must search the Directory users container to find user drct01. Search Input To find user drct01, do the following search: C> ldapsearch -H ldap://<server>:<port>/ -Y DIGEST-MD5 -U drct01 -b "CN=Users,DC=esrootdom,DC=esdev,DC=tdat" -s one "(samaccountname=drct01)" Search Output The following information on user drct01 is returned: Password: dn: CN=John Doe,CN=Users,DC=esrootdom,DC=esdev,DC=tdat objectclass: top objectclass: person objectclass: organizationalperson objectclass: user cn: John Doe sn: Doe givenname: John distinguishedname: CN=John Doe,CN=Users,DC=esrootdom,DC=esdev,DC=tdat instancetype: 4 whencreated: 20040605220928.0Z whenchanged: 20040728221734.0Z displayname: Directory User 1 usncreated: 50268 memberof: CN=xu1,OU=groups,OU=testing,DC=esrootdom,DC=esdev,DC=tdat usnchanged: 315083 name: Directory User 1 objectguid:?=å=çaæ S++ useraccountcontrol: 512 badpwdcount: 0 codepage: 0 countrycode: 0 badpasswordtime: 127337313454062500 lastlogoff: 0 lastlogon: 127355266545781250 pwdlastset: 127309469682812500 primarygroupid: 513 objectsid:? accountexpires: 9223372036854775807 logoncount: 140 samaccountname: drct01 286 Security Administration

Appendix E: Configuring a Directory to Manage Teradata Database Users ldapsearch samaccounttype: 805306368 userprincipalname: drct01@esrootdom.esdev.tdat objectcategory: CN=Person,CN=Schema,CN=Configuration,DC=esrootdom,DC=esdev,DC=tdat lastlogontimestamp: 127355266545781250 tdatprofilememberof: CN=profxu1,CN=profiles,CN=end2end,CN=tdat,OU=testing,DC=esrootdom,DC=esd ev,dc=tdat C> Explanation Search for User drct01 The following table describes the meaning of each of the lines in Example 1: Search Criteria Description ldapsearch Input -H ldap://<server>:<port>/ Identifies the URI for the Ldap server. For details, see Running ldapsearch on page 282. -U drct01 Names the user being authenticated in the search. -b "CN=Users,DC=esrootdom,DC= esdev,dc=tdat" Identifies the search base. In the example shown, the Users container appears in the default naming context. User drct01 and all Active Directory users are all children of this container. -s one Requests that only children of the object named in the -b option be searched. "(samaccountname=drct01)" The search filter. Limits the search to the object where the samaccountname attribute contains "drct01. ldapsearch Output Password: dn: CN=John DoeCN=Users,DC=esrootdom,D C=esdev,DC=tdat Prompt for the directory password for the user named in the -u option. The distinguished name of the user "drct01". This object was returned as a result of the search filter, not the bind of user drct01. Security Administration 287

Appendix E: Configuring a Directory to Manage Teradata Database Users ldapsearch Search Criteria objectclass: top objectclass: person Description These are common directory entries, shown for reference, that may or may not appear in your directory. objectclass: organizationalperson objectclass: user cn: John Doe sn: Doe givenname: John distinguishedname: CN=John Doe,CN=Users,DC=esrootdom, DC=esdev,DC=tdat instancetype: 4 whencreated: 20040605220928.0Z whenchanged: 20040728221734.0Z displayname: Directory User 1 usncreated: 50268 memberof: CN=xu1,OU=groups,OU=testin g,dc=esrootdom,dc=esdev,dc =tdat Lists the groups in which the user has membership. One can use the data contained in this attribute to search the group for roles the user is permitted to assume. The user may assume any role that appears in a tdatrolememberof attribute in the group object identified by the data in this attribute. The tdatrolememberof attribute in the group object is specific to Active Directory. 288 Security Administration

Appendix E: Configuring a Directory to Manage Teradata Database Users ldapsearch Search Criteria usnchanged: 315083 name: Directory User 1 Description These are common directory entries, shown for reference, that may or may not appear in your directory. objectguid:?=å=çaæ S++ useraccountcontrol: 512 badpwdcount: 0 codepage: 0 countrycode: 0 badpasswordtime: 127337313454062500 lastlogoff: 0 lastlogon: 127355266545781250 pwdlastset: 127309469682812500 primarygroupid: 513 objectsid:? accountexpires: 9223372036854775807 logoncount: 140 samaccountname: drct01 samaccounttype: 805306368 userprincipalname: drct01@esrootdom.esdev.tda t objectcategory: CN=Person,CN=Schema,CN=Con figuration,dc=esrootdom,dc =esdev,dc=tdat lastlogontimestamp: 127355266545781250 tdatprofilememberof: CN=profxu1,CN=profiles,CN= end2end,cn=tdat,ou=testing,dc=esrootdom,dc=esdev,dc= tdat Directly locates the Teradata Database profile objects that describe the user's permitted profiles. This attribute only appears in Active Directory. If a directory user is mapped to a Teradata user, a row containing tdatusermemberof attribute will also show up. This attribute points to the tdatuser object that defines the Teradata Database user to which the directory user is mapped. This attribute only appears in Active Directory. Security Administration 289

Appendix E: Configuring a Directory to Manage Teradata Database Users ldapsearch Determining the schemanamingcontext Value When installing Teradata directory schema extensions on Active Directory or ADAM, you must first determine the value to use for the schemanamingcontext. For an explanation of where the schemanamingcontext is used, see Installation on Active Directory or ADAM from Teradata Database on Windows on page 256. Search Input To find the schemanamingcontext, do the following search: C> ldapsearch -b "" -s base -H ldap://k1/ schemanamingcontext Search Output The following information is returned: dn: schemanamingcontext: CN=Schema,CN=Configuration,DC=k1dns,DC=systemone,DC=com" C> Explanation of Search for a schemanamingcontext Value The following table describes the meaning of each item in the search input and output: Search Criteria Description ldapsearch Input -b Specifying a search base (-b) of and a scope (-s) of base -s base obtains the ROOTDSE object. -H ldap://<host>:<port>/ K1 The URI of the directory server. schemanamingcontext A specified attribute name. If you don t specify any attribute names, the search will return values for all available attributes. ldapsearch Output dn:schemanamingcontext schemanamingcontext CN=Schema, CN=Configuration,DC=k1dns, DC=k1dns,DC=systemone, DC=com Indicates that the output is the distinguished name of the schema naming context. The value that the schemanamingcontext attribute contains. 290 Security Administration

Appendix E: Configuring a Directory to Manage Teradata Database Users ldapsearch Other LDAP Tools In addition to tdsbind and ldapsearch, a number of other LDAP tools are included for your convenience when you install TDGSS, which may be useful when configuring a directory for use with Teradata Database or for general directory maintenance. Unlike some of the tools already discussed in this section, these tools were not developed by Teradata, but have been built for use with Teradata Database from commonly available directory tools. The TDGSS versions of these tools are OpenLdap-compliant, and may differ slightly from tools with similar names supplied with your LDAP-compliant directory. You can find the LDAP tools in the following location: usr/tdgss/pkgs/06e.00.00.00/bin/[toolname] LDAP Tool ldapcompare ldapdelete ldapmodify ldapmodrdn ldappasswd ldapsearch ldapwhoami Description Compares two pieces of data in the directory and returns a true/false assessment of their equivalency. Removes data from the directory. Adds new objects and modifies existing objects in the directory. Renames objects in the directory. Changes directory passwords. Note: This tool does not work with currently supported LDAPcompliant directories, but is supplied for future use. Finds objects in the directory. Binds to the directory and discovers a user directory identity. usr/tdgss/pkgs/12.00.00.00/doc/man1/[toolname] Because these are industry standard tools, this manual does not document how to use them. Documentation is in the form of help files that are provided as part of TDGSS. You can find the LDAP tool documentation in the following location: The following table lists the available LDAP tools and describes how they can be used: The help files cover only basic tool usage. For additional information on OpenLdap directory tools, go to the OpenLdap web site at: http://www.openldap.org A Directory Tool For Windows Systems You can also use the LDIFDE tool supplied with Windows for directory maintenance on Windows systems. Security Administration 291

Appendix E: Configuring a Directory to Manage Teradata Database Users ldapsearch 292 Security Administration

APPENDIX F Setting Up SSL/TLS Options This appendix presents the requirements and setup procedures required for use of SSL/TLS options. For information on the rationale for using SSL/TLS protection, see SSL/TLS Protection for Systems Using Simple Binds on page 62. Requirements Supported Versions SSL/TLS options apply only for logons to Teradata Database using the LDAP mechanism. The directory should be pre-configured to support authentication of Teradata Database users, as described in Chapter 9: Directory Management of Database Users, and Appendix F: Setting Up SSL/TLS Options, before attempting to add SSL/TLS options. The following versions are required to support all levels of SSL/TLS protection. TDGSS Versions Support for SSL/TLS requires the following TDGSS minimum versions: V2R6.2.2.13 Release 12.0.0.10 Release 12.0.1.1 Release 13.0.0.0 TeraGSS Versions for Query Director Support for SSL/TLS requires the following TeraGSS minimum versions: 12.0.0.10 13.0.0.0 TeraGSS Versions for Teradata Database Nodes and Clients SSL/TLS functions are not dependent on TeraGSS on either Teradata Database nodes or Teradata clients. However, database nodes and clients must contain some version of TeraGSS. Security Administration 293

Appendix F: Setting Up SSL/TLS Options Configuring Basic SSL/TLS Functions Installation of OpenSSL OpenSSL 0.9.8g or above provides additional utilities that may be useful in the setup of advanced SSL/TLS options. Separate installation of the OpenSSL package may be required depending on the operating system on which Teradata Database runs. For operating systems that do require a separate installation, you can install openssl on a single machine and used to manage certificates from there. Or OpenSSL can be installed on each Teradata Database node, and on the Query Director, if used. OpenSSL on SUSE Linux Enterprise Server OpenSSL is a standard part of SUSE Linux Enterprise Server installations. However, if OpenSSL is not currently installed on the machine from which you want to run an openssl command, you can install it from the SUSE Linux Enterprise Server distribution media. OpenSSL on MP-RAS If you need to use the openssl command on MP-RAS, download the package from the download center and install it on each machine from which you plan to run the openssl utility. OpenSSL on Windows An OpenSSL package exists for Windows that runs in the CygWin environment. You can download and install enough of CygWin so that OpenSSL will install and run. Basic SSL/TLS Support Required to Support Advanced Options You must configure the basic SSL/TLS functions before configuring any of the advanced functions. For instructions, see Configuring Basic SSL/TLS Functions on page 294. Configuring Basic SSL/TLS Functions Basic SSL/TLS protection encrypts the directory user ID and password during a bind to the LDAP directory, to prevent man-in-the-middle attacks and other security threats. The default DIGEST-MD5 binding scheme does not require this protection. SSL/TLS functions are normally employed if site security policy requires its use. For a detailed discussion of the rationale for use of SSL/TLS protection, see SSL/TLS Protection for Systems Using Simple Binds on page 62. Note: SSL and TLS provide similar functionality and it is not necessary to employ them both, but they can both be active simultaneously on the same system. In many instances, the use of SSL or TLS is determined by pre-existing site security policy. Use the procedure shown in Attachment C: Changing the TDGSS Configuration, to add the Ldap SSL/TLS properties to the TdgssUserConfigFile.xml and specify the required values. Make sure to follow all other configuration procedures required for directory authentication, as shown in Appendix F Setting Up SSL/TLS Options. 294 Security Administration

Appendix F: Setting Up SSL/TLS Options Preparing to Configure Advanced Options SSL Protection To activate SSL protection requires that the Ldap mechanism listen on port 636. Reset the LdapServerName property using an ldaps prefix as follows to specify port 636: <Mechanism Name="ldap"> <MechanismProperties LdapServerName="ldaps://myserver/"... /> </Mechanism> Note: Do not reset the LdapServerPort property to 636. The LdapServerPort property is deprecated and should not be used. TLS Protection To activate TLS protection, do the following: Set the LdapClientUseTls property to yes Set the LdapServerName property using an ldap prefix, as follows: <Mechanism Name="ldap"> <MechanismProperties LdapServerName="ldap://myserver/".. LdapClientUseTls="yes" /> </Mechanism> Preparing to Configure Advanced Options In addition to basic protection of logon information, SSL/TLS also offers the following advanced options. Authentication of the directory server by Teradata Database. Authentication of the Teradata Database nodes by the directory server. This option is normally used only when mutual authentication is required by site security policy, and not by itself. Configuration of advanced SSL/TLS authentication options requires initial preparation of the system to meet the conditions shown in the following sections. Security Administration 295

Appendix F: Setting Up SSL/TLS Options Preparing to Configure Advanced Options Directory Server Certificate Requirements Use of the advanced SSL/TLS options requires the presence of one or more security certificates on the directory server. Consult the directory manufacturer documentation for the details of certificate installation. Certificate installation is outside the scope of this procedure and is potentially different for each directory type. Note: LDAP supports only PEM formatted certificates. A certificate offered by the directory server must include the fully qualified DNS name of the directory server as a value for its subject's CN attribute. This requirement is enforced by OpenSSL and OpenLDAP. If the directory server certificate does not conform to this requirement it will not be usable by TDGSS and TeraGSS. To examine the certificate and make sure that it conforms, use the following command: openssl s_client -connect <server-name:port> </dev/null where: server-name is the directory server DNS name port is the port where ssl is listening, usually 636 This command produces output similar to the following example. Example: Typical Directory Server Certificate dlopldap:/etc/openldap/ssl/certs # openssl s_client -connect localhost:636 </dev/null CONNECTED(00000003) depth=0 /C=US/CN=dlopldap.td.teradata.com/ emailaddress=dl160010@teradata.com verify error:num=18:self signed certificate verify return:1 depth=0 /C=US/CN=dlopldap.td.teradata.com/ emailaddress=dl160010@teradata.com verify return:1 --- Certificate chain 0 s:/c=us/cn=dlopldap.td.teradata.com/ emailaddress=dl160010@teradata.com i:/c=us/cn=dlopldap.td.teradata.com/ emailaddress=dl160010@teradata.com --- Server certificate -----BEGIN CERTIFICATE----- MIIC5DCCAk2gAwIBAgIJAMvJ4ZlaGSiNMA0GCSqGSIb3DQEBBQUAMFYxCzAJBgNV BAYTAlVTMSEwHwYDVQQDExhkbG9wbGRhcC50ZC50ZXJhZGF0YS5jb20xJDAiBgkq hkig9w0bcqewfwrsmtywmdewqhrlcmfkyxrhlmnvbtaefw0woda1mtqxota4ndja Fw0wOTA1MTQxOTA4NDJaMFYxCzAJBgNVBAYTAlVTMSEwHwYDVQQDExhkbG9wbGRh cc50zc50zxjhzgf0ys5jb20xjdaibgkqhkig9w0bcqewfwrsmtywmdewqhrlcmfk YXRhLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0QT6CP33QKHsxUWq jetyhwfts2rnlpmpdk/tkj+o5crv0pmlixertrhy68swsblm0w//xivywwqkua2w se8q80lqlbujkfl9etunzcrmqjusl3fvsaqlpoplzlfdicun+xxugcqokuaryi5d 1UkWcQ6r9hlPCGHxXrKlgHRYRIcCAwEAAaOBuTCBtjAdBgNVHQ4EFgQUamJoMI9/ TTS59BUTF1EWoEseNAwwgYYGA1UdIwR/MH2AFGpiaDCPf000ufQVExdRFqBLHjQM ovqkwdbwmqswcqydvqqgewjvuzehmb8ga1ueaxmyzgxvcgxkyxaudgqudgvyywrh dgeuy29tmsqwigyjkozihvcnaqkbfhvkbde2mdaxmeb0zxjhzgf0ys5jb22ccqdl 296 Security Administration

Appendix F: Setting Up SSL/TLS Options Preparing to Configure Advanced Options yegzwhkojtambgnvhrmebtadaqh/ma0gcsqgsib3dqebbquaa4gbaiubbcrug3y0 VXdhAjlAKq95qryTeHE1wiDBmEe1UIC5KyyarGW9tA/sxaJ+9X/zrAwP1ymLn5n9 kijt3gh7hjjrg1qzc7jrvoi0yl/z+7qukejgp0ph1gvl4vwforzxv+i2viuuzyf3 dabr1q0+lqgc1chc001veheak8v9k6q1 -----END CERTIFICATE----- subject=/c=us/cn=dlopldap.td.teradata.com/ emailaddress=dl160010@teradata.com issuer=/c=us/cn=dlopldap.td.teradata.com/ emailaddress=dl160010@teradata.com --- No client certificate CA names sent --- SSL handshake has read 906 bytes and written 340 bytes --- New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : AES256-SHA Session-ID: 1AC1C0A2959387177910D40DBC9EC81887C4A233D907F31BB8BA7EFA7E7E76D3 Session-ID-ctx: Master-Key: 7C6DE241910B1820882D0833976FE4BF4704F163905C7540569C07D5708218A00C542D1E 6846DB65E2DE04FD6F0CEC1A Key-Arg : None Start Time: 1210794467 Timeout : 300 (sec) --- DONE Verify return code: 18 (self signed certificate) Explanation of Certificate Example The example includes the certificate and surrounding text. The certificates being offered by the directory server are bracketed by BEGIN CERTIFICATE and END CERTIFICATE statements. A directory may offer more than one certificate. Only the first certificate is important to SSL/TLS configuration. In the preceding example there is only one certificate. Immediately following the END CERTIFICATE statement are two lines describing the issuer and the subject. The subject is the identity of the certificate. The issuer is the identity of the certificate that was used to sign the certificate. Observe the following facts about the example certificate: When the issuer and subject of a certificate are the same, the certificate is considered to be self-signed. The list of certificates offered by the directory server is called the certificate chain. The subject in the example directory server certificate is: /C=US/CN=dlopldap.td.teradata.com/emailAddress=dl160010@teradata.com The CN attribute that must be verified contains the value dlopldap.td.teradata.com. Security Administration 297

Appendix F: Setting Up SSL/TLS Options Authentication of the Directory Server by Teradata Database Test the CN Value To verify that the CN value is the DNS name of the directory, run the following test. When resolved with the name service on the Teradata Database node or Query Director machine, the value in the CN attribute must yield the IP address of the directory server. If the value does not resolvable, or it resolves to a different IP address, the certificate is unusable. Authentication of the Directory Server by Teradata Database Execute the following tasks to implement authentication of the directory server by Teradata Database. Verifying the Directory Server Certificate Chain This section provides the procedure required to verify a directory server certificate chain. The procedure is comprised of the following steps. 1 Obtain all certificates in the certificate chain. 2 Catenate them into a single file or hash them in a directory. 3 Configure TDGSS and TeraGSS to verify the certificates. 4 Validate the configuration. Step 1: Obtaining the Directory Server Certificate Chain Preparation Create an SSL directory structure on each Teradata Database node, and on the Query Director if it is used. For the database, the structure must be identically named on all nodes. Teradata suggests using the TDGSS or TeraGSS site directory. The resulting ssl structure consists of two directories: site/ssl/cacerts site/ssl/certs Note: These locations correspond to the values required for the following SSL/TLS LDAP mechanism properties, which will search the directories to find needed certificate and key information: For LdapClientTlsCACertDir: site/ssl/cacerts For LdapClientTlsCert and LdapClientTlsKey: site/ssl/certs 298 Security Administration

Appendix F: Setting Up SSL/TLS Options Verifying the Directory Server Certificate Chain When the Directory Supports TLS Only If the directory server supports only TLS, then obtain a copy of the certificates directly from the site security administrator, as follows: the TDGSS site/ssl/cacerts directory (on all Teradata Database nodes) the TeraGSS site/ssl/cacerts directory (on the Query Director) Be sure to retain the BEGIN CERTIFICATE and END CERTIFICATE statements, which identify the beginning and end of each certificate. When the Directory Supports SSL If the directory server supports either SSL only, or SSL and TLS, you can use the following procedures to obtain the server certificate chain from each directory server instance that the Teradata Database, and Query Director if used, will access. The procedure collects the certificates into a directory and then creates hashes for them. For each directory server that the Teradata Database or Query Director will communicate with, run the following command: openssl s_client -connect <server-name:port> -showcerts </dev/null where: server-name is the directory server DNS name port is the port where ssl is listening, usually 636 This command produces output that shows the certificate chain. Example Certificate Chain The following example shows a certificate chain. CONNECTED(00000003) depth=1 /C=US/CN=YaST Default CA (dlopldap)/emailaddress=postmaster@site verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/c=us/cn=dlopldap.site/emailaddress=postmaster@site i:/c=us/cn=yast Default CA (dlopldap)/emailaddress=postmaster@site -----BEGIN CERTIFICATE----- MIIEUTCCAzmgAwIBAgIBATANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJVUzEj MCEGA1UEAxMaWWFTVCBEZWZhdWx0IENBIChkbG9wbGRhcCkxHjAcBgkqhkiG9w0B CQEWD3Bvc3RtYXN0ZXJAc2l0ZTAeFw0wNzA4MDMxMjQwNTdaFw0wODA4MDIxMjQw NTdaMEUxCzAJBgNVBAYTAlVTMRYwFAYDVQQDEw1kbG9wbGRhcC5zaXRlMR4wHAYJ KoZIhvcNAQkBFg9wb3N0bWFzdGVyQHNpdGUwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDYBetFqZE5FFaeKc5n220KWcXFa1ys9ZOyHDwjVtOvm2Rgd/77 KM8TOsFq5HyUCUYzYwdC07VuBU3u2qgAleY/0nN+pKP89ohY/rYQbsblHA8QrXVP LmBuKM3kN/MGyN0bKFYrfhAFy7bU1hreyNbcLdUZAmfunYX9YUk4lX8eOHRuMDgp VMw+L8I0c80PtjwvQLDpjw3HRTch3HQLSK3+vCA9WQFmJmHuj5aZiFqqUiCRnOmW zdlbj9bolstln1luk3+zys5vgrir0k303tezgrdbxcopfajvzly3yjxg4plwepqq eezjzwngqybasyoknz6l/ysspzrulgbtvbttagmbaagjgge9miibotajbgnvhrme AjAAMDAGCWCGSAGG+EIBDQQjFiFZYVNUIEdlbmVyYXRlZCBTZXJ2ZXIgQ2VydGlm awnhdguweqyjyiziayb4qgebbaqdagzamasga1uddwqeawifodadbgnvhq4efgqu GuSiFwDmaqtRK2fNeqoVFSRd2aEwgYIGA1UdIwR7MHmAFGEVkfLO9/CKNHdY/FQ8 Smu+cF2uoVakVDBSMQswCQYDVQQGEwJVUzEjMCEGA1UEAxMaWWFTVCBEZWZhdWx0 Security Administration 299

Appendix F: Setting Up SSL/TLS Options Verifying the Directory Server Certificate Chain IENBIChkbG9wbGRhcCkxHjAcBgkqhkiG9w0BCQEWD3Bvc3RtYXN0ZXJAc2l0ZYIJ AONqNX/09CYAMBoGA1UdEQQTMBGBD3Bvc3RtYXN0ZXJAc2l0ZTAaBgNVHRIEEzAR gq9wb3n0bwfzdgvyqhnpdguwdqyjkozihvcnaqefbqadggebaciemdmfzq2zfbhh 9POKRJ9867BOb0TGmzk/Iw0WT+MbFR5m0a04Ke36tQcluKYSkXxXryrwk+pwDdo4 SXXXf6+cgUT+/te1ifCmjEq3o7zTi1E7wYoXz8q93j8PUjNhhfNfKlfVa4tapwhS z0wot9ie+bltt8zdbwtbx13iyolhqgxev2jnkhfsknw01xlpsygempy/znitwa4n 5Qs3iOj6U+oo3xHkB/dDHgSP6DGurc+jo9doLifyVX9AUUCfLbO/U3sCBneVVelJ d31x/qev/5njrpj1zrrnpf+xgubslqn5vyhl6pdbuk8kv9ozptskjhobnyd5k1lt nmqvdrc= -----END CERTIFICATE----- 1 s:/c=us/cn=yast Default CA (dlopldap)/emailaddress=postmaster@site i:/c=us/cn=yast Default CA (dlopldap)/emailaddress=postmaster@site -----BEGIN CERTIFICATE----- MIIEaDCCA1CgAwIBAgIJAONqNX/09CYAMA0GCSqGSIb3DQEBBQUAMFIxCzAJBgNV BAYTAlVTMSMwIQYDVQQDExpZYVNUIERlZmF1bHQgQ0EgKGRsb3BsZGFwKTEeMBwG CSqGSIb3DQEJARYPcG9zdG1hc3RlckBzaXRlMB4XDTA3MDgwMzEyNDA1NloXDTE3 MDczMTEyNDA1NlowUjELMAkGA1UEBhMCVVMxIzAhBgNVBAMTGllhU1QgRGVmYXVs dcbdqsaozgxvcgxkyxapmr4whayjkozihvcnaqkbfg9wb3n0bwfzdgvyqhnpdguw ggeima0gcsqgsib3dqebaquaa4ibdwawggekaoibaqcshflztizsuhvcwfbwhjhy X9PgH3C3fFXLW7nOjgtmGMq5PqUBpe8ZtyLVvaTW+F7G836arjGUFHdcNmQgDCDD JU48UyNCa+koBqrjD8YCbEGnz8IpNnbIrxFD4XDWtOlEKPCcChtP0SoifkN31SDQ k0yjmgieukbf7ns25+rf+booxvgveq4/kqg5nu1u5parq+g+sfegtb6q2kpjpcmb M80F730u2H2rluBdAgUB+wAUTp+P+KqNKXI0mZuKI9cid167tz5u3IybWwZlNj8I kh8tdrt+cne8xsfwjtnd2jm2jnk9vhfvxgdxkcpd53bvvcsscf6id0x5/kepscvf AgMBAAGjggE/MIIBOzAPBgNVHRMBAf8EBTADAQH/MCwGCWCGSAGG+EIBDQQfFh1Z YVNUIEdlbmVyYXRlZCBDQSBDZXJ0aWZpY2F0ZTARBglghkgBhvhCAQEEBAMCAQYw CwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRhFZHyzvfwijR3WPxUPEprvnBdrjCBggYD VR0jBHsweYAUYRWR8s738Io0d1j8VDxKa75wXa6hVqRUMFIxCzAJBgNVBAYTAlVT MSMwIQYDVQQDExpZYVNUIERlZmF1bHQgQ0EgKGRsb3BsZGFwKTEeMBwGCSqGSIb3 DQEJARYPcG9zdG1hc3RlckBzaXRlggkA42o1f/T0JgAwGgYDVR0RBBMwEYEPcG9z dg1hc3rlckbzaxrlmboga1udegqtmbgbd3bvc3rtyxn0zxjac2l0ztanbgkqhkig 9w0BAQUFAAOCAQEARSQFVo0CQZk80bRF39Ikj6FfV8Ex1vYaDsebYsmEeoK/lPOg jii09lfw0s/80sd096b76txhmazlaobjkd1wszh4pmyxvbw/j5s8ceqmsput1yvo qjygqb45/jnpyagidmn/gi0mt/eov+avwapxdh2ynqrgvo6w3/jd4pj7h8mp43u2 parryejcneosmi5dloyqpmu2redncrfrdhjvhbliqavenzvqghj2xwobjj6llr+b NF+Vw+HrPnEuRFimqCuRs9yRbOxNX9OvJhUQdp1PctvB48WmeBNcUeE+7Ymy2H9J DEKomkn6L5hzQCA6RD3FR6qROBOuNNSWWwEyGQ== -----END CERTIFICATE----- --- Server certificate subject=/c=us/cn=dlopldap.site/emailaddress=postmaster@site issuer=/c=us/cn=yast Default CA (dlopldap)/emailaddress=postmaster@site --- No client certificate CA names sent --- SSL handshake has read 2406 bytes and written 468 bytes --- New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 2048 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : AES256-SHA Session-ID: 60DA3D90FD3D716C2C47BC71D3B08A3932288ABA01B02BCEF9D08F06E0035A38 Session-ID-ctx: 300 Security Administration

Appendix F: Setting Up SSL/TLS Options Verifying the Directory Server Certificate Chain Master-Key: 33F4F8CF6112475A88501239FB4D4BA80D53E5B89848482AA81A58894FAB1C99 05137F3AD15E94EFD276CD84B7C7EF38 Key-Arg : None Start Time: 1210860425 Timeout : 300 (sec) --- DONE Verify return code: 19 (self signed certificate in certificate chain) Explanation of Certificate Chain Example The example includes two certificates and surrounding text. The certificates being offered by the directory server are bracketed by BEGIN CERTIFICATE and END CERTIFICATE statements. These certificates can be copied verbatim into their own files. Be sure to include the BEGIN CERTIFICATE and END CERTIFICATE statements. The name of the file that contains the certificate is not significant, but the file name should clarify which certificate is contained in the file. Immediately following each END CERTIFICATE statement are two lines describing the issuer and the subject. The first certificate has a subject of /C=US/CN=dlopldap.site/ emailaddress=postmaster@site. This is the directory server's certificate. The CN attribute contains the name dlopldap.site so we could give the certificate file the name site/ssl/cacerts/ dlopldap.pem. The extension pem indicates the certificate format. We use pem because LDAP only supports PEM certificates. The first certificate is the directory server certificate. It has a subject of: /C=US/CN=dlopldap.site/emailAddress=postmaster@site The CN attribute contains the name dlopldap.site. The name for the file in which it is stored can be something like site/ssl/cacerts/dlopldap.pem. Note that the extension pem indicates the certificate format. LDAP supports only PEM-formatted certificates. The second certificate in the chain has a subject of: /C=US/CN=YaST Default CA (dlopldap)/emailaddress=postmaster@site so we could give it's file the name site/ssl/ cacerts/yast-ca.pem. Security Administration 301

Appendix F: Setting Up SSL/TLS Options Verifying the Directory Server Certificate Chain Step 2: Creating the CA Certificate Hashes The following procedure creates for the CA certificates, because hashes allow OpenSSL to locate certificates faster. If a directory server provides a certificate, OpenSSL will hash the subject and serial number of that certificate and then open the symlinks bearing the same hash code until it finds the certificate. The symlink hashes provide a kind of indexing service that eliminates the need for OpenSSL to sift through every available certificate. The Certificate Chain example above contains two certificates. Each of these certificates must be stored in a file before beginning the hashing process. OpenSSL cannot use these files directly, instead requiring the following: that the subject and serial number of the file be used to compute a 32 bit hash code and that a file whose name is the hash code (rendered in readable hexadecimal) and whose extension is a decimal number starting with 0 to be created. This scheme allows certificates that have identical hashes to be represented as separate symlinks. use the subject and the serial number of the certificate file to create a 32-bit hash code This scheme allows certificates with identical hashes to be represented as separate symlinks. Creating Hashes Manually Manual creation of hashes is possible using the following script: Note: This is a rudimentary script that does not do much error testing. It is adequate for managing a small number of certificates, but is not appropriate for cases where... The script falls apart when the number of hash collisions on a particular computed hash code exceeds 10. #!/bin/sh # # usage: certlink.sh filename [filename...] for CERTFILE in $*; do # make sure file exists and is a valid cert test -f "$CERTFILE" continue HASH=`openssl x509 -noout -hash -in "$CERTFILE"` test -n "$HASH" continue # use lowest available iterator for symlink for ITER in 0 1 2 3 4 5 6 7 8 9; do test -f "${HASH}.${ITER}" && continue ln -s "$CERTFILE" "${HASH}.${ITER}" test -L "${HASH}.${ITER}" && break done done Using the Certificate Hash Creation Script The following procedure describes how to create hashes using the hash creation script. 1 Copy this script to a file named certlink.sh. 2 Make the file executable. 3 From the site/ssl/cacerts directory, enter the following command: certlink.sh *.pem 302 Security Administration

Appendix F: Setting Up SSL/TLS Options Verifying the Directory Server Certificate Chain Creating Hashes Using c_rehash The c_rehash utility is provided with OpenSSL is contained in the same directory as the openssl utility, and provides an automated method of creating certificate hashes, which is more suitable for large systems than the manual method described above. To create certificate hashes using the c_rehash utility, do the following: 1 From the site/ssl/cacerts directory that contains the two.pem files, enter the following command to hash the files: c_rehash. 2 The command will yield output something like the following example: dlopldap:~ # vi YaST-CA.pem dlopldap:~ # vi dlopldap.pem dlopldap:~ # c_rehash. Doing. dlopldap.pem => c5fc7afc.0 YaST-CA.pem => 9a135280.0 dlopldap:~ # The example output shows that two symlink files named c5fc7afc.0 and 9a135280.0 were created. These symlinks point to the.pem files dlopldap.pem and YaST-CA.pem that were created in Step 2: Creating the CA Certificate Hashes. Step 3: Configuring TDGSS and TeraGSS Implementing authentication of the directory server by Teradata Database requires the configuration of two LDAP mechanism properties. Whether configuring TDGSS for the Teradata Database or TeraGSS for Query Directory, the steps involved in configuring the properties are the same. Make the following changes to the TdgssUserConfigFile.xml file in the TDGSS or TeraGSS site directory as shown in Appendix C Changing the TDGSS Configuration. Add the LdapClientCACertDir property and specify the full path to the site/ssl/ cacerts directory for the property value. This property points to the absolute path of the directory where the two PEM files and the two symlinks are located. Add the LdapClientReqCert property and set the property value to demand. This value causes Teradata Database to ask the directory server for a certificate each time a directory logs on to the database. If a certificate is not provided or an invalid certificate is sent, the connection is terminated. The TdgssUserConfigFile.xml file will look something like the following (for MP-RAS) after the changes have been made: <Mechanism Name="ldap"> <MechanismProperties... LdapServerName="ldap://someserver/" LdapClientUseTls="yes" LdapClientTlsCACertDir="/usr/tdgss/site/ssl/cacerts/" LdapClientTlsReqCert="demand" /> Security Administration 303

Appendix F: Setting Up SSL/TLS Options Verifying the Directory Server Certificate Chain </Mechanism> The LdapClientUseTls attribute should already be set as part of the initial implementation of basic TLS protection. Similarly, the LdapServerName is set to ldap://someserver/. If TDGSS or TeraGSS is using LDAP through SSL as is the case when LdapServerName is set to something like ldaps://someserver/, the setting of this control is ignored. We suggest setting it to "yes" to guarantee that the directory server certificate is always verified regardless of how the connection to the directory is established. Step 4: Testing the Connection Before restarting the Teradata Database (and Query Director, if used), first use tdsbind to try to establish a connection. If the tdsbind run succeeds the Teradata Database and the Query Director can be restarted. If tdsbind fails and does not provide a clear indication of what went wrong, adding a -V 2 option will cause it to provide additional hexadecimal message dumps, which contain hints about the cause of failure. The Troubleshooting section describes the most common errors and solutions for them. For information on using tdsbind, see tdsbind on page 274. Note: Be aware that certificates usually have expiration dates. If any certificate in the certificate chain has expired, the connection to the directory will cease to function until a new set of certificates is obtained and installed in the CA certificate directory. 304 Security Administration

Appendix F: Setting Up SSL/TLS Options Mutual Authentication of the Directory Server and Teradata Database Mutual Authentication of the Directory Server and Teradata Database Once Teradata Database has been configured to authenticate the directory server, you have the option of also having the directory server authenticate the database. Under normal circumstances the directory server does not need to authenticate the database, since it already authenticates the end users that access the database. When mutual authentication between Teradata Database and the directory server is required, a site may require the directory server to authenticate the nodes in a Teradata Database and the machine on which Query Director runs. Site policy determines how and when client certificates are required by network services, and the Teradata components of the system can be configured to conform to these policies. Installing Certificates and Private Keys Installing the Private Key Installation of certificates is not a normal part of configuring a Teradata Database node or a Query Director, so when a mutual authentication requirement exists the certificates and associated keys must be specially installed. The security administrator will need to issue a unique certificate for each Teradata Database node and for the Query Director. These certificates are known as client certificates because for LDAP purposes, the database is a client of the directory server. Client certificates must be in PEM format and conform to the requirements of the directory server being used. Coordinate with the directory administrator or the directory vendor to determine detailed certificate requirements. The security administrator will probably deliver the certificates and keys in one of the following ways: A single file containing both the certificate and the private key. A pair of files, one containing the certificate and the other containing the key. Note: In either case, guard the file containing the private key very closely. Anyone with this key can assume the identity of the database. In the TDGSS (for the Teradata Database) or TeraGSS (for Query Director) site directory, create a directory called site/ssl/certs. From within this new directory create an empty file named clientkey.pem and secure it to be read-write for its owner. Use the following command sequence: 1 touch clientkey.pem 2 chmod 0600 clientkey.pem 3 Place the key in this file using an editor or the Posix cat command The reason for creating an empty file first and making it readable and writable by the owner only is to prevent the key from being revealed to unauthorized personnel that may be trying to obtain sensitive information. Security Administration 305

Appendix F: Setting Up SSL/TLS Options Mutual Authentication of the Directory Server and Teradata Database Installing the Certificate Example of a Private Key Installed on a Database Node The resulting clientkey.pem file will look something like the following: -----BEGIN RSA PRIVATE KEY----- MIICXAIBAAKBgQDRBPoI/fdAoezFRaqN63IdYW1Laucs+akMr+0qP47kKu/SkyUh d6u1eflryzbieubtd//gjxldbcs4dbcx7xdzsvcufqmr+x16241kksyqo6wvd+9j pcwk6ktksv0gk437hg4yko4q4bhijl3vsrzxdqv2gu8iyffesqwadfhehwidaqab AoGAIw0AmO1tvwroV5R9K1tmQYMK/vCoX6RmMth1nvYVkjGZEejW+yvEQZMG93+V UyDIUHCIZcP14LobJjo1fUEnyDag37P7FE9JDXr7I3QRNA0keR+w0egNpMcQMiDE Bgj7UCycCxuzOFX1UuvcnCMJH7QfBLb3p01BgK6W2ENfxLECQQD5PMSfs+ogS7Bb fchlthbja3576pybeburrcz/o3lmutkz0vazxbpwtxncv/tln1huveyuiz2pyun3 0zjcr2UFAkEA1rDZpCMZ4woUkvYX+BwkffG8HXnZNGROd4zu1tbQEgeBjOSVx299 s/fsxegtmrsgv6vpwdmcqfyy+tedj7im8isjtdnbf19htv+qzydrdmrpuezqpb4w 7FMz/PlpoOmeGj1gTID5Hfjw7kPvHfi5GwJBAO83aik2j8LLostNmqsV4e+SUPYx GxpQ3TgIrrdSqCSSTq3WCgHhoJCTeRK2S1W75tjelCXao97yCTp6GxuFpNkCQDLv wknlxjwozbu8ebfgs/pbr80ahmmebvof94c3dkribyu9eqa/vpoczgbgoj557w3w 66sz2d5P4q71EBDcWE05DsFE9fqwAR5xcoWqGPYiuh0= -----END RSA PRIVATE KEY----- Once the key is in place and secure, make the file read-only for the user under which the gateway or Query Directory server runs. Then execute the following procedure: 1 Enter chmod 0400 clientkey.pem 2 Enter chown gtw-or-qd-user clientkey.pem 3 Substitute the user name of the Teradata Gateway or Query Director for gtw-or-qd-user. Note: The preceding procedure is necessary because OpenSSL will not accept a key in a globally readable file. Protection of the file also prevents unauthorized persons from obtaining the key because it is inaccessible. Create a file named clientcert.pem the ordinary way in the site/ssl/certs directory. Make it writable by the owner and universally readable. Place the certificate in the file. Example of a Certificate Installed on a Database Node This file will look something like the following: -----BEGIN CERTIFICATE----- MIIC5DCCAk2gAwIBAgIJAMvJ4ZlaGSiNMA0GCSqGSIb3DQEBBQUAMFYxCzAJBgNV BAYTAlVTMSEwHwYDVQQDExhkbG9wbGRhcC50ZC50ZXJhZGF0YS5jb20xJDAiBgkq hkig9w0bcqewfwrsmtywmdewqhrlcmfkyxrhlmnvbtaefw0woda1mtqxota4ndja Fw0wOTA1MTQxOTA4NDJaMFYxCzAJBgNVBAYTAlVTMSEwHwYDVQQDExhkbG9wbGRh cc50zc50zxjhzgf0ys5jb20xjdaibgkqhkig9w0bcqewfwrsmtywmdewqhrlcmfk YXRhLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0QT6CP33QKHsxUWq jetyhwfts2rnlpmpdk/tkj+o5crv0pmlixertrhy68swsblm0w//xivywwqkua2w se8q80lqlbujkfl9etunzcrmqjusl3fvsaqlpoplzlfdicun+xxugcqokuaryi5d 1UkWcQ6r9hlPCGHxXrKlgHRYRIcCAwEAAaOBuTCBtjAdBgNVHQ4EFgQUamJoMI9/ TTS59BUTF1EWoEseNAwwgYYGA1UdIwR/MH2AFGpiaDCPf000ufQVExdRFqBLHjQM ovqkwdbwmqswcqydvqqgewjvuzehmb8ga1ueaxmyzgxvcgxkyxaudgqudgvyywrh dgeuy29tmsqwigyjkozihvcnaqkbfhvkbde2mdaxmeb0zxjhzgf0ys5jb22ccqdl yegzwhkojtambgnvhrmebtadaqh/ma0gcsqgsib3dqebbquaa4gbaiubbcrug3y0 VXdhAjlAKq95qryTeHE1wiDBmEe1UIC5KyyarGW9tA/sxaJ+9X/zrAwP1ymLn5n9 kijt3gh7hjjrg1qzc7jrvoi0yl/z+7qukejgp0ph1gvl4vwforzxv+i2viuuzyf3 dabr1q0+lqgc1chc001veheak8v9k6q1 306 Security Administration

Appendix F: Setting Up SSL/TLS Options Mutual Authentication of the Directory Server and Teradata Database -----END CERTIFICATE----- Repeat the Installations for the Entire Database Repeat the key and certificate installation process on each node of a Teradata Database. Make sure to keep the keys and certificates for each node paired properly--each pair is uniquely matched. Since the TDGSS configuration is obtained from a GDO, of which there is only one copy on a multi-node system, the GDO can specify only a single file name for the key file and certificate file. Therefore the file must be named and located identically on every node of the system even though the contents of each file will be different. Updating the TDGSS or TeraGSS Configuration Once each LDAP client has a certificate filed in site/ssl/certs/clientcert.pem and a paired key filed in site/ssl/certs/clientkey.pem, update the TDGSS (nodes) or TeraGSS (Query Director) configuration. Perform the edit to the TDGSS or TeraGSS configuration file similarly to configurations shown in previous steps, adding LdapClientTlsCert and LdapClientTlsKey attributes and values. Example Configuration for Mutual Authentication The following example shows a typical TdgssUserconfigfile.xml update to support TLS mutual authentication: <Mechanism Name="ldap"> <MechanismProperties... LdapClientTlsCert="/usr/tdgss/site/ssl/certs/clientcert.pem" LdapClientTlsKey="/usr/tdgss/site/ssl/certs/clientkey.pem" /> </Mechanism> After the client certificate and key have been added to the TdgssUserconfigfile.xml, run the tdgssconfig utility in the TDGSS or TeraGSS bin directory can be run and testing performed with tdsbind. After you're satisfied with the results, the Teradata Database or Query Directory can be restarted to make the new configuration come alive. Note: When verifying correct behavior on a Teradata Database, be sure to verify behavior on each and every Teradata node. Failure to adequately test can result in loss of connectivity for Teradata clients using LDAP authentication through a badly configured node. Security Administration 307

Appendix F: Setting Up SSL/TLS Options Troubleshooting Troubleshooting The following common errors may occur when configuring SSL/TLS options. Hostname Does Not Match CN in Peer Certificate This error is caused by a lack of agreement between the CN in the directory server certificate and the network name service when LdapClientTlsReqCert is set to a value other than never. Error Message Text hostname does not match CN in peer certificate Corrective Action To debug this error do the following: 1 Obtain the certificate from the directory using the following command: openssl s_client -connect server-name:port 2 In the output from this command, find the line that begins with subject:. This string should contain a CN attribute. The CN attribute value is required to be a name that resolves in DNS to the IP address of the directory server being addressed. An error message was returned because is the DNS is either unresolved, or resolves to the wrong IP address. The error is related to either a DNS problem or a problem with the server certificate. 3 Check the following items in order to determine the problem and fix it. a b c If the LdapServerName property names the directory server explicitly, make sure the name you use in the LDAP or LDAPS URI matches the name in the subject: for the directory server certificate. For example, if the subject: CN attribute contains: dlopldap.td.teradata.com then make sure the LdapServerName property contains either the TLS specification: ldap://dlopldap.td.teradata.com/ or the SSL specification: ldaps://dlopldap.td.teradata.com/ Make sure that the name in the CN attribute is resolvable and returns the correct IP address. Fix any errors and try again. If the name in the CN attribute cannot be resolved or resolves to the wrong IP address, and cannot be changed in DNS, then you must install a new certificate on the directory server that conforms to LDAP requirements, as shown in Directory Server Certificate Requirements on page 296. The requirements for the CN attribute are as follows: The subject: for the certificate subject MUST contain the DNS name (preferably, the fully qualified DNS name) that resolves to the IP address where the server is listening. The DNS name must correctly resolve on the Teradata Database nodes, and on the 308 Security Administration

Appendix F: Setting Up SSL/TLS Options Troubleshooting SSL: Certificate Verify Failure Query Director machine, if it is used. If the LdapServerName attribute is configured to explicitly name directory servers, the value in the subject's CN attribute must be used in the configured LDAP or LDAPS URI. This is generally a problem with the server's certificate. Error Message Text error:14090086:ssl routines:ssl3_get_server_certificate:certificate verify failed Corrective Action Recapturing and reinstalling the certificates in the server certificate chain is usually enough to correct this problem. Note: This error may indicate a security breach. Consider the following actions to check for a possible security threat. Check the access logs to detect any suspicious activity. Get a copy of the directory server certificate chain to you to make sure that the database has the officially trusted set of certificates. TLS: Self-signed Certificate Offered or Is Part of the Certificate Chain This error message may not represent a real security issue. It is an alert that the directory server has offered a self signed certificate. This error is generally seen only in the message traces when the tdsbind option -V 2 is used, or in the diagnostic output from the ldap tools when the option -d 2 is used. A more serious form of this error is discussed earlier in this section, and shows up as: certificate verify failed Error Message Text TLS certificate verification: Error, self signed certificate Corrective Action If this is expected behavior, the error can be eliminated by installing the self-signed certificate as described in Installing the Certificate on page 306. TLS: Unable to Get Local Issuer Certificate This error occurs when a certificate signed by a third party (like VeriSign or Thawte) is used in the directory. In such cases, the directory server may not offer the complete certificate chain, with the result that the certificate cannot be verified. Error Message Text verify error:num=20:unable to get local issuer certificate Security Administration 309

Appendix F: Setting Up SSL/TLS Options Troubleshooting Example 1: Use openssl to Identify the Certificates Not Verified When the above error is encountered, use the openssl command to display the certificate chain. The result will show a chain that ends with an issuer for which there is no certificate, as shown in the following example: depth=1 /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign verify error:num=20:unable to get local issuer certificate verify return:0 CONNECTED(00000003) --- Certificate chain 0 s:/c=us/st=california/l=el Segundo/O=Teradata/OU=Domain Controllers/ CN=sussan140.td.teradata.com i:/o=verisign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign -----BEGIN CERTIFICATE----- snipped -----END CERTIFICATE----- 1 s:/o=verisign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSig i:/c=us/o=verisign, Inc./OU=Class 3 Public Primary Certification Authority-----BEGIN CERTIFICATE----- snipped -----END CERTIFICATE------ Server certificate subject=/c=us/st=california/l=el Segundo/O=Teradata/OU=Domain Controllers/CN=sussan140.td.teradata.com issuer=/o=verisign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign --- Acceptable client certificate CA names/c=us/o=verisign, Inc./OU=Class 1 Public Primary Certification Authority - G2/OU =(c)1998 VeriSign,Inc.-For authorized use only/ou=verisign Trust Network /C=US/O=VeriSign, Inc./OU=Class 4 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/ou=verisign Trust Network /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority /C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification Authority /C=US/O=VeriSign, Inc./OU=Class 1 Public Primary Certification Authority /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/ou=verisign Trust Network /OU=Copyright (c) 1997 Microsoft Corp./OU=Microsoft Corporation/ CN=Microsoft Root Authority/DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority--- SSL handshake has read 5299 bytes and written 312 bytes --- New, TLSv1/SSLv3, Cipher is RC4-MD5 Server public key is 1024 bit Compression: NONE Expansion: NONE 310 Security Administration

Appendix F: Setting Up SSL/TLS Options Troubleshooting Explanation of Example 1 The error occurs at a depth of 1, that is, one certificate down the certificate chain, the certificate could not be verified. This error indicates that the issuer certificate (the first two lines shown in bold font) or an acceptable client certificate (the large group of lines shown in bold font) was not found. Corrective Action Use the following procedure to correct the Unable to get local issuer certificate problem. Install any or all of the certificates detected by openssl in the CA certificate directory. The run c_rehash. Teradata recommends installing the issuer certificate, since this certificate is immediately needed to correct the problem. 1 Obtain the needed certificate. See the following section, Obtain the Needed Certificate. 2 Install the certificate. See Installing the Certificate on page 306. 3 Run the c_rehash utility. See Creating Hashes Using c_rehash on page 303. Obtain the Needed Certificate Typically, a certificate can be acquired from the site security administrator. For systems running SUSE Linux Enterprise Server, with openssl installed, some or all of these certificates can be found in the /etc/ssl/certs directory. Do the following to obtain a certificate. 1 Go to the /etc/ssl/certs directory. 2 List the files. The files will look something like the following: dlopldap:~ # cd /etc/ssl/certs dlopldap:/etc/ssl/certs # ls 1e49180d.0 7a9820c1.0 a3c60019.0 demo thawtecb.pem 2edf7016.0 843b6c51.0 aad3d04d.0 eng1.pem thawtecp.pem 56e607f4.0 878cf4c6.0 argena.pem eng2.pem vsign1.pem 594f1775.0 Equifax-root1.pem argeng.pem eng3.pem vsign3.pem 6adf0799.0 ICP-Brasil.pem c33a80d4.0 eng4.pem vsignss.pem 6f5d9899.0 RegTP-5R.pem cdd7aee7.0 eng5.pem wellsfgo.pem 714aceac.0 RegTP-6R.pem d4e39186.0 expired 7651b327.0 YaST-CA.pem ddc328ff.0 f73e89fd.0 dlopldap:/etc/ssl/certs # openssl x509 -inform pem -in vsign3.pem subject subject= /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority-----BEGIN CERTIFICATE---- MIICPDCCAaUCEHC65B0Q2Sk0tjjKewPMur8wDQYJKoZIhvcNAQECBQAwXzELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFz cyazifb1ymxpyybqcmltyxj5ienlcnrpzmljyxrpb24gqxv0ag9yaxr5mb4xdtk2 MDEyOTAwMDAwMFoXDTI4MDgwMTIzNTk1OVowXzELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAzIFB1YmxpYyBQcmlt YXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDJXFme8huKARS0EN8EQNvjV69qRUCPhAwL0TPZ2RHP7gJYHyX3KqhE BarsAx94f56TuZoAqiN91qyFomNFx3InzPRMxnVx0jnvT0Lwdd8KkMaOIG+YD/is I19wKTakyYbnsZogy1Olhec9vn2a/iRFM9x2Fe0PonFkTGUugWhFpwIDAQABMA0G CSqGSIb3DQEBAgUAA4GBALtMEivPLCYATxQT3ab7/AoRhIzzKBxnki98tsX63/Do lbwdj2wsqfhmc9ikwfpwttymwhybv4gsxihx0bh/59ahwm1pf+nehjwzrdmjxnyc AA9WjQKZ7aKQRUzkuxCkPfAyAw7xzvjoyVGM5mKf5p/AfbdynMk2OmufTqj/ZA1k -----END CERTIFICATE----- dlopldap:/etc/ssl/certs # Security Administration 311

Appendix F: Setting Up SSL/TLS Options Troubleshooting Note: The files that end in something other than a numeric suffix are certificate files. On this system, all certificates are stored in PEM format. 3 Use the openssl openssl x509 command with a -subject option to examine the subject of each certificate. Run the openssl -509 -subject common each of the.pem files until one containing a certificate with a subject that matches the missing certificate is found. 4 One can run the openssl command given above on each of the.pem files until one containing a certificate with a subject that matches the missing certificate The subject shown in bold text in the Step 2 example matches the subject of the missing certificate identified in the search shown in Example 1: Use openssl to Identify the Certificates Not Verified on page 310. 312 Security Administration

APPENDIX G Setting up Kerberos Authentication on Unix Nodes This special setup procedure is not required for external authentication using the KRB5 or SPNEGO mechanisms when both the client and Teradata Database run on Windows. However, when Teradata Database runs on Unix several critical setup procedures must be executed before users can employ the KRB5 or SPNEGO mechanism. KRB5 and SPNEGO logons to Teradata Database on Unix are only supported for the following system configurations: Teradata Database Operating System MP-RAS 3.03 Client Operating System Windows SUSE Linux Enterprise Server 10 Note: Since SPNEGO uses the underlying Kerberos framework, a single execution of the following procedure will enable both KRB5 and SPNEGO logons to Teradata Database on Unix. Active Directory Setup Execute the following procedures on the Active Directory server to prepare for Kerberos authentication of logons to Teradata Database running on Unix. 1 Task 1: Create a Computer Component for Each Teradata Database Node 2 Task 2: Add Unix Nodes to the Domain Name System (DNS) 3 Task 3: Create an Active Directory User for Each Unix Node 4 Task 4: Determine the Service Principal Name 5 Task 5: Run ktpass to Create the Kerberos Keys If there are multiple Active Directory servers that will authenticate Teradata Database users, duplicate this setup procedure on each Active Directory server. Note: This procedure is not related to the Active Directory setup for LDAP logons described in Chapter 6. However, if you have set up Active Directory for LDAP logons, some of the steps in this section may have already been completed. Security Administration 313

Appendix G: Setting up Kerberos Authentication on Unix Nodes Active Directory Setup Task 1: Create a Computer Component for Each Teradata Database Node When a Windows computer is added to a domain, the computer is automatically given an entry under Computer Organizational Unit (OU) in Active Directory Users and Computers for the domain. This does not happen when a Unix computer is added. Unix computers must be manually identified in Active Directory. Use the following procedure to create a computer component for each Teradata Database node running on Unix. 1 On the Active Directory server, click on Start > Programs > Administrative Tools > Active Directory Users and Computers. 2 Right click on Computers. 3 Click on New > Computer. 4 Enter the name of the Teradata Database Unix node and click Next. There is no requirement for how nodes are named because the node name is tied to the node IP address in the next task. However, one possibility is to use a structure such as node1-1, where the first 1 denotes a Teradata Database system (to differentiate among multiple systems), and the second 1 identifies a specific node within the system. Note: Record all node names. They will be used in several of the remaining setup tasks. 5 Click Finish. Note: Repeat this procedure for each Teradata Database Unix node. Task 2: Add Unix Nodes to the Domain Name System (DNS) Unix computers, including Teradata Database nodes, must be added manually to the DNS. Add each Teradata Database Unix node to the DNS as follows: 1 On the Active Directory server, click on Start > Programs > Administrative Tools > DNS. If necessary, double click the computer in the left hand pane to expand it. 2 Double click Forward Lookup Zones to expand it. 3 Right click the Forward Lookup Zone entry that corresponds to the domain which contains the Teradata Database nodes. Note: Retain the domain information for use in several of the tasks that follow this one. 4 Click New Host (A) 5 In the New Host dialog box, enter the name of a Teradata Database Unix node in the box labeled Name. Use the node names assigned in Task 1, Step 4. 6 In the box labeled IP Address, enter the IP Address for the node. 7 Check the box labeled Create associated pointer (PTR) record. 8 Click Add Host. 9 Wait for the message The host record was successfully created. 10 Click OK. Note: Repeat this procedure for each Teradata Database Unix node. 314 Security Administration

Appendix G: Setting up Kerberos Authentication on Unix Nodes Active Directory Setup Task 3: Create an Active Directory User for Each Unix Node Create an Active Directory user under the user Organizational Unit (OU) for each Teradata Database Unix node added to the DNS in the previous procedure. This step is necessary for the formation of the SPN when Unix servers are used with Active Directory. Note: Each Active Directory user, which in this case is a Teradata Database Unix node, requires a password. Teradata recommends using a strong password, and if site policy allows, you can use the same password for all node users. For each Teradata Database Unix node, create a User as follows: 1 On the Active Directory server, click on Start > Programs > Administrative Tools > Active Directory Users and Computers. 2 Double-click on Users to expand it, if necessary. 3 Right click on Users. 4 Click on New > User. 5 In the dialog box, enter the name of the node for both User logon name and First name. Use the node names assigned in Task 1, Step 4. 6 Click Next. 7 Enter a password and reenter it to confirm. This is a critical security item. Use a password of sufficient strength to meet the highest security standards for your site. 8 If site policy allows it, check the Password never expires box. If not, check User cannot change password. 9 Click Next. Note: Repeat this procedure for each Teradata Database Unix node. Security Administration 315

Appendix G: Setting up Kerberos Authentication on Unix Nodes Active Directory Setup Task 4: Determine the Service Principal Name Setting up the KRB5 and SPNEGO mechanisms to work with Teradata Database on Unix calls for running the ktpass utility to create the Kerberos encryption keys, shown in a later task. Before proceeding to that task you must determine the Service Principal Name (SPN) for each Teradata Database Unix node. SPNs are used by the Teradata client to specify the Teradata Database Unix node (and the program or service running on the node) to which it wants to connect, and are therefore critical for generating the keys that will be passed between the client and database. SPNs take the following form: <SERVICE NAME>/<instance>@<REALM> where: Term Example Value Description <SERVICE NAME> TERADATA/ The service being requested is always Teradata Database. <instance> node1-1.corp.teradata.com The Fully Qualified Domain Name (FQDN) for the node. It uniquely identifies a Teradata Database Unix node, using: The node name from Task 1, Step 4; in this example, node1-1. The domain path to the node, taken from Task 2, Step 3; in the form: subdomain.domain.com Note: Domain information entered for <instance> is case sensitive and must appear in lowercase characters, as shown in the example. The domain information provided for this term can include one or more additional subdomain specifications if required to uniquely locate the node. <REALM> CORP.TERADATA.COM The name of the realm that contains the node. Note: The realm information must match the Windows domain exactly and must be the same case. The realm information provided for this term can include one or more additional subrealm specifications if required to uniquely identify the realm. Note: Determine the SPNs for all nodes defined in Task 1, Step 4. Retain the SPN information for use in Task 5. 316 Security Administration

Appendix G: Setting up Kerberos Authentication on Unix Nodes Active Directory Setup Task 5: Run ktpass to Create the Kerberos Keys Ktpass is a Microsoft program that creates the encryption keys used by the Key Distribution Center (KDC), an integrated part of Active Directory, to negotiate KRB5 or SPNEGO logon transactions between the client and Teradata Database. Run ktpass once for each Teradata Database node SPN created in Task 4. Note that the procedure for the first node is different than that required for all additional nodes. Once the keys are complete, you must copy the keytab files to a temporary location on the Teradata Database system, as shown in Task 6: Move the Kerberos Keys to the Teradata Database System on page 318. Generating the Key for the First Node Use the following form of the ktpass command to create the key for the first Teradata Database node: ktpass -princ <SPN> -mapuser <NodeName> -pass <Password> -ptype KRB5_NT_PRINCIPAL -out <KeytabFileName> where: ktpass Command Segment SPN Node Name Password -ptype KRB5_NT_PRINCIPAL Keytab File Name Description The Service Principal Name for a Teradata Database node. The name of the a Teradata Database node created in Task 1, Step 4, for example, node1-1. Password for the user represented by the node name. Use the password assigned to the node in Task 3, Step 7. Identifies the principal name type. The example value, KRB5_NT_PRINCIPAL,is the same for all systems and should always be entered exactly as shown in this example for all Unix Kerberos setups. The name of the Keytab file to which the keys will be written. Typically, it is the name of the Teradata Database system followed by.keytab. For example, for a system named TDAT1, the Keytab file would be named TDAT1.keytab. Note: The order in which the ktpass parameters appear is not important. Generating the Keys for Additional Nodes The ktpass command structure for Teradata Database nodes two through X is similar to the structure for the first node, with the addition of the -in parameter, as shown in the following example: ktpass -princ <SPN> -mapuser <NodeName> -pass <Password> -ptype KRB5_NT_PRINCIPAL -out <KeytabFileName> -in <KeytabFileName> where the value for the -in parameter is the name of the same keytab file used for the -out parameter in the first node set up. Security Administration 317

Appendix G: Setting up Kerberos Authentication on Unix Nodes Active Directory Setup Example: Ktpass Commands for a Two Node Setup The following example shows the ktpass commands required for setting up a Teradata Database system containing two nodes, node1-1 and node1-2. ktpass command for node1-1: ktpass -princ TERADATA/node1-1.corp.teradata.com@CORP.XYZ.COM -mapuser node1-1 -pass a$2tya3 -ptype KRB5_NT_PRINCIPAL -out Node.keytab ktpass command for node1-2: ktpass -princ TERADATA/node1-1.corp.teradata.com@CORP.XYZ.COM -mapuser node1-1 -pass a$2tya3 -ptype KRB5_NT_PRINCIPAL -out Node.keytab in Node.keytab Note: If your system has more than one directory, and the directories inhabit separate domains, you must generate separate keytab files with separate file names for each directory. For systems with more than two nodes, you may find it useful to incorporate the ktpass commands into a script. If your site requires frequent password changes, be sure to express the password as a script parameter, where it only needs to be changed once, rather than embedding it in the -pass for each node. Note: Do not use the password in the ktpass example shown above. Task 6: Move the Kerberos Keys to the Teradata Database System After completing the generation of Kerberos keys, securely transfer the keytab files from the Active Directory server to a temporary location on one of the Teradata Database nodes. Note: If your system has more than one directory, and the directories inhabit separate domains, make sure you move all the keytab files for all directories to the Teradata Database system. File the copies of the keytab files in the /tmp directory or some other temporary location. The keys will be installed in a permanent location as part of a later setup step, Task 10: Install the Kerberos Keys on page 327. Note: Do not copy the keys to the final destination at this point in the process, because they could destroy any other keys that may already reside on the system! 318 Security Administration

Appendix G: Setting up Kerberos Authentication on Unix Nodes Teradata Database Node Setup Teradata Database Node Setup Execute the following procedures on Teradata Database nodes running on Unix to prepare for use of external authentication using the KRB5 or SPNEGO mechanism. 1 Task 7: Install Kerberos on All Teradata Database Nodes 2 Task 8: Setup krb5.conf Kerberos Configuration File 3 Task 9: Verify That a Unix Node Can Find the Name Server 4 Task 10: Install the Kerberos Keys Note: If Teradata Database users will be authenticated by multiple Active Directory servers, duplicate this setup procedure on each directory server. 5 Task 11: Synchronize Time Between the Domain and the Nodes 6 Task 12: Check the Kerberos Synchronization Setup Task 7: Install Kerberos on All Teradata Database Nodes Kerberos is included as part of the standard Windows installation, so no additional installation is required to support single sign-on when Teradata Database runs on Windows. The following sections provide information on proper installation of Kerberos on Teradata Database systems running MP-RAS 3.03 or SUSE Linux Enterprise Server 10. Installing Kerberos on MP-RAS Nodes For systems running on MP-RAS 3.03, MIT Kerberos version 1.4.3 or later must be installed on every node as a single package called "kerberos". The Kerberos package is not provided on the Teradata Database CD or DVD, but is available from the Teradata Software Server (TSS). Kerberos installation is a normal part of installing or upgrading Teradata Database. For installation details, refer to Teradata Database installation or upgrade documentation. The default location for Kerberos is /usr/local/lib. If you need to use an alternate location, use the procedure shown in Optional Site-Specific Installation of Kerberos on page 320. Verify the Kerberos installation by running pkginfo from the command prompt, as follows: tdsec2:/ > pkginfo -l kerberos PKGINST: kerberos NAME: Kerberos authentication system CATEGORY: utilities ARCH: x86 VERSION: 01.04.03.00 VENDOR: Teradata Corporation PSTAMP: si650:bd185002:060911151727 INSTDATE: Feb 15 2007 11:51 AM STATUS: completely installed FILES: 153 installed pathnames 13 shared pathnames 21 directories 27 executables 16055 blocks used (approx) Security Administration 319

Appendix G: Setting up Kerberos Authentication on Unix Nodes Teradata Database Node Setup Installing Kerberos on SUSE Linux Enterprise Server 10 Nodes On SUSE Linux Enterprise Server 10 nodes, MIT Kerberos version 1.4.3 or later must be installed in the form of two packages called "krb5" and "krb5-client." These packages are supplied as part of the standard SUSE Linux Enterprise Server 10 operating system DVD. Note: The Unix Kerberos feature will not function on SUSE Linux Enterprise Server 9, and the MIT Kerberos package is not included on SUSE Linux Enterprise Server 9 DVDs. Installation of Kerberos is a standard part of the procedure for installing or upgrading to Teradata Database on SUSE Linux Enterprise Server 10 or higher. For installation details, refer to Teradata Database installation or upgrade documentation. The default location for Kerberos is: /usr/lib64. If you need to install Kerberos to an alternate location, use the procedure shown in Optional Site-Specific Installation of Kerberos on page 320. You can verify that Kerberos is installed on your system before proceeding with subsequent setup procedures by running rpm from the command prompt, as follow: # rpm -aq grep krb krb5-1.4.3-19.2 krb5-client-1.4.3-19.2 The krb5 entry reflects the installed version of Kerberos. Optional Site-Specific Installation of Kerberos The default installation directories for Kerberos are listed in the previous sections. If the default location is not suitable and you want to install Kerberos in a different directory, then you must also update the TdgssUserConfigFile.xml (once Kerberos is installed to the alternate location) so that the config file can access the Kerberos library libgssapi_krb5.so. Edit the TdgssUserConfigFile.xml as follows only if you have installed Kerberos to other than the default location: 1 In the section of the TdgssUserConfigFile.xml that defines the KRB5 and SPNEGO mechanism configurations, find the line that shows the current (default) location: <RequiredLibrary Path="/usr/local/lib/libgssapi_krb5.so"/> 2 Change the path to show the new file location. 3 Run run_tdgssconfig to replace the old configuration. 4 Run tpareset -f to activate the changes. For detailed information about editing the TdgssUserConfigFile.xml, see Making Changes to the User Configuration Files on page 195. Task 8: Setup krb5.conf Kerberos Configuration File The krb5.conf Kerberos configuration file requires a special setup on each Unix node. The sample krb5.conf file is located by default in the /etc directory. The examples below show the structure of the krb5.conf file. The table following each example provides an explanation of the sections and tags shown. The examples contain all the tags required for use of Kerberos authentication with Teradata Database on Unix, as well as a few other tags that are strongly recommended, but not required. 320 Security Administration

Appendix G: Setting up Kerberos Authentication on Unix Nodes Teradata Database Node Setup For more detailed information on MIT Kerberos sections and tags, see the following web site: http://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.3/doc/krb5-admin/krb5.conf.html Note: MIT Kerberos contains a number of additional sections and tags not required for Teradata Database Unix nodes. Teradata recommends that you not use these options for Unix Kerberos implementation unless it is absolutely necessary and you have fully researched their effects. Note: The following examples are for reference only! They must be reconfigured to reflect the actual domain, realm, and logging information for your system. Example 1: krb5.conf on MP-RAS [libdefaults] default_realm = <DefaultKerberosRealm> [realms] <DefaultKerberosRealm> = { kdc = <KDCHostFQDN> <AdditionalKerberosRealm> = } kdc = <AdditionalKDCHostFQDN> [domain_realm] <HostDNSDomain> = <KerberosRealm> <HostFQDN> = <KerberosRealm> [logging] default = FILE:/tmp/krb5lib.log Explanation of Example 1 The following table explains the terms used in the krb5.conf file shown in Example 1. Section, TagName, and TagValue [libdefaults] default_realm = <DefaultKerberosRealm> [realms] Description Contains the default values to be by the Kerberos library for authenticating a logon. The realm that contains the Kerberos logon, including both the KDC host (Windows domain controller) and the Teradata Database nodes. For example: SUBDOMAIN.DOMAIN.COM Note: The realm information must match the Windows domain name exactly. Contains subsections keyed by Kerberos realm names. Each subsection describes realm specific information, including where to find the Kerberos servers for that realm. Security Administration 321

Appendix G: Setting up Kerberos Authentication on Unix Nodes Teradata Database Node Setup Section, TagName, and TagValue <DefaultKerberosRealm> = { kdc = <KDCHostFQDN> <AdditionalKerberosRealm> = } kdc = <AdditionalKDCHostFQDN> [domain_realm] <HostDNSDomain> = <KerberosRealm> Description Required. The realm that contains the KDC host and the Teradata database nodes. For example: SUBDOMAIN.DOMAIN.COM Use the default_realm value from [libdefaults], must match the default Kerberos realm exactly. Required. The FQDN of the KDC host. For example: hostname.subdomain.domain.com Note: The KDC host is a Domain Controller for the Windows domain. Required if realms other than the default Kerberos realms contain functioning KDC hosts. For instance: ALTSUBDOMAIN.DOMAIN.COM Specify the realm according to the rules for default_realm shown above. Required if there is an additional KDC host. The FQDN of the additional KDC host. For example: additionalhostname.subdomain.domai n.com Note: The KDC host is an alternate Domain Controller for the Windows domain. Contains relationships that map DNS domains and host FQDNs to Kerberos realm names. These mappings determine a host realm location by its FQDN. Required. Maps the DNS domain containing one or more hosts (Teradata Database nodes), for instance,.subdomain.domain.com to the Kerberos realm, for instance, SUBDOMAIN.DOMAIN.COM The leading dot in the <HostDNSDomain> expression indicates that the expression maps all hosts resident in the domain to the Kerberos realm. Note: Specification of the DNS domain is in lower case. Specification of the Kerberos realm is case sensitive, and must exactly match the Windows domain. 322 Security Administration

Appendix G: Setting up Kerberos Authentication on Unix Nodes Teradata Database Node Setup Section, TagName, and TagValue <HostFQDN> = <KerberosRealm> Description Required. Maps a specific host FQDN (Teradata Database node), for instance: subdomain.domain.com to the Kerberos realm, for instance: SUBDOMAIN.DOMAIN.COM The lack of a leading dot in the <HostFQDN> expression indicates that the expression maps only the host with the exact specified FQDN to the Kerberos realm. Note: Specification of the DNS domain is in lower case. Specification of the Kerberos realm is case sensitive, and must exactly match the Windows domain. [logging] default = FILE:/tmp/ krb5lib.log Contains instructions for the location of Kerberos logging. Recommended. The location of the default Kerberos log on the node. Note: Express the file location in one of two ways: Using File: appends each new log entry to the existing log file. Using File= overwrites the previous log. Example 2: krb5.conf on SUSE Linux Enterprise Server 10 [libdefaults] default_realm = <DefaultKerberosRealm> clockskew = <AllowableSkew> [realms] <DefaultKerberosRealm> = { kdc = <KDCHostFQDN> <AdditionalKerberosRealm> = } kdc = <AdditionalKDCHostFQDN>} [domain_realm] <HostDNSDomain> = <KerberosRealm> <HostFQDN> = <KerberosRealm> [logging] kdc = FILE:/tmp/krb5kdc.log [appdefaults] pam = { ticket_lifetime = <Duration> renew_lifetime = <Duration> forwardable = <True/False> proxiable = <True/False> retain_after_close = false Security Administration 323

Appendix G: Setting up Kerberos Authentication on Unix Nodes Teradata Database Node Setup } minimum_uid = 0 try_first_pass = true Explanation of Example 2 The following table explains the terms used in the krb5.conf file shown in Example 2. Section, TagName, and TagValue [libdefaults] default_realm = <DefaultKerberosRealm> clockskew = <AllowableSkew> [realms] <DefaultKerberosRealm> = { kdc = <KDCHostFQDN> <AdditionalKerberosRealm> = } Description Contains the default values to be by the Kerberos library for authenticating a logon. The realm that contains the Kerberos logon, including both the KDC host (Windows Domain Controller) and the Teradata Database nodes. For example: SUBDOMAIN.DOMAIN.COM Note: The realm information must match the Windows domain name exactly. The maximum allowable difference, in seconds, for time synchronization between Teradata Database and the client domain. The maximum suggested value is +/- 300 (five minutes). This value must be expressed as a whole, positive integer. Contains subsections keyed by Kerberos realm names. Each subsection describes realm specific information, including where to find the Kerberos servers for that realm. Required. The FQDN of the KDC host. For example: hostname.subdomain.domain.com Note: The KDC host is a Domain Controller for the Windows domain. Required. The FQDN of the KDC host. For example: hostname.subdomain.domain.com Note: The KDC host is a Domain Controller for the Windows domain. Required if realms other than the default Kerberos realms contain functioning KDC hosts. For instance: ALTSUBDOMAIN.DOMAIN.COM Specify the realm according to the rules for default_realm shown above. 324 Security Administration

Appendix G: Setting up Kerberos Authentication on Unix Nodes Teradata Database Node Setup Section, TagName, and TagValue kdc = <AdditionalKDCHostFQDN> [domain_realm] <HostDNSDomain> = <KerberosRealm> <HostFQDN> = <KerberosRealm> [logging] Description Required if there is an additional KDC host. The FQDN of the additional KDC host. For example: additionalhostname.subdomain.domain.com Note: The KDC host is an alternate Domain Controller for the Windows domain. Contains relationships that map domains and subdomains onto Kerberos realm names. This determines a host realm location by its FQDN. Required. Maps the DNS domain containing one or more hosts (Teradata Database nodes), for instance,.subdomain.domain.com to the Kerberos realm, for instance, SUBDOMAIN.DOMAIN.COM The leading dot in the <HostDNSDomain> expression indicates that the expression maps all hosts resident in the domain to the Kerberos realm. Note: Specification of the DNS domain is in lower case. Specification of the Kerberos realm is case sensitive, and must exactly match the Windows domain. Required. Maps a specific host FQDN (Teradata Database node), for instance: subdomain.domain.com to the Kerberos realm, for instance: SUBDOMAIN.DOMAIN.COM The lack of a leading dot in the <HostFQDN> expression indicates that the expression maps only the host with the exact specified FQDN to the Kerberos realm. Note: Specification of the host FQDN is case sensitive. Specification of the Kerberos realm is not case sensitive, but must exactly match the Windows domain. Contains instructions for Kerberos logging. Security Administration 325

Appendix G: Setting up Kerberos Authentication on Unix Nodes Teradata Database Node Setup Section, TagName, and TagValue default = FILE:/tmp/krb5lib.log [appdefaults] pam = { ticket_lifetime = <Duration> renew_lifetime = <Duration> forwardable = <True/False> Description Recommended. The location of the default Kerberos log on the KDC host. Note: The file location can be expressed one of two ways: Using File: appends each new log entry to the existing log file. Using File= overwrites the previous log entry. Each tag specified in the [appdefaults] section specifies an application or option. The value of each tag defines the behavior of the owning application. Identifies the start of a list of settings for the PAM application, which defines some security policy and is installed as part of the SUSE Linux Enterprise Server 10 operating system software. Do not change any of the settings in this list. proxiable = <True/False> retain_after_close = false minimum_uid = 0 try_first_pass = true Guidelines for Configuring krb5.conf The examples provided must be modified to conform to the requirements of individual systems. In addition, if a krb5.conf file previously existed, be careful that changes do not negatively impact any existing Kerberos configuration. Execute a Kerberos Logon to Test the krb5.conf Setup After completing the setup of the krb5.conf Kerberos configuration file, execute a Kerberos logon to test whether or not the file has been set up correctly. Start by executing a Kerberos logon from a Teradata Database TPA node, using the command kinit as shown in the following example: > kinit <domain_user_name> Password for <domain_user_name>@esrootdom.esdev.tdat: Enter the network password when prompted. When all the setup tasks are complete, logon from a Teradata client to ensure that all setup parameters have been executed correctly. 326 Security Administration

Appendix G: Setting up Kerberos Authentication on Unix Nodes Teradata Database Node Setup Task 9: Verify That a Unix Node Can Find the Name Server Verify that Teradata Database nodes can find the Name Server, by running the following from any node: nslookup <AnyOtherNodeName> The nslookup will fail if the node is not able to find the Name Server. For both MP-RAS and SUSE Linux Enterprise Server 10, nslookup verifies that the /etc/resolv.conf file is set up properly, as shown in the following example: domain esrootdom.esdev.tdat search esrootdom.esdev.tdat nameserver 141.206.3.8 In addition, for MP-RAS only, nslookup also verifies that /etc/netconfig is set up properly, similar to the following example: # # The Network Configuration File. # # Each entry is of the form: # # network_id semantics flags protofamily protoname device nametoaddr_libs # ticlts tpi_clts v loopback - /dev/ticlts / usr/lib/straddr.so ticots tpi_cots v loopback - /dev/ticots / usr/lib/straddr.so ticotsord tpi_cots_ord v loopback - /dev/ticotsord / usr/lib/straddr.so tcp tpi_cots_ord v inet tcp /dev/tcp /usr/lib/ tcpip.so,/usr/lib/resolv.so udp tpi_clts v,b inet udp /dev/udp /usr/lib/ tcpip.so,/usr/lib/resolv.so rawip tpi_raw - inet - /dev/rawip /usr/lib/ tcpip.so,/usr/lib/resolv.so icmp tpi_raw - inet icmp /dev/icmp /usr/lib/ tcpip.so,/usr/lib/resolv.so Task 10: Install the Kerberos Keys In order for the Teradata Database system to accept the Kerberos authentication, you must install the Kerberos keys generated from the KDC in a preceding step on each Teradata Database node. The Kerberos Key install process is composed of the following elements: Check the Nodes for Existing Kerberos Keys Install Kerberos Keys on Nodes with Existing Keys (if Necessary) Standard Kerberos Key Installation (No Previously Existing Keys) Check the Nodes for Existing Kerberos Keys It is unlikely that there are other Kerberos keys configured on most Teradata Database nodes, but it is important to check, because any existing keys could be destroyed during the installation of new keys. Security Administration 327

Appendix G: Setting up Kerberos Authentication on Unix Nodes Teradata Database Node Setup Use the pcl command klist -ke to display Kerberos keys on all the nodes in a system: pcl -s klist -ke Pre-existing Kerberos keys will appear as shown in the following example of a two node system (keys shown in bold): l3592:/ > pcl -s klist -ke All 2 node(s) have connected <--------------------- valeris2_bynet -------------------------------> Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---------------------------------------------------------------------- 14 TERADATA/l3592.esrootdom.esdev.tdat@ESROOTDOM.ESDEV.TDAT (DES cbc mode with RSA-MD5) 13 TERADATA/l3593.esrootdom.esdev.tdat@ESROOTDOM.ESDEV.TDAT (DES cbc mode with RSA-MD5)<--------------------- valeris1_bynet ---------- ---------------------> Keytab name: FILE:/etc/krb5.keytab KVNO Principal ----------------------------------------------------------------------- 14 TERADATA/l3592.esrootdom.esdev.tdat@ESROOTDOM.ESDEV.TDAT (DES cbc mode with RSA-MD5) 13 TERADATA/l3593.esrootdom.esdev.tdat@ESROOTDOM.ESDEV.TDAT (DES cbc mode with RSA-MD5)-------------------------------------------------- --------------------- If no keys are present, the output will appear without the key entries, as follows: l3592:/ > pcl -s klist -ke All 2 node(s) have connected <--------------------- valeris2_bynet -------------------------------> Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- ------------------------------------------------------------------ <--------------------- valeris1_bynet -------------------------------> Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- ------------------------------------------------------------------ Once you have run pcl -s klist -ke to detect pre-existing keys, do one of the following: If pre-existing keys are detected: If you want to save the pre-existing keys, use the procedure shown in Install Kerberos Keys on Nodes with Existing Keys (if Necessary) on page 329. This procedure will merge the two key sets so all keys are usable. If do not want to save the detected keys, use the procedure shown in Standard Kerberos Key Installation (No Previously Existing Keys) on page 329, which will overwrite any existing keys. A typical use of this alternative is when site security policy requires that Kerberos keys be replaced at regular intervals to enhance security. If pre-existing keys are not detected, use the procedure shown in Standard Kerberos Key Installation (No Previously Existing Keys) on page 329. 328 Security Administration

Appendix G: Setting up Kerberos Authentication on Unix Nodes Teradata Database Node Setup Note: Regardless of the key installation procedure you choose, if Teradata Database users will be authenticated by more than one directory, and the directories are in separate domains (that is, they are not simply backup directory servers), you must install a set of keytab files for each directory server. If your site requires the installation of multiple keytab files, make sure that each file has a unique KeytabFileName. Install Kerberos Keys on Nodes with Existing Keys (if Necessary) If you discover that other Kerberos keys already exist on a node and you need to continue using the existing keys, Use the Kerberos utility ktutil to merge old and new keys, rather than over-writing them, as shown in the example that follows. For more detailed information on ktutil, see the ktutil man page on the Unix node. Note: This procedure assumes the Keytab file is in the standard location /etc/ krb5.keytab. You must execute the procedure on each Unix node. 1 Run ktutil from the Teradata Command prompt by entering: ktutil 2 At the ktutil prompt, enter the command to read the current keys: rkt /etc/krb5.keytab 3 Enter the command to read the new keys: rkt /tmp/<keytabfilename> 4 List all keys to verify by entering: list 5 Save all keys by entering: wkt /etc/krb5.keytab 6 Type quit. Standard Kerberos Key Installation (No Previously Existing Keys) If there are no Kerberos keys already present on the node, then copy and distribute the Keytab file from the KDC, which was previously stored on one of the Teradata Database nodes in a temporary location, to the permanent location on all nodes. Note: The following procedures assume the Keytab File location is /tmp/krb5.keytab. For single node systems: 1 Log on to Teradata Database. 2 Copy the temporary Keytab file to the permanent location by entering: cp /tmp/<keytabfilename> /etc/krb5.keytab For multi-node systems: 1 Log on to the Teradata Database node that has the temporary Keytab File. 2 From the command prompt, distribute the temporary Keytab file to all nodes, using the following pcl command: pcl -send /tmp/<keytabfilename> /etc 3 Verify that the Kerberos Keys have been correctly installed by displaying a list: Security Administration 329

Appendix G: Setting up Kerberos Authentication on Unix Nodes Teradata Database Node Setup pcl -s klist -ke Task 11: Synchronize Time Between the Domain and the Nodes Kerberos requires synchronization of the time and date across the domain. The most efficient method is to use a time synchronization package, such as Network Time Protocol (NPT), to synchronize the nodes to the Windows Domain Controller that acts as the Kerberos Key Distribution Center (KDC). For further information on NTP, see the following web site: http://www.ntp.org Note: Time synchronization procedure vary depending on whether the Teradata Database nodes run on MP-RAS or SUSE Linux Enterprise Server. Time Synchronization for MP-RAS Nodes The procedure shows how to execute time synchronization for MP-RAS nodes, using npt, is as follows: 1 Navigate to the /etc/inet file and find the sample NPT configuration file, npt.conf. The sample configuration file looks something like the following: # ntp.conf - Sample config file for xntpd #server 141.206.35.140 #peer 192.35.53.2 #peer 192.35.53.29 #peer 192.35.52.14 #peer 192.35.54.106 #driftfile /etc/inet/ntp.drift #keys /etc/inet/ntp.keys #requestkey 30 #controlkey 30 2 Copy the sample from step 1 and uncomment the lines containing ntp.conf, driftfile, and server. 3 On the "server" line, substitute the IP address for the Windows Domain Controller to which the Teradata Database will be synchronized, and add additional "server" lines for any other Domain Controllers that will act as additional KDCs. 4 Change the file description shown in the first line to indicate that it is a real configuration file and not the sample. The resulting file will look something like the following: # ntp.conf - Config file for xntpd server 141.206.35.140 peer 192.35.53.2 peer 192.35.53.29 #peer 192.35.52.14 #peer 192.35.54.106 driftfile /etc/inet/ntp.drift #keys /etc/inet/ntp.keys #requestkey 30 #controlkey 30 Note: Make sure to enter data that is valid for your system in all uncommented lines! 5 Save the ntp.conf file 330 Security Administration

Appendix G: Setting up Kerberos Authentication on Unix Nodes Teradata Database Node Setup 6 To initiate the synchronization, enter the following: in.xntpd 7 The synchronization process will take a few minutes to complete. To view the sequence as it takes place, enter the following: ntpq -p The system will output something like the following: tdsec2:/ > ntpq -p remote refid st t when poll reach delay offset disp ===================================================================== esroot.locl. 1 u 8 64 7 0.00-8.757 3883.22 8 Check the log file to make sure that all the identified directory servers have been synchronized. The log file will look something like the following example: Aug 1 14:05:56 in.xntpd[139]: xntpd version=3.4x (beta multicast); Wed Dec 6 10:53:29 CST 1995 (1) Aug 1 14:05:56 in.xntpd[139]: tickadj = 10000, tick = 10000, tvu_maxslew = 970000 Aug 1 14:05:56 in.xntpd[139]: precision = 10000 usec Aug 1 14:05:56 in.xntpd[139]: bind() fd 4, family 2, port 123, addr 00000000, in_classd=0 flags=1 fails: Address already in use Aug 1 14:08:20 in.xntpd[80]: synchronized to 141.206.35.140, stratum=1 An entry appears for each synchronized directory server (identified by its IP address), as shown in the last line of log file. 9 Once the Teradata Database server is synchronized with all necessary directory servers, enter the following to view the setup: tdsec2:/etc/inet > ls -l ntp* -r--r--r-- 1 root other 235 Jul 18 16:43 ntp.conf -r--r--r-- 1 root other 235 May 18 18:00 ntp.conf.sample -rw-r--r-- 1 root other 9 Jul 25 23:37 ntp.drift -r--r--r-- 1 root other 1325 May 18 18:00 ntp.samplekeys tdsec2:/etc/inet > Time Synchronization for SUSE Linux Enterprise Server Nodes The procedure shows how to execute time synchronization for SUSE Linux Enterprise Server nodes, using npt, is as follows: 1 Navigate to the /etc file and find the sample NPT configuration file, npt.conf. The sample configuration file looks something like the following: # server 127.127.8.0 mode 5 prefer ## ## Undisciplined Local Clock. This is a fake driver intended for backup ## and when no outside source of synchronized time is available. ## #server 127.127.1.0 # local clock (LCL) #fudge 127.127.1.0 stratum 10 # LCL is unsynchronized ## ## Outside source of synchronized time ## Security Administration 331

Appendix G: Setting up Kerberos Authentication on Unix Nodes Teradata Database Node Setup ## server xx.xx.xx.xx #IP address of server ## ## Miscellaneous stuff ## #driftfile /var/lib/ntp/drift/ntp.drift # path for drift file #logfile /var/log/ntp # alternate log file # logconfig =syncstatus + sysevents # logconfig =all # statsdir /tmp/ # directory for statistics files # filegen peerstats file peerstats type day enable # filegen loopstats file loopstats type day enable # filegen clockstats file clockstats type day enable # # Authentication stuff # # keys /etc/ntp.keys # path for keys file # trustedkey 1 2 3 4 5 6 14 15 # define trusted keys # requestkey 15 # key (7) for accessing server variables # controlkey 15 # key (6) for accessing server variables 2 Copy the sample from step 1 and uncomment the lines containing driftfile and server. 3 On the "server" line, substitute the IP address for the Windows Domain Controller to which the Teradata Database will be synchronized, and add additional "server" lines for any other Domain Controllers that will act as additional KDCs. 4 The following shows an example of a configured file: ## server 127.127.8.0 mode 5 prefer ## ## Undisciplined Local Clock. This is a fake driver intended for backup ## and when no outside source of synchronized time is available. ## #server 127.127.1.0 # local clock (LCL) #fudge 127.127.1.0 stratum 10 # LCL is unsynchronized ## ## Outside source of synchronized time ## server 141.206.3.8 # IP address of server ## ## Miscellaneous stuff ## driftfile /var/lib/ntp/drift/ntp.drift # path for drift file # logfile /var/log/ntp 332 Security Administration

Appendix G: Setting up Kerberos Authentication on Unix Nodes Teradata Database Node Setup # alternate log file # logconfig =syncstatus + sysevents # logconfig =all # statsdir /tmp/ # directory for statistics files # filegen peerstats file peerstats type day enable # filegen loopstats file loopstats type day enable # filegen clockstats file clockstats type day enable # # Authentication stuff # # keys /etc/ntp.keys # path for keys file # trustedkey 1 2 3 4 5 6 14 15 # define trusted keys # requestkey 15 # key (7) for accessing server variables # controlkey 15 # key (6) for accessing server variables Note: Make sure to enter data that is valid for your system in all uncommented lines! 5 Save the ntp.conf file 6 To initiate the synchronization, enter the following: tdgs21:/ # /etc/init.d/ntp start Start NTP automatically when system boots: tdgs21:/ # insserv /etc/init.d/ntp 7 The synchronization process will take a few minutes to complete. To view the sequence as it takes place, enter the following: ntpq -p The system will output something like the following: tdgs21:/ # ntpq -p remote refid st t when poll reach delay offset jitter ===================================================================== *tusday700.td.te.gps. 1 u 896 1024 377 77.267 5.317 0.193 LOCAL(0) LOCAL(0) 10 l 38 64 377 0.000 0.000 0.001 8 Check the log file to make sure that all the identified directory servers have been synchronized. The log file will look something like the following example: Oct 16 12:42:55 tdgs21 ntpd[12387]: ntpd 4.2.0a@1.1213-r Tue Nov 8 17:39:08 UTC 2005 (1) Oct 16 12:42:55 tdgs21 ntpd[12387]: precision = 1.000 usec Oct 16 12:42:55 tdgs21 ntpd[12387]: Listening on interface wildcard, 0.0.0.0#123 Oct 16 12:42:55 tdgs21 ntpd[12387]: Listening on interface wildcard, ::#123 Oct 16 12:42:55 tdgs21 ntpd[12387]: Listening on interface lo, 127.0.0.1#123 Oct 16 12:42:55 tdgs21 ntpd[12387]: Listening on interface eth0, 141.206.28.199#123 Oct 16 12:42:55 tdgs21 ntpd[12387]: kernel time sync status 0040 An entry appears for each synchronized directory server (identified by its IP address), as shown in the last line of log file. Security Administration 333

Appendix G: Setting up Kerberos Authentication on Unix Nodes Teradata Database Node Setup 9 Once the Teradata Database server is synchronized with all necessary directory servers, enter the following to view the setup: tdgs21:/etc/> ls -l ntp* -r--r--r-- 1 root other 235 Jul 18 16:43 ntp.conf tdgs21:/etc/> ls -l ntp* Task 12: Check the Kerberos Synchronization Setup Once the process for synchronizing one or more Teradata Database systems with related directory servers is complete, two utilities are available for verifying that the configuration functions properly. kinit Each time there is a restart of the Teradata Database system, the time must be re-synchronized with the directory serer. To insure that this will happen, use the kinit utility to verify that the Teradata system user in the directory can log on and communicate with the database. 1 Log on to run the kinit utility. tdsec4:/keytab>kinit tdsec4 Password for tdsec4@esrootdom.esdev.tdat: <enter password> tdsec4:/keytab 2 Run klist to see if a ticket has been issued. Input: tdsec4:/keytab>klist -c Output: Ticket cache: File:/temp/krb5cc_0 Default principal:tdsec4@esrootdom.esdev.tdat Valid starting Expires Service Principal 09/20/06 11:47:23 09/20/06 21:48:04 krbtgt/ ESROOTDOM.ESDEV.TDAT@ESROOTDOM.ESDEV.TDAT renew until 9/21/06 11:47:23 Kerberos 4 ticket cache: /tmp/tkt() klist: You have no tickets cached tdsec4:/keytab> Klist -e: Credentials Cache and Encryption Type Use klist -e to check the tickets in the credentials cache and the type of encryption the credentials use. Input: tdsec4:/keytab>klist -e Output: Ticket Cache: File:/tmp/krb5cc_0 Default principal: tdsec4@esrootdom.esdev.tdat Valid Starting Expires Service Principal 09/20/06 11:47:23 09/20/06 21:48:04 334 Security Administration

Appendix G: Setting up Kerberos Authentication on Unix Nodes Teradata Database Node Setup krbtgt/esrootdom.esdev.tdat@esrootdomesdev.tdat Security Administration 335

Appendix G: Setting up Kerberos Authentication on Unix Nodes Teradata Database Node Setup 336 Security Administration

APPENDIX H Controlling User Access by IP Address This appendix covers the elements and operations necessary to implement control of user access using IP address restrictions. Additional information on configuration tasks required for implementing IP restrictions in a directory appears in Creating Containers and Inserting Objects on page 266, and Mapping Directory Users to Teradata Database Objects on page 269. Principals of IP AccessRestriction Usage Constraints IP restrictions are enforced by the Teradata Gateway based on information contained in a globally distributed object (GDO). Restrictions are based on: Filters that define the IP addresses to which database access is allowed or denied A list of users that are effected by each filter The information in the GDO originates in one of two sources, but only one set of restrictions can be operational at a time: You can define IP restrictions in the database by creating an XML document file that contains the restrictions and then importing the file into the GDO using the ipxml2bin conversion utility. You can define IP restrictions in a supported directory by loading Teradata Database schema extensions into the directory, populating the directory information tree with restriction-related schema objects, and then importing the restrictions from the directory into the GDO using the ipdir2bin conversion utility. Each of these methods requires the administrator to perform related setup operations. When the setup is complete, the Gateway screens each logon to the database and allows or denies the logon according to the IP restrictions in the GDO. If no IP restrictions exist, the database will allow logons to qualified users from any IP address. Restricting user access by IP address is subject to the following constraints: Systems that employ DIGEST-MD5 binding (the default), and also use Active Directory or ADAM, require additional setup procedures for configuring IP address restriction that are Security Administration 337

Appendix H: Controlling User Access by IP Address Principals of IP AccessRestriction Ensuring Security not covered in this appendix. These additional requirements apply only for IP restrictions of directory-based users. Set the LDAP mechanism LdapServerName property in one of the following ways: Use the DNS to locate the LDAP service (preferred), as follows: LdapServerName="_ldap._tcp.td.teradata.com" Name at least two directory servers, including their domain, as follows: LdapServerName="ldap://sussan140.td.teradata.com/ ldap://susday7541.td.teradata.com/" For information on setting the LdapServerName property, see LdapServerName on page 162 and Set up for LDAP Server Failover Protection on page 163. When multiple restrictions affect a user, the restrictions are cumulative; that is, if any restriction rejects the user, the user logon is not permitted. While there is no limit to the number of IP restrictions concurrently in effect, the database does limit the size of the GDO that contains the limits to 128 KB. This is true for both XML and directory implementations. With adequate planning, IP restrictions should easily fit within the 128KB limit for most systems. The GDO can contain dozens of filters and over 10,000 user names of 10 characters. Companies with very large user bases can save GDO space by employing the directorybased implementation of IP restrictions and mapping multiple directory users to a smaller number of Teradata Database users that have the same access restrictions. Only a single set of restrictions can exist at a time, either XML or directory based. If you want to make changes to the IP restrictions, revise the existing XML document or directory set up and then re-import the file into the GDO using the appropriate utility. The new restrictions will overwrite the old GDO. You must perform a restart to activate the initial IP restrictions. Subsequent changes to the restrictions do not require a restart. The presence of a middle-tier application between the IP address from which the user is logging on and the database prevents the effective use of IP restrictions. When such applications as Teradata Query Director, network address translation (NAT) devices, or other middleware are present, the Gateway sees only the IP address of the middleware, which is the only IP that can be restricted. If you add or alter an IP restriction that denies access to a user from an IP address through which the user has already logged on, the pre-existing session remains connected. The Gateway will deny the user access from that IP at the next logon. This rule holds true even if there is a reconnect of the pre-existing session because of a system restart. The list of names and valid IP addresses in the XML file, and the directory (if used), could represent a threat to your system. Be sure to limit to access only by trusted administrators. 338 Security Administration

Appendix H: Controlling User Access by IP Address Creating an XML IP Restriction Document Creating an XML IP Restriction Document To implement the IP access restrictions you must create an XML document that contains IP filters and links them to users. Before beginning to design IP restrictions for your system, observe the following: A template for creating IP filter XML documents is available in the /etc directory. For file locating /etc and other TDGSS files, see Locating TDGSS Files on page 129. The content of the IP XML document must be in accordance with the guidelines shown in the examples in the sections that follow this one. Once the restriction document is complete, you must import the document information into the IP restriction GDO using the ipxml2bin utility. The Gateway then uses the information in the GDO to process logons. Only one XML document can exist in Teradata Database at any time. Creating a second document and importing it will nullify the effects of the first. Note: As an alternative, you can create IP restriction objects in a supported directory. These objects and object attributes are functionally equivalent to the XML-based elements and element attributes described in the sections that immediately follow this one. For more information about directory-based IP restrictions, see Directory Implementation of IP Restrictions on page 359 and Chapter 9: Directory Management of Database Users. Saving the Completed XML IP Restriction Document When you complete you XML IP restriction document, be sure to save it as ipfilter.xml, to the /site directory, so it can be found and converted to GDO format by the ipxml2bin utility. For information on the ipxml2bin utility, see ipxml2bin on page 363. Designing IP Restrictions An XML IP restriction document defines the IP restrictions the Gateway will apply to users when they log on to the database. To do this, it must define the following: the Teradata Database system to which access is being restricted a list of all the Teradata Database users to which the IP filters defined in the document can can apply one or more IP filters that each identify: the type of filter, implying a set of processing rules an IP address or range of addresses that will be used to screen sources of incoming logons for possible restriction optional specification of one or more Teradata Database users to which the specific filter does apply Security Administration 339

Appendix H: Controlling User Access by IP Address Designing IP Restrictions IP Restriction Concepts Element Descriptions The IP restriction parameters can only be specified in an XML document by attaching the defining data to IP restriction elements. This section describes the elements that can appear in an XML IP restriction document. Most of them are mandatory. The element hierarchy is similar to that of the objects and attributes that must be placed in the directory information tree (DIT) when executing a directory implementation of IP restrictions. For information on how the comparable attributes appear in a directory-based implementation of IP restrictions, see Directory Implementation of IP Restrictions on page 359. The following example shows how IP restriction elements appear in an XML IP restriction document. Example: IP Restriction Elements in an XML Document <tdat name="tdat"> <system name="gizmo"> <users> <user name="drct01" tag="xyzzy"/> <user name="perm01" tag="noside"/> <user name="extuser" tag="shazam"/> </users> <ipfilters> <ipfilter name="filter1" type="restrictive"> <allow ip="141.206.0.0/255.255.0.0"/> <deny ip="141.206.35.0/255.255.255.0"/> <appliesto tagref="xyzzy"/> <appliesto tagref="shazam"/> </ipfilter> <ipfilter name="filter2" type="permissive"> <deny ip="141.206.35.0/255.255.255.0"/> <allow ip="141.206.35.175/255.255.255.255"/> <appliesto tagref="noside"/> <appliesto tagref="xyzzy"/> </ipfilter> </ipfilters> </system> </tdat> The following section describe the elements used an XML IP restriction document, such as the one shown in the previous example. tdat Use the tdat element to specify that the XML IP restriction document applies to Teradata Database systems and users. The tdat element defines a name attribute. There are no restrictions on the actual name value used for this attribute. 340 Security Administration

Appendix H: Controlling User Access by IP Address Designing IP Restrictions system Use the system element to identify the Teradata Database system to which you want to restrict access. A system element must always appear as a child of the tdat element. The system element defines a name attribute. In the interest of simplicity you can use the cn of the Teradata Database system, as assigned in the vconfig GDO, for this name attribute, but this approach is not required. For information on vconfig, see Utilities. If the XML IP restriction document contains multiple system elements, the Gateway will use only the first system element that appears in the document. users The users element must appear at the beginning and end of the list of Teradata Database users that can be affected by the filters defined in the document. Individual usernames are then added to the list, each with a separate user element. The users element must appear as a child of a system element. The XML document may contain as many users elements as needed, but only one appearance is typical. The users element does not require a value. If no individual user elements are specified as children of the users element, the filter is applied to all users, as shown in Applying a Filter to All Users on page 358. user A user element describes a Teradata Database user that has been defined in the database using a CREATE USER statement. Each user element bears a name attribute and a tag attribute. The value assigned to the name attribute is a Teradata Database username. The value of the tag attribute is a string that is unique to the entire XML document. The tag attribute provides a handle that other objects/elements can reference, such as the appliesto element, which links individual user elements to an IP filter. ipfilters An ipfilters element marks both the beginning and end of a list of individual IP filters contained in the XML IP restriction document. Each filter in the list is referenced using an ipfilter element. Use this element only as a child of a system element. You can use as many ipfilters elements as needed in the XML IP restriction document, however, only one list of filters is typical. ipfilter The ipfilter element corresponds to an IP filter. The element has two attributes, name and type. The name is an arbitrary name that has no intrinsic meaning except as a placeholder, and to differentiate one filter from another. The type attribute can contain either of two values, restrictive or permissive, depending on the intended function of the filter. Security Administration 341

Appendix H: Controlling User Access by IP Address Designing IP Restrictions The ipfilter element can appear only as a child of an ipfilters element. Use as many ipfilter elements as necessary to define the active IP filters in an XML IP restriction document. allow The allow element contains an ip attribute, composed of an ip value and a mask value, separated by a slash (/). If the result of the incoming IP address ANDed with the mask matches the result of the address in the allow element ANDed with the mask, the Gateway will allow the incoming IP address to access the database. The allow element can appear only as a child of an ipfilter element. You can use as many allow elements as needed in an XML IP restriction document. In cases where multiple allow elements appear, only one match is necessary to allow the session to proceed. deny The deny element contains an ip attribute, composed of an ip value and a mask value, separated by a slash (/). If the IP address of the incoming session ANDed with the mask matches the IP address of the deny element ANDed with the mask, the IP address of the incoming session is denied access. The deny element can appear only as a child of an ipfilter element. You can use as many deny elements as needed in the XML IP restriction document. When multiple deny elements appear, only one match is needed to deny the incoming IP address. appliesto The appliesto element contains the attribute tagref, which binds an IP filter to a user element that represents a Teradata Database user. The tagref value must exactly match the value of the tag attribute of the user element or the filter will not affect the user. The appliesto element can appear only as a child of an ipfilter element. IP Filters IP filters are the active components in an XML IP restriction document. They identify the IP addresses subject to restriction. Take care to understand effects of the filter elements and attributes and how they work together before attempting to design and build an IP filter. The following example shows a typical XML IP filter: <ipfilter name="filter1" type="restrictive"> <allow ip="141.206.0.0/255.255.0.0"/> <deny ip="141.206.35.0/255.255.255.0"/> <appliesto tagref="xyzzy"/> </ipfilter> Refer to the following table for brief explanations of the filter elements and attributes shown in the previous example. Cross references in the Description column lead to the more detailed explanations that appear in succeeding sections. 342 Security Administration

Appendix H: Controlling User Access by IP Address Designing IP Restrictions Filter Component <ipfilter name="filter1" type="restrictive"> <allow ip="141.206.0.0/ 255.255.0.0"/> <deny ip="141.206.35.0/ 255.255.255.0"/> Description Each filter definition begins (and ends) with an ipfilter element, which must be the child of an ipfilters element. The ipfilter element at the beginning of the filter definition must contain the name attribute and a corresponding value. In this case, the name is filter1. The ipfilter element must also identify the type of filter, either permissive or restrictive, using the type attribute. The filter type is very important, because it determines how the filter allow and deny elements will be processed. For a detailed explanation, see the sections on Permissive Filters on page 350 and Restrictive Filters on page 352. A restrictive filter must first define all the IP addresses that are allowed to log on, using the allow element. The allow element is composed of two parts: the allowed IP address range, in this example, 141.206.0.0 the mask, which defines how much of the allow IP address will be considered in determine the logons allowed to logon. For information about how the allow and deny elements affect both permissive and restrictive filters, see Effects of Filter Type on allow and deny Elements on page 344. For more information about masking, see the sections beginning with Addresses and Mask Structure on page 345 Restrictive filters also provide a way to define exceptions to the range of addresses specified in the allow element, using the deny element. The deny element is composed of two parts: the deny IP address or address range, in this example, 141.206.35.0 the mask, which defines how much of the IP address should be used to determine the logons allowed. For information about how the allow and deny elements function within a filter, see Effects of Filter Type on allow and deny Elements on page 344. For more information about masking, see the sections beginning with Addresses and Mask Structure on page 345. Security Administration 343

Appendix H: Controlling User Access by IP Address Designing IP Restrictions Filter Component <appliesto tagref="xyzzy"/> </ipfilter> Description The tagref value in each appliesto element links the filter to the user element with a matching tag attribute value, in this case the value is xyzzy. This link causes the rules for the IP filter to be applied to that user. Use an appliesto statement for each user the IP filter is to affect. For more information on applying IP filter effects to all users, see Applying a Filter to a User on page 355 and Applying a Filter to All Users on page 358. This IP filter element defines the end of the IP filter definition. Effects of Filter Type on allow and deny Elements Although it is not required, IP filters often contain both an allow and a deny element. One specifies the range of IP addresses to which the IP filter applies. The other defines exceptions within the range to which the filter does not apply. The filter type determines which element is the primary and which is the exception. Consider the functional relationship between the allow and deny elements from the previous example, a restrictive filter. Note how the allow and deny roles change in a permissive filter. <allow ip="141.206.0.0/255.255.0.0"/> <deny ip="141.206.35.0/255.255.255.0"/> Element function within the two filter environments is as follows: Filter Type Element Function Restrictive 1) allow Allows access to the specified IP address or address range. Remember, the true range depends on both the IP address and the mask. 2) deny Defines an exception to the address range specified in the allow element. This exception denies access to a specified IP address or address range that is a subset of the allowed address range. Permissive 1) deny Denies access to the specified IP address or range of addresses. 2) allow Defines an except to the address range specified in the deny element. This exception allows access to a specified IP address or address range that is a subset of the denied address or address range. 344 Security Administration

Appendix H: Controlling User Access by IP Address Designing IP Restrictions Addresses and Mask Structure How Masks Affect Filters The allow and deny elements define the affected IP addresses or address ranges within an IP filter. The address or address range must be stated together with a mask as a single allow or deny element masked IP value, in the following form: <allow ip="141.206.35.0/255.255.255.0"/> Within the quoted string, the specified IP is represented by the four decimal-separated segments preceding the first slash (/), each segment containing a number from 0 to 255. The mask is the four decimal-separated segments that follow the first slash (/). When the mask is ANDed with the specified IP, the result acts as an eight bit filter for the testing the sources of incoming logons. Masks tell the filter what part of an IP filter is important, informing the filter to what extent it must test an incoming IP address against IP restrictions in the allow and deny elements. If an element does not define a mask, the masking defers to the value 255.255.255.255, meaning that the incoming IP must match the filter IP exactly for the filter to have an effect. In the previous allow IP example the mask uses the value 255 in the first three decimalseparated segments (24 bits) to instruct the filter to consider the entire value of each of the corresponding segments of the specified IP. The segments are binary and the eight bits represent (from right to left) the first eight values in the binary sequence: 1, 2, 4, 8, 16, 32, 64, and 128, for a total value of 255. To consider only part of an IP binary segment, you can use a mask like the following: 255.255.192.0 /> Note that masking values are applied to the binary string from right to left. A value of 192 means that the mask will consider the two left to positions of the third binary segment, 128 and 64, which total 192. Partial segment masking can have complex effects on filter function. Before you try to use this type of masking, see Important Masking Properties on page 346. You can also use an alternate form of masking that states the mask in terms of the number of bits rather than the binary value of the bits. For example, express the mask as the number of binary bits (from left to right in the binary string) that must be considered. Using the bit method the 255.255.255.0 /> becomes 24 />, or three decimal-separated, eight bit segments. It is important to understand the detailed function of masking before employing it in an IP filter. When an IP filter encounters an incoming IP address as part of a logon, it automatically uses the following process to determine whether or not the IP address is allowed access to Teradata Database. Note: The following example is based on a typical allow element in a restrictive filter. If the filter also contains a deny element, evaluation of the incoming IP will continue until the deny parameters (which represent exceptions to the allow) are also applied. 1 Convert the specified IP in the primary element, for instance the allow element IP 141.206.35.0 in a restrictive filter, to a binary string: 10001101.11001110.00100011.00000000 Security Administration 345

Appendix H: Controlling User Access by IP Address Designing IP Restrictions 2 Convert the primary element mask, for instance 255.255.255.0, to a binary string: 3 AND the binary string representing the allow element IP with the mask to obtain the allow result (shown in bold): 10001101.11001110.00100011.00000000 11111111.11111111.11111111.00000000 10001101.11001110.00100011.00000000 4 Examine the incoming IP address and convert it to binary format; for instance, the incoming IP address 141.206.35.62 converts to the following binary string: 10001101.11001110.00100011.00111110 5 AND the binary incoming IP address with the allow element mask to obtain the incoming IP result (shown in bold): 10001101.11001110.00100011.00111110 11111111.11111111.11111111.00000000 10001101.11001110.00100011.00000000 6 Compare Incoming IP Result from Step 5 with the allow Result from Step 3 (for this example, they are equal). The filter will have the intended effect, in this case allowing the logon, if both of the following are true: The Incoming IP Result matches the allow Result The username in the logon is referenced in the appliesto element of the filter Note: The filter will continue on and test the incoming IP address against the secondary parameters, in this case, the deny portion of the filter. If the secondary testing denies the logon it will fail prevent access, even if the primary testing would have allowed the logon. Important Masking Properties In some cases, masking effects on specified IPs may not be readily apparent, and may only be discernible through a detailed analysis of the masking. For example, it is easy to understand why the masked IP141.206.0.0/16 in an allow element will allow IP address 141.206.35.62 to log on: The 0 that appears in the third and fourth decimal segments of the IP indicates that those segments are not significant to determining the source IPs from which logons will be allowed. The mask /16 says that only the first 16 bits of the allowed IP range must match exactly as shown for the allow to function. However, many companies might have an internal network divided up in such a way that it is necessary to mask it something like 141.206.0.0/13 to determine IP address allocations to a particular department. Such a mask, with a value not divisible by 8, includes many additional IP addresses beyond the 255 x 255 addresses represented by the 0 in segments three and four, because it also partially masks segment two. In order to properly apply IP filtering, you must consider the effects of the partial segment masking. 346 Security Administration

Appendix H: Controlling User Access by IP Address Designing IP Restrictions The following example helps to explain the effect of a partial segment mask on the content of the top level subnet address: AND the binary values of the subnet address with those of the mask: 10001101.11001110.00000000.00000000 (141.206.0.0) 11111111.11111000.00000000.00000000 (255.248.0.0 or /13) 10001101.11001000.00000000.00000000 (141.200.0.0) The result shows the first 13 digits in bold text to indicate that they must be present in any address allowed by the allow element. Note that the first 13 digits of the result match the first 13 digits of the original range. The remaining 19 digits are shown in normal text to indicate that they can be either a 0 or a 1 (in any combination), and will still be part of the subnet. Expressing all 19 digits as 1, while retaining the first 13 digits as shown in bold, results in the largest possible address in this subnet, or 10001101.11001111.11111111.11111111 (141.207.255.255). The total range of addresses in subnet 141.206.0.0/13 would include all addresses from 141.200.0.0 through 141.207.255.255. For some examples of how to apply partial segment masking to IP filters, see Example 3: Secondary Element Processing--Address Range Exception on page 348and Example 4: Secondary Element Processing--Carve Out Exception on page 349. Forms of Interaction Between Primary and Secondary Masked IPs Although it is not required, an IP filter may contain both an allow and a deny element. The interaction between the two element types (and their masks) depends on the type of filter they inhabit. The filter type determines which element is processed first (the primary). The primary element determines the basic rules by which the filter operates. The secondary element defines the exceptions to those rules. The following examples show the interaction between allow and deny elements. Note: These examples are for a restrictive filter. Masking principles for a permissive filter are similar, but the filter would test allow and deny elements in the opposite order. Example 1: Primary Element Processing The primary element is processed first and sets the overall rule the filter will use in evaluating the incoming IP address. The primary element usually specifies a range of IP addresses. In a restrictive filter, the allow is the primary element. Suppose the allow element allows the following range of IP addresses: <allow ip= 141.206.35.0/ Specifying this value for the element indicates that the filter will allow any IP address in the 141.206.35 subnet (possibly a department within a large company). Note that a 0 is used for the last segment rather than individually specifying each allowed address within the subnet. Security Administration 347

Appendix H: Controlling User Access by IP Address Designing IP Restrictions A user attempts to access the database from the following incoming IP address: 141.206.35.175 The filter allow element includes the following mask, which it uses to test the incoming IP: 155.255.255.0 /> The allow element mask has a 0 in the fourth decimal-separated segment, so only the first three segments of any incoming IP address will be tested. Since the first three segments of the mask have values of 255, the corresponding segments of the allow element and incoming IP address must match exactly for access to be allowed. Since the first three segments match, the logon is allowed. Note: The allow element would achieve the same results with the mask expressed as: 24 /> Filtering is not complete at this point if the filter also contains a deny element that must be processed. Example 2: Secondary Element Processing--Single Address Exception The secondary element is processed after the primary element, and represents an exception to the filter rule stated in the primary. In the example below, the secondary element specifies an individual address, contained within the range defined by the primary element, for exemption from the allow. Suppose the secondary element in a filter is a deny element that seeks to deny a single IP: <deny ip= 141.206.35.175/ The department in Example 1 above has constructed a single-address deny element to restrict the IP of a training computer that is not allowed direct access to the database. The following mask ensures that the filter will test all 32 bits of the address to enforce the deny restriction. 255.255.255.255 /> The deny processing for the incoming IP address will deny access even though the allow element has allowed it. This mask format indicates that all 32 bits of the address are significant, and is required because the denied IP address is unique only in the fourth decimal segment. Note that a mask of /32 > would achieve the same results. Example 3: Secondary Element Processing--Address Range Exception The secondary element can also specify an exception for a range of IP addresses that are contained within the larger range defined by the primary element. Suppose instead of a single IP address exception, you want to deny access to IP addresses for several non-essential departments in the company, using the following deny element: <deny ip= 141.206.35.255/ The company in Example 1 wants to deny access to only some of the workstations with IP addresses beginning with 141.206.35; in this case, workstations 141.206.35.192 through 141.206.35.255, in the Outside Sales. The deny element specified is equivalent to the following binary number: 10001101.11001110.00100011.11111111 348 Security Administration

Appendix H: Controlling User Access by IP Address Designing IP Restrictions Using 255 in the final segment of the deny IP is optional. Any number between 192 and 255 would give the same results, because of the mask construction, as shown in the following bullet. Use of the following mask forces the filter to deny access to all workstations with IP addresses from 141.206.35.192 through 141.206.35.255: 255.255.255.192 /> This mask format indicates that only the last two bits of the forth segment are significant. The ANDing of the binary values for deny IP and the mask illustrate why such a wide range of addresses is usable when specifying the forth segment of the deny IP. Deny IP 10001101.11001110.00100011.11111111 Mask 11111111.11111111.11111111.11000000 Result 10001101.11001110.00100011.11000000 The mask is equivalent to /26 >, and indicates that the first 26 bits (the bold characters in the result) of the incoming IP address must match the masked deny IP to be denied. All IP addresses from 141.206.35.192 through 141.206.35.255 will match the bold characters. IP addresses from 141.206.35.1 through 141.206.35.191 will have a value of 0 for either bit 25 or 26 (or both), will not match all 26 significant binary values, and therefore will not be denied. The range of the secondary element (whether deny or allow) is applied to the binary string from left to right (high to low address), and can be used on any of the four decimal segments, while the ascension of binary values is from right to left. A partial mask of the third segment, for example, would significantly increase the range addresses affected. Example 4: Secondary Element Processing--Carve Out Exception In some cases, the secondary element can be used to specify an exception for a range of IP addresses that are in the midst of a larger range defined by the primary element, thus carving out a list of denied addresses. This approach also requires use of partial segment masking, as shown in the following: Suppose instead of IP addresses 192 through 255, as shown in the previous example, you want to deny access to IP addresses 48 through 63. Consider the following deny element: <deny ip= 141.206.35.48/28 /> The deny element specified is equivalent to the following binary IP and mask: 10001101.11001110.00100011.00110000 (141.206.35.48) 11111111.11111110.11111111.11110000 (255.255.255.240 or /28"/>) 10001101.11001110.00100011.00110000 (141.206.35.48) The result of ANDing the IP and mask indicates (in bold) that only the first four bits of the fourth segment will be considered for denial within the 141.206.35 subnet. These bits must match exactly for an address to be denied. This has the following effect on denial: Addresses 141.206.35.64 through 141.206.35.255 all have a value of 1 for one or both of the first two bits, causing them to not exactly match the deny mask, so they will not be denied. Addresses 141.206.35.1 through 141.206.35.47 have a zero value for either the third or fourth bit, and also will not be denied. Security Administration 349

Appendix H: Controlling User Access by IP Address Designing IP Restrictions Permissive Filters Addresses 141.206.35.48 through 141.206.35.63 all have 0011 for the first four bits, and therefore will be denied. Note: Because masks are processed left to right, in binary notation, some addresses cannot be isolated with a carve out type of mask; for instance, 141.206.35.51 through 141.206.35.62, when using the example above. Carve out exceptions always affect all addresses that contain the mask value of the IP filter. Related Topics For information on using elements and masks to create filters, see Permissive Filters on page 350 and Restrictive Filters on page 352. For information on placing filters in an XML IP restriction document, see Creating an XML IP Restriction Document on page 339. When the filter type is permissive, all incoming IPs are allowed except those specifically denied in the deny element. The Gateway processes the deny elements first, then it processes the allow elements. As a result, the Gateway denies all IP addresses listed in the deny elements unless they also appear in an allow element, in which case the Gateway will allow the IP to access the database. Use permissive filters to define which IPs are denied (using a deny element) for a list of users, while retaining the ability to use an allow element to enable some of the denied IPs for some users. Note: A permissive filter without a deny element will permit logons from all IPs regardless of what IPs are explicitly allowed by the allow element. The Gateway processes each permissive filter deny element as follows: 1 The filter masks the incoming IP address under test with the mask from the deny element. 2 The filter masks the IP address specified in the deny element with the same mask. 3 If the two masked IP addresses match, the filter identifies the IP address under test as a candidate for denial. The filter then ends the deny phase of testing. The Gateway does allow-testing only if deny-testing identifies an IP address as a candidate for denial. If allow-testing does not override the denial, the Gateway rejects the IP. The Gateway process each permissive filter allow element as follows: 1 The filter masks the incoming IP address under test with the mask from the allow element. 2 The filter masks the IP address specified in the deny element with the same mask. 3 If the two masked IP addresses match, the filter allows the IP address under test to access the database and then ends the allow phase of testing. Note: Although a filter can be constructed using both allow and deny elements, use of both element types in a filter is not required. However, a filter must contain at minimum either an allow or a deny element. When using a single element, it should be the primary element type for the filter type, e.g. a deny element in a permissive filter. 350 Security Administration

Appendix H: Controlling User Access by IP Address Designing IP Restrictions The following example shows a typical permissive filter. Example 1: Permissive Filter <ipfilter name="filter2" type="permissive"> <deny ip="141.206.35.0/255.255.255.0"/> <allow ip="141.206.35.175/255.255.255.255"/> <appliesto tagref="samoht"/> <appliesto tagref="noside"/> </ipfilter> The following table provides explanations of the terms used in Example 1, which depicts a typical permissive filter. Term ipfilter name="filter2" type="permissive" <deny ip="141.206.35.0/ 255.255.255.0"/> Description The filter name. This term identifies the specific filter being used. The filter type. This term identifies whether the filter is permissive or restrictive and indicates the order of IP testing (deny and allow) that it will perform on an incoming IP address. The deny element appears first in a permissive filter. The deny element is divided into two segments, separated by a slash (/ ): The filter: <deny ip="141.206.35.0/ The value of this filter element denies access to the database from any IP address within the 141.206.35 subnet, unless the address explicitly appears in the allow element. The filter allows access to all IPs not covered in the deny element. The mask: 255.255.255.0 /> Determines the extent to which the filter will test an incoming IP address against restrictions defined in the deny element. A mask of 255.255.255.0 /> is equivalent to a mask of 24 />. It tests the first 24 bits (all but the last decimal segment) of the IP address. Usage Note: Use the deny element in a permissive filter to specify a higher network tree level than that specified in the allow element. Security Administration 351

Appendix H: Controlling User Access by IP Address Designing IP Restrictions Term <allow ip="141.206.35.175 /255.255.255.255"/> appliesto tagref="samoht" appliesto tagref="noside" Description The allow element appears after the deny element in a permissive filter. The allow element is divided into two segments, separated by a / : The filter: <allow ip="141.206.35.175/ The value of this filter element indicates that the filter will explicitly allow the 141.206.35.175 IP address access to the database, even though it is within the subnet denied access by the deny element. The filter will deny access to any other IP addresses that appear in the deny element. The mask: 255.255.255.255"/> Determines the extent to which the filter will test an incoming IP address against restrictions defined in the allow element. A mask of 255.255.255.255 tests all the decimal segments of the IP address for an exact match. Usage Note: Use the allow element in a permissive filter to specify a lower level in the network tree than that used for the deny element, to allow exceptions to the IPs explicitly denied. You can use multiple allow elements, if necessary, to define the exceptions. Identifies a user affected by this set of filter rules. Filter appliesto tagref values must correspond to the tag attributes assigned to individual Teradata Database users listed in the user element of the XML IP restriction document. Identifies a second user affected by this set of filter rules. Restrictive Filters When the filter type is restrictive, all incoming IPs are denied except those specifically allowed in the allow element. The Gateway processes the allow elements first, then it processes the deny elements. As a result, the Gateway allows only the IP addresses listed in the allow elements unless they also appear in an deny element, in which case the Gateway will deny access to the incoming IP address. Use restrictive filters to define which IPs are allowed for a list of users, while retaining the ability to use the deny element to disable some of the allowed IPs for some users. Note: A restrictive filter without an allow element will deny logons from all IPs regardless of what IPs are explicitly denied by the deny element. The Gateway processes each restrictive filter allow element as follows: 1 The filter masks the incoming IP address under test with the mask from the allow element. 2 The filter masks the IP address specified in the allow element with the same mask. 352 Security Administration

Appendix H: Controlling User Access by IP Address Designing IP Restrictions 3 If the two masked IP addresses match, the filter identifies the IP address under test as a candidate for approval. The filter then ends the allow phase of testing and begins subjecting the incoming IP address to deny testing. The Gateway conducts a test of each deny element as follows. If the test completes without denying access, the Gateway permits the IP to connect. 1 The filter masks the incoming IP address under test with the mask from the deny element. 2 The filter masks the IP address specified in the deny element with the same mask. 3 If the two masked IP addresses match, the filter allows the IP address under test to access the database and then ends the denial phase of testing. Note: Although a filter can be constructed using both allow and deny elements, use of both element types in a filter is not required. However, a filter must contain at minimum either an allow or a deny element. When using a single element, it should be the primary element type for the filter type, e.g. an allow element in a permissive filter. Example 2 helps clarify how the deny and allow testing work with a specific filter setup. Example 2: Restrictive Filtering <ipfilter name="filter1" type="restrictive"> <allow ip="141.206.0.0/255.255.0.0"/> <deny ip="141.206.35.0/255.255.255.0"/> <appliesto tagref="xyzzy"/> <appliesto tagref="shazam"/> </ipfilter> The following table provides explanations of the terms used in restrictive filter shown in Example 2. Term ipfilter name="filter1" type="restrictive" Description The filter name. This term specifies a single IP filter in an XML IP restriction document. The filter type. This term identifies whether the filter is a restrictive or permissive type, and indicates the deny/allow testing that will take place when the filter evaluates an incoming IP address. Security Administration 353

Appendix H: Controlling User Access by IP Address Designing IP Restrictions Term <allow ip="141.206.0.0/ 255.255.0.0"/> <deny ip="141.206.35.0/ 255.255.255.0"/> <appliesto tagref="xyzzy"/> <appliesto tagref="shazam"/> Description The allow element appears first in a restrictive filter. The allow element is divided into two segments, separated by a / : The filter: <allow ip="141.206.0.0/ The value of this element indicates that the filter allows database access to any IP address within the 141.206 subnet unless it explicitly appears in the deny element that follows. The filter denies access to all IPs not covered in the allow element. The mask: 255.255.0.0"/> Determines the extent to which the filter will test an incoming IP address against access allowed in the allow element. A mask of 255.255.0.0 tests the first two decimal segments of each IP address seeking access, to determine whether or not it falls within the allowed range. Usage Note: Use the allow element in a restrictive filter to specify a higher level in the network tree than that used for the deny element. The deny element appears second in a restrictive filter. The deny element is divided into two segments, separated by a / : The filter: <deny ip="141.206.35.0/ The value of this element indicates that the filter will explicitly deny all addresses in the 141.206.35 subnet, even though it is within the range of IPs allowed by the allow element. Any other IP addresses will be denied access if they appear in a subsequent deny element. The mask: 255.255.255.0"/> Determines the extent to which the filter will test an incoming IP address against access denied in the deny element. A mask of 255.255.255.0 tests the first three decimal segments of each IP address seeking access, to determine whether or not it falls within the denied range. Usage Note: Use the deny element in a restrictive filter to specify a lower level in the network tree than that used for the allow element, to define exceptions to the IPs explicitly allowed in the allow element. You can use multiple deny elements, if necessary. Identifies a user affected by this set of filter rules. Filter appliesto tagref values must correspond to tag attributes assigned to individual users listed in the user element of the XML IP restriction document. Identifies a second user affected by this set of filter rules. 354 Security Administration

Appendix H: Controlling User Access by IP Address Designing IP Restrictions Applying a Filter to a User To apply a filter to a database user, you must specify the username in an appliesto attribute of an ipfilter element in the XML IP restriction document. Example 3 shows an XML IP restriction document that selectively applies two IP filters to individual Teradata Database users. Example 3: XML Document Linking a Filters to Individual Users <?xml version="1.0" encoding="utf-8"?> <tdat name="tdat"> <system name="gizmo"> <users> <user name="drct01" tag="xyzzy"/> <user name="perm01" tag="noside"/> <user name="extuser" tag="shazam"/> </users> <ipfilters> <ipfilter name="filter1" type="restrictive"> <allow ip="141.206.0.0/255.255.0.0"/> <deny ip="141.206.35.0/255.255.255.0"/> <appliesto tagref="xyzzy"/> <appliesto tagref="shazam"/> </ipfilter> <ipfilter name="filter2" type="permissive"> <deny ip="141.206.35.0/255.255.255.0"/> <allow ip="141.206.35.175/255.255.255.255"/> <appliesto tagref="noside"/> <appliesto tagref="xyzzy"/> </ipfilter> </ipfilters> </system> </tdat> The following table provides explanations of the terms used in restrictive filter shown in Example 3. Term <?xml version="1.0" encoding="utf-8"?> <tdat name=tdat> <system name="gizmo"> <users> <user name="drct01" tag="xyzzy"/> <user name="perm01" tag="noside"/> <user name="extuser" tag="shazam"/> </users> Description The version of XML used to generate the document. The character set used in the XML document. The XML document root. The system to which the IP restrictions apply. The users to which the restrictions in the XML document apply. Each username must be accompanied by a tag attribute. Use the tag attribute to link the database user to filters. The value of the tag attribute must appear in an appliesto attribute of any filter you want to connect to that user. Security Administration 355

Appendix H: Controlling User Access by IP Address Designing IP Restrictions Term <ipfilters> <ipfilter name="filter1" type="restrictive"> <allow ip="141.206.0.0/ Description This section of the XML IP restriction document lists the ipfilters that define the restrictions. The common name of the first filter specified in the document is filter1. It is a restrictive filter. The IP range allowed by filter1. The value of this element indicates that the filter will allow access to the database for any IP addresses within the 141.206 subnet unless they explicitly appear in a deny element. Because the filter is restrictive, it automatically denies access to all IPs outside those specified in the allow element. 255.255.0.0"/> This mask causes the filter to test the first 16 bits of the incoming IP address against the allowed IP, during allow-testing. The filter will allow access for IPs that have values in the segments inhabited by zeros, as long as the first 16 bits specify the 141.206 subnet. <deny ip="141.206.35.0/ The filter will deny access to IPs in the 141.206.35 subnet even though it is within the 141.206 specified in the allow element. 255.255.255.0"/> This mask causes the filter to test the first 24 bits of an incoming IP address against the denied IP. The zero indicates the filter will not use the last 8 bits of an incoming IP address in deny-testing. <appliesto tagref="xyzzy"/> <appliesto tagref="shazam"/> <ipfilter name="filter2" type="permissive"> <deny ip="141.206.35.0/ The restriction described in filter1 applies to users drct01 and perm01 because it specifies their respective tag attributes, xxzzy and shazam. The name of the second filter specified in the restriction document is filter2. It is a permissive filter. The IP denied by filter2. The value of this element indicates that the filter will deny access to the database for any IP addresses within the 141.206.35 subnet unless they explicitly appear in an allow element. Because the filter is permissive, it allows access to all other IPs outside those specified the deny elements. 356 Security Administration

Appendix H: Controlling User Access by IP Address Designing IP Restrictions Term Description 255.255.255.0"/> The 255 in each decimal-separated segment of the mask indicates the filter will test the corresponding segment of the IP address for access denial. The 0 indicates that no testing will be done for the corresponding segment of the IP address. This mask causes the filter to test the first 24 bits of the incoming IP address against the denied IP. <allow ip="141.206.35.175/ The IP exceptions allowed by filter2. The value of this element indicates that the filter will allow access to the database for IP address 141.206.35.175 even though it would otherwise be disallowed by the more general parameters of the deny element. 255.255.255.255"/> The 255 in each decimal-separated segment of the mask indicates the filter will test the corresponding segment of the IP address for allowable access. This mask causes the filter to test all 32 bits of the incoming IP address against the allowed IP. <appliesto tagref="noside"/> <appliesto tagref="xyzzy"/> </ipfilter> </ipfilters> </system> </tdat> The restrictions described in filter2 apply to the database users noside and xxzzy. These terms close out the various sections of the XML IP restriction document. Application of IP Restrictions Only one XML IP restriction document can exist at a time, but it is not required. Upon completion of an XML document, the contents must be transferred to the GDO using the ipxml2bin utility in order for the restrictions to take effect. The GDO may optionally be populated by restrictions defined in a supported directory, but both methods cannot be used simultaneously. The effects on users include the following additional contingencies: When Multiple Filters Exist When multiple filters exist that reference a single user, the system considers all filters as if they were a single large filter. If any filter denies the user access to the database, processing of the logon stops. When No Filter Exists To maintain backward compatibility with previous Teradata Database versions, when no IP filter exists for a particular user, the user is allowed to access the database from any IP address. Security Administration 357

Appendix H: Controlling User Access by IP Address Designing IP Restrictions Applying a Filter to All Users Sometimes IP filter allow or deny rules can be applied to all users. To eliminate the need to specify all users individually, you can specify everybody. To apply a filter to all users: Employ only the users element, without any individual user elements. Assign a value such as everybody to the users tag attribute Assign the same value to the applies to tagref attribute When such an all users filter exists, the system uses it first when testing an individual user. Example 4 describes an IP filter that applies to all Teradata Database users. Example 4: XML Document Linking a Filter to All Users <?xml version="1.0" encoding="utf-8"?> <name="tdat"> <system name="gizmo"> <users tag="everybody"> </users> <ipfilters> <ipfilter name cn= filter1 Filter type="permissive"> <deny ip="141.206.35.0/255.255.255.0"/> <allow ip="141.206.35.175/255.255.255.255"/> <appliesto tagref="everybody"/> </ipfilter> </ipfilters> </system> </tdat> The following table provides an explanation of the terms used differently than in previous examples, to facilitate an all users application of a filter. The explanation covers only the differences. For the terms not covered in this table, refer to the previous examples in the sections on permissive and restrictive filters. Term <users tag="everybody"> </users> <appliesto tagref="everybody"/> Description Specifies all users, as defined the list of user names that follows Instead of the simple <users> element that appears in Example 3, employing <users tag= everybody > allows for an all users application of the filter. This element closes out the list of users. It does not require the tag="everybody" nomenclature present in the opening users element. By using everybody, this element applies the filter conditions to all users without the need to list them individually. 358 Security Administration

Appendix H: Controlling User Access by IP Address Directory Implementation of IP Restrictions Directory Implementation of IP Restrictions This section covers the following topics: loading directory schema extensions populating the directory with IP-related objects setting the IP-related object attributes Loading Directory Schema Extensions for IP Restriction of Directory Users To implement IP restrictions for directory users, you must first load the IP-related Teradata Database schema extensions into the directory. The schema extensions are part of the TeraGSS software module present in Teradata Database V2R6.2 and beyond. Note: IP restrictions in a directory work only for directory users that are already mapped to Teradata Database users or to EXTUSER. You should first set up your supported, LDAPcompliant directory for LDAP authentication of directory users and take some time to make sure it is operating correctly before proceeding to implement directory-based IP access restrictions. For information about setting up directory-based user management, see Chapter 9 Directory Management of Database Users. For information about loading Teradata Database schema extensions into a supported directory, see Installing Teradata Schema Extensions in a Supported Directory on page 255. Creating IP Restriction Schema Objects in the Directory The Teradata Database schema extensions require that IP filter data be expressed only using IP filter schema objects and object attributes. After installation of the Teradata Database IPrelated schema extensions is complete, you must create IP-related schema objects and assign values to their attributes. Objects used for LDAP authentication will already exist, but must be referenced in lower level objects. IP filter schema objects and attributes are similar to the IP filter elements used in an XML IP restriction document. For example, the appliesto element in an XML IP restriction document corresponds to the IPFilterMember attribute in an ipfilter directory object; they both identify a Teradata Database user to which the filter applies. Higher level object names become attribute values in lower level objects, therefore, many objects also act as attributes. For information on creating schema objects in the directory, see the section beginning with Creating Containers and Inserting Objects on page 266. Standard Teradata Database Schema Objects The following objects are also used to support LDAP authentication. If these objects do not already exist in your directory it is not setup for LDAP. Do the LDAP setup before proceeding. For information about setting up directory-based user management, see Chapter 9: Directory Management of Database Users. Security Administration 359

Appendix H: Controlling User Access by IP Address Directory Implementation of IP Restrictions IP Filter Schema Objects The following section describes how standard LDAP schema objects are used for IP restriction. tdatrootnode The tdatrootnode object identifies the root in the directory information tree (DIT). It corresponds to the tdat element in an IP XML document. This object appears in lower level objects and binds the object definitions to the Teradata Root Node. This attribute must be the first attribute in any IP filter-related object in the directory information tree. The cn attribute of the tdatrootnode object corresponds to the name attribute of the <tdat> element. tdatsystem The tdatsystem object corresponds to the system element in an XML document. It has a name attribute that defines a Teradata Database system name. The value assigned to this attribute must be the common name (cn) assigned to the tdatsystem object that represents the system to which the IP restrictions apply. The tdatsystem object must appear only as a child of the tdat object. users The users object is a type of tdatcontainer object. A users object contains individual tdatuser objects that map IP restrictions to Teradata Database users. A users container can appear only as a child of a tdatsystem object. Express the name attribute for this type of container as cn=users. tdatuser Each tdatuser object describes a Teradata Database user. A user object must appear only as a child of a tdatcontainer object with a cn=users (that is, a users object). Reference tdatuser objects in an IPFilterMember attribute in an IPFilter object to apply the filter rules to that user. Employ tdatuser objects to define the Teradata Database users affected by an IP filter, using the form cn=<teradata Database username> for the value of the name attribute, while specifying only one username per tdatuser object. Some directory objects necessary for IP restrictions are not used for any other purpose and and will need to be specially created. ipfilter The ipfilters object is a type of tdatcontainer object with the common name ipfilters (cn=ipfilters).this object appears only as a child of a tdatsystem object. As many ipfilters objects as needed can appear in the directory, however, only one appearance is typical. The ipfilters container holds individual tdatipfilter objects. 360 Security Administration

Appendix H: Controlling User Access by IP Address Directory Implementation of IP Restrictions tdatipfilter The tdatipfilter directory object describes an individual IP filter. The object has a number of attributes. The value of the name attribute is arbitrary and has no intrinsic meaning except as a placeholder to differentiate among filters. A tdatipfilter object can appear only as a child of an ipfilters object. As many tdatipfilter objects as necessary can appear in the directory. The following attributes define the function of the filter: tdatallowdeny The tdatallowdeny attribute is similar to the filter type element in an IP XML document. It can contain either of two values: A value of TRUE defines the filter as a restrictive filter. This means that the filter: Denies all IP addresses except those specifically allowed. Processes the tdatallowedip filter first, to determine the IP address or range of addresses that are allowed access. Then processes the tdatdeniedip for any exceptions to the allowed IP addresses. A value of FALSE defines the filter as permissive. This means that the filter: Allows all IP addresses except those specifically denied. Processes the tdatdeniedip filter first, to determine the IP address or range of addresses that are denied access. Then processes the tdatallowedip for any exceptions to the denied IP addresses tdatallowedip The tdatallowedip attribute requires two values, an IP address and a mask. It is similar to an allow element in an IP XML document. If the IP address of the incoming session, when ANDed with the mask, matches the IP address in the attribute ANDed with the mask, the IP address of the incoming session is allowed access. For details about how to specify IP addresses and masks for the purpose of IP filtering, see Addresses and Mask Structure on page 345, and Forms of Interaction Between Primary and Secondary Masked IPs on page 347. The tdatallowedip attribute can appear only in an tdatipfilter object. As many tdatallowedip attributes as needed can appear in an IPFilter object. When multiple tdatallowedip attributes appear, only one match is necessary to allow the session to proceed. tdatdeniedip The tdatdeniedip attribute requires two values, an IP address and a mask. It is similar to the deny element in an IP XML document. If the IP address of the incoming session, when ANDed with the mask, matches the IP address in the attribute ANDed with the mask, the IP address of the incoming session is denied access. The tdatdeniedip attribute can appear in an tdatipfilter object. As many tdatdeniedip attributes as needed may appear in the directory, but when multiple tdatdeniedip attributes appear, only one match is needed to deny the incoming IP address. Security Administration 361

Appendix H: Controlling User Access by IP Address Directory Implementation of IP Restrictions tdatipfiltermember The value of the tdatipfiltermember attribute is a user to which the containing tdatipfilter applies. It corresponds to the appliesto element in an IP XML restriction document. The tdatipfiltermember attribute is a unique identifier contained in a tdatuser object. Use an tdatipfiltermember attribute to bind an ipfilter to user. You can use multiple instances of the tdatipfiltermember attribute in a tdatipfilter object, but only one user can be specified per instance. Mapping IP Filters to Database Users Once you create the IP filter objects necessary to implement IP access restrictions for your system and set their attribute values, you must map the filter objects to database users. The mapping method is similar to that required for mapping of other Teradata Database schema objects. To apply an IP filter to a directory user who will access the database, map the IP filter to the Teradata Database user to which the directory user is mapped. Note: The IP access restriction feature is not applicable to unmapped directory users. For information on mapping IP filters to database users, see Mapping IPFilters to Database Users on page 271. 362 Security Administration

Appendix H: Controlling User Access by IP Address Data Conversion Utilities Data Conversion Utilities The Gateway enforces all IP restrictions by drawing information from the IP restriction GDO. Use the following utilities to import IP restrictions from an XML document in the database, or from the directory schema, to the IP GDO. Note: You must run one of the following utilities whenever you create/update IP restrictions. ipxml2bin The ipxml2bin utility transfers XML-based IP restriction information to the IP GDO. Synopsis Use the following format when running the ipxml2bin utility: ipxml2bin -f <outputfile> [-G] [<inputfile>] ipxml2bin [-f <outputfile>] -G [<inputfile>] Description The ipxml2bin utility reads XML input defining the IP restrictions and transfers it to the IP GDO. Specify at least one option (-f or -G). The following table describes the options that can be used in an ipxml2bin statement: Option Description -f Names a file where the binary representation is stored If the file named in the -f option exists, it will not be replaced if errors of any sort occur during parcing or generation of the binary image. -G Instructs ipxml2bin to commit the binary data to the GDO This option is only available on Teradata Database nodes. Upon successful completion, the ipxml2bin utility will terminate with an exit status of 0. If an error has occurred, the ipxml2bin utility will terminate with an exit status of 1. The named file and the GDO will not be modified when an error occurs. Errors Because the an external parser is used by the utility, the majority of the errors that may occur when you use the utility are XML errors. Common errors are as follows: GDO support not available The user specified the -G utility option on a system where PDE is not installed. GDO size limit exceeded; need #, limit #. The data in the XML file is too large to be contained in the GDO. You must either reduce the amount of data in the XML file or switch to a directory-based solution. Security Administration 363

Appendix H: Controlling User Access by IP Address Data Conversion Utilities Example 1: Using the ipxml2bin Utility When you run the ipxml2bin utility, it will look for the XML IP restriction document filed as ipfilter.xml. If you have saved the file under this name the utility will access it and transfer the ipfilter restrictions to the GDO. The following input and output are typical for a run of ipxml2bin: $ ipxml2bin -G ipfilter.xml Parse successful 784 bytes written to the ipfilter GDO. $ ipdir2bin The ipdir2bin utility transfers the IP address restrictions contained in a supported directory to the IP GDO. Synopsis Use the following format when running the ipdir2bin utility: ipdir2bin -f <file> [-G] [-h <srvr>] [-p <port>] [-S <sys>] -u <usr> [-w <pass>] ipdir2bin -G [-f <file>] [-h <srvr>] [-p <port>] [-S <sys>] -u <usr> [-w <pass>] Description The ipdir2bin utility reads input from a supported directory where IP restrictions are defined and produces an easily navigable binary image to use with the API. The following table describes the options that can be used in an ipdir2bin statement: Option Description -f Names a file where the binary representation is stored If the file named in the -f option exists, it will not be replaced if errors of any sort occur during parcing or generation of the binary image. -G Instructs ipdir2bin to commit the binary data to a GDO This option is only available on Teradata Database nodes. 364 Security Administration

Appendix H: Controlling User Access by IP Address Data Conversion Utilities Option Description -h Identifies the directory server. If this option is not present in the statement, the utility consults the TDGSS configuration files and uses the value for the LdapServerName property. If the LdapServerName property is unavailable or not specified, the utility uses the name of the default directory server for the system. The default directory server is normally specified by administrators as part of one of these set-up procedures: when a Windows system is added to a domain when an administrator explicitly names the server in the etc/ ldap.conf file on a Unix system -p Identifies the port where the directory server listens. If this option is not present in the statement, the utility consults the TDGSS configuration files and uses the value for the LdapServerPort property. If the LdapServerPort property is unavailable, the utility uses the default value of 389, the default port value for the LDAP protocol. -S Identifies the FQDN of the Teradata Database system as defined in the directory. If the value is not present ipxml2bin uses the value of the LdapSystem FQDN from the TDGSS configuration files. If the LdapSystemFQDN property contains no value, the utility exits with an error. -u Specifies the FQDN of the directory user. There is no default and this option is required. -w Specifies the user password. If not specified, the system prompts the user for a password. Errors Because ipdir2bin accesses the directory using an external LDAP client, the errors that may be produced by the utility will be LDAP client errors specific to the client and server involved. For a list of application-specific errors that may occur, see the errors in ipxml2bin on page 363, which are similar. Example 2: Using the ipdir2bin Utility Use the ipdir2bin utility to look in the LDAP configuration and locate the filters for the system configured in LdapSystemFQDN. The utility then writes that information into the GDO. $ ipdir2bin -G -u drct01 Enter LDAP password: Parse successful 608 bytes written to the ipfilter GDO. $ Security Administration 365

Appendix H: Controlling User Access by IP Address Data Conversion Utilities 366 Security Administration

APPENDIX I Password Restricted Words This appendix covers the use of restricted words to control password content (password restricted words). There are two sources of password restricted words: Default restricted words are added to the system upon upgrade to Teradata Database 12.0 or greater. Administrators can add new restricted words (or delete existing restricted words) For additional information about use of password restricted words, see Password Control Options on page 97. Default Restricted Words Frequently Used Words Approximately 2400 default restricted words are automatically added when a system is upgraded to Release 12.0 or greater. There are two types of default restricted words: Frequently used words (approximately 2000 words) Common names (approximately 400 words) The following tables list the restricted words by category, in alphabetical order. Note: Password restricted words are not case sensitive A ability advantage allowed any aspects able affairs almost anyone assignment about afraid alone anything assistance academic after along apart associated accept afternoon already apartment association accepted addition also apparent assume according additional although apparently assumed account address always appeal atmosphere achieved adequate america appear attack achievement again american appears attempt across against americans application attention act age among appearance attitude acting agencies amount appeared attorney Security Administration 367

Appendix I: Password Restricted Words Default Restricted Words action agency analysis applied audience actions ago ancient arrived authority active agreed and art available activities agreement animal article average activity ahead animals artist avoid actual aid announced artists aware actually air annual arts away add aircraft anode aside added alive another ask administration all answer asked advance allow answered asking B baby became benefit boat british back because berlin bodies broad background become beside body broke bad becomes besides book broken balance becoming best books brother ball bed better born brought bank been between boston brown bar before beyond both budget base began bible bottle build baseball begin big bottom building based beginning bill bought buildings basic begins billion box built basis behavior birds boy business battle behind birth boys busy bay being bit break but beach belief black bridge buy bear believe block brief beat believed blood bright beautiful below blue bring beauty beneath board britian C california central city communism contemporary call century civil communist continue called certain claim community continued calls certainly claims companies continuing came chair class company contract camp chairman classes compared contrast campaign chance clay competition control 368 Security Administration

Appendix I: Password Restricted Words Default Restricted Words can change clean complete cool cannot changed clear completed corner capable changes clearly completely corporation capacity chapter close completion corps capital character closed complex cost captain characteristic closely components costs car charge closer concept could care charged clothes concern council career charles club concerned countries careful check coast concerning country carefully chemical coffee conclusion county carried chicago cold condition couple carry chief collection conditions course carrying child college conduct courses cars children color conducted court case china column conference cover cases chinese combination confidence covered catholic choice come congo created cattle chosen comes congress credit caught christ coming connection crisis cause christian command consider critical causes churches commercial considered cultural caused church commerce considerable cross cell circle commission constant culture cells circumstances committee construction current cent cities common contact cut center citizens communication contained cutting D daily degree device distance dramatic dallas degree dictionary distribution draw dance demand did district drawn danger demands die divided dream dark democratic died division dress data department difference doctor drew date described differences does drink daughter design different dog drive day designed difficult dogs drop days desire difficulty doing dropped dead desk dinner dollars drove deal despite direct domestic dry 369 Security Administration

Appendix I: Password Restricted Words Default Restricted Words death detail directed dominant due december details direction done during decided determine directly door dust decision determined director double duty declared develop discovered doubt deep developed discussed down defence development discussion dr E each eight enough even exist earlier either enter evening existence early election entered event existing earth electric entire events expect easily electronic entirely ever expected east elements entitled every experience easy else entrance everybody experiment eat emotional equal everyone experiments economic emphasis equally everything explain economy employees equipment evidence explained edge empty escape evident expressed editor end especially evil expression education ended essential exactly extended educational ends establish example extent effect enemy established excellent extreme effective energy estimated except eye effects england etc exchange eyes effort english europe executive efforts enjoyed european exercise F face father file follow frame faces favor filled followed france facilities fear film following frank fact features final follows free factor federal finally food freedom factors feed financial foot french facts feel find for frequently faculty feeling finds force fresh failed feelings fine forced friday failure feet fingers forces friend fair fell finished foreign friendly fairly fellow fire forest friends 370 Security Administration

Appendix I: Password Restricted Words Default Restricted Words faith felt firm form from fail few firms formed front familiar field first former full families fields fiscal forms fully family fifteen fit formula function famous fifty five fort fund far fig fixed forth funds farm fight flat forward further fashion fighting floor found future fast figure flow four fat figures flowers fourth G gain germany goal granted grounds game get god gray group games gets goes great groups garden getting going greater grow gas girl gone greatest growing gave girls good greatly growth general give goods greek guest generally given got green guests generation gives government grew gun george giving governments gross german glass governor ground H had have hell himself hospital hair having help his hot half head helped historical hotel hall headed hence history hour hand headquarters henry hit hours hands health her hold house hanover hear here holding houses happen heard herself hole housing happened hearing high home how happy heart higher homes however hard heat highest honor human hardly heavily highly hope hundred has heavy hill horse hung hat held him horses husband I idea improved independence informed interior Security Administration 371

Appendix I: Password Restricted Words Default Restricted Words ideal inch independent initial internal ideas inches index inside international image include india instance into imagination included indicate instead involved imagine including indicated institutions island immediate income individual intellectual issue immediately increase individuals intensity issues impact increased industrial interest items importance increases industry interested its important increasing influence interesting itself impossible indeed information interests J jack job joined judgement just james jobs jones july justice jazz joe joseph june jesus john jr junior jewish join judge jury K keep key killed knew known keeping kruschev kind knife knows kennedy kid king know kept kill kitchen knowledge L labor lead length line look lack leader less lines looked lady leaders let lips looking laid leadership letter list looks land leading letters literary lord language league level literature lose laos learn levels little loss large learned lewis live lost largely learning liberal lived lot larger least library lives louis last leave lie living love late leaving life local loved later led light located low latter left like location lower law leg liked london laws legal likely long lay legs limited longer 372 Security Administration

Appendix I: Password Restricted Words Default Restricted Words M machine married meeting miles moon machinery martin member military moral made mary members million more main mass membership mind mother maintain master memory minds motion maintenance material men minor motor major materials mentioned minute mouth majority matter mercer minutes move make matters merely miss moved makes maximum message mission movement making may met model moving man maybe metal modern much management mean method moment murder manager meaning methods monday music manner means middle money musical many meant might month must march measure mike months my mark measures mile moreover myself marked medical mine morgan market meeting minimum morning marriage meet minister most N name near neither no notes named nearly never nobody nothing names necessary nevertheless none notice narrow neck new nor novel nation need news normal november national needed newspaper north now nations needs next nose nuclear natural negro nice not number naturally negroes night note numbers nature neighborhood nine noted O object offered one opportunity other objective office ones opposite others objects officer only orchestra otherwise observed officers onto order ought obtained official open ordered our obvious officials opened orders ourselves Security Administration 373

Appendix I: Password Restricted Words Default Restricted Words obviously often opening ordinary out occasion oil operating organization outside occurred old operation organizations over off older operations organized own offer once opinion original P page period plays practical production paid permit please practice products pain permitted pleasure prepared professional painting person plenty presence professor pale personal plus present program palmer personnel poems presented programs paper persons poet president progress parents phase poetry press project paris phil point pressure projects park philosophy pointed pretty proper parker physical points prevent properties part pick police previous property particular picked policies previously propose particularly picture policy price protection parties pictures political prices proved parts piece politics primarily provide party pieces pool primary provided pass place poor principal providence passed placed popular principle provides passing places population principles providing past plan portion private public patient plane position probably published pattern planned positive problem pulled pay planning possibility problems pure peace plans possible procedure purpose people plant possibly procedures purposes per plants post process put percent platform potential processes perfect play power produce performance played powerful produced perhaps playing powers product Q quality questions quickly quite question quick quiet 374 Security Administration

Appendix I: Password Restricted Words Default Restricted Words R race really relation requirements rise radiation reason relations requires rising radio reasonable relationship research river railroad reasons relatively resolution road rain receive relief resources roads raised received religion respect robert ran recent religious response rock range recently remain responsibility role rapidly recognize remained responsible roman rate recognized remains rest rome rates record remember result roof rather records remembered results room reach red remove return rooms reached reduce removed returned rose reaction reduced repeated review round read reference replied revolution rule reading refused report rhode rules ready regard reported rich run real regarded reports richard running reality region represented rifle runs realize regular require right russia realized related required rights russian S safe simply son stands structure said since song stared struggle sales single songs start student sam sir soon started students same sit sort starting studied sample site sought state studies san sitting sound stated study sat situation source statement style saturday six sources statements subject save size south states subjects shelter sky southern station substantial ship sleep soviet stations success shook slightly space status successful shop slow speak stay such shore slowly speaking stayed suddenly short small special step sufficient Security Administration 375

Appendix I: Password Restricted Words Default Restricted Words shot smaller specific steps suggested should smile speech still summer shoulder smiled speed stock sun show snow spent stone sunday showed social spirit stood supply showing society spiritual stop support shown soft spite stopped suppose shows soldiers spoke store supposed side solid spot stories sure sides solution spread story surface sight some spring straight surprised sign somebody square strange sweet signal somehow staff street system significance someone stage streets systems significant something stand strength signs sometimes standard stress similar somewhat standards strong simple somewhere standing struck T table ten thin told trees take tension thing tom trial taken term things tomorrow tried takes terms think tone trip taking test thinking too trouble talk tests third took truck talked texas thirty top true talking text this total truly task than thomas touch truth taste that those toward try tax the though towards trying teacher their thought town tuesday teachers then thousand trade turn teaching theme three tradition turned team themselves through traditional turning technical then throughout traffic twenty technique theory thus train twice techniques there time training two teeth therefore times travel type telephone these title treated types tell they today treatment typical 376 Security Administration

Appendix I: Password Restricted Words Default Restricted Words temperature thick together tree U ultimate union universe upper usual uncle unique university use usually under unit unless used understand united until useful understanding units unusual uses understood unity upon using V valley various view visit volume value vast village vital vote values very virginia vocation variety victory vision voice W wage watching when wilson wore wait water where win work waited way whether wind worked waiting ways which window workers walk weapons while wine working walked weather white winter works wall week who wish world walls weeks whole with worry want weight whom within worth wanted well whose without would wants went why woman write war were wide women writer warm west wife won writers was western wild wonder writing washington what will wondered written watch whatever william word wrong watched wheel willing words wrote Y your yards yes york yourself year yesterday you youth years yet young Frequently Used Names Frequently Used Names A Security Administration 377

Appendix I: Password Restricted Words Default Restricted Words Frequently Used Names aaron alex allen andrew april abigail alexa allison angel ariel adam alexander alyssa angela arthur adrian alexandra amanda anita ashley alan alexandria amber ann austin albert alexis amy anthony autumn alejandro alicia andrea antonio B bailey bianca bradley brian bryan barb billy brandon brittany bryce barry blake breanna brittney ben bob brenda brooke beth bonnie brett bruce C caitlin catherine cheyenne colleen crystal caleb cathy chloe connie curtis cameron chad chris connor cynthia carl charles cindy corey carol chase claire cory casey chelsea cody courtney cassandra cheryl cole craig D dakota darrell dean derek dustin dale darren debbie destiny dylan dalton daryl deborah devin dana dave debra diana dan david denise don darlene dawn dennis doug E edward elizabeth emma erik ethan elijah emily eric erin evan F faith frank G gabriel garrett george gina grace gabriella gary gerald glen gregory gabrielle gavin H hailey hannah heather holly hunter 378 Security Administration

Appendix I: Password Restricted Words Default Restricted Words Frequently Used Names haley harold henry I ian isaac isabel isabella isiah J jack janet jeremy john julia jacob janice jerry jon julian jacqueline jared jesse jordan Julie jada jasmine jessica jose Justin jake jason jesus joshua james jay jill joyce jamie jeff jimmy juan jane jenn joe judy K kaitlyn katheryn keith justin kyle karen kathy kelly kimberly kate katie kelsey kristen katherine kayla ken kristin kathleen kaylee kevin kristina L larry lawrence lindsay lori lynn laura leah lindsey lucas lauren leslie lisa luis laurie linda logan luke M mackenzie maria mary melinda miguel madeline mariah mason melissa mike madison marissa matt mia mitchell makalya mark megan michael molly marcus martha meghan michele monica margaret martin melanie michelle morgan N nancy nathan nicholas nicole noah natalie nathaniel O Olivia P paige patricia paul penny philip pam patrick paula peter phillip R Security Administration 379

Appendix I: Password Restricted Words Default Restricted Words Frequently Used Names rachel rebecca rich rodney russell randall regina ricky roger ryan randy renee robert ron ray rhonda robin roy S sabrina scott sharon sherry stephen sam sean shawn sierra steve sandra sebastian sheila sophia susan sara seth shelby spencer suzanne sarah shane shelly stacy sydney savannah shannon sherri stephanie T tammy terri tim tracy tyler tanner terry tina travis tara theresa todd trevor taylor thomas tony trinity teresa tiffany tracey troy V valerie veronica victor victoria vincent vanessa W walter wayne wendy whitney will wanda Z zachary zoe 380 Security Administration

Glossary AD Active Directory ADAM Active Directory Application Mode AES AMP ASE AWS BAR BTEQ Advanced Encryption Standard Access Module Processor Account String Expansion Administration Workstation Backup And Restore Basic Teradata Query BYNET Banyan Network (high-speed interconnect) CA CBC CFB CJK Certificate Authority Cipher-block Chaining Ciphertext Feedback Chinese Japanese Korean CLIv2 Call Level Interface version 2 CN DBA DBC Common Name Database Administrator Database Computer. Also the name of the top level database user. DBQL DCL Database Query Logging Data Control Language DD DDL DES DH DIT DML DN Data Dictionary Data Definition Language Data Encryption Standard Diffie-Hellman Directory Information Tree Data Manipulation Language Distinguished Name Security Administration 381

Glossary DNS EA ECB EGD FAT Domain Name System External Authentication Electronic Code Book Ethernet Global Data File Allocation Table (a file system architecture) FQDN GDO Fully-Qualified Distinguished Name Global Database Object GSS-API Generic Security Services Application Programmer Interface GUI GUID IETF JAR JCE Graphical User Interface Globally Unique Identifier Internet Engineering Task Force Java Archive (a Java-compatible file protocol) Java Cryptography Extensions JIS KDC Japanese Industrial Standard Key Distribution Center (Kerberos) KRB5 LAN LDAP Kerberos (security mechanism) Local Area Network Lightweight Directory Access Protocol. Also a TDGSS security mechanism LDIFDE An Active Directory tool that can be used to install Teradata schema extensions MD5 MVS NCSC NTFS Message DIGEST Algorithm Multiple Virtual Storage National Computer Security Center New Technology File System (Windows NT standard file system) NTLM Microsoft Windows NT Lan Manager or the Teradata Database NTLM security mechanism that supports it NTP OFB OU Network Time Protocol Output Feedback Organizational Unit (as defined in Active Directory) PAM Pluggable Authentication Modules. A SUSE Linux Enterprise Server 10 application that sets security policy 382 Security Administration

Glossary PC PDN PE PEM Personal Computer Package Distribution Node Parsing Engine Privacy-enhanced Electronic Mail PKCS Public Key Cryptography Standard PRNGD Pseudo-random Gathering of Data PUT QOP SASL SHA-1 Parallel Upgrade Tool Quality of Protection Simple Authentication and Security Layer Secure Hashed Standard SP SPN Service Pack Service Principal Name SPNEGO A Simple and Protected GSSAPI Negotiation Mechanism. A TDGSS security mechanism that supports logons from.net-enabled clients. SQL SSL SSO SSPI TCB Structured Query Language Secure Sockets Layer. Also a type of protection for transmitted data. Single Sign On Secure Sockets Programmer Interface Trusted Computing Base TCP/IP Transmission Control Protocol/Internet Protocol TD 1 TD 2 Teradata Type 1 (security mechanism) Teradata Type 2 (security mechanism) TDGSS Teradata Database Generic Security Services TDI TDP Trusted Database Interpretation Teradata Director Program TDPID Teradata Director Program Identification TLS TSC UDF UPN Transport Layer Security. A type of protection for transmitted data. Teradata Support Center User-Defined Function User Principal Name Security Administration 383

Glossary URI WAN Uniform Resource Identifier Wide Area Network 384 Security Administration

Index A Access control by IP address, see IP access restrictions by password 69 database access 23 hardware access 22, 227 operating system access 36 options 50 Teradata DWM access 37 using hostid 89 Access logging analysis of 24 AuditTrailID 118 BEGIN/END LOGGING statements 114 database level 116 DBC.AccessLogRule table 115 DBC.AccLogTbl table 115 deleting log entries 121, 122 disabling 117 guidelines for use 113 locating log entries 115 MODIFY statement 117 proxy users 119 session views 123 system view queries 123 table level 116 user level database users 113 directory users 118, 217 users forced off system 123 viewing log entries 122 Access rights, see Database Privileges Accounts description 38 use in logon string 70 Active Directory (also ADAM) automatically generated attributes 219 determining schema naming context 290 directory objects unique to 220 installing Teradata schema extensions 256 setup kerberos for Teradata Database on Unix 313 special directory objects 223 support of 198 ADAM, see Active Directory allow element 342 in a permissive filter 344, 352 in a restrictive filter 344, 354 AnonymousAuthentication property 158 app_user_name element 42 Appended domain name 68 use in logging directory users 119 appliesto element 342 Attributes, of Teradata directory objects 219 Auditing database access, see Access logging Authentication definition 22 directory 209 external 52 Teradata Database 73 AuthenticationSupported property 145 AuthorizationSupported property description, editing guidelines 146 use with configured directory 212, 213 use with unconfigured directory 211, 213 Automatic privileges 49 B BAR Encryption 63 BEGIN LOGGING statement 114, 116, 117, 121 errors 117 logging parameters 114 Binding available options 198 DIGEST-MD5 binds 198 service binds 199 anonymous binds 202 authenticated user binds 200 LDAP properties, supporting 200 simple binds 199 C Certificate chain 298 Certificate hashes 302 Certificate, security 296 Child, definition 44 Clauses WITH GRANT OPTION 45, 232 WITH NULL PASSWORD 53, 69, 74, 121, 146, 211, 232 WITH ROLE 42 WITHOUT ROLE 42 clockskew 324 cn (Common Name) attribute 219, 220 Security Administration 385

Index Command line logons 73 Confidentiality 61 ConfidentialityDesired property 156 Containers, creating and inserting objects in 266 CREATE DATABASE statement 49, 117 CREATE PROFILE statement 40 CREATE ROLE statement 100, 215 CREATE USER statement 31, 32, 35, 37, 49, 66, 93, 117 Creator privileges 49 CredentialUsage property 161 D Data Dictionary access log entries 122 use in security administration 120 Data encryption 63 Data integrity 63 Database administrator 36 Database privileges 43 assign using GIVE 44 assign using GRANT and REVOKE 45 automatic 49 creator privileges 49 explicit 45 listing in DBC.UserRightsV 121 mapped directory users 213 modifier privileges 49 unmapped directory users 213 DBC user DBC 31 locked out 103 privileges not automatically granted 45 DBC.AccLogRulesV 121 DBC.AccLogRuleTbl table 115 DBC.AccLogTbl table 121 DBC.AccLogV 121 DBC.AllRightsX 121 DBC.AllRoleRightsV 121 DBC.DBase table 66, 121 DBC.DeleteAccessLogV 121 DBC.LogOnOffX 121, 122, 123, 124 DBC.LogonRulesV 121, 123 DBC.LogonRulesX 124 DBC.OldPasswords table 105, 106 DBC.ProfileInfoX 122 DBC.RoleInfoX 121 DBC.RoleMembersX 121 DBC.SecurityLogX 121 DBC.SessionInfoX 123, 124 example query 125 DBC.SessionTbl table 118, 217 DBC.SysSecDefaults table 35, 40, 93, 97 DBC.UserGrantedRightsV 121 DBC.UserRightsV 121 DBC.UserRoleRightsV 122 DBC.UsersV 121 DBC.UsersX 66, 96 DBCRestrictedWordsV 122 DBCSecurityDefaultsV 122 DBSControl utility 54 DefaultMechanism property 149 defaultnamingcontext, obtaining 285 DelegateCredentials property 152 Delegated credentials, during external authentication 55 DELETE FROM statement 121 DELETE statement 122 deny element 342 in a permissive filter 344, 351 in a restrictive filter 344, 354 description attribute 219 DesiredContextTime property 159 DesiredCredentialTime property 160 DHKeyG property 188 DHKeyP property 188 DIPACC DBCSQL script 114 Directories configuring 217 objects, see Directory objects schema extensions description 217 installing 255 supported 197 Directory Information Tree (DIT) 210, 215, 217, 218, 219, 262 populating 265 Teradata Database objects in 262 verify mapping in 271 Directory integration, preliminary system check 224, 245 Directory management tools 291 ldapadd 265 ldapmodify 258, 261, 265 ldapsearch 257, 272, 273, 282 LDIFDE 256, 257, 258, 265, 291 location of files and documentation 129 tdsbind 272, 274, 279, 281 Directory object attributes 219 cn (Common Name) 220 cn (Common Name) attribute 219 description 219 tdatallowdeny 219 tdatallowedip 220 tdataprofilemember 219 tdatdeniedip 220 tdatipfiltermember 220 tdatipfiltermemberof 220, 223 tdatprofilemember 220 tdatprofilememberof 220, 223 386 Security Administration

Index tdatrolemember 219, 220 tdatrolememberof 220, 223 tdatusermember 219, 220 tdatusermemberof 220, 223 usage requirements 220 Directory object classes 218 Directory objects 218 attributes, see Directory object attributes special, for Active Directory and ADAM 223 tdatcontainer 218, 221 tdatipfilter 218 tdatipfilterr 222 tdatprofile 218, 222 tdatrole 218, 222 tdatrootnode 218, 221 tdatsystem 218, 221, 265 tdatuser 218, 221 Directory search optimization using identity map 202 using identity searches 205 using referral chasing 224 Directory sign-on 75 Directory user management authentication only 210 authorization (mapped users) 211 Directory users access logging of 118, 217 AuditTrailId 217 mapping to database users 213, 269 mapping, verification of 271 ownership of database objects 214 profiles 215, 216 roles 39, 215 DISPLAY POOL statement 124 Domain name appended 68, 119 in logon string 67 Domain Name System (DNS) 314 Domain user name, in logon string 67 DROP DATABASE statement 117 DROP MACRO statement 118 DROP ROLE statement 215 DROP USER statement 104, 117 E EGD 183 Elements GRANT CONNECT THROUGH syntax app_user_name 42 perm_user_name 42 trusted_user_name 41 IP filter syntax, see IP filters Encryption 66 BAR 63 data 63 from a replication system 87 network traffic 63 of logon string 61 END LOGGING statement 114, 115, 117 Errors directory logons or mapping 272, 278 incorrect dropping of EXTERNAL ROLE 215 mechanism unavailable at logon 137 UPN logons 80, 84 when checking mapping using tdsbind 281 when checking mapping with tdsbind 281 EXECUTE statement 116 Expired password effects of LockedUserExpire 106 resetting 102 ExpirePassword parameter 102 External authentication description 52 from channel-attached clients 55 setup requirements and options 53 55 sign-on as 52 single sign-on 74 with delegated credentials 55 External roles 39, 46, 215, 216 EXTUSER access logging 217 database privileges 213 logon 77 privileges 46 set up 211 F FAT, compatibility with TeraGSS 128 File maintenance tools tdgsspkgrm 130 tdgssversion 131 G Gateway Control utility 54 GenerateCredentialFromLogon property 147 GIVE statement 44 GRANT CONNECT THROUGH statement 39, 41, 42, 46, 57, 58 syntax elements 41 GRANT LOGON statement 121 GRANT statement 38, 45, 46, 117 forms of 45 GRANT/REVOKE LOGON statements, precedence of clauses 89 Security Administration 387

Index H Hostid use for access control 89 see also GRANT LOGON or REVOKE LOGON statement Hosts, multiple, logon permission 88 I Identity map 202 authcid form 204 in combination with identity search 206 UPN form 204 with DIGEST-MD5 binding 209 Identity search 205 Inserting objects into containers 266 Integrity 61 IntegrityDesired property 157 IP access restrictions conversion utilities 363 database implementation concepts 340 design 339 xml setup procedures 339 description 91, 337 directory implementation 359 check setup with tdsbind 279 creating a tdatcontainer 268 creating IP restriction objects in the directory 359 loading IP schema extensions 256, 359 mapping IP filters to database users 271 effect on pre-existing session 338 schema object attributes tdatallowdeny 219, 361 tdatallowedip 220, 361 tdatdeniedip 220, 361 tdatipfiltermember 220, 362 tdatipfiltermemberof 220, 223 schema objects ipfilters 360 system 360 tdat 360 tdatipfilter 361 tdatipfilterext 223 user 360 users 360 usage constraints 337 IP filters application to a user in an xml document 355 application to all users 358 elements allow 342 appliesto 342 deny 342 ipfilter 341 ipfilters 341 system 341 tdat 340 user 341 users 341 mapping to Teradata Database users 271, 362 masks 345 effect 345 in a permissive filter 351 in a restrictive filter 354 ina permissive filter 352 interaction between primary and secondary 347 properties 346 structure 345 permissive filters 350 processing when multiple filters exist 357 restrictive filters 352 ipdir2bin utility 364 ipxml2bin utility 357, 363 J Jar update command 134, 238 Java, setting the classpath 134 K Kerberos multiple LAN adapter restriction 139 mutual authentication 153 software description 319 Kerberos authentication 52, 53, 86, 139 KRB5 mechanism 139 sign-on as 81 single sign-on 74 special setup for Teradata Database on Unix 255, 313 Kerberos configuration file 320 Kerberos keys 317, 318, 327 Kerberos utilities kinit 326, 334 klist 334 kutil 329 rpm 320 Key Distribution Center (KDC) 317 Keytab file 317 kinit utility 326, 334 klist utility 334 krb5.conf configuration file 320 on Linux 323 on MP-RAS 321 test procedure 326 ktpass 317 kutil utility 329 388 Security Administration

Index L LDAP binding properties 172 directory authentication properties 162 logon formats 76 mechanism description 141 protection properties 176 search optimization properties 224 ldapadd tool 265 LdapBaseFQDN property 166 LdapClientCACertDir property configuring for certificate authentication 303 LdapClientDebug property 169 LdapClientDeref property controlling referral chasing 225 description, editing guidelines 170 LdapClientMechanism property 172 LdapClientRebindAuth property 171 LdapClientReqCert property configuring for certificate authentication 303 LdapClientSASLSecProps property 186 LdapClientTlsCACert property 177 LdapClientTlsCACertDir property 178 LdapClientTlsCert configuring mutual authentication 307 LdapClientTlsCert property 179 LdapClientTlsCipherSuite property 180 LdapClientTlsCRLCheck property 180 LdapClientTlsKey configuring mutual authentication 307 LdapClientTlsKey property 182 LdapClientTlsRandFile property 183 LdapClientTlsReqCert property 184 LdapClientUseTLS property 185 LdapGroupBaseFQDN property description, editing guidelines 167 use in optimizing directory searches 225 ldapmodify tool 258, 261, 265 ldapsearch tool 257, 272, 273 common errors 250 description 282 determining the schemanamingcontext 290 finding user information 285 options 282 usage notes 284 use in finding the RootDSE 247 user authentication test 249 using 282, 284 LdapServerName property 162 LdapServerPort property 164 LdapServerRealm property 165 LdapServiceBindRequired property 173 LdapServiceFQDN property 174 LdapServicePassword property 175 LdapSystemFQDN property 166 LdapUserBaseFQDN property description, editing guidelines 168 use in optimizing directory searches 225 LDIFDE 256, 257, 258, 265 Library Configuration file 133 Locked out user 104 LockedUserExpire parameter 106 Logging, see Access logging Logoff view logoff activity 121 Logon character set considerations 70 elements 65 examples command line 73 GUI 84 LDAP authcid 76 Single Sign-on 74 Teradata authentication 73 format requirements 72 from a Teradata Database node 86 from channel-attached clients 86 how to release lock due to failed logon 104 LDAP logon 75 maximum attempts 103 parameters 72 password requirements 69 security mechanism selection 65 setting maximum attempts 104 sign-on as 81 single sign-on 74 size limit 65 through Teradata Query Director 85 to a replication system 86 to Teradata Dynamic Workload Manager 37 view logon activity 121 Logon controls 88 active controls, DBC.LogonRulesV 121 by IP address see IP Access restrictions error handling options 88 setting maximum logon attempts 103 M Macros use for access control 50 Mapping directory users to Teradata Database objects 269 Masks effect on IP filters 345 in a permissive filter 351, 352 in a restrictive filter 354 Security Administration 389

Index interaction between primary and secondary 347 properties 346 structure 345 MaxLogonAtttempts parameter 103 maxssf 186 Mechanism properties adding a property 192, 193 description 144 editing property values 128, 135, 190, 192 special handling for new properties 144 types basic functional properties 145 confidentiality properties 187 directory user authentication properties 162 LDAP binding properties 172 LDAP protection properties 176 mechanism status properties 149 operational properties 152 Mechanism selection 135 MechanismEnabled property 150 MechanismRank property 151 Mechanisms capabilities 135 default 136 define the security context 135 handling of selection request 136 properties, see Mechanism properties selection 135 types 137 KRB5 139 LDAP 141 NTLM 140 SPNEGO 143 Teradata Method 2 (TD 2) 138 unavailable mechanism error 137 Mechanisms properties editing property values 195 Migration, effects on TDGSS configuration 194 minssf, quality of protection setting 62, 186 Modifier privileges 49 MODIFY PROFILE statement 40 MODIFY statement access logging 117 MODIFY USER statement 38, 95, 104 Modifying passwords 96 Monitoring system security, see Access logging MutualAuthentication property 153 N Network security 36, 228 Network Time Protocol (NTP) 330 Novell edirectory installing Teradata schema extensions 261 support of 198 nslookup 327 NTFS compatibility with TeraGSS 128 NTLM mechanism 140 specification for sign-on as 82 use for single sign-on 74 use of appended domain name 68 ntp.conf configuration file 330 O OpenLdap tunables related LDAP mechanism properties 176 use of TLS_CACERTDIR 181 use of TLS_CACERTFILE 178 OpenSSL utility Utilities OpenSSL 294 Operating system restrictions 36, 228 security controls 36, 228 special privileges 36, 228 OutOfSequenceDetection property 155 Ownership based on space allocation 37 basis for GRANT/REVOKE privileges 45 definition 44 differences in owner and creator privileges 49 parent-child hierarchy 34 user DBC 32 P PAM 326 Parent-child, hierarchy of ownership 44 Password allowable characters 93 control 101 expiration 102 history 106 modifying 96 release lock 104 resetting expired 102 restricted words 110, 367 reuse 105 temporary 95 Password control methods using profiles 40 Password control parameters current defaults in DBC.SysSecDefaults table 97 ExpirePassword 102 LockedUserExpire 106 MaxLogonAtttempts 103 PasswordDigits 108 PasswordMaxChar 107 390 Security Administration

Index PasswordMinChar 107 PasswordRestrictedWords 110 PasswordReuse 105 PasswordSpecChar 108 Password controls format 98 resetting 101 resetting for specific users 99 resetting global values 98 Password format error messages 112 for Japanese systems 94 password values, setting 98 requirements 93 Password lockout time 106 Password restricted words, see Restricted words, in passwords 367 PasswordDigits parameter 108 PasswordMaxChar parameter 107 PasswordMinChar parameter 107 PasswordRestrictedWords parameter 110 PasswordReuse parameter 105 PasswordSpecChar parameter 108 Peer certificate 308 Performance group, inclusion in account string 70 perm_user_name element 42 Permissive filters 350 Physical access control 227 pkginfo utility 319 Private key 305 Privileges, see Database Privileges PRNGD 183 Profiles 40 defined 40 for directory users 216 use in managing password security 40 Protection 61 BAR encryption 63 data encryption 63 logon encryption 61 password encryption 62 SASL for DIGEST-MD5 binds 62 SSL setup 295 SSL/TLS for simple binds 62 TLS setup 295 Proxy users access logging 119 description 41 GRANT CONNECT THROUGH privilege 46 use of roles 39 PROXYROLE, query banding option 42 Q Queries, monitor-related 123 Query Director allowable logon mechanisms 135 required mechanism property settings 85 R Referral chasing 225 RELEASE PASSWORD LOCK statement 95 ReplayDetection property 154 Replication systems allowable logon mechanisms 135 encryption 87 logon from 86 Restricted words, in passwords 40 default restricted words 367 using the PasswordRestrictedWords parameter 98, 110 Restrictive filters 352 REVOKE LOGON statement 121 REVOKE statement 45, 46 forms of 45 Revoking privileges for database users 45 from PUBLIC and ALL DBC 48 Roles 38 CREATE ROLE statement 100 DBC.RoleMembersX 121 external roles 46, 215 for proxy users 39 members of 121 privileges granted to 121 switching 216 rpm utility 320 S SASL protection 61, 62, 186 Schema extensions 217 installation on Active Directory and ADAM, with Unix nodes 258 on Active Directory and ADAM, with Windows nodes 256 on Sun Java System Directory Server 260 Schema naming context, determining 290 Schema objects creating containers 266 types 218 Scripts, DIPACC DBCSQL 114 Security computer room 227 determining appropriate level 26 LAN server 36, 228 network controls 36, 228 Security Administration 391

Index operating system 36, 228 remedial actions 24 SYSTEMFE 228 Teradata Database files 36, 228 Security administrator 34 assigning privileges to 35 duties 27, 29 setup for Common Criteria compatibility 230 Security certificate 296 Security handbook 28, 135 Security hazards detecting 23 eliminating common hazards 232 Security levels advantages and disadvantages 27 C2 level 229 operating a system at Common Criteria level 229 Security mechanisms, see Mechanisms Security policy enforcing 228 establishing 227 re-evaluating 29 site-specific 28 SELECT ROLE statement 119 SELECT statement 123 SELECT USER statement 118 Service binds 199 anonymous 202 authenticated 200 related mechanism properties 200 Service Principal Name (SPN) 316 Session, establishing 23 SET QUERY BAND 42 SET ROLE ALL statement 38, 216 SET ROLE EXTERNAL Statement 216 SET ROLE statement 38, 213, 216 SET SESSION DATABASE statement 214 Sign-on as 52, 81 Single sign-on, example 74 SingleSignOnSupported property 148 Space allocation 37 SPNEGO mechanism 143 SSL protection 61, 62, 198 configuration errors 308 minimum required software versions 293 setup 295 while testing schema installations 261 while using ldapsearch 283 Statements BEGIN LOGGING 114, 116, 117, 121 CREATE DATABASE 49, 117 CREATE PROFILE 40 CREATE ROLE 215 CREATE USER 31, 32, 35, 37, 49, 66, 93, 117 DELETE 122 DELETE FROM 121 DISPLAY POOL 124 DROP DATABASE 117 DROP MACRO 118 DROP ROLE 215 DROP USER 104, 117 END LOGGING 114, 115, 117 EXECUTE 116 GIVE 44 GRANT 38, 45, 46, 117 GRANT CONNECT THROUGH 39, 41, 42, 46, 57, 58 GRANT LOGON 121 MODIFY PROFILE 40 MODIFY USER 38, 95, 104 RELEASE PASSWORD LOCK 95 REVOKE 45, 46 REVOKE LOGON 121 SELECT 123 SELECT ROLE 119 SELECT USER 118 SET ROLE 38, 213, 216 SET ROLE ALL 38, 216 SET ROLE EXTERNAL 216 SET SESSION DATABASE 214 UPDATE 104, 106, 107, 108, 110, 111 Stored procedures, use for access control 50 system element 341 System identifier, see tdpid 69 system object 360 SYSTEMFE, security 228 T Tables DBC.AccLogTbl 115, 121 DBC.DBase 66, 121 DBC.OldPasswords 105 DBC.SessionTbl 118, 217 DBC.SysSecDefaults 35, 40, 93 DBCAccLogRuleTbl 115 DBCOldPasswords 106 tdat element 340 tdatallowdeny attribute 219, 361 tdatallowedip attribute 220, 361 tdatcontainer object 218, 221 266 similarity to IP filter users element 360 tdatdeniedip attribute 220, 361 tdatgroupext object 223 tdatipfilter object 218, 222, 361 tdatipfilterext object 223 tdatipfiltermember attribute 220, 362 in Active Directory applications 223 392 Security Administration

Index tdatipfiltermemberof attribute 220, 223 in Active Directory applications 223 tdatprofile object 218, 222 tdatprofilemember attribute 219, 220 in Active Directory applications 223 tdatprofilememberof attribute 220, 223 in Active Directory applications 223 tdatrole object 218, 222 tdatrolemember attribute 219, 220 in Active Directory applications 223 tdatrolememberof attribute 220, 223 in Active Directory applications 223 tdatrootnode object 218, 221, 360 tdatsystem object 218, 221, 265 tdatuser directory object 221 tdatuser object 218 tdatuserext object 223 tdatusermember attribute 219, 220 in Active Directory applications 223 tdatusermemberof attribute 220, 223 in Active Directory applications 223 TDGSS application programmer interface 129 C++ and Java application sharing of configuration files 134 changinng the configuration on clients 238 on Teradata Database server 195 client version, see TeraGSS configuration files, reading and editing 133 description 127 file location 129 file maintenance tools 130 files contained in 129 installation 128 jar update command (on clients) 238 Library Configuration file 129, 133 reversion after configuration change 243 security mechanisms 137 User Configuration file 129, 133, 190 tdgssconfig tool file location 129 use 320 tdgsspkgrm tool 130 tdgssuserconfigfile.xml 86, 192 adding new mechanisms or properties 193 editing 128, 135 effects of upgrade and migration on 194 jar update command 134 location of file 130 setting the default mechanism 136 use in setting the Java classpath 134 use in setting up Kerberos 320 tdgssversion tool 130, 131 file location 129 Tdpid, in logon string 69 tdsbind 272, 274, 279, 281 error output 281 file location 129 output, analysis of 277 procedure for use 274 use in testing IP access restrictions 279 mapped directory user 279 unmapped directory user 277 Teradata Director Program 86 Teradata Dynamic Workload Manager, controlling access to 37 Teradata Method 2 (TD 2) 138 Teradata Query Director logons through 73, 85 use with IP access restrictions 338 TeraGSS change versions 132 determine current version 130 for channel-attached clients 128 for network-attached clients 128 remove a version 131 User Configuration file for 190 view available versions 131 TLS protection 61, 62 configuration errors 308 minimum required software versions 293 setup 295 while testing schema installations 261 tpareset -f 320 Trusted Sessions access logging 119 CONNECT THROUGH privilege 58 CTCONTROL privilege 57 Establishing 56 Privileges 57 security considerations 58 trusted_user_name element 41 U UPDATE statement 104, 106, 107, 108, 110, 111 Upgrade, effects on TDGSS configuration 194 UPN logons errors 80, 84 kerberos/ntlm 81 URI 162 User Configuration file 133, 190 editing 190 reading 190 User configuration file 128 User DBC automatic privileges 49 Security Administration 393

Index privileges not automatically granted 45 user element 341 User groups, common 25 User name 66 user object 360 Users access needs, identifying 25 accounts 38 administrative 33 database administrator 36 DBC 31 DBC.UserRoleRightsV 122 DBC.UsersV 121 directory 209 mapped to database users 213 explicit privileges, list of 121 guidelines for creating 32 hierarchy 34 identification options 202 information about 121 security administrator 34 system generated 31 users element 341 users object 360 UTF-16 characters in logon string 70 W WITH GRANT OPTION clause security warning for use 232 use with GRANT statement 45 WITH NULL PASSWORD clause 69, 74, 146 in DBC.LogOnRulesX 121 requirement for external authentication 53 security concerns 232 with directory authentication 211 WITH ROLE clause 42 WITHOUT ROLE clause 42 V VerifyDHKey property 187 Views DBC.AccLogRulesV 121 DBC.AllRightsX 121 DBC.AllRoleRightsV 121 DBC.DeleteAccessLogV 121 DBC.LogOnOffX 121, 122, 123, 124 DBC.LogonRulesV 121, 123 DBC.LogonRulesX 124 DBC.ProfileInfoX 122 DBC.RoleInfoX 121 DBC.RoleMembersX 121 DBC.SecurityLogX 121 DBC.SessionInfoX 123, 124 DBC.UserGrantedRightsV 121 DBC.UserRightsV 121 DBC.UserRoleRightsV 122 DBC.UsersV 121 DBC.UsersX 66, 96 DBCAccLogV 121 DBCRestrictedWordsV 122 DBCSecurityDefaultsV 122 queries for accessing 123 session-related 123 use for access control 50 394 Security Administration