Sign in with
Sign up | Sign in
Your question

Web Server - User Access and Priviledges.

Last response: in Windows 2000/NT
Share
Anonymous
a b 8 Security
September 22, 2004 7:15:59 PM

Archived from groups: microsoft.public.inetserver.iis.security,microsoft.public.security,microsoft.public.win2000.security,microsoft.public.win2000.termserv.clients,microsoft.public.windows.server.security (More info?)

G/Day Forum,

I'm currently hardening access to all my IIS 5.0 and IIS 6.0 servers, that
are located within multiple DMZ environments in multiple locations.



All servers are Firewalled and are administered through VPN's using Terminal
Services/RDP. Recently, I encountered a (self induced)problem with one of
these Servers where I mucked up the password change (on the only
Administrator account on the server) on one of our Production Systems - NOT
GOOD BUT I LEARNED MY LESSON. I managed to access the Sam database and reset
my password - thus enabling me to log back into the system. This required a
site visit and more importantly it created downtime that shouldn't have
happened if there was a fall back mechanism in place that corrects/prevents
this from happening.



Here is what I think should be done:

Create a second Administrator account on each Web Server. Take it that each
account password is 10 characters long and meets the complexity requirements
dictated by the local security policy - roughly 48 bit in strength. This
account will prevent anything like the incident above from happening.



For the purposes of deploying content and other information, I've created a
hidden share on the server - accessible from our corporate LAN environment
only. I've also created a user called 'ShareUser', specifically used for
accessing this hidden share. I've modified the NTFS and Share permissions to
reflect this user's required access. This will eliminate the administrators
from using the server Administrator credentials to access the we server
share for the future deployment of content to the WS. I also added this
account to the 'Deny Log on Locally' section of the Local Security Policy.



I'm also tempted to create another user specifically for Terminal Services
connections (thus removing the right of an Administrators to log on under a
Terminal Services session) - if they want Admin privileges then let that TS
user escalate to Admin through the usage of an Admin command shell or 'runas
'. I've read a few articles by Keith Brown - pluralsight.com (yep your
still talking to a Network Engineer) with regards to the utilisation of the
thinking that 'least privilege is best'. I agree and want to enforce. A
helpful blog that I found on running the explorer.exe process under a
different user can be found at
http://blogs.msdn.com/aaron_margosis/archive/2004/07/07...



So what you ask am I posting to the newsgroup for? I'm trying to provoke a
response where my (maybe silly, ludicrous and daft) ideas are challenged,
corrected and hopefully improved.



Regards,

Steve.
Anonymous
a b 8 Security
September 22, 2004 7:16:00 PM

Archived from groups: microsoft.public.win2000.security (More info?)

Well steve,
I'll take you up on that challenge.

First off I can understand the mistake of jacking up the
admin pass, it happens. However, the idea of creating a
user account for several services running on your web
servers will be taking steps backwards from the hardening
your trying to accomplish. You should review the user
restriction policy that came out with the server 2003
release. Have a logon for your everyday use and one admin
account that your or only a few people have access to.
utilize the "run as" for administrative uses. The fewer
user accounts you have the safer you are.
Hope this helps

-Brad Causey
Instructor, New Horizons Montgomery AL
MCP, MCDST, MCSA, MCDBA, MCT, A+, Network+, CTT+
>-----Original Message-----
>G/Day Forum,
>
>I'm currently hardening access to all my IIS 5.0 and IIS
6.0 servers, that
>are located within multiple DMZ environments in multiple
locations.
>
>
>
>All servers are Firewalled and are administered through
VPN's using Terminal
>Services/RDP. Recently, I encountered a (self induced)
problem with one of
>these Servers where I mucked up the password change (on
the only
>Administrator account on the server) on one of our
Production Systems - NOT
>GOOD BUT I LEARNED MY LESSON. I managed to access the Sam
database and reset
>my password - thus enabling me to log back into the
system. This required a
>site visit and more importantly it created downtime that
shouldn't have
>happened if there was a fall back mechanism in place that
corrects/prevents
>this from happening.
>
>
>
>Here is what I think should be done:
>
>Create a second Administrator account on each Web Server.
Take it that each
>account password is 10 characters long and meets the
complexity requirements
>dictated by the local security policy - roughly 48 bit in
strength. This
>account will prevent anything like the incident above
from happening.
>
>
>
>For the purposes of deploying content and other
information, I've created a
>hidden share on the server - accessible from our
corporate LAN environment
>only. I've also created a user called 'ShareUser',
specifically used for
>accessing this hidden share. I've modified the NTFS and
Share permissions to
>reflect this user's required access. This will eliminate
the administrators
>from using the server Administrator credentials to access
the we server
>share for the future deployment of content to the WS. I
also added this
>account to the 'Deny Log on Locally' section of the Local
Security Policy.
>
>
>
>I'm also tempted to create another user specifically for
Terminal Services
>connections (thus removing the right of an Administrators
to log on under a
>Terminal Services session) - if they want Admin
privileges then let that TS
>user escalate to Admin through the usage of an Admin
command shell or 'runas
>'. I've read a few articles by Keith Brown -
pluralsight.com (yep your
>still talking to a Network Engineer) with regards to the
utilisation of the
>thinking that 'least privilege is best'. I agree and
want to enforce. A
>helpful blog that I found on running the explorer.exe
process under a
>different user can be found at
>http://blogs.msdn.com/aaron_margosis/archive/2004/07/07...
px
>
>
>
>So what you ask am I posting to the newsgroup for? I'm
trying to provoke a
>response where my (maybe silly, ludicrous and daft) ideas
are challenged,
>corrected and hopefully improved.
>
>
>
>Regards,
>
>Steve.
>
>
>.
>
Anonymous
a b 8 Security
September 22, 2004 11:50:04 PM

Archived from groups: microsoft.public.inetserver.iis.security,microsoft.public.security,microsoft.public.win2000.security,microsoft.public.win2000.termserv.clients,microsoft.public.windows.server.security (More info?)

It makes sense to have more than the built in administrator account. It also makes
sense to rename the built in administrator account and configure it's account
properties to not allow logon though TS as it is the top target of hackers. In
Windows 2003 Servers the built in administrators account can be disabled which I
think is a good idea. That account could still logon in safe mode. Non administrators
can access a server in Remote Administration mode if they have the right to logon
locally [ or through Terminal Services for W2003 ] and have user permissions to the
RDP protocol in Terminal Services Configuration. While hidden shares can be helpful
keep in mind that they are not hard to find and that ultimately you can not restrict
an administrator as an administrator can always take ownership and give themselves
permissions to anything on the computer that they have administrative rights on.
Ipsec filtering policies on a computer can also be used to restrict access to port
3389 used for TS from only authorized IP addresses. Ipsec policies do not require a
reboot when assigned or unassigned. For the IIS 5.0 server be sure to consider
running the IIS Lockdown/URLscan tool if you have not already but I would recommend
that you first backup at least the System State and IIS configuration. Be sure to
read the options closely for the IIS lockdown tool when it comes to what best
describes your IIS server needs. --- Steve

http://www.microsoft.com/downloads/details.aspx?FamilyI...

"The Poster" <nospam@nospam_dontyoudare.net> wrote in message
news:uwQC44KoEHA.1300@TK2MSFTNGP12.phx.gbl...
> G/Day Forum,
>
> I'm currently hardening access to all my IIS 5.0 and IIS 6.0 servers, that
> are located within multiple DMZ environments in multiple locations.
>
>
>
> All servers are Firewalled and are administered through VPN's using Terminal
> Services/RDP. Recently, I encountered a (self induced)problem with one of
> these Servers where I mucked up the password change (on the only
> Administrator account on the server) on one of our Production Systems - NOT
> GOOD BUT I LEARNED MY LESSON. I managed to access the Sam database and reset
> my password - thus enabling me to log back into the system. This required a
> site visit and more importantly it created downtime that shouldn't have
> happened if there was a fall back mechanism in place that corrects/prevents
> this from happening.
>
>
>
> Here is what I think should be done:
>
> Create a second Administrator account on each Web Server. Take it that each
> account password is 10 characters long and meets the complexity requirements
> dictated by the local security policy - roughly 48 bit in strength. This
> account will prevent anything like the incident above from happening.
>
>
>
> For the purposes of deploying content and other information, I've created a
> hidden share on the server - accessible from our corporate LAN environment
> only. I've also created a user called 'ShareUser', specifically used for
> accessing this hidden share. I've modified the NTFS and Share permissions to
> reflect this user's required access. This will eliminate the administrators
> from using the server Administrator credentials to access the we server
> share for the future deployment of content to the WS. I also added this
> account to the 'Deny Log on Locally' section of the Local Security Policy.
>
>
>
> I'm also tempted to create another user specifically for Terminal Services
> connections (thus removing the right of an Administrators to log on under a
> Terminal Services session) - if they want Admin privileges then let that TS
> user escalate to Admin through the usage of an Admin command shell or 'runas
> '. I've read a few articles by Keith Brown - pluralsight.com (yep your
> still talking to a Network Engineer) with regards to the utilisation of the
> thinking that 'least privilege is best'. I agree and want to enforce. A
> helpful blog that I found on running the explorer.exe process under a
> different user can be found at
> http://blogs.msdn.com/aaron_margosis/archive/2004/07/07...
>
>
>
> So what you ask am I posting to the newsgroup for? I'm trying to provoke a
> response where my (maybe silly, ludicrous and daft) ideas are challenged,
> corrected and hopefully improved.
>
>
>
> Regards,
>
> Steve.
>
>
!