2 ACS (3.02 Win2K) servers running. Server A is master and currently sends database rep. to Server B. All config/user changes are only done on Server A.
We currently point our Cisco VPN boxes for user authentication to Server A, and admin authentication for switches/routers to Server B.
When a user is prompted to change his/her password on a switch/rtr, password is changed successfully, however this info is only sent to Server B not Server A (since authentication is pointing to Server B). Since Server A doesn't get the update, if a situation ever arose that Server B was down, the admins would authenticate through Server A, but won't be able to get in since the password update was never sent to it...because only server A does the replication sending, it isn't configured to receive.
Should I be turning on replication both send/receive on both servers ? Is this good design. Or should I be pointing all my devices to only one server (i.e Server A). The reason we split it out is because its easier to read logs with VPN info going to one and TACACS info going to another server, plus the fact that both servers are being utilized rather than one sitting idle until needed as a backup.
Okay, maybe I'm missing something here, but why don't you just have Server B be the master for replication?
And no, you shouldn't turn on replication for both servers. One, you can't configure bi-directional replication, and two, if you did it manually, you'd still have to worry that someone made a management change on Server A right before you replicated from B. Effectively, this would overwrite the last change in Server A.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...