Why can a local administrator of a windows 11 (or 10) freely access the default shared folders of windows server 2016 (or 2022) on the same local area network?

George Fang 25 Reputation points
2026-05-28T16:49:21.83+00:00

We have a simple windows domain consisting of some windows server 2016s, 2022s and some windows 11 workstations. We also have some windows 11 workstations that are not domain joined on the same local area network. If I login on to one those non domain joined windows 11 computers as a local administrator, then I can freely access default shared folders like c$, admin$ and others of domain joined windows server 2016s and 2022s. Why is this allowed? It looks to me a huge security issue. I do not remember this was possible in the past. It seems to me that this starts happening recently. How can I fix this security issue?

Thanks,

George.

Windows for business | Windows Server | Networking | Network connectivity and file sharing
0 comments No comments

Answer accepted by question author
HLBui 13,020 Reputation points Independent Advisor
2026-05-29T05:07:35.35+00:00

Good day George Fang

Windows doesn’t really care where the credentials come from, it just checks if the username/password pair matches an account with admin rights on the target machine. That’s why your local admin creds on a non‑domain box can still unlock those hidden administrative shares like c$ and admin$. Domain logons are different because Kerberos/NTLM explicitly require the domain context, so you can’t just “guess” your way in without specifying the domain. But with local accounts, it’s a straight NTLM handshake: if the password matches, you’re in.

Your workaround of making sure local admin passwords don’t match across machines is actually a solid quick fix it prevents that “pass‑the‑hash” style access. Longer term, you’ll want to look at Local Administrator Password Solution (LAPS) or Entra ID joined devices to randomize and manage local admin credentials securely. You can also disable or restrict default admin shares if you don’t need them, or enforce stricter firewall rules to block SMB traffic from non‑domain machines.

Was this answer helpful?

1 person found this answer helpful.
0 comments No comments

2 additional answers

Sort by: Oldest
  1. AI answer

    2026-05-28T16:49:41.12+00:00

    Local administrative shares such as C$, ADMIN$, and IPC$ are created by default on Windows Server and are intended for remote administration. By design, if a user connects over the network using credentials that are members of the local Administrators group on the server, that user can access these administrative shares.

    In the scenario described, the key factor is not that the workstation is non–domain-joined, but that the credentials used over the network are recognized as administrative on the target server. For example:

    • If the same local administrator account (same name and password) exists on both the non-domain Windows 11 workstation and the Windows Server, Windows can treat that as the same security principal and grant access.
    • Administrative shares are hidden (C$, ADMIN$) but not restricted to domain accounts; they are available to any account that has administrative rights on the server.

    This behavior is not new; administrative shares have long been used for remote management and are automatically created on Windows Server.

    To mitigate or remove this access:

    1. Verify and control administrative shares
      • On the server, check whether the default administrative shares are enabled:
        1. Open Registry Editor.
        2. Navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters.
        3. Check the AutoShareServer (for servers) or AutoShareWks (for workstations) values.
        4. If they exist and are set to 0, administrative shares are disabled; if set to 1, they are enabled.
        5. If these values do not exist, the default behavior is to automatically create the administrative shares.
      • After changes, restart the server and verify with net share that Admin$, C$, and IPC$ are or are not present as desired.
      • Be aware that disabling administrative shares can impact legitimate remote administration and some services.
    2. Harden who can access administrative shares
      • Ensure that only trusted accounts are members of the local Administrators group on each server.
      • Avoid reusing the same local administrator name/password combinations on multiple machines, especially between servers and non-domain workstations.
      • Prefer domain accounts with least-privilege assignments for administration.
    3. Monitor and secure SMB/file services
      • Review SMB/file service security options (for example, SMB signing, NTLM restrictions, and other SMB security enhancements) to ensure that only authenticated and authorized users can access shares.

    These steps reduce or eliminate the ability of local administrators on non-domain machines to access default administrative shares on domain-joined servers, while still allowing necessary management where explicitly configured.


    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

  2. HLBui 13,020 Reputation points Independent Advisor
    2026-05-28T17:47:14.9333333+00:00

    Hi George Fang

    By default, Windows servers expose administrative shares like c$ and admin$, and anyone logging in with local admin credentials on the same LAN can hit those shares if the authentication matches up. That’s why your non‑domain joined Windows 11 box, when logged in as a local admin, is able to connect it’s basically being treated as a trusted admin account. It feels like a security hole, but technically it’s “by design” behavior that’s been around for a long time, though changes in SMB and credential handling in newer builds may have made it more noticeable recently.

    The fix is to lock down those administrative shares: you can disable them via registry or group policy, or restrict access by tightening SMB settings and firewall rules. Another good move is to enforce network access restrictions so only domain accounts can connect. If you want to be extra strict, disable administrative shares altogether and rely on explicitly defined shares with controlled permissions. Also, double‑check that your servers aren’t allowing local accounts to authenticate over the network that’s a common oversight.

    If this explanation helps you understand and mitigate the issue, please hit “Accept Answer” so we know it solved your problem

    Was this answer helpful?


Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.