5

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?

Improve this question

2 Answers 2

Reset to default
1

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.

Improve this answer
3
  • 1
    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, 2013 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, 2013 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.
    – John K. N.
    May 9, 2014 at 6:53
0

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .