The following are best practices for the CS ACS Server:
Before CS ACS installation, back up the Windows Registries, so that if a new installation of CS ACS or upgrade is needed, and if the Registries are corrupted, you can restore the Registries without re-imaging the operating system.
Before performing any upgrade, always back up the database either via Web or using CLI (csutil). Also perform regular scheduled backups depending on how often you make changes.
Unless it is absolutely necessary, do not install any web server, FTP server, and so on, which may introduce vulnerabilities to the server. Follow the Windows Operating System (Windows OS) Security Guidelines to harden the Windows OS before installing CS ACS.
To attain maximum availability, configure replication and schedule replication at least once in a day (the scheduling depends on how many changes are made to the server).
Protect the CS ACS Server from malicious viruses or worms by using Enterprise Anti-Virus Software and host-based IDSs (CSA Agent for example) and Personal Firewall.
If you have a small LAN environment, then put the CS ACS on your internal LAN and protect it from outside access by using a firewall and the NAS. For high availability, configure database replication to a secondary CS ACS as a backup. However, if you have a large enterprise network, which is geographically dispersed, where access servers may be located in different parts of a city, in different cities, or on different continents, a central ACS may work if network latency is not an issue. But connection reliability over long distances may cause problems. In this case, local ACS installations may be preferable to a central server. If you want to maintain the same database for all the CS ACS servers, database replication or synchronization from a central server may be necessary. Using external user databases such as Microsoft Active Directory (AD) or Lightweight Directory Access Protocol (LDAP) for authentication may complicate this even more. Additional security measures may be required to protect the network and user information being forwarded across the WAN. In this case, the addition of an encrypted connection between regions would be required.
When replication is performed, the services are stopped on the server. Therefore, the server does not perform authentication. To eliminate this downtime, it is always a good idea to configure on the authentication device for failover. To clarify this, assume that you have one CS ACS in the U.S. replicating to a second CS ACS in Canada. Configuring the authenticating devices to try the U.S. and then Canada may not be the best plan. You might consider installing a second local server (in the U.S.) and replicating from the U.S. master to the U.S. slave. The U.S. slave could then replicate to the Canada slave.