Archives of the TeradataForum

Message Posted: Mon, 23 Dec 2002 @ 13:42:54 GMT

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

Pete,

Sorry, but I don't have the practical experience that you asked for in the network environment, but here's the theory.

A Teradata Userid can be constrained such that it is only allow to logon from specific hostid's. In the above example you may have batch work running from one of the IBM m/f's, so a batch userid may only be allowed to logon from one IBM m/f. These rules are known as LogonRules and are controlled through the Grant Logon/Revoke Logon statements. Additionally, it is these statements which allow you to define that a particular userid is associated with the NULL PASSWORD option, which means that Teradata is not expecting a password (and I don't think will validate one even if one is supplied). In this case Teradata expects the client platform to have done all required logon validation.

In the network environment, this validation is done using the CliLogonExit that you mention. Remember though that because the network environment has no single, central TDP (such as there is on a m/f) this exit has to be installed on every client system where you need this validation to take place, ASSUMING that we're talking about Teradata/Unix. IF you have Teradata running under Windows then you could use Single Sign-On.

So, to achieve what you want I think you'd define your Solaris system as a specific hostid with no other PC's or unix boxes on the same hostid. This needs some work in (pde?)config but your ncr field engineers should be able to set that up for you. You may need to give them a different range of i/p addresses than the ones accessed by any PC's etc.

The 'solaris hostid' defined above would then be the subject of a GRANT LOGON statement which says that 'by default' no userid's can logon from this hostid.

Then issue grant logon statements so that only the necessary data loading userid's can logon from the solaris hostid and possibly that these userid's can't logon from any other hostid. These data loading user id's would be defined to allow NULL PASSWORD from that specific hostid.

Finally, you need to implement the CliLogonExit on the solaris system itself, so that the logon is validated there. If this exit returns a rc=0, the loon will be attempted, if rc<>0 the logon will not be attempted.

Make sense?

Cheers,

Dave

Ward Analytics Ltd: Information in motion (www.ward-analytics.com)

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