Mapping Drive Error - System Error 1808
A vendor is attempting to map and preserve a network drive using nt authority/system; so it stays persistent when the interactive session of the server is lost. They were able to do this on one server (Windows 2008 R2) but not a second computer (also Windows 2008 R2).
D:\PsExec.exe -s cmd.exe
PsExec v1.98 - Execute processes remotely
Copyright (C) 2001-2010 Mark Russinovich
Sysinternals - www.sysinternals.com
Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. all rights reserved.
C:\Windows\system32>whoami
nt authority\system
C:\Windows\system32>net use
New connections will be remembered.
Status Local Remote Network
--------------------------------------------------------------------
OK X: \\netapp1\share1 Microsoft Windows Network
The command completed successfully.
C:\Windows\system32>net use q: \\netapp1\share1
System error 1808 has occurred.
The account used is a computer account. Use your global user account
or local user account to access this server.
C:\Windows\system32>
I am unsure on how to set up a "machine account mapping" which will preserve the drive letter of the Netapp path being mapped, so that the service account running a Windows service can continue to access the share after interactive logon has expired on the server. Since they were able to do this on one server but not another, I'm not sure how to troubleshoot the problem? Any suggestions?
Is it possible that netapp1 is unable to verify if the computer account of the host you are using is actually belonging to the domain?
I do know nothing about the methods of NetApp's AD / authentication and authorization integration, but possible weak spots would be things like ACLs (machineaccount1 is allowed access while machineaccount2 is not), domain trusts (where the NetApp would be able to verify machineaccount1 belonging to domain1 but not machineaccount2 belonging to a trusted domain) or AD replication issues (if information needed to verify machineaccount2 is not present on the DC queried by the NetApp).
Edit: a similar question has been asked at NetApp's support forum in the meantime and it has a promising answer - a mismatch between the DNS registration for netapp1 and the actual address used for accessing it might cause Kerberos auth to fail, resulting in this error message. The thread also references NetApp's KB 2013374 which seems to include additional information but requires a valid logon to NetApp's support site to be viewed.