Solutions for sharing a single Domain account across multiple individuals

Factual Questions
1

I know the straight answer to this is “Just don’t do that”, but there are some constraints in place that mean maybe I have no choice.

So we’ve got a department (let’s call it ‘handling’) staffed by half a dozen different people - there is one computer that they all share (and that’s fine in terms of demand - only about 10% of their individual work is done on the computer - the rest is physical process).

So they all log into the PC using a single domain account called ‘handling’ - and that needs to remain the case because:

[ul]
[li]They all work on one mailbox called Handling@company.com (OK, we could overcome that with a shared mailbox and individual accounts, but…[/li][/ul]

[ul]
[li]They require access to a specific piece of the production system, that:[/li][ol]
[li]Takes a long time to open and process its initial work (so there are strong desires to open it once in the morning and keeping it open)[/li][li]Cannot be opened by multiple users concurrently (it is locked by the first person who opens it)[/li][li]Cannot even be run in a switched-user environment (the program won’t run in one user session at all if there is another locked session with any part of it running)[/li][li]Isn’t going to be replaced or significantly developed, yet, is critical to the operation of the business[/li][/ul]
[/ol]

I want a way for any of those multiple users to be able to log in, or unlock, the shared ‘handling’ domain account on their shared machine.

The current solution is that the password is taped to the monitor, that neatly solves the problem from the user’s perspective, but of course it means anyone who isn’t one of the correct users can also log in with ease.

Now, please spare me any lectures - I know it’s wrong. I already know how I would do this properly if I was designing everything from scratch. That opportunity is not forthcoming.
I also know the constraints above are a steaming pile of bullshit, but they are real, they are not going away, and I have to slap some kind of sticking-plaster solution in place.

What I think I need is some way of enrolling multiple smart cards or fingerprints against a single Windows domain account - and ideally in a way that provides its own additional layer of auditing.

Does such a thing exist?

2

I’m just guessing here, but how about using something like VMWare: multiple logins to the computer, but a shared login to a virtual machine that runs the process? I think you can set the virtual machine to not time out.

So you have individual logins to the machine, but one login to the virtual one. Once the connection is made, you’ll only be running the production system software once.

RDP might work if you need a physical machine.

Not perfect, but it gives an extra level of security even if the password is written down. Of course, you’d have to train people to log off once they’re done.

3

Virtualising the bit they have to share might actually do it - thanks for that suggestion.

Anything that requires great complexity to launch or shut down is probably a no-go - these are quite technophobic users in a company where technophobia is treated as a sort of badge of honour.

4

The problem stems from the fact that, simply put, six people can’t memorize one password? Do I have that right?

5

The “specific piece of the production system” uses the same credentials, including password, as a domain account?

6

Virtualize the process machine, use RDP to connect. You can set it up so each person “grabs” the virtual system from the other. (I believe that’s the default.)

I would still set up the mailbox as shared, that part is not constrained to single user.
Assuming it’s Exchange, so each user sees what others do to the shared mailbox…
If necessary, set up subfolders in the mailbox for each person - "Inbox\Suzy, inbox\Joe, etc. if you need to have a person “grab” an mail and identify it as theirs, take ownership. That way ownership is established, but the emails are available for others to inspect (or grab) if necessary.
If not, make it a distribution group and forward to all handling members.

7

Pretty much - it has some complexity requirements, but most critically, it must be changed every 180 days - which means it’s going to be changed by one of the users on their shift, and somehow communicated to the others who may not be present during the change.

If we were able to implement something like individual biometrics or smart cards, we would probably be able to waive the password change interval - the actual domain password could be recorded and locked away, and only the secondary login method routinely used.

To make things worse, the department I described is one of actually a couple of dozen different departments that are structured in the same sort of way with shared machines, a single logon, and heavy dependence on one person being able to complete what the previous one began.

8

No - the login to the production system uses a different set of credentials (still a domain account, but locked down so it only works for authenticating within the system) - the users who share the domain account to log into Windows also share the production system login, so it might as well be the same account, however.

9

Sounds like many of the industrial systems I’ve worked with. I don’t know the details as to how it is done but my current employer has the department login passwords never time out. It is the same as the area username. My previous department here had a weekend watch laptop that was taken home by the person on call. That PW is allowed to time out. Whoever has it changes the PW to that days date and put a sticker on saying what day the PW was changed. We currently have a central system for my dept that multiple users log in on. One OEM software can talk only to the current user. If it is left open when the user switches but doesn’t logout out, parts of it can not be changed by any one else. That thing is rebooted almost daily, which frees up the software. Our corporate overlords will not allow virtual machines to fix some similar issues.

10

I guess the big problem is: three people can keep a secret if two of them are dead.

My password is known only to me - if someone else gets hold of it and impersonates me, it’s probably traceable back to some act of negligence on my part - that is an incentive for me to be very careful.

If 5 people have the same password, it will probably be 6 tomorrow - and 7 the day after - and there’s no easy way to account for how those extra unauthorised individuals got hold of it. Lack of accountability breeds lack of responsibility.

For these reasons, I’m still thinking that I probably need something that is physically unique per authorised user - i.e. enrolment of their fingerprint, or issuing them with an RFID fob which would be their responsibility to safeguard.

11

Yeah, I would also recommend a virtual machine where each user opens their own RDP into the machine to interact with the program. It’s probably about as good as you’re going to get in terms of easy to set up and maintaining an audit trail.

12

Putting aside “best practice”, an alternative to writing the password on post-it notes is to use smart cards. As many as you need, all programmed with the same key. And configure your computer to lock (not logout) when the key is removed.

The “password reset” or “lost card” process requires re-programming ALL the cards, and you still aren’t individually identifying users. (Since a card can, typically, contain multiple keys, you can reprogram the cards in advance of a key change)

And since a card can typically contain multiple keys, you may be able to use your existing building ID cards, or use the cards for individual ID as well as group ID or …

13

So that’s going to require an RDS server if I need to roll it to a couple of dozen departments (all of whom are like the example I described)?

14

Have you looked into using Yubikey?

Don’t use biometrics. That fails when the user loses a finger or an eye or the finger gets scarred or burned or swollen or otherwise damaged

15

That sounds like it could be promising, but when I’ve been searching for these solutions, they all seem to be offered as the second factor in a two-factor solution (i.e. password + key) - can they be used instead of password entry, rather than on top of it?

16

Assume the app is running on a PC? What OS version?

All but “home” versions can run a single connection RDS. And you can restrict which users can connect to that session/PC. So you may be able to persuade the domain admins to set the actual software “PC” password to never expire with this restriction.

cheers
Steve

17

Regarding the 180-day requirement, couldn’t you just change the password yourself before the 180-day period expires? That would let you do so in an organized manner and to communicate the updated password to each member of the team, perhaps using a method other than a Post-It note.

As for the smart card method, that’s what we use. The computer is logged into using a service account, and users never know the password to it. Each person badges in using their own AD credentials.

18

The blurb on the website seems to indicate that, but you’d have to speak to them.

On second thoughts, I’ve thought of a way which won’t cost your bosses a penny. Give everyone their own account, for which they are responsible, and assign each account a Mandatory Profile in Windows. You may also be able to do this through Group Policy. From their own personal session they can then click on an icon (part of the Mandatory Profile) which opens a RDP session to a box running the Shipping account. The Shipping account is locked to that PC and remote access is appropriately restricted so it doesn’t matter if the password leaks.

19

Not the secure solution you’re looking for but can you standardize it to two passwords? If password1 doesn’t work, use password2. Because of only two passwords, no need to write anything down. After 180 days, change to password2, after a year, change back to password1.
We used this in a similar situation many years ago where we had only two computers but many users & many related signons to a single parent system, each resetting on a different 30 (or 60?)-day schedule.

20

I take it “Domain account” is your internal Windows-app environment (with which I am unfamiliar)? A paid-for external server domain host, eg Google, gives access to its third party apps geared to this no doubt, at various levels of complexity.

But I guess that’s immaterial to your on-the-ground physical access requirements in general…