Let’s look at how to log on to Windows with a local account instead of a domain account. When you enter a user name on a sign-in screen of a domain-joined computer, by default it is assumed that you are logging on as a domain user. If you need to log into Windows as a local user, there’s a little trick that many people don’t know about.
Table of Contents
How to Log into a Local Account on Domain Computer
After the computer is joined to the Active Directory domain, you can sign in under the domain or local user account. By default, Windows tries to log you using a domain account. If you want to sign in to your computer as a local user, click the ‘How to log on to another domain’ button on the Welcome screen. The following tip will appear:
Type domain namedomain user name to sign in to another domain.
Type NY-FS01\local user name to sign in to this PC only (not a domain).
This message contains the hostname of your computer (NY-FS01 in our case). You can login to your local account (for example, Administrator) by typing NY-FS01\Administrator in the User name filed. If your computer name is quite long, typing it in can be a real challenge!
Fortunately, a simple trick allows you to sign in to a local account without typing the full hosname.
The dot ( . ) character in Windows is an alias symbol for the local computer:
- Type .\ in the username field. The domain below will disappear, and switch to your local computer name without typing it;
- Then, after the .\, enter your local username with which you want to log in (for example, .\myusername).
This trick will allow you to log on to the local account of a domain-joined computer on any desktop version of Windows and Windows Server.
Tip. You can use the same trick to access a remote computer as a local user via the SMB (shared folder) protocol.
Show All Local Users on Windows Login Screen
You can display a list of enabled local users on the Windows logon screen. This will allow your users to click directly on a local user name rather than having to type it in. You can enumerate all local users on the Windows Logon Screen via the Group Policy.
- Open the Local Group Policy Editor – gpedit.msc;
- Go to Computer Configuration > Administrative Templates > System > Logon;
- Enable the policy “Enumerate local users on domain-joined computers”;
- Restart your computer to apply the new policy settings;
- Press Ctrl+Alt+Delete on your Windows Welcome Screen, and check the local account list.
Only members of the local Administrators, Backup Operators, and Users groups are allowed to log on locally. Other users will not be able to log in locally and will face the error:
The sign-in method you’re trying to use isn’t allowed.
You can configure the list of users and/or groups allowed to log on locally by using the allow log on locally GPO option.
Local Logon on Active Directory Domain Controllers
You can’t log on to a domain controller with a local Windows account. This is because after promoting the member server to DC (using the dcpromo command), the local Security Account Manager (SAM) database on Windows is no longer available. The DSRM Administrator is the only local account on the Active Directory domain controller.
You can boot your domain controller into Directory Services Restore Mode (DSRM) by pressing the F8 key repeatedly immediately after the BIOS POST screen, before the Windows logo appears. Then use the up/down arrow keys to select Directory Services Restore Mode.
Or you can run msconfig.exe, go to the Boot tab and select Safe boot > Active Directory repair.
You can now log on to the DC using the local DSRM administrator account.
Using Remote Desktop (RDP) with a Local Account
The trick above for logging on to a domain-joined Windows device under a local account using the .\Administrator account format does not work if you logging into a remote computer over RDP.
When you specify .\administrator in the Remote Desktop Connection client window (mstsc.exe), your RDP client resolves that to <your_current_computername>\Administrator, and not to <remote_server _name>\Administrator.
Accordingly, if the passwords of the local and remote users are different, you cannot RDP to a remote computer.
When you use a local Windows account to connect to a remote domain computer via RDP, you can use one of the following formats to specify the user name:
- Specify the hostname of the remote computer:
wks323221s\administrator
- Specify the IP address of the remote computer:
192.168.100.221\administrator
- Use shorthand local instead of remote machine name:
local\administrator
In all these cases, the RDP client will use the local Windows user on the remote computer for authentication.
Hint. Only members of the local Remote Desktop Users and Administrator groups can access computers via RDP. All other users will see an error: To sign in remotely you need the right to sign in through Remote Desktop Services.
When administering Windows environments, you will undoubtedly need to log on with a local user account at some point to perform local administrator tasks, such as fixing a broken domain trust relationship. You can easily log in with a local account using the simple trick provided.
3 comments
It’s not possible as far as I can tell to remotely connect to the LOCAL account of a Windows 10 machine using the Remote Desktop Client for Macintosh (at least not from Catalina). No matter how you specify the Windows10 machine name, it ALWAYS uses the domain account! Using the .\ shortcut does not work. Specifying the machine name first with a backslash like “MyMachineName\MyUserName” does not work either – it completely ignores “MyMachineName” and assumes you want to login to the domain account for that machine! The only fix is to unjoin the remote windows10 machine from the domain and set it back to a workgroup name (the same name as the domain). I’ve reported this bug to Microsoft (bug in Mac RDP Client). It worked just fine in Mavericks, but alas, MS, lately has been wreaking havoc with, formerly working, software (all their time is spent on their insanely expensive cloud services and not with their Operating Systems nor with local versions of Office!).
Thank you, well explained
The . trick was absolutely brillant! Checked many forums and finally found it!
Comments are closed.