įinally, configure a password policy for your or a OU so that users using local user accounts have to enter a long (like the max 255), complex password and they have to change every day and enforce password history using its maximum value to prevent them from re-using their old passwords. ![]() You might push a script to remote all local user accounts at startup. Log On Locally approach should be tested on a test network beforehandĪnother approach could be to turn off USB ports and CD/DVD drives from the BIOS along with adding an admin only password if your BIOS supports such. So one solution could be to build a GPO to Disable all the local user accounts from each workstation that has them and maybe use the GPO deny logon locally (Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment) to prevent anyone except domain users from logging on to desktop computers targeted by such policy. Personally my thoughts were if you cant get in then its probably a good time for a rebuild anyway, but looking at the M$ as if I were on the inside, I guess it comes down to "Your damned if you do and Your damned if you don't" what if you take that "flaw" out and there is an computer owner change or an administrator change that does not have the information to get into an administrator level account, they they are forced to rebuild/reimage the device for something that could have been fixed easily if they had a way to gain entry, the "flaw" was designed to have an OS disk that not many people are just carrying around. What we see as a flaw like this security nuance, has some at M$ looking at it as. Some of the responses I've seen have had me go hmmmmm. ![]() Its a good question? I've been doing beta tests for M$ products for some time and questions just like yours I've brought up along with other beta testers.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |