When a service really starts

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have written a .NET Service. In the OnStart method, I am setting the
Services user name and password. Has the service already obtained this
information at this point and is using the existing information? Is this the
right place to do this in the service's code?
 
Bruce Parker said:
I have written a .NET Service. In the OnStart method, I am setting the
Services user name and password. Has the service already obtained this
information at this point and is using the existing information? Is this
the
right place to do this in the service's code?
Click to expand...

Yes, the Service Controller starts your process up with the credentials
indicated. You don't have to change anything as far as that is concerned. In
fact I would consider it a pretty serious security hole to have a service
change it's own logon credentials.
 
Does this mean if I put the code in the constructor to change the logon
credentials it is too late?

In addition, this is not a security hole. A network administrator provides
this information via another secured application which is required by our
software. The service obtains this information from the secured application.
Without going into details, it becomes a security risk if the logon
credentials does not match the one the network administrator provides in the
other application.

I need a definitive answer on this question.
 
Bruce Parker said:
Does this mean if I put the code in the constructor to change the logon
credentials it is too late?
Click to expand...

Yes, the process has already been started with the credentials entered in
the Service Management Tool. You could stop your service starting if the
credentials do not match. Another possible solution would be to impersonate
the required user.

Finally, you could change the service credentials, and then kick off a
process that will restart the service. Needless to say this process would
require pretty high privileges.
In addition, this is not a security hole. A network administrator
provides
this information via another secured application which is required by our
software. The service obtains this information from the secured
application.
Without going into details, it becomes a security risk if the logon
credentials does not match the one the network administrator provides in
the
other application.
Click to expand...

Any time you're passing logon information around it presents another attack
surface for your app. Obviously if your solution requires this there's not a
helluva lot you can do about it though. If it was acceptable to have your
service fail to start up if it didn't have the required credentials, then
you could connect to the secured admin app, and check what credentials you
required, compare them with the credentials you have, and exit if you don't
have enough. The security hole comes in when the secured admin app stores
and transmits the logon details (namely the password) to your application.
 
Back
Top