Access denied to IDS MC after upgrading to 4.1.2-s58
On Friday the 7th, I did the upgrade of four of our appliance IDS sensors. No problem. Afterwards I did the upgrade on the IDS MC and at the next logon, I did't have any access anymore to IDS MC and Security Monitor :
'You are not authorized to request the Action associated with screenID: "/s510"' or 'You are not authorized to request the Action associated with screenID: "/s550"' depending on the screen I want to access.
Now there seems to be an issue with authentication via ACS (TACACS+) in combination with fall-back to CS local authentication. However disabling fall-back or ACS doesn't solve the problem. Before this upgrade we didn't have this problem (of course).
We are talking to our supplier and a case has already been opened, but after a week, we don't have a solution yet.
This is really urgent, because we don't have any access to our events anymore.
The IDS MC still is generating reports and sending emails to us. So it's a pure access problem, I think.
Rather peculiar is that we can't change also the AAA server in the VMS (IDS MC) administration. It always wants to check with a TACACS+ server even if we configured the CS local authentication in the CS security setup.
Re: Access denied to IDS MC after upgrading to 4.1.2-s58
Thanks, Chad ! This was really the answer and solution we needed.
I did the following :
- change the security setting in CW common services to use the local database
- goto VMS administration/AAA server
- synchronize --> AAA server was changed to CS local database and we got access to IDS MC again !
- go back to the security setting in CW CS and change back to TACACS+
So now we have access again to IDS MC and security monitor. However this seems to me a rather strange behaviour. We login to CW CS via TACACS+, but the VMS AAA server is set to CS local database. The user I use to login is known to the local database, but uses not the same authentication method.
Anyhow, it's working and we are very thankful for this answer !
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...