How to start/stop windows service on a remote machine?

[Goran Djuranovic]

Hi all,
I have a web app running on a local PC that can start and stop windows service on a remote machine, but only when I browse to it locally. If I browse to it from my other PC and try to start/stop the service, it gives me "Cannot open Service Control Manager on computer 'xxx.xxx.xxx.xxx'. This operation might require other privileges." error.

Helpfull info:
- I am an admin on all 3 PCs
- web app is using "Windows" authentication (Integ. Win. Auth. turned ON in IIS, Anonimous Auth. turned OFF), plus "impersonation"
*** from web.config ***:
<authentication mode="Windows" />
<identity impersonate="true" />
<authorization>
<allow users="*" />
<deny users="?" />
</authorization>

Now, I can make it work, if I add user name and password to impersonation part:
<identity impersonate="true" userName="xxxx" password="xxxx" />
but I need the app to impersonate multiple people (admins), and not one person.

Also, when I don't provide userName and password, event viewer one a remote machine logs "ANONIMOUS LOGON" entry, but when I do provide userName and password the event viewer logs "<MyDomainUser>" entry. All is entered under "Security" log file.

I triple checked my IIS settings, and they see to be fine. What am I doing wrong?

Thanks
Goran Djuranovic

 

[Steven Cheng[MSFT]]

Hello Goran,

From your description, I understand you have an ASP.NET application which
impersonate the client user(authenticated via integrated windows
authentication in IIS) and access some remote protected resource(windows
service on remote machine). You find the access works when try visiting the
web application from the webserver locally, but fails when access from
other remote client, correct?

Based on my experience, the problem you meet is a typical windows
authentication's double hop issue. For windows authenticated user, the
windows system issue a security token, for example, when the client use
browser to visit your web application, IIS(windows authentication)
authenticate the client user and issue a windows token at server-side, this
token can represent that certain windows account to access protected
resource on the web server. However, if the webserver(ASP.NET application)
want to continue access other remote machine, this originally authenticated
token will not be able to go acorss the machine boundary. This is called
"double hop" limitation. Here is a blog article which detailedly describe
this:

#Concerning the credentials double hop issue
http://blogs.msdn.com/nunos/archive/2004/03/12/88468.aspx

The reason why you can get it work when visit ASP.NET application locally
is because when accessing locally, the webserver(IIS and your application)
directly obtain the security token from your logon session on the
webserver, this token hasn't go through any hop previously, therefore, it
can be forwarded to a further remote machine.

As the above article has mentioned, generally we can consider several means
to workaround it:

** use basic authentication (with HTTPS) since basic authentication get
clear text credential from client and the authenticated token can be double
hopped

** use code to programmatically perform impersonate in our ASP.NET
application, this will need us to supply clear text username/password
credentials

** configure our webserver, the remote machine(to configure windows
service) and the windows accounts that will play in the application be
delegatable. Thus, we can use kerberos delegation which can also overcome
the double hop limitation. however, configure kerberos delegation is quite
complex which will require particular configuration on both client, server
and remote machines.

** Always use a fixed account(domain account) to access the further remote
server

If you have anything unclear on this or if you have any other particular
questions, please feel free to let me know.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================



This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Goran Djuranovic]

Hello Steven,
You are absolutelly right in your assumption. I was able to make it work by
using choice #2 (Basic Authentication).

However, I did run into another problem. My website was previously
configured to use Integrated Authentication only, but now I cannot use it
because the "double hop" issue comes up, if I use both Basic and Integrated
Authentication. It looks like Integrated overrides Basic.

Is there a way I could combine these two, and eliminate "double hop" issue?

Thanks a lot.
Goran Djuranovic

 

[Steven Cheng[MSFT]]

Thanks for your reply Goran,

Yes, in IIS virtual directory, you can use only one authentication type at
a time. since "Basic" setting is before "Integrated Windows", it will use
"Basic" when you enable both.

As you mentioned, your application previously use "integrated windows
authentication", is there any particular server-side code logic rely on
this or what you worry about is the client-side user's experience. As far
as I know, for basic authentication, the drawback is the client user will
be prompt for username/password credentials when requesting the web page
and this is transfered to server as clear text, so in internet scenario,
you have to use SSL/HTTPS to secure the channel. At server-side basic
authenticated user will also be mapped to a WindowsIdentity associated with
the HttpContext.User propety(as long as the ASP.NET application is
configured as windows authentication).

If you're wondering other means which can also overcome double hop problem
and remain using integrated windows authentication(without impersonate
under a fixed account), I'm afraid the only possible approach is using
Kerberos delegation in your environment(from client to webserver and the
backend server). As I mentioned previously, configure kerberos delegation
is quite complex since it require you to not only configure all the server
machines(webserver and backend server and also the DC), but also all those
windows accounts that will participate in the application scope. Here are
some reference articles about ASP.NET delegation and how to implement it,
you can have a look first to see whether it will fit your environment:


#ASP.NET Delegation
http://msdn2.microsoft.com/en-us/library/aa291350(VS.71).aspx

#How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0
http://msdn2.microsoft.com/en-us/library/ms998355.aspx

#How To: Use Impersonation and Delegation in ASP.NET 2.0
http://msdn2.microsoft.com/en-us/library/ms998351.aspx


#How to configure an ASP.NET application for a delegation scenario
http://support.microsoft.com/kb/810572/en-us

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Goran Djuranovic]

Hi Steven,
We decided to have this asp.net website as an "intranet" website, and
therefore will use Basic Authentication with impersonation. It worked very
well for us. Consider this issue resolved and thank you for all your help.

Goran Djuranovic

 

[Steven Cheng[MSFT]]

Hi Goran,

Thanks for your followup. I'm glad that you've got it working now.

Have a good day!

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.