search

microsoft / WSL

Issues found on WSL
https://docs.microsoft.com/windows/wsl
MIT License
17.34k stars 814 forks source link

The user has not been granted the requested logon type at this computer #5401

Open nd368park opened 4 years ago

nd368park commented 4 years ago

Fails to start any WSL distro with the error:

Logon failure: the user has not been granted the requested logon type at this computer

Environment

Windows 10 x64 10.0.19041.264 wsl2 Ubuntu 18.04 Windows Terminal 1.0 AD joined machine

Steps to reproduce

  1. Follow the standard instructions to install WSL2 and distro
  2. Run WSL2 distro - everything works
  3. Close terminal Window
  4. wsl --shutdown
  5. gpupdate /force
  6. Try and run distro again = error

Expected behavior

Distro runs under wsl2

Actual behavior

Can't run any distro under wsl2

The question is what Group Policy, account privileges are required in order for wsl2 to run successfully?

aleon1220 commented 4 months ago

Everyone please read this thread. Most useful solution is to 

Restart-Service vmcompute
ajkessel commented 4 months ago

Everyone please read this thread.

Most useful solution is to 


Restart-Service vmcompute

My suggestion also provides a durable solution that doesn't require the user to do anything manually. Assuming you have the rights to add log-on scheduled tasks and can run those commands as admin, you shouldn't see this issue anymore.

Ownkel commented 4 months ago

@ajkessel did you modify your GPOs as well after implementing your fix? As per my findings, the crash only happens when a GPO is applied that modfies the "Log on as a service" Permission (SeServiceLogonRight).

ajkessel commented 4 months ago

@ajkessel did you modify your GPOs as well after implementing your fix? As per my findings, the crash only happens when a GPO is applied that modfies the "Log on as a service" Permission (SeServiceLogonRight).

No, I didn't do anything other than run that snippet of code as a logon task. Nothing else.

Ownkel commented 4 months ago

Did you have a GPO in place that modifies "Log on as a service" permissions when the issue started? And if so, do you still have it active even after your fix? I disabled this setting completely and put something simliar to your script into the staging process of new clients (only once). That solved it for good.

trallnag commented 4 months ago

It is so weird. Got a new laptop and started to have this problem. At the same time on my older laptop it is working fine. Same Windows version.

barbuslex commented 3 months ago

Same issue on WSL2 and Windows 11 (x64) for me after long sleep (maybe group policy refreshing by it admins ?). The Restart-Service vmcompute works for me.

pa-0 commented 3 months ago

@aleon1220:

I'm also on a domain-joined machine here (Windows 11 Enterprise), but we do not use 1Password... Could you please shed some light on the connection (if any) between starting that program and getting WSL to work? ...not seeing the connection

I recently tried adding this to a PowerShell script run as admin at each logon

$sid = [System.Security.Principal.SecurityIdentifier]::new("S-1-5-83-0")
Add-WindowsRight -Name SeServiceLogonRight -Account $sid

After another week, this seems to have held up as the best fix I've found so far.

i am under a corporate laptop and even though I have admin permissions I dont have access to certain policies. What works for me is the order in which i open the applications.

  1. Wait 5 minutes for Teams to load
  2. Open OnePassword
  3. Open VsCode or the Windows Terminal with WSL as the default
  4. wait 3 minutes

Doing it in that order and waiting always works for me.

pa-0 commented 3 months ago

@Ownkel, could you share the script you're using?

Did you have a GPO in place that modifies "Log on as a service" permissions when the issue started? And if so, do you still have it active even after your fix? I disabled this setting completely and put something simliar to your script into the staging process of new clients (only once). That solved it for good.

Ownkel commented 3 months ago

Sure, but this approach isn't as effective as the previously mentioned native PowerShell method.

function Add-ServiceLogonRight([string] $Username) {
    Write-Host "Enable ServiceLogonRight for $Username"

    $tmp = New-TemporaryFile
    secedit /export /cfg "$tmp.inf" | Out-Null
    (gc -Encoding ascii "$tmp.inf") -replace '^SeServiceLogonRight .+', "`$0,$Username" | sc -Encoding ascii "$tmp.inf"
    secedit /import /cfg "$tmp.inf" /db "$tmp.sdb" | Out-Null
    secedit /configure /db "$tmp.sdb" /cfg "$tmp.inf" | Out-Null
    rm $tmp* -ea 0
}

Add-ServiceLogonRight "*S-1-5-21-XXXXXXXXXXXXXXXXXXXXXXX"
ajkessel commented 3 months ago

Sure, but this approach isn't as effective as the previously mentioned native PowerShell method.

Is this equivalent to my solution except it allows you to specify the username?

Ownkel commented 2 months ago

@ajkessel I think your solution would also allow the specification of the username (as SID) but you're using the group "NT VIRTUAL MACHINE\Virtual Machines" instead. Are you adding the end users to this group?

ajkessel commented 2 months ago

@Ownkel I'm not adding users to the group. This is just on my own box, and I'm in groups Administrators and Users, no others. wslservice and vmcompute run as system, not as the user, so I wouldn't think the end user would need to get the SeServiceLogonRight for WSL to run. I don't have a deep understanding of any of this, though, I just arrived at my solution through some trial and error.

pa-0 commented 2 months ago

Seems like Microsoft might stand to benefit from open sourcing WSL at this point...

aleon1220 commented 2 months ago

@aleon1220:

I'm also on a domain-joined machine here (Windows 11 Enterprise), but we do not use 1Password... Could you please shed some light on the connection (if any) between starting that program and getting WSL to work? ...not seeing the connection

I recently tried adding this to a PowerShell script run as admin at each logon

$sid = [System.Security.Principal.SecurityIdentifier]::new("S-1-5-83-0")
Add-WindowsRight -Name SeServiceLogonRight -Account $sid

After another week, this seems to have held up as the best fix I've found so far.

i am under a corporate laptop and even though I have admin permissions I dont have access to certain policies. What works for me is the order in which i open the applications.

  1. Wait 5 minutes for Teams to load
  2. Open OnePassword
  3. Open VsCode or the Windows Terminal with WSL as the default
  4. wait 3 minutes

Doing it in that order and waiting always works for me.

hi sure, that was for my previous laptop. Using that flow ensured that everything worked. Doing things in a different order would NOT work for me. I didnt have the time to debug and find out why. I requested a new cool laptop with a fresh windows11 OS and WSL with ubuntu22 and i no longer have that issue.

Sieboldianus commented 1 month ago

Add-WindowsRight -Name SeServiceLogonRight -Account $sid

This gives me an error, telling me that Add-WindowsRight was not found (elevated ps).

trallnag commented 1 month ago

@Sieboldianus, the function comes from the following package https://www.powershellgallery.com/packages/psprivilege/0.2.0.

Sieboldianus commented 1 month ago

Thanks. After a few days, I can says that this does not work.

Install-Module -Name psprivilege
$sid = [System.Security.Principal.SecurityIdentifier]::new("S-1-5-83-0")
Add-WindowsRight -Name SeServiceLogonRight -Account $sid

I still need to run:

Restart-Service vmcompute

... once, after booting Windows, to be able to start WSL2.

ajkessel commented 1 month ago

I believe the WindowsRight command needs to run before WSL launches. I have it set as a scheduled task triggered by login.

It might depend on how your domain's group policy is applied.