Article Number
000013920
Applies To
Access Manager 6.0.4
Issue
"Passive Deny" message in aserver log file for allowed resources
If the aserver is in passive mode, users who should have access to a protected resource are denied access with a "Passive Deny" log message. If the aserver is in active mode, users who should not have access to a protected resource are allowed access with a "Unprotected Resource" log message.
aserver log file shows a "Passive Deny" message instead of "cached allow" for a resource where the user should have access.
sequence_number=16,2009-04-09 13:37:14:293 PDT,messageID=1012,user=user1,webserver=istaines-t,URI=/protected/test.html,client_ip_address=192.168.206.133,client_port=4215,result_code=11,result_action=Authorization Failure,result_reason=Passive Deny
Cause
The log message mesageID=1012 ?Passive deny? indicates that the user is denied access because there are no entitlements for those resources. It occurs when the aserver is in passive mode and checks the aserver cache for a particular URL and finds that it is not present in the protected URL cache.
The protected URL cache is a unique cache in that it is populated on aserver startup and maintained throughout the life of the aserver. It is refreshed when new entitlements are added or deleted otherwise it is fairly static. By definition the cache only contains URL?s that have entitlements, not (potential) URL?s that do not have entitlements. The cache is updated from the datastore whenever the cache time to live (default 5 minutes) expires on a particular entry. At this time the aserver will make a call to the database to refresh any item in the cache.
In certain rare situations if a datastore failure occurs at specific time during a cache refresh event the aserver may return a empty dataset back from the datastore in response to the request instead of a returning a connection failure message. Normally a datastore failure should be detected by the connection manager and result in a failover to an alternate datastore. No known condition of the datastore has been demonstrated to produce this effect but a forensic analysis of a customer log files has provided evidence that this failure mode must have occurred. The incidence of this type of failure is believed to be very rare even on systems with high rates of datastore failure events, but this is considered a serious issue as a URL that is dropped is not added again until a restart of the aserver occurs.
Resolution
This issue has been resolved in hotfix 6.0.4.23 for RSA Access Manger 6.0.4 and hotfix 5.5.3.168 for RSA ClearTrust 5.5.3 Please contact RSA Customer Support and request this hotfix or the latest cumulative fix for your version.
The protected URL cache has been redesigned so that items are never removed from the cache by the cache refresh process. Items are now only removed from the cache after direct eserver cache flush events have been received as the result of an entitlement change.
Notes
In addition a new aserver log file message will be logged in the event that the protected URL cache check returns results that are inconsistent with the datastore. This message may occur if an entitlement is deleted on the eserver and a user attempts to access a resource for that URL before the aserver has time to service the eserver cache poison event for that URL.
sequence_number=15,2009-04-20 10:39:04:421 PDT,messageID=13,Resource=/protected/*,result_code=14,result_action=Cache Event,result_reason=Data Store Error ,ext_result=The result set does not contain any entries.
The aserver debug output will also print out the URL of the affected resource:
09:57:40:030 [*] [MuxWorker-8] - NoSuchEntryException, Cache is out of sync for URL Resource: name = webserver1, uri = /protected/*, (Mon Apr 20 09:56:24 PDT 2009)
