audit logins for a particular user

[abrsvc]

If there is concern about a user modifying their own login procedure, than I would add a line in the system wide procedure for that specific user. The F$USER lexical will return the UIC. Usse that to filter the logging for your specific user in the common login file.

Dan

[Craig A]

Dan

Depending on how Change is managed in an environment will determine whether to go for a user-specific solution (i.e. username of UIC) or a more generic solution.

Personally, it is as much hassle to do the generica solution as it is to do the specific, so that would always be my route.

Craig

[abrsvc]

Craig,

Agreed, all is dependent upon the environment. Another possibility that I have used is to change the LGICMD field in the uaf to point to a "logging" procedure that chains to the standard common login procedure. This makes changing logging easy. All that is needed is to change the UAF entry to point to the logging procedure. I have used this technique in the past as well. The bottom line is that you need to determine the security level needed as well as what flexibility you need to accomplish your goal.

Dan

[Joseph Huber_1]

>TMcB:
>At present we audit all logfailures and breakins.

Since the workarounds in sylogin or /flag=defcli are all rather clumpsy,
could You explain why enabling audit for LOGIN (dialup,local,remote,network only) is not an option for Your system?

[Jan van den Ende]

Craih,

>>>
That MIGHT work but also bear in mind that a user will typically have full access to their LOGIN.COM so could easily circumvent anything you place in it for auditing purposes.
<<<

THAT is why the second user is completely distinct from the "tranfer" user!

The tranfer user has its own GROUP UIC, and the directory with SET HOST 0 /LOG in LOGIN.COM is as tight as can be!

TMcB:
Success!

Proost.

Have one on me.

jpe

[TMcB]

Hi
I didnt want to enable all logins as we have thousands of users and i thought I had read previous warnings that it would be too much to log ALL logins for every user.

If this is not the case, I could just turn on auditing for all successfull logins.

Thanks

[Craig A]

Jan

I've never been a fan of this sort of auditing as it is so easy to circumvent.

Craig

[Hein van den Heuvel]

>> thanks -
i think using the users login.com file will be the easiest route. Will look into this

Hmmm,

I guess a simple ACCOUNTING report does not give teh righ access port information?

If you need a specific log then I would NOT put it in the normal use LOGIN.COM.
Either put this(*) in SYLOGIN, in a IF "xxx".EQS.F$GETJPI("","USERNAME")

or...

How about modifying the user lgicmd in authorize and point it to a special loginLOG.com which does this(*) logging and then chains to the real login.com

Hein

(*) this =

$ OPEN/APPEN log system_directory:world_writable.log
$ WRITE log write sys$output F$CVTIME(""), " ",f$getjpi("","USERNAME"), " ",f$getdvi("SYS$COMMAND","TT_ACCPORNAM")
$ CLOSE log

Better still would be process creating a permanent mailbox with a system logical name. Loop reading the mailbox writing to the log which now no longer needs world write access.

[Joseph Huber_1]

>>warnings that it would be too much to log ALL

It of course depends (disk-space , do all the thousends user login/logout very frequently ?).
I think if the LOGIN audit is restricted to
/LOGIN=(DIALUP,LOCAL,REMOTE)
then all interactive logins are catched (maybe NETWORK for SSH logins ?).
The vast amount could be detached,batch,subprocess,server, and those would make grow the audit file, not the interactive ones, they occur on a "human" time scale.

[Joseph Huber_1]

Apropos audit file disk space usage:
How about rotating (set audit/server=new_log),
then after evaluation archive the old file into a ZIP archive:
audit log files compress with an avarage ratio of ~90%, so the increase for login auditing is easily compensated.