WK2 AD Security

G

Guest

Hi all

We have a W2K network and need to implement better security on the workstations. What would be the best bet? Do I use AD and import a sec template (make the necessary adjustments) and apply it at the domain level for all users?

thanks in advance
 
S

Steven L Umbach

What exactly are you trying to secure as that is a huge topic? Security
templates are comptuer configuration and apply to the compatible computers
and everyone who logs onto them. For a domain, it is easiest and best to
make changes to security and Group Policy at the domain or Organizational
Unit level. Password/account policy can only be applied at the domain policy
level and will apply equally to all domain users. Be careful with changing
security options as you can lock out computers [especially "downlevel"
clients] with incompatbile settings and it is best to try a few test
computers or better yet isolated test domain if possible. The link below may
help. --- Steve


http://www.microsoft.com/technet/Security/prodtech/win2000/win2khg/05sconfg.mspx

wetbehindears said:
Hi all,

We have a W2K network and need to implement better security on the
workstations. What would be the best bet? Do I use AD and import a sec
template (make the necessary adjustments) and apply it at the domain level
for all users?
 
G

Guest

Steve

We have about 55 user with all W2K workstations. We are trying to tighten up security with logging in. Right now we have absolutely no security what so ever and my responsibility is to change that.
 
R

Robert Moir

wetbehindears said:
Steve,

We have about 55 user with all W2K workstations. We are trying to
tighten up security with logging in. Right now we have absolutely no
security what so ever and my responsibility is to change that.

Ok,
You might want to set yourself (and tell us if you want our help) some clear
objectives

(e.g. users should be logged onto a workstation with /these/ rights,
password policies should correspond to /that/ list, etc).

With that in mind, you can maybe arrange users and computers into various
OUs based on which policies you'd like to apply to which sets of users or
computers (e.g. the accounts dept in your company, for example, may need
more rights than you'd normally give them as they need to run a legacy app
that doesn't behave well on a network), and then you work from there.

On an already established network which you presumably don't want to disrupt
too much, applying a pre-cooked template without a lot of testing is a
recepie for disaster imho.

--
--
Rob Moir, Microsoft MVP for servers & security
Website - http://www.robertmoir.co.uk
Virtual PC 2004 FAQ - http://www.robertmoir.co.uk/win/VirtualPC2004FAQ.html

Kazaa - Software update services for your Viruses and Spyware.
 
S

Steven L Umbach

OK. Well the link I referred to should be a good start on account policy but
below are some major points.

-- If not done already, create an account for each user in AD Users and
Computers and for regular users leave them in just the default users group
and make sure they are not in the local administrators group on their
workstation via individual or group membership unless you have a real need
for them to be in that group.

-- Check the membership of the domain admins, admimistrators, schema
anministrators, and enterprise admins groups [assuming in a domain] to make
sure only authorized members are in that group and then have all
administrators in the domain change their passwords and never logon to an
"untrusted" domain machine with an account that has admin credentials in the
domain as there may be keyboard loggers etc installed there. Make sure the
guest account is disabled on the domain controller in AD Users and Computers
and on any domain machine unless you specifically want it enabled. The guest
account being enabled can let ANYONE access a share without authentication
if the resource has the everyone group included in effective permissions.

-- Create a password policy suitable for your needs but consider enabling
"password complexity" and setting reasonable maximum age for passwords and
implement a password lockout policy with threshold of no less than ten
attempts and a lockout period of say ten minutes. I do not recommend setting
maximum password length to more than seven in your policy. Inform users of
impending new password policy including examples of what new passwords are
acceptable and when the deadline is for the change.

-- Check user account properties in AD Users and Computers to make sure
their account password is NOT set to password never expires unless that is
what you want as they will not be subject to maximum password age then. Also
consider limiting what domain computers they can logon to in their account
properties if it suits your businees needs.

-- In the appropriate security policy - domain/OU/local configure the user
rights assingments under security settings/local policies/user rights, for
the right users/groups to have the user right for logon locally and access
this computer from the network. If normal users have no need to access other
domain worksations, remove the everyone/users group from access this
computer from the network so that only administrators and other priviliged
accounts have access. Do NOT change the "access this computer from the
network" setting on the domain controller or in DC Security Policy. Keep in
mind that in Local Security Policy the "effective" setting is what applies
as domain/OU policy can override the same defined setting in local policy.

-- If users need access to shares. Check the share permissions to see that
they are not excessive. By default the everyone group has full control on a
newly created share. Usually you want to change that to users with just read
or read/change.Ntfs permissions also work in conjunction with share
permissions for network users.

-- Enable auditing of account logon events on your domain controller and
logon events for success and failure on any domain computers offering shares
to domain users being sure to increase the size of the security log to at
least 5MB. You can view the security log in Event Viewer.


-- Let us know if you need more info, but this should get you off to a good
start. -- Steve

wetbehindears said:
Steve,

We have about 55 user with all W2K workstations. We are trying to tighten
up security with logging in. Right now we have absolutely no security what
so ever and my responsibility is to change that.
 
S

Steven L Umbach

Have fun, but I should add [got distracted on last post] that don't
underestimate the need for physical security for your computers, particulary
servers and the domain controller. While locked in a room is nice, at least
a heavy duty case with locked access to drives is necessary. Any user that
can access a computer floppy/cdrom and boot from it can compromise any
compter easily with free downloadable software becoming the local
administrator and possibly extracting data and user passwords or purposely
destroying or copying data. While that may be bad on a workstation, it can
be devastating on a domain controller or critical server. In general you
want your workstations also configured to boot from only the hard drive and
then password protect cmos settings and have a lock on those cases also if
possible. If USB ports are not needed, disable them also in cmos [pen/flash
drives] and disable autorun on the cdrom drive. Verify that there are no
local user accounts on the domain computers unless they are authorized. ---
Steve

wetbehindears said:
Thanks! Will give it a shot on a few test dummies first. Enjoy the
weekend!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top