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_margosi...2004/07/07.aspx



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.

[ Post a follow-up to this message ]

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 accoun
t
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 whi
ch I
think is a good idea. That account could still logon in safe mode. Non admin
istrators
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 permiss
ions 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 them
selves
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 t
o port
3389 used for TS from only authorized IP addresses. Ipsec policies do not re
quire a
reboot when assigned or unassigned. For the IIS 5.0 server be sure to consid
er
running the IIS Lockdown/URLscan  tool if you have not already but I would r
ecommend
that you first backup at least the System State and IIS configuration. Be su
re to
read the options closely for the IIS lockdown tool when it comes to what bes
t
describes your IIS server needs.  --- Steve

http://www.microsoft.com/downloads/...&displaylang=en

"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 Termin
al
> 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 - NO
T
> GOOD BUT I LEARNED MY LESSON. I managed to access the Sam database and res
et
> 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/prevent
s
> this from happening.
>
>
>
> Here is what I think should be done:
>
> Create a second Administrator account on each Web Server. Take it that eac
h
> account password is 10 characters long and meets the complexity requiremen
ts
> 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 administrator
s
> 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 T
S
> user escalate to Admin through the usage of an Admin command shell or 'run
as
> '.  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 th
e
> 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_margosi...2004/07/07.aspx
>
>
>
> 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.
>
>

[ Post a follow-up to this message ]