There is a common security recommendation that one will improve domain or server security by renaming the builtin Administrator account. Some state this is a dramatic improvement in security. Bull! Supposedly by changing the name, you can hide this powerful account and improve security. NO. Names mean nothing. All objects in NT have ID numbers. All accounts have SIDs. The SIDs can not be hidden. There are baby hacker tools which automate the process of determining which account is the builtin Administrator account. See SIDs for more information about SIDs.

Another common security recommendation is to emasculate it (take its powers away) and monitor it closely for attacks. NO. NO. NO. This is the only account that can never be locked out from the console. Account lockout policies do not apply to this account when logging on from the console. I have seen commerical security tools in the hands of careless auditors, security and systems personnel lock out all accounts by attempting brute force dictionary attacks on account domains which have account lockout set as a security feature. The only account not locked out from the console was the builtin Administrator account. If the Administrator account had been emasculated and it could not unlock accounts - OUCH. If an account lockout policy is not set, go ahead. From a security perspective, its all down the drain anyway. Otherwise, you set up a terrible Denial Of Services scenario.

What I do recommend is setting the password lockout policy to 3-5 bad attempts and then use passprop.exe from the resource kit to change the Adminstrator account so that it too will be locked out after the set number of bad password attempts (never fear - this only applies remotely - the builtin administrator account can never be locked out from the console).

There is an interesting issue which involving the Administrator account of domains and workstations which are members of that domain. When you add a workstation to a domain, the logon dialog changes the default authenication from the local workstation to the domain. A side-effect is that workstation users attempting to login to their local workstation administrator account will accidently attempt to login to the domain administrator account if they are careless and do not change the default authenicator from the domain to the local workstation. The result:

If you have login security enabled, you will see login failure records on the domain controller which looks like attempts to break into the domain. If you have enabled passprop, after three of these attempts, you get the domain admin account locked out from remote access. So, to avoid hassles, my recommendation is to go ahead and change the builtin administrator account name but only to prevent the accidental lockouts caused by putzes on workstations attempting to access the same named account. [no - I haven't changed my mind - all the baby hacker tools will find it under its new name if they want to hack it. Passprop blocks those attempts. Renaming prevents the accidental lockouts].

A must have for NT administrators in corporate or governmental organizations or anyone being audited by a large outside audit firm.
It is not a secrets type guide but it has excellent sound advice and its used by PriceWaterhouse's auditors as a guide.

Excellent!!!! Scary. Hack Win9x, NT, Netware, Unix, Web, ...