As a remote worker, I own two Windows 10 laptops that are wirelessly connected to the same router at home. To log into my personal laptop, I use a Microsoft account, while for my work laptop, I use my company email address, which can also be accessed through DOMAIN\USERNAME. Even though my work laptop is not joined to the domain and is a member of WORKGROUP, it is connected to my company’s Azure AD as shown in the Windows Settings. Although my user account is not visible in the Local Users and Groups, it is listed as a member of the local Administrators group as DOMAIN\USERNAME. While I can VPN to my company network, I generally don’t need to.
Now, I am wondering how to access network shares on my work laptop from my personal laptop. However, when I attempt to connect using \COMPUTERNAME, I am prompted to enter my credentials. Despite trying all possible combinations, I receive an error message saying “The user name or password is incorrect.”
[email protected]
DOMAIN\USERNAME
domain.com\username
MicrosoftAccount\[email protected]
PCNAME\USERNAME
I’ve verified that I can log on locally to my work laptop with [email protected]
or DOMAIN\USERNAME
, so I know I have the correct credentials and password.
3 Answers
Despite asking the same question on two different websites, nobody has been able to offer a solution to the issue as it was originally presented. Based on feedback received from other sources, it appears that connecting to a target computer using domain account credentials is not feasible unless the source computer is connected to Azure AD, even if the target computer is not joined to the domain. One solution is to join the source computer to Azure AD, which can be done by going to Settings, then Accounts, then Access work or school, and finally Connect.
However, since this is a personal laptop, the user does not want to connect it to their work Azure AD. Therefore, the other workaround is to create a local account on the target work computer, grant access to the file share, and then connect using this account. Although this workaround requires creating an additional account that will never be used for local login, it seems to be the better of the two undesirable choices.