You've explained how to protect the built-in Administrator account. Is it OK to create and use other local account on servers?
To review my recommendations for protecting a computer's Administrator account, see Access Denied, "Securing the Administrator Account," August 2005, InstantDoc ID 46877. As for local user and group accounts, if the computer is a member of a domain, few situations require them, and there's no escaping the security risks and management complications that arise from them.
Let's talk about local users first. Local user account password hashes are stored in the local SAM where they're vulnerable to arbitrary replacement by someone with physical access to the computer using a tool such as Ntpasswd (for more information about this tool, or to download it, go to http://home.eunet
.no/~pnordahl/ntpasswd). Also, Windows authenticates local accounts by using the weaker NT LAN Manager (NTLM) authentication protocol instead of Kerberos. But more importantly, local user accounts defeat one of the most important purposes of domains, which is to help ease maintenance of user accounts. If you begin creating local accounts for actual human users (as opposed to service or application accounts), users are going to end up with multiple accounts. When a user with multiple local accounts leaves the company or changes jobs, the risk of an account that should be disabled remaining functional is high. Furthermore, attacks on local accounts are logged in the local server's Security log--not in the domain controller's (DC's) log--so if you use local accounts, you must monitor the local system logs. Even in well-maintained domains that have only one set of accounts, I regularly find dormant accounts of departed users. Imagine the situation in domains that have user accounts on every server on the network.
The main problem with local groups is maintenance and access control verification. If you control all access through groups and use only domain groups, you can easily ascertain which resources a user can access without leaving the Microsoft Management Console (MMC) Active Directory Users and Groups snap-in by simply checking the user's group membership. However, if you're using local groups on member servers to control access to some resources, such access won't show up when you look at the user's account in Active Directory Users and Groups.