In this modern era, it is becoming more an more common for vendors in the Windows world to either require, or strongly suggest that the vendor perform a software install on a server. In the past this required either sending a physical body out to the location, or using something like PC-Anywhere to do the install. Now, a wide variety of web-based remote-control packages are on the market that greatly simplify getting the knowledgeable install-geek onto the server in question.
More and more often, vendors are offering maintenance and update contracts contingent on console access. While these greatly simplify maintaining a package for small offices who don't have the IT oomph to really do it themselves, these are a great pain for those of us who manage the servers themselves. What's really bad is when web software (typically IIS and .NET based) is subject to these sorts of contracts.
We have a small number of IIS-based web-servers that are shared with a variety of departments. ATUS and ADMCS are the biggest consumers, of course, but other departments have their own stuff on there. This also includes several 3rd party apps we've put in over the years. These servers have a lot on them.
What happens when we get more than one software package with this sort of contract attempting to run on these IIS servers? It means that, at least in theory, multiple vendors have nearly unrestricted access to these web-servers. As these servers are general-purpose servers and not dedicated to this one application, this is a pretty major data-security issue.
This isn't quite as big a problem when the application is a more traditional client/server app, or the app resides on its own dedicated server. We don't like that kind of app-server running with AD credentials on console, but we can work around that. Web-servers, though, run a lot of apps.
In the UNIX world, I have heard of vendors requesting the ability to SSH into a server in order to do installs. The context of this was humor, as in, "look at the stupid vendor." In general, if a vendor asks for local root to a server for a simple install, the answer will be a resounding no way. So what makes the Windows world different, that they'll permit a third party root-access to their own servers? Perhaps because it takes a lot less skill to do Windows administration at least half-way right, so vendors have to compensate for less comprehensively trained system administrators. Unfortunately, it makes them less nimble when they do run into shops with strict controls on what runs on the web servers, and who is allowed console access to them.
More and more often, vendors are offering maintenance and update contracts contingent on console access. While these greatly simplify maintaining a package for small offices who don't have the IT oomph to really do it themselves, these are a great pain for those of us who manage the servers themselves. What's really bad is when web software (typically IIS and .NET based) is subject to these sorts of contracts.
We have a small number of IIS-based web-servers that are shared with a variety of departments. ATUS and ADMCS are the biggest consumers, of course, but other departments have their own stuff on there. This also includes several 3rd party apps we've put in over the years. These servers have a lot on them.
What happens when we get more than one software package with this sort of contract attempting to run on these IIS servers? It means that, at least in theory, multiple vendors have nearly unrestricted access to these web-servers. As these servers are general-purpose servers and not dedicated to this one application, this is a pretty major data-security issue.
This isn't quite as big a problem when the application is a more traditional client/server app, or the app resides on its own dedicated server. We don't like that kind of app-server running with AD credentials on console, but we can work around that. Web-servers, though, run a lot of apps.
In the UNIX world, I have heard of vendors requesting the ability to SSH into a server in order to do installs. The context of this was humor, as in, "look at the stupid vendor." In general, if a vendor asks for local root to a server for a simple install, the answer will be a resounding no way. So what makes the Windows world different, that they'll permit a third party root-access to their own servers? Perhaps because it takes a lot less skill to do Windows administration at least half-way right, so vendors have to compensate for less comprehensively trained system administrators. Unfortunately, it makes them less nimble when they do run into shops with strict controls on what runs on the web servers, and who is allowed console access to them.