The Password View Request report is flooded by events related to the LDAP Bind account.
these appear to be related to system operations whereby PAM is accessing the LDAP directory for authentication or group refresh.
does that constitute a password view request?
is there anyway to prevent those "System-level activities" from flooding the reports?
sample report attached showing LDAP Bind accounts for two domains ( ALIGHIERI.US & SAND.BOX ) . What's interesting here is that my SAND.BOX domain wasn't even online during the period in which the report was run.
thanks in advance
Hi Sebastiano. Do you have some examples of the messages you are getting ? Is there any restriction set to the bind account you are using in your LDAP application ? Password view requests are part of the credential management part of the product, as you know, and accessing an account which is linked to an Windows AD application does not mean this has to connect to the LDAP directory you are using for authentication in PAM, so we would need a bit more information
Thanks for the reply Miquel.
I've attached a report from my test system to the OP.
Is there any restriction on the LDAP Bind account - NO
Password view requests are part of the credential management part of the product, as you know, and accessing an account which is linked to an Windows AD application does not mean this has to connect to the LDAP directory you are using for authentication in PAM, so we would need a bit more information
The issue here is that there is no user trying to access any account. more specifically, no user has tried to access the LDAP Bind account, certainly not 194 times in the last 7 days - per the report. The report attached was taken from my test environment - I'm the only user in it. I haven't tried to access the ldap bind accounts 194 times in the last 7 days.
What more information do you need?
The mere act of refreshing an LDAP group should not result in an entry in the Password View Request report. On the other hand, there could be an entry if the Bind Account in the LDAP Configuration is configured with a Password View Policy(PVP) set for Change Password on Auto Connect, Connection End or Session End. The authentication requests in the logs could be the result of the same thing. Your first step should be to check the PVP. If there is nothing to change there, or your change makes no effect, then you should open a Support Ticket. There is no other way to reduce the entries going to the log file.
Thanks Ed for replying.
In my environment, see attached sample report in OP, the two LDAP Bind accounts have the default PVP assigned.... and, of course, that has not been touched from OTTB config.
FYI - The client has opened a ticket for this.
Hi Sebastiano, The title of this report is a bit confusing, we discussed that recently and consider asking our Engineering team to change it. As a PAM admin you may think of password view requests as referring to a PAM user requesting view of a password, and an approver denying or approving the request. This is NOT what the report shows. The report shows password views, period. Internally Credential Management is considering this a request and provides the password if the user is allowed, or denies it. The LDAP refresh process needs the password of the LDAP bind account, which in PAM 3.x is stored as a target account. So the refresh process makes a call/request to get the password, and this is logged in the report like any other password view. This is working as designed. I wouldn't call two messages per hour a flood. On a busy PAM system with hundreds of password retrievals per hour you will barely notice these. They might be of use if LDAP refresh doesn't appear to work and it's not clear why.
Thank you Ralf for the reply.
That makes sense, however, i still question whether System-Level password access / view needs to be logged. What's the benefit of anyone knowing that the system itself is using a privileged credential to refresh LDAP - outside of just knowing - isn't that understood?
Alternatively, perhaps we need a separate report for "User-Initiated Password View Requests" with related activities. A client is relying on this report to show auditors "User-Initiated Password View Requests".
Is there a better report or better way of showing that information?
Hi Sebastiano, You have valid points. Please raise an idea in this community to have the report enhanced.
done Password View Report Enhancement