How to Log DCL Access

[Clark Powell]

When I occationally allow my captive account users to access the DCL prompt, is it possible to have their sessions logged? We don't plan to use SET HOST/LOG but I was thing that there might be a way using the RUN LOGINOUT.EXE. Any suggestions?

thanks
Clark Powell

[Hoff]

It's not typical nor expected to allow a CAPTIVE user to reach DCL.

As for logging, you will have to use SET HOST /LOG or create or acquire your own or acquired session-logging tools. Google around for details on logging DCL commands; there's no in-built mechanism that does this, so you'll end up implementing your own, or seeing if something like the PEEK and SPY tools work for local auditing requirements.

Usual approach for these cases is a two-password login for contingencies, and a policy that requires both of those users (each with only one of the two passwords) to be present for the entire logged-in session.

And FWIW, on any recent OpenVMS version and by DCL's own explicit definition, a CAPTIVE users cannot access DCL. The process will automatically be deleted when the user gets to the $ prompt. This means you're either running an older VMS version, or your users are marked as RESTRICTED and not as CAPTIVE.

[RBrown_1]

Some sites capture the user input, log it, fire it off to a subprocess, log the subprocess output, and give the user another fake $ prompt. You can do all this with DCL.

It's no fun being the user of the fake $, but it must make someone happy.

[Graham Burley]

If you have a C compiler then SYS$EXAMPLES:ALPHA_LOGGER.C might do.

[John Gillings · Accepted solution]

Clark,

> allow my captive account users to access the DCL prompt

Is an oxymoron. Either they're captive, or they can access DCL.

Logging terminal sessions is fairly simple. We do it routinely for all logins to some of our systems. Have a CAPTIVE account with no password, called (say) "SAFE_LOGIN". its captive login procedure is basically:

$ SET HOST 0/LOG=
$ LOGOUT

Users logging in will see:

Username: SAFE_LOGIN
Username: real-username
Password: their password

To force certain users to login via this mechanism make their UAF entry RESTRICTED and GRANT them an identifier, say SAFE_LOGIN. SYLOGIN.COM checks for the identifier. Any interactive process holding the identifier is required to have SYS$REM_ID to be "SAFE_LOGIN" and SYS$REM_NODE to be the node itself. Generate a suitable warning message and audit if they fail the test and log them out.

In higher security environments and/or where the users are privileged, you may want to use a separate system for logging - that way you can physically isolate users from the log files. They then login to the first system which does SET HOST to the target system. For really serious isolation, have the users login through one network interface and put the target system on a second.

You need to work out how you want to handle batch, network and detached jobs.

[Clark Powell]

thanks all, you are correct, I mis-stated the problem the accounts have DisCtlY Restricted flags set. Another project was looking at eliminating SET HOST becuase it doesn't encrypt passwords. Not sure how that would be done if DECNET was still up but it would probably eliminate the possibility of SET HOST/LOG 0

I would encourage comments but I won't be here to read them for a week so please don't expect a quick reply.

thanks
Clark Powell

[John Gillings]

Clark,

It doesn't need to be DECnet. It could be telnet or ssh with logging enabled. I think DECnet makes it a bit easier to verify where the connection is from.

[John Gillings]

Clark,

I have a vaugue recollection that SET HOST 0 works regardless of DECnet being started(?) or maybe you don't need it fully configured?

> SET HOST becuase it doesn't encrypt passwords.

Probably true if it's across the wire, but I'm fairly sure SET HOST 0 traffic doesn't ever hit the "real" network. How are your users connecting though? If it's via telnet, then passwords are exposed regardless, on the first hop from client to host. If they're using SSH, then passwords are protected anyway (assuming SET HOST 0 traffic is internal).

[Jeremy Begg]

Clark,

Have a look at the JUMP utility written by Jonathan Ridler. You can download a copy here:

ftp://ftp.vsm.com.au/kits/jump.zip

I think it will do what you want without requiring the user to re-enter his or her password. The log file(s) can be written to a "secure" directory i.e. one to which the users don't have access.

Regards,
Jeremy Begg

[Craig A]

> It's no fun being the user of the fake $, > but it must make someone happy.

I remember starting a new contract and after a few days getting a call from an Apps Support person with a DCL query.

Being in the next block, I had a wander over to meet and chat and have a look at the problem.

IIRC it was a query with F$GETDVI and I did, as I have always done, the usual redfine SYS$OUTPUT to a file and then parse the values from HELP LEX F$GETDVI.

I'm not usually slow on the uptake (steady!) but it took me a good few minutes to work out why the file was not being created. Eventually, it dawned on me that they had a pseudo-VMS environment in a bit of rather clever DCL.

Horrid, but - as you say - I imagine it keeps someone happy.