Logging issue in CiscoSecure ACS 4.2
Bookmark this page:
 Yahoo!
 Google
 Windows Live
 del.icio.us
 digg
 Netscape
|
|
|||||||||||||
|
Posted by Daniel Alex on May 5, 2008, 4:08 am
Please log in for more thread options Good day everyone, I have a problem with ACS's logging and I hope anyone who had similar experience could help me on this issues. We have two ACS on our network (primary & secondary). All our dial-up customer are authenticated on primary ACS and the secondary ACS is only serves as a backup ONLY when the primary ACS is fail or out of service. User databases and groups including certain security & network configurations are replicated to secondary ACS on daily basis (every 24 hours). The logging for configuration for each ACS reports (Failed Attempts, Passed Authentication, RADIUS Accounting and etc) are also configured to daily basis. So far, the operational status for both are fine but I found out the logging files on secondary ACS has an extra ACS report which ends with "(HH-MM-SS).csv", for example, RADIUS Accounting 2008-05-02(00-00-33).csv. This happens whenever the secondary ACS are in replication mode and receives updates from primary ACS after every 24 hours. In a day, the secondary ACS generates two identical ACS reports, with and without '(HH-MM-SS)'. Example ACS reports generated by secondary ACS; RADIUS Accounting 2008-05-02.csv RADIUS Accounting 2008-05-02(00-00-33).csv It only happens on secondary ACS but not in primary ACS, although in my understanding, whenever ACS in replication mode, all ACS services will be temporarily suspended and return to operational once the replication mode is completed. Our billing software is customized only to process those normal ACS reports (logs) but not those ends with "(HH-MM-SS).csv" and we have to manually extrack the content and merge it with the current reports. We did not having this problem in our previous ACS version 3.2 until we had upgraded our service recently. Question: How do I overcome this issue? Any workaround? Thank you very much! Regards, Daniel | |||||||||||||
|
Posted by Thrill5 on May 5, 2008, 11:41 pm
Please log in for more thread options secondary. When done this way, as each message is logged, it is immediately sent to the secondary server, and both logs are always up to date. Don't remember how to do this off the top of my head and if you don't find where to set this up, post a reply. | |||||||||||||
|
Posted by Daniel Alex on May 6, 2008, 6:18 am
Please log in for more thread options Hi,
I still need the log replication. However, I want to know how to prevent the secondary ACS to produce similar log files (as shown below) after performing replication. RADIUS Accounting 2008-05-02.csv RADIUS Accounting 2008-05-02(00-00-33).csv It always happened whenever the primary ACS performed replication towards secondary ACS. I wonder, after the replication complete on secondary ACS, why it needs to create a new log instead of using the current log at that day. Thanks. > Disable log replication, and configure the primary to also log to the
> secondary. When done this way, as each message is logged, it is > immediately sent to the secondary server, and both logs are always up to > date. Don't remember how to do this off the top of my head and if you > don't find where to set this up, post a reply. > >> Hi All,
>> >> Good day everyone, I have a problem with ACS's logging and I hope anyone >> who had similar experience could help me on this issues. >> >> We have two ACS on our network (primary & secondary). All our dial-up >> customer are authenticated on primary ACS and the secondary ACS is only >> serves as a backup ONLY when the primary ACS is fail or out of service. >> User databases and groups including certain security & network >> configurations are replicated to secondary ACS on daily basis (every 24 >> hours). The logging for configuration for each ACS reports (Failed >> Attempts, Passed Authentication, RADIUS Accounting and etc) are also >> configured to daily basis. So far, the operational status for both are >> fine but I found out the logging files on secondary ACS has an extra ACS >> report which ends with "(HH-MM-SS).csv", for example, RADIUS Accounting >> 2008-05-02(00-00-33).csv. This happens whenever the secondary ACS are in >> replication mode and receives updates from primary ACS after every 24 >> hours. >> >> In a day, the secondary ACS generates two identical ACS reports, with and >> without '(HH-MM-SS)'. Example ACS reports generated by secondary ACS; >> >> RADIUS Accounting 2008-05-02.csv >> RADIUS Accounting 2008-05-02(00-00-33).csv >> >> It only happens on secondary ACS but not in primary ACS, although in my >> understanding, whenever ACS in replication mode, all ACS services will be >> temporarily suspended and return to operational once the replication mode >> is completed. Our billing software is customized only to process those >> normal ACS reports (logs) but not those ends with "(HH-MM-SS).csv" and we >> have to manually extrack the content and merge it with the current >> reports. We did not having this problem in our previous ACS version 3.2 >> until we had upgraded our service recently. >> >> Question: How do I overcome this issue? Any workaround? >> >> Thank you very much! >> >> Regards, >> >> Daniel >> >
> | |||||||||||||
|
Posted by Thrill5 on May 6, 2008, 8:16 pm
Please log in for more thread options You can't prevent this from happening when you replicate the log FILES, but
you can when you configure the primary also log to the secondary. > Hi,
> > I still need the log replication. However, I want to know how to prevent > the secondary ACS to produce similar log files (as shown below) after > performing replication. > > RADIUS Accounting 2008-05-02.csv > RADIUS Accounting 2008-05-02(00-00-33).csv > > It always happened whenever the primary ACS performed replication towards > secondary ACS. I wonder, after the replication complete on secondary ACS, > why it needs to create a new log instead of using the current log at that > day. > > Thanks. > >> Disable log replication, and configure the primary to also log to the
>> secondary. When done this way, as each message is logged, it is >> immediately sent to the secondary server, and both logs are always up to >> date. Don't remember how to do this off the top of my head and if you >> don't find where to set this up, post a reply. >> >>> Hi All,
>>> >>> Good day everyone, I have a problem with ACS's logging and I hope anyone >>> who had similar experience could help me on this issues. >>> >>> We have two ACS on our network (primary & secondary). All our dial-up >>> customer are authenticated on primary ACS and the secondary ACS is only >>> serves as a backup ONLY when the primary ACS is fail or out of service. >>> User databases and groups including certain security & network >>> configurations are replicated to secondary ACS on daily basis (every 24 >>> hours). The logging for configuration for each ACS reports (Failed >>> Attempts, Passed Authentication, RADIUS Accounting and etc) are also >>> configured to daily basis. So far, the operational status for both are >>> fine but I found out the logging files on secondary ACS has an extra ACS >>> report which ends with "(HH-MM-SS).csv", for example, RADIUS Accounting >>> 2008-05-02(00-00-33).csv. This happens whenever the secondary ACS are in >>> replication mode and receives updates from primary ACS after every 24 >>> hours. >>> >>> In a day, the secondary ACS generates two identical ACS reports, with >>> and without '(HH-MM-SS)'. Example ACS reports generated by secondary >>> ACS; >>> >>> RADIUS Accounting 2008-05-02.csv >>> RADIUS Accounting 2008-05-02(00-00-33).csv >>> >>> It only happens on secondary ACS but not in primary ACS, although in my >>> understanding, whenever ACS in replication mode, all ACS services will >>> be temporarily suspended and return to operational once the replication >>> mode is completed. Our billing software is customized only to process >>> those normal ACS reports (logs) but not those ends with "(HH-MM-SS).csv" >>> and we have to manually extrack the content and merge it with the >>> current reports. We did not having this problem in our previous ACS >>> version 3.2 until we had upgraded our service recently. >>> >>> Question: How do I overcome this issue? Any workaround? >>> >>> Thank you very much! >>> >>> Regards, >>> >>> Daniel >>> >>
>> >
| |||||||||||||
|
Posted by Daniel Alex on May 6, 2008, 10:07 pm
Please log in for more thread options Okay. I will test it. Thanks.
> You can't prevent this from happening when you replicate the log FILES,
> but you can when you configure the primary also log to the secondary. > >> Hi,
>> >> I still need the log replication. However, I want to know how to prevent >> the secondary ACS to produce similar log files (as shown below) after >> performing replication. >> >> RADIUS Accounting 2008-05-02.csv >> RADIUS Accounting 2008-05-02(00-00-33).csv >> >> It always happened whenever the primary ACS performed replication towards >> secondary ACS. I wonder, after the replication complete on secondary ACS, >> why it needs to create a new log instead of using the current log at that >> day. >> >> Thanks. >> >>> Disable log replication, and configure the primary to also log to the
>>> secondary. When done this way, as each message is logged, it is >>> immediately sent to the secondary server, and both logs are always up to >>> date. Don't remember how to do this off the top of my head and if you >>> don't find where to set this up, post a reply. >>> >>>> Hi All, >>>> >>>> Good day everyone, I have a problem with ACS's logging and I hope >>>> anyone who had similar experience could help me on this issues. >>>> >>>> We have two ACS on our network (primary & secondary). All our dial-up >>>> customer are authenticated on primary ACS and the secondary ACS is only >>>> serves as a backup ONLY when the primary ACS is fail or out of service. >>>> User databases and groups including certain security & network >>>> configurations are replicated to secondary ACS on daily basis (every 24 >>>> hours). The logging for configuration for each ACS reports (Failed >>>> Attempts, Passed Authentication, RADIUS Accounting and etc) are also >>>> configured to daily basis. So far, the operational status for both are >>>> fine but I found out the logging files on secondary ACS has an extra >>>> ACS report which ends with "(HH-MM-SS).csv", for example, RADIUS >>>> Accounting 2008-05-02(00-00-33).csv. This happens whenever the >>>> secondary ACS are in replication mode and receives updates from primary >>>> ACS after every 24 hours. >>>> >>>> In a day, the secondary ACS generates two identical ACS reports, with >>>> and without '(HH-MM-SS)'. Example ACS reports generated by secondary >>>> ACS; >>>> >>>> RADIUS Accounting 2008-05-02.csv >>>> RADIUS Accounting 2008-05-02(00-00-33).csv >>>> >>>> It only happens on secondary ACS but not in primary ACS, although in my >>>> understanding, whenever ACS in replication mode, all ACS services will >>>> be temporarily suspended and return to operational once the replication >>>> mode is completed. Our billing software is customized only to process >>>> those normal ACS reports (logs) but not those ends with >>>> "(HH-MM-SS).csv" and we have to manually extrack the content and merge >>>> it with the current reports. We did not having this problem in our >>>> previous ACS version 3.2 until we had upgraded our service recently. >>>> >>>> Question: How do I overcome this issue? Any workaround? >>>> >>>> Thank you very much! >>>> >>>> Regards, >>>> >>>> Daniel >>>> >>> >>> >>
>
> | |||||||||||||
| Similar Threads | Posted |
| Logging issue in CiscoSecure ACS 4.2 | May 5, 2008, 4:08 am |
| CiscoWorks and CiscoSecure ACS | January 24, 2006, 2:33 am |
| MAC authentication on Linksys switches with CiscoSecure ACS 4.2 | May 8, 2008, 6:32 am |
| CiscoSecure ACS v. 3.3 user TACACS+ password choice defaults not LDAP | April 18, 2007, 2:22 pm |
| logging buffered vs. logging history | February 5, 2006, 8:57 am |
| logging w/ PIX / ASA | January 4, 2006, 11:43 am |
| VPN logging | April 6, 2006, 7:58 am |
| logging PIX | August 15, 2006, 10:20 am |
| PIX Logging | October 19, 2006, 11:40 pm |
| logging | October 25, 2006, 12:21 pm |
| IOS-VPN and logging | October 11, 2007, 6:29 am |
| Remotely logging in | September 16, 2005, 4:38 pm |
| remotely logging in | September 16, 2005, 6:53 pm |
| logging to syslog ? | October 12, 2005, 12:07 pm |
| PIX not logging IDS to syslog | December 21, 2005, 12:52 am |
>
> Good day everyone, I have a problem with ACS's logging and I hope anyone
> who had similar experience could help me on this issues.
>
> We have two ACS on our network (primary & secondary). All our dial-up
> customer are authenticated on primary ACS and the secondary ACS is only
> serves as a backup ONLY when the primary ACS is fail or out of service.
> User databases and groups including certain security & network
> configurations are replicated to secondary ACS on daily basis (every 24
> hours). The logging for configuration for each ACS reports (Failed
> Attempts, Passed Authentication, RADIUS Accounting and etc) are also
> configured to daily basis. So far, the operational status for both are
> fine but I found out the logging files on secondary ACS has an extra ACS
> report which ends with "(HH-MM-SS).csv", for example, RADIUS Accounting
> 2008-05-02(00-00-33).csv. This happens whenever the secondary ACS are in
> replication mode and receives updates from primary ACS after every 24
> hours.
>
> In a day, the secondary ACS generates two identical ACS reports, with and
> without '(HH-MM-SS)'. Example ACS reports generated by secondary ACS;
>
> RADIUS Accounting 2008-05-02.csv
> RADIUS Accounting 2008-05-02(00-00-33).csv
>
> It only happens on secondary ACS but not in primary ACS, although in my
> understanding, whenever ACS in replication mode, all ACS services will be
> temporarily suspended and return to operational once the replication mode
> is completed. Our billing software is customized only to process those
> normal ACS reports (logs) but not those ends with "(HH-MM-SS).csv" and we
> have to manually extrack the content and merge it with the current
> reports. We did not having this problem in our previous ACS version 3.2
> until we had upgraded our service recently.
>
> Question: How do I overcome this issue? Any workaround?
>
> Thank you very much!
>
> Regards,
>
> Daniel
>