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.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.
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.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.
Facebook
Twitter
Instagram