어찌되었건 이 씨리즈에서는 공유폴더를 액세스하는데 필요한 기본 보안 사항(필자가 알고 있는)과 IIS/ASP.NET의 보안 설정 등을 설명하고 구체적인 예제, 그리고 유틸리티로 사용할 수 있는 Impersonation 클래스, Http 핸들러를 차례로 소개하고자 합니다.

• ASP.NET에서 공유 폴더 액세스 (I) : 공유 폴더 기본 및 파일 서버 설정
• ASP.NET에서 공유 폴더 액세스 (II) : 프로그램에서의 공유 폴더 액세스
• ASP.NET에서 공유 폴더 액세스 (III) : 공유 폴더 액세스와 Impersonation
• ASP.NET에서 공유 폴더 액세스 (IV) : ASP.NET의 프로세스/쓰레드 계정 과 공유 폴더 액세스
• ASP.NET에서 공유 폴더 액세스 (V) 네트워크 드라이브 이용

Accessing Shared Folder in ASP.NET (I)

ASP.NET에서 공유 폴더를 액세스 해야 하는 상황은 대단히 많이 발생하기 마련이다. 특히 2대 이상의 웹 서버가 사용 중일 때는 더더욱 그렇다. 요즘 웹 어플리케이션들은 죄다 파일 업로드/다운로드 기능을 갖고 있기 마련인데, 2대 이상의 웹 서버가 사용 중이라면 두 서버 중 어디에다 파일을 업로드하고 다운로드 해야 할까? 이 때 손쉽게 생각할 수 있는 것이 파일 서버를 마련해서 여기에다 파일을 업로드/다운로드 하면 두 웹 서버가 동일한 파일을 바라볼 수 있을 것이다.

그런데... ASP.NET에서 파일 서버를 액세스하는 것이 대략 녹녹하지 않다는 것이다. 다양한 보안 설정 사항들 때문에 그러한데... 그다지 어렵지 않지만 파일 공유에 대한 기본적인 사항들과 ASP.NET이 수행되는 환경을 제대로 이해하지 못하기 때문이다. 먼저 파일 공유에 대한 기본 지식에 대해 살펴보고 일반 Console 프로그램으로 공유 폴더를 액세스하는 것을 먼저 알아보자. 그리고 나서 ASP.NET에서 공유 파일을 액세스하는 것을 다루어 볼까 한다. 이번 포스트는 파일 공유에 대한 일반적인 사항만을 먼저 다루기로 하겠다. 그 이유는.... 필자 맘이다... -_-;

File Share Basic

공유 폴더란 무엇이더냐? (잘 모르겠는데요... -_-;) 아주 많이 사용되는 Windows의 기능이자 MSDOS 시절부터 사용되어왔던 기능이 바로 공유 폴더이다. 로컬 시스템의 특정 폴더를 네트워크 상에서 공유함으로써 FTP와 같은 파일 서버의 기능을 제공한다는 것이 되겠다. 기억하는 독자가 얼마나 될지 모르지만 Windows 3.1 버전(1990년에 출시되었던 것으로 기억난다)에서 노벨(Novell)사가 지배하고 있던 NOS(Network Operating System) 시작을 좀 따먹어보자고 마이크로소프트가 내 놓은 것이 바로 Lan Manager라는 것이 되겠다. Lan Manager와 Windows 3.1이 결합되어 윈도우 환경에서 폴더, 프린터 등을 네트워크 상에서 공유하여 사용하는 제품으로는 Windows 3.11 Work Group이란 제품도 있다. Lan Manager 서버는 노벨사의 제품에 계속 쪽박을 차다가 Windows NT와 Windows 95의 등장으로 빛을 발휘하게 된다. 아무도 콘솔 기반의 노벨 제품을 사용하는 사람이 없어졌고, 운영체제에 끼워진 Lan Manager 기반으로 파일 공유 서비스를 사용하게 된 것이다. 언제나 그렇듯이 클라이언트 운영체제를 등에 업고 마이크로소프트가 승리한 전형적인 예로 볼 수 있겠다.

어찌되었건 이 Lan Manager란 녀석은 지금까지도 명맥을 유지하고 있고(내부 코드나 인터페이스, 기능등은 당근 최신화 되어 바뀌어 왔다), 우리가 흔히 사용하는 폴더 공유 역시 Lan Manager 란 이름이 아직도 사용되고 있다.

File Server Service

우리가 흔히 파일 공유를 제공하려고 하면 파일 공유에 관련된 Windows 서비스를 시작해야 한다. 이런 서비스가 있었던가 하는 독자도 있다면 무리도 아니다. 이 서비스는 도통 그 역할을 알기 어려운 이름을 갖고 있기 때문이다. 이 서비스의 이름은 너무나도 애매모호하고 쌩뚱맞게 "Server" 란 이름을 갖고 있다. 당췌 무슨 서버인지 모르기 때문에 우리는 그저 그런 넘으로 인식하고 개 무시를 해 왔던 것이다. 그런데 사실 서비스의 설명을 잘 읽어보면 이 놈이 파일, 프린터 등을 공유하는데 필요한 서비스란 것을 알 수 있다(화면1)

화면1. Server 서비스. 이 눔이 폴더 공유를 가능하게 해주는 서비스 이다.

"Server" 란 이름은 소위 서비스의 Display Name 이란 것으로, 사실 서비스의 고유한 이름은 아니다. 이 서비스의 진정한 서비스 이름은 Lan Manager의 전통(?)을 이어 받아 LanmanServer 란 이름이 사용된다. 이 서비스는 필요에 따라 중지가 가능한데, 화면1과 같은 UI를 사용해도 되고 다음과 같이 콘솔 명령어를 통해 중지할 수도 있다.

물론 중단된 서비스를 시작할 수도 있으며 시작 역시 UI 화면을 사용하거나 net start lanmanserver 명령어를 사용할 수도 있다.

Server Logon & Session

공유 폴더를 제공하는 서버를 대개 파일 서버라고 한다. 파일 서버의 공유 폴더를 액세스하기 위해서는 일단 해당 파일 서버에 로그온을 해야만 한다. 이 때 로그온은 콘솔이나 터미널 서비스를 이용하여 대화형(interactive)으로 로그온 하는 것이 아니라 네트워크를 통해 해당 서버를 액세스하는 네트워크 로그온으로도 충분하다. 우리가 탐색기에서 공유 폴더를 액세스할 때 아이뒤와 암호를 묻는 창이 나타나는데 이것이 바로 파일 서버에 로그온 하는 것이 되겠다.

가끔 특정 상황에서는 아이디와 암호를 묻지 않고 바로 공유 폴더에 접근 가능할 때도 있다. 이런 경우는 이미 로그온이 되어 있는 상황일 것이다. 그렇지 않다면, 무조건 로그온 절차는 수행된다. 로그온 절차가 수행되더라도 아이디와 암호를 묻지 않을 수 있는데 이러한 경우는 두 가지 상황으로 나누어 볼 수 있겠다. 첫째, 액티브 디렉터리가 사용되고 클라이언트와 파일서버가 모두 도메인에 가입된 상황이다. 이 경우, 파일 서버가 해당 클라이언트를 거부하지 않는다면 액티브 디렉터리에 기록된 사용자 정보를 통해 로그온은 수행된다. 좀 더 유식한 용어를 사용해 아는 척을 좀 해보면(물론 필자가 잘못 알고 있을 수도 있다. 그렇다면 지적 바란다... -_-), AD 에 가입되면 로컬 컴퓨터에 로그온하면 AD는 자격 증명을 발행해 준다. 그리고 로컬 컴퓨터에서 원격 컴퓨터(이 경우 파일 서버)에 접근할 때 자신의 자격 증명을 원격 컴퓨터에 제시한다. 원격 컴퓨터는 자신이 속한 도메인의 자격 증명임을 확인하고 해당 계정이 파일서버에 로그온 할 수 있다면 로그온을 수행한다.

도메인에 가입되지 않은 상황에서도 아뒤/암호를 묻지 않을 수도 있다. 이 경우, 클라이언트 프로그램(예를 들어 탐색기) 스레드에 적용된 현재 사용자의 아이디/패스워드를 이용하여 파일서버에 로그온을 시도한다. 만약 파일서버에 동일한 아이디/패스워드를 가진 계정이 존재한다면 로그온은 성공할 것이다. 이 때문에 아이디/패스워드를 묻지 않는 것이다.

어찌 되었건 로그온이 실패하면 친숙한 아이디 패스워드를 묻는 대화 상자가 나타나게 된다. 일단 로그온이 되면 서버는 해당 계정이 공유 폴더에 접근할 액세스 권한이 있는가를 살피게 된다. 권한이 있다면 액세스를 허용할 것이고 권한이 없다면 매몰차게 액세스를 거부해 버릴 것이다. 주의할 점은 일단 로그온이 되어야 권한 검사를 할 수 있다는 점이다.

일단 로그온이 되고 액세스 권한이 있다면 파일 서버와 클라이언트는 세션을 맺게 된다. 세션 하니깐 또 ASP.NET의 세션을 생각하는 사람이 있다면 X잡고 반성해야 한다. 좀 더 넓게 세상을 바라보길 권하는 바이다.... 이 세션은 파일 공유의 세션을 말한다. 이 세션 동안에는 로그온을 다시 시도하지 않고 공유 폴더를 액세스하게 된다. 지속적으로 파일 서버를 액세스하면 이 세션은 계속 유지된다. 그러나 일정 시간(디폴트 15분)동안 파일 서버를 액세스하지 않으면 이 세션은 끊기게 된다. 세션이 끊긴 후 다시 공유 폴더를 액세스하는 경우, 세션을 다시 맺을려고 시도하며 로그온 역시 다시 시도된다. 이때 클라이언트는 이미 캐시 된 자격증명(아이디/패스워드는 캐시 하지 않는다!)을 다시 사용하므로 아이디 패스워드를 다시 묻지는 않을 것이다. 세션의 타임아웃 시간은 서버(Windows 2000/2003 서버)의 경우 15분, 워크 스테이션(Windows 2000 Professional, Windows XP)은 정의되어 있지 않다. 이 설정을 바꾸려면 그룹 정책 개체 편집기 혹은 Policy Editor 를 사용하거나 로컬 보안 정책 MMC 스냅인을 사용하여 변경할 수 있다(변경 후 LanmanServer 서비스를 다시 시작해야 한다). 화면2를 참고하기 바란다.

로그온 및 세션에 대한 정확한 사항은 이 내용과 다를 수 있다. 필자 역시 마이크로소프트 공식 문서나 관련 도움말에서 알아낸 것이 아니라 여기저기 조각난 정보들을 짜 맞춘 것이기 때문이다. 필자가 방금 이야기한 내용이 사실과 다르다면 곧바로 필자에게 꼰질러 주면 감사하겠다.

화면2. 파일 공유 세션 타임아웃 설정

정말 타임아웃이 되는지 살펴보고 싶다면 타임아웃 시간을 짧게 잡아놓고 세션을 모니터링 해보기 바란다. 세션이 어떻게 맺어지고 있고 유휴 시간이 얼마나 되는지 알아보고 싶다면 컴퓨터 관리 MMC에서 공유 폴더 밑에 있는 세션을 클릭해서 관찰해 볼 수 있다. 주어진 유휴 시간이 초과하면 세션은 끊기게 됨을 확인해 보자. (귀찮거나 싫으면 걍 필자를 믿던가... -_-;)

화면3. 파일 공유 세션 모니터링

Access Control

공유 폴더를 액세스할 때 종종 겪는 것이 권한 없다는 메시지일 것이다. 이런 오류 메시지를 몇번 겪다 보면, 귀차니즘이 몰려오고 원인을 알 수 없는 "권한 없음" 때문에 연신 욕지거리를 하며 Administrator 계정 혹은 Administrators 그룹을 이용하여 공유 폴더에 권한을 주는 경우가 허다하다.

Access Permission

공유 폴더에 관련된 권한 설정을 할 때는 반드시 공유 폴더 자체에 대한 권한과 공유되어지는 폴더 및 파일에 대한 권한을 모두 고려해야 한다. 공유 폴더에 대한 권하는 해당 공유 폴더를 액세스할 수 있는 권한을 설정하는 것이다. 이는 말 그대로 공유 폴더를 네트워크를 통해 액세스할 수 있음을 설정하는 것이지 공유 폴더 내의 파일 혹은 폴더에 대한 권한을 설정하는 것이 아님에 유의해야 한다. 실예로 공유 폴더에 권한을 주었지만 공유 폴더에 존재하는 특정 파일/폴더를 읽거나 쓸 수 없어서 "권한 없음" 오류가 발생할 수 있기 때문이다. 따라서 공유 폴더 자체에 읽기/쓰기 권한을 주었다면 파일 시스템의 해당 폴더 및 파일들에도 읽기/쓰기 권한을 주어야 한다.

클라이언트가 공유폴더에 적절한 권한을 갖고 액세스하기 위해서는 앞서 언급한 대로 일단 로그온이 가능해야 할 것이다. 로그온이 가능하려면 액티브 디렉터리 환경을 사용하던가 아니면 클라이언트와 파일 서버에 동일한 아이디/암호를 갖는 계정을 똑같이 만들어야 함을 잊지 말자. 그리고 이들 도메인 계정 혹은 동일한 아이디/암호를 갖는 로컬 계정에 대해 공유 폴더 및 파일 시스템 폴더/파일에 권한을 주어야만 한다.

Special Account

또 한가지 자주 범하는 실수는 계정에 대한 혼동이다. 공유 폴더에 권한을 줄 때는 오직 파일 서버가 "볼 수 있는" 계정에 대해서만 권한을 줄 수 있다. 액티브 디렉터리가 사용 중이라면 도메인 계정/그룹과 로컬 계정/그룹에 대해 권한을 설정할 수 있으며, 액티브 디렉터리를 사용하지 않는다면 로컬 계정/그룹에 대해서만 권한을 줄 수 있다.

이 때, 로컬 컴퓨터에만 존재하는 특별한 계정들에게 권한을 주는 오류를 자주하게 되는데, 이런 류의 계정이 바로 SYSTEM, NETWORK SERVICE, LOCAL SERVICE, ASPNET, IUSR_XXX 등의 계정이다. 이들 계정은 모두 암호가 랜덤하게 결정되며 이 계정들의 암호를 알아낼 방법이 없다.  다시 말하자면 각 컴퓨터 마다 SYSTEM 계정, NETWORK SERVICE 계정, ASPNET 계정이 존재하더라도 이들의 암호는 서로 다르다. 따라서 이들 계정에 대해 공유 폴더의 권한을 주는 것은 매우 우매한 짓이라는 것이다.

마지막으로 권한에 관련되어 알아둘 것은 SYSTEM 계정, NETWORK SERVICE 계정, LOCAL SERVICE 계정이 Windows 네트워크를 액세스할 때 갖는 특성이다. 이들 계정들은 윈도우 설치와 더불어 생성되는 특수한 Built-in 계정으로서 네트워크를 액세스할 때는 이들 계정이 아닌 다른 계정을 사용하여 액세스하기 때문이다.

먼저 LOCAL SERVICE 계정으로 작동하는 프로세스/스레드가 네트워크를 액세스할 때는 항상 ANONYMOUS LOGON 이란 계정을 사용한다. ANONYMOUS LOGON 계정 역시 특수 계정으로서 말 그대로 익명 사용자이다. 익명 사용자는 Everyone 그룹에도 포함되지 않는 왕따 계정이 되겠다(사실 Windows XP 이상부터 익명 계정이 Everyone 그룹에서 제외되었다). LOCAL SERVICE 계정으로 작동하는 프로세스(대개의 경우 Windwos 서비스 이거나 IIS 작업 프로세스이다)는 익명 계정을 사용하기 때문에 거의 공유 폴더에 접근할 수 없다고 보면 된다. 물론 파일 서버에서 익명 계정을 Everyone 그룹으로 포함시키거나 명시적으로 익명 계정에 권한을 주고 또, Lanmanserver 서비스가 ANONYMOUS LOGON 계정을 허용하도록 설정하면 가능하긴 하지만 말이다(구체적으로 알려고 하지말자. 졸라 복잡타...).

SYSTEM 계정과 NETWORK SERVICE 계정으로 작동하는 프로세스/스레드가 네트워크를 액세스할 때는 특별한 컴퓨터 계정이란 것이 사용된다. 컴퓨터 계정은 컴퓨터 이름 뒤에 $ 표시가 붙는 특별한 계정으로서 컴퓨터 자체를 나타낸다. 컴퓨터 계정은 액티브 디렉터리 도메인이 사용되지 않으면 전혀 의미가 없는 계정이다. 액티브 디렉터리는 도메인에 가입한 컴퓨터들에 대한 목록을 유지하며 각 컴퓨터 계정에 대한 정보를 갖고 있기 때문에 도메인에 가입한 컴퓨터들을 서로 컴퓨터를 인증하고 권한을 줄 수 있게 되어 있다. 하지만 도메인에 가입하지 않은 워크 그룹(work group) 컴퓨터들은 서로의 컴퓨터 계정을 인증할 방법이 전혀 없기 때문에 SYSTEM 계정과 NETWORK SERVICE 계정을 사용하는 프로세스/스레드는 공유 폴더에 접근할 방법이 거의 없게 되는 것이다. 그런데... IIS 6.0의 작업 프로세스가 사용하는 디폴트 계정이 바로 NETWORK SERVICE 이며, 이 계정에 대한 제약이 많기 때문에 바꾸어 사용하는 것이 바로 SYSTEM 계정이다. 고로... 공유 폴더를 액세스할 때 문제가 당연히 발생할 공산이 높다!

하나 더 이야기 할 계정이 있다면 바로 ASPNET 계정이다. ASPNET 계정은 닷넷 프레임워크를 설치하면 생성되는 계정으로, Built-in 특수 계정은 아니지만 암호가 매번 바뀌고 암호를 알아낼 수 없는 계정이다. ASPNET 계정은 Windows 2000 혹은 Windows XP에서 IIS 5.x가 사용될 때만 ASP.NET 작업 프로세스의 계정으로 사용된다. 이 계정은 닷넷 프레임워크가 정상적으로 설치된 모든 컴퓨터에 존재하는 계정이긴 하지만 개개의 암호는 모두 다르다. 이 때문에 ASP.NET 어플리케이션에서 공유 폴더를 액세스할 때 애로(므흣?) 사항이 있는 것이다.

마지막으로 하나만 더 이야기 해보자. 지겹더라도 좀 참아라... 이렇게 글로 쓰는 필자는 오죽하겠냐... IUSR_XXX 계정이 바로 마지막으로 언급할 계정이다. 이 계정은 IIS가 설치되면 생성되는 계정으로서 뒤에 XXX는 컴퓨터 이름이 되겠다. 이 계정은 웹 어플리케이션을 익명으로 사용하는 경우 웹 어플리케이션 쓰레드에게 설정되는 계정이다. 당연 각 컴퓨터마다 계정 아이디도 다르고 암호도 다르다. 고로 이 계정 역시 공유폴더를 액세스하는 데는 애로 사항이 있겠다. IUSR_XXX 계정이 언제 사용되고 ASP.NET 과의 관계를 좀 더 자세히 알고 싶다면 닷넷과 IIS Security 란 필자의 글을 읽어 보기 바란다.

따라서, 적절히 공유 폴더를 액세스 하고자 한다면, 액티브 디렉토리를 사용하던가 아니면 파일 서버에 공유 폴더 액세스를 위해 특정 계정을 생성하고 모든 클라이언트가 이 계정을 사용하도록 하면 될 것이다.

Summary

공유 폴더를 액세스하는 것은 어렵지 않게 보인다. 탐색기에서 \\xxx.xxx.xxx.xxx 라고 입력하거나 간단히 네트워크 드라이브를 연결하는 경우, 대부분 문제 없이 공유 폴더를 액세스할 수 있기 때문이다. 이렇게 공유 폴더를 액세스할 수 잇는 이유는 해당 공유 폴더가 적절히 설정되어 있고, 특수 계정이 아닌 사용자 계정이 사용되고 있기 때문이다. 그러나 ASP.NET 혹은 기타 COM+ 컴포넌트, Windows 서비스 에서 공유 폴더를 액세스 할려 치면 조또 보기 싫은 "권한 없음" 혹은 "로그온 실패" 등의 오류 메시지가 졸라 나타나는 것이다.

왜 그렇게 쉽게 보이는 공유 폴더 액세스가 실패할까? 그것은 파일 서버가 공유 폴더에 권한을 줄 때 사용하는 계정에 대한 이해가 부족하거나 혼동을 하기 때문이며, 더욱이 ASP.NET, COM+ 컴포넌트, Windows 서비스가 사용하는 계정들이 네트워크를 액세스할 때의 특징을 알지 못하기 때문이다.

그렇다면 공유 폴더에 접근하는 확실한 방법은 파일 서버가 공유 폴더에 준 권한을 갖는 사용자 계정을 이용하여 공유 폴더를 액세스하면 되는 것이다. ASP.NET 어플리케이션의 쓰레드가 이 계정으로 설정되기만 한다면 공유 폴더를 정확하게 액세스할 수 있을 것이다. 다음 포스트에서는 먼저 일반 윈도우 콘솔 어플리케이션에서 공유 폴더를 액세스할 때 특정 계정을 사용하도록 하는 방법을 알아보도록 하겠다. 그리고 나서 ASP.NET에 이것을 응용 시켜 보면 될 것이다. 기대하시라~~~ (기대하는 사람이 얼마나 될까? -_-;)