Same user, different accounts, same uic?

[Rich Hearn]

Hi,

I haven't found anything pertaining to this, so I thought I'd ask: if I have the same user (X) and I want to create another account for her/him - ftpX, will I create any problems using the same uic for both accounts (101,101)? ie: modifying/deleting in future actions? I see it as an easy way to tie the 2 accounts together for human recognition.

I'm not aware of any problems, but best to confirm before wishing I had.

Tnx,
Rich

[Hoff]

It'll work, though the users with matching UICs are indistinguishable for access controls and for various security-related activities; all you'll have for ACLs and for various objects is the UIC value. Not the username.

Some auditors will justifiably get cranky with the lack of individual accountability per-user and with doubled-logins, and ftp is a particularly nasty protocol if the site has an interest in maintaining security.

Would you mind elaborating on the background and the goals here, in addition to the posted particulars of this solution? There may well be a different approach or different solution available.

[Rich Hearn]

Hoff,

1st of all, thanks for the quick response. No problem elaborating at all.

I have a number of users that use Refelection to Telnet to my VMS systems to their char cell app (Intersystems Caché). We're now starting to make a switch to a Web-based app.

Reflection has an FTP client that they use for xfr'ing files (reports) to their Xp boxes. Because of the nature of the setup for the web-based app, their regular user accounts are no longer accessible to them. I was trying to come up with a way to give them the access to use the same ftp client, but keep it simple so the user only has to add "ftp" to their normal username and it would "look normal" to them (same acc't/home dir/privs (netmbx, tmpmbx), etc). Basically, another way to get into the same account.

Thoughts welcome,
Rich

[Hoff]

Some details on what's happened with the "normal" logins to render then as ftp- or sftp-inaccessible? It may be feasible to continue to access those usernames specifically for ftp or sftp, for instance, either inboard within VMS, or outboard by redirecting the ftp or sftp connection or such.

That written, what you've got will work (in the absence of auditing), but you'll likely have fun with password skews and privilege skews and remembering to DISUSER both and other such, for instance. It's maintenance and accounting hassles more than anything.

[Richard W Hunt]

You seem to be in a commercial environment so that might work.

Be aware that if you have to go through any form of financial or government certification, "work" and "legal" are two different things for this question.

If you are ever going to be subject to standards based on FIPS-140-2, that might also be a problem.

However, OpenVMS doesn't really care if the same person and same UIC have two logins.

[Rich Hearn]

Hoff,

All the normal logins have been set to a common password the users are not allowed to know and accounts set to "noexpire" for the application to use - they do the authentication on the windows/web side.

Now, before anyone thinks I like this, let me state I was told this is how things will be.

It may just be easier, for me anyway, if I simply go with a different name for each user and not pursue this approach - that is an option.

Richard,
non-profit health environment - I was hoping to make the users life easier, but especially with HIPPA, I don't think I need to go there, even if VMS doesn't have a problem with it.

Thank you gentlemen for your time and thoughts,
Rich

[Hoff]

sftp would get you "around" this stuff and within your current constrains; set up a certificate login, either no-password or with a pass-phrase specific to the cert. (And there's no need to use a public CA nor to pay for the certificates. You can run your own CA and issue your own certs.) Disable ssh access, and maintain and control any write access granted to sftp with great caution.

I've managed to get VMS authenticating its passwords using Mac OS X Server boxes as authentication servers, so that's another potential approach here; Open Directory or Active Directory or other such. That's a single-password environment.

Between the double logins and the use of ftp here, I'm mildly surprised this configuration would pass a HIPPA review. And then I'd wonder what other issues lurk here. One port scan and a rogue wireshark session (or an IOS crack) and all your base are belong to us.

[Rich Hearn]

Hoff,

Intriguing as it sounds, I'll have to pass on it for now. I like the idea, just haven't got the time available to work out getting things set up right now. I *will* keep it in mind though for future reference.

Thank you very much for the thoughts - they're never wasted...
Rich

[John Gillings · Accepted solution]

Rich,

I'm not sure if the issue of shared UICs has been spelled out clearly. For most purposes, the UIC *IS* the user. So X and ftpX will be indistinguishable. If there is a reason (good or otherwise) that the password for X is withheld, then the same reason applies to ftpX.

Simple example, assuming X's LOGIN.COM (which may be different from ftpX's LOGIN.COM) is owned by X, then ftpX could create a new file and overwrite the old one. Next time X logs in, they execute the new code.

This is particularly relevant if X and ftpX have different sets of privileges. Although there may be no evidence of privilege in ftpX's UAF record, they can hijack any process running as X to exploit privileges. I believe this is a very bad thing. It's much better to have privilege or access visible that hidden.

I've seen auditors ectually recommend exactly this model to create pairs privileged and non-privileged users using the same UIC in order to satisfy some misguided "proportion of privileged users" rule. A clear example of working to the letter of the rule, disregarding the intent.

In your case it may make sense, especially if the accounts are non-privileged, but make sure you think through all the possible hi-jack scenarios.

[Rich Hearn]

John,

Thanks for the response.

If anything were left un-clear, it would be due to my lack of understanding it. Folks here are great!

I *do* appreciate your further clarification though... :^)

The reason for the user not knowing their pwd is because the application needs to be able to login to vms on their behalf and the application would be doing the authorization of them, so the app needs a non-expiring pwd on vms. In the name of progress, we're cripp'ling one of vms' strong points.

Since we we'ren't keeping the users out for actual security reasons I *had* been thinkn' that a different name, (ftpX) would have used a different pwd, even tho' the uic was the same. That way they could access their own files created in their name by the app. The actual account privs are only (netmbx & tmpmbx) - the acc't entry & lgicmd would be different - X is captive, ftpX would not be. This will end up being ~700 users - duplicating users, creating acl's, etc and giving *them* a different name just seems a "bit messy" overall. I was simply hoping for an easier way - all 'round.

NOT arguing *any* of the points provided here.

Tnx,
Rich