서비스에서 사용할 네트워크 드라이브 매핑

서비스에서 사용할 네트워크 드라이브 매핑

---

일부 Windows 서비스가 UNC 경로를 매핑하지 않고 매핑 된 네트워크 드라이브를 원하는 코드를 사용한다고 가정합니다. 서비스가 시작될 때 서비스 세션에서 드라이브 매핑을 사용 가능하게하려면 어떻게해야합니까? 서비스 사용자로 로그인하고 지속적 맵핑을 작성하면 실제 서비스 컨텍스트에서 맵핑이 설정되지 않습니다.

---

세션 / 드라이브 액세스 문제와는 별도로 서비스를 수정하거나 도우미 프로세스로 래핑해야합니다. 영구 드라이브 매핑은 일반적으로 서비스가 수행하지 않는 대화 형 로그온에서만 복원됩니다.

도우미 프로세스 접근 방식은 매우 간단합니다. 드라이브를 매핑하고 '실제'서비스를 시작하는 새 서비스를 만드십시오. 이것에 대해 완전히 사소한 것은 아닙니다 :

• 도우미 서비스는 모든 적절한 SCM 명령 (시작 / 중지 등)을 실제 서비스에 전달해야합니다. 실제 서비스가 사용자 정의 SCM 명령을 허용하는 경우 해당 명령도 전달하는 것을 잊지 마십시오 (UNC 명령이 이국적인 명령을 사용한다고 생각하는 서비스는 기대하지 않습니다 ...)

• 자격 증명이 약간 까다로울 수 있습니다. 실제 서비스가 일반 사용자 계정으로 실행되는 경우 해당 계정으로도 도우미 서비스를 실행할 수 있으며 계정에 네트워크 공유에 대한 적절한 액세스 권한이있는 한 모두 정상이어야합니다. 실제 서비스가 LOCALSYSTEM 등으로 실행될 때만 작동한다면 네트워크 드라이브를 전혀 볼 수 없거나 자격 증명 저글링이 필요하기 때문에 더 흥미로워집니다.

---

이 위험을 감수하십시오. (XP 및 Server 2008 x64 R2에서 테스트했습니다)

이 해킹 에는 Mark Russinovich의 SysinternalsSuite 가 필요합니다 .

1 단계 : 관리자 권한으로 실행 된 cmd.exe 프롬프트를 엽니 다.

2 단계 : PSExec.exe를 사용하여 다시 루트로 상승 : SysinternalsSuite가 포함 된 폴더로 이동하여 psexec -i -s cmd.exe프롬프트에 있는 다음 명령 을 실행하고을 nt authority\system입력하여이를 증명할 수 있습니다 whoami. 는 -i드라이브 매핑이 사용자와 상호 작용해야하기 때문에 필요하다

3 단계 : 다음 명령을 사용하여 영구 매핑 된 드라이브를 SYSTEM 계정으로 만듭니다.net use z: \\servername\sharedfolder /persistent:yes

그렇게 쉽습니다!

경고 : SYSTEM 계정에서 생성 한 것과 동일한 방식으로 만이 매핑을 제거 할 수 있습니다. 제거해야하는 경우 1 단계와 2 단계를 수행하되 3 단계의 명령을로 변경하십시오 net use z: /delete.

참고 : 새로 만든 매핑 된 드라이브는 이제이 시스템의 모든 사용자에게 표시되지만 "연결이 끊긴 네트워크 드라이브 (Z :)"로 표시됩니다. 이름이 당신을 속이게하지 마십시오. 연결이 해제되었다고 주장 할 수 있지만 모든 사람에게 효과적입니다. 이것이이 핵이 M $에 의해 지원되지 않는다고 말할 수있는 방법입니다.

---

psexec를 사용하는 것과 유사한 솔루션을 찾았지만 추가 도구없이 작동 하며 재부팅 후에도 지속 됩니다.

간단한 작업을 추가하고 "다음 계정으로 실행"필드에 "시스템"을 삽입 한 다음 간단한 명령으로 작업을 배치 파일로 지정하십시오.

net use z: \servername\sharedfolder /persistent:yes

그런 다음 "시스템 시작시 실행"(또는 유사하게 영어 버전이 없음)을 선택하면 완료됩니다.

---

mklink.exe를 사용하여 심볼릭 링크를 사용하는 것이 더 좋은 방법입니다. 모든 앱에서 사용할 수있는 파일 시스템에 링크를 만들면됩니다. http://en.wikipedia.org/wiki/NTFS_symbolic_link를 참조하십시오 .

---

여기에 좋은 대답이 있습니다 : https://superuser.com/a/651015/299678

즉, 예를 들어 심볼릭 링크를 사용할 수 있습니다

mklink /D C:\myLink \\127.0.0.1\c$

---

'net use'명령을 사용할 수 있습니다.

var p = System.Diagnostics.Process.Start("net.exe", "use K: \\\\Server\\path");
var isCompleted = p.WaitForExit(5000);

서비스에서 작동하지 않으면 Winapi 및 PInvoke WNetAddConnection2를 시도하십시오.

편집 : 분명히 나는 ​​당신을 오해했습니다-당신은 서비스의 소스 코드를 변경할 수 없습니다. 이 경우 mdb 의 제안을 따르지만 약간의 왜곡이 있습니다. 드라이브를 매핑하는 자체 서비스를 작성하십시오 (매핑 서비스라고 함).이 매핑 서비스를 첫 번째 (실제 작업) 서비스의 종속성에 추가하십시오. 이렇게하면 매핑 서비스가 시작되고 드라이브를 매핑하기 전에 작업 서비스가 시작되지 않습니다.

---

힘,

참고 : 새로 만든 매핑 된 드라이브는 이제이 시스템의 모든 사용자에게 표시되지만 "연결이 끊긴 네트워크 드라이브 (Z :)"로 표시됩니다. 이름이 당신을 속이게하지 마십시오. 연결이 해제되었다고 주장 할 수 있지만 모든 사람에게 효과적입니다. 이 해킹이 M $에서 지원되지 않는다고 말할 수있는 방법입니다 ...

모두 공유 권한에 따라 다릅니다. 공유 권한에 Everyone이 있으면 다른 사용자가이 매핑 된 드라이브에 액세스 할 수 있습니다. 그러나 배치 스크립트에서 자격 증명을 사용하고이 배치 스크립트가 시작 스크립트에 추가 된 특정 사용자 만있는 경우 시스템 계정 만 관리자가 아닌 해당 공유에 액세스 할 수 있습니다. 예를 들어, 예약 된 ntbackuo 작업을 사용하는 경우 '다음 계정으로 실행'에서 시스템 계정을 사용해야합니다. 서비스의 '로그온 : 로컬 시스템 계정'인 경우 작동합니다.

내가 한 일은 시작 스크립트에 드라이브 문자를 매핑하지 않고 net use \\\server\share ...예약 된 작업에서 UNC 경로를 사용 하고 사용했습니다. net use Z: \\\...동일한 자격 증명을 가진 일부 드라이브 문자로 동일한 공유에 매핑하여 로그온 스크립트를 추가하거나 시작 파일 폴더에 배치 파일을 추가하면 됩니다. 이제 로그 된 사용자가 해당 매핑 된 드라이브를보고 액세스 할 수 있습니다. 동일한 공유에 2 개의 연결이 있습니다. 이 경우 사용자에게는 "연결이 끊어진 네트워크 드라이브 ..."라는 메시지가 표시되지 않습니다. 그러나 UNC뿐만 아니라 드라이브 문자로 해당 공유에 액세스해야하는 경우 다른 드라이브 문자 (예 : 시스템의 경우 Y, 사용자의 경우 Z)와 공유하는 해당 드라이브를 매핑하십시오.

---

Windows 서비스에 네트워크 드라이브에 대한 액세스 권한을 부여하는 방법을 찾았습니다.

NFS 디스크가있는 Windows Server 2012를 예로 들어 보겠습니다.

1 단계 : 마운트 할 배치 파일 작성

Write a batch file, ex: C:\mount_nfs.bat

echo %time% >> c:\mount_nfs_log.txt
net use Z: \\{your ip}\{netdisk folder}\ >> C:\mount_nfs_log.txt 2>&1

Step 2: Mount Disk as NT AUTHORITY/SYSTEM.

Open "Task Scheduler", create a new task:

1. Run as "SYSTEM", at "System Startup".
2. Create action: Run "C:\mount_nfs.bat".

After these two simple steps, my Windows ActiveMQ Service run under "Local System" priviledge, perform perfectly without login.

---

The reason why you are able to access the drive in when you normally run the executable from command prompt is that when u are executing it as normal exe you are running that application in the User account from which you have logged on . And that user has the privileges to access the network. But , when you install the executable as a service , by default if you see in the task manage it runs under 'SYSTEM' account . And you might be knowing that the 'SYSTEM' doesn't have rights to access network resources.

There can be two solutions to this problem.

1. To map the drive as persistent as already pointed above.

2. There is one more approach that can be followed. If you open the service manager by typing in the 'services.msc'you can go to your service and in the properties of your service there is a logOn tab where you can specify the account as any other account than 'System' you can either start service from your own logged on user account or through 'Network Service'. When you do this .. the service can access any network component and drive even if they are not persistent also. To achieve this programmatically you can look into 'CreateService' function at http://msdn.microsoft.com/en-us/library/ms682450(v=vs.85).aspx and can set the parameter 'lpServiceStartName ' to 'NT AUTHORITY\NetworkService'. This will start your service under 'Network Service' account and then you are done.

3. You can also try by making the service as interactive by specifying SERVICE_INTERACTIVE_PROCESS in the servicetype parameter flag of your CreateService() function but this will be limited only till XP as Vista and 7 donot support this feature.

Hope the solutions help you.. Let me know if this worked for you .

---

You wan't to either change the user that the Service runs under from "System" or find a sneaky way to run your mapping as System.

The funny thing is that this is possible by using the "at" command, simply schedule your drive mapping one minute into the future and it will be run under the System account making the drive visible to your service.

---

Instead of relying on a persistent drive, you could set the script to map/unmap the drive each time you use it:

net use Q: \\share.domain.com\share 
forfiles /p Q:\myfolder /s /m *.txt /d -0 /c "cmd /c del @path"
net use Q: /delete

This works for me.

---

I can't comment yet (working on reputation) but created an account just to answer @Tech Jerk @spankmaster79 (nice name lol) and @NMC issues they reported in reply to the "I found a solution that is similar to the one with psexec but works without additional tools and survives a reboot." post @Larry had made.

The solution to this is to just browse to that folder from within the logged in account, ie:

    \\servername\share  

and let it prompt to login, and enter the same credentials you used for the UNC in psexec. After that it starts working. In my case, I think this is because the server with the service isn't a member of the same domain as the server I'm mapping to. I'm thinking if the UNC and the scheduled task both refer to the IP instead of hostname

    \\123.456.789.012\share 

it may avoid the problem altogether.

If I ever get enough rep points on here i'll add this as a reply instead.

참고URL : https://stackoverflow.com/questions/182750/map-a-network-drive-to-be-used-by-a-service