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].
