Web Server - User Access and Priviledges.

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.
2 answers Last reply
More about server user access priviledges
  1. 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.as
    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.
    >
    >
    >.
    >
  2. 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?FamilyID=dde9efc0-bb30-47eb-9a61-fd755d23cdec&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 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.
    >
    >
Ask a new question

Read More

Security Microsoft Servers Windows