Delegation for undelete and restore

After introduction of "Recycle Bin goes UI" in Windows 2012 we saw number of requests for delegation on technet forums.


These are answers marked as correct:


I would not recommend to delegate control for above activity to helpdesk admin for security reason.


In general domain admin rights are required to achieve the above task.


You can check the same by delegating required permission to heldesk id as suggest in MS KB.You can test the same in test environment.


Alternately however this activity is not carried on daily basis you can share the domain admin credential while restoring the object in case of crisis to helpdesk team or create seperate domain admin account and dont share the credential share only when required.


The table shows the min requirement & you can't achieve restoring or deleting object without domain admin membership. Delegation are used for simple task like unlock account, password change,domain join etc which doesn't require big modification or changes to AD.Restoring object is a big task & without domain admin, it will not work.


While technically it is possible to delegate undelete using native functionality, in reality this brings great security risks.

Another problem is that it is not documented functionality.


Let's look at how the delegation model was implemented in RMAD. Here we have two layers of delegation.


Delegation for UI is based on membership in local groups on RM portal machine and each group has access to specific part of portal. I draw a rainbow to show where which group has access;)


Delegation engine for restore and undelete is powered by Active Roles Server technology so user’s permissions are virtual (don’t exist in AD). These permissions can be set via Web UI on per-container basis in each domain (see below screenshots). Permissions model is similar to file system.



Restore and undelete tasks will be actually performed by proxy account that should have all nessesary permissions in AD.


As we know in most organizations authenticated users have full read-only access to AD - so we decided that for first version it would be acceptable to give read access to all portal user.


During restore user will get "Access denied" message in case he doesn't have permissions on OU from where object was deleted.