Remoting using Azure Active Directory (AAD) credentials fails with "access is denied"

[pcgeek86]

Summary

I'm trying to specify an AzureAD credential to connect to a PowerShell Remoting session. I can connect locally (loopback) without specifying any credentials successfully. However, when I specify the exact same account information explicitly, it fails.

https://stackoverflow.com/questions/62235382/powershell-throws-access-is-denied-exception-when-using-azure-active-directory
https://www.reddit.com/r/sysadmin/comments/drkq67/remote_powershell_session_using_azuread/
https://powershell.org/forums/topic/problem-with-remote-session-using-azure-ad-credentials/
https://powershell.org/forums/topic/azure-ad-connection-credential/

Steps to reproduce

C:\Users\TrevorSullivan> etsn localhost -UseSSL -SessionOption (New-PSSessionOption -SkipCACheck -SkipCNCheck) -Credential azuread\trevorsullivan

PowerShell credential request
Enter your credentials.
Password for user azuread\trevorsullivan: **********

Enter-PSSession: Connecting to remote server localhost failed with the following error message : Access is denied. For more information, see the about_Remote_Troubleshooting Help topic.
C:\Users\TrevorSullivan> etsn localhost -UseSSL -SessionOption (New-PSSessionOption -SkipCACheck -SkipCNCheck)
[localhost]: PS C:\Users\TrevorSullivan\Documents>

Expected behavior

PowerShell uses the Azure AD credential to establish a remoting session.

Actual behavior

Access is denied.

Environment data

Name                           Value
----                           -----
PSVersion                      7.0.3
PSEdition                      Core
GitCommitId                    7.0.3
OS                             Microsoft Windows 10.0.19041
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[jborean93]

Is the Azure AD user a member of the local Administrators group or the Remote Management Users group? Can you use something like PSExec to run psexec.exe -u azuread\trevorsullivan -p password whoami.exe /all? Are there any entries in the Security event logs that might indicate why the logon has failed? I'm not 100% sure as to how Azure AD logons actually work with Windows but IIRC it's not the same as a domain joined host using Kerberos.

[pcgeek86]

Yes, I am the only user of this computer, and I am in the Administrators group.

PS C:\Users\TrevorSullivan> psexec -u azuread\trevorsullivan whoami /all

PsExec v2.2 - Execute processes remotely
Copyright (C) 2001-2016 Mark Russinovich
Sysinternals - www.sysinternals.com

Password:
PsExec could not start whoami:
The user name or password is incorrect.

I'm pretty sure this is a bug with Windows and Azure Active Directory authentication, just like Task Scheduler.

[jborean93]

Ah ok I didn't realise your current user was the same as the credentials you specified. It's interesting that the example without an explicit -Credential works just fine as that means the implicit token that Windows has stored for your current logon will work against a network logon whereas when you specify it explicitly it does not. I do not fully understand how AzureAD works but I believe Windows uses the CloudAP Negotiate provider to facilitate the logon for those accounts so that might be a place to start looking into.

I'm also curious, is the connection to localhost just for an example to replicate this problem or are you actually using that for something in particular?

[jborean93]

I was very curious at this situation and I'm not able to replicate the problem in my test environment. I'm able to RDP to the Azure VM and auth with my Azure AD account. I'm able to create an run a scheduled task using that same account. I'm also able to connect to over PSRemoting with the implicit and explicit credentials for my Azure AD account. I was able to do so with both the Netlogon (DOMAIN\username) and UPN form (username@DOMAIN.COM).

The PSRemoting tests I tried

I also tried a HTTPS listener with a self signed certificate, even with CbtHardeningLevel set to Strict and it worked just fine.

When looking through the Wireshark captures I found that it is using Kerberos authentication which is expected. This is a completely vanilla setup of Azure AD that I used https://docs.microsoft.com/en-us/azure/active-directory-domain-services/tutorial-create-instance to complete.

One thing I did notice is that the PowerShell instance needs to already be running as an Administrator. Without that the underlying WinRM library is set to always fail with that error based on a recentish update. Although that blog post doesn't actually describe this particular scenario, that CVE fix also affected this setup. This check is to stop a limited process from elevating itself to an Administrator without going through a UAC prompt. I can definitely rule out PowerShell adding that check by running

winrs -r:http://localhost:5985/wsman -u:jborean93\testazad whoami.exe

On an elevated shell this works just fine but on a limited shell it will fail due to that new check I mentioned above.

Tutorial - Create an Azure Active Directory Domain Services managed domain

In this tutorial, you learn how to create and configure an Azure Active Directory Domain Services managed domain using the Azure portal.

[pcgeek86]

@jborean93 Do you have Multi-Factor Authentication (MFA) configured on your Azure Active Directory (AAD) user account? I do.

[jborean93]

I did not but that would indicate why yours fails and mine does not. It also explain how it works when you omit the credentials as it will be using the existing PRT that Windows had received during the logon process compared to getting a new one.

When you RDP into the box, do you just use the normal password? How does the MFA part come into that?

I'm recreating my environment and will enable MFA to test with.

[pcgeek86]

I'm not RDP'ing into anything. This is my local development system.

Here's what I see in the Windows Event Log (Security) when I run the above command.

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" /> 
  <EventID>4625</EventID> 
  <Version>0</Version> 
  <Level>0</Level> 
  <Task>12544</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8010000000000000</Keywords> 
  <TimeCreated SystemTime="2020-09-23T20:07:16.1450560Z" /> 
  <EventRecordID>680302</EventRecordID> 
  <Correlation ActivityID="{40d705d0-91e4-0010-0306-d740e491d601}" /> 
  <Execution ProcessID="1716" ThreadID="15940" /> 
  <Channel>Security</Channel> 
  <Computer>artemis</Computer> 
  <Security /> 
  </System>
- <EventData>
  <Data Name="SubjectUserSid">S-1-0-0</Data> 
  <Data Name="SubjectUserName">-</Data> 
  <Data Name="SubjectDomainName">-</Data> 
  <Data Name="SubjectLogonId">0x0</Data> 
  <Data Name="TargetUserSid">S-1-0-0</Data> 
  <Data Name="TargetUserName">trevorsullivan</Data> 
  <Data Name="TargetDomainName">azuread</Data> 
  <Data Name="Status">0xc000006d</Data> 
  <Data Name="FailureReason">%%2313</Data> 
  <Data Name="SubStatus">0xc0000064</Data> 
  <Data Name="LogonType">3</Data> 
  <Data Name="LogonProcessName">NtLmSsp</Data> 
  <Data Name="AuthenticationPackageName">NTLM</Data> 
  <Data Name="WorkstationName">ARTEMIS</Data> 
  <Data Name="TransmittedServices">-</Data> 
  <Data Name="LmPackageName">-</Data> 
  <Data Name="KeyLength">0</Data> 
  <Data Name="ProcessId">0x0</Data> 
  <Data Name="ProcessName">-</Data> 
  <Data Name="IpAddress">-</Data> 
  <Data Name="IpPort">-</Data> 
  </EventData>
  </Event>

[pcgeek86]

By the way, I do not need to be running PowerShell as Administrator, in order to establish a loopback PowerShell Remoting session. See screenshot below.

[pcgeek86]

NOTE: The substatus code in the Event Log entry indicates

0xC0000064 | User logon with misspelled or bad user account

... according to this document.

When I run whoami, I get literally the exact same output. How is it that this could be an invalid username?

[jborean93]

So is your local machine joined to the Azure AD domain?
Is your running running user the Azure AD user?
Does whoami output azuread\trevorsullivan?

By the way, I do not need to be running PowerShell as Administrator, in order to establish a loopback PowerShell Remoting session. See screenshot below.

That's weird as I definitely have to do so and have had to do so for a while now. Does the Medium or High mandatory label appear when you run whoami.exe /groups in that normal process?

[pcgeek86]

Here is the output from whoami /groups

And yes, whoami outputs azuread\trevorsullivan.

[jborean93]

Ok so you either have UAC disabled or your account is the builtin admin account (renamed). Because you have the High Mandatory Label the process is elevated and running like it would when you right click -> Run as administrator. This explains why you are able to do the loopback connection.

My test domain and VM is now online, I've enabled MFA so I'm going to test out a few things right now.

[pcgeek86]

Sorry, that was from the admin session. This one is from the non-admin session. You can see Medium Mandatory Level here.

[pcgeek86]

Also, I have disabled MFA on my AzureAD user account, and still receive the same error. Clearly, due to the earlier substatus code, there is some kind of account name resolution issue going on. It doesn't think that azuread\trevorsullivan is a valid username, but the operating system is the one telling me that, that's my username. 🤷🏻‍♂️

[pcgeek86]

By the way, I also tried configuring CredSSP on the WinRM service, and enabling credential delegation through local GPO. Using CredSSP didn't get me anywhere. It only introduced more roadblocks with the SPN configuration.

[jborean93]

Well then I don't know why the loopback works :(

Yea the error code is clearly Windows saying that the username cannot be resolved. In either case with MFA I'm still able to connect but I didn't have to do anything special so I have no idea if I even set it up properly.

Ultimately the error is happening outside of PowerShell and Windows is unable to process the authentication for that user. It could be that there's enough info cached to allow you to log on interactively using your Azure AD account but subsequent network logons are relying on an active connection to the Azure AD domain itself which isn't there. The fact that it tried to logon using NTLM is suspicious as for me it's using Kerberos.

You could also see if Windows is able to lookup the SID based on the name with

[Security.Principal.NTAccount]::new('username@DOMAIN.COM').Translate([Security.Principal.SecurityIdentifier])
[Security.Principal.WindowsIdentity]::GetCurrent().User

Sorry I couldn't help anymore, it seems like it is possible but there's something specific with your environment setup that I cannot replicate that is causing an issue with Windows trying to resolve the username. I would potentially try to use the UPN in your credential to see if that works but I have my doubts it will.

[pcgeek86]

I tried using UPN syntax as well, same issue.

Good idea to test resolving the account SID. All of these properly resolve my SID.

[Security.Principal.NTAccount]::new('trevor@trevorsullivan.net').Translate([Security.Principal.SecurityIdentifier])
[Security.Principal.NTAccount]::new('azuread\trevorsullivan').Translate([Security.Principal.SecurityIdentifier])
[Security.Principal.WindowsIdentity]::GetCurrent().User

The fact that it tried to logon using NTLM is suspicious as for me it's using Kerberos.

I agree. I noticed that when you posted earlier.

[pcgeek86]

I think the next thing I'll try is to create another Azure AD user, and attempt to login with that one. I will avoid putting a space in the name (ie. azuread\joe), and omit the last name.

[ethanfrom]

Anyone get this working I am experiencing the same thing.

[donfox007]

facing the same issue ,
win 11 :

Name Value

---

PSVersion 5.1.22000.282
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.22000.282
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

[najki78]

This is a response from Microsoft Support on the issue:

WinRM doesn’t support AAD authentication. It supports only Kerberos, NTLM and certificate authentication.
You can find more details here: Authentication for Remote Connections - Win32 apps | Microsoft Docs - https://docs.microsoft.com/en-us/windows/win32/winrm/authentication-for-remote-connections

The AAD authentication is going to be added with next version of OS.
As a conclusion you have faced with by design behavior.

Guys, do you have maybe some workaround of how to run on-demand, scripts remotely in an environment with AAD joined devices please

[mariuselix]

Have you tried using a local account? With the local account, the only requirement would be that the machines can talk to each other over the network & you could use Negotiate authentication via HTTPS, for some extra security/encryption.

[nkasco]

Have you tried using a local account? With the local account, the only requirement would be that the machines can talk to each other over the network & you could use Negotiate authentication via HTTPS, for some extra security/encryption.

This does work but I think it's besides the point, I don't want to rewrite my entire library of scripts to have every command authenticate with lanadmin... Unless you've got a clever way to wrap it in to make things run remotely under that context?

[pcgeek86]

Have you tried using a local account? With the local account, the only requirement would be that the machines can talk to each other over the network & you could use Negotiate authentication via HTTPS, for some extra security/encryption.

Why would someone want to create a whole bunch of local user accounts and compromise the secure configuration of an enterprise network? That doesn't make any sense.

[nkasco]

@SteveL-MSFT SOS.

This really is a broader question too as I know some things use RPC, others use WinRM, etc. I've been wracking my brain around this for a while now and have had very limited success, even with Azure Connect Seamless SSO going from hybrid joined domain machine to pure AAD joined that has line-of-sight via VPN.

[KofaxLisa]

I experienced the same issue. and struggled a lot. Until I found this post https://learn.microsoft.com/en-us/powershell/scripting/learn/remoting/ps-remoting-second-hop?view=powershell-7.2, this issue is caused by the second hop in Powershell remote. the link mentioned a couple of solutions, I tried the one at https://learn.microsoft.com/en-us/archive/blogs/sergey_babkins_blog/another-solution-to-multi-hop-powershell-remoting, it works. Please have a try.

Making the second hop in PowerShell Remoting - PowerShell

This article explains the various methods for configuring second-hop authentication for PowerShell remoting, including the security implications and recommendations.

Another solution to multi-hop PowerShell remoting

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.