In the article Mike says you need to run gpupdate from the comand line in Windows 2000. gpupdate is a Windows XP and Server 2003 tool.
To achieve the same effect in Windows 2000 you need to use the secedit tool with the /refreshpolicy switch.
Discussion on:
View:
Show:
Good catch Pete. You are correct in saying that gpudate is the replacement for secedit on XP & 2003 systems. I've gotten so used to working from my 2003 member server, that I should have done a dry run on the actual 2000 server itself.
I read another suggestion awhile back to set up a new user with full admin rights and leave the administrator account but strip all of it's rights. Any thoughts?????
In many circles the act of removing administrative rights to the user "administrator" is often a lure for potential intrusions. With knowledge that this account is targeted, administrators watch for accesses to this account and sniff the packets to aid in the identification and capture of the intruder.
Yes, we wait and watch!
Yes, we wait and watch!
or any number of methods using the MMC or Group Policy Management Console.
It would take too much space here to give a full proceedure; I suggest buying an MSCE book or check the TechNet site at Microsoft.
It would take too much space here to give a full proceedure; I suggest buying an MSCE book or check the TechNet site at Microsoft.
We currently do this. Having a way to monitor/detect those attacks against the "admin" account is key. We use event monitoring to a SIM tool with rules to match and alert.
This technique may provide early warning against "noisy" attackers, but this won't fool the careful ones. The other steps should be implemented carefully.
This technique may provide early warning against "noisy" attackers, but this won't fool the careful ones. The other steps should be implemented carefully.
There are more users of WinXP than Win 2000 and Win XPserver, so how does this affect us?
There are more users of WinXP than Win 2000 and Win XPserver, so how does this affect us?
Speaking fromlocal experience,I would like to note the following:
1) All XP computers come with the Administrator account with the password set to null
2) Of the 50-75 machines a month we get in from the public to "repair" probably 95% (guestimate, not hard numbers!) still have not set a password to this account.
3) The above fact proves useful for a technician working on a computer for which the customer forgot to provide passwords for, however, it certainly makes a mockary of the whole password concept.
4) In my experience, kids are aware of the above facts and will use this information to bypass security or protections which partents or teachers have installed.
5) In a large number of managed networks I encounter, the Local Admins did not realize that by attaching a computer to a domain, they did nothing about locking out or otherwise protecting the local Administrator account.
So to put it simply, at absolute minimum, don't forget to password protect this account at the very least.
1) All XP computers come with the Administrator account with the password set to null
2) Of the 50-75 machines a month we get in from the public to "repair" probably 95% (guestimate, not hard numbers!) still have not set a password to this account.
3) The above fact proves useful for a technician working on a computer for which the customer forgot to provide passwords for, however, it certainly makes a mockary of the whole password concept.
4) In my experience, kids are aware of the above facts and will use this information to bypass security or protections which partents or teachers have installed.
5) In a large number of managed networks I encounter, the Local Admins did not realize that by attaching a computer to a domain, they did nothing about locking out or otherwise protecting the local Administrator account.
So to put it simply, at absolute minimum, don't forget to password protect this account at the very least.
set up an admin account for yourself, with a very good password. (Note, this means you will have two accounts. Your everyday account, which is a normal user. and an admin account, which you only use for admin purposes (no web browsing or email reading).
Then, disable the built-in administrator account. It is no longer avialable as a target, but if you should need for some strange reason to get to it, you can boot to safe mode and login in to it, even though it is disabled.
Then, disable the built-in administrator account. It is no longer avialable as a target, but if you should need for some strange reason to get to it, you can boot to safe mode and login in to it, even though it is disabled.
The myth should really be "JUST renaming this account prevents hackers from finding it", correct? As long as you disable SID enumeration, then a renamed Admin account isn't identifiable as the old Admin account.
As far as Win 2003, I'm a bit confused by its solution. Win 2000's solution is renaming, but now Win 2003 has jumped to disabling. You can still simply disable SID enumeration, rename the Admin account, and still achieve the same level of security as disabling the original Admin account and creating a new admin level account, correct? If there is an advantage to disabling the original admin account over disabling SID enumeration and renaming the original account, it isn't apparent from this article. I'm left wondering what advantages one has over the other.
As far as Win 2003, I'm a bit confused by its solution. Win 2000's solution is renaming, but now Win 2003 has jumped to disabling. You can still simply disable SID enumeration, rename the Admin account, and still achieve the same level of security as disabling the original Admin account and creating a new admin level account, correct? If there is an advantage to disabling the original admin account over disabling SID enumeration and renaming the original account, it isn't apparent from this article. I'm left wondering what advantages one has over the other.
Disabling the built-in admin account was one of the top security features requested for 2003. There are some instances where you might have to allow anonymous users to connect (such as to a SQL Server) and you can't disable Allow Anonymous SID/Name Translation.
In that instance you would definitely want to disable the old admin account and create a new one (not in that order of course).
In that instance you would definitely want to disable the old admin account and create a new one (not in that order of course).
I thought disabling anonymous SID enumeration was effective only for the methods used by MS utilities using anonymous SID enumeration.
Third-party tools (including all that run on Linux) can use other methods to anonymously enumerate SIDs.
In other words you are safe from hackers using MS supplied tools. So don't get a false sense of security from renaming the default accounts and disabling anonymous SID enumeration.
When you couple the above fact with the sometimes severe productivity impact of disabling anonymous SID enumeration, it changes the equation in deciding whether to disable the function.
Your best mitigation for this is to block this type of traffic from unathorized locations. Definitely at the perimeter and also WAPs and even internally between some subnets if you have your topology laid out right. MS networking, SMB, CIFS, (all basically the same set of services) and many other non-MS network services were never designed with the right level of security to operate exposed to the hostile network we know as the internet. All such services' traffic should be blocked at least at the perimeter.
Third-party tools (including all that run on Linux) can use other methods to anonymously enumerate SIDs.
In other words you are safe from hackers using MS supplied tools. So don't get a false sense of security from renaming the default accounts and disabling anonymous SID enumeration.
When you couple the above fact with the sometimes severe productivity impact of disabling anonymous SID enumeration, it changes the equation in deciding whether to disable the function.
Your best mitigation for this is to block this type of traffic from unathorized locations. Definitely at the perimeter and also WAPs and even internally between some subnets if you have your topology laid out right. MS networking, SMB, CIFS, (all basically the same set of services) and many other non-MS network services were never designed with the right level of security to operate exposed to the hostile network we know as the internet. All such services' traffic should be blocked at least at the perimeter.
last time I built a machine to ghost-cast out, it asked me for an Administrator password during the initial setup, during that "just out of the box period".
Am I missing something here?
Am I missing something here?
If I remember correctly, a WinXP installation will prompt you to enter a password for Administrator, but it does not *require* one.
I've accidentally got click-happy and left it blank at first, but I don't recall ever seeing any message like: "You should NEVER leave the admin password blank!!! Are you really sure?"
I've accidentally got click-happy and left it blank at first, but I don't recall ever seeing any message like: "You should NEVER leave the admin password blank!!! Are you really sure?"
For this reason you can employ the use of RIS, Sysdiff, and/or Answer files to completely automate the process. The various Windows NOS releases and Resource Kits give you a basic "MSBATCH.INF" or "WINNT.SIF" file template for this purpose. A quick review of it's function and varibles/parameters can demonstrate its usefullness.
I have used these two files for years boasting a full slient install of WXP Pro in about 30 minutes hands off.
Edit the WINNT.SIF file to include custom Product Keys, ComputerName, Company, Branding, Networking, etc. Edit via Notepad and save to a floppy disk. Then, change the BIOS settings to BOOT from a CDROM drive. Place the floppy disk in drive A [making sure that it contains the WINNT.SIF ANSI file format] and restart the PC with the Windows CDROM and hit any key when prompted to boot from the CD. Watch as Windows Textmode setup will access the floppy drive and read the WINNT.SIF file contents and write the auto setup parameters into a new file $$TXTSETUP.SIF$$ upon reformatting the first available active drive [one possible option!].
A very slick & speedy method!
By the way, I did not provide any step-by-steps herein - but enough info to spur on some of your own research into using this method...check it out!
I have used these two files for years boasting a full slient install of WXP Pro in about 30 minutes hands off.
Edit the WINNT.SIF file to include custom Product Keys, ComputerName, Company, Branding, Networking, etc. Edit via Notepad and save to a floppy disk. Then, change the BIOS settings to BOOT from a CDROM drive. Place the floppy disk in drive A [making sure that it contains the WINNT.SIF ANSI file format] and restart the PC with the Windows CDROM and hit any key when prompted to boot from the CD. Watch as Windows Textmode setup will access the floppy drive and read the WINNT.SIF file contents and write the auto setup parameters into a new file $$TXTSETUP.SIF$$ upon reformatting the first available active drive [one possible option!].
A very slick & speedy method!
By the way, I did not provide any step-by-steps herein - but enough info to spur on some of your own research into using this method...check it out!
I don't think this will work on SBS 2003, but I haven't tested it to find out for sure. Any time you need to change a component of SBS, it requires you to log in using the original administrator account.
Anyone have any experience with this?
Anyone have any experience with this?
We generally follow renaming of the Administrator account follwed by
1. Lockout on failed No of logins.
2. Disable enumeration of SID.
3. Apply it accross the domain.
4. Exterme control on policy changes.
1. Lockout on failed No of logins.
2. Disable enumeration of SID.
3. Apply it accross the domain.
4. Exterme control on policy changes.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
