For anyone to access a computer on our network, they need permission to resources. These can be shared network resources (like gigs and gigs of PowerPoint presentations) or personal resources (like a company-issued laptop). At the time of log in, the user's network ID is transmitted to a central database which grants or denies these resources, and a check is performed every time they try to access anything.
Even though I administer that system, I refer to that domain-based process as "external security".
It isn't external. Its completely ours. But I call it that to differentiate it from security built into the applications themselves which is "internal security".
Anyone still reading? I suspected at this point people would drift, start scanning down for the kitten picture, desperately seeking something about this post which is interesting or humorous. I can't promise interesting or humorous, but I'm sure I've got enough kitten pictures stashed on my work hard drive to share one I'd been saving for a weekly report. Just stay with me.
Okay. So applications with "internal security" do not leverage domain security and users need to be set up manually with new passwords they must be given and which they will either jot down on a Post-It note stuck to their monitor or forget (whichever is faster) and (this is particularly bad given that I am allergic to speaking with the users) call whoever set them up to reset it to something easier to remember like "password". Insert involuntary shudder.
And then, there was a request to deploy one of these applications through Citrix, because every other group said no already.
So I looked over the documentation, which was actually less than I've written above about it and contacted their support people (in Europe) to find out if the application was supported if deployed through Terminal Services. It isn't.
I recommended that the application go somewhere else, anywhere else, because I know when it breaks I'm the only person to call about it.
My recommendation was dismissed.
Resentfully, I published the application. I sent the person who originally requested the application the SuperUser password and headed for the virtual dance floor.
As the music started, the user asked for the application to be published to three users for testing.
I granted them domain access (which was also required) and pirouetted into "But the users will need to be set up within the application by the application owner".
The music swelled.
The user wrote back and requested that the test users be granted access.
Shuffle-step left, "The SuperUser account can be used to set up however many people are needed to fully take advantage of this application for the continued profitability of the enterprise."
Circling left with some kind of half-turn designed to disorient, the user replied with, "Shall I just have them use the SuperUser account for access?"
There was a loud scratching noise from the record player.
Give all the users SuperUser access to the database associated with an application without vendor support?
When the music resumed, the tempo was a little faster.
"This would be inadvisable," I turned in a slow circle, waving my arms but maintaining my position on the dance floor, "since someone could delete everything and no one would know which user did it. They should be given separate accounts with rights to modify only data that pertains to things that belong to them. This can all be done with the SuperUser account which I provided. When that is done, the password for that account should be changed as well since it is still the default password."
The user went all "River Dance" at this point and asked me to set up users within the application. He asked me directly.
There is no way I want to be the point of contact for this. Or, for that matter, for anything.
Users shouldn't call me. I'm still a little upset that someone keeps fixing my desk phone number in the company directory even after I changed it to a 555 number and locked the field.
With a jump to the left (and then a step to the right), I pulled up a list of reasons I could not be in charge of this application, not the least of which being that I don't even know what it does or why we have it. The user decided to do it himself before I got the the "pelvis thrust" part, which was quite wise (for a user).
1 comment:
Sounds similar to an issue that my BF had with a client's network... Everyone there refused to use their own logins, and as such, all borrowed the login of the person they knew with the most access... Against my BF's advice of course.
Lets just say he wasn't happy when he found out, and much cursing ensued... Along with deleting everyone's access, and assigning new logins and passwords, with the directive that if anyone shared, they, and the person that gave them their login, would be permanently barred from the system, whether or not that meant the client would have to hire new staff.
Post a Comment