mattjohnsonpint/SimpleImpersonation

Impersonate on Azure AD Joined Device

george-uk opened this issue · 5 comments

I’m using your SimpleImpersonation library for a very small .NET application, however our IT department have recently moved our devices from an On Premises Active Directory to instead making them Azure AD joined. The on-premises domain is still there behind the scenes, however the laptops cannot “see” it directly.

In short, the significance is that in order to now login I need to provide a username in the format of:

AzureAD\firstname.lastname@mydomain.com

but I get an error of Username cannot contain more than one \ or @ character

I see a few internet articles taking about this dual-domain syntax with the runas command. I'm not sure if the LogonUser Win32 API supports it or not. I'll have to investigate.

https://medium.com/@talthemaor/moving-laterally-between-azure-ad-joined-machines-ed1f8871da56

https://chrisatech.wordpress.com/2020/04/24/run-as-a-different-user-add-user-to-local-groups-on-an-azure-ad-joined-machine/

Any link to official docs would be great.

Also, is AzureAD a hard-coded special name that enables this syntax? Or is it just a default that can be changed to anything? In other words, should SimpleImpersonation be testing for if the first part is explicitly AzureAD then allow this? Or is it that this validation check should be removed entirely?

The medium.com article you've linked to above is the one I'd read initially.

I believe AzureAD is indeed a special name, so in theory yes your code could check for that at the start and if so allow a @ further on in the name.

As you've said, I don't know if the Win32 API will support it or not.

I just did a brief test with the code here:

https://docs.microsoft.com/en-us/dotnet/api/system.security.principal.windowsidentity.runimpersonated?view=net-6.0

And that seemed to work, entering AzureAD as the domain and aaa.bbb@mydomain.com as the username

Only thing is, I was testing it on my own device that has already "learned" about the user.

I did wonder actually whether I could just use the code in that article to do the impersonation.

Fixed in version 4.2.0. Note that the tests only test the syntax. I did not actually try to use this against an Azure Active Directory instance. Please give it a try and let me know how it goes. Thanks.

Hi Matt, From the limited testing I've been able to do, this does appear to work. Thanks very much.