This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(60.8, 35%, 15%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDR%3C/text%3E%3C/svg%3E)
Hello All,
i have an Azure AD joined laptop on which i use to login with a normal user with no administrative rights. But now i want to manage user rights from Azure AD portal using Privileged identity management.
I then assigned a role "Azure AD joined device local administrator" to the normal user so he can do the administrative task on his local machine. i assigned this role with time bound limit so his role will expire after the end time i mentioned in the role assignment settings.
But the thing is these settings don't reflect on the user end and user don't get the access to perform the administrative task with in the specified time limit.
I have gone through multiple forums and seen a lot of videos regarding this.
Need help
Thanks in Advance
Daniyal
Hi all,
I have almost achieved the target to pass the administrative rights to a user on local device and it will also expire after the time limit you set in the configuration.
Here's the link i got help from
https://www.lieben.nu/liebensraum/2021/06/lightweight-laps-solution-for-intune-mde/
Thanks
Dan
Using PIM in Azure to control local admin permissions is not supported. It does more or less work, however, it's tied to the PRT refresh cycle which is every 4 hours so is also more or less unpredictable and of limited (at best) value,
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(185.6, 42%, 27%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EWK%3C/text%3E%3C/svg%3E)
I am attempting to setup this same solution and have been stymied by the PRT 4-hour refresh cycle making this feature unreliable like you mentioned. However, I have discovered the command "dsregcmd /refreshprt" When I used this command, I was immediately granted local admin access on my machine. I am wondering if this is a reliable work-around to continue using until you develop the "cloud/Azure based LAPS like solution that will integrate with Intune that would fill this gap" you mentioned in another post.
Can I also use this command to turn off access when the user is finished with his task?
Is there any sort of rate limit, or other limit I should be aware of when attempting to use this command to refresh my PRT token so that I may then proceed to gain local admin rights on that user account?
I am wondering if this is a reliable work-around
It's not tested so your results may vary and aren't guaranteed (which is more or less the meaning of unsupported in this scenario) thus you assume all risk if you choose to use this method. I don't know of any specific throttling but most services in the cloud have at least a practical limit if not a specifically hard-coded limit and/or throttling as that's the nature of any cloud service.
I turned the whole activity into a script that the end-user can right-click and then run with powershell under standard user credentials. I've changed some of the identity strings below to not reflect my actual identity. After a day or so of testing, this seems to be working out for my solution.
connect-azuread -accountid bgates@Company portal .com
write-host "if you continue, you will be logged off so that you can log back on with administrator privileges"
pause
$Jux = Read-Host -Prompt 'Input your justification for activating the admin role'
$mytspan = new-timespan -hours 4
$schedule = New-Object Microsoft.Open.MSGraph.Model.AzureADMSPrivilegedSchedule
$schedule.Type = "Once"
$schedule.StartDateTime = (Get-Date).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ss.fffZ")
$schedule.endDateTime = ((Get-Date) + $mytspan).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ss.fffZ")
Open-AzureADMSPrivilegedRoleAssignmentRequest -ProviderId 'aadRoles' -ResourceId '4c123456-121f-12bf-b121-d1d2f1d2a121' -RoleDefinitionId '1f12201d-73c1-7d3c-771a-1edb20102fd1' -SubjectId 'd2b1b201-2c12-1e21-b6ea-f2d512da0162' -Type 'UserAdd' -AssignmentState 'Active' -Schedule $schedule -Reason $Jux
write-host "takin a quick nappy nap for about 120 seconds"
start-sleep -seconds 120
write-host "Lets request a refresh on that Primary Refresh Token"
dsregcmd /RefreshPRT
write-host "take another nap for 10 more seconds, then you will be logged off"
start-sleep -seconds 10
logoff
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(153.6, 38%, 24%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EAB%3C/text%3E%3C/svg%3E)
Hi Jason, thanks
I believe Microsoft is pretty laidback on this. Why to have a policy in there when it is of no use? Advertising it like J-I-T Just in Time access and then ditching the users that it's something unpredictable. No disrespect but I don't see any logic behind this.
Because PIM wasn't designed for this scenario. PIM was designed for admin activities within Azure (using the Azure portal or Graph API). It doesn't (and can't really with the way Windows currently works) account for how something outside the scope of its control behaves which in this case is the PRT refresh process in Windows which is what is actually dictating the behavior.
No commitments whatsoever and no timelines to share, but we are investigating a cloud/Azure based LAPS like solution that will integrate with Intune that would fill this gap.
Again, why would one thing be advertised with Local Device Administrator Policies and applicable in some fashion ? If it wasn't designed in such a fashion, then why work intermittently ? I see bug turned as feature and now when reported, saying it's a bug/never designed this way. No offence but I find it very difficult to digest this truth.
Again, why would one thing be advertised with Local Device Administrator Policies
Not sure what you mean here. Nothing is "advertised" by Microsoft concerning this because we know it's not supported due to the issue I called out.
As far as why it's possible, it's because it works for the intended purpose: PIM for access to Azure admin functionality. The fact that it may have other affects is an unintended by-product and we can't explicitly turn it off for this one use case as that would break its actual intended purpose. This is reality.