PAM Provider maintenance mode and granular disabling of heartbeat failure notifications

Another scenario where this would be useful is when a provider/environment is auto power managed and it is shutdown outside of business hours when not in use.

Hello Joe,

Thank you for your request. I understand your need and it makes sense. We know that receiving heartbeat failure when you know that the system is not available is not useful and is annoying. I'm taking note of your request and will see if we could plan a such feature.

As you probably know, with the last version, 2024.1, it is possible to unsubscribe the notification of pam heartbeat failure, but we know that it will unsubscribe for all heartbeat failures. We have something plan to add filters on notifications. A user could specify a PAM Account list that he wants to receive the notification and he could remove some PAM Account to ignore them and not receive the notification for them. That improvement planned later could help for sure, but I also understant that having a configuration to flag a provider in maintenance mode could be useful for heartbeat, but also for rotation on a schedule as you said.

If we add a maintenance mode on the provider, I assume that we should not be able to use all PAM Accounts from that provider, am I right ? Is it what you had in mind ?

Best regards,

Hello François,

Thanks for looking into this request.

Re 'If we add a maintenance mode on the provider, I assume that we should not be able to use all PAM Accounts from that provider';

• There probably isnt a need to preclude a credential from an offline provider from being used/checked out/in, but obviously and associated password rotation would not be available.

Re the notification changes in 2024.1;

• The personalization capability is great, although it needs to be configured by each admin user individually.
• Ideally there would be a system wide 'default' personalization profile that any administrator could configure
• Following RBAC best practices, DVLS admins would use a seperate account for administering server settings, as opposed to a limited access account which they use with RDM for day to day activities. In such cases, the notification preferences are only available on the administrative user, When a regular user tries to configure notification settings, they see a message 'You currently do not have any management rights leading to the receipt of notifications.' Typically administrative accounts dont have a mailbox, so the only way to get the notifications is to update the email address for the admin user to be the same as the regular user. This is a bit cumbersome to manage, so ideally there would be an alternative way to configure this, for example:
  • a setting to send notifications to linked accounts (i..e an admin account would most likely be linked to a regular account for licencing optimization)
  • instead of each admin personalizing their notifications, it would only be configured as a system wide setting with some granularity to target specific users/groups
• Excluding notifications for specific PAM accounts would be great, ideally this would be a setting on the PAM credential itself to 'disable notifications', as opposed to each admin user having to manually maintain their own list of exclusions. Sometimes it is undesirable to set a PAM account to 'unmanaged' just to prevent being notified when the password is out of sync (i.e. some admins may update their personal PAM credentails manually, but when they are unable or neglect to do this, all admins get notified when the heartbeat fails)

Please let me know if you would like any additional info.

Thanks
Joe

Hello Joe,

Thank you very much for your feedback on our notifications. You have good points that I will keep in mind when we will improve them. Of course, notifications don't remove the need of a maintenance mode, I understand that. I'm taking note of that feature in a ticket in our backlog. We will post back here once we have an update.

Best regards,

Hello,
I'd like to chime in here, we are also looking for a way to disable heartbeat notifications. Not the same scenario though, in our case we are bulk importing personal accounts over a Domain User provider, but we don't reset the passwords until first use by that user. This causes a lot of unnecessary log entries and e-mail notifications being sent out do admins, since the accounts are technically out-of-sync.

(We don't want to manually reset these during import because the users are still using the current password which is stored in their user vault, and they haven't created a DVLS Privileged Account entry yet.)

Regards,
Simon

Hello Simon,

Thank you for your feedback. I understand your use case. Would it work for you if we add a way to disable the heartbeat on a PAM Account ? Of course, it would mean that you would have to enable it once your user start to use it. I'm not sure ignoring heartbeat until the account has rotate the password at least once would be the solution since you can set the password manually in the PAM to fix the heartbeat failure if you want. We could probably add a separate parameter as well to ignore the heartbeat until a password rotation is applied. I'm thinking about a solution while writing, we will see what could be done to support that case as well.

Best regards,

Hello,
Yes, to have the heartbeat disabled post-import, either by configurable system/vault default or perhaps just by adding a parameter that can be used with Import-DSPamScanResult, which we use. Then also have it enabled once the password has been reset, that would be ideal solution for us :)

Regards,
Simon

Hello Simon,

Thank you for your feedback. I understand your use case. Would it work for you if we add a way to disable the heartbeat on a PAM Account ? Of course, it would mean that you would have to enable it once your user start to use it. I'm not sure ignoring heartbeat until the account has rotate the password at least once would be the solution since you can set the password manually in the PAM to fix the heartbeat failure if you want. We could probably add a separate parameter as well to ignore the heartbeat until a password rotation is applied. I'm thinking about a solution while writing, we will see what could be done to support that case as well.

Best regards,

Hello Simon,

Thank you for your feedback. We keep that information to analyze it and see what could be the solution. We will post back here once we have an update for that.

Best regards,