audit logins for a particular user

[John Gillings]

T,

Here's a neat trick for generating customised audits for whatever you like. An example for your specific case, I'll call your user AUDIT_ME.

First create an empty, world readable file, with a name that indicates what you want to audit:

$ CREATE/PROTECTION=(W:R) SYS$MANAGER:LOGIN.AUDIT

Now add an ACL which specifies a READ+FAIL security audit ACE, and an ACE to pick out who you want to trigger it:

$ SET SECURITY/ACL=((AUDIT=SECURITY,ACCESS=READ+FAIL),(IDENTIFIER=AUDIT_ME,ACCESS=NONE)) SYS$MANAGER:LOGIN.AUDIT

Now, in SYLOGIN.COM trigger the audit:

$ PIPE TYPE SYS$MANAGER:LOGIN.AUDIT >NL: 2>NL:

(we're using PIPE here to redirect any output or errors to NL:, since it's single stage PIPE everything occurs in the context of the current process, so no real expense).

Since the file is W:R, this will be a NOOP for most users. For user AUDIT_ME, they'll trigger the AUDIT ACE, and generate an event in the audit journal. You can identify it by the object name LOGIN.AUDIT.

In practice, I'd use identifier LOGIN_AUDIT and then:

UAF> GRANT/IDENTIFIER LOGIN_AUDIT AUDIT_ME

this gives you a simple way to request the audit for other users.

The same mechanism can be used for anything you like. Use the PIPE TYPE command to generate a message.

If you have a code path that only your target user(s) will execute, it's even easier. Same empty file, but:

$ SET SECURITY/ACL=(AUDIT=SECURITY,ACCESS=READ+SUCCESS)SYS$MANAGER:LOGIN.AUDIT

and:

$ TYPE SYS$MANAGER:LOGIN.AUDIT

(since you won't generate an error message, and the file is empty, you don't need to redirect output).

For this to work, you need to have ACL audits enabled. From your SHOW AUDIT posting, you already have that.

[John Gillings]

A couple of other points...


Why not audit all LOGINs for all users? For that matter throw in LOGOUTs as well. At today's storage prices, for a few cents you'll have capacity for hundreds of years worth of login traffic. Remember, it's easy to throw away data that you've gathered, but you can't recover data that you didn't capture.

Enabling AUDIT in the UAF will also work, but you'll also audit entries for literally everything that user does! Probably not what you want, especially if your objective of not capturing all logins is to save space. The data volume for a single login and immediate logout for a UAF AUDIT flagged user would probably exceed all the login and logout traffic for all your users across a week!

[Hein van den Heuvel]

Expanding on John's idea...

Set a success audit on the users LOGIN.COM ?

- Yeah you can have false positives
- Do not tell user about Username: xxx/NOCOM
:-)

Hein

[Jan van den Ende]

Hein,

>>>

- Yeah you can have false positives
- Do not tell user about Username: xxx/NOCOM
<<<

... OR... like I said before, have this user be CAPTIVE!! Blocks /NOCOMM

Proost.

Have one on me.

jpe

[John Gillings]

Taking Hein's idea of applying the audit ACE to LOGIN.COM one step further... the problems are:

1) User's LOGIN.COM is owned by them, so could be modified, breaking the mechanism

2) They may execute LOGIN.COM other than at login time, giving false positives

Try this.

Create a command procedure:

SYS$COMMON:[SYSMGR]AUDIT_LOGIN.COM (W:RE)
$ @SYS$LOGIN:LOGIN

put audit ACLs on this procedure:

$ SET SECURITY/ACL=(AUDIT=SECURITY,ACCESS=EXECUTE+SUCCESS)

For any users you wish to audit, change their UAF entry:

UAF> MODIFY user/LGICMD=SYS$STARTUP:AUDIT_LOGIN

Invoking the system level procedure will trigger the audit, and then execute the default login procedure for the user.

There is a 3rd issue:

3) /NOCOMMAND or /COMMAND=other-file

As Jan suggested /FLAG=CAPTIVE will block that, but it's a bit harsh. Perhaps /FLAG=RESTRICTED?

(an example of the application of Hext's rule - a further level of indirection solves all problems)