Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 -

Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. all rights reserved.

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.


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?

share|improve this question

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.

share|improve this answer
I don't think you can ever use the NT AUTHORITY\SYSTEM account to map network drives. The principal isn't valid except on the local machine. – Falcon Momot May 24 '13 at 9:50
@FalconMomot you can - network connections initiated by NT AUTHORITY\SYSTEM use the machine's AD account for authentication. – the-wabbit May 24 '13 at 15:21
Could it be the the machine's AD account is not trusted for delegeation? This would result in the NT AUTHORITY\SYSTEM account not being able to act as the machine's AD account. You can check this in Active Directory on the second machine's object. Another issue might be missing Service Princicpal Names for the second machine. Try the following SETSPN -L <second_machine_name> and see what you get back. There should be at least an entry for HOST and one for RestrictedKrbHost would be nice. – hot2use May 9 '14 at 6:53

Since it worked on one machine and not the other, I would check the netapp logs to see if it is denying the connection to the share from that server.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.