Since ages I've mounted a network share (via samba to a Linux machine) in Windows 7 to access it via drive letter. This worked flawlessly so far. The local security authority is internally inconsistent upon mounting a network drive. 'The Local Security Authority (LSA) database contains an internal inconsistency'.
It's interesting that I have searched for days now, and still can not find an answer to this. Hopefully someone can look over what I have and recommend a solution. The situation: There is a VPN tunnel that connects the various locations. I have a user that connects to the corporate network via VPN, and uses RDP to connect to their workstation in a different location than the entry point. User receives the following error when trying to use RDP: Authentication error has occurred.
The Local Security Authority cannot be contacted. Remote computer xxx.xxx.xxx.xxx This could be due to an expired password. Please update your password if it has expired. If I am physically within the network, but attempt to RDP to any of the workstations on the other side of the tunnel, I receive the same error. I am able to successfully RDP into any system on my side of the tunnel, and RDP into a server on the other side of the tunnel.
If I were to connect to the remote server and RDP into any workstation that resides within that network, I receive the following error: An authentication error has occurred (Code: 0x80090304) Remote computer: xxx.xxx.xxx.xxx What I have tried:. Error code 0x80090304 is linked to error SECEINTERNALERROR. The Microsoft Hotfix for this error returned a message stating that it did not apply to this system. The server is x64 and the hotfix was for an x64 system. This error message also seems to be link to the error in the workstations Event Viewer TermDD Event ID 56. In the Terminal Services Configurations settings on that server, the Security Layer is correctly set to RDP Security Layer and 'Allow connections only form computers running Remote Desktop with Network Level Authentication' is unchecked in the System Properties under the Remote tab.
In the registry, HKEYLOCALMACHINE SYSTEM CurrentControlSet Control Terminal Server WinStations RDP-Tcp the UserAuthentication value was changed it to 1 and system was restarted to apply registry changes. GPO already disables Network Level Authentication.- Computer Configuration Windows Settings Security Settings Local Policies User Rights Assignment 'Access this computer from the network' is set to correctly. Even with firewall disabled, RDP attempts to remote workstation were unsuccessful.
RDP connecting to workstations using domain admin credentials or users credentials. Users credentials was reset, user does not have to log in to change password and password is set to never expire. Is there anything else that could cause this issue that I should check? It's interesting that I have searched for days now, and still can not find an answer to this. Hopefully someone can look over what I have and recommend a solution. JCT2 wrote: @Keith9482: I am using a Cisco VPN.
I have not connect to VPN on the other side and I am not able to set this up. There are some reasons for this, that I can not really discuss. @MattJH: I wish I had the answer to that question. Even when I use RDP to connect to the server, I can not then use RDP from the server to connect to other workstations on that side. I successfully ping every device on both sides, and have checked the DNS settings on that side. It sounds like it has nothing to do with the VPN then Are the times correct on both server and client on remote side? Does the DC log any logon errors?
@MattJH: It is a Windows 2008 R2 Server and Windows 7 Pro workstations. @Keith T.: Yes, I made sure that 'Allow remote connections to this computer ' was checked. @MrG3: This would make sense, but I can't use another computer within that network to RDP into another computer within that network. That kind of eliminates the VPN idea.
@Greg2078: Microsoft and all of its wisdom made the errors very generic for this issue. After a lot of digging, the error code on the server is 0x80090304 and on the workstation is TermDD Event ID 56 Error code 0x80090304 is linked to error SECEINTERNALERROR. @JCT2 - Everything I'm seeing points to disabling Network Level Authentication, but you already did that.
![Windows Windows](http://www.online-tech-tips.com/wp-content/uploads/2010/05/Windows7LocalSecurityPolicy_thumb2.png)
There are a few other solutions on the second page of that worked for some people (changing permissions of the account you're using, changing the local GPO of workstations you're trying to RDP to, etc). Suggests removing and re-adding the workstations to the domain. In regards to: In the registry, HKEYLOCALMACHINE SYSTEM CurrentControlSet Control Terminal Server WinStations RDP-Tcp the UserAuthentication value was changed it to 1 and system was restarted to apply registry changes.I keep finding resources saying that the value. Everything still points to NLA.. @JCT2: It might be worth your time to systematically take them off of one workstation until RDP (hopefully!) works. Their problem isn't identical to yours, but the end result is the same.
You've already been very thorough in trying the solutions found online for SECEINTERNALERROR and 0x80090304. It's probably time to start nice and simple and go from there. Thanks to @Greg2078's suggestion, knowing that the workstations aren't accepting connections on 3389 is a really good lead.
Whether it has anything to do with you coming over the VPN is undetermined, but it's unlikely. Do you have anyone at the remote site that can locally try RDPing to a workstation with no VPN involved? @JCT2 We discovered that our Cert store server had corrupted files due to EMC Networker (our backup solution) corrupting the MBR on our VMWare Servers. Apparently its a known issue for EMC who only provided a workaround instead of a fix which has something to do with switching to 'GPT' instead of MBR. Once we ran checkdisk on the vm servers and got them communicating again with out domain controller, it was able to hand out computer certificates that we required for those PC's to connect to our network.
This resolved the issue for us. I Don't think this information will assist you in resolving the RDP issue your customer is having, but regardless Here's the details of what happened to us: 'Looks like the VMware/EMC backups coincide with NTFS corruption errors on VMware servers. I’ve quickly looked at WSUS server, AD server, File server, and cert store servers and they all have NTFS corruption events that occur about 60 seconds after the VMware backup kicks off.
The NTFS corruption events date back to march when we got EMC backups for VMware to “work”. This is not a SAN issue because the above VMs sit on.SAN A.
and.SAN B.; and, in separate VMware volumes (VMStore#, VMReplication#, VMReplication#). The issue occurs only when a VMware backup runs. I migrated Files server to VMware6 in June and starting that night we began getting NTFS errors (servers on VMware5 were not backed up with EMC). I stopped VMware backups for now - Researching the issue a little further and I found the VMware KB: It states that this is a known issue and there is no resolution.
As a workaround, VMware references this KB2853247: KB articale says to format volumes to GPT, or, if you are still using MBR, then create only one MBR partition per disk. When creating a VM using the wizard, the Windows Server instalation process automatically formats the C: volume to MBR and creates an extra “System Reserved” partition on the same disk (2 partitions per disk). Converting MBR to GPT requiers a deletion of the MBR partition and creation of a GPT partition – this requieres a format & reinstall of the OS.'