Chasing down dormant user accounts

[Byrocat]

One of the fun tasks that is looking me in the face is generating a
list of potential stale accounts that access DB2. The systems are
running on OS authentication (login exists at the operating system
level).

The obvious place to look is the system log and get an aged listing of
logins.

The question I have is that while this is a great idea when the user
logs in to the server (telnet or a terminal session), but is this sort
of information present when the user comes directly against the
database using ODBC or similar processes?

Oh, and yes, not running auditing of successful logins.

[Pierre Saint-Jacques]

Re: Chasing down dormant user accounts

Look in your Admin Guide about the Governor.
You can configure a cfg. file for it that will collect ACCOUNT info which
will give you the ID, APPL., and TIMESTAMP of the connect/disconnect
activity.
Running it should not be a perf. impact that you'd notice (apart from memory
usage, but quite small).
Whatever process is used to access the db, the governor can pick it up.
HTH, Pierre.

--
Pierre Saint-Jacques
SES Consultants Inc.
514-737-4515
"Byrocat" <bdealhoy@sympa tico.ca> a écrit dans le message de
news:b47d3acf.0 503241213.24a1a d9d@posting.goo gle.com...[color=blue]
> One of the fun tasks that is looking me in the face is generating a
> list of potential stale accounts that access DB2. The systems are
> running on OS authentication (login exists at the operating system
> level).
>
> The obvious place to look is the system log and get an aged listing of
> logins.
>
> The question I have is that while this is a great idea when the user
> logs in to the server (telnet or a terminal session), but is this sort
> of information present when the user comes directly against the
> database using ODBC or similar processes?
>
> Oh, and yes, not running auditing of successful logins.[/color]