At work our first level support uses a ticket management system that allows us to add extra functionality via VBScripts that the application invokes. First level support also receives quite a few requests for a certain issue that requires a very simple one line of SQL code to fix. We'd like to provide them with a solution (ie: VBScript) that they can invoke to quickly fix the issue while the client is on the phone instead of escalating to a team that has access to the database.

However, we are hesitant to create a VBScript for them to use to fix this problem since the VBScript would contain database credentials and they are able to view the script if they know where to look. Obviously the database user account that would be used for this would have very limited access, however, exposing the credentials still doesn't sit well with with us.

The approach we're thinking of taking is to have an intranet exposed application that the VBScript would connect to and this application would be the one that would perform the database change. This would prevent us from having to put the database credentials in the VBScript, instead they would be in a closed source web application that we have full control over. However, I'm not 100% sure how to prevent unauthorized access to this "middle man" application. Is there any industry standard for dealing with situations where you want only one source (the VBScript) to be able to connect to an application? We could simply password protected this application, however, that's credentials again and any credential exposure doesn't sit well with us. I'm thinking something more along the lines of cryptography keys which would mean almost nothing to most individuals. Any help and insight into how to address our problem is highly appreciated.

1 Answer 1


Consider using a credential authenticated VB .NET TCP session to your database server as the secure interaction agent for your process. Microsoft has an example here.

If the first level support folks have the certificate for the VB transactions on their systems rather than the DB certificates you will not have to expose anything more than the capability your have already decided to delegate to them. The DB certificates can remain on the database and be used to kick off the change in authorization needed once the secure VB request comes in from the help desk.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .