Problems accessing Windows share on domain computer using local accounts

Try assigning a secondary DNS server and see if that has any effect...assuming you haven't already. Try enabling/disabling NETBIOS of TCP/IP.

I am assuming a couple things here... please tell me if these are not correct:

1. There is no DNS server at the site where PC1 and PC2 are located. (They receive their DNS only from the remote DC, over the VPN).
2.There is a hardware IPSEC VPN setup between sites (as opposed to the pc1 or pc2 machines using a software VPN client to connect to the VPN).

Assuming #1 is true, there should be a local DNS server in case the AD server is unavailable, both to access local computers and the internet. If you already have a local DNS server, let me know if it's a Windows server or the local router, etc. And what order the DNS servers are for pc1 and pc2 (primary vs secondary).

An additional test I'm curious about, have you tried accessing the share while AD is unavailable via IP? Is the behavior the same or different?

Thanks,
Kara

Thanks,
Kara

renazonse:

There is secondary DNS (outside the AD) provided by a local router for the purposes of Internet access if the VPN is down. Have tried with and without this second DNS resolution source, no change in problem.

Have tried forcing Netbios over TCP/IP to enabled (which should have been the default with static IP set) but there was no effect.

Karatechle:

There is a local router that provided DNS resolution before the AD was available, and we've tried both with and without this router listed as the second DNS server with the AD set as the primary, I believe we've also tried them the other way around. No effect.

Yes, there is a hardware IPSEC VPN connecting the network with the PC's to the network with the AD. We have tried using IP instead of name, and we get the same effect; long wait and then the dialog message complaining about no logon server or no permission

Why not create an AD account for Bill? You could create the AD account for him and migrate the user settings/profile. This should work around the local user issue, and should not cause issues for the domain account if the AD were unavailable for short periods of time.

One of the problems is that the PC needs to auto-login ... we found registry change instructions to let a local account auto-login after joining AD but I've not tried this with a domain account. I can test and see if this is a fix, but how long is a "short" period of time. Because the AD is WAN connected, a router failure at the remote site could be a 3 day delay in getting a new router delivered and installed.

By short I mean within the tombstone lifetime. Which by default in Server 2003 SP1 is 180 days. Server 2003 was 60 days. As long as the workstation doesn't tombstone, the VPN could come back up 5,15,50 (etc) days later and the workstation would still authenticate to the domain.

Kara

Kara: Tried your idea. Works until the PC reboots, then the cached credential seems to be lost and the system challenges for credential. Until the AD comes back online the share is down.

And when you get prompted for credentials, you enter them as:
domain\user
password

Correct? Do you receive the same error?

Kara

Also, please check the event log and post any application/system/security errors that happen around the time you're trying to access the share.

Thanks,
Kara

Kara:

1. Boot PC's with AD connected
2. Login as the domain account
3. Verify connectivity PC1 to PC2 and back again, no problem
4. Pull connection to AD
5. Verify connectivity PC1 to PC2 and back again, no problem
6. Reboot PC1
7. Verify connectivity PC1 to PC2

When using the local accounts, no error message is logged in the Event Log. The dialog that appears doesn't contain an error code, just a message no logon server is available or no permissions

When using AD credentials, and entering the user name and password (in the format DOMAIN\user)  an error pops up saying:

Logon unsuccessful:

The user name you typed is the same as the user name you logged in with. That user name has already been tried. A domain controller cannot be found to verify that user name.

In the application log:

Windows cannot obtain the domain controller name for your computer network.

In the system log:

The security system could not establish a secured connection with the server. CISS/PC2 no authentication protocol was available

We also get the normal "Downgrade attempt" warning message, I think it's LSASRV 40960, which I understand happens when the kerberos authentication has to be scrapped and NTLMv2 used because the KDC isn't available.

Other than those, which we fully expect to see because the AD isn't available to the workstation, there's nothing being logged.

I don't see that you've tried also rebooting PC2 after pulling the connection to AD.

-Pull connection to DC
-Reboot both machines
-Login with domain credentials
-Test the share

So in the real world, if the AD site was unavailable for any reason, the share would work until a computer rebooted. If that happened, then the other computer would need rebooted as well.

Let me know how that goes. There was a bug in XP service pack 2 that describes a similar issue, fixed by a hot fix. Are your POSReady machines up to date?

Kara

We did try rebooting both PC's with the AD offline and we get the same problem. We're checking to make sure all the available patches have been loaded on both PC's right now but I suspect we already installed, at minimum, all the critical updates

Forgive me if somewhere in here this has already been explained but I'm seeing that the user "Bill" is a local user account and I'm not seeing here that you're trying to authenticate as PCNAME\Bill to the machines. Have you tried adding the machine name to the authentication attempts?

Yes Rena. We've tried all variations of the local account. All of them work when the AD is online, all of them fail when the AD is offline, despite the fact that they are NOT AD accounts and according to all of Microsoft documentation, the AD shouldn't even be hit to authenticate these accounts.

This is long :) please test after each step to ensure we know which, if any, affects your issue…
Double check that the time, time zone, and date settings are correct and in sync on each computer with the DC.

Check PC1 for stored usernames and passwords, remove any credentials associated with the PC2 (do the same on PC2, with any stored PC1 credentials).
Stored user names and passwords
-Open the User Accounts applet from the Control Panel
-Click the Advanced tab and then click the Manage Passwords button.
-Remove credentials in question
Also see: http://www.1stbyte.com/2007/02/01/lsasrv-event-id-40960-detected-an-attempted-downgrade-attack/

This KB article describes an issue accessing DFS shares since they only allow Kerberos. I understand that is not the exact issue here, but it could be that your computers are only allowing Kerberos due to a local or group policy…
http://support.microsoft.com/kb/891559
Are there any group policies applied to these machines?
-Check the settings being applied by both local and group security policies:
Start> Run> rsop.msc
Generate a report, the wizard should walk you through choosing the local computer, and the domain account (don’t bother running for the local account “Bill”, for now at least). Check the following location on both PC1 & PC2:
Local Policies> Security Options> “Network security: LAN Manager authentication level”
Is the setting defined?

You can try setting the “Restrict Anonymous” registry value (more info on this setting at http://technet.microsoft.com/en-us/library/bb418944.aspx). You don’t have to try the symptoms test they mention, unless you want to. Pasted information is from: http://winhlp.com/wxnet.htm
{snip}
You have both the following symptoms:
•      You can ping the computer by IP and by name.
•      When you type on another computer, replacing computername with the name of the inaccessible computer:

(At the command line) net view \\computername
•      you get one of the various "Error 5" error messages, like "System error 5 has occurred. Access is denied" or "Error 5: You do not currently have access to this file. ..."
However, other commands, like
net use Z: \\computername\sharename
or typing the full network path into Windows Explorer may work.
This can be caused by a registry setting named RestrictAnonymous. Go to the computer which you cannot access, start a registry editor and change the following registry value.
HKEY_LOCAL_MACHINE
 \SYSTEM
  \CurrentControlSet
   \Control
    \Lsa
Value name: RestrictAnonymous
Value type: DWORD
If the value is 1 or even 2, change it to 0.
{snip}
Check immediately afterwards and again after a reboot, whether the value changes back to non-zero on its own. If that happens, then you have to find the culprit, which can be spyware, a worm, or a badly designed security program. In this case this procedure most likely solved your problem, but then the bad software stepped back in and recreated the problem.


If these suggestions don’t fix the issue, please answer/clarify the following:
-In the past has this location had a domain controller onsite? If so was is gracefully demoted?
-Is the site’s subnet listed in Active Directory Sites & Services on the domain controller? You’ll want to ensure that the site’s subnet is listed, as well as associate the subnet with the correct AD site.
-Please clarify which machine the event logs you posted came from. Also, if you only checked one of the machines, please post relevant event logs from the other machine as well.
-Please post the exact text from the LSASRV 40960 event you mention, and let me know which machine it was logged on (I assumed it is PC2).
- On PC2, please check and post back both the NTFS permissions (on the security tab of the folder’s properties), and the share permissions from the share tab.

Also, you should be able to restart the "Server" service instead of rebooting your machine on the step regarding the 'Restrict Anonymous' setting.

> Double check that the time, time zone, and date settings are correct {snip}

All times in sync

> Check PC1 for stored usernames and passwords, {snip}

Saved credential page is blank on both PC's

> This KB article describes an issue accessing DFS shares since they only allow Kerberos. {snip}

Already set to Allow LM & NTLM use NTLMv2 if supported

> You can try setting the “Restrict Anonymous” registry value {snip}

Already tried this one, didn't help

> (At the command line) net view \\computername  you get one of the various "Error 5" error messages, ... However, other commands, like net use Z: \\computername\sharename or typing the full network path into Windows Explorer may work. {snip}

net view shows the PC's on the network, net view PCx gives error 5, net use ... results in a not found error. Typing the full path in Explorer doesn't work, either by name or by IP (no logon server error)

> This can be caused by a registry setting named RestrictAnonymous. {snip}

Tried this, didn't help

> Check immediately afterwards and again after a reboot, whether the value changes back to non-zero on its own. {snip}

Value holds at zero after rebooting

> If these suggestions don’t fix the issue, please answer/clarify the following:
> In the past has this location had a domain controller onsite? If so was is gracefully demoted?

No, both were freshly installed workgroup PC, joined into a new isolated test network, to a new Win2008 r2 DC installed fresh. Nothing else has ever been on this network.

>Is the site’s subnet listed in Active Directory Sites & Services on the domain controller? You’ll want to ensure that the site’s subnet is listed, as well as associate the subnet with the correct AD site.

Done. There's currently only one AD server though, and there's no additional sites created in the AD to split anything up at this point. All IP ranges were added anyway and it doesn't resolve the issue.

>Please clarify which machine the event logs you posted came from. Also, if you only checked one of the machines, please post relevant event logs from the other machine as well.

The logs were identical when test either PC1 to PC2 or vice versa

>Please post the exact text from the LSASRV 40960 event you mention, and let me know which machine it was logged on (I assumed it is PC2).

Source: LSASRV
Category: SPNEGO (Negotiator)
Type: Warning
EventID: 40960
User: N/A
Computer: PC1

The Security System detected an attempted downgrade attack for server cifs/PC2. The failure code from authentication protocol Kerberos was "There are currently no logon servers available to service the logon request (0xc000005e)

>On PC2, please check and post back both the NTFS permissions (on the security tab of the folder’s properties), and the share permissions from the share tab.

The test user account has all permissions checked (except the Full Control box) on the folder. On the share, the Full Control box is checked for the test account. Note that we have also tried this with administrator accounts and it makes no difference.

Thanks for the info. Let's take a step back to some basics real quick.

So far, have all your attempts to access the share been via explorer? Try mapping a drive with the DC accessible, as user domain\bill, and test access in this manner.

I also need:

Thanks,
Kara

It looks like we have discovered an issue with NETLOGIN.DLL distributed with POSready 2009. POSready 2009 appears to be XPsp3 based and this issue is documented, with a hotfix, for XP. We are testing now but so far it looks promising.

That's great! Let us know how it goes. Can you also post a link to the hotfix?

Kara

Not listed as affecting POSready 2009, but the hotfix instantly corrected both the slow name resolution and no logon server errors. Systems are now working properly after the hotfix. The fix appeared to work BETTER if installed after the system had joined the domain.