Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Win9x Security on Win 2000 Server
- Thread starter Bluebull
- Start date
Ah, a topic probably worthy of a book (or at least a long chapter)! I manage a network at a middle school (grades 6-8, roughly ages 11-14) in California. Several suggestions that have worked for me:
1. Use the Win9x Policy Editor to establish a few restrictions.
2. Use a good tweaking program (I play with lots, but X-Setup is the single most comprehensive one I've found) to tighten things further. Be sure to prevent the ability to access a DOS prompt and the Run command.
3. Disable local password cacheing, require server-based logon validation, and use static IP addresses on your 9x boxes (if you use DHCP under Win9x, disconnecting from the network provides an easy way around validation requirements).
4. Disable booting from removable drives in BIOS if possible, and password-protect the ability to alter BIOS settings.
5. Set the hidden attribute on files and folders you don't want users messing with, be sure users by default can't see hidden files/folders, and disable their ability to change this (see #2 above).
6. Create a backup copy of System.dat (the HKLM registry settings) on each machine, and have your Autoexec.bat remove System, Hidden, and ReadOnly attributes on System.dat and restore from your backup on each reboot.
7. Tweak the default user account so that it can't do anything (nothing on the Start Menu, no Run, no Find, nothing on the Desktop, etc.). Then set a program that logs the user out in the default StartUp group, or, better, through the Run key in the Registry.
8. Create individual user accounts which they must use to log in to the system, and keep track of user logins. I log user name, time, and date on individual machines, and machine name, time, and date in a per-user file on the server, so I can see who's been on a particular machine if there's a problem with it, and what machine(s) a particular user has been on if I have reason to think (s)he's been up to something!
9. Use a scripting language (I use KixTart) to modify the user environment. Among other things, this extends some OU functionality to Win9x. For instance, our students must have a signed permission slip before they can use the internet, so I've created an Internet Users group. I then use this in my scripts to block or allow internet access on a per-user basis.
10. Be sure to create a well-protected Administrator account on each machine that you can use for troubleshooting/updating/etc. Just remember that when YOU want to change your system configuration or install updates, you need to update your "master image" System.dat backup on each box if you follow my suggestion #6 above. Otherwise, your desired changes will be undone, just like students' undesireable ones!
11. Set clear, written rules about what is and is not permitted, and make students (and, ideally, their parents) sign something acknowledging their acceptance. Then hold students accountable for their actions--it doesn't take making an example of too many for others to decide to behave!
I'm sure there's more, but this should give you a good start. It's a lot of work to set up, but not so hard to maintain once it's in place. I've found there's almost nothing that can't be done with a login script, so that's a real key for me, both in implementing restrictions, and in making system changes down the road.
Hope this helps!
Joe
1. Use the Win9x Policy Editor to establish a few restrictions.
2. Use a good tweaking program (I play with lots, but X-Setup is the single most comprehensive one I've found) to tighten things further. Be sure to prevent the ability to access a DOS prompt and the Run command.
3. Disable local password cacheing, require server-based logon validation, and use static IP addresses on your 9x boxes (if you use DHCP under Win9x, disconnecting from the network provides an easy way around validation requirements).
4. Disable booting from removable drives in BIOS if possible, and password-protect the ability to alter BIOS settings.
5. Set the hidden attribute on files and folders you don't want users messing with, be sure users by default can't see hidden files/folders, and disable their ability to change this (see #2 above).
6. Create a backup copy of System.dat (the HKLM registry settings) on each machine, and have your Autoexec.bat remove System, Hidden, and ReadOnly attributes on System.dat and restore from your backup on each reboot.
7. Tweak the default user account so that it can't do anything (nothing on the Start Menu, no Run, no Find, nothing on the Desktop, etc.). Then set a program that logs the user out in the default StartUp group, or, better, through the Run key in the Registry.
8. Create individual user accounts which they must use to log in to the system, and keep track of user logins. I log user name, time, and date on individual machines, and machine name, time, and date in a per-user file on the server, so I can see who's been on a particular machine if there's a problem with it, and what machine(s) a particular user has been on if I have reason to think (s)he's been up to something!
9. Use a scripting language (I use KixTart) to modify the user environment. Among other things, this extends some OU functionality to Win9x. For instance, our students must have a signed permission slip before they can use the internet, so I've created an Internet Users group. I then use this in my scripts to block or allow internet access on a per-user basis.
10. Be sure to create a well-protected Administrator account on each machine that you can use for troubleshooting/updating/etc. Just remember that when YOU want to change your system configuration or install updates, you need to update your "master image" System.dat backup on each box if you follow my suggestion #6 above. Otherwise, your desired changes will be undone, just like students' undesireable ones!
11. Set clear, written rules about what is and is not permitted, and make students (and, ideally, their parents) sign something acknowledging their acceptance. Then hold students accountable for their actions--it doesn't take making an example of too many for others to decide to behave!
I'm sure there's more, but this should give you a good start. It's a lot of work to set up, but not so hard to maintain once it's in place. I've found there's almost nothing that can't be done with a login script, so that's a real key for me, both in implementing restrictions, and in making system changes down the road.
Hope this helps!
Joe
- Status
Similar threads
- Locked
- Question