Hi Vamsi,
Much of the precise specifics for your environment you will
need to adjust with knowledge of your environment. There are
some general things that you could take into account however.
The biggest in my mind is to make absolutely certain that the
Sharepoint grants are well administered. This is not predefined
with policies in GP (could be done with GP if someone was very
familiar with the peculiarities of sharepoint but it would be tedious)
but is predefined in the Sharepoint admin interface. What you do
want the Sharepoint admin to be absolutely certain they do not
goof up is making sure that these accounts are never granted any
Sharepoint role higher than browser (actually you could likely
get by with collaborator if this is WSS sharepoint). If they are
allowed any authoring role they could mount (or try) an elevation
of scope of access even though limited to only http/https.
You say you have this behind firewall, so the next thing is to
make sure this is correctly allowing only tcp 80/443 with the
outside world. The machines themselves could be further
configured if desired with IPsec in filter mode so that they
allow only these from outside addresses (basically, deny all,
and then grant these with outside IPs, and grant, most simply
all, to internal servers that are necessary : backup, DCs of the
domain and forest root, DNS if different, mail servers, etc..)
This you would implement in the GPO linked to the OU that
holds these sharepoint servers.
Next, and this depends on specifics of your infrastructure, you
may consider placing these accounts in a custom group, and
removing them from Domain Users, and then use this custom
group to grant access to the clustered front-end sharepoint
servers (add where Domain Users exists in user rights and
Users group). You could make this tighter, but if you have
the 80/443 limitation of traffic your exposure is fairly small.
Doing this will need some complete examination/testing as
it depends on where these accounts actually need to flow
(sharepoint does not use Windows integrated accounts when
going off-box to the SQL backend in normal circumstances,
but if there is much custom webparts and/or business logic
involved this may come into play). If your overall environment
allows removal of these from Domain Users, you may have
reduced exposure of other machines (if the unlikely event of
any of them getting ability to hop off the sharepoint servers
into the internal network) dramatically - at least if your
environment has removed Authenticated Users from the Users
group as a standard practice on domain member machines.
If your environment has not taken control over the Authenticated
Users membership in local Users groups issue, you may not
actually gain that much by going to this extra effort.
Other than these, there are only the normal sanity things,
making sure the sharepoint frontends are service minimized,
etc. per normal hardening guidance. One thing to call out
here however for especially attention is to make sure that
rpc over http is not allowed on the sharepoint frontends.
Also, you may want to implement monitoring of these frontends,
and in this something to watch that is easy to overlook is whether
local profiles ever get created and if the logon type is ever other
than network logon for these accounts on the sharepoint servers.
I am sure there are more things that could be brought to bear,
but right now I am sort of at the end of what comes to mind now.
Other than IPsec filter if used, user rights and membership in
Users group, the only things of this that are done via GPO are
those that are normal hardening for an IIS box (services minimized,
etc..).
