Intune Custom Roles
ฝัง
- เผยแพร่เมื่อ 21 ก.ค. 2024
- #Intune #IntuneAdminPortal #IntuneRoles
Please read the first pinned comment, it is insightful.
Intune Admin Portal
Intune Custom Roles
- These are the terms covered in this video.
Microsoft Article - docs.microsoft.com/en-us/intu...
Regards,
ConceptsWork - วิทยาศาสตร์และเทคโนโลยี
I think there's a mistake in this.
Step 1: When creating the scope tag, you're selecting groups of target objects to be bound by that particular scope tag. ✔
Step 3: In the role assignment wizard you're selecting:
- which admin user groups you're giving that role (i.e set of rights) to ✔
- which scope tag those users will be limited to being able to administer ✔
- and again optionally you can further restrict by selecting a scope group at this role assignment level to act in addition to the group(s) you already set in step 1 ✔
But in the middle of that there's step 2: creating a custom role.
When you select a scope tag while creating a custom role, you're only tagging that custom role as a target object, not giving it (the custom role) permissions over any other objects in any way.
So say you wanted the "Mumbai L3 Admins" group to be able to edit and manage the "Mumbai L1 Helpdesk" custom role, you'd apply a "Mumbai L3" scope tag to the custom role (in exactly the same way you'd apply it to various other objects that you want the L3 admins to control). They can then go in and edit that "Mumbai L1 Helpdesk" role object, add/remove rights etc.
If you actually wanted to associate the "Mumbai L1 Helpdesk" custom role with a scope tag (say "Mumbai L1") to give them rights over a particular set of objects, you'd have to use the role assignment wizard, specifying the "Mumbai L1" scope tag in that, not in the custom role options.
In fact if the "Mumbai L1 Helpdesk" custom role did get tagged with the "Mumbai L1" scope tag, the L1 Helpdesk users would be able to go in and edit their own rights and give themselves a lot more access than they should have, so probably avoid!
Thanks TH for bringing this up, I am pinning your comment to the top so this can help everyone.
At - th-cam.com/video/LxiolhjTPAo/w-d-xo.html, you have to add the scope tag that we created initially.
So in a nutshell explanation is good.
How many nutshells do I need? ;-)
Two. Nutshell within a nutshell = Acorn = LOL
Thank you so much!
You're welcome!
One question for you. Since there are two type of roles :- Custom Roles and Built-in Roles. out of these two which one can be controlled by PIM feature of AAD. ? Kindly clarify
While creating the CustomRole-Intune, under Members(Group) we are selecting the Group of users that will get the permissions assigned, but in the next step i'm a little confused, is this something mandatory or depends on our requirement? whats exactly that option is? kindly clarify
Thank you, but .... can you explain this..... my organization uses Intune-MDM as assignment group... which is not actually in active directory....and not using any active directory groups......
It's fine, we can use Azure AD groups also for assignment. All you have to make sure, respective users should be the member of scoped groups.
I believe there's a small error at th-cam.com/video/LxiolhjTPAo/w-d-xo.html, the checkbox allows the scope tag only to be assigned to a group of devices, not to a group of users. Great job anyway on providing this content, love your very clearly presented videos!
Sir plese put total concept video
I can join device to Azure, but unable to login with that same account, do we need to configure anything to allow user to login?
have you registered or Azure AD joined your device.
@@ConceptsWork azure ad only
I am confused with the group "Passwordless". Don't we already have targeted groups defined in scope tag A?
I'm also not clear on that.
Below is my understanding.
Custom role is scoped to "SiteTag A"
Assignment includes two settings:
Admins - Intune_MAM
Scope group - Passwordless (further segregated set of users part of Site A)
So, when admins part of group (Intune_MAM) apply/modify settings, it will only applied to users part of the group "Passwordless". Not for all the users & Devices part of SITE A.
There's some strange behaviour with this that I've been trying to learn and understand.
Things that are hit by a Scope TAG (by being part of the group specified in the scope tag options you refer to, or by having the same tag directly applied to their invidivual object properties) are accessible to your chosen admin group(s), but this is done in a particular way: functionally it's by blocking READ access to all other objects that are outside of that scope (and obviously by blocking "read" they're also not able to do anything else at all with those objects either).
But using a Scope *Group* creates quite different behaviour. There's no limitation on read access. In fact there's no limitation on any create/update/delete permissions whatsoever, admins will have those permissions on all objects in your environment still, so they have pretty limited use. They only actually restrict the "intune-like" functionality, i.e:
- assigning policies/profiles/applications
- remote control tasks of devices
... that's it.
I say this as a learner who's trying to pass the MD-101 exam in a few day's time with the help of the Concepts Work vids... But this is definitely what MS say!
docs.microsoft.com/en-us/mem/intune/fundamentals/role-based-access-control
(At the top click the link to video 3)
same here, i'm confused on passwordless thing, when we have selected the users that will be a part of the Admin, then whats the other option where we are selecting a Group (passwordless)? @@kavingaranaraja4195
Hi,
Can you make more videos on Sentinel also please.
It will be released very soon.