Skip to main content

Hello,

Want to ear you from your experience about one point.

 

Context:

Group with 20k computers spread out in diferente business units (countries).

Cybersecurity: centralized team for all the group.

Helpdesk: each business unit (country) have their own team (some from an external provider and some other it’s internal technicians), with a dedicated IT manager. Those helpdesk teams have a quite huge turnover of people, over the time.

 

Considering that (if I’m not mistaken) only administrator role can have the possibility to add/remove users from Group Policies, what is the best approach/what your experience tells?:

  • Concentrate the administrator role only to cybersecurity team members?
    • Problem/dificulty I see: it put all the heavy work of add/remove users (as I mentioned, there’s a huge turnover on helpdesk teams) to Cybersecurity team.
  • Give administrator role to people on each business unit side (for example to the managers of each helpdesk teams)?
    • Problem/difficulty I see: it give administrator role (so, can edit/change basically anything, as Group Policies, Session policies, Jump policies, create/remove users, ...) to people that shoudn’t be able to do that on all Group Policies, but only on their Group Policy.
  • For each Group Policy, have a dynamic AD group and appli it to the Group Policy (it means that it will take automatically the users that are within this dynamic AD group)
    • Problem/difficulty I see: it means that AD need to be very well organized/managed/mastered to be sure only right people are included in the AD group and so applied to the Group Policy.
  • Other possibility?

 

Ideally, it would be great to have the possibility to grant admin role affecting only a specific Group Policy (I mean, be possible to define that the user X can administrate only the Group Policy Y). But as far as I understood it is not possible by design.

 

Thanks in advance

Hey Mauro!
What I have put below does not answer your question directly, however, it will give you a great starting point and best practices and will help you devise a way to implement the product how you would like.  

The best way to approach this is if you have any admins you trust with full access to /login and all the management tools.  Create at least one backup admin account then I would create an admin policy with full access to everything.  Add your new admin account and all users you trust to the admin policy to lighten the load.  Even if it’s just you, next, create a bare bones basic policy with these minimum permissions and label it “copy of basic policy” or something. (Do no add any users to this.  You will copy this policy to save some work).  

1.      Create a group policy -> /login -> users and security -> group policy -> create a new group policy.
** Set every section from general permissions to final EXCEPT Memberships at the bottom.  This will prevent any permissions to be overridden as our policies ALWAYS take the most restrictive path.**

2.      Under Account settings - this controls account expiration, 2fa, and the reps ability to edit it's own name, photo, and ability to show on the public site.

3.         Under General permissions - This controls various hostname/login controls and functions.  This is also where reporting is located and can grant the user access to their own reports to view, teams reports or All reports. 

4.         For basic remote support - Scroll to representative permissions -> make sure the following is selected:

a.         Allowed to provide remote support

b.         Under jump technology -> jump clients are selected and any other permissions or session functions such as RDP, Local jump, ect. 

c.         Under jump items roles -> set default role, leave Teams, Personal and System as NO ACCESS.  If you do NOT set system to NO Access, they will have access to ALL jump clients.

Default - Only what you assign them
Personal - Clients only the user can see
Teams - All personal clients of everyone on the team
System - Access to ALL CLIENTS in the system.  (Only admins should have this)

d.         Under attended permissions -> set prompting behaviors and allow screensharing – set any other permissions you want - Attended sessions is session key, public portal issue submission, clicking a reps name or Support Button.  These are all Customer initiated sessions.

e.         Under unattended permissions -> set prompting behaviors and allow screensharing – set any other permissions you want - Unattended sessions are jump client, jump to, remote jump - all rep initiated sessions.

The above permissions are what is needed to have basic support access.  You then can just copy the policy, rename it, add users, and adjust all permissions as need.  

Based on your requirements - I would create a support team, group policy, and jump group ALL with the same names to keep it clean and organized.  You will know Team A, access Jump group A, and is in Group Policy A.  

Support teams details:
Team Manager: They can manage, monitor and take over sessions of Team Leads and also Team Members.
(Note: Managers cannot view sessions of other Managers.)

 
Team Lead: It is a role on which you can control subjacent users (ex. Team Members), in this role you can monitor, manage and take over sessions if required.
(Note: Leads cannot view sessions of other Leads/Managers.)


Team Member: This is the lowest level in the hierarchy, regular users should be placed on this group.
(Note: Members cannot view sessions of other Members/Leads/Managers.)

 

 

 


Reply