Security Administration

Teradata Database

Security AdministrationRelease V2R6.2

B035-1100-096ASeptember 2006

The product described in this book is a licensed product of Teradata, a division of NCR Corporation.

NCR, Teradata and BYNET are registered trademarks of NCR Corporation.

Adaptec and SCSISelect are registered trademarks of Adaptec, Inc.

EMC, PowerPath, SRDF, and Symmetrix are registered trademarks of EMC Corporation.

Engenio is a trademark of Engenio Information Technologies, Inc.

Ethernet is a trademark of Xerox Corporation.

GoldenGate is a trademark of GoldenGate Software, Inc.

Hewlett-Packard and HP are registered trademarks of Hewlett-Packard Company.

IBM, CICS, DB2, MVS, RACF, OS/390, Tivoli, and VM are registered trademarks of International Business Machines Corporation.

Intel, Pentium, and XEON are registered trademarks of Intel Corporation.

KBMS is a registered trademark of Trinzic Corporation.

Linux is a registered trademark of Linus Torvalds.

LSI, SYM, and SYMplicity are registered trademarks of LSI Logic Corporation.

Active Directory, Microsoft, Windows, Windows Server, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

Novell is a registered trademark of Novell, Inc., in the United States and other countries. SUSE is a trademark of SUSE LINUX Products GmbH, a Novell business.

QLogic and SANbox are registered trademarks of QLogic Corporation.

SAS and SAS/C are registered trademark of SAS Institute Inc.

Sun Microsystems, Sun Java, Solaris, SPARC, and Sun are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. or other countries.

Unicode is a registered trademark of Unicode, Inc.

UNIX is a registered trademark of The Open Group in the US and other countries.

NetVault is a trademark and BakBone is a registered trademark of BakBone Software, Inc.

NetBackup and VERITAS are trademarks of VERITAS Software Corporation.

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 NCR CORPORATION (NCR) 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 NCR intends to announce such features, functions, products, or services in your country. Please consult your local NCR 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. NCR 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: [email protected]

Any comments or materials (collectively referred to as “Feedback”) sent to NCR will be deemed non-confidential. NCR 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, NCR 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 © 2002--2006 by NCR Corporation. All Rights Reserved.

mailto:[email protected]

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 users defined in supported directories with Teradata Database users, 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 V2R6.2.

Security Administration iii

PrefaceChanges to This Book

Changes to This Book

This book includes the following changes to support the current release:

Date Description

September 2006 • Added information on access restrictions by IP address to Chapters 2, 6, and the new Appendix D.

• Added information on LDAP referral chasing to Chapters 2 and 5.

• Revised the procedures for changing the TDGSS configuration and distributing it to the nodes in Chapter 5.

• Added information on new password encryption option in Chapter 2.

• Added information on LDAP support for UPN logons to Chapter 2.

December 2005 General update to clarify compatibility among versions of Teradata Database and Teradata Tools and Utilities.

November 2005 • Extensively reorganized the sections on passwords and added new material on password control options in Chapter 2: “Logon Security.”

• Added material on delegated credentials.

• Added material on replication security.

• Revised sections on external authentication and LDAP to include the provision for LDAP logons without the need to configure the directory.

• Added information on changes to EXTUSER

• Revised the sections on editing the tdgssUserConfiguration files and running the tdgssconfig tool in Chapter 5: “Managing Network Security.”

January 2005 • Added Appendix C: “Preparing for Directory Integration--System Evaluation Tasks.”

• Revised the section on “External Authentication for Network-Attached Clients” on page 37.

• Revised the editing criteria for several mechanism properties, as shown in “Making TDGSS Configuration Changes on Teradata Database Servers” on page 157.

November 2004 • Reorganized and made minor revisions to existing material.

• Extensively revised Chapter 2: “Logon Security.”

• Added Chapter 5: “Managing Network Security.”

• Added Chapter 6: “Using a Directory to Manage Database Users.”

iv Security Administration

PrefaceAdditional Information

Additional Information

Additional information that supports this product and the Teradata Database is available at the following Web sites.

Type of Information Description Source

Overview of the release

Information too late for the manuals

The Release Definition provides the following information:

• Overview of all the products in the release

• Information received too late to be included in the manuals

• Operating systems and Teradata Database versions that are certified to work with each product

• Version numbers of each product and the documentation for each product

• Information about available training and support center

http://www.info.ncr.com/

Click General Search. In the Publication Product ID field, enter 1725 and click Search to bring up the following Release Definition:

• Base System Release DefinitionB035-1725-096K

Additional information related to this product

Use the NCR Information Products Publishing Library site to view or download the most recent versions of all manuals.

Specific manuals that supply related or additional information to this manual are listed.


Click General Search, and do one of the following:

• In the Product Line field, select Software - Teradata Database for a list of all of the publications for this release,

• In the Publication Product ID field, enter one of the following book numbers:

• Database AdministrationB035-1093-096A

• SQL Reference: Data Definition StatementsB035-1144-096A

• Teradata Director Program ReferenceB035-2416-096A

CD-ROM images This site contains a link to a downloadable CD-ROM image of all customer documentation for this release. Customers are authorized to create CD-ROMs for their use from this image.


Click General Search. In the Title or Keyword field, enter CD-ROM, and click Search.

Ordering information for manuals

Use the NCR Information Products Publishing Library site to order printed versions of manuals.


Click How to Order under Print & CD Publications.

Security Administration v

http://www.info.ncr.com




PrefaceAdditional Information

Scope

Because it is not possible to separate the subject of security from related administrative topics, not all information of interest to security administrators is found in this book. Security Administration does attempt to cover all basic security concepts, as well as some of the details. However, some of the details on which security depends have been delegated to other books.

The following table provides a map to locations of related topics within the Teradata Database user documentation library:

General information about Teradata

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

Type of Information Description Source

For information about... Refer to...

• the basic structure and function of Teradata Database

• how Teradata Database security fits into the basic structure

Introduction to Teradata Warehouse

setting up users, databases, roles, profiles, and other security-related administrative tasks

Database Administration

the syntax and usage of Teradata Structured Query Language (SQL) to set up and alter security parameters

SQL Reference: Data Definition Statements

dictionary tables that contain information about users, roles, profiles, access logging and other security-related topics

Data Dictionary

programming the logon and security exits in the Teradata Director Program.

Teradata Director Program Reference

logon and security requirements for specific Teradata Client applications

The Users Guide for that application

vi Security Administration

http://www.teradata.com

PrefaceReferences to Windows

References to Windows

This book refers to “Microsoft Windows.” For Teradata Database V2R6.2, such references mean Microsoft Windows Server 2003 32-bit and Microsoft Windows Server 2003 64-bit.

Security Administration vii

PrefaceReferences to Windows

viii Security Administration

Table of Contents

Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii

Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii

Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii

Supported Software Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii

Changes to This Book. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv

Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .v

References to Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Chapter 1: Introduction to Teradata Database System Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

Security Controls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

Controlling Physical Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

Controlling Database Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

Transmitting Secure Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

Monitoring System Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

Determining Security Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

Security Administrator Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

Business Value of Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

Identifying Users and Their Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

Determining the Level of Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

Formulating Security Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Site-specific Teradata Database Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Re-evaluating Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Chapter 2: Logon Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

Logon Elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

Security Mechanism Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Database User Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Directory User Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Security Administration ix

Table of Contents

Domain User Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

Domain/Realm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

Appended Domain Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

Hostid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

Tdpid. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

Account String . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

Using UTF-16 Characters in the Logon String . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

Network Logon Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

Command Line Logons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

Logon Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

Logons Using Teradata Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

Logons Using External Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

Single Sign-on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

LDAP Logons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

UPN Logons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

LDAP UPN Logons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

Sign-on As Using Kerberos/NTLM UPN Logons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28

GUI Logons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30

Logons Through Teradata Query Director. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

Logons from Channel-Attached Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

Logons from Teradata Database Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

Replication Logons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

Encryption of Replication Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

Related Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

Logon Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34

Granting and Revoking Logons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34

Description of GRANT/REVOKE LOGON Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . .34

Rules for Submitting GRANT/REVOKE LOGON Statements . . . . . . . . . . . . . . . . . . . . . .34

Precedence of Clauses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

Controlling Access with Hostids. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

Restricting Logons by IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36

External Authentication for Network-Attached Clients. . . . . . . . . . . . . . . . . . . . . . . . . . . .37

External Authentication for Channel-Attached Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . .40

Related Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

Managing Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42

Creating Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42

Password Format Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43

Modifying Passwords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45

Password Control Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

Password Controls in DBC.SysSecDefaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

x Security Administration

Table of Contents

Re-Setting Password Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Using UPDATE to Reset Password Controls in DBC.SysSecDefault . . . . . . . . . . . . . . . . 48

Using CREATE or MODIFY PROFILE to Reset Password Controls . . . . . . . . . . . . . . . . 48

Setting Password Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

ExpirePassword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

MaxLogonAttempts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

PasswordReuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

LockedUserExpire (Password Lockout Time). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

PasswordMinChar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

PasswordMaxChar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

PasswordDigits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

PasswordSpecChar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Chapter 3: Managing Data Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

User DBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

User DBC Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

User DBC Warning!. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Establishing Administrative Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

System Administrator User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Security Administrator User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Typical Privileges Granted to a Security Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Controlling Access to the Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Controlling Access to Dump Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Controlling Access to Teradata Dynamic Workload Manager . . . . . . . . . . . . . . . . . . . . . 63

Users and Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Space Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Owners and Parents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Object Ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Giving Ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Related Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Access Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Ownership Rights. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Automatic Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Explicit Rights. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Using GRANT and REVOKE to Control Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Forms of the GRANT Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Examples Using GRANT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Security Administration xi

Table of Contents

Forms of the REVOKE Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70

Revoking Privileges from PUBLIC or ALL DBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71

Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72

Advantages of Using Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72

Using EXTUSER to Provide Limited Database Access to Directory Users . . . . . . . . . . . . . . . .73

Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73

Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73

Advantages of Using Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73

Using Profiles to Control User-Level Password Security . . . . . . . . . . . . . . . . . . . . . . . . . . .74

Chapter 4: Monitoring Access to Teradata Database . . . . . . . . . .75

Security Information in the Data Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75

System Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75

System View Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77

MONITOR Related Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77

Access Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78

Overview of Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78

Access Logging of Directory Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78

General Rules for Using DDL Statements in Access Logging . . . . . . . . . . . . . . . . . . . . . . .78

Security Macro Privilege Checking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79

System Default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79

BEGIN/END LOGGING Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79

Logging Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80

DBC.AccLogRuleTbl Entries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80

DBC.AccLogTbl Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80

Database-Level Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81

Table Level Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81

Using BEGIN LOGGING With GRANT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82

Viewing Log Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82

Using END LOGGING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82

Purging Aged Log Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82

DBC.AccLogRule Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83

Access Logging and Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83

Changing Logging Options With MODIFY USER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83

Using Account String Expansion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84

xii Security Administration

Table of Contents

Chapter 5: Managing Network Security . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Logon Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Enhanced Password Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Related Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Network Traffic Encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Related Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Data Integrity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Mechanisms Define the Security Context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Mechanism Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Default Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Mechanism Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Support for External Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

TDGSS Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

TDGSS Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Versions and Version Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Locating TDGSS Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

TDGSS File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

TDGSS Site File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

C/C++ and Java Application Sharing of TDGSS Configuration Files . . . . . . . . . . . . . . . . . . . 94

Setting the Java Application Classpath. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Using the Jar Update Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

TDGSS File Maintenance Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

tdgsspkgrm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

tdgssversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

TDGSS Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

TDGSS Legal Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Configuration File Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

AlgorithmName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

KeyLength . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

InterfaceType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

AlgorithmType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

MechanismProperties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

TDGSS Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

TDGSS Quality of Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

TDGSS Security Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Related Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Teradata Method1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Teradata Method 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Security Administration xiii

Table of Contents

Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120

NTLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122

LDAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122

Changing the TDGSS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124

Mechanism Property Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124

Differences in Function for Client and Server Configuration Files. . . . . . . . . . . . . . . . . .125

General Rules for Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126

AuthenticationSupported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128

AuthorizationSupported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129

SingleSignOnSupported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130

MechanismEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131

MechanismRank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132

DefaultMechanism. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133

DelegateCredentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134

MutualAuthentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135

ReplayDetection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136

OutOfSequenceDetection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137

ConfidentialityDesired . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138

IntegrityDesired . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139

AnonymousAuthentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140

DesiredContextTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141

DesiredCredentialTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142

CredentialUsage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143

LdapServerName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144

LdapServerPort. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144

LdapServerRealm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145

LdapSystemFQDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147

LdapBaseFQDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147

LdapGroupBaseFQDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148

LdapUserBaseFQDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .149

LdapClientReferrals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .150

LdapClientDeref. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151

LdapClientDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152

LdapClientRebindAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153

VerifyDHKey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154

DHKeyP and DHKeyG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155

Making TDGSS Configuration Changes on Teradata Database Servers . . . . . . . . . . . . . . . . .157

Planning A Configuration Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157

Changing the TDGSS Configuration for Teradata Database on Windows . . . . . . . . . . .158

Changing the TDGSS Configuration for Teradata Database on Linux . . . . . . . . . . . . . .159

Changing the TDGSS Configuration for Teradata Database on MP-RAS . . . . . . . . . . . .160

Making TDGSS Configuration Changes on Teradata Clients . . . . . . . . . . . . . . . . . . . . . . . . .161

Changing the TDGSS Configuration on Windows Clients . . . . . . . . . . . . . . . . . . . . . . . .162

xiv Security Administration

Table of Contents

Changing the TDGSS Configuration on Linux Clients . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Changing the TDGSS Configuration on non-Linux UNIX Clients . . . . . . . . . . . . . . . . 164

Reversion Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Using dumpcfg to Check the Current TDGSS Configuration . . . . . . . . . . . . . . . . . . . . . 165

Chapter 6: Using a Directory to Manage Database Users . . 169

Supported Directories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

User Management Strategies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Option 1: Authentication Only--No Directory Schema Changes . . . . . . . . . . . . . . . . . . 171

Option 2: Mapping Directory Users to Database Users, Roles, and Profiles . . . . . . . . . 172

Option 3: Enhanced Security -- Restricting User Access by IP Address . . . . . . . . . . . . . 173

Related Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Directory User Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Characteristics of Unmapped Directory Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Characteristics of Directory Users Mapped to Permanent Users . . . . . . . . . . . . . . . . . . 175

Ownership of Database Objects Created by Directory Users. . . . . . . . . . . . . . . . . . . . . . 176

Roles and Profiles for Directory Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Database Administration of External Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Directory Administration of External Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Session Role Hierarchy and Role Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Effects of ‘Drop External Role’ on Directory User Roles . . . . . . . . . . . . . . . . . . . . . . . . . 178

Effects of Changing Directory Role Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Profiles for Directory Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Related Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Access Logging of Directory Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

Configuring a Directory to Support Authentication and Authorization of Database Users 180

Directory Schema Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Teradata Schema Extensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Attribute Usage Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

Special Objects and Attributes Required For Active Directory . . . . . . . . . . . . . . . . . . . . 187

System Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Installing Teradata Schema Extensions in a Supported Directory . . . . . . . . . . . . . . . . . . . . . 189

Schema Installation Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Installation on Active Directory from Teradata Database on Windows. . . . . . . . . . . . . 190

Installation on Active Directory from Teradata Database on MP-RAS or Linux . . . . . 192

Installation on Sun Java System Directory Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Directory Information Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Teradata Database Objects in the DIT Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Security Administration xv

Table of Contents

Populating the Directory Information Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .199

tdatRootNode Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .199

tdatSystem Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .199

Creating Containers and Inserting Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200

Naming Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200

Entering Container and Object Information in the Directory . . . . . . . . . . . . . . . . . . . . .201

Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201

Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201

Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201

IP Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202

Mapping Directory Users to Teradata Database Users, Roles, and Profiles . . . . . . . . . . . . . .203

Mapping Directory Users to Database Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203

Mapping Directory Users to Database External Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . .203

Mapping Directory Users to Database Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .204

Mapping IPFilters to Database Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .204

Testing Mapped Directory Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205

Using BTEQ to Verify Directory User Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205

Common BTEQ Error Messages Indicate Possible Directory Problems . . . . . . . . . . . . .206

tdsbind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207

Running tdsbind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207

Output from tdsbind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .210

Explanation of Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .210

Explanation of Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .212

Diagnosing Logon Failure Due to Incorrect Realm Information . . . . . . . . . . . . . . . . . . .214

tdsbind Error Output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .214

tdssearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .215

Running tdssearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .215

Finding User Information with tdssearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217

Determining the schemaNamingContext Value. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .222

Other LDAP Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .223

Optimization of Directory Searches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .224

Appendix A: Teradata Database Physical Security . . . . . . . . . . . .227

Controlling Machine Room Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .227

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .227

Setting Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .227

Enforcing Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .228

Controlling Access to Outside Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .228

Controlling Access to Dump Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .228

xvi Security Administration

Table of Contents

Controlling Access to the Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

Appendix B: Running a Secure Teradata Database . . . . . . . . . . 229

Securing a System to the Common Criteria Evaluated Configuration . . . . . . . . . . . . . . . . . 229

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

Common Criteria Level Security Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

Avoid Potential Security Hazards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

Appendix C: Preparing for Directory Integration--System Evaluation Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

Check the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

From a Teradata Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

From Teradata Database Server Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

Test the Directory Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

The RootDSE Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

Authenticate a Real User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

Common Errors with Active Directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

DNS Naming Issue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

Server Down: As Seen from Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

Server Down: As Seen from MP-RAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

Invalid User, Password, or Realm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

Common Errors with Sun Java Directory Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

Server Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

Bad Canonicalization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

Bad User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Bad Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Appendix D: Implementing Control of User Access by IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Elements of IP Access Restriction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Usage Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Ensuring Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

Overview of the Implementation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

Setting up IP Access Restrictions for Users Defined in Teradata Database . . . . . . . . . . 244

Setting up IP Restrictions for Directory-based Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

Security Administration xvii

Table of Contents

Creating and Applying IP Restrictions for Database Users. . . . . . . . . . . . . . . . . . . . . . . . . . . .245

IP Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .245

Filter Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .245

Filter Masks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .247

Related Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .248

Permissive Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .248

Restrictive Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .251

When No Filter Exists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .252

When Multiple Filters Exist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .252

Creating an XML IP Restriction Document. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .253

Save the Completed XML IP Restriction Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . .253

Applying a Filter to a User. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .253

Applying a Filter to All Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .256

Directory Implementation of IP Restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .257

Loading Directory Schema Extensions for IP Restriction of Directory Users. . . . . . . . . . . . .257

Creating IP Restriction Schema Objects in the Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . .257

Tags and Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .258

Mapping IP Filters to Database Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .259

Data Conversion Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260

ipxml2bin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260

ipdir2bin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .262

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .265

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .267

xviii Security Administration

CHAPTER 1 Introduction to Teradata DatabaseSystem Security

The information in this book is intended help you to understand how to:

• create a security policy appropriate to your Teradata Database system

• authenticate users at logon to prevent outsiders from gaining access to the system

• authorize legitimate Teradata Database users to access only those objects and resources for which they have permission

• employ and modify security mechanisms to meet site-specific security needs

• enable encryption to ensure secure transmissions of data between client and server

• monitor security events and take corrective action

• integrate supported security directories with Teradata Database

Security Controls

You must define and implement effective security controls to establish and maintain optimal system security. You can control system security by:

• restricting physical access to system hardware

• using software controls to limit access to data

• securing transmitted data using encryption

• monitoring user actions 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:

• protecting the system and its components against deliberate damage by locating it in a secure room

• controlling access to external devices used to connect to the system, such as remote terminals

Security Administration 1

Chapter 1: Introduction to Teradata Database System SecuritySecurity Controls

Security discussions in the chapters following this section will be limited primarily to software security procedures. For detailed suggestions on controlling physical access, see “Appendix A: Physical Access Control.”

Controlling Database Access

Users may access theTeradata Database system internally, by way of system nodes and administrative work stations (AWS), or externally by way of the Client system. The administrator controls access to the system by assigning a username and password to each user.

Each user wishing to access the system must submit a username and password at logon. Once the system verifies that the username is an authorized user and the password is correct for that user, it establishes a session with the user and assigns it 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 implicitly (automatically) grants users the right to access certain databases and objects based on ownership. In addition, the administrator can explicitly (selectively) grant or revoke access rights for users or groups of users. For information on how to regulate access, see Chapter 2: “Logon Security.”

Transmitting Secure Data

Administrators can secure data transmitted between the database system and the client system using encryption. There are two types of encryption:

• Logon strings are automatically encrypted to ensure the security of passwords transmitted from the Client to the database through the Teradata Gateway.

• Administrator and users may enable or disable encryption of data transmissions between the Client system and the Teradata Gateway as part of logging on from client applications.

For further information on securing transmitted data, see Chapter 5: “Managing Network Security.”

Monitoring System Security

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 all logon and logoff activity. The security administrator can also specify audits 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)

2 Security Administration

Chapter 1: Introduction to Teradata Database System SecurityDetermining 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 access rights

• Change compromised passwords

• Deny the offending users any access to Teradata Database (in extreme cases)

• Change the security policy

Related Topics

For further information on security monitoring see, Chapter 4: “Monitoring Access to Teradata Database.”

Determining Security Requirements

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 creating and maintaining available security tools and procedures against your actual security needs. You should consider the following factors before establishing your security policy:

• Appoint a Security Administrator.

• Consider the business value of data security, including industry standards, government requirements, and the business disruption that could result from a security breach.

• Identify the classes of users that require access to Teradata Database and the security concerns associated with each one.

• Define the level of security that is appropriate for your data and users.

Security Administrator Role

Introduction

To help ensure that Teradata Database system security needs are met, one or more individuals should assume responsibility for the duties of the 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. Teradata Database security features allow for privileges associated with security to be assigned solely to the security administrator.



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 access privileges

• Defines the users, objects, and SQL functions, if any, to be audited

• Monitors security incidents and initiates corrective action

• Coordinates Teradata Database security duties with the Client security administrator, and with database and client system administrators

• Documents, distributes, and explains system security policy to affected administrators and users

Related Topics

Administration of Teradata Database is complex. Before you make a final decision on whether or not you need a separate security administrator you should read the rest of this publication to understand security administration tasks.

• For information on general system administration topics, see Database Administration.

• For set up of the system administrator and security administrator users, see “Establishing Administrative Users” on page 60.

Business Value of Security

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 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 wide variety of local, state, and national government regulations, including those of foreign countries in which they do business. Administrators should become acquainted with all applicable government security regulations before finalizing their 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 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

Introduction

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 access rights and without resorting to frequent and detailed audits. However, for all but the smallest user communities, the time required for you 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.

Common User Groups

When formulating a security policy, you must balance the access needs of users with the need to provide system 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.

For information on how to regulate user access to the database, see Chapter 3: “Managing Data Access.”

Table 1: User Groups

User Group Duties Suggested Access

Administrators Responsible for the installation, maintenance, and availability of Teradata Database to all system users.

Principal administrators require full access to the database, including all privileges. Secondary or assistant administrators may be given more restricted access.

Application Programmers

Create databases, tables, views, stored procedures, and macros on behalf of the end users.

Programmers may need wide access to create or restructure databases and objects, but may need restrictions on adding or changing data.

End Users Make Teradata SQL requests to Teradata Database to view, add, or change 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.



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 Level of Security

Once you understand the security risks you face and the consequences of their occurrence, you must determine the appropriate level of security to counter possible threats. The following basic security levels are presented for your reference.

Minimal Security

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 with a small number of trusted administrative users that can access the system directly.

Under such a minimal security policy, the only security-related access restriction is on end users, who must first gain access to a client system (mainframe, minicomputer, PC, or Application Processor) that is capable of communicating with Teradata Database via a channel, LAN, WAN, or BYNET connection. Database security then depends on the client system security policy, if it exists.

Teradata Database can be configured to use the client system security directory for user authentication and authorization. For more information on interfacing with client security directories, see Chapter 6: “Using a Directory to Manage Database Users.”

Moderate Security

Under moderate security, the database administrator performs security administration duties, grouping users according to their needs and trustworthiness, and assigning access rights 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, but no formal security policy exists for the users.

High Security

High security requires that the security administrator formally establish and maintain Teradata Database security. The security administrator is responsible for following security-related 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.

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.

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

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

Disadvantages • allows anyone accessing Teradata Database to 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.

• can leave serious security violation s 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.

• requires that owners of shared data make additional effort to define those authorized to access the data.

• may degrade system performance depending on the frequency and scope of auditing and the demands of other required security practices.


Chapter 1: Introduction to Teradata Database System SecurityFormulating Security Policy

Formulating Security Policy

Introduction

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.

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

• Database access rights 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 violation that require procedural changes

• New releases of Teradata Database software that introduce new security features


CHAPTER 2 Logon Security

This chapter describes how to set up, use, and maintain the security features that manage user logons to Teradata Database. It discusses the following topics:

• Logon elements

• Logon format requirements and options

• Logon control options

• Password format requirements and options

• Password control options

Logon Elements

Introduction

To access the database, users must submit their username, password, and other related information as part a logon request. Each username is associated with a default storage area and an array of access rights that define the user’s privileges within a database. Upon successful logon, Teradata Database associates the username with a unique session number under which the session runs until the user logs off.

Logon strings must include some or all of the following elements, depending on system configuration and security policy:

• Security mechanism

• Username

• Domain or Realm

• Password

• Tdpid

• Account string

The size of these four 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’s rights and privileges.

Note: Teradata Database may provide some of these elements by default, or transfer them from other sources, depending on the system setup options you have exercised.


Chapter 2: Logon SecurityLogon Elements

Security Mechanism Selection

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.

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 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 Chapter 5: “Managing Network Security.”

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

For logon procedures for a specific application, see the users guide for that application.

Database User Names

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

CREATE USER requires that you define:

• A unique username

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

For specific instructions on how to construct and use variations of the CREATE USER statement, see SQL Reference: Data Definition Statements.

For information on password format requirements and controls, see “Password Format Requirements” on page 43 and “Password Control Options” on page 46.

Directory User Names

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. 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, not their database usernames.

For further information about directory users and their rights a privileges, see Chapter 6: “Using a Directory to Manage Database Users.”

Domain User Names

Users must logon with a domain username that matches a Teradata Database username for the Single Sign-on and Sign-on As logon options.

Domain/Realm

The name of either the domain or realm (depending on the directory) is required for logons using the LDAP mechanism where at least one of the following is true:

• Teradata Database is running on Windows

• The LdapClientReferrals property of the LDAP mechanism is set to on (the default setting)

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.



Related Topics

For information on LDAP mechanism properties and how to set them, see Chapter 5: “Managing Network Security.”

For information on how to specify the realm/domain value in a logon string, see “Network Logon Formats” on page 16.

Appended Domain Name

You may need to set up the gateway to append the domain name to make every logon name unique across all domains for users that log on under the following circumstances:

• If Teradata Database is running on Windows

and

• If logons use the KRB5 or NTLM mechanism

or,

• If logons use the LDAP mechanism and the directory is Active Directory

To accomplish the necessary setup, perform the following steps:

1 Query the Append Domain Name value of the Gateway Control GDO using the -d option of the Gateway Control utility. This value determines what form of username is accepted.

• If Append Domain is set to no, username is the only form accepted.

• If Append Domain is set to yes, "username@domainname" is accepted.

2 To change the current value, toggle it by entering the -F option for the gtwcontrol command.

gtwcontrol -F

3 If the system accepts domain names, append a domain name to the user name. To do this, define each username in the form:

"username@domainname"

For example, to create user “Bob” for domain “esdev3”, enter:

CREATE USER "Bob@esdev3" AS PERM=10000000, PASSWORD=Bob;GRANT LOGON ON ALL TO "Bob@esdev3" WITH NULL PASSWORD;

For further information about creating users, see Chapter 3: “Managing Data Access,” and Database Administration.

For further information about the gtwcontrol utility, see Utilities.

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.



Logging on Without a Password

It is possible for a user to log on to Teradata Database without submitting a password directly to the database if the username and password have already been authenticated by an external security application. External authentication requires the following:

• A GRANT LOGON statement containing the WITH NULL PASSWORD option must be current for this username, so authentication of the password can be done by external authentication instead of by the database. The GRANT LOGON statement is explained later in this chapter.

• 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 43 and “Password Control Options” on page 46.

For further information about authentication of users by external security applications, see “External Authentication for Network-Attached Clients” on page 37.

For further information about security exits, see Teradata Director Program Reference.

Hostid

For network-attached clients connected to a Teradata Database system by more than one LAN connection, each connection must have a unique identifier, called a hostid. The hostid is a required part of the logon string that identifies the connection the user wants to access. The Teradata Database administrator must assign each hostid using the config utility.

Note: The Kerberos mechanism does not support use of more than one LAN adapter.

For more information on assigning hostids, see Utilities.

Tdpid

The Teradata Director Program (TDP) is a Teradata-supplied program that manages communication between Teradata Database systems and channel-attached clients. On a Teradata Database system with more than one channel adapter, each adapter has a copy of the TDP and must have a unique identifier, called a tdpid. The Teradata Database administrator must assign each tdpid using the Teradata Director Program interface.

In a Teradata Database logon string, the tdpid indicates the copy of the TDP (i.e. the channel adapter) to whcih the system should connect for the requested session. The tdpid is a client system-based operand and is not transmitted to Teradata Database.

Channel-attached clients can specify only the TD2 mechanism when submitting logon credentials.

Related Topics

For information on tdpids and default tdpid values, see Teradata Director Program Reference.



Account String

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 account strings 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 the basic set up and use of account strings, see Database Administration and “Using Account String Expansion” on page 84.

For details on the syntax needed to specify an account string for a user, see “CREATE USER” in SQL Reference: Data Definition Statements.



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

• Kerberos (KRB5)

• Lightweight Directory Access Protocol (LDAP)

• Microsoft Windows NT LAN Manager (NTLM)

Version Requirements

In order to make full use of logons with the UTF-16 character set, a client must be at Teradata Tools and Utilities 8.1 or higher.

There are some restrictions on UTF-16 logons from a Teradata Tools and Utilities 8.1 client to a V2R6.0.x database, depending on the authentication mechanism employed for the session:

• LDAP: A Teradata Tools and Utilities 8.2 client using the LDAP authentication mechanism will not be able to use a UTF-16 logon to access a V2R6.0.x database because such a logon is dependent on changes to the Teradata Gateway not made until V2R6.1.

• Other mechanisms: A Teradata Tools and Utilities 8.2 client can use the following mechanisms when using a UTF-16 logon to access a V2R6.0.x database:

• KRB5

• NTLM

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.

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 the KanjiSJIS as the session character set but logs on with KanjiEUC characters that are not in the set’s repertoire, a translation error will occur and the logon will fail.

Solution: Make sure that the logon characters are present in the session character set.


Chapter 2: Logon SecurityNetwork Logon Formats

Network Logon Formats

You can gain access to Teradata Database through any one of a number of available client applications, using one of two logon methods:

• Command line logon

• GUI logon

Each element of the logon string information must be input as part of a logon parameter. The three logon parameters are as follows:

• .logmech: Contains the user selected security mechanism that 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.

• .logdata: Contains all the information needed for external authentication and authorization of the user by an agent other than Teradata Database. May require such information as username, password, and realm.

• .logon: Contains the hostid or tdpid, the Teradata Database username and password (unless the user is being externally authenticated), and optional account string information.

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

The format and content 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

• Teradata logon

• External Authentication

• Single Sign-on

• LDAP logons

• Authcid logons

• UPN logons

• Kerberos/NTLM logons (Sign-on As)

Examples in the following sections show the format and content requirements for each type of logon.

For detailed information on the requirements for setting up External Authentication, see “External Authentication for Network-Attached Clients” on page 37.


Chapter 2: Logon SecurityCommand Line Logons

Logon Conventions

Logons may differ based on the Teradata Client application through which the logon takes place and depending on whether it is an interactive logon or a script-based logon. For some applications you may not be able to enter the .logdata or .logon information exactly as shown in the examples provided in this chapter. For instance, the examples shown are from a BTEQ script. Interactive (non-script) logons that require credential information in the .logdata command will prompt the user to enter it on a separate line.

For more detailed information on logon requirements for a specific client application, see the users guide for that application.

Logons Using Teradata 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.logmech TD2.logon cs4400s3/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 when Teradata Database is at V2R6.0 and Teradata Tools and Utilities 8.0 and up.

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

Channel-attached clients automatically defer to TD 2--you do not need to use .logon specify a mechanism.

.logon cs4400s3 The hostid or tdpid

The hostid is the identifier of the Gateway that controls access to Teradata Database for network-attached clients.

The tdpid is the identifier for the Teradata Director Program that controls access to the database from channel-attached clients.

Note: The Kerberos mechanism does not support logons to systems with more than one LAN adapter (hostid).

rhh The user’s Teradata Database username

password The user’s Teradata Database password



Logons Using External Authentication

External authentication allows users to be authenticated by an external agent rather than by Teradata Database. To be externally authenticated, the user must select a mechanism that supports external authentication. Teradata Database must be properly configured to support external authentication.

For detailed information on the requirements for setting up External Authentication, see “External Authentication for Network-Attached Clients” on page 37.

External authentication logons are differentiated by the information entered as part of the .logdata parameter. The .logdata is optional for single sign-on, but is mandatory for Kerberos, LDAP or NTLM authentication.

Note: 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 to log on to the client domain once without the requirement to resubmit their credentials (username and password) if they subsequently want to access Teradata Database. Single sign-on users must logon with a username that matches a Teradata Database username. They must also select a security mechanism that supports single sign-on, and submit a hostid (if there is more than one LAN connection to the database), as part of their logon string before they can access the database.

The authenticating application then passes the user credentials, which the client system has held since the original client system logon, to the database so it can authorize the access privileges recorded in the database for that user. The name used for the initial domain logon must match a username recorded in the database.

Single sign-on requires that the user select either the Kerberos or NTLM mechanism, depending on client system is set up. It also requires that the SingleSignOn property be set to yes (the default) for the supporting mechanism.

Example 1: Single Sign-on.logmech KRB5.logon cs4400s3/,,"account"

The following explains the logon terms used in Example 2:


.logmech KRB5 (or NTLM) The Kerberos mechanism is shown as an example, but you can also use the NTLM mechanism for single sign-on depending on how your system is set up.

For further information system set-up to support single sign-on, see “External Authentication for Network-Attached Clients” on page 37.



.logdata Not required The .logdata field is not required for single sign-on.

Credential information from the user’s earlier logon to the client is passed to the database to authorize specific privileges associated with that user in the database.

The user’s client username must be the same as their database username.

.logon cs4400s3 The hostid

The hostid is the identifier of the Gateway that controls access to a LAN connection for network-attached clients.

, , You do not need to submit the user’s 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.

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’s AuthorizationSupported property must be set to no.

• Directory users can log on only if their usernames match a database username.

• The directory user can only exercise the database privileges granted to the matching database user.

• When the directory is configured to map directory users to database objects:

• The LDAP mechanism’s AuthorizationSupported property must be set to yes.

• Directory users can log on only if they have at least one mapping to one or more Teradata Database objects.

• A directory user mapped to a Teradata Database user inherits the database user’s 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.

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

• The directory can only authorize privileges that have been defined in the database.

Related Topics

For information on how to setup directory users for external authentication and authorization, see “External Authentication for Network-Attached Clients” on page 37.

For information on uses of the AuthorizationSupported property and how to edit its value, see “AuthorizationSupported” on page 129.

For further information about directory user privileges (including EXTUSER) and how to map directory users to database users, roles, and profiles, see Chapter 6: “Using a Directory to Manage Database Users.”

LDAP Logon Formats

The LDAP mechanism supports two logon formats:

• Authcid logons

• UPN logons

Examples in this section cover the authcid logon format. For information on use of the UPN format for LDAP logons, see “UPN Logons” on page 24.



Example 1: LDAP Authcid Logon -- All Supported Directories

Use LDAP logon authcid form with all TDGSS-supported directories.

.logmech ldap

.logdata authcid=robert password=password realm=domain

.logon cs4400s3/,,"account"


Logon Parameter Term Description/Usage

.logmech ldap LDAP is the only mechanism that supports authentication by a directory.

.logdata authcid=robert The user’s directory username.

Use this form for:

• directory users that are mapped to Teradata Database users, roles, and profiles

• directory users having usernames that match a Teradata Database username

Special Conditions:

• 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 username must match a Teradata Database username.

• If the directory user is mapped to more than one database user, include the additional term

user=<database user>

in the .logdata statement to designate the database user whose privileges the directory user wants to exercise.

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

• Similarly, if a directory user is mapped to more than one profile, then add profile=profilename to the .logdata to select the desired profile.

• If the directory is Sun Java System Directory Server and you track 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 4: “Monitoring Access to Teradata Database.”

password=password The user’s directory password



.logdata (Continued)

realm=domain

(also realm=realm)

Requirements for the realm value vary depending on database operating system, the setup of the LDAP mechanism, and the type of directory in use.

Note: Users will not normally know how these items are configured, so you should create a security handbook to help inform them about logons and other site-specific security conventions.

For Teradata Database on MP-RAS and Linux with LdapClientReferrals set to off (all supported directories):

When the LdapClientReferrals property of the LDAP mechanism is set to off, the realm information has no meaning and the system will ignore it.

Note: The default setting for the LdapClientReferrals property is on.

For all Teradata Database systems with LdapClientReferrals set to On:

Realm information is required and is drawn from either the .logdata string or the value of the LDAP mechanism’s LdapServerRealm property. Realm information provided in the .logdata string takes precedence over the property value.

If no realm information is provided in the .logdata string, the logon will defer to the LdapServerRealm property value.

If the factory preset default value for the LdapServerRealm property is not correct for your directory type, you should edit it to a valid value so users do not have to include realm information in the .logdata.

For Active Directory users logging on to Teradata Database on Windows:

• If the value for the LdapServerRealm property is valid and the user does not need to enter realm information in the .logdata.

For a description of valid settings for the LdapServerRealm property, see “LdapServerRealm” on page 145.

• If LdapServerRealm property value is not valid the user can enter either of the following:

• the fully qualified DNS name of the directory server, in the form: realm=FQDNSname

• The domain in which the directory authentication takes place, in the form: realm=domain

For Active Directory users logging on to Teradata Database on Linux or MP-RAS and for all Sun Java System Directory Server users:



• If LdapServerRealm property value is not valid the user can enter the fully qualified DNS name of the directory server: realm=FQDNSname

Note: The default “” property value is not valid for this directory type. The logon may fail if the server’s fully qualified DNS name is not specified in either the .logdata statement or the LDAP mechanism’s LdapServerRealm property.





Example 2: Alternate LDAP Authcid Logon

In addition to the logon string shown in the previous Example 1, you can also use this variation of the LDAP authcid logon form on Active Directory, and on other directories if they are specially configured to accept it.

.logmech ldap

.logdata authcid=diruser@dirrealm password=dirpassword


.logon cs4400s3 The hostid that identifies the LAN connection through which the user is logging on.

, , Substitute , , for Teradata Database username and password, which are not entered for an LDAP logon.

The , , is required only if an account string is used.





UPN Logons

Teradata Database allows logons using the User Principal Name (UPN) -- a common logon format recognized by many external authentication agents. This type of logon does not require use of the authcid= term to precede the user name. However, the username itself can be entered in the same way.

The basic UPN form is:

diruser@@password

Observe the following restrictions when using the UPN form of logon:

• 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 used in the authcid-type logon, such as realm=domain or profile=profilename may be used with the UPN logon, but they must appear after the UPN and be separated by white spaces.

The following list shows some common variations of the UPN format:

UPN Variation Explanation

.logdata diruser@@password The simplest form of UPN logon

.logdata diruser@realm@@password The username may require inclusion of realm information to accurately identify the user.

Note: Realm information included to the left of the @@ as part of the username does not fulfill the requirement for providing realm information where such information is required by the authentication mechanism or system configuration.

.logdata diruser@realm@@password realm=division.corp.com

or,

.logdata diruser@realm@@password realm=” “

When realm information is required, it must be preceded by a realm= statement, located after the password, and preceded by a white space.

.logdata @@password authcid=diruser

or

.logdata @@password authcid=diruser@realm

or

.logdata @@password authcid=diruser@realm realm=

The UPN format also allows the user to not enter the username to the left of the @@. For these variations, the user enters the username as an authcid= entry, which must be located after the password and preceded by a white space.



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 Reason not Allowed

diruser@realm@@dirpassword authcid=diruser Duplicate user information

diruser@realm@@dirpassword password=dirpassword Duplicate password information

profile=teradataprofile diruser@realm@@dirpassword UPN style token must be the first token

user=teradatauser diruser@realm@@dirpassword UPN style token must be the first token



LDAP UPN Logons

The UPN logon for LDAP is limited to use with compatible LDAP directories.

This logon form is similar to the Kerberos and NTLM UPN logons shown later in this section. For further information on these forms, see “Sign-on As Using Kerberos/NTLM UPN Logons” on page 28.

Example 1: LDAP UPN Logon

Use the following logon string example for LDAP UPN logons through Active Directory and on other supported directories if they are specially configured to accept it.

.logmech ldap

.logdata diruser@dirrealm@@dirpassword realm=domain profile=profilename


The following table explains the logon terms used in Example 1:


.logmech ldap LDAP is the only mechanism that supports LDAP logons.

.logdata diruser@@dirrealm The user’s directory username.

Use this form of specifying the user for:

• directory users that are mapped to Teradata Database users, roles, and profiles

• directory users having usernames that match a Teradata Database username (Sign-on As)

Special Conditions:

• 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 username must match a Teradata Database username.

• If the directory user is mapped to more than one database user, include the additional term

user=<database user>

in the .logdata statement to designate the database user whose privileges the directory user wants to exercise.

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

• Similarly, if a directory user is mapped to more than one profile, then add profile=profilename to .logdata to select the desired profile.

@@dirpassword The user’s directory password.



.logdata (continued)

realm=domain Requirements for the realm value vary depending on database operating system, the setup of the LDAP mechanism, and the type of directory.

Note: Users will not normally know how these items are configured, so you should create a security handbook to help inform them about logons and other site-specific security conventions.

For Teradata Database on MP-RAS and Linux with LdapClientReferrals set to off (all supported directories):

When the LdapClientReferrals property of the LDAP mechanism is set to off, the realm information has no meaning; the system will ignore it.

Note: The default setting for the LdapClientReferrals property is on.

For all Teradata Database systems with LdapClientReferrals set to On:

Realm information is required and is drawn from either the .logdata string or the value of the LDAP mechanism’s LdapServerRealm property. Realm information provided in the .logdata string takes precedence over the property value.

If no realm information is provided in the .logdata string, the logon will defer to the LdapServerRealm property value.

If the factory preset default value for the LdapServerRealm property is not correct for your directory type, you should edit it to a valid value so users do not have to include realm information in the .logdata.

Logging from Active Directory to Teradata Database on Windows:



• If LdapServerRealm property value is not valid the user can enter either of the following:

• the fully qualified DNS name of the directory server, in the form: realm=FQDNSname

• The domain in which the directory authentication takes place, in the form: realm=domain

Logging on from Active Directory to Teradata Database on Linux or MP-RAS and for all Sun Java System Directory Server users:



• If LdapServerRealm property value is not valid the user can enter the fully qualified DNS name of the directory server: realm=FQDNSname

Note: The default “” property value is not valid for Sun Java System Directory Server. The logon may fail if the server’s fully qualified DNS name is not specified in either the .logdata statement or the LDAP mechanism’s LdapServerRealm property.





Sign-on As Using Kerberos/NTLM UPN Logons

If a user has the same username for both the client domain and the database, that user may choose to be authenticated by a supported external application instead of by the database, while signing on as a database user. The user must select the mechanism corresponding to the application that will do the authentication (Kerberos or NTLM).

Sign-on As uses theUPN logon format.

The LDAP mechanism also supports a UPN logon that can be used for Sign-on As. For further information, see “LDAP UPN Logons” on page 26.

Once the kerberos or NTLM 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.

Example 1: Kerberos or NTLM Logons

.logmech kerberos

.logdata robert@domain@@password


Note: The example shown is from a BTEQ script. Interactive logons will prompt you 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.



, , The Teradata Database username and password are not entered for an LDAP logon.

The , , is required if an account string is used.




.logmech kerberos

(or NTLM)

UPN logons must specify the mechanism that supports the external security agent that will authenticate the user.



.logdata robert The user’s name

The username exists in the database, but is authenticated by Kerberos or NTLM.

The username must match a Teradata Database username.

@domain (optional) The domain where the authenticating application resides. If not specified, the current domain will be used.

@@password The user’s password

The password need not be the same for the client system and Teradata Database.


, , The Teradata Database username and password are not entered for UPN logons.

The , , is required as a place-holder if an account string is used.




Chapter 2: Logon SecurityGUI Logons

GUI Logons

GUI applications provide logon dialog boxes to allow users to specify logon data and a security mechanism. A typical logon dialog box is shown below.

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.

After entering the required information, click the Mechanism button and the Mechanism dialog box is 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


Chapter 2: Logon SecurityLogons Through Teradata Query Director

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:

• TD 2

• Kerberos (KRB5)

• LDAP

The client software must be Teradata Tools and Utilities 8.1 or newer to use this feature.

Mechanism property values must be set as follows to support Query Director:

• Set the MechanismEnabled property value to yes in the client, the intermediary, and the database server TDGSS User Configuration files, for any of the following mechanisms you plan to use for Query Director logons:

• TD 2

• KRB5

• LDAP

• Set the DelegateCredentials property value to yes only in the client system TDGSS User Configuration file, for any of the following mechanisms you plan to use for Query Director logons:

• KRB5

• LDAP

• The TD 2 mechanism does not require this change

• Ensure that the MutualAuthentication property value is set to yes for the KRB5 mechanism in the client system TDGSS User Configuration file.

All other system set-up requirements are the same as for normal use of these mechanisms.

For details on editing mechanism properties, see “General Rules for Editing” on page 126.


Chapter 2: Logon SecurityLogons from Channel-Attached Systems

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 channel-attached clients use only the .logon command, and are similar to the logon shown in “Example1” on page 17.

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 should use only the .logon command, and are similar to the logon shown in “Example1” on page 17.

Replication Logons

Teradata Database can be set up to use the Teradata Replication Solutions feature, such 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. By means of such automatic updates, replication serves to maintain data equivalency between two separately addressable databases.

Each transfer of data requires that the intermediary logon to both the initiator (source) system and the receiver (destination) system. The logon process is automatic once the systems are set up for replication, using the following mechanisms:

• TD1 is used if the destination system is running V2R5.1.x

• TD2 is used if the destination system is running V2R6.0 or above

Check to 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 Solutions feature.


Chapter 2: Logon SecurityReplication Logons

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 set-up process, using the tam.ini file.

For further information on security options for replication applications, see Golden Gate Operations Guide, Version 7.3.

Related Topics

For information on the Teradata Replication Solutions feature, see Teradata Replication Solutions Overview.

For information on enabling the TD1 and TD2 mechanisms, see “General Rules for Editing” on page 126.


Chapter 2: Logon SecurityLogon Controls

Logon Controls

This section describes the following optional methods provided in Teradata Database to restrict user logons.

Administrators can:

• grant logons only to users that require database access.

• grant logons to users only on specific hostids.

• revoke logons from users who have left the company or who seem to pose a security risk.

• restrict logons based on user IP address.

• enable authentication and authorization of users by external security agents.

Granting and Revoking Logons

Teradata Database grants logon permission to all users from all client system connections by default. However, you can control which users have access from which client system connections. The GRANT LOGON and REVOKE LOGON statements associate specific usernames with specific hostids.

Each username must already have been created as a user in Teradata Database before it can be the subject of a GRANT/REVOKE LOGON statement.

Teradata Database maintains Data Dictionary (DD) system tables using Data Definition Language (DDL) statements. The GRANT LOGON and REVOKE LOGON statements are DDL statements. Teradata Database uses the DD tables to execute subsequent statements.

For detailed information on use of GRANT and REVOKE statements, see SQL Reference: Data Definition Statements.

Description of GRANT/REVOKE LOGON Statements

A brief description of each LOGON statement follows:

• TheGRANT LOGON statement gives specific users permission to log on to Teradata Database from one or more specific client systems. In addition, the statement is used to change the current system defaults for logon permissions.

• The REVOKE LOGON statement retracts permission to log on to Teradata Database from one or more specific client systems. In addition, the statement is used to change the current system defaults. A REVOKE LOGON statement inhibits only future logon attempts; it does not affect users who are currently logged on.

Rules for Submitting GRANT/REVOKE LOGON Statements

GRANT LOGON and REVOKE LOGON statements must be submitted according to the following rules of usage for DDL statements:

• A DDL statement cannot be combined with other statements as part of a multi-statement request.



• A DDL statement can only be included in an explicit transaction (one or more requests bracketed by BEGIN TRANSACTION/ END TRANSACTION statements in Teradata mode, or terminated with a COMMIT statement in ANSI mode) if it is one of the following:

• The only statement in the transaction

• Structured as a single-statement request that appears as the last request in the transaction

When you submit a GRANT LOGON or REVOKE LOGON statement, the Teradata Database checks whether you have the EXECUTE privilege on the system macro associated with that statement. However, the Teradata Database does not check whether the user name defined in the statement applies to users owned by the requesting user.

If Teradata Database cannot verify the submitted statement (for example, the statement specifies an invalid user name or an invalid hostid), it takes no action on the statement.

Precedence of Clauses

Rules are exercised according to the specific level of the client system and user ID clauses in the GRANT LOGON and REVOKE LOGON statements. The specific clauses take precedence over the general clauses. The clauses are:

• 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

For syntax and usage information on the GRANT LOGON and REVOKE LOGON statements, see SQL Reference: Data Definition Statements.

Controlling Access with Hostids

Network-attached clients access the Teradata Database system through a LAN or WAN connection. When systems have more than one LAN or WAN connection, you must identify each such connection with a hostid using the Configuration utility and users must specify the hostid as part of the logon string.

Define the connection values according to the following:

• All network-attached systems can belong to a single hostid, independent of node, or you can configure the system for multiple hostids if it has multiple connections.

• For Windows/Linux nodes:

• You can define each connection to the database as a different hostid, but it is not required.



• Multiple connections to the same LAN have the same hostid.

• You can as many hostids as there are LAN connections.

• For MP-RAS nodes: All LANs connected to the node must have the same hostid.

When multiple client systems are connected to a Teradata Database, the initial default grants logon permission to all users for all hostids. However, the administrator can GRANT LOGON and REVOKE LOGON to users for specific hostids. Only administrative users having EXECUTE privilege on the DBC.LogonRule special system macro can REVOKE logons by hostid. For examples of revoking logons by hostid, see “Precedence of Clauses” on page 35.

You can also enable or disable logons by host using the Gateway Global utility.

Related Topics

For details about hostid setup using the Configuration utility or enabling and disabling of logons by host, using the Gateway Global utility, see Utilities.

For additional information on hostid administration, see Database Administration.

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 be configured to restrict the database access of:

• some or all users from a particular IP address

• users from some IP addresses while allowing them access from other IP addresses

Note: Restricting logons by IP address is not practical when applied to users who logon through Teradata Query Director or other middleware applications because the Gateway will only see the IP of the middleware.

Creating IPAccess Restrictions

To restrict user logons by IP address, you must execute a unique set-up 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 document describing the restrictions on users that resides in the database

You must transfer the data from directory or 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-related schema extensions into the directory.

For detailed information about creating and using IP address restrictions, see “Appendix D Implementing Control of User Access by IP Address” on page 243.

For details about loading IP-related schema extensions into a directory and setting attributes of schema objects, see Chapter 6: “Using a Directory to Manage Database Users.”



External Authentication for Network-Attached Clients

External authentication allows Teradata Database users to be authenticated by a network-attached client application at logon rather than forcing them to provide a username and password directly to the database.

Note: A Teradata Database server may be connected by both network and channels to its clients. External authentication (EA) for channel-attached clients functions very differently from EA on network-attached systems.

For information on external authentication for channel-attached systems, see “External Authentication for Channel-Attached Clients” on page 40.

There are two types of external authentication for network-attached systems:

1 Without User Credentials (Single Sign-on or SSO): Users exercising this authentication option do not need to submit their credentials directly to the database as part of the .logdata parameter.

• SSO users must logon to the client domain with a username that matches a Teradata Database username.

• Once an SSO user has been authenticated by the external application (Kerberos or NTLM), they do not have to resubmit their credentials to access the database

2 With User Credentials: The user submits credentials as part of the .logdata parameter of the logon string when logging on to the database, and is authenticated by a directory or a supported external security application.

• LDAP Logon (Directory Sign-on): Users are authenticated by the directory using their directory username. The directory will also authorize the user to exercise any database privileges associated with mapping to Teradata Database users, roles, and profiles.

Directory users with usernames that match database usernames can execute an LDAP logon and be authenticated by the directory without the need for mapping. In this case, the directory user is authorized the same privileges as the matching database user.

For information on mapping directory users to Teradata Database users, roles, and profiles, see Chapter 6: “Using a Directory to Manage Database Users.”

• Kerberos/NTLM Logon (Sign-on As): A User exercising this authentication option must logon as a user that has a username common to both the client domain and Teradata Database. The user is then authenticated by Kerberos or NTLM. Once authenticated, the user can access specific database areas and functions only according to privileges granted to that user in the database.

Users wanting to use external authentication must specify a mechanism that supports the method by which they will be authenticated. For a detailed list of what mechanisms support a specific type of external authentication and operating system, see “Security Mechanisms that Support External Authentication” on page 39.

For detailed information on logon formats required for the various external authentication options, including selection of a mechanism and submission of user credentials, see “Network Logon Formats” on page 16.



Setting Up Logon Privileges for External Authentication

The administrator must take the following actions to enable external authentication for network-attached systems:

Set-up 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-- users cannot be externally authenticated.

• 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 the purpose of each one for use with external authentication and the results of conflicts in their settings.

The DBS Control utility affects all logons to the database system. The Gateway Control utility only affects logons through a particular Teradata Gateway, and can be st 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.

External Authentication Type Set-up Requirements

• Single Sign-on

• Kerberos/NTLM logon

• LDAP logon where the directory has not been configured to map directory users to Teradata Database users.

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

• The AuthorizationSupported property of the selected mechanism must be set to No for the external authentication mechanisms you plan to use.

• LDAP logon where the directory has been configured to map directory users to Teradata Database users.

• If the directory user is mapped to a Teradata Database user, the database user must have been granted LOGON WITH NULL PASSWORD privileges (except EXTUSER).

• The AuthorizationSupported property of the selected mechanism must be set to Yes for the external authentication mechanisms you plan to use.

• Directory users mapped to EXTUSER and not mapped to a database user, role or profile, have only the PUBLIC privileges, unless they are also mapped to additional roles or profiles.



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

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

External Authentication with Delegated Credentials

Some systems may pass user logon credentials (i.e. delegate the credentials) through Teradata Query Directory to one of multiple database systems to enhance user load-balancing or database availability. Users logging on through Query Director can still be authenticated externally if you have followed the normal external authentication set-up procedures described in this section.

The following exceptions to the normal rules for set-up of external authentication apply when authentication requires delegated credentials (for Query Director):

• You can use only the KRB5 and LDAP mechanisms for external authentication that requires delegated credentials.

• The following minimum software versions must be installed on your system:

• The Teradata Database server software must be at V2R6.1 or newer

and

• The Teradata Client software must be at Teradata Tools and Utilities 8.1 or newer

• Set the DelegateCredentials property value to yes for the mechanism(s) to be used (KRB5 and/or LDAP).

For further information on how to edit mechanism properties, see “General Rules for Editing” on page 126.

Security Mechanisms that Support External Authentication

Even when external authentication is enabled, users must still select a security mechanism that supports both of the following:

• The type of external authentication they want to exercise

• The external application that will perform the authentication



Select a security mechanism for use with external authentication according to the following guidelines:

External Authentication for Channel-Attached Clients

Users may 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.

For further information on set up of external authentication options for mainframe users, see Teradata Director Program Reference.

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 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 detailed instructions on the use of DBS Control and Database Window functions to enable external authentication, see “Set-up Options for External Authentication” on page 38.

External authentication of mainframe users also requires that they have LOGON WITH NULL PASSWORD privileges.

User authentication via... On this system configurationRequires the selection of this security mechanism

Single Sign-on or Sign-on As using Kerberos application

• Server running Teradata Database V2R6.0 or newer on Windows

• Client running Teradata Tools and Utilities 8.0 or newer

KRB5

Single Sign-on or Sign-on As using NT Lan Manager (NTLM)



NTLM

(Not usable for delegated credential logons)

LDAP logon through:

• Sun Java Directory Server

• Active Directory (all versions)



LDAP

LDAP logon through:

• Active Directory (Windows Server 2003 only)

• Sun Java System Directory Server

• Server running Teradata Database on MP-RAS (V2R6.0.0 or newer) or SUSE Linux Enterprise Server 9 (V2R6.1 or newer)




Related Topics

For further information related to external authentication, see the following:

For further information on... See...

Enabling external authentication using the DBS Control or Gateway Control utility

Utilities

Enabling external authentication using DBW Graphical User Interfaces: Database Window and Teradata MultiTool

Setting up Single Sign-on for use with Windows network security


Mechanism properties “TDGSS Security Mechanisms” on page 118.

Setting up external authentication using an integrated, LDAP-compliant directory

Chapter 6: “Using a Directory to Manage Database Users.”.


Chapter 2: Logon SecurityManaging Passwords

Managing Passwords

Introduction

Teradata Database provides a number of controls to aid in password administration and enhance password security.

The following password management topics are covered in this section:

• Creating passwords

• Password format requirements

• Modifying passwords

Creating Passwords

Creating a password is required when you create a user with the CREATE USER statement. The format of the password must conform to system enforced password format requirements, as well as password format control parameters maintained in the DBC.SysSecDefaults dictionary table.

When you create a new user, be sure to set the PasswordChgDate to zero. A zero value indicates that the password initially assigned to the user is a temporary password. Temporary passwords expire at the first logon attempt and users are prompted to create their own passwords, which are likely to be easier for them to remember than passwords created for them.

Use the MODIFY USER statement with the FOR USER option to provide a new temporary password for users who forget their password.

The system validates each new or modified password when the administrator submits the SQL statement that creates it, or when users create new passwords to replace their temporary passwords. An error message results whenever a password violates a password format rule.

Related Topics

For information about setting up passwords with the CREATE/MODIFY USER statement, see SQL Reference: Data Definition Statements.

For information about password format control parameters maintained in the DBC.SysSecDefaults dictionary table, see “Password Controls in DBC.SysSecDefaults” on page 46.

For information on password encryption, see “Logon Encryption” on page 86.

For information about system-enforced password format requirements, see the following section.



Password Format Requirements

Teradata Database accepts any string for a password as long as it conforms to the default, system requirements. The following password format requirements affect all users unless the administrator exercises one or more password control options that supersede them:

A Password Can Contain...

• 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 (“ ”).

A Password Cannot Contain...

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



The rules for passwords are similar to those for naming objects. Note that many of these rules make sense only in a multibyte character set environment. See additional restrictions on multibyte environments in the sections that follow.

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.

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 Reference: Fundamentals.

For charts of 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.



Modifying Passwords

Use the MODIFY USER statement with the FOR USER option to provide a new temporary password for users who forget their password.

The following procedure causes the existing password to expire and creates a temporary pass-word to replace it. The user can then specify a new password at the next log on.

1 Enter: SELECT ExpirePassword FROM DBC.SecurityDefaults;

2 Examine the reported value for ExpirePassword.

3 Perform MODIFY USER with the FOR USER option.

Note: You must have the appropriate privilege.

MODIFY USER JDoe ASPASSWORD = mysecretFOR USER;

The existing password immediately expires and is replaced by ‘mysecret.’

The value for PasswordChgDate is reset to 0 just as is true for a new user.

The temporary password expires immediately when the user logs on for the first time, and they must create a new, permanent password at that time using the MODIFY USER

command without the FOR USER option.

IF the value is… THEN…

0 Change it to a value > 0.

UPDATE DBC. SecurityDefaultsSET ExpirePassword=2;

Restart the database.

Go to Step 3.

Note: Temporary passwords expire immediately only if you first set a non-zero value in the ExpirePassword column.


Chapter 2: Logon SecurityPassword Control Options

Password Control Options

Teradata Database provides several options for controlling password format and usage requirements to help administrators to 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:

• Editing global password controls in the SysSecDefaults table using UPDATE

• Editing password controls for groups of users by creating or modifying a profile

• A detailed review of each password control option, including:

• Description/purpose

• Default setting and range

• Usage strategies

• Editing instructions

• Password control-related error messages

Password Controls in DBC.SysSecDefaults

The DBC.SysSecDefaults dictionary table contains a set of global controls that restrict the usage and content of passwords for all users, as shown in the following table:

Field Name Description

Password Usage Controls

ExpirePassword The number of days that must elapse before a password expires

MaxLogonAttempts The number of erroneous logons allowed before the user is locked out of the database

LockedUserExpire The number of minutes to elapse before a locked user is unlocked

PasswordReuse The number of days that must elapse before a password can be reused

Password Format Controls

PasswordMinChar Sets the minimum number of characters required in a password

PasswordMaxChar Sets the maximum number of characters allowed in a password



Re-Setting Password Controls

The security administrator can reset the password control parameters shown in the SysSecDefaults table in two ways:

PasswordDigits Determines whether digits are:

• allowed in a password

• not allowed in a password

• required in a password

PasswordSpecChar Indicates whether or not special characters are:

• allowed in a password

• not allowed in a password

• required in a password

In addition, you can place much tighter restrictions on password special characters to require that:

• passwords must contain at least one alpha character

• passwords must contain a mixture of upper/lower case letters

• no password can contain a database username

Field Name Description

Reset Method Effects Guidelines for Use

Change a parameter value using an UPDATE statement

Resets password control parameter(s) globally

Warning: Since this is a global reset, it will undo all pre-existing controls for the parameter affected.

• Global password controls apply to all users logging on to Teradata Database regardless of the logical client system from which the logon is received.

• Password controls do not affect externally authenticated users because their passwords are validated outside the database.

• Teradata Database reads the DBC.SysSecDefaults table only at system startup. You must restart the system to allow it to read the DBC.SysSecDefaults table and make changed values take effect.

• After the system restart, changes to DBC.SysSecDefaults only take effect:

• When a new user is created with a CREATE USER statement.

• When an existing user’s password is modified with a MODIFY USER statement.

• When an existing user’s password expires and the user creates a new password in response to a system prompt.



Using UPDATE to Reset Password Controls in DBC.SysSecDefault

You can set or reset global password control options in the SysSecDefaults table using an UPDATE statement as shown in the following example:

UPDATE DBC.SysSecDefaults SET PasswordMinChar = 8 ;

For further information on password control strategies and allowable values when using UPDATE to change password control parameters, see “Setting Password Controls” on page 49.

Using CREATE or MODIFY PROFILE to Reset Password Controls

You can use a CREATE or MODIFY PROFILE statement to override global password control parameters defined in SysSecDefaults for those users assigned to a 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 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 49.

CREATE/MODIFY PROFILE Resets password control parameter(s) for members of a profile

• Applies only to users that are members of the profile.

• Users that are members of profiles that reset default password controls and who are externally authenticated are not affected because their passwords are validated outside of the database.

• Does not require a system restart-- all changes take effect at the next user logon.

Reset Method Effects Guidelines for Use


Chapter 2: Logon SecuritySetting Password Controls

Setting Password Controls

Teradata Database provides options to edit default password control parameters found in the DBC.SysSecDefaults dictionary 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.

The following section presents password control parameters and strategies for editing them.

ExpirePassword

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. The system 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 UPFDATE, 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 ;

Results of Logging on with an Expired Password

When a user attempts a logon with an expired password:

• A session is established 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 within the session.



If the user already has a session logged on and the password expires, the current session may be used to submit the MODIFY USER statement to establish a new password. If the current session is for a utility such as Archive or 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.

• A second attempt to logon with an expired password will not be successful.

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 field, ExpirePassword, in the DBC.SysSecDefaults table.

For details, see the MODIFY USER syntax in SQL Reference: Data Definition Statements.

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 below). 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.



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 use 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 3: “Managing Data Access.”

Strategy

When specifying the number of failed logon attempts to allow before locking out the user, consider the following trade-offs:

• 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 could 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 Reference: Data Definition Statements.



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 all old password rows for that user with a date earlier than the current date minus the PasswordReuse time span.



Note: If an administrator resets a password for a user, the system makes no entry in DBC.OldPasswords. As a result, 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 Old Password table contains the following information:

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 example shows the UPDATE statement to set the duration of user lock to two minutes:

UPDATE DBC.SysSecDefaults SET LockedUserExpire = 2 ;

Table 3: OldPasswords Column Descriptions

Column Description

UserName Identity of the user to which the password was assigned.

PasswordDate Date the password was changed for the user.

PasswordSeed Data Encryption Standard (DES) seed needed to encrypt the password.

PasswordString Encrypted password string.



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

The value set for PasswordMinChar must be 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

The value set for PasswordMaxChar must be 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.



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 if 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 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



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:

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

Status Indicator Description

Y Allowed but not required

N Not Allowed

R Required

If you enter this Password SPECCHAR Option...

You get this combination Special Character Option rules

UserNameMixture 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

E, e Y R R N



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’ ;

Error Messages

The following error messages are associated with password control parameters.

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

If you enter this Password SPECCHAR Option...

You get this combination Special Character Option rules

UserNameMixture of Upper and Lower Case letters

At least One Alpha Character Special Characters

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.

Message Number Description


CHAPTER 3 Managing Data Access

Teradata Database provides the ability to control access to databases, objects, and operations. The security administrator can use access controls to insure that users have access to the data they need, while protecting the data from misuse or corruption.

This chapter explains:

• How to create system administrative users

• Basic rules for database ownership and access

• How to use Teradata SQL statements to GRANT and REVOKE access rights

• How to use Roles and Profiles to simplify the administration of user access to the database and to system resources

This chapter provides only a basic overview of data ownership and access. For more detailed information on this and other related aspects of Teradata Database structure and management, see the following documents:

For information on... See...

Basic concepts of database structure and management Introduction to Teradata Warehouse

Rules and methods for creating and managing your database

Database Design

Administrative procedures for managing users and controlling user access


Using SQL to define access rights and how this affects database object ownership



Chapter 3: Managing Data AccessUser DBC

User DBC

Introduction

When first installed, Teradata Database contains space allocated to a special system user named DBC.

User DBC Contents

Initially, user DBC contains:

• Data Dictionary system tables

• All Teradata Database-managed disk space available for the site applications including users, databases, objects, and data

• A series of system views that allow retrieval of data from the underlying system tables.

Since User DBC owns all of the Teradata Database-managed disk space, it is the parent of all other users. The first users you need to create under User DBC are the administrative users. The administrative users will then be responsible for creating and managing all other users, databases, and objects.

User DBC Warning!

Warning: Never alter the access rights for user DBC. Changing DBC access rights may cause installation, upgrade, maintenance, or archive procedures to end abnormally and consequently require Teradata Support Center assistance to correct the problem.

For information on how to revoke rights on DBC tables from users other than User DBC, see “Revoking Privileges from PUBLIC or ALL DBC” on page 71.

Establishing Administrative Users

Space under user DBC that is not needed for system data should be allocated to administrative users--the system administrator, security administrator, and if necessary, other assistant administrators.

System Administrator User

The Teradata Database system administrator is responsible for maintaining the system configuration and data, creating all users and databases, and defining their access privileges. The system administrator should have access to everything in the database hierarchy and explicit privileges on all database objects.

Use the following procedure to set up the system administrator user:

1 Log on as DBC.

2 Submit a CREATE USER statement to allocate the space to an administrative user.


Chapter 3: Managing Data AccessEstablishing Administrative Users

The name of the new user can be anything except “sysadmin,” which is the name assigned to a special system database. This book assumes the new username to be ADMIN.

3 Allocate to user ADMIN all the free PERM space that remains under DBC after the requirements of the site system tables and largest transient journal have been calculated and subtracted. For details on the transient journal and creating the administrative user, see Database Design.

When DBC submits the CREATE USER ADMINstatement, the space for ADMIN is allocated from DBC space. DBC thus becomes the immediate owner and parent, as well as the creator of ADMIN.

4 Explicitly grant ADMIN all the privileges needed to administer the daily activities of the site, including creating users and databases, roles and profiles, and granting privileges, with the following statements:

GRANT ALL ON ADMIN TO ADMIN WITH GRANT OPTION;GRANT ROLE, PROFILE TO ADMIN WITH GRANT OPTION;

5 Explicitly grant ADMIN the privileges needed to monitor and control system performance, including ABORT SESSION and MONITOR RESOURCE. The following statement grants those rights; however, the statement does not include an ON clause, and cannot work if it has one:

GRANT MONITOR PRIVILEGES TO ADMIN WITH GRANT OPTION;

6 While still logged on, submit a MODIFY USER statement to change the password for DBC. When the statement is accepted, DBC should log off. From this point on the system administrator should log on under username ADMIN.

When logged on as ADMIN, the system administrator can create new users and any administrative databases from the ADMIN space. ADMIN is the parent of all users and databases it has created and automatically receives creator privileges on them.

ADMIN also automatically receives implicit ownership privilege on all databases and users subsequently created, because it is the indirect owner of these objects. In turn, a user created by ADMIN becomes the owner of any databases, other users, and objects he or she creates.

The resulting hierarchical structure gives the owner or creator of an object control over the security of that object.

Security Administrator User

Rather than assigning all administrator access privileges to the system administrator, you may find it useful to designate a security administrator and grant some administrative rights accordingly.

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 under username DBC.

2 Enter a CREATE USER statement to create user space for the security administrator in Teradata Database.

Any name except “sysadmin” can be assigned (this book uses the name “SECADMIN”).



Be sure to assign a password to user SECADMIN.

3 After you create user SECADMIN, enter the following Teradata SQL statements to grant user SECADMIN the privilege of executing the GRANT/REVOKE LOGON and BEGIN/END LOGGING statements:

GRANT EXECUTE ON DBC.LogonRule TO SECADMIN ;GRANT EXECUTE ON DBC.AccLogRule TO SECADMIN ;

4 Log off Teradata Database as user.

5 Immediately log back onto Teradata Database as username SECADMIN.

6 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 ON EACH ALL ON MACRO DBC.LogonRule,MACRO DBC.AccLogRule ;

Executing this statement generates audit entries for all future execution of Teradata SQL statements that control auditing of actions on, and the source of logons to, Teradata Database.

7 Log off Teradata Database.

You can assign other duties and rights to the security administrator depending on your system needs.

Typical Privileges Granted to a Security Administrator

The following SQL represents a typical assignment of database privileges for a Security Administrator:

CREATE PROFILE admin_user_profile AS PASSWORD ATTRIBUTES = (EXPIRE = 0) ;

CREATE USER SECADMIN AS PASSWORD = xxx, PROFILE = admin_user_profile, PERMANENT = xxx, SPOOL = xxx, ACCOUNT = 'SecAdmin', FALLBACK ;

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 */ ;

BEGIN LOGGING WITH TEXT ON EACH ALL ON MACRO DBC.LogonRule, MACRO DBC.AccLogRule ;



Controlling Access to the Operating System

It is important to 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 NCR 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 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 by default.

The system initialization scripts explicitly grant SELECT access to dump data to the SYSTEMFE user. 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. You should change the SYSTEMFE password periodically to reduce the chance that unauthorized users might get access to CRASHDUMPS.

Related Topics

• For further information on use of the CREATE USER, GRANT/REVOKE LOGON and BEGIN/END LOGGING statements, see SQL Reference: Data Definition Statements.

• For information on other database administration tasks, see Database Administration.

Controlling Access to Teradata Dynamic Workload Manager

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 this tool can have on how requests are processed and system resources allocated, the most secure approach is to allow as few users as is practical to access the Teradata DWM username and password.

For further information about Teradata DWM, see Teradata Dynamic Workload Manager User Guide.


Chapter 3: Managing Data AccessUsers and Databases

Users and Databases

Although a user and a database are both allocated space in which object data can be stored, and the keywords USER and DATABASE may sometimes be used synonymously, they are not the same. A dbname, or database name, merely identifies the space in which data is stored.

A database is a defined logical repository for tables, views, and macros. A database has perm and spool space. A Teradata Database user is similar to a database except a user:

• has a password or an account

• can be used to log on

• can establish a session

• can execute Teradata SQL statements

A user may log on to a database either by its own access rights or by way of another database for which it has access rights.

Space Allocation

The requested space for a new user or database is allocated from the space of the requesting user unless the CREATE USER or CREATE DATABASE statement contains a FROM ownerdb clause.

If the new user then creates another user or a database, the requested space is allocated from the space for that user. The result is a hierarchical structure that is maintained for all users and databases.

Related Topics

The following shows the location of other information related to users and databases:

For more Information on. . . See. . .

How to create users and databases Database Administration

User and database space allocation Database Design

Unique characteristics of external directory-based users

“User Management Strategies” on page 171


Chapter 3: Managing Data AccessOwners and Parents

Owners and Parents

Introduction

A user who creates a database or another user becomes the owner and is implicitly granted ownership rights on that space. As the owner of the new space, the user is also automatically granted access rights to anything created in that space.

If the new space is a user, the owning user is considered the parent and the newly created user is considered its child. In turn, a child becomes the parent of any new users it creates.

A parent may grant itself privileges on any objects owned by any of its child users. For example, assume that user ADMIN creates a database named Finance and a user named Smith. ADMIN grants Smith the privilege to create new databases and users.

Smith then logs on and creates another user, Jones. Jones receives automatic and implicit privileges on the items he creates in his own space. However, as parent user for Jones, Smith, and those above him in the hierarchy, may also grant themselves privileges on any items owned by Jones, because they have implicit ownership rights on user Jones. This parent-child relationship is maintained for all users defined in Teradata Database.

Object Ownership

The immediate owner of an object is the containing user or database. However, the parents in the hierarchy above the containing user or database are also indirect owners of the object.

For example, assume a user named USER1 creates in its own space a database named TEST. Assume also that USER1 then creates a table defined as TEST.TABLEA. The occurrence of TABLEA is stored in TEST, which is the immediate owner of TABLEA. However, TABLEA is also indirectly owned by USER1 and all the parents of USER1.

Giving Ownership

Use the Teradata SQL GIVE statement to transfer actual ownership of a database or user to a non-owner. 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.

Related Topics

For information on ownership of users, databases, and objects created by directory-based users, see “Directory User Characteristics” on page 175.


Chapter 3: Managing Data AccessAccess Rights

Access Rights

Introduction

Access rights give users permission to access databases or objects. Teradata Database security uses access rights to control activities such as creating, deleting, viewing, or modifying database objects, as well as running executable database objects. Teradata Database must verify the requestor as having the appropriate privileges before access is allowed. If a user does not have the appropriate privileges, Teradata Database denies the request and generates an access violation informing the requesting user of the violation.

Some rights must be intentionally granted or revoked. Other rights are created automatically as a result of actions not specifically concerned with access. For detailed information about the use of SQL data control language statements to define or modify access rights for your system, see SQL Reference: Data Definition Statements.

Three types of access rights (or privileges) are defined in this section:

Ownership Rights

Ownership rights are also called implicit rights. These rights are implicitly granted to the immediate owner of a database or database object. A database or user from whose space a database object is created is the immediate owner of that object. Ownership is also granted to all indirect owners (parents), that is, those in the hierarchy above the immediate owner. Ownership provides two forms of rights:

• An owner can execute a GRANT or REVOKE statement for any privilege applied to an owned object.

For example, the owner of a table has the implicit right to GRANT to itself the SELECT privilege on an owned table. Even if a parent revoked theSELECT privilege from a child on tables owned by that child, the child could subsequently GRANT itself the revoked SELECT privilege.

• Ownership rights also implicitly provide CHECKPOINT, DUMP, and RESTORE privileges on owned objects. Ownership rights do not include the privilege to execute any form of the CREATE statement.

Access Right Description

Implicit (Ownership) Granted implicitly by the system to the owner of the space from which a database, user, or object is created.

Automatic Granted automatically by the system to the creator of a database, user, or object, and to a newly created user or database.

Explicit Given to any user having the WITH GRANT OPTION privilege. Explicit rights are given using the Teradata SQL GRANT statement.



A user does not own itself; therefore, creating a user does not grant to the newly created user any ownership rights. Ownership rights cannot be revoked. Even though ownership rights are implicit, they are still subject to logging when access logging is specified for the particular right.

Automatic Rights

Automatic rights are granted by the Teradata Database system to:

• the creator of a database, user, or object

• a newly created user or database

Creator privileges are distinct from ownership privileges because the FROM dbname option of the CREATE DATABASE or CREATEUSER statement allows the creator to define an owner different from his or her own space.

A new user or database is automatically granted all rights on itself, with the exception of the GRANT (WITH GRANT OPTION) and CREATE DATABASE/USER, CREATE PROCEDURE, and EXECUTE PROCEDURE rights. Thus, a newly created user can create tables, views, and macros within his or her own user space. The automatic right to create objects can be explicitly revoked from a new user by an owner or by the creator of the user.

A user can be explicitly granted the right to create databases and other users in his or her own user space. This right can only be granted by a user who has the GRANT right (WITH GRANT OPTION) and the right to create such users and databases.

In the case of stored procedure-related rights, a newly created user gets only the DROP PROCEDURE privilege. The rights to create or execute stored procedures are not automatic. These can be explicitly granted to any user by DBC or by a user having the rights WITH GRANT OPTION. For details, see “Explicit Rights” on page 68.

The initial user (DBC) in the system has all rights, with the exception of CREATE PROCEDURE and EXECUTE PROCEDURE. When creating the ADMIN user, all rights should be explicitly granted by DBC to ADMIN. User ADMIN then has the right to pass these privileges down to any user created by ADMIN.

If a user has been granted either the CREATE DATABASE or the CREATE USER privilege, and subsequently creates a new database or user, Teradata Database automatically grants to that user a series of creator privileges on the created space.

There is a case where the new user or database is the creator but not necessarily the owner. The CREATE DATABASE/USER statement offers a FROM option that creates the new database or user from the space of a specified owner, instead of the space of the user submitting the CREATE statement. The creator is the user or database submitting the CREATE statement but does not own the space the new object is created in. While the owner of the space becomes the owner of the newly created user or database.

Privileges that are automatically granted to the creator of an entity are listed in Table 4.



Explicit Rights

Explicit rights are those rights that are actively granted to users, in contrast with those that are inherited or automatically provided. GRANT and REVOKE statements explicitly give one or more privileges to or retract them from a user or group of users on a database, user, table, view, stored procedure, or macro.

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 an administrative user, and the administrator then create and grant privileges to all other users.

Related Topics

Access rights for external directory-based users are not the same as those for created users.

For detailed information on the characteristics and rights of directory-based users, see “User Management Strategies” on page 171.

Table 4: Creator Privileges

CREATE Statement Automatic Rights

CREATE DATABASE

CREATEUSER

All privileges on databases, users, macros, tables, and views created in the new space, and DROP PROCEDURE privilege on the database or user space.

CREATE TABLE DROP TABLE, INDEX, INSERT TRIGGER, UPDATE, DELETE REFERENCE, SELECT, and DUMP and RESTORE privileges on the newly created table, as well as the CREATE TRIGGER privilege WITH GRANT OPTION.

If the JOURNAL option is specified, the user also must have INSERT privilege on the journal table.

CREATE MACRO DROP MACRO, EXECUTE, and GRANT on the created macro. Performing an EXECUTE or GRANT on a macro depends also on the privileges the owner of the macro has on the objects referenced by that macro.

CREATE VIEW DELETE, DROP VIEW, GRANT, INSERT, SELECT, and UPDATE on the new view. Using the view or performing a GRANT on a view depends also on whether the owner of the view has GRANT privileges on the objects referenced by that view.

CREATE PROCEDURE DROP PROCEDURE and EXECUTE PROCEDURE on the new stored procedure.

Performing an EXECUTE PROCEDURE or GRANT on a stored procedure depends also on the privileges the owner of the stored procedure has on the objects referenced by that procedure.


Chapter 3: Managing Data AccessUsing GRANT and REVOKE to Control Access

Using GRANT and REVOKE to Control Access

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

The following sections provide a general description of the use of GRANT and REVOKE statements to control access. For more detailed syntax and usage information for GRANT and REVOKE, see SQL Reference: Data Definition Statements.

Note: You cannot use GRANT privileges to or REVOKE them from the system-generated pseudo-user, EXTUSER.

Forms of the GRANT Statement

The GRANT statement has four forms:

Note: If you want to maintain a security log of access attempts, see the “BEGIN/END LOGGING Statements” section in “Chapter 4 Monitoring Access to Teradata Database.”

Examples Using GRANT

The following examples show how you can use the GRANT to allow access to database objects and functions. The REVOKE statement functions in much the same way to restrict access.

Example 1: User A Creating Database X

When user A creates database X, the following GRANT statements are executed by Teradata Database:

GRANT TABLE, VIEW, MACRO, SELECT, INSERT, UPDATE,DELETE, DUMP, RESTORE, CHECKPOINT, EXECUTE,DROP PROCEDURE ON x TO x;

GRANT USER, DATABASE, TABLE, VIEW, MACRO, SELECT,

Statement Description

GRANT (SQL Form)

In Teradata SQL, this statement pertains to access privilege control on Teradata Database and is used to assign one or more privileges on a database, user, table, view, stored procedure, or macro to a user or a group of users.

GRANT (Monitor Form)

Used to grant system-wide performance monitoring privileges.

GRANT LOGON Described in Chapter 2: “Logon Security” in this book.

GRANT (Role Form)

Used to grant role membership to users or other roles.


Chapter 3: Managing Data AccessUsing GRANT and REVOKE to Control Access

INSERT, UPDATE, DELETE, WITH GRANT OPTION, DUMP,RESTORE, CHECKPOINT, EXECUTE, DROP PROCEDURE ON xTO a;

The owner gets implicit rights.

Example 2: User A Creating User B

When user A creates user B, the following GRANT statements are executed by Teradata Database:

GRANT TABLE, VIEW, MACRO, SELECT, INSERT, UPDATE,DELETE, DUMP, RESTORE, CHECKPOINT, EXECUTE,

DROP PROCEDURE ON b TO b;GRANT USER, DATABASE, TABLE, VIEW, MACRO, SELECT,

INSERT, UPDATE, DELETE, WITH GRANT OPTION, DUMP,RESTORE, CHECKPOINT, EXECUTE, DROP PROCEDUREON b TO a;

The owner gets implicit rights.

Example 3: User C Creating Table Z.Y

When user C creates table z.y, the following GRANT statement is executed by Teradata Database:

GRANT DROP TABLE, INSERT, UPDATE, DELETE, SELECT,WITH GRANT OPTION, DUMP, RESTORE ON z.y TO c ;

Example 4: User D Creating Stored Procedure Z.SpSample

When user D creates a stored procedure z.SpSample, the following GRANT statement is executed by Teradata Database:

GRANT PROCEDURE WITH GRANT OPTION ON z.SpSample TO D;

where PROCEDURE includes DROP PROCEDURE and EXECUTE PROCEDURE rights.

Forms of the REVOKE Statement

The REVOKE statement has four forms:


REVOKE (SQL Form)

Cancels privileges to a database, user, table, view, stored procedure, or macro from a user or group of users. The privileges may have been given automatically or by a previous GRANT statement.

REVOKE (Monitor Form)

Cancels system-wide performance monitoring privileges.

REVOKE LOGON

Does either of the following:

• Revokes permission to log on to the Teradata Database from one or more specific client systems.

• Changes the current system logon defaults.


Chapter 3: Managing Data AccessRevoking Privileges from PUBLIC or ALL DBC

Note: Implicit ownership privileges cannot be revoked.

Revoking Privileges from PUBLIC or ALL DBC

For some systems, the administrator may have granted privileges to PUBLIC (all users) that are no longer appropriate. In such cases, administrators may find it necessary to REVOKE these rights from all PUBLIC or from a large number of users. The methods for revoking PUBLIC privileges vary according to when the privilege was originally granted. To revoke PUBLIC privileges properly, use the following procedures:

REVOKE (Role Form)

Used to revoke role membership from users or other roles.


Rights to be Revoked REVOKE Statement Remarks

Non-DBC table right granted to PUBLIC or ALL DBC before V2R5.0

REVOKE <right> FROM ALL DBC; Revokes right from PUBLIC.

DBC table rights granted to PUBLIC or ALL DBC before V2R5.0 that were not converted over to “new” PUBLIC rights after upgrading from pre-V2R5.0 to V2R5.0 or later

If the conversion was done, use REVOKE <right> FROM PUBLIC;

Note: Avoid granting DBC table rights to PUBLIC if at all possible. Most DBC tables shouldn’t be made that widely available and the rights are much harder to revoke.

REVOKE <right> FROM

• <user>;

• <list of users>;

• ALL <non-DBC user>

Warning: When revoking DBC table rights, use of REVOKE <right> FROM ALL DBC will also remove user DBC rights on these tables. Once revoked, these rights can only be re-granted with the assistance of the Teradata Support Center.

Revokes DBC table rights only from the users specified

If you need to REVOKE a DBC table right granted before V2R5.0 from a very large number of users and can’t use REVOKE <right> FROM ALL <non-DBC user>, contact the Teradata Support Center for assistance.

Non-DBC or DBC table right granted to PUBLIC or ALL DBC at V2R5.0 and after

REVOKE <right> FROM PUBLIC; Revokes right from PUBLIC.


Chapter 3: Managing Data AccessRoles

Roles

Introduction

Roles define access privileges on database objects for groups of users. The administrator can assign one or more roles to each user, including a default role. A user who is a member of a role can access all the objects on which the role has privileges. Users can use SET ROLE to switch from the default to any alternate role of which they are a member.

Advantages of Using Roles

Use roles to:

• Simplify access rights administration.

A database administrator can grant rights on database objects to a role and have the rights automatically applied to all users assigned to that role instead of having to assign them individually.

When the function of a user within an organization changes, changing the role of the user is far easier than deleting old rights and granting new rights to go along with the new function.

• Reduce dictionary disk space.

Maintaining rights at a role level rather than on an individual level makes the size of the DBC.AccessRights table much smaller. Instead of inserting one row per user per right on a database object, the Teradata Database inserts one row per role per right in DBC.AccessRights, and one row per role member in DBC.RoleGrants.

Related Topics

The following shows the location of other information related to roles:


Administrative procedures for using the roles feature Database Administration

Detailed syntax needed to create, drop, set, grant, or revoke a role, or to assign a default role to a user


The special attributes of external roles that are applied to directory-based users

“Roles and Profiles for Directory Users” on page 177


Chapter 3: Managing Data AccessUsing EXTUSER to Provide Limited Database Access to Directory Users

Using EXTUSER to Provide Limited Database Access to Directory Users

EXTUSER is a pseudo-user automatically created in Teradata Database with the installation of V2R6.0.0.32 or later. Directory users that require limited database access can be mapped to EXTUSER instead of to Teradata Database users, roles, and profiles in cases where:

• Mapping to existing users, roles, and profiles would provide an inappropriate level of access

Note: Directory users that have been mapped to EXTUSER can subsequently be mapped to additional users, role, and profiles. In such cases, the directory user can exercise all the privileges to which it has been mapped.

• Creating new users, roles, and profiles is not worth the effort involved

For a more detailed description of EXTUSER’s built-in capabilities and access rights, see “Directory User Characteristics” on page 175.

Profiles

Definition

Profiles define values for the following system parameters:

• Default database

• Spool space

• Temporary space

• Account strings

• Password security attributes

An administrator can define a profile and assign it to a group of users who share the same settings.

Advantages of Using Profiles

Use profiles to:

• Simplify system administration.

Administrators can create a profile that contains system parameters such as account, default database, spool space, temporary space, and password attributes, and assign the profile to a group of users. To change a parameter, the administrator updates the profile instead of each individual user.

• Control user-level password security.

Administrators can assign the profile to an individual user or to a group of users.


Chapter 3: Managing Data AccessProfiles

Using Profiles to Control User-Level Password Security

Teradata Database stores the system-wide password security options in a single row in the DBC.SysSecDefault table. During system startup, Session Control validates against password expiration and lockout attributes stored in this row.

An administrator can create profiles that define values for the following user-level password security attributes:

• Minimum and maximum number of characters in a password string

• Whether or not to allow digits and special characters in a password string

• Number of incorrect logon attempts to allow before locking a user

• Number of minutes before unlocking a locked user

• Whether a user is locked out indefinitely

• Number of days before a password can be used again

• Whether a password may be reused

• Ability to change password expiration

The password attribute settings in a user profile override the corresponding system-level password settings. The system uses the system-level password settings for password attributes that are not defined in the profile for a user.

Note: Changes to password attribute settings in a profile do not require a system restart to take effect. The new settings take effect the next time a user assigned the profile logs on.

Related Topics

The following shows the location of other information related to profiles:


Administrative procedures for using profiles Database Administration

Detailed syntax and rules for creating or dropping a profile


Modifying a profile "MODIFY PROFILE" in the section on "SQL Data Definition Language Statement Syntax" in SQL Reference: Data Definition Statements

Assigning profiles to users The section on "Using Profiles to Manage System Parameters for Groups" in SQL Reference: Data Definition Statements

The special attributes of profiles that are applied to directory-based users

“Roles and Profiles for Directory Users” on page 177


CHAPTER 4 Monitoring Access to TeradataDatabase

The security administrator can periodically audit system activity to detect security hazards and events. Teradata Database automatically audits all logon and logoff activity. The security administrator can also configure the system to specify additional audits of attempts to access data. If unauthorized or undesirable activity is detected, the administrator can take remedial actions to address the problem.

This chapter:

• Describes use of the Data Dictionary to collect and monitor security information

• Discusses the system views from which useful audit reports can be extracted

• Provides general rules for controlling access log entries

• Details the use of BEGIN LOGGING and END LOGGING statements to invoke and suspend audit trails

• Explains the use of Account String Expansion (ASE) for detailed security audit information

Security Information in the Data Dictionary

Teradata Database includes a Data Dictionary in which information is accumulated about users, databases, data demographics, resource usage, and access rights. This information is stored in tables reserved for system use and can be accessed by administrators using views. These tables and views reside in the system database called DBC.

The Data Dictionary provides the ability to check access rights, to verify user and creator access privileges, and to review recorded access activity.

For detailed information on the content of Data Dictionary tables, see Data Dictionary.

System Views

Each site is provided with a set of standard system views loaded into user DBC during installation. System views allow users to retrieve information from selected columns of the underlying system tables.


Chapter 4: Monitoring Access to Teradata DatabaseSystem Views

The following table describes views that provide information on users and their access rights, as well as historical data on grant, logon, and access activities.

For information on system views, see Data Dictionary.

View Name Description

DBC.AccessLog 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, based on the criterion defined in a BEGIN LOGGING statement.

DBC.AccLogRules Entries are maintained in the underlying tables for this view as the result of executing BEGIN LOGGING and END LOGGING statements. These entries are used by the system to determine which privilege checks should result in entries being generated in the DBC.AccLogTbl table.

DBC.AllRights Entries provide information about all users’ automatically or explicitly granted privileges, and the objects on which those privileges were granted.

DBC.AllRoleRights Entries list all rights granted to each role.

DBC.DeleteAccessLog Use this view to remove entries more than 30 days old from the DBC.AccessLog table.

For example, to remove all entries over 30 days old, type the statement:

DELETE FROM DBC.DELETEACCESSLOG ALL ;

DBC.LogOnOff Use this view to record 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.

This view also shows the users that have been granted “with null password” privileges, which allows them to be externally authenticated.

DBC.LogonRules Entries are stored in the underlying table of this view as a result of the GRANT LOGON and REVOKE LOGON statements. These entries are used by the system to determine whether to allow or prevent system access.

DBC.RoleMembers Entries list 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.

DBC.Users Use this view to extract information about the user submitting the request and all users owned by that user. The information is derived from system table DBC.DBase.

DBC.UserRights Use this view to list every individual access right explicitly granted to a user. It does not list the user's implicit rights.

DBC.UserRoleRights Use this view to list all rights granted to the user's current role and its nested roles. It does not list the rights of all external roles assigned to directory users.


Chapter 4: Monitoring Access to Teradata DatabaseSystem View Queries

System View Queries

Introduction

Query the following system views to review information concerning user access privileges and activities:

• DBC.LogonRules

• DBC.AccLogRules

• DBC.AccessLog

You can use all parameters of the SELECT statement to query system views. For example:

SELECT * FROM DBC.AccLogRules ;SELECT * FROM DBC.AccessLog WHERE AccessType = ’CP’ ;

MONITOR Related Queries

You can make queries regarding the use of system monitoring or production control features similar to the way you make other SELECT queries.

Example 1: Determining Which Users Can Force Other Users Off the System

To determine which users have the privilege to force other users off the system (where AS is an abbreviation for the ABORT SESSION privilege), type:

SELECT DISTINCT UserName FROM DBC.AllRights WHERE AccessRight = ’AS’ ;

Example 2: Determining Which Users Have Been Forced Off the System

To determine which users have been forced off the system in the past two days, type:

SELECT DISTINCT UserName FROM DBC.LogOnOff WHERE Event = ’Forced Off’ AND LogDate > DATE - 3 ;

Example 3: Determining Who Is Currently Using the MONITOR Function

To learn who is currently using the MONITOR function, type:

SELECT UserName, IFPNo FROM DBC.SessionInfo WHERE Partition = ’MONITOR’ ;


Chapter 4: Monitoring Access to Teradata DatabaseAccess Logging

Access Logging

Overview of Logging

You can use BEGIN LOGGING and END LOGGING to control the monitoring of access rights checks performed by Teradata Database. These are Data Definition Language (DDL) statements in that they affect Data Dictionary entries, which the Teradata Database uses when executing subsequent statements.

Each time you execute a BEGIN LOGGING statement, the system table DBC.AccLogRuleTbl receives applicable rule entries. (The system view DBC.AccessLogRules offers access to the contents of this table.)

When a user named in a BEGIN LOGGING statement attempts to execute a specified action against a specified object, Teradata Database checks the access rights necessary to execute the statement according to the rules in AccLogRuleTbl. The privilege checks made and the access results are logged in the system table DBC.AccLogTbl. The system view DBC.AccessLog offers access to the contents of this table.

A logging entry does not indicate that a statement was executed; rather, it indicates that the system checked the privileges necessary to execute the statement.

You can terminate logging by submitting an END LOGGING statement for any action, user, or object for which logging is currently active. Note that you cannot end logging begun for a specific username by omitting the BY username option.

Access Logging of Directory Users

Access log entries normally list the Teradata Database username of the user performing the activity being logged. In cases where authentication for a session logon has been performed by a directory, the directory users will be identified in all access logs by their directory-based identifiers, and not by the Teradata Database username to which they are mapped.

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 -f option in the GTWControl utility to append the domain name from which the logon has taken place 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.

For further information on access logging for directory users, see “Access Logging of Directory Users” on page 179.

General Rules for Using DDL Statements in Access Logging

Because the BEGIN LOGGING and END LOGGING statements are DDL statements, you must submit them according to the following general rules for DDL statement usage:


Chapter 4: Monitoring Access to Teradata DatabaseBEGIN/END LOGGING Statements

• You cannot combine a DDL statement with other statements as part of a multi-statement request.

• You can only include a DDL statement in an explicit transaction (one or more requests bracketed by BEGIN TRANSACTION and END TRANSACTION statements) if it is:

• The only statement in the transaction,

OR

• Structured as a single-statement request that appears as the last request in the transaction

Security Macro Privilege Checking

When a user submits a BEGIN LOGGING or END LOGGING statement, the system checks whether the executing user has the EXECUTE privilege on the special system macro associated with that statement.

Teradata Database makes no checks for privileges on the user or objects identified in the LOGGING statement.

If the system cannot execute a statement, it returns an error message to the user. Possible errors could be an invalid:

• Action name

• Username

• Object name

System Default

If the user does not submit a BEGIN LOGGING statement, then by default the system does not generate any entries on any user action.

BEGIN/END LOGGING Statements

Introduction

A user can execute the BEGIN LOGGING and END LOGGING statements only if the following conditions are present:

• The DIPACC DBCSQL script, which the software release tape provides, has been run to create the special security macro DBC.AccLogRule.

• The system has been reset to initialize the logging software.

• The user has been granted the privilege to EXECUTE the macro DBC.AccLogRule.

Otherwise, access logging is not allowed on Teradata Database.

For syntax and additional usage information on the BEGIN LOGGING and END LOGGING statements, see SQL Reference: Data Definition Statements.



Logging Function

The BEGIN LOGGING and END LOGGING statements start and stop the auditing of data access requests.

Each time a user named in a BEGIN LOGGING statement attempts to execute a specified action against a specified object, Teradata Database performs one or more access-rights checks as defined by the rules residing in DBC.AccLogRuleTbl. The completed checks generate one or more log entries in DBC.AccLogTbl.

The BEGIN LOGGING statement can request checks on one, all, or any combination of the following items:

• Type of access

• Text of the request

• Frequency of access

• Action requested

• Name of the requesting user

• Objects referenced

A user can terminate logging for an action, user, or object for which log entries are currently active by submitting an END LOGGING statement.

DBC.AccLogRuleTbl Entries

The rules resulting from the execution of BEGIN LOGGING statements are entered in the system table DBC.AccLogRuleTbl.

When access logging is active, Teradata Database looks in AccLogRuleTbl to determine which privilege checks to make against a specified user, action, or object.

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. If this action turns off all logging rules for a particular user, database, or table, the system deletes the row from AccLogRuleTbl.

DBC.AccLogTbl Entries

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 performs the specified privilege checks. These checks generate one or more log entries in the system table DBC.AccLogTbl.

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 row will be either a “denied” or a “granted” entry.

Log entries may contain one or two names. The 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 access right of the logon username of that EXECUTE statement. However, the system also checks the access rights for the individual statements within the macro for the owner of the macro itself.

Database-Level Logging

A user should consider the object level used in the granting of an access right when specifying the object level of a logging statement.

When a logging statement specifies logging at the database level, the actions requested against all the tables in that database are candidates for log entries.

To illustrate this, assume that DatabaseA contains several tables, and that the INSERT privilege has been 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 the DatabaseA

The same type of action against separate tables in that 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. Next, assume that rows were inserted into both Table1 and Table2 in the same session. The logging result would be 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. (The absence of an access right 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.

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

Viewing Log Entries

You can monitor the contents of:

• The DBC.AccLogRuleTbl via the DBC.AccLogRules system view

• The DBC.AccLogTbl via the DBC.AccessLog system view

If access logging is specified for a data object (for example, a table), the system will generate log entries only when a user accesses that object by name. For example, a logging statement specifying “FIRST SELECT ON DatabaseA.Table1” causes a log entry to be generated if an access statement is the following:

SELECT . . . FROM Table1

Logging will not occur on the following access statements unless a logging rule specifies the view, macro, or stored procedure used:

• SELECT . . . FROM View1_of_Table1

• EXECUTE MACRO1

where Macro1 contains the following statement:


• CALL SpSample1

where SpSample1 contains the following statement:


Using END LOGGING

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.

Using the END LOGGING statement results in an error if BEGIN LOGGING is not currently in effect for the community (dbname) for which you want to end logging:

• Logging begun for specific usernames cannot be ended by omitting the BY username option.

• The END LOGGING statement erases text flags for the specified actions and user or object. However, the frequency syntax cannot be included in END LOGGING statements because it is restricted.

Purging Aged Log Entries

Include a WHERE condition clause in the DELETE statement to purge aged log entries. Use the viewname DBC.DeleteAccessLog in the DELETE statement. For example, to delete entries older than 90 days, type the statement:



DELETE FROM DBC.DELETEACCESSLOG WHERE LogDate < (Date - 90) ;

If you do not specify a WHERE LogDate, by default the view always deletes entries older than 30 days. The view contains logic to retain a 30-day minimum of logging entries. For more information on the DELETE statement, see SQL Reference: Data Manipulation Statements.

DBC.AccLogRule Macro

You must install the DBC.AccLogRule macro feature on any site that formerly used the SecurityLog and wishes to continue doing so. After you create the DBC.AccLogRule macro and initialize logging, any subsequent command causes the statements that were previously logged in the SecurityLog to be logged in DBC.AccLogTbl.

Caution: Only those sites that require access logging should create the DBC.AccLogRule macro. The feature extracts a performance penalty even if little or no logging is performed.

The user executing a BEGIN LOGGING or END LOGGING statement must have the EXECUTE privilege on the DBC.AccLogRule macro.

Access Logging and Errors

If the SQL parser identifies and reports any syntactic or semantic error, then it returns an error message to the user with no logging of the statement.

Changing Logging Options With MODIFY USER

A user with no access rights can enter a self-referent MODIFY USER statement to change the following options:

• BEFORE JOURNAL

• AFTER JOURNAL

• DEFAULT JOURNAL TABLE

• PASSWORD

• STARTUP

• COLLATION

• DEFAULT DATABASE

Logging is triggered by using access rights. Therefore, no logging occurs if you enter a self-referent MODIFY USER statement.

Note: Privilege checks generate log entries. MODIFY is not a privilege that can be granted, so MODIFY is not a privilege that is checked. MODIFY operations are not logged.

To log MODIFY operations, select logging for the type of access that the MODIFY requires. Specifying such actions as DROP, INSERT, DELETE, and UPDATE can cause logging on actions used by a MODIFY.

For example, to log MODIFY DATABASE operations, specify logging on the DROP DATABASE privilege. DROP DATABASE is the documented access right requirement for MODIFY DATABASE.


Chapter 4: Monitoring Access to Teradata DatabaseUsing Account String Expansion

Using Account String Expansion

Use the optional Account String Expansion (ASE) feature if you need detailed security audit information. ASE provides precise statistics, enabling more accurate capacity planning and information for charge back and accounting software.

You must modify user logon strings in order to use the ASE feature. ASE does not modify the AMP usage statistics gathering process; those functions and features operate in the usual way prior to ASE.

To enable ASE, the system administrator establishes one or more account identifiers for a new user when the user is created (or modified). When the user logs on, they must supply an account identifier as a part of the logon string. The user may enter the identifier explicitly, or the system will supply an identifier by default. Establish a list of allowable account ID strings with the CREATE USER or MODIFY USER statements.

The system collects a new set of statistics (AMP usage, number of I/Os, etc.) each time it determines that a new account string is in effect. The system stores the accumulated statistics for a user/account string pair as a row in DBC.AMPUsage. Each user/account string pair results in a new set of statistics and an additional row.

Related Topics

For detailed ASE information, string expansion examples, and usage examples, see the Account String Expansion (ASE) section in Database Administration.


CHAPTER 5 Managing Network Security

Many Teradata Database systems support network connections that provide easy database access to clients in multiple locations. However, transmission of data between the database and network-attached clients may leave the data vulnerable to access by unauthorized users, interception, and/or corruption. Secure management of a diverse and widely-dispersed user base requires a complex balancing of the risks against the effort required for set-up and benefits inherent in various security strategies.

Teradata Database provides the following security features to enhance network security and simplify user management:

• Confidentiality: Encryption of logon strings and data transmitted over the network.

• Integrity: Checking all received messages against what was sent to ensure that data has not been corrupted during transmission.

• External Authentication and Authorization: Delegation of the authentication of user identity and the authorization of user database access privileges to supported external security applications.

Note: The features described in this chapter are applicable only to network-attached clients.

These and other network security functions are bundled into “security mechanisms” that are administered by the Teradata Database Generic Security Services Library (TDGSS). Teradata Database provides several standard security mechanisms that are usable with little or no administrator intervention, along with the option for the administrator to edit mechanism properties to meet site-specific security requirements.

For detailed information on the description and use of Teradata Database security mechanisms, see “TDGSS Security Mechanisms” on page 118.


Chapter 5: Managing Network SecurityLogon Encryption

Logon Encryption

Teradata Database encrypts logon strings to ensure the confidentiality of passwords transmitted between client applications and the Teradata Gateway.

Client applications cannot enable or disable encryption of the logon string. The Teradata Gateway determines whether or not logon encryption is enabled.

By default the Teradata Gateway accepts only encrypted logons, while rejecting those that are unencrypted. When logon encryption is in the default enabled state the Gateway Control Utility -b option is set to no, as follows:

gtwcontrol -b no

You must temporarily reset the Gateway to allow deprecated (unencrypted) logons during an upgrade from Teradata Database V2R5.x to V2R6.x or newer. Otherwise, logon encryption should always be enabled.

If you need to enable deprecated logons, set the gtwcontrol -b option to yes as follows:

gtwcontrol -b yes

Enhanced Password Encryption

Teradata Database provides the option of increasing the level of password encryption if a high level of password security is required. The two levels of security are shown in the following:

Setting the Password Encryption Level

The password encryption level is controlled by the SHAPasswordEncryption field in the DBSControl utility.

• When this field is set to FALSE, the system uses DES encryption.

• When the field is set to TRUE, the system uses SHA encryption.

The field is set to TRUE as a default on all new systems running V2R6.2 and above. For systems that upgrade to V2R6.2 and above you must manually set the field to TRUE if you want the higher-level SHA password security. Even after you set the SHAPasswordEncryption field to TRUE, the higher level of encryption is only in effect for passwords that are subsequently created or changed. Existing passwords will continue to use DES encryption.

Encryption Type

Encryption Level Defaults Setting Usage

DES 8-bit • V2R6.1.x and before

• V2R6.2 and above (upgrades only)

Secure

Use where a moderate level of password protection is sufficient.

Usable for all releases.

SHA-256 256-bit • For V2R6.2 and above

(new installations only)

Very secure

Use where a high level of password protection is essential.

Usable only for V2R6.2 and above.


Chapter 5: Managing Network SecurityNetwork Traffic Encryption

Related Topics

For more information on how to set DBS Control and Gateway Control options, see Utilities.

For information about the use of deprecated logons during an upgrade to a new version of Teradata Database or running the script to detect SHA-encrypted passwords during a backdown, see the upgrade manual for the Teradata Database version and operating system to which you are upgrading.

Network Traffic Encryption

Users have the option of encrypting data transmitted between client and server. Although security provided by the encryption of transmitted data is desirable, you should not use this feature indiscriminately. Depending on the application you use and the type of session being run, encrypting data may significantly reduce system performance. Users should not encrypt a session unless the value of the security outweighs the potential performance losses. The security administrator should provide a clear policy statement to all database uses about when network 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.

Related Topics

For details on enabling encryption within a specific client application, see the users guide for that application.

For details on how to view or edit security mechanism property settings, see “General Rules for Editing” on page 126.

For information about how to enable or disable encryption during logon from a client application, see the users guide for the application.

For details on how encryption affects system performance, see Performance Management.

Data Integrity

Teradata Database is set by default to check all received messages against what was sent to ensure that data has not been corrupted during transmission


Chapter 5: Managing Network SecurityMechanisms Define the Security Context

Mechanisms Define the Security Context

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

• to separately enable and disable mechanisms

• edit the values of individual properties within each mechanism

• set up and customize interfaces with external security applications

For detailed information on the description and use of Teradata Database security mechanisms, see “TDGSS Security Mechanisms” on page 118.

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.

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 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 only available on Windows systems. The NTLM mechanism does not appear in the configuration files or on logon menus for 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 TDGSS User Configuration files to disable (and also to re-enable) a mechanism. Make sure you fully understand the effects of changing a mechanism’s availability status before you try enable/disable a mechanism.

Restrictions

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, and LDAP mechanisms.

• Teradata Replication Services: Allows use of only TD1 or TD2, depending on the destination system.

In addition, users being externally authenticated can only choose mechanisms that support external authentication.


Chapter 5: Managing Network SecurityMechanisms Define the Security Context

Related Topics

For an overview of mechanism selection within the logon sequence, see “Network Logon Formats” on page 16.

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

Default Mechanism

To relieve users of the necessity of selecting a security mechanism, Teradata Database also allows for 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 TDGSS Configuration file is factory preset with a default mechanism (TD2) and the system will automatically use it. The client version of the Configuration file does have a factory preset default, to allow for differences in requirements among client groups. You can edit the TDGSS User Configuration File to:

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

Mechanism Handling

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; the logon is successful and the system uses the specified mechanism.

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


Chapter 5: Managing Network SecuritySupport for External Authentication

• 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; the server also 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 TDGSS User Configuration files, see “Changing the TDGSS Configuration” on page 124.

Support for External Authentication

Many client systems already have well developed security applications in place before they are connected to Teradata Database. Therefore, some TDGSS mechanisms are made to interface with supported security applications, allowing the applications to perform such functions as external authentication and/or authorization of users.

Related Topics

For detailed information on enabling external authentication, see “External Authentication for Network-Attached Clients” on page 37.

For detailed information on the set-up required for authentication of users by a directory, see Chapter 6: “Using a Directory to Manage Database Users.”


Chapter 5: Managing Network SecurityTDGSS Library

TDGSS Library

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, which is 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 is made up of front-end application program interfaces (APIs) for both C and Java-based applications. In addition, it has a back-end interface for the C library that consists of a number of sub-libraries, each of which provides compatibility with a different external security standard.

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

TDGSS Installation

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.

• On every server node:

• One copy of TDGSS (the TDGSS server package)

• One copy of TeraGSS (the server also uses the client security functions)

Note: 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, must have both TDGSS and TeraGSS installed to enable network communication among nodes.


Chapter 5: Managing Network SecurityTDGSS Installation

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, if there is a version mismatch between client and server, you will only be able to use security features common to both 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 for a particular Teradata Database release.

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.

For detailed information on installation of TDGSS or TeraGSS on the server, see the Parallel Upgrade Tool manual for your database operating system and Teradata Database release.

Locating TDGSS Files

Unless the system administrator chooses an alternate location during installation, the TDGSS files are located in the following default directories:

Administrator activities described in the sections that follow require that you access some or all of the TDGSS files, so you should become familiar with their contents and location.

For detailed instructions on installing TDGSS, refer to the installation, upgrade, and migration publications listed in the Release Definition for the release you are installing.

Note: The server file locations are automatically determined by the Parallel Upgrade Tool (PUT), and are as shown in the table above. The client files are installed manually and the location may vary slightly from what is shown for different systems and platforms.

System Type/OS Client System File Location Server System File Location

Windows Systems C:\Program Files\NCR\Teradata GSS\<TDGSS file name>

C:\Program Files\NCR\TDAT\TDGSS\LSERVER\<TDGSS file name>

Unix Systems (except Linux)

/usr/teragss/<TDGSS file name> /usr/tdgss/server/<TDGSS file name>

Linux Systems /opt/teradata/tdat/teragss/ /opt/teradata/tdgss/<TDGSS file name>


Chapter 5: Managing Network SecurityTDGSS Installation

TDGSS File Contents

TDGSS is fully functional as soon as you complete installation on your client and server systems.

TDGSS files include the following:

• /bin executable files:

• Libraries containing callable TDGSS functions

• Administrator tools, such as dumpcfg, tdgssconfig, tdsbind, tdgsspkgrm, tdssearch, 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 schema for adding database-specific information to supported directories

• /inc files: Application programmer interface

• /lib files: Library of routines used by Teradata in mechanism development

TDGSS Site File

The TDGSS site file contains the working version of the TDGSS User Configuration file that the system uses to create tdgssconfig.bin. The site file is located in a different directory than other TDGSS files, as follows:

Operating System On each server node On each client

Linux /opt/teradata/tdat/tdgss/site /opt/Teradata/teragss/site

Other UNIX (including MP-RAS)

/usr/tdgss/site usr/teragss/site

Windows C:\Program Files\NCR\TDAT\TDGSS\site

C:\Program Files\NCR\Teradata GSS\site


Chapter 5: Managing Network SecurityC/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 physical client machine, then Java applications must be configured to use the TeraGSS security library's 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 physical 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 TeraGSS directory that contains the TeraGSS User Configuration file, TdgssUserConfigFile.xml.

The following items must be included in the classpath for standalone Java applications. They must also be included in the Data Source classpath for JDBC Driver components in an application server environment.

• terajdbc4.jar

• tdgssjava.jar

• The directory containing TdgssUserConfigFile.xml

Unfortunately, not all classloaders support the specification of a directory on the classpath. 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 complete instructions on how to use 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, and an extra step must be performed to enable this indirect sharing.


Chapter 5: Managing Network SecurityC/C++ and Java Application Sharing of TDGSS Configuration Files

Execute a “jar update" command to take the TeraGSS User Configuration file from the TeraGSS directory and to put the TeraGSS User Configuration file into the tdgssconfig.jar file from the Teradata JDBC Driver download package, as follows:

jar uvf tdgssconfig.jar TdgssUserConfigFile.xml

Note: If you use the Jar Update method, you must run the command again each time you modify the TeraGSS User Configuration file. Then restart the application server or environment so that the modified tdgssconfig.jar will be used.


Chapter 5: Managing Network SecurityTDGSS File Maintenance Tools

TDGSS File Maintenance Tools

It may not be practical for you to install or upgrade all parts of your 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.

TeraGSS, the client version of TDGSS, provides two utilities, tdgsspkgrm and tdgssversion, to facilitate the management of multiple TeraGSS versions on the client system and server.

Use the parallel upgrade tool (PUT) to manage TDGSS versions on the server.

tdgsspkgrm

Tdgsspkgrm is included only with TeraGSS for Unix platforms. For Windows platforms, use the Add/Remove Programs panel to manage TDGSS versions.

You can use the tdgsspkgrm tool to:

• determine the current active version of TeraGSS

• determine the TeraGSS version(s) available for removal

• remove versions of TeraGSS that you no longer use

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

Note: For a list of typical TDGSS file locations on various operating systems, see “Locating TDGSS Files” on page 92.

2 Enter:

tdgsspkgrm

3 The system will return information similar to the following example:

TeraGSS current version:

06.00.00.0x

TeraGSS versions available for removal:

06.00.00.0w

4 If you want 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 a version of TeraGSS you no longer plan to use, 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


Chapter 5: Managing Network SecurityTDGSS File Maintenance Tools


2 Enter:

tdgsspkgrm -h [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 view TeraGSS versions.

tdgssversion

The tdgssversion tool is included with TeraGSS on all platforms. Use the tool to survey the available versions of TeraGSS and to switch versions, to maintain version compatibility or access features that are not available on all versions.

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. For example, on a Windows system, cd to:

C:\Program Files\NCR\Teradata GSS\nt-i386\LCLIENT\bin


2 Enter:

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 tdgssversion is located. For example, on a Windows system, cd to:

C:\Program Files\NCR\Teradata GSS\nt-i386\LCLIENT\bin

Note: For a list of typical tdgss file locations on various operating systems, see “Locating TDGSS Files” on page 92.

2 Enter:

tdgssversion -h [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.


Chapter 5: Managing Network SecurityTDGSS 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 User Configuration file 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:

Once you install the TDGSS Configuration files on the client and server, TDGSS is ready to use--no further action is required. However, security administrators have the option of editing some of the property values in User Configuration files to suit their unique system security needs. Editing the User Configuration file does not take affect until you save the edited file and run the TDGSS Configuration Tool.

For information on editing the TDGSS User Configuration files and using the TDGSS Configuration Tool, see “Changing the TDGSS Configuration” on page 124.

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 or mechanism properties are added to TDGSS, they will appear only in the new library configuration file.

User Configuration file • Displays only editable mechanism properties.

• Properties that are shown initially have the same values as in the Library Configuration file.

• The system defers to any changes (from what is shown in the Library files) that it finds in this file, to determine current security function.

• This file is not changed by installation of a new release of TDGSS, to avoid overwriting any edits you may have made to the user configuration. Therefore, any new mechanisms or properties contained in a new release of TDGSS must be manually transferred from the library to the user configuration files.


Chapter 5: Managing Network SecurityTDGSS Legal Values

TDGSS Legal Values

There are seven classes of security attributes in the Legal Values section of the TDGSS Library and User Configuration files. They set the allowable values that form the basis for system security functions. They are not user-editable and will only change if TDGSS is re-designed in a future release. The Algorithms, Quality of Protection (QOP), and Mechanisms configurations defined later in this chapter are based on these legal values.

The classes of legal values are:

• Configuration File Header: Defines whether the file is a Library or User configuration file.

• Algorithm Name: Names of the encryption algorithms available for use

• Key Length: Allowable encryption key lengths (in bits)

• Mode: Available encryption modes

• Padding: Supported encryption padding types

• Interface Type: Supported security interface types

• Algorithm Type: The encryption functions available

• Mechanism Properties: The properties that define the function of each mechanism

Note: Some legal values may not be used for a particular release of TDGSS.

Legal values are not meant to be changed. For information on editable mechanism properties, see “Making TDGSS Configuration Changes on Teradata Database Servers” on page 157.

Configuration File Header

The Header section identifies the file type (Library or User) and the file version.

Example 1: TDGSS Library Configuration File

The header for the Library Configuration file appears in the following default form:

<Header Version="1" ConfigFileType="Library"> </Header>

Example 2: TDGSS User Configuration File

The header for the User Configuration file appears in the following default form:

<Header Version="1" ConfigFileType="User"> </Header>



AlgorithmName

The AlgorithmName class lists the encryption algorithms available for use. The algorithm functions listed in the Algorithm Configuration section are each identified with one of these algorithm names.

The table below describes supported algorithms:

Example: Algorithm Names

Supported algorithm names appear in the AlgorithmName section of TDGSS Legal Values in the following xml format:

<AlgorithmNameNONE="0"

Blowfish="1" AES="2" MD5="3" SHA1="4" DIFFIE_HELLMAN="5" SHA256="6" SHA512="7"> </AlgorithmName>

Algorithm Name Description

NONE Encryption not supported

Blowfish A 64-bit cipher with a variable length key

AES Advanced Encryption Standard algorithm

A symmetric block cipher using the rijndael algorithm that can process data blocks of 128 bits using cipher keys of 128, 192, and 256 bits

MD5 Message Digest Algorithm

Used for digital signature applications where a large file must be compressed in a secure manner

• SHA-1

• SHA-256

• SHA-512

Secure Hashed Standard algorithms

Used for computing a condensed representation of a message or data file

Diffie-Hellman An encryption key exchange algorithm invented by W. Diffie and M.E. Hellman



KeyLength

The KeyLength class lists the supported encryption key lengths. The key lengths shown in the Algorithm Configuration and QOP Configuration sections must take their values from this list.

Note: Some of the supported key lengths may not be activated for a particular release of Teradata Database. Active key lengths are those used in QOP configurations defined in the TDGSS Library Configuration file. To determine what encryption key lengths are activated for the current release, see “TDGSS Quality of Protection” on page 116.

The table below describes supported key lengths:

This list of supported key lengths will not change unless you install a new release of TDGSS that supports a different set of key lengths.

Example: Key Lengths

Supported encryption key lengths appear in the KeyLength section of TDGSS Legal Values in the following xml format:

<KeyLength K0="0" K128="128" K192="192" K256="256" K416="416" K448="448" K512="512" K1024="1024" K2048="2048"> </KeyLength>

Note: The numbers associated with each key length are used by the underlying mechanism code to represent the key length in bits.

Key Length Description

K0 Encryption not supported.

K128 The numeric portion of the values shown are equal to the length, in bits, of the associated encryption keys.

K192

K256

K416

K448

K512

K1024

K2048



Mode

The Mode class defines the encryption mode types supported by TDGSS. The Mode attribute values shown in the Algorithm Configuration and QOP Configuration sections are drawn from this list.

Note: If you use Java Cryptography Extensions (JCE), the mode types must match the mode types supported by TDGSS.

The table below describes the encryption mode types.

This list of supported modes will not change unless you install a new release of TDGSS that supports a different set of encryption modes.

Example: Modes

Supported encryption modes appear in the Mode section of TDGSS Legal Values in the following default xml form:

<Mode NONE="0" CBC="1" CFB="2" ECB="3" OFB="4"> </Mode>

Note: The numbers associated with each mode type are used by the underlying mechanism code to represent the represent the mode type.

Mode Type Description

NONE Encryption not enabled

CBC Cipher-block Chaining

An operational mode for a block cipher, in which a a set number of bits is encrypted as a single unit or block with a cipher key applied to the entire block

CFB Ciphertext Feedback

An operational mode for a block cipher, in which a plaintext values are encrypted and transferred one at a time

ECB Electronic Code Book

An operational mode for a block cipher in which each possible block of plaintext has a defined corresponding ciphertext value

OFB Output Feedback

An operational mode for a block cipher that permits encryption of differing block sizes, but the output of the encryption block function is the feedback instead of the cipher text



Padding

The Padding class lists theencryption padding types supported by TDGSS. The Algorithm Configuration and QOP Configuration sections of TDGSS use the encryption padding types described in this list.

Note: If you run any Java Cryptography Extensions (JCE) on your system, the encryption padding must be one of the types supported by TDGSS.

The following table describes the supported encryption padding types:

This list of supported encryption padding types will only change if you install a new release of TDGSS that supports a different set of padding types.

Example: Padding Types

Supported encryption padding types appear in the Padding section of TDGSS Legal Values in the following default xml form:

<Padding NoPadding="0" OAEPWithDIGESTAndMGFPadding="1" PKCS1Padding="3" PKCS5Padding="4" SSL3Padding="5"> </Padding>

Note: The numbers associated with each padding type are used by the underlying mechanism code to represent the represent the padding type.

Padding Type Description

No Padding Encryption padding not used

OAEPWithDIGESTAndMGFPadding Optimal Asymmetric Encryption Padding with DIGEST function and Mask Generation function, for Java

PKCS1 Padding Public Key Cryptography Standard 1

PKCS5 Padding Public Key Cryptography Standard 5

SSL3 Padding Secure Sockets Layer

A protocol that allows two parties to authenticate and establish a session key to encrypt the rest of the session



InterfaceType

The InterfaceType class lists the encryption interfaces supported by TDGSS. The security mechanisms defined in the Mechanisms Configuration section must use an encryption interface drawn from this list.

The following table describes the supported interface types:

This list of supported encryption interface types will only change if you install a new release of TDGSS that supports a different set of interface types.

Supported interface types appear in the InterfaceTypes section of Legal Values in the following default form:

<InterfaceType> gss sspi

teradata custom </InterfaceType>

Interface Type Description

GSS Standard UNIX interface.

SSPI Standard Windows interface.

Teradata Default Teradata interface.

Custom Reserved for future use. Allows for the creation and use of a custom security interface when the feature is implemented.



AlgorithmType

The Algorithm Type class lists the encryption functions supported by TDGSS. Security algorithms defined in the Algorithms Configuration section specify the function of the algorithm by using one of the algorithm types described in this class.

The following table describes the supported algorithm functions:

This list of supported algorithm functional types will only change if you install a new release of TDGSS that supports a different set of functional types.

Supported encryption functions appear in the AlgorithmType section of TDGSS Legal Values in the following default xml form:

<AlgorithmType> Confidentiality Integrity KeyExchange </AlgorithmType>

Algorithm Type Function

Confidentiality Encrypts transmitted data to insure confidentiality

Integrity Checks a message encrypted by the sender against the received, decrypted message to ensure that none of the data has been changed or lost

Key Exchange Encrypts the exchange of encryption keys between initiator and acceptor



MechanismProperties

The MechanismProperties class defines the functional properties contained in TDGSS security mechanisms. Most mechanism properties are simple, settable, Yes/No flags. All property values are preset for the standard mechanisms contained in the TDGSS Library. You can change the settings for some existing mechanism properties, or add new mechanism properties when they are made available in a new Teradata Database release, by editing the TDGSS User Configuration file and then running the tdgssconfig tool.

For an overview of available security mechanisms and their factory preset property values, see “TDGSS Security Mechanisms” on page 118.

For information on how to edit property settings, see “Changing the TDGSS Configuration” on page 124.

For information on allowable editing for property values, see “Making TDGSS Configuration Changes on Teradata Database Servers” on page 157 and “Making TDGSS Configuration Changes on Teradata Clients” on page 161.

The following table describes the mechanism property types, allowable settings, and inter-property dependencies.

Mechanism Property Description

Basic Functional Properties

The following three properties, from AuthenticationSupported through SingleSignOnSupported, are provided mainly for reference and describe the basic capabilities of the mechanism.

AuthenticationSupported Indicates whether or not the security mechanism supports external user authentication.

The value of this property indicates how the mechanism functions and is for reference only. The function cannot be changed by altering the property value.

Valid Settings:

• yes = Mechanism supports authentication

• no = Mechanism does not support authentication

AuthorizationSupported Indicates whether or not the security mechanism supports external user authorization.

Valid Settings:

• yes = Authorization supported

• no = Authorization not supported

A setting of Yes is only valid for mechanisms that allow mapping of directory users to Teradata Database users, roles, and profiles (currently only the LDAP mechanism).



SingleSignOnSupported Indicates whether or not the mechanism supports single sign-on, i.e. users are not required to re-submit credentials when logging on to the database.

The value of this property indicates how the mechanism functions, and is for reference only. The function cannot be changed by altering the property value.

Valid Settings:

• yes = The mechanism supports single-sign-on (Allows user to logon without re-submitting a Teradata Database username and password).

If this property is set to yes, then the AuthenticationSupported property must also be set to yes.

• no = The mechanism does not support single sign-on.

Mechanism Status Properties

The following three properties, from MechanismEnabled through MechanismRank, indicate the status of the mechanism.

MechanismEnabled Indicates whether or not the mechanism is enabled and available for use.

Valid Settings:

• yes = Mechanism enabled

• no = Mechanism disabled

DefaultMechanism Indicates whether or not the mechanism is the default mechanism. If a mechanism is defined as the default mechanism, it will be automatically used by the system if no mechanism is specified as part of the logon string.

Valid Settings:

• yes = This mechanism is the default mechanism

• no = This mechanism is not the default mechanism

MechanismRank Allows the administrator to set the preferred order of mechanism presentation to the user.

Valid Settings;

• Numeric

• The lowest number has the highest rank

Note: This property is not currently used by the system, but is reserved for future use.

Operational Properties

Use the following group of properties, from DelegateCredentials through CredentialUsage, to set flags to request that certain operational options be employed by the system.




DelegateCredentials Indicates whether or not to delegate credentials to a remote peer, such as Teradata Query Director.

Valid Settings:

• yes= Delegate credentials

• no = Do not delegate credentials

MutualAuthentication Indicates whether or not the client requests that the server authenticate itself to the client.

Valid Settings:

• yes = Mutual authentication supported

• no = Mutual authentication not supported

ReplayDetection Indicates whether or not the client requests detection of duplicate messages when they are protected with:

• tdgss_wrap

• tdgss_get_mic

Valid Settings:

• yes = ReplayDetection supported

• no = ReplayDetection not supported

OutOfSequenceDetection Indicates whether or not the client requests detection of out-of-sequence protected messages.

Valid Settings:

• yes = Out of sequence detection supported

• no = Out of sequence detection not supported

ConfidentialityDesired Indicates whether or not the security mechanism supports encryption of messages transmitted between client and server.

Valid Settings:

• yes = Encryption supported

• no = Encryption not supported

IntegrityDesired Indicates whether or not the security mechanism checks the integrity of encrypted data upon decryption by the receiver.

Integrity checking is not supported for systems where the server software is V2R5.1.x or earlier.

Valid Settings:

• yes = Data integrity is checked

• no = Data integrity is not checked

AnonymousAuthentication This property indicates whether or not the system will reveal the client’s identity to the server.

Valid Settings:

• yes = AnonymousAuthentication supported

• no = AnonymousAuthentication not supported




DesiredContextTime The number of seconds the security context will remain valid.

Valid Settings:

• An integer, expressed in seconds.

• The default value = “”, meaning no time limit.

DesiredCredentialTime The number of seconds the security credentials will remain valid.

Valid Settings:

• An integer, expressed in seconds.

• The default value = “”, meaning no time limit

CredentialUsage Indicates whether the credential can be used by the client, server, or both.

Valid Settings:

• GSS C BOTH = Credential may be used to initiate or accept a security context.

• GSS C INITIATE = Credential may be used to initiate a security context.

• GSS C ACCEPT = Credential may be used to accept a security context.

LDAP Configuration Properties

The following properties, from LdapServerName through LdapClientRebindAuth, are only important if you plan to use the LDAP mechanism to authenticate directory users. These properties apply to the LDAP mechanism as follows:

• The TDGSS version (not the TeraGSS version) of the TDGSSUser Configuration files on all database server nodes.

• The TeraGSS version TDSGSS User Configuration files on the query director (if employed).

LdapServerName The DNS name of the network interface where the LDAP server is running.

Valid Settings:

• “” = The default setting. Will cause the default server to be used.

Use this setting when the database is running on MP-RAS or Linux.

• When the database is running on Windows, this setting must be the fully qualified DNS name of the LDAP server.

• This property can be set to the IP address of the directory server.

For detailed information on the allowable format for this property value, see “LdapServerName” on page 144.




LdapServerPort The designated port number where the LDAP server listens for directory information requests from the gateway.

Valid Settings:

• “389” = The default port for LDAP service. If your system already uses port 389, we recommend that you do not change it.

• Must be a valid, port number in the range of 1 to 65535.

LdapServerRealm The name of the domain or realm where the directory server resides.

Valid Settings:

For Teradata Database on Windows

• “” = The default domain setting, that is, the domain for the Teradata Database system.

• If directory users are being authenticated in a domain other than that in which Teradata Database resides, and the database is running on Windows, this value should be edited as follows:

• When the directory server application is Active Directory, specify the directory domain name.

• When the directory server application is Sun Java System Directory Server, specify the fully qualified DNS name of the directory server.

For Teradata Database on MP-RAS or Linux

• “”=The default realm setting, that is, a zero-length string. Use the default setting with the following exception:

If the directory is Active Directory and the LdapServerName property value won’t yield a name that is registered as an ldap service principal name for the Active Directory server, then the LdapServerRealm property must contain the fully qualified DNS name of the directory server.

LdapSystemFQDN The fully qualified distinguished name of the directory object that contains the description of the Teradata Database server. There is no default--this property must be defined.

Valid Settings:

• “” = Directory object not defined.

• The FQDN must refer to a tdatSystem object.




LdapBaseFQDN The fully qualified distinguished name of the directory object that contains the user and group objects.

Note: LdapBaseFQDN exists only for backward compatibility with previous releases. It is being replaced by the newer LdapGroupBaseFQDN and LdapUserBaseFQDN properties, for which it provides default values if they have not been set. If you currently have a value set for LdapBaseFQDN, you should edit it back to “” and then assign values to LdapGroupBaseFQDN and LdapUserBaseFQDN.

Valid Settings:

• “” = The default naming context for the directory.

Note: Using the default value may cause unnecessarily deep searches of the directory to find user and group objects.

• The LdapBaseFQDN must take the form cn=xxxx,cn=yyyy,dc=zzzz

LdapGroupBaseFQDN Specifies the FQDN of a directory object that is a parent of directory groups. When this property contains a valid FQDN value, the process of searching the directory that takes place during LDAP user authorization is narrower, more efficient, and faster.

This property, along with LdapUserBaseFQDN, is meant to replace the LdapBaseFQDN property. Set values for the LdapGroupBaseFQDN and LdapUserBaseFQDN properties and then set the value of the LDAPBaseFQDN back to “”.

Note: This property is optional and does not appear in the TDGSS User Configuration file. It must be transferred manually from the TDGSS Library Configuration file.

For information on how to add this property to the TDGSS User Configuration file, see “Planning A Configuration Change” on page 157.

Valid Settings:

• The default setting is “”, that is, no FQDN is specified. If this property is not set to a specific FQDN, the system will use the value of the LdapBaseFQDN property as the search base.

• Any valid FQDN for a parent object that contains directory groups.




LdapUserBaseFQDN Specifies the FQDN of a directory object that is a parent of directory users. When this property contains a valid FQDN value, the process of searching the directory that takes place during LDAP user authorization is narrowest, most efficient, and fastest.

This property applies only when the directory is Active Directory.

This property, along with LdapGroupBaseFQDN, is meant to replace the LdapBaseFQDN property. Set values for the LdapGroupBaseFQDN and LdapUserBaseFQDN properties and then set the value of the LDAPBaseFQDN back to “”.

Note: This property is optional and does not appear in the TDGSS User Configuration file. It must be transferred manually from the TDGSS Library Configuration file.

For information on how to add this property to the TDGSS User Configuration file, see “Planning A Configuration Change” on page 157.

Valid Settings:

• “” = The default setting, that is, no FQDN is specified. If this property is not set to a specific FQDN, the system will use the value of the LdapBaseFQDN property as the search base.

• Any valid FQDN for a parent object that contains directory users.

LdapClientReferrals Instructs LDAP to enable or disable referral-chasing.

Valid Settings:

• off = The default setting. Instructs LDAP to disable referrals.

• on = Instructs LDAP to enable referrals.

LdapClientDeref When LdapClientReferrals is set to on or referrals are being chased by default, this property indicates which kind of referrals are to be chased. Otherwise, this property has no meaning to LDAP.

Valid Settings:

• always = Any referral is chased.

• never = The default setting. No referrals are chased.

• finding = Only referrals that are generated while finding objects are chased.

• searching = Only referrals that are generated while searching for specific objects are chased.

LdapClientDebug If non-zero, LdapClientDebug causes the value it contains to be written into the LDAP debug flags. It is equivalent to the -d option in the standard LDAP tools, such as tdsbind and tdssearch. End users should not set this property without the aid of the TSC.

This property does not function when Teradata Database runs on Windows.

Valid Settings:

• The only valid setting is the default setting, 0. This is not a user-settable property.




LdapClientRebindAuth Instructs LDAP how to deal with authentication on the new connections formed when referral chasing is turned on with the LdapClientReferrals property.

This property does not function when Teradata Database runs on Windows.

Valid Settings:

• yes =The default. Informs LDAP to use the user credential info to authenticate on the new connection before continuing the search.

• no=Do not authenticate using the user credential info. Use an anonymous connection to continue the search.

Confidentiality Properties

The following properties define the mechanism elements that support confidentiality.

VerifyDHKey Checks the integrity of keys exchanged between client and server to insure that nothing has been lost during key exchange.

Valid Settings:

• yes = The system verifies the integrity of the DH key.

• no = The system does not verify the integrity of the DH key.

DHKeyP The DH key used by the system to encrypt data transmissions.

Valid Settings:

• The TDGSS Configuration files contain a standard preset key.

• You can substitute any valid DH key.

DHKeyG The encryption key multiplier. Increases the number of encryption key combinations that would have to be tried to break the code.

Valid Settings:

• The TDGSS Configuration files contain a standard preset key.

• You can substitute any valid DH key.

QOP The quality of protection. Describes the unique set of algorithm attributes used by the mechanism. Taken from the QOP section of TDGSS Legal Values.

Valid Settings:

• Any valid QOP--currently QOP 0 and QOP 1

• A particular mechanism may not support all valid QOPs



Chapter 5: Managing Network SecurityTDGSS Algorithms

TDGSS Algorithms

The Algorithms section of the TDGSS Library lists the algorithms available to implement confidentiality, integrity, and key exchange security functions.

Each algorithm takes its name from the “Algorithm Names” section of TDGSS Legal Values. The algorithms are defined by a common set of attributes. The values of these attributes describe the algorithm’s function. Some attributes are not applicable to some algorithm types, and some attributes may have more than one valid value. The Quality of Protection (QOP) section uses two of these algorithms to define each QOP type: one confidentiality algorithm and one integrity algorithm.

Algorithm configurations are preset and should not be modified.

The following table describes the configuration of Algorithm attributes:

Attribute Description

AlgorithmName The name of the algorithm.

Taken from the list of AlgorithmNames in the Legal Values section.

AlgorithmType The function of the algorithm.

Taken from the list of AlgorithmTypes in the Legal Values section.

LibraryName The name of the library with the code that implements the Algorithm.

The Library Name does not include the prefix or extension that may be part of the actual file name.

Prefix To avoid naming problems, in any given mechanism library the "tdgss" in all the function names is replaced with a prefix.

The prefix is placed in the configuration file so that tdgss can properly construct function names.

KeyLength The encryption key lengths, in bits, supported by the algorithm.

Taken from the list of KeyLengths in the Legal Values section.

Mode The encryption modes supported by the algorithm.

Taken from the list of Mode types in the Legal Values section.

Padding The encryption padding types supported by the algorithm.

Taken from the list of Padding types in the Legal Values section.


Chapter 5: Managing Network SecurityTDGSS Algorithms

The TDGSS Library Configuration file contains the standard preset algorithm configurations shown in the following examples.

Example 1: Blowfish Algorithm

<Algorithm AlgorithmName="Blowfish"

AlgorithmType="Confidentiality"LibraryName="openssl"Prefix="BF">

<KeyLength> K128 K256 K448 </KeyLength> <Mode> ECB, CBC, CFB, OFB </Mode> <Padding> NoPadding PKCS1Padding </Padding> </Algorithm>

Example 2: AES Algorithm

<Algorithm Name="AES" AlgorithmName="AES"

AlgorithmType="Confidentiality"LibraryName="custom"Prefix="AES">

<KeyLength> K128 K192 K256 </KeyLength> <Mode> ECB CBC OFB </Mode> <Padding> NoPadding PKCS1Padding PKCS5Padding </Padding> </Algorithm>

Example 3: MD5 Algorithm

<Algorithm AlgorithmName="MD5"

AlgorithmType="Integrity"LibraryName="openssl"Prefix="MD5">

</Algorithm>

Example 4: SHA1 Algorithm

<Algorithm AlgorithmName="SHA1"

AlgorithmType="Integrity"LibraryName="custom"Prefix="SHA1">

</Algorithm>

Example 5: Diffie-Hellman Algorithm

<Algorithm AlgorithmName="DIFFIE-HELLMAN"

AlgorithmType="KeyExchange"LibraryName="openssl"Prefix="DH">

<KeyLength> K128 K192 K256 K448 </KeyLength> </Algorithm>


Chapter 5: Managing Network SecurityTDGSS Quality of Protection

TDGSS Quality of Protection

The TDGSS Global Quality of Protection (QOP) types define detailed sets of encryption methods and attributes used by TDGSS security mechanisms to support confidentiality and integrity. A QOP defines a unique subtype of a supported Algorithm, specifying only a single value for each attribute, whereas Algorithms can specify multiple allowable attribute values.

For example: The Blowfish Algorithm supports three key lengths, two encryption modes, and three types of encryption padding. However, a QOP based on this Algorithm supports only one key length, one encryption mode, and one type of encryption padding.

Standard preset QOPs only use a few of the allowable Algorithm attribute combinations. The rest are for future use in subsequent Teradata Database releases.

QOP attribute values are preset and are not editable.

For a detailed look at Algorithm structure and content, see “Example 1: Blowfish Algorithm” on page 115.

The following table describes the attributes present in QOPs:

Attribute Description

Value Global QOP Identifier

The value is used by each security mechanism to specify the QOPs it supports.

ConfidentialityAlgorithm The encryption algorithm designated by the QOP to provide confidentiality.

KeyLength The length of the encryption key used by the encryption algorithm.

Note: Although several keylengths are listed in the Algorithms Legal Values, only the 128 bit encryption key is currently supported.

Mode The encryption mode type used by the encryption algorithm.

Padding The encryption padding type used by the encryption algorithm.

IntegrityAlgorithm The algorithm designated by the QOP to maintain message integrity from encryption through decryption.


Chapter 5: Managing Network SecurityTDGSS Quality of Protection

Example: QOP Types

The TDGSS Library Configuration file contains the Quality of Protection configurations shown in the following examples:

<GlobalQOPs>



<GlobalQOP Value="GLOBAL_QOP_0" ConfidentialityAlgorithm="Blowfish" KeyLength="K128" Mode="ECB" Padding="NoPadding" IntegrityAlgorithm="NONE"/>

 <GlobalQOP Value="GLOBAL_QOP_1" ConfidentialityAlgorithm="AES" KeyLength="K128" Mode="OFB" Padding="PKCS5Padding" IntegrityAlgorithm="SHA1"/>

</GlobalQOPs>


Chapter 5: Managing Network SecurityTDGSS Security Mechanisms

TDGSS Security Mechanisms

Teradata Database currently provides seven pre-defined security mechanisms, as shown in the following list.

Standard mechanisms:

• Teradata Method 2

• Kerberos

• NTLM

• LDAP

Mechanisms for support of legacy systems:

• Teradata Method 1

• Kerberos C

• NTLMC

Note: The Kerberos and NTLM mechanisms do not appear in TDGSS files installed on non-Windows systems.

Each mechanism is represented in the TDGSS Library Configuration files by the following: five mechanism identification attributes, 16 to 24 properties that define the mechanism’s function, and a Quality of Protection (QOP) type that defines the encryption algorithm used by the mechanism to support confidentiality.

The mechanism identification attributes, QOPs, and some other properties are not editable.

Related Topics

• For detailed information on Mechanism Properties, see “MechanismProperties” on page 106.

• For detailed information on the content of a QOP type, see “TDGSS Quality of Protection” on page 116.

• For information on editing mechanism property values and designating a default mechanism, see “Changing the TDGSS Configuration” on page 124.

Teradata Method1

Teradata Method 1 (TD1) is provided for compatibility with prior versions, and is the only mechanism the system can use where:

Users need not select TD1, the system will default to it when it is required. If TD2 is selected, the system will still default to TD1, where necessary.

TD1 does not support external authentication or authorization. Its only purpose is to provide backward compatibility to legacy systems and a basic security context in which the system can perform data encryption/decryption and integrity checking.



When using the TD1 mechanism, CLIv2 is the only client application from which you can run an encrypted session.

The TD1 mechanism appears in the TDGSS Library Configuration file as shown in the following example, which lists the standard preset values for each mechanism attribute and property.

Example 1: Teradata Method 1<Mechanism Name="TD1" ObjectId="1.3.6.1.4.1.191.1.1012.1.1.8" LibraryName="gssp2td1" Prefix="TD1" InterfaceType="teradata">

<MechanismProperties AuthenticationSupported="no" AuthorizationSupported="no" SingleSignOnSupported="no" DefaultMechanism="no" MechanismEnabled="yes" MechanismRank="10"

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>

Teradata Method 2

Teradata Method 2 (TD2) provides 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

TD2 supports running encrypted sessions from most Teradata Client applications.

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: Teradata Method 2</Mechanism>



<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"

DelegateCredentials="no" MutualAuthentication="yes" ReplayDetection="yes" OutOfSequenceDetection="yes" ConfidentialityDesired="yes" IntegrityDesired="yes" AnonymousAuthentication="no" DesiredContextTime="" DesiredCredentialTime="" CredentialUsage="0"

VerifyDHKey="no"DHKeyP="E4BE0A78F54C4A0B17E7E9249A78BCC08868C17281D8463C880937853E73DDC787E41580A8AFE2594D984C9E0814C590790354ECCD1BE8EA85961E5E0974B32EFE178335F061E80189B4BDAA20F67B47"DHKeyG="0500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000" />


</Mechanism>

Kerberos

Teradata Database employs the Kerberos mechanisms to provide confidentiality and integrity while supporting external authentication (Single Sign-on and Sign-on As) via Kerberos on Teradata Database for Windows, V2R6.0 or later. TDGSS Configuration files installed on non-Windows systems do not contain the Kerberos mechanism.

Kerberos Multiple LAN Adapter Restriction

The Kerberos authentication mechanism may fail when client users attempt to connect to server machines with more than one LAN adapter. In order to use the Kerberos 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 Kerberos mechanism to avoid the error message that will be generated if a user selects the Kerberos mechanism. Note that disabling Kerberos may eliminate the use of kerberos dependent logon features such as Single Sign-on and Sign-on As.

For further information on disabling Kerberos, see “MechanismEnabled” on page 131 and “Changing the TDGSS Configuration” on page 124.

For information on Kerberos dependencies for Single Sign-on and Sign-on As, see “External Authentication for Network-Attached Clients” on page 37.

Example: KRB5

The Kerberos 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>



<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" MechanismEnabled="yes" MechanismRank="40" DelegateCredentials="no" MutualAuthentication="yes" ReplayDetection="yes" OutOfSequenceDetection="yes" ConfidentialityDesired="yes" IntegrityDesired="yes" AnonymousAuthentication="no" DesiredContextTime="" DesiredCredentialTime="" CredentialUsage="0" />


</Mechanism>



NTLM

Teradata Database employs two NTLM mechanisms to provide confidentiality and integrity while supporting external authentication via NTLM on Windows systems where the server is running V2R6.0 or later.

Note: TDGSS files installed on non-Windows systems do not contain NTLM mechanisms.

The SSPI 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</Mechanism>

 <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" MechanismEnabled="yes" MechanismRank="60"

DelegateCredentials="no" MutualAuthentication="yes" ReplayDetection="yes" OutOfSequenceDetection="yes" ConfidentialityDesired="yes" IntegrityDesired="yes" AnonymousAuthentication="no" DesiredContextTime="" DesiredCredentialTime="" CredentialUsage="0" />


</Mechanism>

LDAP

The LDAP mechanism is used to support external authentication and authorization of users defined in a supported, LDAP-compliant directory.

Note: The six properties beginning with LdapGroupBaseFQDN are optional and do not appear in the TDGSS User Configuration file.



Example: LDAP

The LDAP mechanism appears in the TDGSS Library Configuration file as follows:

</Mechanism>



<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" 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="" LdapBaseFQDN=""

LdapGroupBaseFQDNLdapUserBaseFQDNLdapClientReferralsLdapClientDerefLdapClientDebugLdapClientRebindAuth

VerifyDHKey="no"DHKeyP="E4BE0A78F54C4A0B17E7E9249A78BCC08868C17281D8463C880937853E73DDC787E41580A8AFE2594D984C9E0814C590790354ECCD1BE8EA85961E5E0974B32EFE178335F061E80189B4BDAA20F67B47"DHKeyG="0500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000" />


</Mechanism>


Chapter 5: Managing Network SecurityChanging 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.

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.

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

Editing suggestions and restrictions are noted in the “Editing Guidelines” section for each mechanism property, beginning with “MechanismEnabled” on page 131.

For specific instructions on how to locate and edit the TDGSS User Configuration files, see “Locating TDGSS Files” on page 92.

Mechanism Property Handling

In order to properly edit mechanism property values, you should understand how the system uses the properties.

The system follows this sequence to make use of a mechanism property:

1 The user requests a mechanism, or defers to the default mechanism, at logon.

2 If the mechanism doesn’t support a particular property, the property value indicated in the User Configuration files is ignored.

3 If the mechanism supports a property, the client system sends out a request (as part of establishing the session security context) for the property to be handled according to how the property value is set in the client user configuration file:

• If the property value has not been changed in the client TDGSS User Configuration file, the system will use the default value.

• If the property value is currently hard-coded to the default value, the system will ignore any edits to the value in the client TDGSS User Configuration file, and will use the default value.

• If the property value has been edited in the User Configuration file and there is no hard-coding linking it to the default value, the system will use the edited value.

4 The client system then sends the property value as a request to the server. Except for the MechanismEnabled, DefaultMechanism, and AuthorizationSupported properties, the



system examines only the mechanism property values in the client User Configuration files. If any other property values are mismatched between server and client, they will not have any effect on session security context.

For information on how the MechanismEnabled and DefaultMechanism properties affect overall mechanism handling, see “Mechanism Handling” on page 89.

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 restrict what mechanisms are available to all clients.

The configuration must match on all 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 available to administrators logging on from database nodes.

Will not affect administrator logons from clients.



Packages Installed on Each Network-Attached Client

tdgssUserConfigurationFile TeraGSS Edit these files to restrict what mechanisms are available on individual clients.

The configuration may or may not match from one client to the next depending client requirements.





General Rules for Editing

When editing mechanism property values, keep in mind the following general rules:

• Before you edit a mechanism, refer to the property-specific editing guidelines for each property, as shown later in this section.

• You cannot add or delete mechanism properties, only change their values.

• Some mechanism properties are not active for some mechanisms, and some property values are hard-coded to 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 User Configuration files 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 89.

• You can individually enable or disable mechanisms.

Note: A user logon will fail if the selected mechanism is not in existence and 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 the following LDAP mechanism properties if you plan to enable directory-based user authentication:

• LdapServerName

• LdapServerPort (editing not required for some systems)

• LdapServerRealm (required when Teradata Database is running on Windows)

• LdapSystemFQDN

• LdapBaseFQDN

For further information on integrating external security directories, see Chapter 6: “Using a Directory to Manage Database Users.”

• The following optional LDAP properties can also be configured, but they do not appear in the LDAP mechanism and must be added manually:

• LdapGroupBaseFQDN (server only)



• LdapUserBaseFQDN(server only)

• LdapClientReferrals (client only)

• LdapClientDeref (client only)

• LdapClientDebug (client only)

• LdapClientRebindAuth

For information on the uses and valid settings for these optional properties, see “LDAP Configuration Properties” on page 109.

For information on editing the values of these properties, see the detailed material on the individual properties beginning with “LdapGroupBaseFQDN” on page 148.

For information on how to manually add these properties to the LDAP mechanism in the TDGSS User Configuration file, see “Making TDGSS Configuration Changes on Teradata Database Servers” on page 157.

• Edited values must conform to the editing guidelines listed for each property as shown in the sections that follow.

• If you edit the TDGSS server configuration, you must make the change in the User Configuration file on every node in the server system. Similarly, if you want to 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 TDGSS server configuration files does not result in changes to the TDGSS client configuration files--you must edit the files individually.

Note: Remember, there are two sets of client files--one for client stations, and one for the 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 TDGSS User Configuration files, you must run the TDGSS Configuration Tool to make the system aware of the changes.



AuthenticationSupported

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:

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.

Mechanism Property Supported? Property Editable?

TD1 No No

TD2 No No

KRB5 Yes No

KRB5C Yes No

NTLM Yes No

NTLMC Yes No

LDAP Yes No



AuthorizationSupported

This property determines whether or not the mechanism supports non-Teradata Database user authorization.


The value of this property is factory preset to no for all mechanisms except LDAP.


The AuthenticationSupported property is supported by the following mechanisms:

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 is set 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.


TD1 No No

TD2 No No

KRB5 No No

KRB5C No No

NTLM No No

NTLMC No No

LDAP Yes Yes



SingleSignOnSupported

This property indicates whether or not the mechanism supports Single Sign-on.


The value of this property is factory preset to yes for all mechanisms that support single sign-on.


SingleSignOnSupported property is supported by the following mechanisms:

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 for Network-Attached Clients” on page 37.

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

Mechanism Property Supported Property Editable?

TD1 No No

TD2 No No

KRB5 Yes No

The property value is hard coded to yes for all mechanisms that support it.

KRB5C

NTLM

NTLMC

LDAP No No



MechanismEnabled

This property determines whether or not a mechanism is available for use.


The value of this property is factory preset to yes (enabled) for all mechanisms.


The MechanismEnabled property is supported by the following mechanisms:

Editing Guidelines

You can edit the TDGSS User Configuration file to enable and disable mechanisms according to the following guidelines:

• 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 any mechanisms that you do not plan to use. Users who select a disabled mechanism will 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 the LDAP mechanism 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.

• Make sure that all mechanisms enabled on any client are also enabled on all nodes of the server.

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


TD1 Yes Yes

TD2 Yes Yes

KRB5 Yes Yes

KRB5C Yes Yes

NTLM Yes Yes

NTLMC Yes Yes

LDAP Yes Yes



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”

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


The MechanismRank property is not currently active for any mechanism.

Editing Guidelines

You can edit the TDGSS User Configuration file to assign mechanism rank according to the following:

• This property is not currently used by the system, but is reserved for future use.

• The system will ignore this property for all mechanisms.



DefaultMechanism

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.


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.

None of the mechanisms are preset to be the default mechanism in the client TDGSS User Configuration files.


DefaultMechanism is supported by the following mechanisms:

Editing Guidelines

Edit the TDGSS User Configuration file according to the following guidelines:

• 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 mechanism, the system uses the server default mechanism.

• If no mechanism is designated as the default, 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.


TD1 Yes Yes

TD2 Yes Yes

KRB5 Yes Yes

KRB5C Yes Yes

NTLM Yes Yes

NTLMC Yes Yes

LDAP Yes Yes



DelegateCredentials

This property indicates whether or not to delegate credentials to a remote peer.


The value of this property is factory preset to no for all 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:

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


TD1 No No

TD2 Yes Yes

KRB5 Yes Yes

KRB5C No No

NTLM No No

NTLMC No No

LDAP Yes Yes



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 un-authenticated 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.


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 Mutual Authentication in a future release of Teradata Database.


Mutual Authentication is supported by the following mechanisms:

Editing Guidelines

Use the following guidelines when editing MutualAuthentication in the TDGSS User Configuration file:

• 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 Kerberos to slightly enhance performance. However, because the performance effects of Mutual Authentication are extremely small, such editing is not really useful.


TD1 No No

TD2 No No

KRB5 Yes Yes

KRB5C Yes Yes

NTLM No No

NTLMC No No

LDAP No No



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.


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.


ReplayDetection is supported for the following mechanisms:

Editing Guidelines

Use the following guideline when editing ReplayDetection in the TDGSS User Configuration file:

• Any edits to this property will be ignored by the system.


TD1 No No

TD2 No No

KRB5 Yes No

KRB5C No No

NTLM Yes No

NTLMC No No

LDAP No No



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.


The value of this property is factory preset to yes for all mechanisms.


OutOfSequenceDetection is supported for the following mechanisms.

Editing Guidelines

Use the following guideline when editing OutOfSequenceDetection in the TDGSS User Configuration file:

• Any edits to the value of this property will be ignored by the system.


TD1 No No

TD2 No No

KRB5 Yes No

KRB5C No No

NTLM Yes No

NTLMC No No

LDAP No No



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.


The ConfidentialityDesired property is preset to yes for all standard mechanisms.


ConfidentialityDesired is supported by all standard mechanisms.

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.


TD1 Yes No

TD2 Yes

KRB5 Yes

KRB5C Yes

NTLM Yes

NTLMC Yes

LDAP Yes



IntegrityDesired

This property indicates whether or not the client requests integrity checking of messages by the receiver.


The value of this property is factory preset to yes for all mechanisms.


IntegrityDesired is supported by the following mechanisms:

Editing Guidelines

TDGSS does not support editing of this property value.


TD1 Yes No

The value of this property is hard-coded to yes for all mechanisms.

TD2 Yes

KRB5 Yes

KRB5C Yes

NTLM Yes

NTLMC Yes

LDAP Yes



AnonymousAuthentication

This property indicates whether or not to reveal the initiator’s identity to the acceptor.


The value of this property is factory preset to no for all mechanisms.


The AnonymousAuthentication property is not currently supported for any mechanisms, but is reserved for future use.

Editing Guidelines

Any edits to this property will be ignored by the system.


TD1 No No

The value of this property is hard-coded to no for all supporting mechanisms.

TD2 No

KRB5 No

KRB5C No

NTLM No

NTLMC No

LDAP No



DesiredContextTime

The DesiredContextTime property indicates the time duration, in seconds, that the security context defined by the mechanism will remain in effect.


The value of this property is factory preset to “”, that is, the security context cannot expire.


The DesiredContextTime property is not currently supported for any mechanism, but is reserved for future use.

Editing Guidelines

Edit the TDGSS User Configuration file to specify the DesiredContextTime according to the following guidelines:

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


TD1 No No

TD2 No No

KRB5 No No

KRB5C No No

NTLM No No

NTLMC No No

LDAP No No



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.


This property is factory preset to “”, that is, the credential cannot expire.


The DesiredCredentialTime property is supported by the following mechanisms:

Editing Guidelines

Edit the TDGSS User Configuration file to specify the DesiredCredentialTime according to the following guidelines:

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


TD1 No No

TD2 No No

KRB5 No No

KRB5C No No

NTLM No No

NTLMC No No

LDAP No No



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


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.


The CredentialUsage property interacts with the standard mechanisms in the following ways:

Editing Guidelines

Edit the TDGSS User Configuration file to specify the CredentialUsage according to the following guidelines:

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


TD1 Yes No

TD2 Yes No

KRB5 Yes No

KRB5C Yes No

NTLM Yes No

NTLMC Yes No

LDAP Yes No



LdapServerName

The LdapServerName property contains the DNS name of the network interface where the LDAP server is connected.

Note: If your system supports external authentication by a directory, you must edit the default value for this property.


This property is factory preset to “”, indicating that an LDAP server is not specified.


This property appears only in the LDAP mechanism.

Editing Guidelines

Edit the TDGSS User Configuration file to identify the LdapServerName according to the following guidelines:

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

Also see the editing instructions for the related LdapServerRealm property in “LdapServerRealm” on page 145.

LdapServerPort

This property identifies the port designation for the LDAP service port.

Note: If your system supports external authentication by a directory, you must substitute the actual port designation if it is different than the default.


This property is factory preset to “389”, the default LDAP service port.



Editing Guidelines

Edit the TDGSS User Configuration files to assign an LdapServerPort according to the following guidelines:


• Only the server requires LdapServerPort information. The client ignores this property.

• If your LDAP server is already listening on port “389” do not edit this property.

• If your LDAP server is not listening on port “389” you must edit the LdapServerPort property value to indicate the port your LDAP server is actually using.



LdapServerRealm

This property identifies the name of the SASL realm used by LDAP for authentication. It only applies to the LDAP mechanism. Set the LdapServerRealm property to a valid value so directory users do not need to enter realm information as part of the logon string.

Note: The system ignores this property when Teradata Database is running on Linux or MP-RAS and the LdapClientReferrals property is set to no.


This property is factory preset to “”, that is, no realm is specified.



Editing Guidelines

Edit the TDGSS User Configuration file to provide the LdapServerRealm value according to the following guidelines:

• Only the LDAP mechanism requires this information and only in the User Configuration files on the server. The client ignores this property.

• If you enter the valid fully qualified DNS name of your directory server for the LdapServerName property, the default value of the LdapServerRealm property will refer to it. If the LdapServerName property is not so configured, the default LdapServerRealm value is meaningless.

• Use the rules in the following table to determine the allowable property values:

For Teradata Database systems running on...

With this directory type and LDAP configuration... Set the LdapServerRealm property value to...

• Linux

or

• MP-RAS

All supported directories --LdapClientReferrals property set to off

If the LdapClientReferrals property is set to off the system will ignore the LdapServerRealm value.

Retain the default value (“”).

Active Directory -- LdapClientReferrals property set to on

If the LdapClientReferrals property is set to on the system requires an LdapServerRealm value.

Set the value as follows:

• If the LdapServerName property is properly set to the fully qualified DNS name of the directory server, retain the default LdapServerRealm value (“”) and it will refer to the LdapServerName value.

• If the LdapServerName property value won’t yield a name that is registered as an LDAP service principal name for the Active Directory server, you must use the fully qualified DNS name of the directory server because the default (“”) will be meaningless.



Windows Active Directory Use the default (“”) if either of the following are true:

• If Teradata Database and the directory server run in the same domain, no realm information is required.

• If the LdapServerName property is properly set to the fully qualified DNS name of the directory server, the default value of the LdapServerRealm property will refer to it.

If you can’t use the default you can do one of the following:

• Use the name of the Windows domain where the directory authentications will take place.

Example:

If the LdapServerName property is set to

LdapServerName=”xyzroot”

then the LdapServerRealm property must be set to something like:

LdapServerRealm=”xyzrootdom”

or,

• Use the fully qualified DNS name of the directory server.

Sun Java Directory Server The default property value (“”) is not valid for this directory type.

You must set the LdapServerRealm property to the fully qualified DNS name of the LDAP server.

For Teradata Database systems running on...

With this directory type and LDAP configuration... Set the LdapServerRealm property value to...



LdapSystemFQDN

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 the to locate the system without resorting to a deep search of the directory.


This property is initially factory preset to “”, that is, no system FQDN is specified.


The LdapSystemFQDN property only appears in the LDAP mechanism.

Editing Guidelines

Edit the TDGSS User Configuration file to identify the LdapSystemFQDN according to the following guidelines:


• Only the server requires LdapSystemFQDN 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.

LdapBaseFQDN

The LdapBaseFQDN property contains the fully qualified distinguished name of a directory object that contains the group of objects in which the system resides. If the values of LdapGroupBaseFQDN or LdapUserBaseFQDN are set, they will replace LdapBaseFQDN.


This property is initially standard preset to “”, that is, no name is specified.


The LdapBaseFQDN property only appears in the LDAP mechanism.

Editing Guidelines

Edit the TDGSS User Configuration file to identify the LdapBaseFQDN according to the following guidelines:


• Only the server requires LdapBaseFQDN information. The client ignores this property.

• Normally, the BaseFQDN is an object one level higher in the directory tree than the highest level group object named in a tdatRole object for the system identified by the LdapSystemFQDN.

• You can use any object name that meets the criteria as long as it is can generate a unique, fully qualified distinguished name.



LdapGroupBaseFQDN

The LdapGroupBaseFQDN property contains the fully qualified distinguished name of a directory object that contains the group objects. When set, this property helps narrow the search of the directory when a directory users is being authenticated by LDAP.




The LdapGroupBaseFQDN 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 TDGSS Configuration Changes on Teradata Database Servers” on page 157.

Editing Guidelines

Edit the TDGSS User Configuration file to identify the LdapGroupBaseFQDN according to the following guidelines:

• If you don’t edit the default value for this property (“”), directory searches will use the value of the LdapBaseFQDN.


• Only the server can use LdapGroupBaseFQDN information. The client ignores this property.

• Normally, the LdapGroupBaseFQDN is an object one level higher in the directory tree than the highest level group object named in a tdatRole object for the system identified by the LdapSystemFQDN.



LdapUserBaseFQDN

The LdapUserBaseFQDN property contains the fully qualified distinguished name of a directory object that contains the group of objects in which the system resides.

Note: This property is available for use only when the directory is Active Directory.




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.



Editing Guidelines

Edit the TDGSS User Configuration file to identify the LdapUserBaseFQDN according to the following guidelines:


• Only the server can use LdapUserBaseFQDN information. The client ignores this property.

• Normally, the LdapUserBaseFQDN is the FQDN of an object one level above the parent object that contains users.



LdapClientReferrals

The LdapClientReferrals property instructs LDAP to enable or disable referral chasing.


This property is initially factory preset to off, that is, it instructs LDAP to not chase referrals.


The LdapClientReferrals property only appears in the LDAP mechanism.

Note: This property only 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 on every server node to make this feature available.



Editing Guidelines

Edit the TDGSS User Configuration file to enable or disable LdapClientReferrals according to the following guidelines:


• Only the TDGSS User Configuration files on the server, and the query director, if used, can use LdapClientReferrals information. The client ignores this property.

• Set this property to on to enable referral chasing.

• Set this property to off to disable referral chasing. If you set this property to off and Teradata Database is running on MP-RAS or Linux, the default LdapServerRealm property value (“”) will have no meaning and you must edit it to a valid value.

For more information on editing the LdapServerRealm property, see “LdapServerRealm” on page 145.



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


This property is initially preset to never, that is, LDAP will not chase any kind of referrals.


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.



Editing Guidelines

Edit the TDGSS User Configuration file to define the type of referrals to be chased according to the following guidelines:

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



LdapClientDebug

When set properly, the LdapClientDebug property assists the TSC in debugging LDAP directory issues. This property is not user-settable.


This property is initially preset to 0, that is, no debugging parameters are specified.


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.



Editing Guidelines

Edit the TDGSS User Configuration file to specify the debugging parameters in LdapClientDebug according to the following guidelines:

• Only the TSC can properly set a correct value. Do not attempt to set this value without TSC assistance.



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.


This property is initially standard preset to yes, that is, LDAP will use the users credentials to rebind.


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.



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.



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.


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.


The VerifyDHkey property is supported by the following mechanisms:

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.

• Both client and server files must be edited and must match.


TD1 No No

TD2 Yes Yes

KRB5 No No

KRB5C No No

NTLM No No

NTLMC No No

LDAP Yes Yes



DHKeyP and 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="E4BE0A78F54C4A0B17E7E9249A78BCC08868C17281D8463C880937853E73DDC787E41580A8AFE2594D984C9E0814C590790354ECCD1BE8EA85961E5E0974B32EFE178335F061E80189B4BDAA20F67B47"

Default Property Value for DHKeyG

This property is preset to a standard DH base key, such as:

DHKeyG="0500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"


The DHKey P and DHKey G properties are currently supported by the following mechanisms:


TD1 No No

TD2 Yes Yes

KRB5 No No

KRB5C No No

NTLM No No



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.

• Both client and server TDGSS User Configuration files must be edited, and must match.

• 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

NTLMC No No

LDAP Yes Yes



Chapter 5: Managing Network SecurityMaking TDGSS Configuration Changes on Teradata Database Servers

Making TDGSS Configuration Changes on Teradata Database Servers

Planning A Configuration Change

Teradata Database provides administrators the ability to customize security functions to meet site-specific security needs by editing security mechanism 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 on the server and on clients, see “Changing the TDGSS Configuration” on page 124 and “General Rules for Editing” on page 126.

For a detailed explanation of the rationale for editing mechanism properties, see the sections on mechanism property editing, beginning with “AuthenticationSupported” on page 128.

Required Configuration Change Tasks

Changing the TDGSS configuration on Teradata Database servers requires that you complete the following activities:

Note: On Teradata Database servers, verify that all nodes are running before you change the configuration. A non-running node will not pick up the configuration change.

1 On the PDN (Package Distribution Node), make a back-up copy of the TdgssUserConfig file.

2 Edit the TdgssUserConfigFile.xml.

If the configuration change includes adding optional properties to the LDAP mechanism for referral chasing, add the optional properties and edit their values (if necessary) along with any other planned editing.

For an explanation of the rationale for using optional LDAP properties, see “Optimization of Directory Searches” on page 224.

3 Run the tdgssconfig tool to update the TDGSSCONFIG GDO.

4 Run tpareset to cause the Gateway to pick up the configuration changes.

The configuration change process has minor differences among operating systems. See the sections beginning with “Changing the TDGSS Configuration for Teradata Database on Windows” on page 158 for step-by-step instructions on changing the TDGSS configuration on Windows, Linux, and MP-RAS Teradata Database systems, 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 165.



Changing the TDGSS Configuration for Teradata Database on Windows

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\NCR\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 node and the xmppconfig utility, 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.


run_tdgssconfig

7 Run tpareset to activate the changes to the TDGSS configuration.

tpareset -f “use updated TDGSSCONFIG GDO”



Changing the TDGSS Configuration for Teradata Database on Linux

To change the TDGSS configuration on Linux, do the following:

1 On the Package Distribution Node (PDN), navigate to the Linux 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



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 TdgssUserConfigFile.xml you are editing.



/opt/teradata/tdgss/bin/run_tdgssconfig





Changing the TDGSS Configuration for Teradata Database on MP-RAS

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



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.



/usr/tdgss/server/bin/run_tdgssconfig




Chapter 5: Managing Network SecurityMaking TDGSS Configuration Changes on Teradata Clients

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 124 and “General Rules for Editing” on page 126.

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

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

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.

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, Linux, 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\NCR\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



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\NCR\Teradata GSS\site\TdgssUserConfigFile.xml

For tdgssconfig.bin:

c:\Program Files\NCR\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.


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 Linux Clients

To change the TDGSS Configuration on Linux clients, do the following:

1 Navigate to the Linux 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.



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.


/opt/Teradata/teragss/site/TdgssUserConfigFile.xml


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


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.



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 standard system backup procedures. Do not copy from the Library Configuration file!

3 Open a valid text editor, such as vi and bring up the working copy of the TDGSS User Configuration file.

vi teragss/site/TdgssUserConfigFile.xml




*/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:


usr/teragss/site/TdgssUserConfigFile.xml


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.


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 doesn’t 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 try another change. Either way, you must rerun the “Changing the TDGSS Configuration” procedure again to replace the changed configuration with the backup.

Note: If you choose to revert to and stay with the original configuration, you can skip the editing step.

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-g TDGSSCONFIG Reads the tdgssconfig gdo-f <bin file> Specifies the name of the bin file to be read-? Produces this help message

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.

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)

Example dumpcfg Output

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>dumpcfgdumpcfg: 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" 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"="E4BE0A78F54C4A0B17E7E9249A78BCC08868C17281D8463C880937853E73DDC787E41580A8AFE2594D984C9E0814C590790354ECCD1BE8EA85961E5E0974B32EFE178335F061E80189B4BDAA20F67B47" ATTR: "DHKeyG"="0500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"Level 03: MechQop (Element 16) ATTR: "Value"="0" DATA: "GLOBAL_QOP_1"




CHAPTER 6 Using a Directory to ManageDatabase 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 access rights 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 user- management tasks have been delegated to the directory. The administrator must perform configuration activities in both the database and the directory to exercise some of the LDAP user-management functions.

This chapter covers the following elements of directory-based user management:

• Supported directories

• Directory user characteristics

• Roles and profiles for directory users

• Teradata Database additions to the directory schema

• Populating the directory information tree with database-related objects

• Mapping directory users to Teradata Database users, roles, profiles, and IP filters

• Tools for searching the directory and verifying its content

Related Topics

For information on setting up users in the database, see Database Administration.

For information on using the LDAP mechanism to manage directory users, see “LDAP” on page 122.

For information on configuring a directory to manage database users, see “Configuring a Directory to Support Authentication and Authorization of Database Users” on page 180.


Chapter 6: Using a Directory to Manage Database UsersSupported Directories

Supported Directories

Teradata Database interfaces with the following directories that conform to the Lightweight Directory Access Protocol (LDAP), version 3:

Notes:

1 The Teradata Client is not affected by the support requirements shown above because it makes no use of the directory.

2 Support for other LDAP-compliant directories may be available through Teradata Professional Services.

3 If the Teradata Database server is running Windows 2003 and you want to authenticate users via Sun Java System Directory Server, you must install Microsoft Windows service pack 1 (SP 1) or higher.

Teradata Database Server Operating System Supported Directories

SUSE Linux Enterprise Server 9 • Active Directory (Windows Server 2003 only)

• Sun Java System Directory Server version 5.2

MP-RAS 3.03 • Active Directory (Windows Server 2003 only)


Windows Server 2003 (32- and 64-bit) • Active Directory (all versions)



Chapter 6: Using a Directory to Manage Database UsersUser Management Strategies

User Management Strategies

Introduction

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 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. They are then authenticated by the directory and authorized database privileges based on directory mapping to database users, roles, and profiles. Mapping of directory users requires a series of set-up tasks in both the database and the directory.

You can also use mapping to restrict directory user access to specific IP address.

In the event of security problems, you can quickly cut off directory user access by disabling the LDAP mechanism or setting the external authentication flag to off.

The following sections describe some typical administrator options for management of directory users:

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 assume the privileges of the matching database user.

This option is most useful where:

• mapping directory users to database users, roles, and profiles is not worth the required set-up 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 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.



Set-up Requirements

The authentication-only option requires minimal set-up:

• 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 for Network-Attached Clients” on page 37.

• Verify that the matching database user has WITH NULL PASSWORD privileges.

Option 2: Mapping Directory Users to Database Users, Roles, and Profiles

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 pseudo-user, EXTUSER, which already has a set of defined rights.

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 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 additional privileges associated 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 set-up process.

• Once the Teradata schema objects on which mappings are based are installed in Active Directory, you can’t remove them -- although you can change individual mappings. Other directories allow you to remove the 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 base schema extensions in the directory.

Note: You can also install the IP schema if you want to implement the optional access restrictions by IP address option. For further information, see “Option 3: Enhanced Security -- Restricting User Access by IP Address” on page 173.

• create external roles and additional profiles in the database for directory users in cases where no database user has the roles or profiles they need.

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

Option 3: Enhanced Security -- Restricting User Access by IP Address

In addition to mapping directory users to Teradata Database users, roles, and profiles, you can also use the mapping process to control directory user access to the database by IP address.

Note: You can implement IP access restrictions from either the database or the directory, but not both.

Advantages

IP access restrictions provide an extra measure of security beyond normal username and password logon restrictions.

• Even if a valid username and password are compromised by outsiders, they are useless unless employed from a computer with a valid IP address, which is likely to be unknown or physically inaccessible to the culprits.

• Valid users are prevented from accessing sensitive data from unsecured computers.

Limitations

Mapping users to IP restrictions requires a time-consuming set-up process.

Set-up Requirements

The set-up requirements for IP access restrictions are similar to those for mapping directory users to database users, roles, and profiles. However, implementation of IP access restrictions also requires that you install additional, IP-related schema extensions in the directory.



Related Topics

For information LDAP logons and directory authentication of users, see “Network Logon Formats” on page 16 and “LDAP Logons” on page 20.

For information on checking or editing the MechanismEnabled or AuthorizationSupported properties, see “Changing the TDGSS Configuration” on page 124.

For information on the default database privileges available to directory users, see “Characteristics of Unmapped Directory Users” on page 175.

For information on mapping directory users to Teradata Database users, roles, and profiles, see “Mapping Directory Users to Teradata Database Users, Roles, and Profiles” on page 203.

For information on enabling external authentication, see “Setting Up Logon Privileges for External Authentication” on page 38 and “Set-up Options for External Authentication” on page 38.

For detailed information on how to configure a directory to restrict user access to the database by IP address, see “Appendix D Implementing Control of User Access by IP Address.”


Chapter 6: Using a Directory to Manage Database UsersDirectory User Characteristics

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.

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 rights and 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 system-generated 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:

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

• Directory users mapped only to the pseudo user, EXTUSER, have the following privileges:


Chapter 6: Using a Directory to Manage Database UsersDirectory User Characteristics

• 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 rights 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 access rights inherited by or granted to them, or if they have been mapped to a role that permits it. 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 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.


Chapter 6: Using a Directory to Manage Database UsersRoles 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 must handled 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 external roles:

• The user that creates or drops an external role 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.

• External roles cannot be GRANTed, but must be assigned directly to directory users.

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


Chapter 6: Using a Directory to Manage Database UsersRoles 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 processing of user rights authorization.

Effects of ‘Drop External Role’ on Directory User Roles

If an external role is dropped the logged-on users to which that role is assigned will immediately cease to have the role available for rights authorization.

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

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.

Related Topics

For further information on... See...

Creating external roles Database Administration

Assigning profiles and external roles to directory users “Populating the Directory Information Tree” on page 199


Chapter 6: Using a Directory to Manage Database UsersAccess Logging of Directory Users

Access Logging of Directory Users

For the purpose of access logging, directory users are identified and logged by their directory-based identifiers. The identifier is supplied by the Gateway when a session is established and stored in DBC.SessionTbl.AuditTrailId. The identifier stored depends on the type of directory, as shown in the following table:

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 will return 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)

• A ‘SELECT ROLE’ request returns the current role for the session. The initial current role for a directory-based logon is a dummy role called ‘EXTERNAL’. Any time the directory-assigned roles are enabled, a SELECT ROLE request will return EXTERNAL as its result.

Directory ID Supplied for Access Logging

Active Directory 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 an “A”

• The remainder of the AuditTrailID may be composed of:

• the letters of the alphabet

• the numbers 0 through 5

Sun Java System Directory Server

This directory does not support GUIDs, so the AuditTrailID is the value of the authcid property in the logon string that was 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.


Chapter 6: Using a Directory to Manage Database UsersConfiguring a Directory to Support Authentication and Authorization of Database Users

Configuring a Directory to Support Authentication and Authorization of 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 detailed information on the system evaluation tasks recommended to prepare for configuring the directory integration, see Appendix C: “Preparing for Directory Integration--System Evaluation Tasks.”

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.

Teradata Schema 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.


Chapter 6: Using a Directory to Manage Database UsersDirectory Schema Overview

For further information on where objects appear in the hierarchy, see “Teradata Database Objects in the DIT Hierarchy” on page 195.

Teradata Schema Objects

The schema extensions allow for the creation of a number of objects in a supported directory to 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 system-generated 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”



Requirements for Teradata Schema Object Attributes in the Directory Information Tree

The Teradata extensions to the directory schema include attributes that Teradata schema 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. 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.

For usage, see “Attribute Usage Requirements” on page 184.

All directories

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

tdatUserMember FQDN of a directory user that maps to the Teradata Database User named in the cn attribute of the tdatUser object.

Optional.

For usage, see “Attribute Usage Requirements” on page 184.tdatRoleMember FQDN of a directory group that maps to

the Teradata Database role named in the cn attribute of the tdatRole object.

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.



tdatAllowedIP These attributes correspond to the allow and deny tags defined in the XML-based IP filter.

The attributes contain the IP address and mask defined in the parent ipFilter object.

Optional All Directories

tdatDeniedIP

tdatIPFilterMember FQDN of a directory profile that maps to the Teradata Database profile named in the cn attribute of the tdatProfile object.

tdatIPFilterMemberOf The FQDN of an IP filter named in an ipFilters object.

Generated.

For further information on generated objects and attributes, see “Special Objects and Attributes Required For Active Directory” on page 187.

Active Directory only

tdatUserMemberOf FQDN of a Teradata Database user in an Active Directory user object.

tdatRoleMemberOf FQDN of a Teradata Database role in an Active Directory group object.

tdatProfileMemberOf FQDN of a Teradata Database profile in an Active Directory user object.

Attribute Name Description Type Directory



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 Object UsagetdatUserMember

TdatRoleMember

tdatProfileMember

tdatIPFilterMember Common Name (cn)

All Optional Only applicable for some individual objects

Only applicable for some individual 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.

tdatRootNode This is the top-level Teradata Database object. It can be located anywhere in the directory.

Not applicable

Not applicable

Not applicable

Not applicable

No naming restrictions.

tdatSystem A Teradata Database system to which directory users can connect. This object is always the child of a tdatRootNode object.

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.



tdatContainer These objects must be children of a tdatSystem object.

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.

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.


TdatRoleMember

tdatProfileMember




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.


TdatRoleMember

tdatProfileMember




Special Objects and Attributes Required For Active Directory

To fully utilize the objects in the Teradata schema extensions, Active Directory requires three additional objects and their associated attributes and values. These objects must appear in the directory, but the directory administrator does not need do anything to make them function, as the data that goes into them is generated by Active Directory.

The following table shows the special Active Directory objects and associated attributes:

The attributes of these special Active Directory objects are linked to other attributes common to all directories:

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 the Active Directory is automatically removed as well.

• If the user object is removed from Active Directory, the corresponding tdatUserMember attribute is removed from the corresponding tdatUser object.

Object

Attributes

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

This common attribute... Links to this special Active Directory attribute...

tdatUserMember tdatUsermemberOf

tdatRoleMember tdatRolememberOf

tdatProfileMember tdatProfileMemberOf

tdatIPFilterMember tdatIPFilterMemberOf


Chapter 6: Using a Directory to Manage Database UsersSystem 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 description of the LDAP properties you must examine and instructions on how to edit them, see “Making TDGSS Configuration Changes on Teradata Database Servers” on page 157.

For detailed information on evaluating your system for directory integration compatibility, see “Appendix C Preparing for Directory Integration--System Evaluation Tasks.”

Once you have successfully completed these tasks, your system will be ready for directory integration.


Chapter 6: Using a Directory to Manage Database UsersInstalling Teradata Schema Extensions in a Supported Directory

Installing Teradata Schema Extensions in a Supported Directory

Installing the Teradata schema extensions on the directory server allows directory users to be linked to Teradata Database users, roles, and profiles. The following sections provide instructions on how to install the schema extensions on supported directory servers:

Warning: Once you install the schema (and add data) on Active Directory, these 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 add data to the Directory Information Tree.This is especially important on large systems that have several Active Directory servers. 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 (and the data they contain) will be replicated on all other Active Directory servers in the system. These changes cannot be undone without re-initializing the entire network of servers.

Schema Installation Options

There are two types of Teradata directory schema extensions contained in the TDGSS files for each supported directory:

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 don’t 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 schema and the IP restriction schema.

• For existing systems that have already installed the base schema: Add the IP restriction schema if you plan implement IP restrictions.

Schema Type Description

tdat.<dir type>.schema The base schema

Use this schema extension to enable mapping of directory users to Teradata Database users, roles, and profiles.

ipfilter.<dir type>.schema The IP restriction schema

Use this schema extension to enable IP-based access restrictions.



Installation on Active Directory from Teradata Database on Windows

You can use the LDIFDE.EXE tool (provided with Active Directory) to retrieve the Teradata schema extensions from the server and install them on Active Directory.

The server contains two types of schema extensions for use with Active Directory, as shown in the following table.

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 after you’ve installed them, don’t install the schema unless you plan to use them.

Do the following to install the Active Directory schema extensions:

1 Using tdssearch, determine the value to use for the schema naming context. For information on using tdssearch to determine this value, see “Determining the schemaNamingContext Value” on page 222.

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:


tdat.actdir.schema Use this schema extension to enable mapping directory users to Teradata Database users, roles, and profiles.

ipfilter.actdir.schema Use this schema extension to enable IP-based database access restrictions for directory users.

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.



3 Type the password for the administrator login when prompted.

4 You will get a messages that reads approximately like the following:

Connecting to K1Logging in as administrator in domain “K1dns” using SSPIImporting directory from file “tdat.actdir.schema”<or “ipfilter.actdir.schema”>Loading entriesxx 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

For further information about determining the schemaNamingContext, see “Finding User Information with tdssearch” on page 217.

-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=Configuration, DC=k1dns,DC=systemone,DC=com"

Changes the CN=Schema to the actual schema Naming Context.

Note: Your actual schemaNamingContext may vary.

-f tdat.actdir.schema

or

-f ipfilter.actdir.schema

The file LDIFDE is importing

You must import the files individually.

Syntax Element Description



Installation on Active Directory from Teradata Database on MP-RAS or Linux

The best way to install Teradata schema extensions from an MP-RAS or Linux server into Active Directory is to use a script. The TDGSS/.bin directory contains the ldapmodify utility. Use it as follows to install the schema on Active Directory from Teradata Database on MP-RAS or Linux:

Note: You can use the following example for installations from Teradata Database running on either Linux or MP-RAS, except that in Step 7, the Linux 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 server where schema # is to be loaded. #

2 - if [ $# != 1 ]; then3 - echo "Wrong # args"4 - echo "usage: $0 <server>"5 - exit 16 - fi

7 - cd /usr/tdgss/server/etc

8 - SNC=‘tdssearch -h $1 -b "" -s base schemanamingcontext | \9 - grep -i schemanamingcontext | \10 - cut -d’ ’ -f2‘

11 - if [ "$SNC" = "" ]; then12 - echo "Schema naming context not found on server $1"13 - exit 114 - 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 is running on a Windows 2003 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 Linux to Active Directory 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:

SASL/DIGEST-MD5 authentication started

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: administratorSASL SSF: 0

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.


tdat.sunone.schema Use this schema extension to enable mapping of directory users to Teradata Database users, roles, and profiles.

ipfilter.sunone.schema 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 ascertain whether or not additional action is required by directory set up for your site.


Chapter 6: Using a Directory to Manage Database UsersDirectory 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 199.

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.



The following table describes these objects:

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

Standard directory schema

ou=groups organizationalUnit Directory object that contains user and database objects


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


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




Figure 4: Lower-level Teradata Directory Objects in the DIT Hierarchy

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 second-level 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 by the tdatRootNode (cn=tdat) is rigid and must be defined exactly as shown.

The following table describes the objects in Figure 4:

1100A001

cn=systemone

cn=users cn=profiles

cn=user

cn=ipfilters

cn=ipfilter2cn=administrator cn=ipfilter1cn=jcm cn=bwq

cn=roles

cn=bwqprofcn=jcmprof


Top cn=systemone tdatSystem A Teradata Database system to which directory users can connect


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



Bottom cn=administrator tdatRole Teradata Database role Teradata directory schema extensions

cn=user tdatRole Teradata Database role

cn=filter1 tdatIPFilters IP restriction filter

cn=filter2 tdatIPFilters IP restriction filter



Chapter 6: Using a Directory to Manage Database UsersPopulating the Directory Information Tree

Populating the Directory Information Tree

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 ltools like LDIFDE.EXE (Windows) and the more common ldapadd and ldapmodify tools (UNIX).

For information on the entire set ov available LDAP tools, see “Other LDAP Tools” on page 223.

tdatRootNode Object

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: tdatRootNodedn: cn=tdat,dc=domain,dc=comobjectClass: tdatRootNodeobjectClass: topcn: tdat

tdatSystem Object

A tdatSystem object is required for every Teradata Database system that directory users will access.

Create tdatSystem objects by entering the following information in the DIT.

Example 2: tdatSystemdn: cn=systemone,cn=tdat,dc=domain,dc=comobjectClass: topobjectClass: tdatSystemcn: systemone



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 Naming Convention

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

tdatUser, tdatRole, tdatProfile, or tdatIPFilter 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.

Users

Example 3a: tdatContainer (Users)

Use the following syntax to construct a typical users container in the directory.

dn: cn=users,cn=systemone,cn=tdat,dc=domain,dc=comobjectClass: topobjectClass: tdatContainercn: users

Example 3b: tdatUserdn: cn=jcm,cn=users,cn=systemone,cn=tdat,dc=domain,dc=comobjectClass: topobjectClass: tdatUsercn: jcm

Roles

Example 4a: tdatContainer (Roles)dn: cn=roles,cn=systemone,cn=tdat,dc=domain,dc=comobjectClass: topobjectClass: tdatContainercn: roles

Examples 4b and 4c: tdatRoledn: cn=administrator,cn=roles,cn=systemone,cn=tdat,dc=domain,dc=comobjectClass: topobjectClass: tdatRolecn: administrator

dn: cn=user,cn=roles,cn=systemone,cn=tdat,dc=domain,dc=comobjectClass: topobjectClass: tdatRolecn: user

Profiles

Example 5a: tdatContainer (Profiles)dn: cn=profiles,cn=systemone,cn=tdat,dc=ncr,dc=comobjectClass: topobjectClass: tdatContainercn: profiles

Examples 5b and 5c: tdatProfiledn: cn=profileone,cn=profiles,cn=systemone,cn=tdat,dc=domain,dc=comobjectClass: top



objectClass: tdatProfilecn: profileone

dn: cn=profiletwo,cn=profiles,cn=systemone,cn=tdat,dc=domain,dc=comobjectClass: topobjectClass: tdatProfilecn: profiletwo

IP Filters

Example 6a: tdatContainer (IPFilters)dn: cn=ipfilters,cn=systemone,cn=tdat,dc=ncr,dc=comobjectClass: topobjectClass: tdatContainercn: ipfilters

Examples 6b and 6c: tdatIPFilterdn: cn=filter1,cn=ipfilters,cn=systemone,cn=tdat,dc=domain,dc=comobjectClass: topobjectClass: tdatIPFiltertdatAllowDeny: TRUEtdatAllowedIP: 141.206.0.0/16tdatDeniedIP: 141.206.35.0/24tdatIPFilterMember: cn=profileone,cn=profiles,cn=systemone,cn=tdat,dc=domain,dc=comtdatIPFilterMember: cn=profiletwo,cn=profiles,cn=systemone,cn=tdat,dc=domain,dc=comcn: filter1

dn: cn=filter2,cn=ipfilters,cn=systemone,cn=tdat,dc=domain,dc=comobjectClass: topobjectClass: tdatIPFiltertdatAllowDeny: FALSEtdatAllowedIP: 141.206.35.175/32tdatDeniedIP: 141.206.35.0/24tdatIPFilterMember: cn=Profile7,cn=profiles,cn=systemone,cn=tdat,dc=domain,dc=comtdatIPFilterMember: cn=Profile9,cn=profiles,cn=systemone,cn=tdat,dc=domain,dc=comcn: filter2


Chapter 6: Using a Directory to Manage Database UsersMapping Directory Users to Teradata Database Users, Roles, and Profiles

Mapping Directory Users to Teradata Database Users, Roles, and Profiles

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:

• 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 Userdn: cn=jcm,cn=users,cn=systemone,cn=tdat,dc=domain,dc=comchangeType: modifyadd: tdatUserMembertdatUserMember: 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 Rolesdn: cn=administrator,cn=roles,cn=systemone,cn=tdat,dc=domain,dc=comchangeType: modifyadd: tdatRoleMembertdatRoleMember: cn=dbas,ou=groups,dc=domain,dc=com

dn: cn=user,cn=roles,cn=systemone,cn=tdat,dc=domain,dc=comchangeType: modifyadd: tdatRoleMembertdatRoleMember: cn=users,ou=groups,dc=domain,dc=com


Chapter 6: Using a Directory to Manage Database UsersMapping Directory Users to Teradata Database Users, Roles, and Profiles

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 Profilesdn: cn=xxxprof,cn=profiles,cn=systemone,cn=tdat,dc=domain,dc=comchangeType: modifyadd: tdatProfileMembertdatProfileMember: uid=jcm,ou=people,dc=domain,dc=com

dn: cn=yyyprof,cn=profiles,cn=systemone,cn=tdat,dc=domain,dc=comchangeType: modifyadd: tdatProfileMembertdatProfileMember: 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, as shown in Examples 10a and 10b, based on the following rules:

• Presence of a user FQDN in a tdatIPFilterMember attribute of a tdatIPFilter object links the user to that filter.

• Absence of a user FQDN in any tdatIPFilterMember attribute of a tdatIPFilter object means that no directory user is affected by the filter.

Examples 10a and 10b: Mapped IPFiltersdn: cn=filter1,cn=ipfilters,cn=systemone,cn=tdat,dc=domain,dc=comchangeType: modifyadd: tdatIPFilterMembertdatIPFilterMember: cn=jcm,cn=users,cn=systemone,cn=tdat,cn=domain,cn=com

dn: cn=filter2,cn=ipfilters,cn=systemone,cn=tdat,dc=domain,dc=comchangeType: modifyadd: tdatIPFilterMembertdatIPFilterMember: cn=bwq,cn=users,cn=systemone,cn=tdat,cn=domain,cn=com


Chapter 6: Using a Directory to Manage Database UsersTesting Mapped Directory Users

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:

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

• Tdssearch tool: Use tdssearch 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 20.

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.


Chapter 6: Using a Directory to Manage Database UsersUsing BTEQ to Verify Directory User Mapping

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

User could not be externally authenticated with the information provided in the logon.

Use tdsbind to determine whether or not the directory user mapping implied in the logon actually exists in the directory.

Gateway error: User, account, or password information is invalid.

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.

Do not use Teradata Database usernames and passwords in the .logon statement of a directory logon.

DBS error: User identification is not authorized.

The Teradata Database user to which the directory user is mapped doesn’t exist in the database.

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.

DBS error: Profile ‘xxx’ does not exist.

Mapped Teradata profile (xxx) does not exist.

Use tdssearch 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.


Chapter 6: Using a Directory to Manage Database Userstdsbind

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 TDGSS LDAP authentication method (LDAP) 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.



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




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

If this property is omitted, tdsbind uses the value of the LdapClientDebug property from the TDGSS User Configuration file.

Valid Settings:

• Consult documentation from http://www.openldap.org for more information regarding the values that may be set.

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




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 199. The output in the examples was generated when tdsbind was run specifying the name of a configured directory user.

Example 1: Unmapped Directory User

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

Explanation of Example 1

The following table describes the meaning of each of the lines in Example 1:

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


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.

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 request (-B, -S, and -h) will take precedence over the default mechanism values.4

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 “TDGSS Security Mechanisms” on page 118.

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.

Line Number Description



Example 2: Mapped Directory User

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,dc=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

Explanation of Example 2

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.

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.87LdapGroupBaseFQDN: 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


Logon by user <djl> from IP <141.206.35.88> is not allowed


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.88Enter 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

$



Diagnosing Logon Failure Due to Incorrect Realm Information

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 Credentialsadditional 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 145.

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

tdsbind Error Output

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.


Chapter 6: Using a Directory to Manage Database Userstdssearch

tdssearch

Tdssearch is a simplified version of a standard LDAP search tool. It allows an administrator or user to explore the directory assignments of a user to gain an understanding of user rights 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.

Running tdssearch

You can run tdssearch from the Teradata Database Command Prompt by entering the following tdssearch attributes in any order:

tdssearch –u user -w password -d domain [-s {base|one|subtree}] [–b basedn] [-h host] [–p port] [filter] [attr1 [attr2 …]]

Observe the following rules when you configure tdssearch attributes:

tdssearch Attribute Description

-u A directory user authentication identifier (authcid or user name)

This option must be specified in cases where a directory login is required.

Depending on directory security settings, this may prevent you from accessing the data you want.

-w The directory user password

This attribute must be specified in cases where the -u attribute is defined.

If a password is not submitted and -u has been included in the command, tdssearch interactively prompts the user and does a secure read of the submitted password.

-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. This option has no meaning if the directory server is not Active Directory.

By default, tdssearch uses the value configured for the LdapServerRealm property in the LDAP mechanism.

-b -b specifies the FQDN of 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. The defaults are:

• Windows: The defaultNamingContext for the domain

• MP-RAS: The default search base is configured in /etc/ldap.conf and/or the private .ldaprc file for the user.



-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 The DNS name of a system where the LDAP server runs

By default, tdssearch uses the value configured for the LdapServerName property in the LDAP mechanism. If nothing is configured, omitting this option produces unspecified result.

-p The port where the LDAP server listens.

The value can be a decimal number in the range from 1 to 65535.

By default, tdssearch uses the value configured for the LdapServerPort property in the LDAP mechanism.

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

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

tdssearch Attribute Description




Usage Notes for tdssearch

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 nor Active Directory support special attribute names. Other servers may allow the name “*” to mean “all user attributes” and “+” to mean “all operational attributes.”

When using tdssearch to examine an entire OpenLdap RootDSE object, you must use the following commands:

2 When a system name is specified in a tdssearch command, the system where the tdssearch 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.

For example: If directory server dirsvr1 resolves to dirsvr1.ncr.com on the directory server system, the dirsvr1 must also resolve to dirsvr1.ncr.com on the where the tdssearch is run.

Be sure to make the server names resolve in the same way or tdssearch will not run.

Finding User Information with tdssearch

The following is a typical situation in which tdssearch could be used to search an Active Directory server:

For directory server esroot running Active Directory, run tdssearch to find information about a configured directory user drct01, as follows:

Note: The tdssearch output is returned in standard LDIF format, in accordance with IETF RFC 2849. For further information on the LDIF format, go to:


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> tdssearch -b "" -s base defaultNamingContext -h k1

When run from this operating system Use this command

Windows tdssearch -h server -b ““ -s base *

MP-RAS tdssearch -h server -b ““ -s base \*




Search Output

The following information is returned:

dn: defaultNamingContext: DC=esrootdom,DC=esdev,DC=tdat

Explanation of defaultNamingContext Search


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> tdssearch -h esroot -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=tdatobjectClass: topobjectClass: personobjectClass: organizationalPersonobjectClass: usercn: John Doe

Search Criteria Description

tdssearch Input

-b ““ Specifying a search base (-b) of ““ and a scope (-s) of base obtains the ROOTDSE object.

-s base

-h k1 The name of the directory server

defaultNamingContext Specifying an attribute name limits the search. If you don’t specify any attribute names, the search will return values for all available attributes.

tdssearch Output

dn: 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.

defaultNamingContext: DC=esrootdom, DC=esdev, DC=tdat

The actual value contained in the schemaNamingContext attribute



sn: DoegivenName: JohndistinguishedName: CN=John Doe,CN=Users,DC=esrootdom,DC=esdev,DC=tdatinstanceType: 4whenCreated: 20040605220928.0ZwhenChanged: 20040728221734.0ZdisplayName: Directory User 1uSNCreated: 50268memberOf: CN=xu1,OU=groups,OU=testing,DC=esrootdom,DC=esdev,DC=tdatuSNChanged: 315083name: Directory User 1objectGUID: £?=å=çAÆ¦¶S++§userAccountControl: 512badPwdCount: 0codePage: 0countryCode: 0badPasswordTime: 127337313454062500lastLogoff: 0lastLogon: 127355266545781250pwdLastSet: 127309469682812500primaryGroupID: 513objectSid: ?accountExpires: 9223372036854775807logonCount: 140sAMAccountName: drct01sAMAccountType: 805306368userPrincipalName: [email protected]: CN=Person,CN=Schema,CN=Configuration,DC=esrootdom,DC=esdev,DC=tdatlastLogonTimestamp: 127355266545781250tdatProfileMemberOf: CN=profxu1,CN=profiles,CN=end2end,CN=tdat,OU=testing,DC=esrootdom,DC=esdev,DC=tdatC>

Explanation Search for User drct01



tdssearch Input

-h esroot Names the directory server being searched.

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



tdssearch Output

Password: Prompt for the directory password for the user named in the -u option.

dn: CN=John DoeCN=Users,DC=esrootdom,DC=esdev,DC=tdat

The distinguished name of the user "drct01". This object was returned as a result of the search filter, not the bind of user drct01.

objectClass: top These are common directory entries, shown for reference, that may or may not appear in your directory.

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

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.




uSNChanged: 315083 These are common directory entries, shown for reference, that may or may not appear in your directory.

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

sAMAccountType: 805306368

userPrincipalName: [email protected]

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




Determining the schemaNamingContext Value

When installing Teradata directory schema extensions on Active Directory, 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 from Teradata Database on Windows” on page 190.

Search Input

To find the schemaNamingContext, do the following search:

C> tdssearch -b ““ -s base -h 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:


tdssearch Input

-b ““ Specifying a search base (-b) of ““ and a scope (-s) of base obtains the ROOTDSE object.

-s base

-h K1 The name 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.

tdssearch Output

dn:schemaNamingContext Indicates that the output is the distinguished name of the schema naming context.

schemaNamingContext CN=Schema,CN=Configuration,DC=k1dns,DC=k1dns,DC=systemone, DC=com

The value that the schemaNamingContext attribute contains.



Other LDAP Tools

In addition to tdsbind and tdssearch, a number of other LDAP tools may be useful when configuring a directory for use with Teradata Database, or for general directory maintenance.

For Windows Systems

Use the LDIFDE tool supplied with Windows for directory maintenance on Windows systems.

For MP-RAS Systems

A number of tools are included for your convenience when you install TDGSS. Unlike 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]

The following table lists the available LDAP tools and describes how they can be used:

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:

usr/tdgss/pkgs/06E.00.00.00/doc/man1/[toolname]

The help files cover only basic tool usage. For additional information on OpenLdap directory tools, go to the OpenLdap web site at:

www.openldap.org

LDAP Tool Description

ldapadd Adds objects to the directory.

ldapcompare Compares two pieces of data in the directory and returns a true/false assessment of their equivalency.

ldapdelete Removes data from the directory.

ldapmodify Modifies objects in the directory.

ldapmodrdn Renames objects in the directory.

ldappasswd Changes directory passwords.

Note: This tool does not work with currently supported LDAP-compliant directories, but is supplied for future use.

ldapsearch Finds objects in the directory.

ldapwhoami Binds to the directory and discovers a user directory identity.


Chapter 6: Using a Directory to Manage Database UsersOptimization of Directory Searches

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 by adding optional properties to the LDAP mechanism and configuring them for optimal directory searching.

Optional LDAP properties are available to perform the following functions:

Property Function

Optional LDAP properties for use in narrowing the directory search base

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

LdapUserBaseFQDN 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

LdapClientReferrals The LdapClientReferrals property instructs LDAP to enable or disable referral chasing.

• When enabled, this property allows referral chasing for directories that require it.

• When disabled, this property eliminates unnecessary referral chasing where referrals are not beneficial to the search process.

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



For instructions on the use of these properties how to edit them, see the sections beginning with “LdapGroupBaseFQDN” on page 148.

For instructions on how to add these optional properties to the LDAP mechanism, see “Making TDGSS Configuration Changes on Teradata Database Servers” on page 157.

LdapClientDebug The LdapClientDebug property instructs LDAP how to help the TSC to debug any problems that may exist between LDAP and the directory.

LdapClientRebindAuth When the LdapClientReferrals property is set to chase referrals, a new connection is established between LDAP and the directory server and the search is continued on that connection. The LdapClientRebindAuth property tells LDAP how to deal with (bind with) authentication on the new connections.

Property Function




APPENDIX A Teradata Database PhysicalSecurity

Controlling Machine Room Access

Introduction

Physical system security involves controlling access to the physical components of the computer system. For example, physical system security protects:

• The system and its component against deliberate damage

• The Administration Workstation (AWS) or system console from unauthorized access

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 NCR systems; information on them can be obtained in books and 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 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 any media that contains sensitive data in a controlled area such as the computer room.


Appendix A: Teradata Database Physical SecurityControlling Access to Outside Devices

8 Remove all sensitive data from all media before removing it from the controlled area or releasing it to unsecured personnel.

Enforcing Security Policy

To effectively enforce the security policy, operators must be knowledgeable about the current security policy.

Controlling Access to Outside Devices

Access control to devices outside the computer room is generally less stringent than for devices located inside the computer room. However, some exceptions apply.

The security policy is mainly concerned with controlling access to the data because it is intellectual capital and the corporate resource. Therefore, removing remote devices from the computer room can pose a problem.

The caretakers or custodians of the remote devices must always be aware of security and report any unauthorized uses of the equipment they suspect. Such caretakers or custodians should invoke the related audit procedures to help detect and prevent attempted security violations.

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 NCR server platform. Restrict users without special privileges from accessing the LAN through the operating system to prevent inadvertent corruption of Teradata Database data files.


APPENDIX B Running a Secure TeradataDatabase

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.

NCR 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, NCR 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

Introduction

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

2 Establish the physical security controls for the system.

3 Establish operating system and network security controls for the Teradata Database server.


Appendix B: Running a Secure Teradata DatabaseSecuring a System to the Common Criteria Evaluated Configuration

4 Install the system hardware and software following NCR-supplied installation documentation. Be sure to use the documentation that corresponds to the applicable hardware, software, and operating system versions.

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 = 270WHERE PrimeIndex = 1;

For detailed information on the password controls in the DBC.SysSecDefaults table, including their default values, see “Password Control Options” on page 46.

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 of this manual 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:


Appendix B: Running a Secure Teradata DatabaseSecuring a System to the Common Criteria Evaluated Configuration

CREATE USER SECADMIN AS PASSWORD = xxx, PERMANENT = 40E6 BYTES, /* 40M */ SPOOL = 25E6 BYTES, /* 25M */ ACCOUNT = 'SecAdmin', FALLBACK;

Please note that Chapter 3 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.


Appendix B: Running a Secure Teradata DatabaseAvoid Potential Security Hazards

Avoid 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 access rights 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.


APPENDIX C Preparing for DirectoryIntegration--System Evaluation Tasks

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.

This Appendix describes how to conduct the following system evaluation tasks:

• 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 tdssearch and tdsbind tools. For further information on these tools, see “tdsbind” on page 207 and “tdssearch” on page 215.

Check 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 C1 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 C1: Server Configuration in Client Machine’s Host File192.168.1.50 xyzcop1192.168.1.51 xyzcop2192.168.1.52 xyzcop3192.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 LDAPmethod. If you plan to use both the


Appendix C: Preparing for Directory Integration--System Evaluation TasksTest the Directory Server

KRB5 and LDAP methods, NCR 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.

Test the Directory Server

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

The RootDSE Object

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.



Finding the RootDSE on Active Directory

Example C2 demonstrates the use of tdssearch to fetch and display the contents of the RootDSE object from an Active 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 tdssearch tool, see “tdssearch” on page 215.

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 C2: Using tdssearch to Find the RootDSE in Active Directory$ tdssearch -h esroot -b "" -s basedn:currentTime: 20040820001616.0ZsubschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=esrootdom,DC=esdev,DC=tdatdsServiceName: CN=NTDS Settings,CN=ESROOT,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=esrootdom,DC=esdev, DC=tdatnamingContexts: DC=esrootdom,DC=esdev,DC=tdatnamingContexts: CN=Configuration,DC=esrootdom,DC=esdev,DC=tdatnamingContexts: CN=Schema,CN=Configuration,DC=esrootdom,DC=esdev,DC=tdatnamingContexts: DC=DomainDnsZones,DC=esrootdom,DC=esdev,DC=tdatnamingContexts: DC=ForestDnsZones,DC=esrootdom,DC=esdev,DC=tdatdefaultNamingContext: DC=esrootdom,DC=esdev,DC=tdatschemaNamingContext: CN=Schema,CN=Configuration,DC=esrootdom,DC=esdev,DC=tdatconfigurationNamingContext: CN=Configuration,DC=esrootdom,DC=esdev,DC=tdatrootDomainNamingContext: DC=esrootdom,DC=esdev,DC=tdatsupportedControl: 1.2.840.113556.1.4.319...snipped...supportedLDAPVersion: 3...snipped...supportedSASLMechanisms: DIGEST-MD5dnsHostName: esroot.esrootdom.esdev.tdat



ldapServiceName: esrootdom.esdev.tdat:[email protected]: 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 C3 demonstrates the use of tdssearch 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 C3: Using tdssearch to Find the RootDSE in Sun Java Directory Server$ tdssearch -h djltnt -b "" -s basedn:objectClass: topnamingContexts: dc=elsegundoca,dc=ncr,dc=comnamingContexts: o=NetscapeRootsupportedExtension: 2.16.840.1.113730.3.5.7...snipped...supportedControl: 2.16.840.1.113730.3.4.2...snipped...supportedSASLMechanisms: DIGEST-MD5...snipped...supportedLDAPVersion: 3vendorName: Sun Microsystems, Inc.vendorVersion: Sun-ONE-Directory/5.2dataversion: 020040814221707020040814221707netscapemdsuffix: cn=ldap://dc=djltnt,dc=elsegundoca,dc=ncr,dc=com:389$

Authenticate 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 tdssearch. Provided that there are no DNS issues to resolve, this should be a fairly straightforward process.


Appendix C: Preparing for Directory Integration--System Evaluation TasksCommon Errors with Active Directory

Authenticate an Active Directory User

Example C4 demonstrates the command to cause the Administrator user on a Windows network to be authenticated with Active Directory. 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: Use tdssearch to Authenticate an Active Directory User$ tdssearch -h esroot -b "" -s base -u administrator namingContextsEnter LDAP password:dn:namingContexts: DC=esrootdom,DC=esdev,DC=tdatnamingContexts: CN=Configuration,DC=esrootdom,DC=esdev,DC=tdatnamingContexts: CN=Schema,CN=Configuration,DC=esrootdom,DC=esdev,DC=tdatnamingContexts: DC=DomainDnsZones,DC=esrootdom,DC=esdev,DC=tdatnamingContexts: DC=ForestDnsZones,DC=esrootdom,DC=esdev,DC=tdat$

Authenticate a Sun Java Directory Server User

Example C5 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: Use tdssearch to Authenticate a Sun Java Directory Server User

$ tdssearch -h djltnt -b "" -s base -u diperm01@testing naming-ContextsEnter LDAP password:dn:namingContexts: dc=elsegundoca,dc=ncr,dc=comnamingContexts: o=NetscapeRoot$

Common Errors with Active Directory

This subsection lists the more common errors a customer may encounter when using tdssearch or other directory utilities to verify information in Active Directory.


Appendix C: Preparing for Directory Integration--System Evaluation TasksCommon Errors with Active Directory

DNS Naming Issue

Example C6 demonstrates the error that occurs when an Active Directory 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 C6: Error -- Mismatched Digest-uri and LDAP SPN$ tdssearch -u administrator -h esroot -b "" -s baseEnter LDAP password:Can’t tds_bind: tds_bind: Directory error - Invalid credentialsadditional info: 80090303: LdapErr: DSID-0C0903FB, comment:The digest-uri does not match any LDAP SPN’s registered for thisserver., data 0, vece$

Server Down: As Seen from Windows

Example C7 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 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.


Appendix C: Preparing for Directory Integration--System Evaluation TasksCommon Errors with Sun Java Directory Server

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 C7: Error -- Server Down as Seen from Windows$ tdssearch -u administrator -h esroot -b "" -s baseEnter LDAP password:Can’t tds_bind: tds_bind: Directory error - Server Down$

Server Down: As Seen from MP-RAS

Example C8 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 C8: Error -- Server Down Seen from MP-RAS$ tdssearch -u administrator -h esroot -b "" -s baseEnter LDAP password:Can’t tds_bind: tds_bind: Directory error - Can’t contact LDAP server$

Invalid User, Password, or Realm

Example C9 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 C9: Error -- Invalid User, Password, or Realm$ tdssearch -u administrator -h esroot -b "" -s baseEnter LDAP password:Can’t tds_bind: tds_bind: Directory error - Invalid credentialsadditional info: 8009030C: LdapErr: DSID-0C090419, comment:AcceptSecurityContext error, data 0, vece$

Common Errors with Sun Java Directory Server

This subsection lists the more common errors a customer may encounter when using tdssearch 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 238 and “Server Down: As Seen from MP-RAS” on page 239.



Bad Canonicalization

Example C10 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 C10: Detecting Bad Canonicalization$ tdssearch -u diperm01@testing -h djltnt -b "" -s baseEnter LDAP password:Can’t tds_bind: tds_bind: Directory error - Invalid credentialsadditional info: SASL(-1): generic failure: unable canonify userand get auxprops$

Example C11 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=ncr,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 web at:

http://docs.sun.com/db/doc/816-6698-10

Example C11: dn: cn=test mapping,cn=DIGEST-MD5,cn=identity mapping,cn=configobjectClass: topobjectClass: nsContainerobjectClass: dsIdentityMappingobjectClass: dsPatternMatchingcn: test mappingdsMatching-pattern: ${Principal}dsMappedDN: uid=$1,ou=people,ou=$2,dc=elsegundoca,dc=ncr,dc=comdsMatching-regexp: ([ˆ:]*)@(.*)



Bad User

Example C12 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.

Example C12: Bad User Error$ tdssearch -u diperm01@testing -h djltnt -b "" -s baseEnter LDAP password:Can’t tds_bind: tds_bind: Directory error - Invalid credentialsadditional info: SASL(-13): user not found: no secret in database$

Bad Password

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’s 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 C13 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.

Example C13: Bad Password Error$ tdssearch -u diperm01@testing -h djltnt -b "" -s baseEnter LDAP password:Can’t tds_bind: tds_bind: Directory error - Invalid credentialsadditional info: SASL(-13): authentication failure: clientresponse doesn’t match what we generated$




APPENDIX D Implementing Control of UserAccess by IP Address

This Appendix covers the 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 Chapter 6.

Elements of IP Access Restriction

IP restrictions are enforced by the Teradata Gateway based on information contained in a globally distributed object (GDO). The information in the GDO originates in one of two sources:

• You can define IP restrictions in the database by creating an XML document file that describes them and then importing the file into the GDO using the ipxml2bin utility.

• You can define IP restrictions in a supported directory by loading Teradata Database schema extensions into the directory and then populating it with restriction-related schema objects. You must then import the restrictions from the directory schema into the GDO using the ipdir2bin utility.

Each of these two sources requires that the administrator perform a unique series of set- up operations.

When the set-up 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.

Usage Constraints

Restricting user access by IP address is subject to the following constraints:

• The database limits the size of GDOs to 128 KB. For most systems only a small number of users will need to be locked to a particular IP address, so the database GDO size limit should be sufficient. However, if you need to restrict large numbers of user/IP combinations, you should use the directory-based implementation of this feature.

• The presence of an intermediary application between the IP address from which the user is logging on and the database prevents the effective use of IP restrictions. When such intermediary 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, so it is the only IP that can be restricted.


Appendix D: Implementing Control of User Access by IP AddressOverview of the Implementation Process

• 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 re-connect of the pre-existing session because of a system restart.

Ensuring Security

The list of names and valid IP addresses in the XML file and the GDO could possibly aid outsiders in breaking into a Teradata Database system. If such actions could represent a threat to your system, be sure to limit privileges on this data to access only by trusted administrators.

Overview of the Implementation Process

Implementation of IP restrictions differs depending on whether or not you set-up the restrictions in a directory. The following sections outline the differences.

Setting up IP Access Restrictions for Users Defined in Teradata Database

You must perform the following steps to setup IP restrictions for users defined in the database.

1 Familiarize yourself with the design criteria for creating IP restrictions, as presented in the following sections.

2 Design IP filters as required to enforce user restrictions at your site.

3 Create the XML IP restriction document to apply the filter restrictions to users.

4 Use the ipxml2bin utility to import the XML document contents into the GDO.

Setting up IP Restrictions for Directory-based Users

You must perform the following steps to setup IP restrictions for users defined in a directory.

1 Familiarize yourself with the design criteria for creating IP restrictions, as presented in the following sections.

2 Make sure any directory user you want to restrict is already mapped to a database user.

3 Load the Teradata Database schema extensions required for IP restrictions into the directory.

4 Create IP restriction-related objects in the directory and set their attributes.

5 Map the IP filters that define IP restrictions to the database users that link to the directory users you want to restrict.

6 Use the ipdir2bin utility to import the directory-based IP restrictions into the GDO.


Appendix D: Implementing Control of User Access by IP AddressCreating and Applying IP Restrictions for Database Users

Creating and Applying IP Restrictions for Database Users

This section covers the following topics:

• Description of available IP filters and how they function

• Instructions on how to create filters for specific purposes

• Instructions on how to create the master XML IP restriction document that applies the restrictions to users

IP Filters

IP Filters define the IP restrictions the Gateway will apply to users when they log on to the database. Users and filters are linked in the XML IP restriction document.

Filters are of two types: “permissive” and “restrictive.” The type of filter determines the order in which the Gateway processes the IP allow and deny tags contained in the filter.

Filter Tags

The characteristics of an IP filter are determined by the filter attributes, or tags. All data in the XML document that defines database IP restrictions must be attached to a tag.

The following section describes the filter tags that appear in an XML IP restriction document.

For information on applying tags in a directory-based implementation of IP restrictions, see “Directory Implementation of IP Restrictions” on page 257.

tdat

Use the tdat tag to specify that the XML IP restriction document applies to Teradata Database systems and users.

The tdat tag defines a name attribute. The value is always tdat.

system

Use the system tag to identify the Teradata Database system to which you want to restrict access. A system tag must always appear as a child of the tdat tag.

The system tag defines a name attribute. The value assigned to the name attribute should correspond to the cn of the Teradata Database system.

The XML IP restriction document may contain multiple system tags, but the Gateway will use only the first system tag that appears in the document.


Appendix D: Implementing Control of User Access by IP AddressIP Filters

users

The users tag defines the beginning and end of the list of users that are affected by the filters defined in the document. The users tag must appear as a child of a system tag. The XML document may contain as many users tags as needed, but only one appearance is typical.

user

The user tag describes a Teradata Database user that has been defined in the database using a CREATE USER statement. The user tag bears a name attribute and a tag attribute.

• The value assigned to the name attribute is the name of the Teradata Database user affected by the IP restriction.

• 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/tags can reference.

ipfilters

The ipfilters tag indicates the beginning and end of a list of individual IP filters contained in the XML IP restriction document.

Use this tag only as a child of a system tag. You can use as many ipfilters tags as needed in the XML document, however, only one list of filters is typical.

ipfilter

The ipfilter tag corresponds to an individual IP filter. The tag defines two attributes, a name and a 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.

The ipfilter tag can appear only as a child of an ipfilters tag. Use as many ipfilter tags as necessary to define the active IP filters in the XML IP restriction document.

allow

The allow tag contains two attributes, ip and mask. If the IP address of the incoming session, when anded with the mask, matches the IP address in the tag anded with the mask, the Gateway will allow the IP address of the incoming session to access the database.

The allow tag can appear only as a child of an ipfilter tag. You can use as many allow tags as needed in an IP restriction document. When multiple tags appear, only one match is necessary to allow the session to proceed.

deny

The deny tag contains two attributes, ip and mask. If the IP address of the incoming session, when anded with the mask, matches the IP address in the tag anded with the mask, the IP address of the incoming session is denied access.



The deny tag can appear only as a child of an ipfilter tag. You can use as many deny tags as needed in the XML IP restriction document. When multiple tags appear, only one match is needed to deny the incoming IP address.

appliesto

The appliesto tag contains a single attribute, tagref. This tag binds an ipfilter to a user.

Filter Masks

In addition to specifying IP addresses in allow and deny tags, you must also specify a template or “mask,” which the filter will use when comparing the incoming IP address against allowed or denied IP addresses.

Masks are binary in construction. You must create a mask for each allow and deny tag to inform the filter to what extent it must test the incoming IP address against IP restrictions in the allow and deny tags.

Note: The following examples are for a typical restrictive filter. Masking principles for a permissive filter are similar, but the filter would test allow and deny tags in the opposite order.

Example 1: Allow Tag Masking

• Suppose the allow tag in a filter allows the following IP:

141.206.35.0

This indicates that the filter will allow any IP address in the 141.206.35 subnet, which may represent a department within a large company.

• A user attempts to access the database from the following incoming IP address:

141.206.35.175

• The filter allow tag includes the following mask, which it uses to test the incoming IP:

255.255.255.0

Since the allow tag has a 0 for the fourth level, only the first three levels are meaningful for testing. The binary mask example shown above specifies that the filter will test only the first three levels of any incoming IP address against the allow tag.

In allow testing for Example 1, the filter would give database access to the incoming IP. However, testing is not complete because the filter also contains a deny tag.

Example 2: Deny Tag Masking

• Suppose the deny tag in the filter denies the following IP:

141.206.35.175

The department in Example 1 above might construct a single-address deny tag to restrict the IP of a training computer that is not allowed to direct access the database.

• The best mask to use to ensure that the filter enforces the deny restriction is the following:

255.255.255.255



You must use this mask format because the IP address requiring denial is only unique at the fourth level. The deny test for the incoming IP address, using this mask, will deny access even though the allow tag has allowed it.

Related Topics

For information on using tags and masks to create filters, see “Permissive Filters” on page 248 and “Restrictive Filters” on page 251.

For information on placing filters in an XML IP restriction document, see “Creating an XML IP Restriction Document” on page 253.

Permissive Filters

When the filter type is “permissive,” the Gateway processes the deny tags first. Then it processes the allow tags. The filter is called permissive because it requires that you explicitly list any IPs you want to exclude. As a result, the Gateway denies all IP addresses listed in the deny tags unless they also appear in an allow tag, 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 tag) for a list of users, while retaining the ability to use an allow tag to enable some of the denied IPs for some users.

Note: A permissive filter without a deny tag will permit logons from all IPs regardless of what IPs are explicitly allowed by the allow tag.

The Gateway processes each permissive filter deny tag as follows:

1 The filter masks the incoming IP address under test with the mask from the deny tag.

2 The filter masks the IP address specified in the deny tag 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 tag as follows:

1 The filter masks the incoming IP address under test with the mask from the allow tag.


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.



To help understand how the deny- and allow-testing work with a permissive filter setup, see Example 1, “Example 1Permissive Filter” on page 249.

Example 1Permissive Filter<ipfilter name="filter2" type="permissive">

<deny ip="141.206.35.0" mask="255.255.255.0"/><allow ip="141.206.35.175" mask="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 Description

ipfilter name="filter2" The filter name

This term identifies the specific filter being used.

type="permissive" The filter type

This term identifies whether the filter is permissive or restrictive and indicates the type of IP testing (deny or allow) that it will perform first.

deny ip="141.206.35.0" The deny tag appears first in a permissive filter.

The value of this tag indicates that the filter will deny access to the database to any IP addresses within the 141.206.35 subnet unless they explicitly appear in the allow tag. The filter allows access to all IPs not defined in the deny tag.

Usage Note: Use the deny tag in a permissive filter to specify a higher level in the network tree than that used for the allow tag.

mask="255.255.255.0" This mask determines the extent to which the filter will test an incoming IP address against restrictions defined in the deny tag.

allow ip="141.206.35.175" The allow tag

The value of this tag 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 tag. The filter will deny access to any other IP addresses that appear in the deny tag.

Usage Note: Use the allow tag in a permissive filter to specify a lower level in the network tree than that used for the deny tag, to allow exceptions to the IPs explicitly denied. You can use multiple allow tags, if necessary, to define the exceptions.

mask="255.255.255.255" This mask determines the extent to which the filter will test an incoming IP address against restrictions defined in the allow tag.



appliesto tagref="samoht" 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 tag of the XML IP restriction document.

appliesto tagref="noside" Identifies a second user affected by this set of filter rules

Term Description



Restrictive Filters

When the filter type is “restrictive,” the Gateway processes the allow tags first. Allowed IPs are permitted by a restrictive filter unless they are overridden by the deny tags. The deny tags are processed last. The filter is called restrictive because it must explicitly name the permitted IPs.

Use restrictive filters to define which IPs are allowed for a list of users, while retaining the ability to use the deny tag to disable some of the allowed IPs for some users.

Note: A restrictive filter without an allow tag will deny logons from all IPs regardless of what IPs are explicitly denied by the deny tag.

The Gateway processes each restrictive filter allow tag as follows:

1 The filter masks the incoming IP address under test with the mask from the allow tag.

2 The filter masks the IP address specified in the allow tag with the same mask.

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


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.

Example 2 helps clarify how the deny and allow testing work with a specific filter setup.

Example2: Restrictive Filtering<ipfilter name="filter1" type="restrictive">

<allow ip="141.206.0.0" mask="255.255.0.0"/><deny ip="141.206.35.0" mask="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 Description

ipfilter name="filter1" The filter name

This term specifies a single IP filter in an IP restriction document.

type="restrictive" The filter type

This term identifies whether the filter is a restrictive or permissive type, and indicates the type of deny/allow testing that is required.



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.

When Multiple Filters Exist

When multiple filters exist for a single user the system considers all restrictive filters simultaneously, as if they were a single large filter. If the Gateway denies the user access to the database, processing of the logon stops. If the Gateway allows the user access to the database, the system continues processing by considering all permissive filters at once. Because of the complexity of this feature, Teradata recommends that a single user have only a single filter. If multiple filters are required, they should be all of the same type (i.e permissive or restrictive).

<allow ip="141.206.0.0" The allow tag appears first in a restrictive filter.

The value of this tag indicates that the filter allows database access t to any IP addresses within the 141.206 subnet unless they explicitly appear in the deny tag that follows. The filter denies all others are denied access.

Usage Note: Use the allow tag in a restrictive filter to specify a higher level in the network tree than that used for the deny tag.

mask="255.255.0.0"/ This mask determines the extent to which the filter will test an incoming IP address against restrictions defined in the allow tag.

<deny ip="141.206.35.0" The deny tag appears second in a restrictive filter.

The value of this tag 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 tag. Any other IP addresses will be denied access if they appear in a subsequent deny tag.

Usage Note: Use the deny tag in a restrictive filter to specify a lower level in the network tree than that used for the allow tag, to define exceptions to the IPs explicitly allowed in the allow tag.

You can use multiple deny tags, if necessary.

mask="255.255.255.0"/ This mask determines the extent to which the filter will test an incoming IP address against restrictions defined in the deny tag.

<appliesto tagref="xyzzy"/> 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 tag of the XML IP restriction document.

<appliesto tagref="shazam"/> Identifies a second user affected by this set of filter rules

Term Description


Appendix D: Implementing Control of User Access by IP AddressCreating an XML IP Restriction Document

Creating an XML IP Restriction Document

To implement the IP access restrictions defined in IP filters you must create an XML document that contains the filters and links them to users. 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.

Note: Implementing IP restrictions for directory users requires that you create restriction-related schema objects in the directory. These objects and attributes are similar to the tags and tag attributes that comprise the XML IP restriction document, as described in the following sections.

For more information about directory-based IP restrictions, see “Directory Implementation of IP Restrictions” on page 257.

Save the Completed XML IP Restriction Document

When you complete you XML IP restriction document, be sure to save it as ipfilter.xml so it can be found and converted to GDO format by the ipxml2bin utility.

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

Example3: XML Document Linking a Filters to Individual Users<?xml version="1.0" encoding="UTF-8"?><name cn="tdat">

<system name cn="gizmo"> <users> <user name="drct01" tag="xyzzy"/> <user name="perm01" tag="noside"/> <user name="extuser" tag="shazam"/> </users> <ipfilter name cn="filter1" type="restrictive"> <allow ip="141.206.0.0" mask="255.255.0.0"/> <deny ip="141.206.35.0" mask="255.255.255.0"/> <appliesto tagref="xyzzy"/> <appliesto tagref="shazam"/> </ipfilter> <ipfilter name="filter2" type="permissive"> <deny ip="141.206.35.0" mask="255.255.255.0"/> <allow ip="141.206.35.175" mask="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 Description

<?xml version="1.0" The version of XML used to generate the document

encoding="UTF-8"?> The character set used in the XML document

<name cn=tdat> The system name

<system name="gizmo"> The system to which the IP restrictions apply

<users>

<user name="drct01" tag="xyzzy"/>

<user name="perm01" tag="noside"/>

<user name="extuser" tag="shazam"/>

</users>

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.

<ipfilters> This section of the XML IP restriction document lists the ipfilters that define the restrictions.

<ipfilter name cn="filter1" type="restrictive"> The common name of the first filter specified in the document is “filter1.” It is a restrictive filter.

<allow ip="141.206.0.0" The IP range allowed by filter 1.

The value of this tag 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 tag.

Because the filter is restrictive, it automatically denies access to all IPs outside those specified in the allow tag.

mask="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 tag.



mask="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"/>

The restriction described in filter1 applies to users “drct01” and “perm01” because it specifies their respective tag attributes, “xxzzy” and “shazam.”

<ipfilter name="filter2" type="permissive"> The name of the second filter specified in the restriction document is “filter2.”

It is a permissive filter.

<deny ip="141.206.35.0" The IP denied by filter 2

The value of this tag 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 tag.

Because the filter is permissive, it allows access to all other IPs outside those specified the deny tags.

mask="255.255.255.0"/> 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 filter 2

The value of this tag 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 tag.

mask="255.255.255.255"/> 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"/>

The restrictions described in filter2 apply to the database users “noside” and “xxzzy.”

</ipfilter></ipfilters></system></tdat>

These terms close out the various sections of the XML IP restriction document.

Term Description



Applying a Filter to All Users

Sometimes IP filter allow or deny rules may apply to all users. To eliminate the need to specify the user individually for these cases, Teradata Database allows the XML IP restriction to specify “everybody” in an appliesto tagref. To apply a filter to all users, assign a value to a tag attribute in the users XML tag and specify the same value in a tagref attribute of an applies to tag embedded in an ipfilter.

When such an all users filter exists, the system uses it first when testing an individual user.

Example 4 describes how IP filters appear when applied to all Teradata Database users.

Example4: XML Document Linking a Filter to All Users<?xml version="1.0" encoding="UTF-8"?><name="tdat"> <system name="gizmo"> <users tag="everybody"> <user name="drct01"> <user name="perm01"> <user name="extuser"> </users> <ipfilters> <ipfilter name cn=”filter1” Filter type="permissive"> <deny ip="141.206.35.0" mask="255.255.255.0"/> <allow ip="141.206.35.175" mask="255.255.255.255"/> <appliesto tagref="everybody"/> </ipfilter> </ipfilters> </system></tdat>

The following table provides an explanation of the terms used in differently in Example 4, as compared to Example 3, 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 table for Example 3.

Term Description

<users tag="everybody"> Specifies all users, as defined the list of user names that follows

Instead of the simple <users> tag that appears in Example 3, employing <users tag=”everybody”> allows for an “all users” application of the filter.

<user name="drct01">

<user name="perm01">

<user name="extuser">

This is a list of all users that are subject to the restrictions.

Since the appliesto tag will specify “everybody,” use of a tagref with the individual users is not necessary.

</users> This tag closes out the list of users. It does not require the tag="everybody" nomenclature present in the opening users tag.

<appliesto tagref="everybody"/> By using “everybody,” this tag applies the filter conditions to all users without the need to list them individually.


Appendix D: Implementing Control of User Access by IP AddressDirectory 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 schema objects

• setting the IP-related object attributes

Loading Directory Schema Extensions for IP Restriction of Directory Users

If you want 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 only work for directory users that are already mapped to Teradata Database users or to EXTUSER. You should first set up your supported, LDAP-compliant directory for basic authentication and authorization 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 6 Using a Directory to Manage 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 189.

Creating IP Restriction Schema Objects in the Directory

Once you install the Teradata Database IP-related schema extensions in your directory, you must create IP-related schema objects and assign values to their attributes. Some of the objects used by the directory to restrict IP access are duplicates of objects already used for directory user authentication and authorization. Other objects and attributes are unique to IP access restriction.

For information on creating schema objects in the directory, see “Creating Containers and Inserting Objects” on page 200.

The following sections describe the tags that form the basis for IP-related schema objects.


Appendix D: Implementing Control of User Access by IP AddressCreating IP Restriction Schema Objects in the Directory

Tags and Objects

The Teradata Database schema extensions require that IP-related schema objects contain only tags and tag attributes. There is no character data present outside of a tag. Schema object tags are similar to the tags used in an XML IP restriction document for users defined in the database. For example, the system tag in an XML IP restriction document corresponds to the tdatSystem directory object.

tdat

Use the tdat tag to identify the root of the directory tree. This tag binds the schema definitions to the Teradata Root Node. This tag must be the first tag in the document.

The tdat tag defines a name attribute. The value assigned to this attribute should match the common name (cn) of the tdatRootNode object in the directory.

system

The system tag corresponds to the tdatSystem object in the directory. The tag defines a name attribute. The value assigned to the name attribute should correspond to the common name assigned to the tdatSystem object that represents the system to which the IP restrictions apply.

The system object must appear only as a child of the tdat object.

users

The users tag corresponds to the tdatContainer object in the directory bearing the common name users. A tdatContainer object can appear only as a child of a system object. As many tdatContainer objects as needed can appear in the directory, however, only one appearance for the purpose of directory user IP restrictions is typical.

user

The user tag describes a Teradata Database user and is analogous to the tdatUser object in the directory. The user tag bears a name and a tag. The value assigned to the name attribute is the name of the Teradata Database user the restrictions are meant to effect. The value assigned to the tag attribute is a string that is unique to the entire directory. The tag attribute provides a “handle” to a unique user that other objects can reference.

A user object must appear only as a child of a tdatContainer object with a cn=users.

ipfilters

The ipfilters tag corresponds to a tdatContainer directory object where the common name is “ipfilters.” This tag appears only as a child of a system object. As many ipfilters tags as needed can appear in the XML document, however, only one appearance is typical.

ipfilter

The ipfilter tag corresponds to a tdatIPFilter directory object. The tag defines two attributes, a name and a type. The name is an arbitrary name that has no intrinsic meaning except as a placeholder to differentiate among filters. The type attribute can contain either of two values, “restrictive” or “permissive.”


Appendix D: Implementing Control of User Access by IP AddressMapping IP Filters to Database Users

The ipfilter object can appear only as a child of an ipfilters tag. As many ipfilter tags as necessary can appear in the IP restriction document.

allow

The allow tag is actually an attribute contains two attributes, “ip” and “mask.” If the IP address of the incoming session, when anded with the mask, matches the IP address in the tag anded with the mask, the IP address of the incoming session is allowed access.

The allow tag can appear only as a child of an ipfilter tag. As many allow tags as needed can appear in an IP restriction document. When multiple tags appear, only one match is necessary to allow the session to proceed.

deny

The deny tag contains two attributes, “ip” and “mask.” If the IP address of the incoming session, when anded with the mask, matches the IP address in the tag anded with the mask, the IP address of the incoming session is denied access.

The deny tag can appear only as a child of an ipfilter tag. As many deny tags as needed may appear in the XML IP restriction document. When multiple tags appear, only one match is needed to deny the incoming IP address.

appliesto

The appliesto tag contains a single attribute, tagref. The tagref is a unique identifier you must apply to each user listed in the user tag. Use the appliesto tag to bind an ipfilter to a user, by way of the assigned user tag attribute value.

For information on defining the user tag value, see “user” on page 246.

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 un-mapped directory users.

For information on mapping IP filters to database users, see “Mapping IPFilters to Database Users” on page 204.


Appendix D: Implementing Control of User Access by IP AddressData 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 always run the needed utility whenever you create or 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 <file> [-G] [<xmlfile>]ipxml2bin -G [-f <file>] [<xmlfile>]

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:

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.

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.



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.xmlParse successful784 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.

-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 or is illegal, the utility uses the default value of 389, the IANA assigned port for the LDAP protocol.



Errors

Because the ipdir2bin utility access 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.

The application-specific errors that may also occur are similar to those listed for the ipxml2bin utility on page 249.

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 drct01Enter LDAP password:Parse successful608 bytes written to the ipfilter GDO.

$

-S Identifies the FQDN of the Teradata Database system as defined in the directory

If the value is not present the utility uses the value of the LdapSystemFQDN 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.

Option Description




Glossary

AES Advanced Encryption Standard

AMP Access Module Processor

AP Application Processor

ASE Account String Expansion

AWS Administration Workstation

BTEQ Basic Teradata Query

BYNET Banyan Network (high-speed interconnect)

CLIv2 Call Level Interface version 2

CBC Cipher-block Chaining

CFB Ciphertext Feedback

CN Common Name

DBC Database Computer

DD Data Dictionary

DDL Data Definition Language

DES Data Encryption Standard

DH Diffie-Hellman

DIT Directory Information Tree

EA External Authentication

ECB Electronic Code Book

FQDN Fully-qualified Distinguished Name

GSS-API Generic Security Services Application Programmer Interface

GUI Graphical User Interface

GUID Globally Unique Identifier

IETF Internet Engineering Task Force

JCE Java Cryptography Extensions

JIS Japanese Industrial Standard


Glossary

KRB5 Kerberos (security mechanism)

LAN Local Area Network

LDAP Lightweight Directory Access Protocol

MD5 Message Digest Algorithm

MVS Multiple Virtual Storage

NCSC National Computer Security Center

NTLM Microsoft Windows NT Lan Manager or the Teradata Database NTLM security mechanism that supports it

OFB Output Feedback

PC Personal Computer

PE Parsing Engine

PKCS Public Key Cryptography Standard

PUT Parallel Upgrade Tool

QOP Quality of Protection

SASL Simple Authentication and Security Layer

SHA-1 Secure Hashed Standard

SSPI Secure Sockets Programmer Interface

SQL Structured Query Language

SSL Secure Sockets Layer

SSO Single Sign On

TCB Trusted Computing Base

TCP/IP Transmission Control Protocol/Internet Protocol

TD 1 Teradata Type 1 (security mechanism)

TD 2 Teradata Type 2 (security mechanism)

TDGSS Teradata Database Generic Security Services

TDI Trusted Database Interpretation

TDP Teradata Director Program

TDPID Teradata Director Program Identification

UDF User-Defined Function

WAN Wide Area Network


Index

AAccess control

access to dump files 63access to operating system 63logon 9monitoring access rights 78password 12physical 1, 227types of 2using hostid 35using IP address, see Access restriction by IP address

Access logging 78BEGIN LOGGING statement 78changing logging options with MODIFY USER 83database level 81DBC.AccessLog view 76DBC.AccessLogRule table entries 80DBC.AccLogTbl entries 80DBC.DeleteAccessLog view 76DBC.LogOnOff view 76END LOGGING statement 78errors 83monitoring in DBC tables 82of directory users 78, 179of users forced off system 77overview 78privileges required 79purging entries 82system default 79table level 81using DDL statements 78using views 76viewing log entries 82

Access restriction by IP address 173, 243see also IP access restrictionsdata conversion utilities for set up of 260effect on pre-existing session 244for directory users 244for Teradata Database users 244implementation 244IP filters 245summary 36usage constraints 243

Access rights 66automatically granted with CREATE statement 67checking, using system views 76

control of using GRANT and REVOKE 69DBC.AllRights view 76DBC.AllRoleRights view 76DBC.UserRights view 76explicit 68implicit (automatic) rights 66, 67

mapped directory users 175un-mapped directory users 175

ownership rights 66types of 66

Account stringdetailed security auditing using ASE 84use of in logons 14

Active Directoryautomatically generated attributes 182determining schema naming context in 222directory objects unique to 183installing Teradata schema on 190special objects 187supported Teradata Database server operating systems 170using tdssearch 217

Administrative usersADMIN space 61CREATE USER ADMIN statement 61

Advanced Encryption Standard. See AES algorithmAES algorithm 100

example 115AlgorithmName

attribute 114class, legal values 100

Algorithmsattributes 114configurations, preset 115

AlgorithmTypeattribute 114class 105

allow tag 246database implementation 246directory implementation 259

AnonymousAuthentication propertydescription, editing guidelines 140legal values 108

Appended domain name 12for access logging of directory user logons 78

appliesto tagdatabase implementation 247directory implementation 259


Index

Attributes, Teradata schema objects 182Audit trails

access logs 75accessing audit logs 3analysis 3, 75hazard detection 2invoking 75logon/logoff activity 2, 75suspending 75

Authenticationby directory, no schema changes 171by directory, with schema changes and mapping 172external 37Teradata 17

AuthenticationSupported propertydescription, editing guidelines 128legal values 106

AuthorizationSupported propertydescription, editing guidelines 129legal values 106use with configured directory 173, 175use with unconfigured directory 172, 175

Automatic privileges, see Automatic rights 67Automatic rights

associated with types of CREATE statement 68resulting from various GRANT statements 69

BBEGIN LOGGING statement 79

check types available 80DDL 78used with GRANT 82

Blowfish algorithm 100example 115

CCBC encryption mode (Cypher-block Chaining) 102CD-ROM, user documentation vCFB encryption mode (Cyphertext Feedback) 102Child, definition 65Cipher-block Chaining, see CBC encryption modeCiphertext Feedback, see CFB encryption modeClauses, FROM ownerdb 64cn attribute 182Command line logons 16Confidentiality

data encryption 87definition 85

Confidentiality (Algorithm type) 105ConfidentialityDesired property

description, editing guidelines 138legal values 108

Containerscreating, inserting objects 201

CRASHDUMPScontrolling access 63

CREATE ROLE statement 64, 72, 74CREATE statements, automatic rights associated with each

type 68CREATE USER

for allocating space to an administative user 60for establishing usernames and passwords 10

Creatordefinition 65privileges 68

CredentialUsage propertydescription, editing guidelines 143legal values 109

Custom interface 104

DData 10Data access control, see Access controlData access requests, auditing with BEGIN and END

LOGGING 80Data Dictionary

tables for viewing access log entries 82use in security administration 75

Data encryptionduring logon 10requirements for use 87

Data integrity 87Database

definition 64security 64transfer ownership 65

DBCspace 60user DBC 60user DBC locked out 50

DBC.AccLogRule macro 83DBC.AccLogRules view 76DBC.AMPUsage, for storing user/account string statistics 84DBC.DBase system table

database names 10usernames 10

DBC.Users view 10DBSControl utility, set up for external authentication 38DDL statements

BEGIN LOGGING 78END LOGGING 78

DefaultMechanism propertydescription, editing guidelines 133legal values 107

defaultNamingContext, obtaining 217


Index

DelegateCredentials propertydescription, editing guidelines 134legal values 108

Delegated credentials, requirements when using external authentication 39

deny tagdatabase implementation 246directory implementation 259

description attribute 182DesiredContextTime property


DesiredCredentialTime propertydescription, editing guidelines 142legal values 109

DHKeyG propertydescription, editing guidelines 155legal values 113supporting mechanisms 155

DHKeyP propertydescription, editing guidelines 155editing guidelines 156legal values 113

Diffie-Hellman algorithm 100example 115

DIPACC DBCSQL script 79Directories

configuring for authentication of database users 180schema extensions 180supported by Teradata Database 170

Directory 175Directory Information Tree (DIT) 195

adding Teradata Database objects 199populating 199Teradata Database objects in 195tools for adding objects

ldapmodify 199verify mapping 205

Directory integration 169preliminary system check 188, 233

Directory management tools 223LDAP tools 223Teradata Database tools

tdsbind 207tdssearch 215

Windows toolsLDIFDE 223

Directory management tools, location of files and documentation 93

Directory searches, optimize using referral chasing 224Directory sign-on 20, 37Directory user management

authentication only, no mapping 171full implementation with schema changes 172

Directory usersaccess logging of 179mapped to database users 175mapping to database profiles 204mapping to database roles 203mapping to database users 203mapping, testing of 205ownership of database objects 176profiles 178roles and profiles 177

Domain nameappended 12, 78in logon string 11

Domain user name, use in logon 11

EECB encryption mode (Electronic Code Book) 102Editing mechanism properties, see Mechanism properties,

editing property valuesElectronic Code Book, see ECB encryption modeEncryption

algorithm types 105data 87from a replication system 33key length 101mode types 102network traffic 87padding types 103password 86

Encryption, logonsdescription 86enabling with Gateway Control Utility 86

END LOGGING statement 79DDL 78usage 80, 82

Errorsencountered with incorrect directory logons or mapping

206incorrect dropping of EXTERNAL ROLE 177mechanism unavailable at logon 89UPN logons 25when checking mapping using tdsbind 211, 214

Expired password, resetting 49External authentication 37

from channel-attached clients 40from network-attached clients 37LDAP logon (directory sign-on) 37logon variations 16set-up options 38set-up requirements 38sign-on as 37single sign-on 18supporting mechanisms 39, 40


Index

with delegated credentials 39with user credentials 37without user credentials (single sign-on) 37

External roleschanging directory assignments 178creating and dropping 177directory administration 177effects of dropping 178maximum number per user 177role hierarchy and role switching 178

EXTUSERdatabase privileges 175logon 21, 26set up for 172

FFAT, compatibility with TeraGSS 91File maintenance tools

tdgsspkgrm 96tdgssversion 97

FROM ownerdb clause 64

GGateway Control utility

for encryption of logons 86for set-up of external authentication 38

General information about Teradata viGive ownership, using the GIVE statemnent 65GRANT LOGON statement, rules for use 34GRANT statement

examples using 70forms of 69requirements for use 69

GRANT/REVOKE LOGON statements, precedence of clauses 35

GSS interface 104

HHostid

associated with usernames 34in logon string 13

single sign-on 19Teradata authentication 17

LAN connection 34use for access control 35see also GRANT LOGON or REVOKE LOGON statement

Hosts, multiple, logon permission 34

IImplicit rights 66Inserting objects into containers 201Integrity

algorithm type 105definition 85

IntegrityDesired propertydescription, editing guidelines 139legal values 108

Interface types, encryption 104IP access restrictions

see also Access restriction by IP addressdescription of 36directory implementation 257

creating IP restriction objects in the directory 257loading IP schema extensions 257

filter tags for directory implementation 258allow 259appliesto 259deny 259ipfilter 258ipfilters 258system 258tdat 258user 258users 258

IP filters 245application to a user in an xml document 253application to all users 256filter tags for database implementation 245

allow 246appliesto 247deny 246ipfilter 246ipfilters 246system 245tdat 245user 246users 246

masks 247permissive 248processing when multiple filters exist 252restrictive 251

IP restriction document (xml) 253ipdir2bin utility 262ipfilter tag

database implementation 246directory implementation 258

ipfilters tagdatabase implementation 246directory implementation 258

ipxml2bin utility 260


Index

JJar update command 94, 161Java Cryptography Extensions

mode requirements 102padding requirements 103

Java, setting the classpath 94

KKerberos 120

for external authentication 40Key Exchange (algorithm type) 105Key Length 101KeyLength attribute 114Keywords

DATABASE 64USER 64

LLDAP 122

authcid logon 21authcid logon, alternate form 23logon formats 20optional properties

use of to control referral chasing 224use of to narrow search base 224

UPN logon 26ldapadd 199LdapBaseFQDN property


LdapClientDebug propertydescription, editing guidelines 152legal values 112

LdapClientDeref propertydescription, editing guidelines 151legal values 112use in controlling referral chasing 224

LdapClientRebindAuth propertydescription, editing guidelines 153legal values 113use in referral chasing 225

LdapClientReferrals propertydescription, editing guidelines 150effect on logon requirements 11legal values 112use in controlling referral chasing 224

LdapGroupBaseFQDN propertydescription, editing guidelines 148legal values 111use in optimizing directory searches 224

ldapmodify 199

LdapServerName propertydescription, editing guidelines 144legal values 109

LdapServerPort propertydescription, editing guidelines 144legal values 110

LdapServerRealm propertydescription, editing guidelines 145legal values 110

LdapSystemFQDN propertydescription, editing guidelines 147legal values 110

LdapUserBaseFQDN propertydescription, editing guidelines 149legal values 112use in optimizing directory searches 224

LDIF 199LDIFDE 199Legal values in TDGSS configuration files 99

AlgorithmName 100Algorithms 114AlgorithmType 105File Header 99InterfaceType 104KeyLength 101MechanismProperties 106Mode (encryption) 102Padding type 103

Library Configuration file 98LibraryName attribute 114Lightweight Directory Access Protocol, see LDAP 170Logging, see Access loggingLogoff

DBC.LogOnOff view 76view logoff activity 76

Logonaccount string 14activity 76command line 16controls shown in views, DBC.LogonRules 76database user name 10DBC.LogOnOff view 76DBC.SysSecDefaults shows MaxLogonAttempts 50deprecated 86directory user name 11domain name 11domain user name 11elements 9enabling data encryption 10encrypted 86examples

GUI 30kerberos/NTLM 28LDAP authcid 21


Index

LDAP authcid (alternate form) 23LDAP UPN 26Single Sign-on 18Teradata Database authentication 17

formats 16from channel-attached systems 32from Teradata Database node 32GUI 30how to release lock on failed logon 51LDAP logon 20MODIFY USER statement, using 51parameters 16password requirements 12replication systems 32requirements 9security mechanism selection 10setting maximum attempts 51sign-on as 28single sign-on 18size limit 9Teradata authentication 17through Teradata Query Director 31to Teradata Dynamic Workload Manager 63unmapped directory user 37UPN 24users GRANTed access, record 76using UTF-16 characters 15view logon activity 76why unsuccessful 76WITH NULL PASSWORD 13without user credentials (SSO) 18

Logon controls 34by IP address 36GRANT/REVOKE LOGON statements 34setting maximum number of attempts 50UPDATE statement, using 51

MMacros, DBC.AccLogRule 83Mapping directory users

to database users 203to external roles 203to profiles 204

Mapping IPFilters to database users 204Masks, masking 247MD5 algorithm 100

example 115Mechanism properties

adding optional properties 126editing values 124how used by system 124

Mechanism selection 88

MechanismEnabled propertydefault value 131description, editing guidelines 131legal values 107supporting mechanisms 131

MechanismProperties class, legal values 106MechanismRank property


Mechanismsbasic functional properties 106capabilities 88confidentiality properties 113default 89define the security context 88editing property values 157error message when unavailable 89handling of selection request 89interface types 104LDAP configuration properties 109operational properties 107preset property values

Kerberos 121LDAP 123NTLM 122Teradata 1 119Teradata Method 2 119

properties 106selection 88status properties 107that support external authentication 39types 118

Kerberos 120LDAP 122NTLM 122Teradata Method 1 (TD 1) 118Teradata Method 2 (TD 2) 119

unavailability of 88Message digest algorithm, see MD5 algorithmMode

attribute 114class 102

Moderate security, advantages 6MODIFY privilege, logged indirectly in audit 83MODIFY PROFILE statement 74MODIFY USER statement 42, 45, 51Monitoring system security, see Audit trailsMutualAuthentication property



Index

NNetwork controls, security 63, 228Network logons

command line 16GUI 30

Network security 63, 85, 228NTFS compatibility with TeraGSS 91NTLM 122

OObjects

creating 67ownership of 65

OFB encryption mode (Output Feedback) 102Operating system

restrictions 63, 228security controls 63, 228special privileges 63, 228

OutOfSequenceDetection propertydescription, editing guidelines 137legal values 108

Output Feedback, see OFB encryption modeOwner, definition 65Ownership

GRANT and REVOKE privileges 66objects 65parent and child 65rights implicitly provided to an owner 66rights, forms of 66User DBC 60

Ownership rightsSELECT privilege 66

PPadding

attribute 114types 103

Passwordcontrol 47expiration 49history 53levels of encryption 86lockout 51release lock 51resetting expired 49reuse 52temporary 42, 45using profiles to control 73

Password controlsExpirePassword 49LockedUserExpire (Password lockout time) 53PasswordDigits 55

PasswordMaxChar 54PasswordReuse 52PasswordSpecChar 55using profiles 74using UPDATE to reset 48

Password formaterror messages 57Japanese and non-Japanese systems, differences 44password values 48requirements 43valid contents 43

Password history, in DBC.OldPasswords table 53Password lockout time 53Performance group, optional inclusion of in an account

string 14Permissive filters 248Physical access control 1, 227PKCS 1 and PKCS 5 encryption padding 103Prefix attribute 114Privileges

access types 66EXECUTE 36granted to creator 67see Access rights

Profiles 73defined 73for directory users 178MODIFY PROFILE statement 74use in managing password security 74use in managing system resources 73

Property valuesediting 157

Public Key Cryptography Standard, see PKCS1 and PKCS 5 encryption padding

Publications, ordering information v

QQuality of protection (QOP) 116

attributes 116legal values 113

Queries, monitor-related 77Query Director

allowable mechanisms 88required mechanism property settings 31

RReferral chasing 224Release password lock 51Remote devices, security 228ReplayDetection property



Index

Replication systemsallowable mechanisms 88encryption 33logon from 32

Restrictive filters 251REVOKE LOGON statement, rules for use 34Revoking privileges 70

from PUBLIC and ALL DBC 71use of the REVOKE statement 70

Rightsautomatic 67ownership 65, 66see also Access rights

Roles 72CREATE ROLE statement 64, 72, 74DBC.RoleMember view 76DROP ROLE statement 64, 72members of 76rights granted to 76use in managing security 72

SSchema extensions 180

installationon Active Directory, from MP-RAS or Linux 192on Active Directory, from Windows 190on Sun Java System Directory Server 193

Schema naming context, determining 222Schema objects

attribute usage requirements 184classes 180creating containers 200required for Active Directory

tdatGroupExt 187tdatIPFilterExt 187tdatUserExt 187

special objects and attributes for Active Directory 187types 181

Scripts, DIPACC DBCSQL 79Secure Hashed Standard, see SHA-1 algorithmSecure Sockets Layer, see SSL3 encryption paddingSecurity

computer room 227determining appropriate level 6hazards 75LAN server 63, 228network controls 63, 228operating system 63, 228remedial actions, types of 3remote devices 228SYSTEMFE 63, 228Teradata Database files 63, 228

Security administrator 61assigning privileges to 61duties 4privileges 4role of 3tasks 6

Security handbook 88Security hazards

crash (restart) 63detecting 2eliminating common hazards 232

Security levelsadvantages and disadvantages 7C2 level 229operating a system at Common Criteria level 229

Security mechanisms, see MechanismsSecurity policy

enforcing 228establishing 227reevaluating 8site-specific 8

Security, network 85SELECT privilege 66Session

duration 9establishing 2

SET ROLE, for directory users 178SET SESSION DATABASE, use to set default database 176Setting password encryption level 86SHA-1 algorithm

description (also SHA-256 and SHA-512) 100SHA1 algorithm

example 115Sign-on as 28, 37Single sign-on 37

example 18SingleSignOnSupported property


Space allocation 64SSL3 encryption padding 103SSPI interface 104Stored procedures, revoking 70Sun Java System Directory Server

supported Teradata Database server operating systems 170System administrator, setting up 60System identifier, see tdpid 13system tag


System views, see ViewsSYSTEMFE, security 63, 228


Index

Ttagref, in IP filter appliesto tag 259tdat tag


tdatAllowDeny attribute 182tdatAllowedIP attribute 183tdatContainer

object 181, 200objects and naming conventions 200similarity to IP filter users tag 258

tdatDeniedIP attribute 183tdatGroupExt object 187tdatIPFilter object 181tdatIPFilterExt object 187tdatIPFilterMember attribute

description 183in Active Directory applications 187

tdatIPFilterMemberOf attributedescription 183in Active Directory applications 187

tdatProfile object 181tdatProfileMember attribute


tdatProfileMemberOf attributedescription 183in Active Directory applications 187

tdatRole object 181tdatRoleMember attribute


tdatRoleMemberOf attributedescription 183in Active Directory applications 187

tdatRootNodeobject 181similarity to tdat IP filter tag 258

tdatSystem 199object 181similarity to IP filter system tag 258

tdatUserobject 181similarity to IP filter user tag 258

tdatUserExt object 187tdatUserMember

attribute 182in Active Directory applications 187

tdatUserMemberOfattribute 183in Active Directory applications 187

TDGSSapplication programmer interface 93C++ and Java application sharing of configuration files 94changinng the configuration

on clients 161on Teradata Database server 157

classes, list 99client package, seeTeraGSSconfiguration files, reading and editing 98description 91file location 92file maintenance tools 96files contained in 93installation 91jar update command (on clients) 161legal values 99Library Configuration file 93, 98Quality of Protection (QOP) 116reversion after configuration change 165schema for use in directory integration 93security mechanisms 118User Configuration file 93, 98, 124

tdgssconfig, file location 93tdgsspkgrm 96tdgssversion 97Tdpid, in logon string 13tdsbind 207

error output 214file location 93output, analysis of 210procedure for use 207use in testing

IP access restrictions 212mapped directory user 212unmapped directory user 210

tdssearch 215file location 93finding user information 217procedure for use 215usage notes 217

Teradata Database, other related publications vTeradata Dynamic Workload Manager, controlling access to

63Teradata Method 1 (TD 1) 118Teradata Method 2 (TD 2) 119Teradata Query Director

logons through 17, 31use with IP access restrictions 243

Teradata schema objects, attributes 182Teradata standard interface 104TeraGSS 91

change versions 97determine current version 96for channel-attached clients 91


Index

for network-attached clients 91remove a version 96User Configuration file for 124view available versions 97

UUPN logons

description and variations 24errors 25kerberos/NTLM 28LDAP 26

Useraccess needs, identifying 5creating 10groups, identifying 5

User Configuration file 98, 124editing 124reading 124

User groups, common 5User Identifier 10user tag


UsersDBC 60DBC.UserRoleRights view 76DBC.Users view 76directory 171

mapped to database users 175explicit rights, list of 76information about 76security administrator 61security audit accounting 84system administrator, set up 60

users tagdatabase implementation 246directory implementation 258

using UPDATE to set 48UTF-16 characters in logon string 15

VVerifyDHKey property


ViewsDBC.Users 10for checking access rights and access logging 76queries for accessing 77

WWITH GRANT OPTION, security warning for use of 232WITH NULL PASSWORD option, logon 13

Date post:	11-Feb-2017
Category:	Documents
Upload:	databaseguys
View:	147 times
Download:	4 times