x
This website is using cookies. We use cookies to ensure that we give you the best experience on our website. More info. That's Fine
HPC:Factor Logo 
 

Cannot see available network shares listed on a Domain Controller even though you are logged-in

CESD|200088

Applies To

  • Windows CE 2.0, SP1
  • Handheld PC Professional, SP1
  • Handheld PC 2000
  • Windows CE .net 4.0, 4.1, 4.2
  • Windows 2000, XP, 2003

Overview

When you use your Handheld PC to browse available network shares on a Windows 2000 / 2003 Domain Controller My Handheld PC will prompt for password and authenticate to the Domain Controller, however the shares list will either not appear (looking like a blank folder) or you will not be able to enter any available shares. This circumstance occurs irrespective of if you are logged in as a member of a valid user group or as a member of the Administrative group.

This situation may present itself as only an issue on Windows 2003 Domain Controller or Member Servers. Existing Windows 2000 servers may authenticate and list shares as normal.

Summary

With the release of Windows Server 2003 Microsoft removed the out of box ability for Windows Server Domain Controllers to accept connections from legacy systems. This was achieved by enforcing the local systems security policy requiring Secure Channel authentication be encrypted before access would be granted to a client.

All generations of Windows CE are unable to connect using encrypted authentication to a Domain Controller. As a result default policy enforcement will block all traffic from Windows CE devices unless they are assigned certificates (Windows CE Net only).

Resolution

Resolving the issue for legacy clients will require substantial changes to the security authentication on the Domain Controller. Any user attempting to modify the Windows Group Policy of an Active Directory or local network should be sure they understand the implications of the changes on the over all security of the Network.

There are several different situations that may arise with this issue. Read through the descriptions below and follow the appropriate steps.

I can access shares on Windows 2000 DC's but not Windows 2003 DC's

If the problem exists only on Windows Server 2003 systems then the default local security setting on the Windows 2003 domain controllers is in effect. This means that security settings have not been specified using either the Default Domain Controller Security Policy or using a custom Domain Controller Security Policy.

To fix the issue administrators should either modify the local security settings on the affected server or define a global policy for Domain Controllers using Group Policy. We recommend the use of Group Policy over individual modification to the Local Security Policy. Follow Step 1

I can access shares on Windows Servers but not on Windows Server DC's

The security policy for Active Directory clients has been set to allow unsecured connections however the security settings on the Default Domain Controller Security Policy or custom Domain Controller Group Policy have been set so that unsecured connections will be rejected. Follow Step 2

I cannot access shares on any Windows Server or NT5 workstations

Group Polices exist on the domain that prevent any unencrypted authentication with any Windows 2000 or above network share. This applies to both client workstations, servers and Domain Controllers. Follow Step 2 & 3

I only have Windows 2003 DC's on my network

Policy enforcement in the Default Domain Controller Security Policy are preventing network resource access. Follow Step 2

Step 1: Local Security Policy

    1. Click Start, ChooseSettings. Open the Control Panel, double click Administrative Tools
    2. Run the Local Security Policy applet
    3. Expand Local Polices
    4. Select Security Options
    5. Find the Policy option named: Secure Channel: Digitally encrypt or sign secure channel data (always)
    6. If this setting have been enforced either locally or through a Group Policy you will need to disable it. Double click the entry and select to disable it
    7. Reboot or reload the security policy

We recommend that as a substitute you enable the proceeding policy setting: Secure Channel: Digitally encrypt or sign secure channel data (when possible) as this will allow capable clients to communicate safely with the Domain Controller.

 

Step 2: Default Domain Controller Security Policy

        1. Click Start, ChooseSettings. Open the Control Panel, double click Administrative Tools
        2. Run the Default Domain Controller Security Policy applet
        3. Expand Windows Settings\Security Settings\Local Policies\Security Options\
        4. Find the Policy option named: Domain Controller: Digitally encrypt or sign secure channel data (always)
        5. If this setting have been enforced either locally or through a Group Policy you will need to disable it. Double click the entry and select to disable it
        6. Reboot or reload the security policy

We recommend that as a substitute you enable the proceeding policy setting: Domain Controller: Digitally encrypt or sign secure channel data (when possible) as this will allow capable clients to communicate safely with the Domain Controller.

 

Step 3: Domain Security Policy

        1. Click Start, ChooseSettings. Open the Control Panel, double click Administrative Tools
        2. Run the Domain Security Policy applet
        3. Expand Windows Settings\Security Settings\Local Policies\Security Options\
        4. Find the Policy option named: Domain member: Digitally encrypt or sign secure channel data (always)
        5. If this setting have been enforced either locally or through a Group Policy you will need to disable it. Double click the entry and select to disable it
        6. Reboot or reload the security policy

We recommend that as a substitute you enable the proceeding policy setting: Domain member: Digitally sign secure channel data (when possible) as this will allow capable clients to communicate safely with the Domain Controller.

Acknowledgements

With thanks to Larry Vermeulen and C3 Technology for working with us on this article.