Today I'm spending most of it sheepdogging a vendor installing an application. This vendor is VPNing in, and such access is a key part of the product's support contract.
This is something I've noticed recently. Several of the server-based off the shelf apps I've installed lately have had a requirement that the vendor have access to the server in some way. Some of it is so they can do the install. Some of it is so they can update it so we don't have to. Some of it is just in case we ever call for support and need their help.
I have a theory for why this is. I have a sneaking suspicion that its because that's how these vendors support installs in environments where the sysadmin is a desktop person who got handed a server and was asked, "make it work." This kind of vendor-based hand-holding makes the ongoing maintenance of applications lower on the client side of the equation, which can lead to more sales. But, I'm not sure if that's it or not.
This is causing some grumbling in the ranks, since it means untrusted parties have to be allowed to log in to servers in the domain. Before this recent spate of applications, vendors demanding such access had their apps relegated to servers not in the domain at all. This doesn't work when the app requires domain access. Console access to servers is a sensitive thing for us, so we don't like to hand it out on demand to vendors.
Especially when we weren't involved in the purchase process to begin with. Many a time we've been told:
Ahem.
How are y'all handling this kind of thing, presuming you're also seeing it and it isn't just me getting lucky.
This is something I've noticed recently. Several of the server-based off the shelf apps I've installed lately have had a requirement that the vendor have access to the server in some way. Some of it is so they can do the install. Some of it is so they can update it so we don't have to. Some of it is just in case we ever call for support and need their help.
I have a theory for why this is. I have a sneaking suspicion that its because that's how these vendors support installs in environments where the sysadmin is a desktop person who got handed a server and was asked, "make it work." This kind of vendor-based hand-holding makes the ongoing maintenance of applications lower on the client side of the equation, which can lead to more sales. But, I'm not sure if that's it or not.
This is causing some grumbling in the ranks, since it means untrusted parties have to be allowed to log in to servers in the domain. Before this recent spate of applications, vendors demanding such access had their apps relegated to servers not in the domain at all. This doesn't work when the app requires domain access. Console access to servers is a sensitive thing for us, so we don't like to hand it out on demand to vendors.
Especially when we weren't involved in the purchase process to begin with. Many a time we've been told:
Client: We spent umpty thousand dollars on this ap. Install it.Or words to that effect.
Us: *reads install document, cringes* They need Administrator access to the whole box and a tunnel into the inner Banner fortress. I don't want to.
Client: What part of umpty thousand dollars don't you understand? Make it work.
Us to Management: Insecure! Violates best practices!
Management to Us: It's too late to get a refund, and upper management was involved in the decision. Make it work.
Us: Wilco.
Ahem.
How are y'all handling this kind of thing, presuming you're also seeing it and it isn't just me getting lucky.
Basically you call the bluff of Upper Meatheads
Its their blunder not yours.
Tell them to install it
Or walk.
Hmm... Why not write up a document with some known possible damage that could occur, then require that the "management" types sign-off and accept responsibility for the risks?
I mean, if you can't stop it, you might as well at least make them *think* about it... might have a deterrent effect for next time, too...
Sometimes it helps to have an outsider chime in. Management types never listen to their own employees, but they listen to outsiders. I'm talking about vendors/owners of other apps (who would probably like to know that their competitor now has the ability to screw up their install, for example) as well as consultants, vars, etc., if any.
8-)
My preferred solution is something like the webex support: you call the vendor, logon a website and the support people can share your admin desktop. You can see what is going on and stop the connection any time. Plus multi-platform client (yes, it works in linux, java client).
What we do for the cases where domain credentials are required is create a domain logon account that only allows to logon to the application server(s). On the vpn side you can also control what the external people can do.
It's basically a question of trust. On the one hand, I am happy not to have to support yet another application, apply its patches/upgrades etc. On the other, yes, you lose some control of your infrastructure.
Why are software companies using these services? Well, I do not know about the knowledge of IT professionals in non-tech companies in the US, but where I work I can assure you that I was really surprised to see admins who did not understand dns, ldap, kerberos or basic scripting stuff. Windows admins are used to buying off the shelf solutions, so they do not invest in learning stuff to solve it themselves. But that is what windows has brought us, you do not need to understand how stuff works because it is easy, isn't it? Except that it is not, of course. I mean, Active Directory is a great solution (really, the more I use it, the more I like it), but to manage a complex network you really do need to understand at least how the technologies I mentioned earlier work. Maybe in the future non-tech companies will have just helpdesk people on site and for something more engaged than making users they will call outsourced sysadmins who work for the big companies.
About written policies: they are great as long as they are endorsed by management. If management ignores their own policies, then you are basically out of luck. Sysadmins are overhead, so managers do not feel they should ask them anything (specially in non-tech companies).
I have been on both ends of this -- supporting server installed in client environments and having clients want to install them in my own environment.
My solution has been to either install it in its own dedicated DMZ or advise the client to do the same. This way it ends up with no more access to anything on the internal network than anything else on the Internet really.
The server itself can then handle the VPN or remote access and I just NAT to it or give it's own public IP.
The big problem with having upper management overrule the people who are paid to know this stuff is it leads to fatalism on the part of us minions. Since government work (for we all are State employees) tends to lead to people spending most of their lives at a place, a disillusioned employee (even technical ones) are more likely to stay in one place being a pissy-pants fatalist than move on to something more to their liking. It's one of the failure modes for being in one place for a long time.
Yup, hitting this post a bit late, but it just happened to be topical these days. I don't have this problem on windows boxes so much, I have this problem on ALL boxes.
Recently a vendor deployed a server I'm supposed to be responsible for. It collects some metrics on some hardware we have, and I really need the data. If I really need the data, the machine has to be available. For it to be available, I need to monitor it. I made the mistake of asking for an account on this linux box so I could enable the SNMPd.
Long, LONG story short, I was completely denied. When I said I'd take physical measures to change it myself, I was told I'd be completely forgoing support and jeopardizing who knows what.
My company bought and paid for this machine, yet, I'm not allowed to have access to it. I'm ultimately responsible for it working, but to do so, I have to rely on the vendor. Sure, I could proactively find out if the machine was ready to die and open the case, but no... I have to wait till it's completely dead and spend hours of my time getting a solution in order. I admin thousands of similar servers with no issue, so I had one question, the same you did. Your scenario is similar, but I don't agree on how one gets there.
I ask, who does this benefit? Everyone but the sysadmin. Upper management gets to say we're saving money by the SLA of the vendor, and they're right, because it's in writing. Middle management gets some sort of responsibility to put on their CV, the vendor rakes in exorbitant support fees for basically nothing, and the sysadmin is left with the shortest end of the straw, as always. You can't even try to be proactive in these situations.
Ironically, I've found that the system that was such a big deal became such a pain in the ass, that we don't use it. I'm going to recommend we don't renew the software support for it because the users and the admins aren't getting any use out of it. I couldn't evangelize it and I was discontent, so my users weren't excited either.
This sort of operation usually digs its own hole over time.