Re: Remote process with network access
From: Ivan Brugiolo [MSFT] (ivanbrug_at_online.microsoft.com)
Date: 09/02/04
- Next message: Jimmy B: "Re: Win32_LogicalDiskToPartition question"
- Previous message: Gerry Hickman: "Re: Remote process with network access"
- In reply to: Gerry Hickman: "Re: Remote process with network access"
- Next in thread: Gerry Hickman: "Re: Remote process with network access"
- Reply: Gerry Hickman: "Re: Remote process with network access"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 2 Sep 2004 15:47:07 -0700
If you have a internet-exposed web server,
does this web server allows authenticated connections ?
If yes, via Windwos-Integrated-Authentication, or via SSL ?
If you have SSL, then credentials does not need to be delegated
(actually, kerberos is not even involved).
If a server gets compromised, then it can run arbitrary code
with either the process account (NetworkService in modern-era Web Servers),
or any other token that happens to be in that process.
If these are SSL tokens, than delegation OFF will not save you.
There's not much point discussing the different security requirements
of your deployment here. I just pointed out what are the options.
Sorry.
-- This posting is provided "AS IS" with no warranties, and confers no rights. Use of any included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm "Gerry Hickman" <gerry666uk@yahoo.co.uk> wrote in message news:#KirX0TkEHA.524@TK2MSFTNGP15.phx.gbl... > Hi Ivan, > > In my own scenario, it's a corporate network, but the users don't have > local Administrator access. There are two reasons delegation has not > been allowed in my environment to date: > > 1. Some servers are also web servers (world facing) running IIS and we'd > like to use ASP in conjunction with Active Directory and WMI, but the > risk is that if the server was compromised the local system would be > able to access other boxes on the network. > > 2. When the guys in head office try to enable delegation in AD they get > big dialog boxes saying it's not safe. In days gone by, they'd have been > less cautious, but with all the recent security scandals they refuse to > consider anything that may be a risk. It's also no good if we have to do > it for every box on the network we want to manage. > > Ivan Brugiolo [MSFT] wrote: > > The credentials of the account needs to be delegatable > > and the machine account needs to be trusted for delegation. > > > > The only reason I can see for not structing for delegation a machine account > > is that the machine is compromiseable, that is, it's easy to have arbitrary > > code running as localsystem. > > If you have code running as localsystem in a machine trusted for delegation, > > then, if you can induce an authentication over it (for example, > > by creating a web server and forcing a user to navigate that web server > > with non anonymous credentials), then you can impersonate delegat-able > > credentials, > > and perform any action on behalf of the user. > > > > I guess that your scenario is a corporate network where users are allowed > > to log-in as local administraotrs. In this case, delegation is dangerous. > > > > > -- > Gerry Hickman (London UK)
- Next message: Jimmy B: "Re: Win32_LogicalDiskToPartition question"
- Previous message: Gerry Hickman: "Re: Remote process with network access"
- In reply to: Gerry Hickman: "Re: Remote process with network access"
- Next in thread: Gerry Hickman: "Re: Remote process with network access"
- Reply: Gerry Hickman: "Re: Remote process with network access"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|