PEDM – One of the strange abbreviations within the PAM world, usually set next to PASM. PEDM stands for Privilege Elevation and Delegation Management. But what is it actually, and how does it enhance security while simplifying management processes?
Think of a situation where there are 5000 internal users within an organization. Every single one of them has their own laptop. Occasionally a user wishes to install a program, make slight modifications to the settings of OS or do something that requires admin rights. Some organizations have solved this by granting local admin rights to the users. In general, this is unacceptable and a strict no no! Some have created for the users one extra account, that is a local admin account. And whenever a user needs to do something that requires admins, they simply use that account instead of the normal one. This is also not such a good way of doing things. There could be 5000 admin accounts just waiting for someone to exploit them.
Where is the transparency? Domain admin cannot know in which state the domain computers are, if everyone can decide by themselves what to do with their laptops. The third option is usually that a user is forced to grab hold of a service desk person and ask them to make/install the changes. In the last example the service desk person will make the decision on whether the app should be installed or whether the settings can be approved.
What if you could see everything that is happening in the workstations within your domain? What if users could install approved applications by themselves without having admin rights, without having to stop their work and contact IT Support? And what if one could still monitor and see what has been installed and where?
It is possible, by utilizing PEDM – an endpoint management system (which can also be utilized within servers) that follows the pre-set policies and logs everything that happens within a workstation. What this means in practice is that the workstation has an agent installed in it – one that monitors the workstation and is in connection with the endpoint management system. The agent runs as a Local System, so it has full access to the system. Whenever a user wants to do something that requires admin rights, the action is checked against the pre-set policies. If the action is allowed, the windows UAC prompt is substituted with a new prompt, and the user’s own credentials are requested (to make sure this actually is this user), the application is elevated and the user is allowed to proceed with the elevated application.
The same applies in cases where a user wants to run MMC with Device Manager Snap-in. The domain administrator isn’t so keen on giving the user the possibility to run the whole MMC with elevated rights with every possible Snap-in, so he decides to make a policy that allows the user to run the “devmgmt.msc” as an administrator. Now the user can run only the Device Manager as an administrator, but all the other Snap-ins run as “unprivileged”. So the application is elevated for a short period of time, but the user is left with the default normal accesses. In this way, the need for POLP (Principle of Least Privilege) is also fulfilled successfully.
PAM Technology Lead
+358 46 600 0205