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!

@ConceptsWork

3 жыл бұрын

Thanks TH for bringing this up, I am pinning your comment to the top so this can help everyone. At - kzread.info/dash/bejne/fqyd0c6hmre2cdI.html, you have to add the scope tag that we created initially.

So in a nutshell explanation is good.

Thank you so much!

@ConceptsWork

3 жыл бұрын

You're welcome!

How many nutshells do I need? ;-)

@MoAli-nv9cf

2 жыл бұрын

Two. Nutshell within a nutshell = Acorn = LOL

I believe there's a small error at kzread.info/dash/bejne/fqyd0c6hmre2cdI.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!

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......

@ConceptsWork

2 жыл бұрын

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.

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

I am confused with the group "Passwordless". Don't we already have targeted groups defined in scope tag A?

@kavingaranaraja4195

3 жыл бұрын

I'm also not clear on that.

@Prasanna0590

3 жыл бұрын

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.

@THuk44444

3 жыл бұрын

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)

@mrkhan4737

8 ай бұрын

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

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?

@ConceptsWork

3 жыл бұрын

have you registered or Azure AD joined your device.

@pugazhendhid5765

3 жыл бұрын

@@ConceptsWork azure ad only

Hi, Can you make more videos on Sentinel also please.

@ConceptsWork

Жыл бұрын

It will be released very soon.

Sir plese put total concept video