 |
|
|
|
Next: IIS 6.0 cannot render html or ASP
|
| Author |
Message |
External
Since: Apr 12, 2004
Posts: 6
|
(Msg. 1) Posted: Tue Apr 13, 2004 2:32 am
Post subject: Restrict use of AMI, ADSI and WScript.Shell
Archived from groups: microsoft>public>inetserver>iis (more info?)
|
|
|
Hi, I would appreciate any tips on restricting WMI, ADSI, and WScript.Shell
from being used in ASP pages by anyone other than the Administrators group
in a shared hosting environment. WMI seems like it can be restricted fairly
easily via the "WMI Control" MMC snap-in. But how about ADSI and
WScript.Shell? This is for IIS 6.0 on W2K3.
By the way, each web site has it's own IUSR account and application pool.
The application pool's identity is also a unique user account for each web.
This allows me to restrict access to files between different webs. However,
I would still like to restrict WMI, ADSI and Wscript.Shell from being used
at all, except by the Administrators group.
Thanks for any tips and advice. |
|
| Back to top |
|
 | |
External
Since: Aug 25, 2003
Posts: 2419
|
(Msg. 2) Posted: Tue Apr 13, 2004 2:32 am
Post subject: Re: Restrict use of AMI, ADSI and WScript.Shell [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
You can use Filesystem ACL on %windir%\System32\wshom.ocx to control who
can create the WScript.Shell object (as well as all the WScript.* objects)
in one shot. Can't use Filesystem ACL to allow one users to create
WScript.Network but not WScript.Shell, for example.
I'm not certain if ADSI has anything comparable to WMI, but you can use the
same Filesystem ACL approach on %windir%\system32\adsiis.dll to prevent
users to access all of the IIS:// ADSI namespace.
--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Peter Johansen" <peterJohan13384.TakeThisOut@hotmail.com> wrote in message
news:ZFFec.132167$Bk31.35595@twister01.bloor.is.net.cable.rogers.com...
Hi, I would appreciate any tips on restricting WMI, ADSI, and WScript.Shell
from being used in ASP pages by anyone other than the Administrators group
in a shared hosting environment. WMI seems like it can be restricted fairly
easily via the "WMI Control" MMC snap-in. But how about ADSI and
WScript.Shell? This is for IIS 6.0 on W2K3.
By the way, each web site has it's own IUSR account and application pool.
The application pool's identity is also a unique user account for each web.
This allows me to restrict access to files between different webs. However,
I would still like to restrict WMI, ADSI and Wscript.Shell from being used
at all, except by the Administrators group.
Thanks for any tips and advice. |
|
| Back to top |
|
| |
External
Since: Apr 12, 2004
Posts: 6
|
(Msg. 3) Posted: Tue Apr 13, 2004 7:01 am
Post subject: Re: Restrict use of AMI, ADSI and WScript.Shell [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
Hi David,
Thank you very much. I'm really glad it's as simple as setting NTFS
permissions on the 2 files you mentioned. Just a note - the "adsiis.dll" was
in the "%windir%\system32\inetserv" folder on my server, not the
"%windir%\system32" folder. Not sure if different Windows versions has the
file in different places but thought I should mention it in case someone
else ever has the same Q's. I assume it's the same file though.
If anyone has any suggestions as to what other dangerous objects should be
restricted in this manner I would appreciate it. The one possible security
risk I will have to allow unfortunately is access to the FSO, but I think I
have that locked down fairly well since I'm using different IUSR's and app
pool identities for each web site, with appropriate NTFS permissions set on
the web root and contents.
Thanks!
"David Wang [Msft]" <someone RemoveThis @online.microsoft.com> wrote in message
news:ufc1RcQIEHA.4092@TK2MSFTNGP11.phx.gbl...
> You can use Filesystem ACL on %windir%\System32\wshom.ocx to control who
> can create the WScript.Shell object (as well as all the WScript.* objects)
> in one shot. Can't use Filesystem ACL to allow one users to create
> WScript.Network but not WScript.Shell, for example.
>
> I'm not certain if ADSI has anything comparable to WMI, but you can use
the
> same Filesystem ACL approach on %windir%\system32\adsiis.dll to prevent
> users to access all of the <a style='text-decoration: underline;' href="IIS://" target="_blank">IIS://</a> ADSI namespace.
>
> --
> //David
> IIS
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> //
> "Peter Johansen" <peterJohan13384 RemoveThis @hotmail.com> wrote in message
> news:ZFFec.132167$Bk31.35595@twister01.bloor.is.net.cable.rogers.com...
> Hi, I would appreciate any tips on restricting WMI, ADSI, and
WScript.Shell
> from being used in ASP pages by anyone other than the Administrators group
> in a shared hosting environment. WMI seems like it can be restricted
fairly
> easily via the "WMI Control" MMC snap-in. But how about ADSI and
> WScript.Shell? This is for IIS 6.0 on W2K3.
>
> By the way, each web site has it's own IUSR account and application pool.
> The application pool's identity is also a unique user account for each
web.
> This allows me to restrict access to files between different webs.
However,
> I would still like to restrict WMI, ADSI and Wscript.Shell from being used
> at all, except by the Administrators group.
>
> Thanks for any tips and advice.
>
>
>
>
><!-- ~MESSAGE_AFTER~ --> >> Stay informed about: Restrict use of AMI, ADSI and WScript.Shell |
|
| Back to top |
|
| |
External
Since: Apr 12, 2004
Posts: 3
|
(Msg. 4) Posted: Tue Apr 13, 2004 7:01 am
Post subject: Re: Restrict use of AMI, ADSI and WScript.Shell [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
Adsiis.dll and its companion, iisext.dll, lived in system32 in IIS 4.0 and
5.x, but moved to system32\inetsrv for IIS 6.
--
Liberty means responsibility. That is why most men dread it.
-- George Bernard Shaw
(Get Witty Auto-Generated Signatures from <a style='text-decoration: underline;' href="http://SmartBee.org" target="_blank">http://SmartBee.org</a>)
George V. Reilly george.TakeThisOut@reilly.org
"Peter Johansen" <peterJohan13384.TakeThisOut@hotmail.com> wrote in message
news:5CJec.140611$Bk31.70372@twister01.bloor.is.net.cable.rogers.com...
> Hi David,
>
> Thank you very much. I'm really glad it's as simple as setting NTFS
> permissions on the 2 files you mentioned. Just a note - the "adsiis.dll"
was
> in the "%windir%\system32\inetserv" folder on my server, not the
> "%windir%\system32" folder. Not sure if different Windows versions has the
> file in different places but thought I should mention it in case someone
> else ever has the same Q's. I assume it's the same file though.
>
> If anyone has any suggestions as to what other dangerous objects should be
> restricted in this manner I would appreciate it. The one possible security
> risk I will have to allow unfortunately is access to the FSO, but I think
I
> have that locked down fairly well since I'm using different IUSR's and app
> pool identities for each web site, with appropriate NTFS permissions set
on
> the web root and contents.
>
> Thanks!
>
>
> "David Wang [Msft]" <someone.TakeThisOut@online.microsoft.com> wrote in message
> news:ufc1RcQIEHA.4092@TK2MSFTNGP11.phx.gbl...
> > You can use Filesystem ACL on %windir%\System32\wshom.ocx to control
who
> > can create the WScript.Shell object (as well as all the WScript.*
objects)
> > in one shot. Can't use Filesystem ACL to allow one users to create
> > WScript.Network but not WScript.Shell, for example.
> >
> > I'm not certain if ADSI has anything comparable to WMI, but you can use
> the
> > same Filesystem ACL approach on %windir%\system32\adsiis.dll to prevent
> > users to access all of the <a style='text-decoration: underline;' href="IIS://" target="_blank">IIS://</a> ADSI namespace.
> >
> > --
> > //David
> > IIS
> > This posting is provided "AS IS" with no warranties, and confers no
> rights.
> > //
> > "Peter Johansen" <peterJohan13384.TakeThisOut@hotmail.com> wrote in message
> > news:ZFFec.132167$Bk31.35595@twister01.bloor.is.net.cable.rogers.com...
> > Hi, I would appreciate any tips on restricting WMI, ADSI, and
> WScript.Shell
> > from being used in ASP pages by anyone other than the Administrators
group
> > in a shared hosting environment. WMI seems like it can be restricted
> fairly
> > easily via the "WMI Control" MMC snap-in. But how about ADSI and
> > WScript.Shell? This is for IIS 6.0 on W2K3.
> >
> > By the way, each web site has it's own IUSR account and application
pool.
> > The application pool's identity is also a unique user account for each
> web.
> > This allows me to restrict access to files between different webs.
> However,
> > I would still like to restrict WMI, ADSI and Wscript.Shell from being
used
> > at all, except by the Administrators group.
> >
> > Thanks for any tips and advice.
> >
> >
> >
> >
> >
>
><!-- ~MESSAGE_AFTER~ --> >> Stay informed about: Restrict use of AMI, ADSI and WScript.Shell |
|
| Back to top |
|
| |
External
Since: Apr 12, 2004
Posts: 6
|
(Msg. 5) Posted: Tue Apr 13, 2004 8:03 am
Post subject: Re: Restrict use of AMI, ADSI and WScript.Shell [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
Thanks George. Should I restrict access to "iisext.dll" as well? What
exactly is the function of this dll?
BTW, I applied NTFS permissions to "wshom.ocx" and "adsiis.dll"
(Administrators and System - Full Control) as suggested by David and it
worked great. My test scripts which worked before now correctly fails at the
object creation stage unless I logon with an administrator account, which is
exactly what I wanted.
"George V. Reilly" <george.RemoveThis@reilly.org> wrote in message
news:%23KIJP%23QIEHA.3848@tk2msftngp13.phx.gbl...
> Adsiis.dll and its companion, iisext.dll, lived in system32 in IIS 4.0 and
> 5.x, but moved to system32\inetsrv for IIS 6.
> --
> Liberty means responsibility. That is why most men dread it.
> -- George Bernard Shaw
> (Get Witty Auto-Generated Signatures from <a style='text-decoration: underline;' href="http://SmartBee.org" target="_blank">http://SmartBee.org</a>)
> George V. Reilly george.RemoveThis@reilly.org
>
>
> "Peter Johansen" <peterJohan13384.RemoveThis@hotmail.com> wrote in message
> news:5CJec.140611$Bk31.70372@twister01.bloor.is.net.cable.rogers.com...
> > Hi David,
> >
> > Thank you very much. I'm really glad it's as simple as setting NTFS
> > permissions on the 2 files you mentioned. Just a note - the "adsiis.dll"
> was
> > in the "%windir%\system32\inetserv" folder on my server, not the
> > "%windir%\system32" folder. Not sure if different Windows versions has
the
> > file in different places but thought I should mention it in case someone
> > else ever has the same Q's. I assume it's the same file though.
> >
> > If anyone has any suggestions as to what other dangerous objects should
be
> > restricted in this manner I would appreciate it. The one possible
security
> > risk I will have to allow unfortunately is access to the FSO, but I
think
> I
> > have that locked down fairly well since I'm using different IUSR's and
app
> > pool identities for each web site, with appropriate NTFS permissions set
> on
> > the web root and contents.
> >
> > Thanks!
> >
> >
> > "David Wang [Msft]" <someone.RemoveThis@online.microsoft.com> wrote in message
> > news:ufc1RcQIEHA.4092@TK2MSFTNGP11.phx.gbl...
> > > You can use Filesystem ACL on %windir%\System32\wshom.ocx to control
> who
> > > can create the WScript.Shell object (as well as all the WScript.*
> objects)
> > > in one shot. Can't use Filesystem ACL to allow one users to create
> > > WScript.Network but not WScript.Shell, for example.
> > >
> > > I'm not certain if ADSI has anything comparable to WMI, but you can
use
> > the
> > > same Filesystem ACL approach on %windir%\system32\adsiis.dll to
prevent
> > > users to access all of the <a style='text-decoration: underline;' href="IIS://" target="_blank">IIS://</a> ADSI namespace.
> > >
> > > --
> > > //David
> > > IIS
> > > This posting is provided "AS IS" with no warranties, and confers no
> > rights.
> > > //
> > > "Peter Johansen" <peterJohan13384.RemoveThis@hotmail.com> wrote in message
> > >
news:ZFFec.132167$Bk31.35595@twister01.bloor.is.net.cable.rogers.com...
> > > Hi, I would appreciate any tips on restricting WMI, ADSI, and
> > WScript.Shell
> > > from being used in ASP pages by anyone other than the Administrators
> group
> > > in a shared hosting environment. WMI seems like it can be restricted
> > fairly
> > > easily via the "WMI Control" MMC snap-in. But how about ADSI and
> > > WScript.Shell? This is for IIS 6.0 on W2K3.
> > >
> > > By the way, each web site has it's own IUSR account and application
> pool.
> > > The application pool's identity is also a unique user account for each
> > web.
> > > This allows me to restrict access to files between different webs.
> > However,
> > > I would still like to restrict WMI, ADSI and Wscript.Shell from being
> used
> > > at all, except by the Administrators group.
> > >
> > > Thanks for any tips and advice.
> > >
> > >
> > >
> > >
> > >
> >
> >
>
><!-- ~MESSAGE_AFTER~ --> >> Stay informed about: Restrict use of AMI, ADSI and WScript.Shell |
|
| Back to top |
|
| |
External
Since: Apr 12, 2004
Posts: 6
|
(Msg. 6) Posted: Tue Apr 13, 2004 5:14 pm
Post subject: Re: Restrict use of WMI, ADSI and WScript.Shell [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
It looks like the ADSI "WinNT" namespace is implemented with a different
..dll. I checked and found a few dll's in "c:/Windows/system32" that look
like they may be related to ADSI :
adsldp.dll
adsldpc.dll
adsmsext.dll
adsnds.dll
adsnt.dll
adsnw.dll
I'd be happy to restrict access to them via NTFS as I had done with
"adsiis.dll", but I wanted to check first that these dll's are in fact part
of ADSI, and does not require less strict permissions for some other reason.
Thanks - Peter
"David Wang [Msft]" <someone RemoveThis @online.microsoft.com> wrote in message
news:ufc1RcQIEHA.4092@TK2MSFTNGP11.phx.gbl...
> You can use Filesystem ACL on %windir%\System32\wshom.ocx to control who
> can create the WScript.Shell object (as well as all the WScript.* objects)
> in one shot. Can't use Filesystem ACL to allow one users to create
> WScript.Network but not WScript.Shell, for example.
>
> I'm not certain if ADSI has anything comparable to WMI, but you can use
the
> same Filesystem ACL approach on %windir%\system32\adsiis.dll to prevent
> users to access all of the <a style='text-decoration: underline;' href="IIS://" target="_blank">IIS://</a> ADSI namespace.
>
> --
> //David
> IIS
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> //
> "Peter Johansen" <peterJohan13384 RemoveThis @hotmail.com> wrote in message
> news:ZFFec.132167$Bk31.35595@twister01.bloor.is.net.cable.rogers.com...
> Hi, I would appreciate any tips on restricting WMI, ADSI, and
WScript.Shell
> from being used in ASP pages by anyone other than the Administrators group
> in a shared hosting environment. WMI seems like it can be restricted
fairly
> easily via the "WMI Control" MMC snap-in. But how about ADSI and
> WScript.Shell? This is for IIS 6.0 on W2K3.
>
> By the way, each web site has it's own IUSR account and application pool.
> The application pool's identity is also a unique user account for each
web.
> This allows me to restrict access to files between different webs.
However,
> I would still like to restrict WMI, ADSI and Wscript.Shell from being used
> at all, except by the Administrators group.
>
> Thanks for any tips and advice.
>
>
>
>
><!-- ~MESSAGE_AFTER~ --> >> Stay informed about: Restrict use of AMI, ADSI and WScript.Shell |
|
| Back to top |
|
| |
External
Since: Apr 12, 2004
Posts: 6
|
(Msg. 7) Posted: Tue Apr 13, 2004 7:22 pm
Post subject: Re: Restrict use of WMI, ADSI and WScript.Shell [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
I think I may have found the answer here :
<a style='text-decoration: underline;' href="http://support.microsoft.com/default.aspx?scid=kb;EN-US;216290" target="_blank">http://support.microsoft.com/default.aspx?scid=kb;EN-US;216290</a>
Looks like all those .dll's are collectively part of ADSI.
Regards - Peter
"Peter Johansen" <peterJohan13384 DeleteThis @hotmail.com> wrote in message
news:dBSec.112$le3.88@news04.bloor.is.net.cable.rogers.com...
> It looks like the ADSI "WinNT" namespace is implemented with a different
> .dll. I checked and found a few dll's in "c:/Windows/system32" that look
> like they may be related to ADSI :
>
> adsldp.dll
> adsldpc.dll
> adsmsext.dll
> adsnds.dll
> adsnt.dll
> adsnw.dll
>
> I'd be happy to restrict access to them via NTFS as I had done with
> "adsiis.dll", but I wanted to check first that these dll's are in fact
part
> of ADSI, and does not require less strict permissions for some other
reason.
>
> Thanks - Peter
>
>
>
> "David Wang [Msft]" <someone DeleteThis @online.microsoft.com> wrote in message
> news:ufc1RcQIEHA.4092@TK2MSFTNGP11.phx.gbl...
> > You can use Filesystem ACL on %windir%\System32\wshom.ocx to control
who
> > can create the WScript.Shell object (as well as all the WScript.*
objects)
> > in one shot. Can't use Filesystem ACL to allow one users to create
> > WScript.Network but not WScript.Shell, for example.
> >
> > I'm not certain if ADSI has anything comparable to WMI, but you can use
> the
> > same Filesystem ACL approach on %windir%\system32\adsiis.dll to prevent
> > users to access all of the <a style='text-decoration: underline;' href="IIS://" target="_blank">IIS://</a> ADSI namespace.
> >
> > --
> > //David
> > IIS
> > This posting is provided "AS IS" with no warranties, and confers no
> rights.
> > //
> > "Peter Johansen" <peterJohan13384 DeleteThis @hotmail.com> wrote in message
> > news:ZFFec.132167$Bk31.35595@twister01.bloor.is.net.cable.rogers.com...
> > Hi, I would appreciate any tips on restricting WMI, ADSI, and
> WScript.Shell
> > from being used in ASP pages by anyone other than the Administrators
group
> > in a shared hosting environment. WMI seems like it can be restricted
> fairly
> > easily via the "WMI Control" MMC snap-in. But how about ADSI and
> > WScript.Shell? This is for IIS 6.0 on W2K3.
> >
> > By the way, each web site has it's own IUSR account and application
pool.
> > The application pool's identity is also a unique user account for each
> web.
> > This allows me to restrict access to files between different webs.
> However,
> > I would still like to restrict WMI, ADSI and Wscript.Shell from being
used
> > at all, except by the Administrators group.
> >
> > Thanks for any tips and advice.
> >
> >
> >
> >
> >
>
><!-- ~MESSAGE_AFTER~ --> >> Stay informed about: Restrict use of AMI, ADSI and WScript.Shell |
|
| Back to top |
|
| |
| Related Topics: | WScript.Shell problem on windows 2003 - Dear sir, I tried everything I knew already, however, I just can not get WScript.Shell in a asp page to run on a windows 2003 server. The page didn't return any error,but if I change objShell.run(ExeName) to objShell.Run ExeName, 1, True. True means..
executing shell commands in asp - Hi, I'm trying to execute a Windows command in ASP. For example, this is a snippet of what I have right now: .... Set WshShell = WScript.CreateObject("WScript.Shell") WshShell.Run("notepad", 1, true) Set WshShell = Nothing .... The ...
How can I create a redirection using shell scripts? - Hi all, I need to configure a virtual directory to have a redirection to another url. How can I do it using shell scripts such as adsutil.vbs (or other) ? Thanks, Hagay.
Restrict files for certain IPs ? - Hello all, IIS 5 on Win2k Server, running PHP and MySQL, no other mappings. Is it possible to have IIS restrict access to a certain file ONLY from specific IPs ? For example, only accept from 10.1.1.1 - 10.1.1.10 ? Thanks.
IIS on XP Pro- Can't restrict incoming IP's, what are my o.. - I have a small website that I want to put on the internet, but I need to keep it private, so I think my best bet would be to just restrict access to an IP range for the clients that need it, as well as my intranet. Unfortunately, the "IP address an... |
|
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
|
|
|
FAQ
Profile
Private Messages
Log in
