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

[Hoff]

>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.

It would appear the designers or programmers working on the app may have used an expedient approach, and that you're now stuck with that. (Auditors are taught to try to find this stuff, BTW. It's how they earn their pay. It's also how the hackers look to attack this stuff, and (given what I'm reading here, and) I'd assume expect there are other vulnerabilities here. Given that there's likely password storage here, that's likely vulnerable.)

If the application source code is generally available, it's often feasible to get this stuff to work "right" and to log in directly here, and to get rid of the password storage, and to use a single user. There are a couple of approaches, whether SSH or something riding atop that, or using OD or AD or such and Kerberos, or otherwise. I've certainly also run this stuff with what amounts to a side-channel connection to the server, and that tends to reduce exposing the application to the vagaries of the user quotas and the user login environment and to the occasional and nefarious user.

>NOT arguing *any* of the points provided here.

Well, I'd certainly be having a discussion with the programmer that designed and wrote this stuff. If (when?) the auditors ever find this stuff, that discussion will be held regardless. (Should the auditors not find a cleartext password store or suspect the existence of a reversible password store, then I'd question the completeness of the auditing. But this is what a post-mortem on a successful attack does tend to find regardless, and whether through investigation on the clients and the servers and the designs, or potentially finding the discussion here in the forums. And ignoring the auditors and the post-mortems, there are almost certainly also potential attackers reading internet forums.)

[John Gillings]

Rich,

> because the application needs to be able
>to login to vms on their behalf

If that's the case I'd be turning this around. Instead of username "RICH" for the application and "FTPRICH" for the user, I'd make it "RICH" for the user and "RICH_CAP"(tive) for the application (beware of the 12 character limit on usernames). Keep the simplest case for the real users. Let the application add the suffix to get at its username. I tend to use suffixes rather than prefixes so that related usernames sort together.

>This will end up being ~700 users -
>duplicating users

Trivial... Let the computer do the work, that's what it's for!

The users you want to have the application account get created with some specific identifier "_USER". You then have a procedure which scans the UAF, for any users with that identifier, check that the _CAP version of the username exists, and confirm that it's configured correctly. The procedure can also generate passwords for the application.
Conversly, any users without the identifier, check that they don't have the corresponding user, delete it if present. That way you can easily enable or disable application access by granting or revoking the identifier.
Run the procedure manually after creating a new user or modifying the UAF. Also run it daily as part of system housekeeping. Since it's automated and enforced, you keep your auditors happy.


>creating acl's, etc

No. The way identifiers work, is there is a UIC identifier matching the user. By definition all UAF entries with the same UIC share the same UIC identifier. Note that the identifier can be any arbitrary string, it doesn't need to match any of the UAF entries, but in your case I'd recommend it have the same name as your real user.

Granting of identifiers is to the IDENTIFIER, *NOT* the username. Although you manipulate identifiers through AUTHORIZE, they're completely independent of SYSUAF, all the information lives in RIGHTSLIST. Think of RIGHTSLIST as a giant matrix with UIC identifiers on the vertical axis, and non-UIC identifiers on the horizontal axis. GRANTing an identifier is ticking the box at the intersection.

So, if you have multiple usernames which share the same UIC, by definition, they share the same set of granted identifiers.

Usernames which don't have a corresponding UIC identifier cannot have identifiers granted.