Stephan,
if all is well the AM COMPARE function (AM.2) compares the outcome of the original access check against the outcome of the simulated access check against your allocated RACF input source. The option that is named "Profile used" can be used to refine your selection to take into account what was the best fitting profile at the actual time of the access event against the best fitting profile during the simulation of the access event.
- Option 1 should only report the access events where the best fitting resource profile during the actual event and the simulation of that access event are the same resource profile.
- Option 2 should only report the access events where the best fitting resource profile during the actual event and the simulation of that access event today are different resource profiles.
- Option 3 should report the outcome of all actual and simulated access events whether that decision was taken by the same or a different resource profile.
Thus, if you state that your allocated RACF input source contains the same DBS1.MQ.** dataset profile that was the best fitting profile at the actual time of the access event, I would expect that when you use "Profile used option=3" both the actual RC (AccRC) and simulated RC (SimRC) would be reported as "0" indicating that access was allowed at the time of the event, and will be allowed today through the same dataset profile in the currently allocated RACF input source.
If according to your experiments, you get a different actual RC (AccRC) and simulated RC (SimRC) for an access event whereas the best fitting dataset profile did not change, I suggest to open a ticket with our zSecure support team to diagnose what is going wrong here.
Best regards, Tom Zeehandelaar
------------------------------
Tom Zeehandelaar
z/OS Security Enablement Specialist - zSecure developer
IBM
------------------------------
Original Message:
Sent: Mon March 10, 2025 02:27 AM
From: Stephan Reichelt
Subject: Strange results from the Access Monitor
Hello Tom,
First of all, thank you very much for your quick reply.
Regarding the topic: That's what's confusing me. The historical file was only from the previous day, Scope from one day ago. And in both data sources, historical file and current database, I have ALTER access to the profile DBS1.MQ.** via a group. Yes, we have activated Protect = YES. But all files that begin with DBS1.MQ. are protected by this profile, so there are no unprotected files.
And when I use the functions Profile = Same (1) and Profile = Other (2), everything is fine. Only when I use Profile = All (3) does this discrepancy occur.
Maybe I don't understand the function properly (the manual doesn't help much either, not to mention the online help).
I understand that selection 3 is a combination of 1 and 2. But apparently 3 uses different search algorithms or filters than 1 and 2?
Best regards,
Stephan
------------------------------
Stephan Reichelt
Original Message:
Sent: Fri March 07, 2025 04:41 AM
From: Tom Zeehandelaar
Subject: Strange results from the Access Monitor
Hi Stephan,
I am not sure whether I fully understand the scenario that you describe, but I am going to attempt to answer your question anyway.
The access monitor compare option (AM.2) can be used to compare a historic RACF access decision that access monitor collected in the past and stored in an ACCESS record with the simulated RACF access decision for that same access event when it occurs today against the RACF input source that you have currently allocated to your zSecure session. Note that this RACF input source does not have to be the RACF active primary database. When you had allocated a year old UNLOAD or BACKUP of that RACF database during your experiment, that RACF input source is used to produce the compare output.
The RC=8 result that you refer to, indicates that the RACF input source that you had allocated to your zSecure session did not find a matching dataset profile protectig data set DATASET DBS1.MQ.T4.SCSQAUTH. And when the RACF SETROPTS PROTECTALL setting for that system was set to YES/FAIL, you are not authorized to READ data set DATASET DBS1.MQ.T4.SCSQAUTH, hence the RC=8 that zSecure reports.
Does that help?
------------------------------
Tom Zeehandelaar
z/OS Security Enablement Specialist - zSecure developer
IBM
Original Message:
Sent: Fri March 07, 2025 03:55 AM
From: Stephan Reichelt
Subject: Strange results from the Access Monitor
Hello everyone,
I ran a compare via AM.2. I used the file from the previous day as the historical file. Since my permissions have not changed, the result should not show any differences. So far, so good.
In the fields Profile used... 3 1. Same 2. Different 3. All I first took 1 = no differences. With 2 = no differences. And now the surprise! With 3 there were fewer rights.
The output:
DATASET DBS1.MQ.T4.SCSQAUTH
Intent=READ
Historic DATASET GENERIC DBS1.MQ.**
Allowed=ALTER Result=0
Current
Result=8 via NOTHING
I think NOTHING is best. Can someone explain to me how this strange result comes about? The fact is that I had the same rights the day before, and an access check also confirms that I have the right, even on the current database.
Thank you in advance.
Kind regards
Stephan
------------------------------
Stephan Reichelt
------------------------------