Archives of the TeradataForum

Message Posted: Mon, 08 Dec 2003 @ 09:01:33 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

Bill,

A number of things comes to mind, some obvious some not so obvious.

Obvious things:

-- change the "well-known" passwords of the standard userid's installed with a Teradata system (root, systemfe, DBC, Sysadmin, Crashdumps etc)

-- set up password controls (expiry, min/max length) by updating table dbc.syssecdefaults. Under v2r4 and earlier, the one row in this table applies to all userid's. With Teradata v2r5 and above the same options (all/most of them ?) can be applied at the user level.

(Perhaps) not so obvious:

-- check through the list of AccessRights that have been GRANTed to PUBLIC. Mostly these are select privilege against various system views and largely don't hurt, but if security is a particular concern then you may want to take a look at these,

-- restrict a username so that it can only logon from the specified hostid (e.g. which lan, which mainframe)

-- remember that Teradata largely operates a 'closed' security system, i.e. a username cannot performa a function unless they have been granted the security to do it. The one area this isn't quite true is with implicit access rights, however these only apply to objects below the username in the heirarchy and as most users in a Teradata environment don't own anything it often isn't a real problem.

-- if you're using a cli based application then you can get a logon exit nstalled on the client to allow the client userid to be checked against an external security agent. I'm not aware of anything that is available for ODBC clients.

-- if you've got Teradata running under Win2k then you can use Single Sign-On (SSO) which achieves the same thing as the previous point but the dbms end handles the security package interaction, hence the rules get applied to cli as well as odbc clients.

Cheers,

Dave

	<Prev	Next>		<<First	<Prev	Next>	Last>>