Disable Windows Network Discovery C:\Users Sharing

Enabling network discovery in Windows automatically exposes the C:\Users directory through administrative shares created by the Server service, allowing full network access without explicit sharing configuration. This default behavior is a security concern that can be permanently disabled through registry modifications, service configuration, or Group Policy settings, even surviving Windows reinstallation.

---

Contents

• Understanding Network Discovery and Administrative Shares in Windows
• Why C:\Users Directory Becomes Visible with Network Discovery
• Security Implications of Default Administrative Shares
• Method 1: Registry-Based Solution for Permanent Disabling
• Method 2: Service-Based Disabling Approach
• Method 3: Group Policy Solution for Enterprise Environments
• Best Practices for Network Security and Share Management

---

Understanding Network Discovery and Administrative Shares in Windows

Network discovery is a Windows networking feature that allows your computer to find other devices and resources on the network. When you enable network discovery, Windows automatically turns on several underlying services, including the Server service, which manages file and printer sharing. This is where the automatic sharing behavior originates - the Server service creates hidden administrative shares by default, including the C:\Users directory.

Administrative shares are special hidden shares automatically created by Windows for administrative purposes. They have a dollar sign ($) at the end of their name, making them invisible in normal browsing but still accessible if you know the exact path. The C:\Users directory becomes visible as "C$" and “Users$” administrative shares when network discovery is enabled, as documented in Microsoft’s troubleshooting guide.

These shares are not just simple folder shares - they’re deeply integrated into Windows networking architecture and are created regardless of whether you’ve explicitly configured any file sharing. The relationship between network discovery and administrative sharing can be confusing for many users, as enabling one feature automatically activates the other without clear notification.

How Network Discovery Enables Sharing

When you enable network discovery through the Network and Sharing Center, Windows performs several actions behind the scenes:

1. Turns on the SSDP Discovery service to discover UPnP devices
2. Enables the Function Discovery Provider Host service
3. Activates the Function Discovery Resource Publication service
4. Starts the Server service (srvnet) which creates administrative shares

The Server service is the key component here. It’s responsible for managing all SMB file sharing on Windows and automatically creates administrative shares for each drive letter and special directories like C:\Users. This is why you see your C:\Users directory suddenly accessible on the network even though you didn’t specifically share it.

---

Why C:\Users Directory Becomes Visible with Network Discovery

The C:\Users directory becomes automatically visible and accessible on the network due to how Windows implements administrative shares through the Server service. This behavior is intentional from a system administration perspective but creates significant security risks in many environments.

Administrative shares are created with specific permissions that grant access to certain user groups. The C$ administrative share (representing the C drive) and the Users$ share (representing the C:\Users directory) are created with permissions that allow authenticated users to access them. This means any user who can authenticate to the system has potential access to these shares.

This behavior is documented in Microsoft’s official documentation on file sharing, which explains how network discovery enables both file sharing and administrative shares simultaneously.

Permission Layering and Access Control

The seemingly “full access” to C:\Users through network shares doesn’t mean users can bypass filesystem permissions. Instead, Windows implements a permission layering system where:

1. Share permissions control access at the network level
2. NTFS permissions control access at the file system level

For administrative shares, the share permissions typically grant “Change” access to the “Authenticated Users” group. However, the actual access level is limited by the more restrictive NTFS permissions on the target directories. This means a network user might have “Change” permission at the share level but only “Read” permission on specific files at the NTFS level.

This dual permission system is often misunderstood. Users who don’t have appropriate NTFS permissions won’t be able to access files even if they can connect to the administrative share. However, the fact that the share exists at all creates a security vulnerability, as it reveals the directory structure and provides an attack surface for brute force or other credential-based attacks.

Why This Behavior Persists Across Reinstalls

The automatic creation of administrative shares persists even after Windows reinstallation because it’s controlled by:

1. Registry settings stored in the system hive
2. Service configurations that are reset to default during installation
3. Group Policy objects that may be applied after installation

These system-level configurations are designed to provide consistency in enterprise environments where administrative shares may be needed for legitimate system administration tasks. However, in home or small office environments, this default behavior often represents an unnecessary security risk.

---

Security Implications of Default Administrative Shares

The automatic sharing of C:\Users with network discovery enabled creates significant security implications that many users are unaware of. Administrative shares like C$ and Users$ expose system information and provide potential entry points for unauthorized access.

As discussed in the Petri article on disabling administrative shares, these shares reveal system information to anyone on the network who can discover them. Attackers can use these shares to gather reconnaissance information about your system, including drive structures, user directories, and potentially sensitive data.

Information Disclosure Risks

When network discovery is enabled and administrative shares are active, anyone on the same network can:

1. Browse available shares and see the existence of C$ and Users$
2. Attempt to access these shares using valid credentials
3. Discover user account names through the Users$ share
4. Map drives to these administrative shares if they have appropriate permissions

This information disclosure is particularly dangerous in network environments where users have reused credentials or where weak password policies exist. The Users$ share, in particular, can reveal all user account names on the system, providing attackers with half the information needed for credential-based attacks.

Attack Surface Expansion

Administrative shares expand the attack surface of your system in several ways:

1. Brute force attacks: Attackers can attempt to guess passwords for existing user accounts by connecting to administrative shares
2. Pass-the-hash attacks: If compromised credentials are available, attackers can use them to access administrative shares
3. Lateral movement: In network environments, compromised administrative shares can serve as jumping points to other systems
4. Data exfiltration: If proper access controls aren’t in place, sensitive data could be copied out through these shares

The security implications are particularly concerning in unsecured networks like public Wi‑Fi or office networks with lax security policies. As noted in the O’Reilly Network Security Hacks resource, administrative shares have been a known security concern for years and are commonly exploited in network attacks.

Mitigation Strategies

To address these security concerns, consider the following strategies:

1. Disable administrative shares entirely using the registry methods described later
2. Implement strong password policies to reduce the effectiveness of brute force attacks
3. Network segmentation to limit which devices can see administrative shares
4. Regular security audits to monitor for unauthorized access attempts
5. Disable network discovery on systems that don’t need to be discovered

The registry-based solutions provide the most comprehensive protection by completely removing the administrative share creation capability, while other approaches focus on access control rather than prevention.

---

Method 1: Registry-Based Solution for Permanent Disabling

The most reliable method to permanently disable administrative shares, even across Windows reinstalls, is through registry modifications. This approach directly prevents the Server service from creating administrative shares by modifying system registry values.

As detailed in the WinAero guide, registry modifications provide a persistent solution that survives system reboots and even Windows reinstallation when the appropriate registry keys are set.

Step-by-Step Registry Modification

Follow these steps to permanently disable administrative shares:

1. Open Registry Editor:

• Press Win + R to open the Run dialog
• Type regedit and press Enter
• Navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

2. Create or Modify Registry Values:

• In the right pane, locate the following values:

• AutoShareWks (for workstation/Windows 10/11)

• AutoShareServer (for server versions)

• If these values don’t exist, create them:

• Right-click in the right pane → New → DWORD (32-bit) Value

• Name the value AutoShareWks for workstations or AutoShareServer for servers

• Double-click the new value and set it to 0 to disable automatic sharing

• Set it to 1 to re-enable (default)

3. Additional Registry Settings:

• Create another DWORD value named AutoShareGuest
• Set it to 0 to prevent guest access to shares
• This enhances security by requiring authentication for all share access

4. Restart the Server Service:

• Open Command Prompt as Administrator
• Run: net stop server then net start server
• Alternatively, restart your computer

Verifying the Registry Fix

After applying the registry changes:

1. Check Administrative Shares:

• Open File Explorer on another computer on the same network
• Try to access \\your-computer-name\C$ or \\your-computer-name\Users$
• You should receive an “Access Denied” error or “Network path not found” error

2. Confirm Registry Values:

• Reopen the registry editor and navigate to the same key
• Verify that AutoShareWks or AutoShareServer is set to 0

This registry modification creates a permanent solution that will survive Windows reinstallation because these registry keys are part of the system configuration that persists across reinstalls. The values are reset to their defaults (1) during Windows setup, so you’ll need to reapply this fix after a fresh installation.

Alternative Registry Method

Another approach is to modify the AutoShareWks value in the same registry location:

1. Navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
2. Create or modify the AutoShareWks DWORD value
3. Set its data to 0 to disable administrative shares
4. Restart the Server service or reboot the system

This method is described in detail in the SysProbs article, which provides additional context on why this registry value specifically targets workstation-based administrative share creation.

Both registry methods are effective and provide a permanent solution to the automatic sharing of C:\Users when network discovery is enabled.

---

Method 2: Service-Based Disabling Approach

An alternative approach to disabling automatic administrative shares is to configure the Server service itself. While this method doesn’t provide the same level of persistence as registry modifications, it can be effective in certain situations and might be easier for less technical users to implement.

The Server service (srvnet) is responsible for creating and managing all file shares, including administrative shares. By modifying how this service operates, we can prevent it from creating administrative shares while potentially maintaining other sharing functionality.

Disabling the Server Service

The most direct service-based approach is to disable the Server service entirely:

1. Open Services:

• Press Win + R to open the Run dialog
• Type services.msc and press Enter

2. Locate the Server Service:

• Scroll down and find “Server” in the list
• Double-click to open its properties

3. Configure the Service:

• Set “Startup type” to “Disabled”
• Click “Stop” to stop the service if it’s running
• Click “Apply” and “OK”

4. Restart Your Computer:

• A restart is required for the changes to take full effect

After disabling the Server service, your computer will no longer create any file shares, including administrative shares. However, this approach has significant drawbacks:

• You won’t be able to share any folders intentionally
• Network discovery may not function correctly
• Some network-dependent applications may fail
• The service will be re-enabled after a Windows update that resets service configurations

Modifying Service Dependencies

A less disruptive approach is to modify the service dependencies:

1. Open Registry Editor:

• Press Win + R, type regedit, and press Enter
• Navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\srvnet

2. Modify the DependOnService Value:

• Double-click the DependOnService multi-string value
• Remove all dependencies (leave it empty or delete the value)
• Click “OK”

3. Restart the Server Service:

• Open Command Prompt as Administrator
• Run: net stop server then net start server

This approach prevents the Server service from starting automatically and creating shares, but allows you to start it manually when needed for legitimate file sharing.

Service Configuration Limitations

While service-based approaches can temporarily disable administrative shares, they have several limitations compared to registry modifications:

1. Not Persistent Across Reboots: Service configurations can be reset by Windows updates
2. May Affect Other Functionality: Disabling the Server service entirely impacts legitimate file sharing
3. Requires Manual Intervention: Some methods require you to restart services after each boot
4. Not Survive Windows Reinstallation: Service configurations are reset to defaults during Windows setup

For these reasons, service-based approaches are generally recommended as temporary solutions or for situations where registry modifications aren’t feasible. The most reliable permanent solution remains the registry-based methods described in the previous section.

---

Method 3: Group Policy Solution for Enterprise Environments

For enterprise environments using Windows Pro, Enterprise, or Education editions, Group Policy provides a centralized method to disable administrative shares across multiple computers. This approach is particularly valuable in organizations with many computers that need consistent security configurations.

Group Policy allows administrators to enforce registry settings, service configurations, and security settings across an entire domain or organizational unit. By configuring appropriate Group Policy Objects (GPOs), you can ensure that administrative shares are disabled consistently across all managed computers.

Creating a Group Policy Object

Follow these steps to create a Group Policy Object that disables administrative shares:

1. Open Group Policy Management Console:

• On a domain controller or computer with Remote Server Administration Tools (RSAT)
• Press Win + R, type gpmc.msc, and press Enter

2. Create a New GPO:

• Right-click your domain or appropriate OU
• Select “Create a GPO in this domain, and Link it here…”
• Name the GPO something descriptive like “Disable Administrative Shares”
• Click “OK”

3. Configure Registry Settings via GPO:

• Right-click the new GPO and select “Edit”
• Navigate to: Computer Configuration → Preferences → Windows Settings → Registry
• Right-click in the right pane → New → Registry Item

4. Set Registry Properties:

• Action: Update
• Hive: HKEY_LOCAL_MACHINE
• Key path: SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
• Value name: AutoShareWks
• Value type: DWORD
• Value data: 0
• Check “Remove this item when it is no longer applied”
• Click “OK”

5. Link the GPO:

• Close the Group Policy Management Editor
• Ensure the GPO is linked to the appropriate OU containing target computers
• Run gpupdate /force on target computers to apply the policy immediately

Verifying Group Policy Application

After deploying the Group Policy:

1. Check Registry Values:

• On a target computer, open Registry Editor
• Navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
• Verify that AutoShareWks is set to 0

2. Check Event Logs:

• Open Event Viewer → Windows Logs → Application
• Look for events related to Group Policy processing
• Confirm that the policy was applied successfully

3. Test Administrative Shares:

• Try to access administrative shares from another computer
• Verify that access is denied

Advantages of Group Policy Approach

The Group Policy approach offers several advantages in enterprise environments:

1. Centralized Management: Configure once, apply to many computers
2. Consistent Enforcement: Ensures all computers have the same security settings
3. Automatic Updates: Policy changes propagate to all managed computers
4. Audit Trail: Group Policy processing creates event logs for auditing
5. Survives Reinstalls: Policies reapply after Windows reinstallation

For organizations with large numbers of computers, this approach is significantly more efficient than manually configuring each computer. It also ensures consistent security posture across the organization, reducing the risk of accidental misconfigurations.

Limitations of Group Policy

While powerful, Group Policy has some limitations:

1. Requires Windows Pro/Enterprise/Education: Home editions don’t support Group Policy
2. Domain Membership Required: For full functionality, computers need to be domain-joined
3. Network Dependency: Policy application requires network connectivity
4. Complex Setup: Initial configuration requires domain administrator privileges

In environments without Active Directory, you can use Local Group Policy (gpedit.msc) on individual computers, but this doesn’t provide the centralized management benefits of domain-based Group Policy.

---

Best Practices for Network Security and Share Management

Disabling administrative shares is an important step in securing Windows network environments, but it should be part of a comprehensive security strategy. Implementing best practices for network security and share management provides layered defense against potential threats.

As emphasized in the Action1 blog post, a holistic approach to network security involves multiple layers of protection rather than relying on a single configuration change.

Network Segmentation

Network segmentation is a fundamental security practice that limits the exposure of administrative shares:

1. Create Network Zones: Divide your network into trusted and untrusted segments
2. Use VLANs: Implement Virtual LANs to separate different types of devices
3. Apply Firewall Rules: Restrict access to administrative shares based on IP ranges
4. Monitor Cross-Zone Traffic: Alert on unusual access patterns between network segments

By implementing network segmentation, you can ensure that administrative shares are only accessible from specific trusted networks, significantly reducing the attack surface.

Strong Authentication and Access Control

Even if administrative shares are disabled, proper authentication and access controls are essential:

1. Enforce Strong Passwords: Implement complex password requirements
2. Enable Multi-Factor Authentication: Add an extra layer of security for remote access
3. Regularly Rotate Credentials: Change passwords periodically
4. Principle of Least Privilege: Grant only necessary permissions to users
5. Account Lockout Policies: Protect against brute force attacks

These measures help protect against credential-based attacks that might target other shared resources or services on your network.

Regular Security Auditing

Continuous monitoring and auditing help detect and respond to potential security issues:

1. Enable Auditing: Configure Windows to log access attempts to sensitive resources
2. Review Logs Regularly: Monitor for unusual access patterns
3. Conduct Vulnerability Scans: Regularly assess your network for security weaknesses
4. Penetration Testing: Simulate attacks to identify potential vulnerabilities
5. Update and Patch: Keep systems and applications current with security updates

As noted in the O’Reilly Network Security Hacks resource, regular security assessments are crucial for maintaining a secure network environment.

Share Management Best Practices

For legitimate file sharing needs, implement these best practices:

1. Use Explicit Shares: Instead of relying on administrative shares, create specific shares with controlled permissions
2. Share Only Necessary Folders: Avoid sharing entire drives or system directories
3. Implement Share Permissions: Configure appropriate share permissions for each shared resource
4. Combine with NTFS Permissions: Use both share and NTFS permissions for layered security
5. Regularly Review Shared Resources: Audit and remove unnecessary shares

These practices help balance functionality with security, allowing legitimate file sharing while minimizing exposure to potential threats.

User Education

Finally, user education is a critical component of network security:

1. Security Awareness Training: Educate users about network security risks
2. Social Engineering Defense: Train users to recognize and report suspicious activities
3. Proper Password Handling: Guide users on creating and managing strong passwords
4. Incident Reporting: Establish clear procedures for reporting security concerns

By implementing these best practices in conjunction with disabling administrative shares, you create a comprehensive security posture that protects against a wide range of network-based threats.

---

Sources

1. Microsoft Network Discovery Troubleshooting — Technical explanation of network discovery behavior: https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/cannot-turn-on-network-discovery
2. Dummies Network Discovery Guide — Configuration details for network discovery in Windows: https://www.dummies.com/article/technology/computers/operating-systems/windows/windows-10/how-to-enable-network-discovery-and-configure-sharing-options-in-windows-10-140265/
3. Microsoft File Sharing Documentation — Official guidance on file sharing over networks: https://support.microsoft.com/en-us/windows/file-sharing-over-a-network-in-windows-b58704b2-f53a-4b82-7bc1-80f9994725bf
4. SuperUser Administrative Shares — Security analysis of default administrative shares: https://superuser.com/questions/1089079/c-users-folder-shared-by-default-with-everyone-security-faultcompromised-dat
5. WinAero Disable Administrative Shares — Step-by-step registry modification guide: https://winaero.com/disable-administrative-shares-in-windows-10-windows-8-and-windows-7/
6. Action1 Stop File Sharing — Comprehensive methods to disable administrative shares: https://www.action1.com/blog/how-to-stop-file-sharing-windows-10/
7. Petri Disable Administrative Shares — Registry solution using AutoShareWks: https://petri.com/disable_administrative_shares/
8. SysProbs Disable Administrative Shares — Detailed registry modification steps: https://sysprobs.com/disable-administrative-shares-windows-7-lets-data-secret
9. O’Reilly Network Security Hacks — Security implications and risks of administrative shares: https://www.oreilly.com/library/view/network-security-hacks/0596006438/ch02s08.html
10. Microsoft Cannot Access Shared Folder — Technical details on administrative shares and permissions: https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/cannot-access-shared-folder-file-explorer

---

Conclusion

Enabling network discovery in Windows automatically exposes the C:\Users directory through administrative shares created by the Server service, a behavior that persists across Windows reinstallation due to system-level configurations. This default sharing mechanism creates security risks by exposing directory structures and potential entry points for unauthorized access, particularly in unsecured network environments.

The most reliable solution to permanently disable administrative shares is through registry modifications, specifically setting AutoShareWks or AutoShareServer to 0 in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters. This approach survives Windows reinstallation and provides comprehensive protection against automatic share creation. Alternative methods include service configuration changes and Group Policy deployment for enterprise environments, though these may offer less persistence or require additional infrastructure.

For optimal network security, disabling administrative shares should be part of a comprehensive strategy that includes network segmentation, strong authentication, regular security auditing, proper share management, and user education. By implementing these measures alongside the registry-based solution, organizations and individuals can significantly reduce their network attack surface while maintaining legitimate functionality.