Why does Windows 11 say the network username or password is incorrect?

When Windows repeatedly requests a username and password for a network share, it can appear that the credentials are wrong. File Explorer may reopen the Windows Security prompt or report that the username or password is incorrect, even when the account details have been entered correctly.

This error can have several causes. It may involve stored credentials, the account format, permissions, network policy or the way the shared folder has been configured.

This guide focuses particularly on cases where access to \\ComputerName\C$, \\ComputerName\D$ or another Windows administrative share stops working. In these situations, Windows may have accepted the credentials successfully but withheld the administrative rights required to open the drive.

The guide begins with practical checks to determine whether the problem affects an ordinary shared folder or an administrative share. It then explains how SMB sessions, User Account Control remote restrictions, the built-in Administrator account and Windows security policy can affect access.

This guide is intended for people who administer Windows computers. Some checks require local administrator access, and some possible changes affect the security of remote administrative connections.

Where access is required only to business documents or a particular data folder, an ordinary folder share with specific permissions is normally preferable to providing network access to the complete drive.

The problem does not normally mean that files have been deleted or that the drive itself has failed.

Use the links below to jump to the section most relevant to your question.

• What should you check before changing Windows security settings?
• Is the problem affecting an ordinary share or an administrative share?
• What are C$ and other administrative shares?
• Why can Windows reject correct network credentials?
• How can you confirm that SMB is working?
• How do UAC remote restrictions affect local administrators?
• Why is the built-in Administrator account different?
• What changed after Windows 11 25H2 in the case examined?
• How can you compare the previous and current registry settings?
• Which setting most closely restores the previous behaviour?
• Why is LocalAccountTokenFilterPolicy a broader change?
• Why will enabling SMB 1 not help?
• What security controls should be reviewed?
• Frequently asked questions
• When should you get IT support?
• Supporting references
• Further Guidance and Support

Before changing UAC, the registry or SMB settings, first establish which part of the connection is failing. A password prompt does not by itself prove that the password is incorrect.

1. 1. Confirm the exact network path that is failing.

Examples include:

\\ComputerName\SharedFolder

\\ComputerName\C$

\\192.168.1.100\C$

1. 2. Determine whether the same account can open an ordinary shared folder.

   Check whether Windows is reusing an existing network connection or saved credential.

   On the connecting computer, run:

   net use

   This shows existing network connections. To disconnect all current network share sessions before testing again, use:

   net use * /delete /y

   This command disconnects existing mapped shares, so record any mappings that will need to be restored.

   Also open Control Panel > Credential Manager > Windows Credentials and remove any saved entry for the destination computer’s name or IP address.

   When testing again, use the destination computer’s account format, such as:

   COMPUTERNAME\username

   Use the Windows account password rather than a Windows Hello PIN.

   3. Confirm that the computer trying to connect can reach TCP port 445 on the computer hosting the share.

   Use:

   Test-NetConnection 192.168.1.100 -Port 445

   Replace the address with the address of the computer hosting the share.

3. 4. On the computer hosting the share, check whether an SMB session appears for the connecting computer.

Use:

Get-SmbSession | Select-Object ClientComputerName, ClientUserName, Dialect, NumOpens

1. 5. If the problem involves C$, D$ or another hidden administrative share, confirm that those shares still exist.

Use:

Get-SmbShare | Where-Object Special -eq $true | Select-Object Name, Path

1. 6. Confirm whether the account being used is the built-in Administrator account, even if it has been renamed.

Use:

Get-LocalUser | Select-Object Name, Enabled, SID

The built-in Administrator account has a security identifier ending in -500.

1. 7. Check the current values of EnableLUA, ConsentPromptBehaviorAdmin, PromptOnSecureDesktop, FilterAdministratorToken and LocalAccountTokenFilterPolicy before changing anything.
   8. Keep SMB 1 disabled while carrying out these checks. An administrative token problem is not corrected by enabling an older SMB protocol.

If an SMB session appears with the expected account and a modern dialect such as SMB 3.1.1, Windows has progressed beyond basic network connectivity and protocol negotiation. The remaining problem is more likely to involve authorisation, policy or permissions.

The same Windows credentials message can appear in different circumstances. Identifying the type of share helps prevent an unrelated security setting from being changed unnecessarily.

An ordinary share normally points to a particular folder that someone has deliberately shared. For example:

\\ComputerName\Accounts

\\ComputerName\SharedDocuments

Access to an ordinary share depends on the share permissions, the NTFS permissions on the folder and the identity used for the connection.

An administrative share normally points to the root of a drive or a Windows administration location. Examples include:

\\ComputerName\C$

\\ComputerName\D$

\\ComputerName\ADMIN$

Administrative shares require administrative authorisation on the destination computer.

If ordinary shared folders work but C$ or D$ does not, the problem is unlikely to be basic network connectivity. UAC remote restrictions or the administrative token supplied to the account become more relevant.

If ordinary shares and administrative shares both fail, investigate stored credentials, account naming, permissions, firewall rules, network profile and SMB configuration before changing an administrative UAC policy.

Windows normally creates hidden administrative shares for local drives and system administration. They are different from folders that someone has shared manually.

Examples include:

C$ for the root of the C drive.

D$ for the root of the D drive.

ADMIN$ for the Windows installation folder.

IPC$ for interprocess communication used during network connections.

The dollar sign makes the share hidden from ordinary network browsing. It does not make the share anonymous or remove the requirement for administrative authorisation.

Access to C$ therefore requires more than permission to use an ordinary shared folder. The network session must have sufficient administrative rights on the computer hosting the share.

Windows makes two separate decisions during a network connection.

The first decision is authentication:

Is this a valid account, and is the password correct?

The second decision is authorisation:

What is this authenticated account allowed to open or change?

A correct local administrator username and password can establish an SMB session. Windows may then limit the administrative token supplied to that remote session.

The account is recognised, but the session does not have the rights needed to open C$, D$ or another administrative share. File Explorer may respond by showing the credentials window again, which makes the problem look like a password failure.

This distinction is useful when troubleshooting. Repeatedly changing or re-entering the password will not resolve an authorisation or token filtering problem.

The same credentials message can also appear for other reasons. The existence of an SMB session using the expected account is therefore an important diagnostic detail rather than proof that every part of the connection has succeeded.

A small number of PowerShell checks can distinguish a network or SMB failure from a later authorisation failure.

On the connecting computer, test TCP port 445:

Test-NetConnection 192.168.1.100 -Port 445

A result of:

TcpTestSucceeded : True

confirms that the SMB service is reachable over the network.

On the computer hosting the share, check the active sessions:

Get-SmbSession | Select-Object ClientComputerName, ClientUserName, Dialect, NumOpens

A result similar to the following is significant:

ClientComputerName : 192.168.1.15

ClientUserName : COMPUTERNAME\Administrator

Dialect : 3.1.1

NumOpens : 0

This shows that:

1. The connecting computer reached the SMB service.
2. SMB 3.1.1 was negotiated.
3. Windows associated the session with the stated account.
4. No files or shares were successfully opened through that session.

The server configuration can also be checked with:

Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, EnableSMB2Protocol, Smb2DialectMin, Smb2DialectMax, RequireSecuritySignature, EnableSecuritySignature

A typical modern configuration has SMB 1 disabled and SMB 2 or SMB 3 enabled.

When the expected user and SMB 3.1.1 session are already visible, enabling SMB 1 is not a relevant response.

User Account Control affects more than the prompts displayed during an interactive Windows session. Windows also applies UAC restrictions to some remote network logons.

A local account may belong to the Administrators group, but Windows can provide that account with a filtered token when it connects remotely. The account remains valid, but its administrative privileges are removed from the network session.

This is a protective mechanism. It reduces the ability of malicious software or someone with compromised local credentials to use administrative rights remotely across other computers.

An interactive user can normally respond to a UAC prompt when an action requires elevation. An SMB network connection cannot display an interactive elevation prompt on the destination computer.

The practical result is that an ordinary shared folder may remain accessible while an administrative share such as C$ is refused.

This behaviour is not new to Windows 11 25H2. UAC remote restrictions have existed since much earlier versions of Windows.

Every Windows installation has a built-in Administrator account. Renaming the account does not change its underlying identity.

The account can be identified by a security identifier ending in:

-500

For example:

S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-500

The policy named:

User Account Control: Admin Approval Mode for the Built-in Administrator account

is represented in the registry by:

FilterAdministratorToken

The relevant values are:

0 or value absent: Admin Approval Mode for the built-in Administrator account is disabled.

1: Admin Approval Mode for the built-in Administrator account is enabled.

When Admin Approval Mode is enabled for this account, its behaviour changes. In a remote network connection, the account can become subject to token filtering that prevents access to administrative shares.

This setting applies specifically to the built-in account identified by the SID ending in -500. It should not be confused with settings that affect every local administrator account.

In the computer examined for this guide, access to the administrative drive shares worked before a Windows 11 25H2 upgrade and stopped afterwards.

The previous Windows registry was available under C:\Windows.old, allowing the relevant settings to be compared.

The comparison showed:

The account used for the connection was confirmed as the renamed built-in Administrator account because its SID ended in -500.

The previous absence of FilterAdministratorToken meant that its effective value was the default value of 0. In the current installation, the value was explicitly set to 1.

This was the material UAC policy difference identified between the previous and current Windows installations.

The SMB evidence also showed that the client had established an SMB 3.1.1 session using the expected account, but no files were open. This was consistent with successful authentication followed by insufficient administrative authorisation.

These findings provide strong evidence that enabling Admin Approval Mode for the built-in Administrator account caused the loss of administrative share access on that computer.

They do not establish that every Windows 11 25H2 upgrade applies the same change. The value could have been introduced by the feature upgrade, a migrated or refreshed security policy, management software or another configuration process operating during or after the upgrade.

It is therefore accurate to say that the problem appeared after the upgrade and that the registry comparison identified the policy change. It should not be described as a confirmed universal Windows 11 25H2 defect.

Where C:\Windows.old is still available, the previous SOFTWARE registry hive can be mounted temporarily and queried.

Open Command Prompt as Administrator and use:

reg load HKLM\OldSoftware "C:\Windows.old\Windows\System32\Config\SOFTWARE"

This mounts the old SOFTWARE hive under:

HKEY_LOCAL_MACHINE\OldSoftware

It is not simply a read only copy placed in memory. The mounted key remains associated with the old registry hive file, so changes made beneath HKLM\OldSoftware could be written back to that file.

For comparison purposes, use query commands only.

Check the previous values:

reg query "HKLM\OldSoftware\Microsoft\Windows\CurrentVersion\Policies\System" /v EnableLUA

reg query "HKLM\OldSoftware\Microsoft\Windows\CurrentVersion\Policies\System" /v ConsentPromptBehaviorAdmin

reg query "HKLM\OldSoftware\Microsoft\Windows\CurrentVersion\Policies\System" /v PromptOnSecureDesktop

reg query "HKLM\OldSoftware\Microsoft\Windows\CurrentVersion\Policies\System" /v FilterAdministratorToken

reg query "HKLM\OldSoftware\Microsoft\Windows\CurrentVersion\Policies\System" /v LocalAccountTokenFilterPolicy

Check the current values by repeating the queries beneath:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

When the comparison has been recorded, unmount the old hive:

reg unload HKLM\OldSoftware

Do not delete Windows.old until any required comparison or recovery work has been completed.

The safest response depends on why access to the drive root is required.

Where access is needed only to business documents or a particular data folder, the preferred approach is to create an ordinary shared folder and assign suitable share and NTFS permissions. This avoids giving routine network access to an entire drive.

Where access to administrative shares is genuinely required and the account is confirmed as the renamed built-in Administrator account, the narrower policy change is to disable:

User Account Control: Admin Approval Mode for the Built-in Administrator account

Open:

secpol.msc

Then go to:

Local Policies

Security Options

Set:

User Account Control: Admin Approval Mode for the Built-in Administrator account

to:

Disabled

The corresponding registry value is:

FilterAdministratorToken = 0

It can be set from an elevated Command Prompt with:

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v FilterAdministratorToken /t REG_DWORD /d 0 /f

Alternatively, the value can be removed so that Windows uses the default behaviour:

reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v FilterAdministratorToken /f

Restart the computer after changing the policy.

On the connecting computer, clear existing SMB sessions:

net use * /delete /y

Then test the administrative share without placing the password directly in the command:

net use \\ComputerName\C$ /user:"ComputerName\AdministratorName" *

The asterisk makes Windows request the password separately.

After restarting, confirm that the setting remains disabled. If FilterAdministratorToken returns to 1, Group Policy, Intune, another management system or security software may be enforcing it.

This setting should not be changed merely to avoid creating appropriate folder shares. It should be used only where full remote administration is a genuine requirement.

Another registry value commonly mentioned in Remote UAC troubleshooting is:

LocalAccountTokenFilterPolicy

Setting it to:

1

allows qualifying local administrator accounts to receive elevated tokens during remote connections.

This is broader than changing FilterAdministratorToken for the built-in Administrator account. It can affect other local administrator accounts as well.

For that reason, it is not the most targeted correction where:

1. 1. The affected account is confirmed as the built-in RID 500 Administrator account.
   2. The previous configuration had FilterAdministratorToken disabled.
   3. The requirement is to recreate that specific previous behaviour.

LocalAccountTokenFilterPolicy = 1 may be required by some remote administration, deployment or authenticated scanning tools. Where it is used, the security consequences should be considered alongside firewall restrictions, password uniqueness, account scope and monitoring.

It should not be described as simply turning off the ordinary UAC slider. It changes the token made available to local administrators during remote network connections.

SMB controls how Windows carries file sharing traffic across the network. UAC token filtering controls the authority available to the account after it connects.

These are different stages of the connection.

If Get-SmbSession already shows:

Dialect : 3.1.1

then SMB 3.1.1 has negotiated successfully.

Enabling SMB 1 will not restore the administrative token required for C$. It only makes an obsolete file sharing protocol available in addition to the modern protocols already working.

SMB 1 should remain disabled unless an essential legacy device has no supported alternative and the risk has been assessed separately.

Do not disable SMB 2 or SMB 3 when investigating this problem.

Administrative shares provide extensive access to a Windows computer. Restoring that access should therefore be accompanied by controls that reduce unnecessary exposure.

Use a strong, unique password for the local administrator account. Do not reuse the same administrator password across several computers.

Where the environment is managed appropriately, Windows LAPS can provide unique, rotated local administrator passwords.

Limit File and Printer Sharing firewall rules to trusted local networks, management devices or required subnets where practical.

Keep SMB 1 disabled.

Use ordinary folder shares with specific permissions where full drive access is not required.

Avoid using the built-in Administrator account for everyday work.

Review active administrative access periodically and remove settings that are no longer required.

Monitor for unexpected remote logons, account use and configuration changes.

A single registry value is not a complete security design. Technology, Windows behaviour and organisational requirements change over time. Administrative access controls should be reviewed periodically and used as part of a layered security approach.

Does the repeated password prompt prove that the password is wrong?

No. Windows may have accepted the credentials and created an SMB session before refusing access to the administrative share.

Check Get-SmbSession and the relevant Windows security policy before concluding that the password is incorrect.

Why can I access an ordinary shared folder but not C$?

An ordinary folder share depends on the permissions assigned to that folder. C$ is an administrative share and requires an administrative token on the destination computer.

Windows may authenticate a local administrator account but provide a filtered token that is not sufficient for C$.

Is FilterAdministratorToken new in Windows 11 25H2?

No. The setting belongs to the long established UAC and Admin Approval Mode framework.

In the case examined here, the value changed after the 25H2 upgrade, but the underlying Windows feature is not new.

Does selecting Never notify in Control Panel completely disable UAC?

Not necessarily.

In the examined system, the previous and current installations both had:

EnableLUA = 1

ConsentPromptBehaviorAdmin = 0

PromptOnSecureDesktop = 0

This configuration suppresses the ordinary administrator consent prompt, but the UAC architecture remains enabled because EnableLUA is still set to 1.

Will enabling SMB 1 restore access to C$?

No, not where SMB 3.1.1 is already negotiating successfully.

SMB 1 does not correct a filtered administrator token.

Which registry change is narrower?

For the built-in Administrator account identified by a SID ending in -500, setting FilterAdministratorToken to 0 is narrower than setting LocalAccountTokenFilterPolicy to 1.

The latter can affect other local administrator accounts.

Is a restart required?

A restart is recommended after changing the UAC policy or registry value.

Existing SMB sessions should also be cleared before testing again.

Can I share files without changing these UAC settings?

Yes. Create an ordinary folder share and grant the required account suitable share and NTFS permissions.

This is generally preferable when access is needed only to specific data rather than the complete drive.

Does this guide apply to every network password error?

No. The same error can be caused by stored credentials, account naming, permissions, firewall settings, network policy or other SMB configuration issues.

The UAC and built-in Administrator explanation is particularly relevant when ordinary sharing works, the expected SMB session is established and only administrative shares are refused.

Further investigation is appropriate when the expected account does not appear in Get-SmbSession, the administrative shares are missing, the relevant policy returns after being changed or several computers are affected.

Support may also be required where:

1. 1. The computer is domain joined, Microsoft Entra joined or managed through Intune.
   2. Group Policy or another management platform may be enforcing the setting.
   3. The affected account does not have a SID ending in -500.
   4. Port 445 is not reachable.
   5. The SMB session uses an unexpected account.
   6. Access fails to ordinary shares as well as administrative shares.
   7. Share or NTFS permissions may have changed.
   8. The computer is part of a wider business network where privileged access changes need to be reviewed across several devices.

For a problem limited to one Windows computer, see our computer support and repairs page.

Where the issue affects shared systems, several users or a wider business network, see our structured IT support page.

Where the main concern is privileged access, password reuse, remote administration or lateral movement risk, review our security and resilience planning guidance.

The following Microsoft documentation provides further technical information about the Windows behaviour described in this guide.

User Account Control and remote restrictions

User Account Control settings and configuration

Get-SmbSession

Problems can occur when administrative shares are missing

This guide forms part of a broader layered security approach. For structured guidance on security and resilience planning, see our Security and Resilience page.

For information about practical implementation and ongoing support, you can review our IT services and local IT support coverage across London, Hertfordshire, and Essex.

Return to all guides

Author
Elías Sánchez
IT Support Consultant
Evening Computing
London, United Kingdom

This guide was prepared by Elías Sánchez with research and drafting assistance from AI tools. All technical content has been reviewed and adapted for clarity and accuracy.

Last reviewed
25 June 2026