목차/06. Mobile Access 애플리케이션

06Mobile Access 애플리케이션Mobile Access 애플리케이션

Mobile Access의 가치는 결국 사용자가 포털 안에서 어떤 사내 응용을 쓸 수 있느냐 에 있습니다. 원격 사용자에게 내부망을 여는 것은 곧 외부 위협에 망을 노출시키는 일이라, 연결성과 보안 사이의 균형 을 잡는 것이 핵심입니다. 어떤 경우든 엄격한 인증·인가 로 올바른 사람만 사내 망에 닿게 해야 합니다. 그래서 응용을 정의한다는 것은 곧 어떤 사내 LAN 응용을, 어떤 종류의 원격 사용자에게 노출할지를 결정 하는 일입니다.

Mobile Access는 원격 사용자에게 여러 종류의 사내 응용을 제공합니다 — Web application(웹 애플리케이션), file share(파일 공유), Citrix service, Web mail(웹메일), 그리고 native application 입니다. 이 장은 클라이언트리스로 제공되는 이 응용들을 정의·구성하는 방법, 내부 링크를 인터넷용으로 바꾸는 Link Translation, WebSocket 기반 RDP/SSH, 스마트폰·태블릿용 Exchange 메일 응용, 그리고 한 번 로그인으로 여러 응용을 쓰게 하는 Single Sign-On(SSO) 까지 빠짐없이 정리합니다.

클라이언트리스 응용 — 웹 애플리케이션

웹 애플리케이션이란

Web application 은 같은 맥락에서 웹 브라우저로 접근하는 URL 묶음 으로 정의됩니다(예: 재고 관리, 인사 관리). Mobile Access는 HTML·JavaScript로 만든 사이트의 브라우징을 지원 합니다.

다만 다음과 같은 사이트는 그대로는 안 됩니다.

VBScript·Java·Flash 요소가 임베디드 링크를 담고 있는 사이트는 SSL Network Extender를 거쳐 native application으로 정의 해야 지원됩니다.
일부 사이트는 기본 브라우저로만 동작 하므로 Web application으로 정의할 수 없습니다. 이 경우에도 native application을 씁니다.

특정 유형의 웹 애플리케이션 — iNotes와 OWA

웹 애플리케이션은 iNotes(Domino Web Access) 또는 Outlook Web Access(OWA) 라는 특정 유형 으로도 지정할 수 있습니다.

iNotes 는 IBM iNotes(예전 이름 Lotus Domino Web Access)로, 메일·연락처·일정·스케줄링·협업 서비스를 제공하는 웹 애플리케이션입니다. Domino Web Access는 파일을 클라이언트 측 브라우저가 임시로 캐싱 해야 동작하기 때문에, Mobile Access Protection Level(또는 Endpoint Compliance Profile)의 엔드포인트 브라우저 캐싱 설정이 이 파일들에는 적용되지 않습니다. 또 연결이 되게 하려고 Domino Web Access에 대해서는 XSS(cross site scripting)·command injection·SQL injection Web Intelligence 보호가 해제됩니다.

Outlook Web Access(OWA) 는 Microsoft Outlook과 같은 모양·느낌·기능을 가진 웹 기반 메일 서비스 입니다. Mobile Access는 OWA 버전 2000, 2003 SP1, 2007, 2010, 2013, 2016 을 지원합니다. OWA 기능은 이메일·일정·연락처 같은 기본 메시징 구성요소를 포괄합니다.

Mobile Application 객체 만들기

SmartConsole에서 Mobile Access 응용 객체를 만들고 설정합니다.

SmartConsole에서 Objects > Object Explorer(Ctrl+E)를 클릭합니다.
New > Custom Application/Site > Mobile Application 을 클릭하고 원하는 Mobile application 유형을 고릅니다. 그러면 Mobile application 창이 열립니다.

Web Application — General Properties 페이지

General Properties 페이지에서 웹 애플리케이션의 기본 설정을 합니다.

Name — 응용의 이름입니다. 사용자 포털에 보이는 이름은 여기가 아니라 Link in Portal 페이지에서 정의 한다는 점에 유의하세요.
This application has a specific type — 웹 애플리케이션이 다음 유형 중 하나일 때 선택합니다.
- Domino Web Access — 메일·연락처·일정·스케줄링·협업 서비스를 제공하는 웹 애플리케이션.
- Outlook Web Access(OWA) — Microsoft Outlook의 모양·느낌·기능을 가진 웹 기반 메일 서비스.

Web Application — Authorized Locations 페이지

Authorized Locations 페이지에서 이 웹 애플리케이션에 접근할 수 있는 위치 를 정의합니다.

OWA로 정의한 응용은 다음 디렉터리가 허용 디렉터리로 자동 설정 됩니다.

용도	허용 디렉터리
Private Mailboxes(개인 메일함)	`/exchange/`
Graphics and Controls(그래픽·컨트롤)	`/exchweb/`
Client access(클라이언트 접근)	`/owa/`
Public Folders(공용 폴더)	`/public/`

페이지의 항목은 다음과 같습니다.

Host or DNS name — 응용이 호스팅되는 호스트나 DNS 이름.
Allow access to any directory — Servers에 정의된 응용 서버의 모든 위치 에 접근을 허용합니다.
Allow access to specific directories — 특정 디렉터리로 접근을 제한 합니다(예: /finance/data/). 경로에는 현재 로그인한 사용자 이름을 뜻하는 $$user를 넣을 수 있습니다.
Application paths are case sensitive — 경로의 대소문자를 구분해 보안을 높입니다. 대소문자를 구분하는 UNIX 기반 웹 서버 에 사용합니다.
Services that are allowed — 보통 평문 접근용 HTTP, SSL 접근용 HTTPS 입니다. HTTPS에 쓸 SSL 버전을 목록에서 고를 수 있으며 기본은 Automatic 입니다.
Advanced — 여러 서비스를 함께 선택할 수 있습니다.

Web Application — Link in Portal 페이지

Link in Portal 페이지에서 Mobile Access 사용자 포털에 보일 응용 링크 를 구성합니다.

Add a link to this Web application in the Mobile Access Portal — 링크를 입력하지 않아도 사용자는 포털에서 URL을 직접 입력해 응용에 접근할 수 있지만, 미리 구성된 링크는 없게 됩니다.
Link text(다국어) — 포털에 표시되는 텍스트입니다. $$user(현재 로그인 사용자 이름)를 넣을 수 있습니다. 같은 이름(대소문자 무시)의 링크가 둘 이상이면 포털에는 하나만 표시 됩니다.
URL — 응용 위치로 가는 링크입니다. $$user를 넣을 수 있습니다. 예를 들어 http://host/$$user로 정의하면 사용자 aa에게는 http://host/aa, bb에게는 http://host/bb로 보입니다.
Tooltip(다국어) — 추가 정보를 주는 툴팁입니다. $$user를 넣을 수 있고, 커서를 링크 위에 올리면 자동으로 나타났다가 클릭하거나 커서를 치우면 사라집니다.

Web Application — Protection Level 페이지

Protection Level 페이지에서 웹 애플리케이션의 보호 수준과 브라우저 캐싱 을 구성합니다.

이 응용 접근을 위한 보안 요건(Security Requirements for Accessing this Application) 은 두 가지입니다.

This application relies on the security requirements of the gateway — 게이트웨이 보안 요건에 의존 합니다. 포털 접근이 허가된 사용자는 이 응용 접근도 허가됩니다. 기본 옵션 입니다.
This application has additional security requirements specific to the following protection level — 응용에 Protection Level을 연결합니다. 사용자는 포털 요건에 더해 이 응용만의 보안 요건까지 충족 해야 합니다.

엔드포인트 브라우저 캐싱(Browser Caching on the Endpoint Machine) — 원격 사용자 브라우저의 웹 응용 콘텐츠 캐싱을 제어합니다.

Allow caching of all content — Link Translation 방식 중 Hostname Translation을 쓸 때 권장 되는 설정입니다. ActiveX·스트리밍 미디어는 Hostname Translation을 사용합니다.
Allow caching of these content types — 캐싱할 콘텐츠 유형(images, scripts, HTML)을 선택합니다.
Prevent caching of all content — 완전히 통제할 수 없는 워크스테이션에서 접근하는 원격 사용자의 보안을 높입니다. 개인 데이터가 워크스테이션에 저장되지 않습니다. 주의! 이 설정을 켜면 외부 응용이 필요한 파일(예: MS Office 파일)이 열리지 않으며, 캐싱이 필요한 응용이 오작동할 수 있습니다.

웹 콘텐츠 캐싱 구성하기

Protection Level은 관리자가 브라우저의 웹 콘텐츠 캐싱을 막을 수 있게 해 줍니다. 대부분 브라우저의 캐싱 기능은 캐시 내용에 해커가 쉽게 접근 할 수 있어 보안 위험이 됩니다.

Prevent caching of all content 를 켜면 외부 뷰어가 필요한 파일(예: Word·PDF)을 못 열 수 있어, 사용자가 먼저 파일을 로컬에 저장 해야 합니다.

사용자가 외부 파일을 열 수 있게 하려면 다음과 같이 합니다.

Protection Level을 Allow caching of all content 로 설정합니다.
Microsoft Office 문서를 HTML 캐싱 범주에 추가합니다.
1. 다음을 실행합니다.

Apache 구성 파일을 백업합니다: $CVPNDIR/conf/http.conf
1. 이 파일에서 Microsoft Office 문서 관련 CvpnCacheGroups 지시어의 주석을 해제합니다.
2. 클러스터 구성이라면 모든 클러스터 멤버 에서 이 단계를 반복합니다.
3. 다음을 실행합니다.

정책을 설치(Install Policy)합니다.

Web Application — Link Translation 페이지

Link Translation 페이지에서 이 웹 애플리케이션이 내부 URL을 인터넷용 유효 링크로 어떻게 바꿀지 구성합니다.

Use the method specified on the gateway through accessing this application — 게이트웨이의 Additional Settings > Link Translation 페이지(Link Translation Settings on Gateways)에서 구성한 방식을 따릅니다.
Using the following method — 이 응용이 쓸 방식을 직접 고릅니다.
- Path Translation — 신규 설치의 기본값.
- URL Translation — Mobile Access 게이트웨이가 추가 구성 없이 지원.
- Hostname Translation — Mobile Access Applications 방식(별도 구성·인증서 필요).

현재 로그인 사용자 이름 사용하기($$user)

Mobile Access 응용은 현재 로그인한 사용자 이름에 따라 다르게 동작 하도록 구성할 수 있습니다. 예를 들어 포털 링크에 사용자 이름을 넣거나, 파일 공유가 사용자의 홈 디렉터리를 가리키게 할 수 있습니다. 이를 위해 $$user 지시어를 씁니다 — Mobile Access 세션 동안 $$user는 현재 로그인한 사용자의 로그인 이름으로 풀립니다.

이런 개인화 구성을 하려면 웹 애플리케이션·파일 공유·native application 정의의 해당 위치에 $$user 문자열을 넣습니다. 예를 들어 http://host/$$user로 정의한 URL은 사용자 aa에게 http://host/aa, bb에게 http://host/bb로 나타납니다. 사용자가 인증서로 인증 하면 $$user는 로그인 과정에서 인증서에서 추출되어 디렉터리 서버가 인가한 사용자 이름 으로 풀립니다.

웹 애플리케이션 구성 마무리

구성을 끝내려면 정의한 웹 애플리케이션을 정책 규칙에 넣고 SmartConsole에서 정책을 설치합니다. Unified Access Policy 방식은 Authorization 장, legacy 정책 방식은 Getting Started 장을 참고합니다.

웹 애플리케이션별 프록시 구성

웹 애플리케이션마다 HTTP 또는 HTTPS 프록시 서버를 따로 정의 할 수 있습니다. 이렇게 하면 사용자에게 허용되는 웹 리소스 접근을 더 세밀하게 통제할 수 있습니다. 구성 상세는 sk34810 을 참고하세요.

사용자 지정 HTTP 헤더 전달 구성(CvpnAddHeader)

표준 HTTP 인증 방식을 지원하지 않는 사내 전용(proprietary) 웹 애플리케이션 에는, HTTP 헤더에 담긴 최종 사용자 자격(사용자명·IP 주소)을 전달하는 CvpnAddHeader 지시어를 쓸 수 있습니다.

지정한 값을 담은 사용자 지정 HTTP 헤더를 Mobile Access가 자동 전달하도록 하려면 다음과 같이 합니다.

$CVPNDIR/conf/http.conf를 편집합니다. Mobile Access 클러스터라면 모든 멤버 를 편집합니다.
다음 구문으로 CvpnAddHeader 줄을 추가하거나 수정합니다.

   CvpnAddHeader "customized_header_name" "customized_header_value"

customized_header_value에는 다음 두 매크로를 쓸 수 있습니다.

$CLIENTIP — 최종 사용자 클라이언트 머신의 실제 IP 주소로 풀립니다.
$USER NAME — 로그인 페이지에서 자격으로 입력한 사용자 이름으로 풀립니다.

예시:

CvpnAddHeader "CustomHTTPHeaderName" "MyCustomHTTPHeaderValue"
CvpnAddHeader "CustomIPHeader" "$CLIENTIP"
CvpnAddHeader "CustomUsernameHeader" "$USER NAME"

웹 애플리케이션 기능

Mobile Access에는 웹 애플리케이션을 효율적·안전하게 다루는 여러 기능이 있습니다.

Reuse TCP Connections

Reuse TCP Connections 기능은 원래 닫힐 TCP 연결을 재사용 하게 해 성능을 높입니다. 켜려면 Security Gateway 구성 파일을 수정합니다.

웹 애플리케이션의 General Properties 페이지에는 Application Type 섹션이 있어 응용을 Domino Web Access 또는 Outlook Web Access 유형으로 지정할 수 있습니다. 이전 버전에서는 이 유형을 고르면 요청마다 TCP 연결이 닫혔지만, Reuse TCP Connections를 켜면 연결이 재사용 됩니다. 그러면 3-way handshake를 다시 할 필요가 없고 최적화된 authorization cache 기능도 충분히 활용되어 성능이 좋아집니다. 기본적으로 Reuse TCP Connections는 켜져 있습니다.

Reuse TCP Connections를 끄려면 다음과 같이 합니다.

$CVPNDIR/conf/http.conf 구성 파일의 다음 줄을

   CvpnReuseConnections On

다음으로 바꿉니다.

   CvpnReuseConnections Off

변경을 저장합니다.
설정을 적용하려면 cvpnrestart 명령을 실행합니다.

Mobile Access Security Gateway가 클러스터의 일부라면 각 클러스터 멤버에서 같은 변경 을 합니다.

웹사이트 인증서 검증(Website Certificate Verification)

Mobile Access는 웹사이트 보안 인증서를 검증 해서, 문제가 있을 때 사용자에게 경고하거나, 무시하거나, 사이트를 차단할 수 있습니다.

기본값은 monitor 로, SmartLog에 기록만 남기고 최종 사용자에게는 영향이 없습니다. 설정값은 다음과 같습니다.

값	동작
monitor	기본값. SmartLog에 기록만 남기고 사용자에게 영향 없음
warn	잠재적 보안 문제를 사용자에게 알려, 사용자가 조치를 결정하게 함
block	SSL 서버 인증서에 문제가 있는 사이트를 차단
ignore	사이트 보안 문제를 무시(이 값만 SmartLog 기록을 남기지 않음)

설정 변경 후에는 Mobile Access 서비스를 재시작 해야 합니다. Website Certificate Verification은 Security Gateway별·응용별 로 구성할 수 있으며, Database Tool(GuiDBEdit Tool) 로 구성합니다.

Security Gateway의 웹 애플리케이션 기본 동작을 바꾸려면:

Management Server에 연결된 SmartConsole 창을 모두 닫습니다.
Database Tool(GuiDBEdit Tool)로 Management Server에 연결합니다.
Network Objects > network_objects > 해당 Security Gateway 객체 로 갑니다.
아래 창에서 Connectra_settings 섹션으로 갑니다.
certificate_verification_policy를 검색합니다.
값으로 block, warn, monitor, ignore 중 하나를 입력합니다(기본은 monitor).
변경을 저장합니다(File 메뉴 > Save All).
Database Tool(GuiDBEdit Tool)을 닫습니다.

사내 웹 서버가 널리 알려진 인증서를 쓰지 않으면(예: 내부 CA), 기본 설정을 바꾸거나 신뢰 CA를 Mobile Access에 추가합니다. Security Gateway가 클러스터의 일부라면 클러스터 객체 테이블에도 같은 변경을 합니다.

웹 애플리케이션별 기본 동작을 바꾸려면:

Database Tool(GuiDBEdit Tool)에서 Network Objects > network_objects > 해당 웹 애플리케이션 객체 로 갑니다.
아래 창에서 certificate_verification_policy를 검색합니다.
값으로 block, warn, ignore 중 하나를 입력합니다.
use_gateway_settings 파라미터는 — Security Gateway 설정을 쓰려면 true, 응용별 설정을 쓰려면 false.
변경을 저장하고 Database Tool을 닫습니다.
Security Management Server에서 정책을 설치합니다.

신뢰할 인증 기관(CA) 추가하기

Mobile Access가 기본으로 인식하지 못하는 CA(예: 조직 내부 CA)를 신뢰 인증서에 추가할 수 있습니다. Mobile Access가 기본 인식하는 CA 목록은 일반 브라우저가 인식하는 목록과 동일 합니다. 추가하려면 인증서를 .pem 파일 로 만들어 Mobile Access Security Gateway로 옮깁니다. 클러스터라면 각 멤버에서 같은 작업을 합니다.

신뢰 인증서를 .pem 형식으로 저장하기

신뢰 인증서를 .pem으로 저장하는 절차는 브라우저·버전마다 조금씩 다른데, 아래는 Internet Explorer 7.0 예시입니다.

브라우저로 추가하려는 CA를 사용하는 웹사이트의 인증서를 봅니다(View). 반드시 CA 인증서를 골라야 합니다 — Certification Path 탭에서 CA를 골라 View Certificate 를 클릭합니다.
Details 탭을 선택하고 Copy to File 을 클릭합니다(Certificate Export Wizard가 열립니다).
Export File Format 페이지에서 Base-64 encoded 를 선택합니다.
File to Export 페이지에서 .pem 확장자 를 붙인 파일 이름을 입력합니다.
Finish 를 클릭합니다.

CA 인증서를 Mobile Access로 옮기기

.pem 파일을 Mobile Access Security Gateway의 다음 디렉터리로 옮깁니다.

다음 명령을 실행합니다.

이제 CA가 경고 없이 받아들여집니다. 이 변경에는 Mobile Access 서비스 재시작이 필요 없습니다.

신뢰 목록에서 CA 삭제하기

Mobile Access Security Gateway의 $CVPNDIR/var/ssl/ca-bundle/에서 해당 .pem 파일을 삭제합니다.
다음 명령을 실행합니다.

이 변경에도 서비스 재시작은 필요 없습니다.

Link Translation — 내부 링크를 인터넷용으로

배경

Link Translation 은 Mobile Access가 내부 URL을 인터넷에서 유효한 공개 URL로 바꾸는 과정 입니다. 이렇게 해야 사내 리소스를 모든 인터넷 브라우저에서 접근할 수 있습니다.

Mobile Access는 HTTP 요청을 안전한 HTTPS 요청으로 바꾸고 포트를 443으로 바꿉니다. 이를 위해 소스 URL을 게이트웨이를 거쳐 목적지로 트래픽을 보내는 HTTPS URL 로 번역하고, 번역된 URL을 브라우저로 돌려주어 사용자에게 보여 줍니다.

Mobile Access가 지원하는 Link Translation 방식은 네 가지입니다.

방식	설명
Path Translation(PT)	대부분의 웹 애플리케이션에 동작하는 기본 방식
URL Translation(UT)	가장 오래된 방식. 하위 호환성 을 위해 유지
Hostname Translation(HT)	PT보다 빠르고 더 넓은 범위의 웹 앱을 지원. 추가 구성과 인증서가 필요
Client-side Link Translation	Mobile Access 브라우저 플러그인 또는 Wrapped Mobile application에서 클라이언트 측으로 각 요청을 번역

브라우저에 보이는 번역된 URL의 모습

방식마다 사용자 브라우저에 보이는 번역 URL 모습이 다릅니다. 원본 http://www.example.com/path가 다음처럼 번역됩니다.

방식	번역 결과
UT	`https://ssl.example.com/Web/path,CVPNHost=www.example.com,CVPNProtocol=http`
HT	`https://c-ds1q-itfgppae7oq.ssl.example.com/path` — 난수 같은 `c-ds1q-itfgppae7oq` 문자열이 목적지 URL을 나타냄
PT	`https://ssl.example.com/PT/http://www.example.com/path`
Client-side	클라이언트 측에서 처리

SmartDashboard에서 Link Translation 구성

Link Translation은 응용(웹 앱·Citrix 서비스)의 요건에 맞추거나, 응용이 거치는 Security Gateway의 요건에 맞춰 구성할 수 있습니다. 예를 들어 한 응용은 URL Translation으로, 나머지 응용은 Path Translation으로 동작하게 할 수 있습니다.

Security Gateway의 모든 응용에 기본 방식을 설정 할 수 있습니다 — 다른 방식이 따로 구성된 응용만 기본을 따르지 않습니다.
응용별로 기본 방식을 설정 할 수 있습니다 — 게이트웨이의 기본과 달라도 이 웹 앱은 선택한 방식을 씁니다.
어떤 도메인을 번역할지 구성할 수 있습니다.

Path Translation(PT) 구성

Path Translation(PT) 은 새로 설치한 Security Gateway의 기본 방식 입니다.

Security Gateway의 기본 방식으로 PT를 구성하려면:

SmartConsole에서 Security Gateway를 우클릭하고 Edit 를 선택합니다.
탐색 트리에서 Mobile Access > Link Translation 을 클릭합니다.
Supported Translation Methods 에서 Path Translation(always supported) 가 선택되어 있는지 확인합니다.
Default Translation Method 에서 Path Translation 을 선택합니다.
OK 를 클릭합니다.

응용의 기본 방식으로 PT를 구성하려면:

SmartConsole에서 Objects > Object Explorer(Ctrl+E)를 클릭합니다.
Mobile Access 응용을 검색합니다.
응용을 더블 클릭합니다(Web Application 창이 열립니다).
Additional Settings > Link Translation 을 클릭합니다.
Use the following method > Path Translation 을 선택합니다.
OK 를 클릭하고 Web Application 창을 닫습니다.
정책을 설치합니다.

URL Translation(UT) 구성

URL Translation 은 모든 버전의 Security Gateway가 지원 합니다.

Security Gateway의 기본 방식으로 UT를 구성하려면:

SmartConsole에서 Security Gateway를 우클릭하고 Edit 를 선택합니다.
Mobile Access > Link Translation 을 클릭합니다.
Supported Translation Methods 에서 URL Translation(always supported) 가 선택되어 있는지 확인합니다.
Default Translation Method 에서 URL Translation 을 선택합니다.
OK 를 클릭합니다.

응용의 기본 방식으로 UT를 구성하려면:

Objects > Object Explorer(Ctrl+E)를 클릭합니다.
Mobile Access 응용을 검색해 더블 클릭합니다.
Additional Settings > Link Translation 을 클릭합니다.
URL Translation 을 클릭합니다.
OK 를 클릭하고 정책을 설치합니다.

Hostname Translation(HT) 사용하기

Hostname Translation 은 클라이언트 브라우저에 보이는 URL에서 목적지 호스트명을 난수 같은 문자열로 바꿔 보안을 높입니다. HT를 켜려면 DNS 서버가 와일드카드 호스트명을 풀도록 구성해야 합니다.

Hostname Translation(HT) 구성

HT용으로 DNS 서버를 구성하려면:

DNS 서버에 Mobile Access 하위 도메인을 Mobile Access IP로 푸는 레코드 를 추가합니다: *.domain
- 예: ssl.example.com이 Security Gateway라면 *.ssl.example.com을 게이트웨이 IP로 풀게 합니다. 이 와일드카드는 a.ssl.example.com, b.ssl.example.com 같은 모든 하위 도메인을 포함합니다.
부모 도메인(ssl.example.com)을 별도 DNS 레코드 로 정의해 Mobile Access IP로 풀게 합니다. 이래야 사용자가 FQDN으로 포털에 직접 접근할 수 있습니다.
Server Certificates를 참고합니다.

Security Gateway의 기본 방식으로 HT를 구성하려면:

SmartConsole에서 Security Gateway를 우클릭하고 Edit 를 선택합니다.
Mobile Access > Portal Settings 를 클릭합니다. 다음 메시지가 나오면 일단 Hostname Translation을 해제합니다.

   Hostname Translation requires Portal URL to be defined in the
   following format: 'https://hostname/'

Main URL 에 Mobile Access Security Gateway의 포털 URL을 입력합니다.
Link Translation 을 클릭합니다.
Supported Translation Methods 에서 Hostname Translation 을 클릭합니다.
Default Translation Method 에서 Hostname Translation 을 선택합니다.
OK 를 클릭합니다.
정책을 설치합니다.

응용의 기본 방식으로 HT를 구성하려면:

Objects > Object Explorer(Ctrl+E)를 클릭합니다.
Mobile Access 응용을 검색해 더블 클릭합니다(Web Application 창이 열립니다).
Additional Settings > Link Translation 을 클릭합니다.
Use the following method > Hostname Translation 을 선택합니다.
Advanced Hostname Translation Settings 를 클릭합니다.
HTTP Cookies Handling 모드를 선택합니다.
- On the gateway — 기본값. 사내 웹 서버가 클라이언트에 보내는 모든 HTTP 쿠키를 Mobile Access에 저장하고 클라이언트 브라우저로는 넘기지 않습니다.
- On the endpoint machine — 기본 설정 때문에 HTTP 쿠키를 다루는 (사내 서버의) JavaScript가 클라이언트 브라우저에서 실패하면 이 옵션을 선택합니다. Mobile Access가 HTTP 쿠키를 브라우저로 전달 합니다.
OK 를 클릭하고 Web Application 창을 닫습니다.
정책을 설치합니다.

Hostname Translation 제약

Mobile Access 포털은 Outlook Web Access 2013/2016에 대해 HT 방식이 최적 이며, 반드시 'cookies on the endpoint machine'이 켜져 있어야 합니다. PT 방식은 부분 지원, UT 방식은 지원되지 않습니다.

Link Translation 도메인

웹 애플리케이션용 Link Translation 도메인은 다음 이점이 있습니다.

외부 사이트 연결성을 개선 합니다 — 예를 들어 메일 속 외부 사이트 링크가 Mobile Access에 의해 번역되지 않아 깨지지 않습니다.
Mobile Access 머신의 부하를 줄여 성능을 높입니다.
모든 외부 콘텐츠를 웹 애플리케이션으로 정의하는 수고를 덜어 줍니다.

Legacy SmartDashboard에서 Link Translation 도메인 구성

Mobile Access 탭 > Additional Settings > Link Translation > Link Translation Domains 에서 어떤 도메인이 링크 번역을 쓸지 구성합니다.

번역할 도메인을 수동으로 구성하려면:

Link Translation Domains 영역에서 Manually configure domains to translate 를 선택합니다.
Add Domain 을 클릭해 번역할 도메인 전체나 호스트(URL)를 추가합니다.
Add Exception 을 클릭해 번역하지 않을 도메인 일부나 도메인 내 호스트를 구성합니다.
정책을 설치합니다.

옵션은 다음과 같습니다.

옵션	설명
Translate all domains	기본 동작. 모든 트래픽에 링크 번역이 활성화됨
Manually configure domains to translate	내부 도메인만 목록에 추가. 목록의 도메인만 번역. 도메인 내 예외도 추가 가능. 성능 개선을 위해 권장(보안 유지를 위해 모든 내부 도메인을 목록에)
Do not translate any domain	내부 도메인이 없는 회사에 해당

Wrapped Application과의 Link Translation

Wrapped application을 이용한 Client-Side Link Translation 에서는 Check Point Mobile App 클라이언트가 지정된 wrapped application의 링크 번역을 맡습니다. 이런 응용은 보안 컨테이너에 감싸여(wrapped) 네트워크 리소스에 안전하게 접근하고 데이터 유출을 막 습니다.

Wrapped application은 모바일 기기에서만 쓸 수 있고 Mobile Access 포털에는 보이지 않습니다. 사용법은 App Wrapping Guide를 참고하세요.

Link Translation 관련 이슈

다음 팁은 웹 애플리케이션에 적용됩니다.

ActiveX·스트리밍 미디어를 쓰는 사이트 는 Mobile Access 웹 애플리케이션을 Allow caching of all content 로 구성합니다(Protection Level 페이지에서).
JavaScript로 만든 도메인 쿠키는 지원되지 않습니다. 예를 들어 다음 JavaScript로 쿠키를 만들면, Mobile Access가 .example.com 도메인 아래에 있지 않은 한 클라이언트 브라우저가 쿠키를 Mobile Access·웹 서버로 보낼 수 없습니다.

  document.cookie=Name=Value; domain=.example.com

단, HTTP 헤더로 만든 도메인 쿠키는 JavaScript로 조작되지 않는 한 지원됩니다. - Hostname Translation에서 클라이언트 브라우저에 보이는 URL은 다음과 같습니다.

  https://<Obscured Destination Host Name>.<Mobile Access FQDN>/path

호스트명의 각 부분(https://와 /path 사이)은 최대 63자 로 제한됩니다(RFC 1034). 따라서 프로토콜·포트를 포함한 전체 내부 호스트명이 제한을 받습니다. 또 호스트명은 전체 목적지 경로 대신 난수 같은 문자열로 보이며, OWA·iNotes·Microsoft SharePoint에서 로그아웃하면 Mobile Access 세션이 끊길 수 있습니다.

WebSocket 프로토콜 지원

Mobile Access Software Blade는 WebSocket 프로토콜(RFC 6455)을 쓰는 웹 애플리케이션을 지원 합니다. 일부 3rd-party 응용은 사전 설치된 RDP/VDI 클라이언트 없이도 HTML5·WebSocket을 지원하는 브라우저로 RDP/VDI 기능 을 제공합니다(상세는 sk95311). Mobile Access의 Guacamole 기반 클라이언트리스 RDP-SSH 지원도 WebSocket 기능을 활용합니다.

Check Point 어플라이언스는 수백 명의 동시 WebSocket 사용자 를 지원할 수 있습니다. 인원은 어플라이언스 성능과 배치(Load Sharing 클러스터는 더 많은 사용자 지원)에 달려 있으니, 필요에 맞는 어플라이언스는 Check Point 영업 엔지니어와 상담하세요.

WebSocket 사용하기

WebSocket 지원을 쓰려면 WebSocket 서버로 가는 일반 웹 애플리케이션을 생성 합니다.

웹 애플리케이션의 Authorized Locations 에 WebSocket 연결에 쓰는 포트를 반드시 포함 합니다.
WebSocket 응용과 관련된 웹 애플리케이션은 Link Translation 방식으로 반드시 Path Translation을 써야 합니다(게이트웨이 설정에서 상속하거나 웹 앱에서 구성).

WebSocket 모니터링

Security Gateway 명령줄에 연결합니다.
Expert mode로 로그인합니다.
다음을 실행합니다.

   PingerAdmin report type ws

또는 Pinger 데몬이 현재 다루는 모든 연결(ActiveSync push 등)을 보려면 다음을 실행합니다.

   PingerAdmin report all

파일 공유(File Shares)

File share 는 네트워크 너머의 파일을 열고·읽고·쓰고·지우게 해 주는 응용 으로, 네트워크 상에서 파일 작업을 가능하게 하는 프로토콜로 제공됩니다.

파일 공유 구성

새 File Share Application을 만들려면:

SmartConsole에서 Objects > Object Explorer(Ctrl+E)를 클릭합니다.
New Custom Application/Site > Mobile Application > File Share 를 클릭합니다(File Share Application 창이 열립니다).

File Share Application — General Properties 페이지

File Share Application 객체의 General Properties 페이지로 갑니다. Name 은 SmartDashboard 객체의 이름입니다.

File Share Application — Authorized Locations 페이지

Authorized Locations 페이지에서 사용자가 접근을 허가받는 파일 공유 를 구성합니다. 이 설정은 사용자가 어떤 인터페이스로 접근하든(포털에서 경로 직접 입력, 파일 뷰어로 브라우징, 사용자 정의 즐겨찾기 클릭, 관리자가 정의한 즐겨찾기 경로 클릭) 항상 적용 됩니다.

Servers — 파일 서버가 호스팅되는 머신이나 DNS 이름. 단일 Host or DNS name 또는 Multiple hosts 중 선택합니다.
Allow access to any file share — Servers에 정의된 파일 서버의 모든 위치 에 접근을 허용합니다.
Allow access to specific file shares — 특정 공유로 접근을 제한 합니다(예: My_Share). 슬래시 없이 공유 이름만 씁니다(예: My_share, $$user, My_share$). 공유 안의 하위 디렉터리는 지정하지 않습니다. $$user 변수는 현재 로그인한 사용자 이름을 나타내 개인화 인가를 제공합니다 — 예를 들어 $$user를 파일 공유로 정의하면 로그인 사용자가 alice일 때 서버에 정의된 alice 공유(예: \\myserver\alice)에 접근이 허용됩니다.

File Share Application — Link in Portal 페이지

이 페이지에서 포털에 표시되는 즐겨찾기 링크 하나 를 구성합니다. 링크를 클릭하면 사용자가 지정된 경로에 바로 접근할 수 있습니다. 이 위치는 Authorized Locations 페이지에서 접근을 허가해야 합니다.

Add a link to this file share in the Mobile Access Portal — 링크를 입력하지 않아도 사용자는 포털에서 링크를 직접 입력해 접근할 수 있지만, 미리 구성된 링크는 없게 됩니다.
Link text(다국어) — 포털에 표시되는 텍스트. $$user를 넣을 수 있고, 같은 이름의 링크가 둘 이상이면 하나만 표시됩니다.
Path — 링크가 접근하려는 전체 파일 경로(UNC 구문). 공유 위치나 공유 아래 어떤 경로든 가능합니다. $$user를 넣을 수 있어, 예를 들어 \\host\Pub\users\$$user로 정의하면 alice에게 \\host\Pub\users\alice, Bob에게 \\host\Pub\users\Bob로 나타납니다.
Tooltip(다국어) — 추가 정보 툴팁. $$user를 넣을 수 있습니다.

File Share Application — Single Sign-On 페이지

File Share Application 객체의 Single Sign On 페이지로 갑니다.
Turn on single Sign On for this application 을 선택합니다.
응용의 로그온 방식을 구성합니다. 기본 옵션은 다음과 같습니다.
- Prompt the users for their credentials and store them for future use(사용자에게 자격을 묻고 이후 사용을 위해 저장)

File Share Application — Protection Level 페이지

File Share Application 객체의 Protection Level 페이지로 갑니다.
Security Requirements for Accessing this Application 에서 다음 중 하나를 합니다.
- Security Gateway의 보안 요건을 충족하는 모든 엔드포인트 머신에 접근을 허용.
- 선택한 Endpoint Compliance Profile 을 준수하는 엔드포인트에만 조건부로 접근을 허용.

파일 공유 구성 마무리

SmartConsole을 엽니다.
왼쪽 탐색 패널에서 Security Policies 를 클릭합니다.
Shared Policies 섹션에서 Mobile Access > Policy 를 클릭합니다(Mobile Access Policy 화면이 열립니다).
다음을 연결하는 규칙을 만듭니다.
- User groups(사용자 그룹).
- 그 그룹의 사용자가 접근할 수 있는 Applications.
- Install On — 그 그룹의 사용자가 접속할 수 있는 Mobile Access Security Gateway·Cluster.
Save 를 클릭하고 SmartDashboard를 닫습니다.
SmartConsole에서 정책을 설치합니다.

파일 공유에서 $$user 변수 사용하기

현재 로그인한 사용자 이름을 쓰는 개인화된 사용자 위치 를 구성할 수 있습니다. 사용자 이름을 지정해야 하는 곳마다 $$user를 쓰면, Mobile Access 세션 동안 현재 로그인 사용자의 로그인 이름으로 풀립니다. 예를 들어 \\host\Pub\$$user로 정의한 UNC 경로는 사용자 Alice에게 \\host\Pub\Alice, Bob에게 \\host\Pub\Bob로 풀립니다.

Citrix 서비스

Citrix 배치 모드 — Unticketed와 Ticketed

Unticketed Mode(권장) 시나리오:

원격 접속 사용자가 Mobile Access 사용자 포털에 로그인합니다.
Mobile Access 웹 인터페이스를 통해 사용자가 Citrix Web Interface 서버로 안내 되고, 그다음 Presentation 서버에 접근합니다.

Ticketed Mode 시나리오:

원격 접속 사용자가 Mobile Access 사용자 포털에 로그인합니다.
Mobile Access 웹 인터페이스를 통해 Citrix Web Interface 서버로 안내됩니다.
사용자가 Citrix Web Interface 서버에 로그인하면 Secure Ticket Authority 가 보안 티켓(secure ticket) 을 발급합니다. 이 티켓이 Mobile Access Web Security Gateway에서 검증되면 사용자가 Presentation 서버에 접근할 수 있습니다.

Mobile Access는 자체 STA 엔진을 구현 하므로 별도 Secure Ticketing Authority(STA) 서버를 둘 필요가 없습니다.

Citrix 서비스 구성

SmartConsole에서 Objects > Object Explorer(Ctrl+E)를 클릭합니다.
New Custom Application/Site > Mobile Application > Citrix Services 를 클릭합니다(Citrix Services 창이 열립니다).

Citrix 서비스 구성 전에

Mobile Access 서버 인증서는 FQDN 기반이어야 하고 Mobile Access FQDN으로 발급 되어야 합니다(예: www.sample.com). Citrix의 서버 인증서 표준을 따르려면 Citrix 서비스 구성 전에 FQDN으로 발급된 인증서로 Mobile Access 서버 인증서를 바꿔야 합니다. 또 최종 사용자는 자신의 네트워크에서 라우팅되는 FQDN으로 Mobile Access에 접속 해야 합니다.

Web Interface 서버가 ICA Web 클라이언트를 배포하도록 구성되어 있고 Mobile Access 서버 인증서가 사설 CA가 발급한 것이라면, ICA Web Client가 제대로 동작하도록 Mobile Access 인증서의 공개 키를 클라이언트 측 브라우저에 설치 해야 합니다. 공개 키 위치: $CVPNDIR/var/ssl/server.crt

Citrix Service — Web Interface 페이지

Citrix Service 객체의 Web Interface 페이지로 갑니다.
항목을 채웁니다.
- Servers — Web Interface 서버가 호스팅되는 머신·DNS 이름. 단일 Host/DNS name 또는 Multiple hosts. 환경을 단순하게 유지하려면 Citrix 응용당 단일 Web Interface 서버를 권장 합니다.
- Services — Web Interface 서버 설정과 반드시 일치 해야 합니다. http 또는 https를 선택합니다. 다른 서비스는 지원되지 않습니다.

Citrix Service — Link in Portal 페이지

Citrix Service 객체의 Link In Portal 페이지로 갑니다.
항목을 채웁니다.
- Link text(다국어) — 포털에 표시되는 텍스트. 같은 이름의 링크가 둘 이상이면 하나만 표시됩니다.
- URL — 응용 위치(또는 응용의 하위 디렉터리)로 가는 링크.
- Tooltip(다국어) — 추가 정보 툴팁.

Citrix Service — STA Servers 페이지

Citrix Service 객체의 STA servers 페이지로 갑니다.
Host 를 Web Interface(WI) 서버의 현재 설정에서 가져옵니다.
STA ID 를 STA 서버에서 가져옵니다.

호스트명·IP 주소를 얻으려면:

Web Interface Citrix 관리 페이지에 로그인합니다.
Server-Side Firewall 을 클릭합니다.
Secure Ticket Authority 목록으로 스크롤합니다.
- 필드가 비어 있으면 unticketed 모드 이므로 Mobile Access에 STA 서버를 정의할 필요가 없습니다.
- 항목이 있으면 ticketed 모드 입니다. 각 항목은 Citrix 서버의 IP나 FQDN을 담은 URL이며, 목록의 모든 항목을 Mobile Access에 따로따로 입력 해야 합니다.

STA ID를 얻으려면:

STA 서버에 로그인합니다.
Windows 시작 메뉴에서 Programs > Citrix > Citrix Secure Gateway > Secure Ticket Authority Configuration 을 선택합니다.
Next 를 클릭합니다. STA ID가 Enter the STA ID 필드에 표시됩니다.

Citrix Service — XenApp Servers 페이지

XenApp Servers 페이지에서 XenApp 서버 접근을 구성합니다.

서버를 IP 주소나 FQDN 으로 정의합니다.
정의가 Metaframe 서버 팜의 구성과 일치하는지 확인합니다.

일치하지 않으면 Mobile Access가 연결을 인가하지 못할 수 있습니다(XenApp 서버 구성은 클라이언트가 받는 ICA 파일의 한 파라미터에 영향을 줍니다).

Citrix Service — Single Sign On 페이지

Single Sign On은 응용 보안을 높입니다.

(File Share Application 객체의) Single Sign On 페이지로 갑니다.
Turn on single Sign On for this application 을 선택합니다.
응용의 로그온 방식을 구성합니다.

Citrix Service — Protection Level 페이지

Citrix Service 객체의 Protection Level 페이지로 갑니다.
Security Requirements for Accessing this Application 에서 다음 중 하나를 합니다.
- Security Gateway의 보안 요건을 충족하는 모든 엔드포인트에 접근을 허용.
- 또는 선택한 Endpoint Compliance Profile 을 준수하는 엔드포인트에만 조건부 접근.

STA 서버의 Host와 STA ID를 Web Interface(WI) 서버의 현재 설정에서 가져옵니다(위 STA Servers 페이지의 호스트명·STA ID 얻는 절차와 동일).

Citrix 서비스 구성 마무리

구성을 끝내려면 Citrix Service를 정책 규칙에 넣고 SmartConsole에서 정책을 설치합니다. Unified Access Policy는 Authorization 장, legacy 정책은 Getting Started 장을 참고합니다.

웹메일 서비스(Web Mail Services)

Mobile Access는 내장 웹메일 을 지원합니다. 웹메일은 원격 사용자가 웹 브라우저로 이메일에 접근하는 간단한 방법으로, 도서관·인터넷 카페처럼 인터넷이 되는 어떤 컴퓨터에서든 이메일에 접근할 수 있습니다. 별도 이메일·원격 접속 소프트웨어 설치가 필요 없어 외근이 잦은 직원에게 유용합니다.

Mobile Access는 IBM Lotus Domino Web Access(DWA, 예전 이름 iNotes)와 Outlook Web Access(OWA)도 지원 하는데, DWA와 OWA는 웹 애플리케이션으로 구성합니다.

웹메일 사용자 경험

원격 사용자는 Mobile Access에 로그인·인증해 포털에 접근한 뒤, 링크를 클릭해 웹메일 응용에 접근합니다. Mobile Access는 메일 서버의 IMAP 계정 인증에 로그인 자격을 재사용 하도록 구성할 수 있습니다. 재사용한 자격이 틀리면 다시 로그인 페이지가 나오고, 유효한 자격은 이후 로그인을 위해 저장됩니다.

인증되면 사용자는 다음을 할 수 있습니다.

이메일 작성·발신·수신
메일 폴더 생성·삭제·이름 변경·조작
다양한 방식으로 메시지 색인(index)
주소 저장
본문·제목·발신자 주소 등 다양한 기준으로 이메일 검색
메시지에 다른 배경색을 입혀(highlight) 빠르게 구분
표시 환경설정(Display preferences)

수신(IMAP)·발신(SMTP) 메일 서버

Mobile Access는 수신에 IMAP, 발신에 SMTP 프로토콜 을 쓰는 모든 이메일 응용에 웹 프런트엔드를 제공합니다. IMAP 서버에 저장된 메일은 메시지를 주고받지 않고도 브라우저 인터페이스로 조작 됩니다. 사용자는 인가에 따라 여러 메일 서버에 접속할 수 있습니다.

웹메일 서비스 구성

SmartConsole에서 Objects > Object Explorer(Ctrl+E)를 클릭합니다.
New Custom Application/Site > Mobile Application > Mail Service 를 클릭합니다(Web mail service 창이 열립니다).

Web Mail Service — General Properties 페이지

Web mail service 객체의 General Properties 페이지로 갑니다.
항목을 채웁니다.
- Name — 메일 서비스 이름(예: my_mail_server).
- Outgoing Mail Server(SMTP) — Host or DNS Name(예: smtp.example.com), Service는 보통 표준 사전 정의 SMTP 서비스.
- Incoming Mail Server — IMAP server type, Host or DNS Name(예: smtp.example.com), Service는 보통 표준 사전 정의 IMAP 서비스.

Web Mail Service — Link in Portal 페이지

Web mail service 객체의 Link In Portal 페이지로 갑니다.
항목을 채웁니다.
- Link text(다국어) — 포털에 표시되는 텍스트. 같은 텍스트의 링크가 둘 이상이면 하나만 표시됩니다.
- Tooltip(다국어) — 추가 정보 툴팁.

Web Mail Service — Single Sign-On 페이지

Web mail service 객체의 Single Sign On 페이지로 갑니다.
응용의 로그온 방식을 선택합니다(아래 Single Sign-On 절 참고).

Web Mail Service — Protection Level 페이지

Web mail service 객체의 Protection Level 페이지로 갑니다.
Security Requirements for Accessing this Application 에서 다음 중 하나를 합니다.
- Security Gateway의 보안 요건을 충족하는 모든 엔드포인트 머신에 접근을 허용.
- 선택한 Endpoint Compliance Profile을 준수하는 엔드포인트에만 조건부 접근.

웹메일 서비스 구성 마무리

구성을 끝내려면 웹메일 응용을 정책 규칙에 넣고 정책을 설치합니다. Unified Access Policy는 Authorization 장, legacy 정책은 Getting Started 장을 참고합니다.

웹메일에서 LDAP 연락처 검색 켜기

기본적으로 웹메일의 연락처 검색은 Mobile Access Security Gateway에 정의된 내부 사용자 에만 동작합니다. LDAP 서버에 정의된 연락처까지 검색하려면 sk34997 을 참고하세요.

Guacamole 기반 클라이언트리스 RDP-SSH

Mobile Access는 Apache Guacamole 와 통합되어 Mobile Access 포털에서 클라이언트리스 RDP·SSH 연결 을 제공합니다. 이 기능은 엔드포인트 컴퓨터에 클라이언트를 설치하지 않고도 사무실 데스크톱에 접속 하게 해 주며, WebSocket 기술로 안전하고 매끄러운 인가된 클라이언트리스 원격 데스크톱 연결을 제공합니다.

이 기능에는 다음이 포함됩니다.

Mobile Access Software Blade와 Apache Guacamole 소프트웨어 스위트를 통한 클라이언트리스 RDP·SSH 접근.
외부에 배치된 guacd Docker 컨테이너의 도움.
최종 사용자를 자기 데스크톱에 매핑하기 위한 custom AD 속성 기반 'macro' 인가 지원.
모든 기능은 레거시 Mobile Access 포털과 새 포털 UI 를 모두 지원.

Guacamole

Apache Guacamole 은 HTML5·WebSocket을 통한 클라이언트리스 RDP·SSH·VNC 플랫폼 입니다. 오픈소스이며 MIT 라이선스입니다. Mobile Access와 Guacamole 통합은 R81 이상 에서 포털의 클라이언트리스 RDP·SSH 연결로 제공됩니다.

구성

구성은 Security Gateway(Cluster Member)와 SmartConsole 양쪽 에서 필요합니다.

Security Gateway·Cluster Member 구성

Security Gateway와 Apache Guacamole 서버 간 통신은 $CVPNDIR/conf/cvpnd.C 파일을 갱신해 구성합니다.

속성 이름	기본값	설명
`:guacamoleServerHostname`	`("")`	Apache Guacamole 서버(guacd)의 호스트명·IP
`:guacamoleServerPort`	`(4822)`	guacd 포트 번호
`:guacamoleServerEnableSsl`	`(true)`	guacd로의 SSL/TLS 연결 토글
`:guacamoleValidateApplicationServerCertificate`	`(false)`	guacd가 RDP 서버의 인증서를 검증할지 토글
`:guacamolePreferQualityOverPerformance`	`(false)`	색 심도·Windows 배경 렌더링 등 대역폭 소모 RDP 기능 활성 여부(성능 위해 기본 비활성)
`:showRemoteDesktopSectionOnlyIfLinksExist`	`(true)`	Unified Access Policy 모드에서 원격 데스크톱 링크가 없을 때 포털에 Remote Desktop 섹션을 표시할지 토글
`:guacamoleRdpSecurityMode`	`("any")`	RDP 보안 모드: `any`(기본, handshake 수행), `nla`, `nla-ext`, `tls`, `rdp`
`:customUserRecordAttribute`	`("")`	`$$custom` 매크로가 쓸 사용자 레코드 속성(데스크톱 FQDN·IP 매핑용)
`:guacamoleEnableBitmapCaching`	`(true)`	RDP 전용. 결함 있는 RDP 서버 호환용 — 비활성 시 호환성 개선
`:guacamoleEnableOffscreenCaching`	`(true)`	RDP 전용(위와 동일 범주)
`:guacamoleEnableGlyphCaching`	`(true)`	RDP 전용. Guacamole 1.3.0 이상으로 Windows 7 RDP 서버에 접속하려면 'glyph caching'을 비활성 해야 함
`:guacamoleEnableConsoleMode`	`(false)`	true면 RDP 서버의 'console' 세션에 접속(상시 사용 비권장)
`:guacamoleServerKeyboardLayout`	`("")`	예: `en-us-qwerty`, `fr-fr-azerty`, `failsafe`(Unicode)
`:guacamoleEnableClipboardCopy`	`(true)`	false면 원격 데스크톱→사용자 클립보드 텍스트 복사 차단
`:guacamoleEnableClipboardPaste`	`(true)`	false면 사용자 클립보드→원격 데스크톱 텍스트 붙여넣기 차단
`:guacamoleRdpCustomSettings`	`("")`	향후 Guacamole 버전 호환용 custom RDP 속성. `attribute1=value1;attribute2=value2` 형식

$CVPNDIR/conf/cvpnd.C 파일의 속성을 구성하려면:

명령줄에 연결합니다.
Expert mode로 로그인합니다.
파일을 백업합니다.

   cp -v $CVPNDIR/conf/cvpnd.C{,_BKP}

각 속성을 다음과 같이 설정합니다.

   cvpnd_settings $CVPNDIR/conf/cvpnd.C set <Attribute Name> <Attribute Value>

예시:

   cvpnd_settings $CVPNDIR/conf/cvpnd.C set guacamoleServerHostname guacamole.example.com

guacamoleServerEnableSsl 값이 true(권장)이면 $CVPNDIR/conf/guacdispatcher.C 파일에 아래 SSL 구성이 필요합니다.

속성 이름	기본값	설명
`:trustedCaCertificatesDir`	`("$CVPNDIR/var/ssl/ca-bundle/")`	신뢰 CA 인증서 파일의 게이트웨이 로컬 경로. 인증서 추가 가능. 권장: 기본 유지
`:customCipherSuites`	`("")`	게이트웨이↔guacd SSL에 허용되는 암호화. 권장: 기본 유지
`:verifyServerCertificate`	`(true)`	Guacamole 세션마다 게이트웨이가 guacd 서버 인증서를 검증할지 토글

각 속성을 다음과 같이 구성합니다.

      cvpnd_settings $CVPNDIR/conf/guacdispatcher.C set <Attribute Name> <Attribute Value>

예시:

      cvpnd_settings $CVPNDIR/conf/guacdispatcher.C set verifyServerCertificate true

guacd 서버 인증서가 Mobile Access CA bundle에 없는 CA가 발급한 것이라면:
1. 해당 CA 인증서를 게이트웨이의 신뢰 CA 디렉터리(또는 trustedCaCertificatesDir로 정의된 위치)에 복사합니다.
2. 인증서 파일 확장자를 *.pem으로 바꿉니다.
3. 다음을 실행합니다.

Mobile Access 서비스를 재시작합니다.

SmartConsole 구성

원격 데스크톱 응용을 나타낼 새 Web Application 객체 를 만듭니다.

Global toolbar에서 Objects > More object types > Custom Application/Site > Mobile Application > New Web Application 을 클릭합니다.
왼쪽 트리에서 General Properties 를 클릭합니다.
Name 필드에서 객체 이름은 접두사 guac__(밑줄 두 개)로 시작 해야 합니다.
왼쪽 트리에서 Authorized Locations 를 클릭합니다.
Host or DNS name 필드에서 RDP/SSH 연결을 허용할 Host 객체를 선택합니다(IP 주소나 DNS 객체 사용 가능). DNS 객체 이름에는 다음 매크로를 쓸 수 있습니다.
- $$user — 현재 로그인 사용자의 사용자명.
- $$domain — 로그인 사용자의 도메인 이름.
- $$custom — 위 customUserRecordAttribute 설정으로 구성한 custom 속성 값.

Authorized Locations > Services > Edit 로 갑니다.
다음 중 하나를 유일한 인가 서비스 로 추가합니다.
- Remote_Desktop_Protocol
- SSH
- SSH_version_2

Link in Portal > URL 을 클릭합니다.
특수 URL 형식으로 Guacamole 응용 링크를 정의합니다.

여기서: - <HOST> — 원격 데스크톱 호스트의 호스트명·IP 주소. - <PORT> — 원격 데스크톱 호스트가 RDP 연결을 허용하는 포트. 기본 포트는 RDP 3389, SSH 22.

로그와 디버그

오류가 나면 Mobile Access 포털에 오류 메시지가 표시됩니다. Guacamole 기반 응용의 트래픽 로그는 Web 범주 로 생성되며 서버 오류 시 실패 정보를 담습니다. 사용자별 Guacamole 기반 응용 연결을 보려면 Mobile Access 게이트웨이에서 다음을 실행합니다.

PingerAdmin guac report all

Mobile Access와 Guacamole 서버 통합

Mobile Access Software Blade로 Guacamole 기반 응용을 게시하는 방식은 두 가지입니다 — Guacamole 포털을 표준 Mobile Access Web application 객체로 구성(Guacamole as Web App) 하거나, Mobile Access 포털에서 직접 Guacamole 응용을 게시(Integrated Guacamole) 하는 것입니다.

항목	Guacamole as Web App	Integrated Guacamole
가용성	모든 지원 버전	모든 지원 버전
Guacamole 서버 요건	전체 Guacamole 설치 필요(Java 웹 서버 + guacd)	guacd만 필요(Docker 이미지로 쉽게 사용)
인증	Guacamole 서버가 수행	Mobile Access Software Blade가 정책에 따라 수행
접근 제어	Guacamole 서버가 수행	Mobile Access Software Blade가 정책에 따라 수행
응용 링크	Mobile Access가 제공하는 Guacamole 서버 포털에 표시	Mobile Access 포털에 표시
WebSocket 처리	sk95311대로 프록시되어 guacd로 'as is' 전달	Mobile Access가 처리, 내부 'Guacamole 프로토콜' 내용을 서버로 전달
성능	WebSocket 트래픽을 단일 프로세스 가 처리	WebSocket 트래픽을 여러 프로세스 가 처리
모바일 기기 지원	지원	기기 브라우저 종류에 따라 부분 지원 또는 미지원
프로토콜·기능 지원	RDP·SSH·VNC + 파일 전송·SFTP·세션 녹화	RDP·SSH만 지원(VNC·파일 전송·SFTP·세션 녹화 미지원)

Guacamole 버전 호환성

Mobile Access R81·R81.10은 Guacamole 1.1.0에 최적화 되었고 이후 버전을 부분 지원합니다. Mobile Access R81.20은 Guacamole 1.3.0(현재 Apache 제공 최신 버전)에 최적화 되었습니다.

Guacamole Docker 이미지 설치

Linux 머신에서 guacd Docker 컨테이너를 설치하는 예시 순서입니다.

사용자를 'root'로 전환합니다(또는 아래 모든 명령에 sudo를 붙입니다).

guacd Docker 이미지를 내려받습니다.

   docker pull guacamole/guacd

guacd가 RDP 서버에 닿는 것을 막을 수 있는 Docker 컨테이너 프록시 구성을 비활성 합니다. Docker가 Guacamole의 포트 4822 같은 비-HTTP 연결에도 httpProxy·httpsProxy를 적용할 수 있어 필요한 단계입니다.
1. 파일이 있으면 편집합니다.

guacd 연결에 쓰일 수 있는 프록시 참조를 모두 제거합니다. 일부 Docker 버전은 noProxy 속성을 무시하니 그걸로 프록시 우회를 기대하지 마세요.
내려받은 이미지로 guacd 컨테이너를 실행합니다.

   docker run --name <Name of Container> -d -p <External Port>:4822 -v
   <Path to Directory with Guacamole Server Certificates>:/mnt/certs guacamole/guacd
   /opt/guacamole/sbin/guacd -f -b 0.0.0.0 -L info -C
   /mnt/certs/<Name of Guacamole Server Certificate File> -K
   /mnt/certs/<Name of Guacamole Server Certificate Key File>

예시:

   docker run --name guacd_example -d -p 4822:4822 -v
   /var/tmp/guacCerts:/mnt/certs guacamole/guacd
   /opt/guacamole/sbin/guacd -f -b 0.0.0.0 -L info -C
   /mnt/certs/guacamole.example.com.pem -K
   /mnt/certs/guacamole.example.com.key

guacd 로그를 보려면:

   docker logs <Name of Container> -f

컨테이너를 멈추려면:

   docker container stop <Name of Container>

Custom 사용자 레코드 속성 구성

최종 사용자가 Mobile Access 게이트웨이에 인증하면 Mobile Access는 사용자 디렉터리에서 사용자 레코드를 가져옵니다. 사용자명·그룹 같은 일부 필드는 기본 제공되지만, 사용자 계정을 데스크톱 FQDN·IP에 매핑하는 데 필요한 디렉터리 속성은 보통 기본으로는 없습니다. 이런 custom 속성을 추가하려면:

파일을 백업합니다.

   cp -v $CPDIR/conf/customUserRecordAttribute.conf{,_BKP}

파일을 편집합니다.

   vi $CPDIR/conf/customUserRecordAttribute.conf

아래 형식으로 원하는 속성을 추가합니다.

   :userAttribute ("<Name of User Attribute>")
   )

예시:

   :userAttribute ("info")
   )

변경을 저장하고 편집기를 빠져나옵니다.
Mobile Access 서비스를 재시작합니다.

변경은 최종 사용자가 로그인하고 새 속성이 가져와진 뒤 적용됩니다.

스마트폰·태블릿용 Exchange 메일 응용

Exchange 메일 응용 소개

Mobile Mail 과 ActiveSync 응용은 스마트폰·태블릿 사용자가 Exchange 서버를 통해 이메일·일정·연락처·노트에 접속 하는 응용입니다. 웹 애플리케이션과 파일 공유도 스마트폰·태블릿에서 지원됩니다.

Mobile Mail 응용

Mobile Mail 응용은 Exchange 서버와 동작해 Capsule Workspace App 으로 모바일 기기에서 업무 이메일 을 쓰게 해 줍니다. 응용은 모바일 기기의 보안 영역(보통 passcode로 보호) 에 있고, Capsule Workspace 안의 모든 데이터는 암호화 됩니다.

Mobile Access Wizard에서 Mobile Devices > Capsule Workspace 를 선택하고 Exchange 서버를 입력하면 Mobile Mail 응용이 자동 생성 됩니다. 사용자가 Mobile Access 정책에서 이 응용에 접근할 수 있게 하세요.

Mobile Mail 응용 구성

SmartConsole에서 Objects > Object Explorer(Ctrl+E)를 클릭합니다.
New Custom Application/Site > Mobile Application > Business Mail 을 클릭합니다(Mobile Mail Application 창이 열립니다).
General Properties 페이지에서:
- 응용 Name 을 입력합니다.
- Security Gateway와 통신할 Exchange Server 이름과 Port 를 입력합니다(예: ad.example.com).
Exchange Access 페이지의 Define access settings 영역에서:
- Use encryption(https) — 기본적으로 Exchange 서버 트래픽은 HTTPS로 동작합니다.
- Use non-default path — Exchange Web Services 경로가 기본이 아니면 여기에 입력합니다. 기본 경로는 EWS/Exchange.asmx이고 URL은:

     https://<IP address of the Exchange Server>/EWS/Exchange.asmx

Use specific domain — 특정 도메인으로 인증하게 하려면 입력합니다.
Exchange Access 페이지의 Proxy Settings 영역에서, Exchange 서버와 Security Gateway 사이에 프록시 서버가 있으면 구성합니다.
- Use gateway proxy settings — 기본적으로 Security Gateway에 구성된 프록시 설정을 씁니다.
- Do not use proxy server — 프록시가 필요 없으면 선택합니다.
- Use specific proxy server — Security Gateway가 Exchange 서버에 닿기 위해 통신할 프록시 서버를 구성합니다.
  1. Host 와 Service 를 선택합니다.
  2. 프록시 접근에 자격이 필요하면 Use credentials for accessing the proxy server 를 선택하고 Username·Password 를 입력합니다.
Display Link 페이지에서:
- Title — 사용자가 모바일 기기에서 볼 응용 이름.
- Description — 사용자가 볼 응용 설명.
Single Sign On 페이지에서 이 응용의 SSO에 쓸 자격 출처를 선택합니다.
- Login to Exchange with the application credentials — 기본. Business Secure Container 로그인에 쓰는 같은 자격을 사용. 게이트웨이에 구성된 인증 방식이 Username/Password일 때만 적용됩니다(Gateway Properties > Mobile Access > Authentication).
- Prompt for user credentials and store them locally for reuse — Business Secure Container에 다른 자격 을 씁니다.
  - Show the user the following message on the credentials prompt — 자격 입력 시 사용자에게 보여줄 메시지를 입력합니다.
Periodic Test 페이지에서 Security Gateway가 Exchange 서버에 연결되는지 주기적으로 실행할 테스트 를 선택합니다. 연결 문제가 있으면 System Alert 로그가 생성됩니다.
- Run periodic test from gateways that have access to this application — Security Gateway↔Exchange 서버 연결성을 확인하는 테스트를 입력한 간격으로 실행합니다.
- Perform extensive test using the following account — 사용자가 Exchange 서버에 인증되는지 주기적으로 테스트합니다. 유효한 Username·Password 가 필요합니다.

OK 를 클릭합니다.
정책을 설치합니다.

Office 365 / OAuth 2.0

Mobile Access Blade와 Capsule Workspace는 OAuth 2.0 인증 프로토콜 로 Office 365 클라우드 메일 서비스에 연결할 수 있습니다. 구성 대상은 Security Gateway, SmartConsole, 최종 사용자 디렉터리, Office 365 서비스 네 가지입니다.

Security Gateway 구성

Capsule Workspace가 OAuth 2.0으로 Office 365에 인증하고, 게이트웨이가 Office 365 관련 알림을 구독하려면 $CVPNDIR/conf/cvpnd.C 파일에 다음 구성을 넣어야 합니다.

속성 이름	기본값	설명
`:Office365TenantID`	`("")`	Microsoft Entra ID(구 Azure AD) Office 365 응용 객체에 등록된 고객의 UUID
`:Office365ApplicationID`	`("")`	Microsoft Entra ID에 등록된 Office 365 응용의 UUID
`:Office365ClientSecret`	`("")`	Microsoft Entra ID가 Office 365 응용 객체에 생성한 고객의 client secret(ID가 아니라 값), 난독화 형태(obfuscated) 로 지정. 난독화 형태는 게이트웨이에서 `obfuscate_password client_secret` 명령으로 얻음

$CVPNDIR/conf/cvpnd.C 속성을 구성하려면:

Security Gateway / 각 Cluster Member 명령줄에 연결합니다.
Expert mode로 로그인합니다.
해당 속성을 구성합니다.

   cvpnd_settings $CVPNDIR/conf/cvpnd.C set <Attribute Name> <Attribute Value>

예시:

   cvpnd_settings $CVPNDIR/conf/cvpnd.C set Office365TenantID 1234ab56-c78d-9efa-b01c-de2f0ab12c3

Mobile Access 서비스를 재시작합니다.

SmartConsole 구성

Office 365 메일 응용은 Mobile Mail Application 객체 로 구성합니다.

General Properties > Exchange Server 로 가서 입력합니다.

Exchange Access > Use Specific Domain 으로 가서 Office 365 Enterprise 계정의 도메인을 입력합니다(예: mailaccountdomain.onmicrosoft.com).
Single Sign-On 으로 가서 Prompt for user credentials 를 선택합니다.
Single Sign-On > Credential Formats 로 가서 username@domain 을 선택합니다.
객체 구성을 마치면 접근 정책으로 이 객체를 하나 이상의 Capsule Workspace 사용자 그룹에 추가합니다.

Office 365 클라우드 푸시 알림을 지원하려면:

Mobile Access 'Exchange registration' 포털을 게이트웨이의 공개 접근 가능한 URL 로 사용하게 구성합니다.

SmartConsole에서 Mobile Access Gateway 객체를 엽니다.
왼쪽에서 Mobile Access > Capsule Workspace 를 클릭합니다.
Enable Push Notifications 를 선택합니다.
OK 를 클릭합니다.
SmartConsole 세션을 게시(Publish)합니다.
Database Tool(GuiDBEdit Tool)로 Management Server에 연결합니다.
왼쪽 위 패널에서 Network Objects > network_objects 로 갑니다.
오른쪽 위 패널에서 Mobile Access Gateway 객체를 선택합니다.
CTRL+F 키를 누릅니다.
portals 속성을 검색합니다.
portal_name 속성들을 훑어 ExchangeRegistration 포털에 이릅니다.
포털의 main_url 속성을 SSL/TLS로 제공되는 공개 접근 가능한 호스트명 으로 수정합니다(포털 경로는 그대로 유지). 예시:

변경을 저장합니다(File 메뉴 > Save All).
Database Tool을 닫습니다.
SmartConsole에서 Mobile Access Gateway 객체에 정책을 설치합니다.

최종 사용자 디렉터리 구성

Mobile Access는 사용자 디렉터리 레코드에서 최종 사용자 이메일 주소를 학습 합니다. 디렉터리는 내부 사용자 DB, 로컬 Active Directory, Microsoft Entra ID(구 Azure AD), 또는 다른 LDAP 기반 디렉터리일 수 있습니다.

Capsule Workspace는 최종 사용자가 게이트웨이에 인증하면 곧바로 그 이메일 주소를 받습니다. 이 주소는 Office 365 메일 서비스 인증과 메일 ID 획득 에 쓰이므로, 사용자 레코드에 올바른 이메일 주소를 구성하는 것이 필수입니다. 주소 형식은 다음과 같습니다.

username@mailaccountdomain.onmicrosoft.com

Office 365 서비스 구성

OAuth 2.0 인증은 Microsoft Entra ID(구 Azure AD) 관리 WebUI 에서 'Office 365 Exchange Online' 응용 객체로 구성합니다.

게이트웨이에 구성하는 'client secret' OAuth 2.0 파라미터는 메일 읽기 'impersonation' 권한(Application Permission: full_access_as_app)이 있는 응용 객체 에서 얻어야 합니다. 게이트웨이가 로그인한 최종 사용자의 메일 알림을 등록하는 데 필요합니다.

또한 Capsule Workspace에는 최종 사용자가 OAuth 2.0으로 'Office 365 Exchange Online' 응용에 인증할 수 있도록 application permission(Delegated Permission: EWS.AccessAsUser.All) 이 필요합니다. Capsule Workspace 플랫폼(iOS/Android)에 따라 응용의 'Redirect URIs'도 구성해야 합니다.

iOS의 Capsule Workspace:

Bundle ID	Redirect URI
`com.checkpoint.secureconnectid`	`msauth.com.checkpoint.secureconnectid://auth`

Android의 Capsule Workspace:

Package Name	Signature Hash	Redirect URI
`com.CheckPoint.SSLVpn`	`N+JwdXkEsT15pn8v2+RNjPjwmcs=`	`msauth://com.CheckPoint.SSLVpn/N%2BJwdXkEsT15pn8v2%2BRNjPjwmcs%3D`

ActiveSync 응용

ActiveSync 응용은 대부분 모바일 기기에 기본 내장된 ActiveSync로 동작하는 이메일 응용 입니다. ActiveSync 프로토콜을 쓰고 Exchange 서버에 연결할 수 있는 모바일 기기가 접근할 수 있습니다.

Mobile Mail 응용과 달리, ActiveSync 응용은 Business Secure Container에 있지 않아 보호되지 않습니다. ActiveSync 응용을 쓴다면 민감한 업무 데이터와 Exchange 사용자 자격이 안전하도록 모바일 기기를 다른 방식으로 보호 하세요. 사용자가 Mobile Access 정책에서 ActiveSync 응용에 접근할 수 있게 하세요.

ActiveSync 응용 구성

새 ActiveSync 응용을 만들려면:

SmartConsole에서 Objects > Object Explorer(Ctrl+E)를 클릭합니다.
New Custom Application/Site > Mobile Application > ActiveSync Application 을 클릭합니다(ActiveSync Application 창이 열립니다).

ActiveSync 응용을 구성하려면:

Objects > Object Explorer(Ctrl+E)를 클릭합니다.
Mobile Access 응용을 검색해 더블 클릭합니다(ActiveSync Application 창이 열립니다).
General Properties 페이지에서:
- 응용 Name 을 입력합니다.
- Security Gateway와 통신할 Exchange Server 이름과 Port 를 입력합니다(예: ad.example.com).
Exchange Access 페이지의 Define access settings 영역에서:
- Use encryption(https) — 기본적으로 Exchange 서버 트래픽은 HTTPS로 동작합니다.
- Use non-default path — ActiveSync 경로가 기본이 아니면 여기에 입력합니다.
- Use specific domain — 특정 도메인으로 인증하게 하려면 입력합니다.
Exchange Access 페이지의 Proxy Settings 영역에서, 프록시가 있으면 구성합니다.
- Use gateway proxy settings — 기본. Security Gateway의 프록시 설정 사용.
- Do not use proxy server — 프록시가 필요 없으면 선택.
- Use specific proxy server — 프록시 서버를 구성합니다.
  1. Host 와 Service 를 선택합니다.
  2. 자격이 필요하면 Use credentials for accessing the proxy server 를 선택하고 Username·Password 를 입력합니다.
Display Link 페이지에서 Title·Description 을 입력합니다.
Periodic Test 페이지에서 주기 테스트를 선택합니다(Mobile Mail의 Periodic Test와 동일 — Run periodic test, Perform extensive test using the following account). 계정 암호가 바뀌면 새 암호를 입력해야 합니다.
OK 를 클릭합니다.
정책을 설치합니다.

ActiveSync 응용의 정책 요구사항

ActiveSync에 접근하려면 사용자가 ActiveSync 응용 접근이 허용된 사용자 그룹에 속해야 합니다.
각 사용자는 내부 사용자 객체 속성의 Email Address 필드(또는 LDAP 사용자라면 LDAP 서버)에 이메일 주소가 정의 되어 있어야 합니다.
내부 사용자라면 Check Point 클라이언트 암호가 Exchange 암호와 같아야 ActiveSync가 동작합니다.

Mobile Access 응용 설정

응용의 TLS/SSL 버전 구성

웹 애플리케이션과 Exchange Mail 응용에 대해 내부 서버에 쓸 SSL 프로토콜을 구성 할 수 있습니다(예: Mobile Mail 응용이 항상 TLS 1.0을 쓰게). 구성하지 않으면 Mobile Access는 조직 서버가 권장하는 기본 버전 을 씁니다. 각 응용마다 Database Tool(GuiDBEdit Tool) 로 구성합니다.

Management Server에 연결된 SmartConsole 창을 모두 닫습니다.
Database Tool(GuiDBEdit Tool)로 Management Server에 연결합니다.
Other > network_applications > APPLICATION NAME > internal_resource_ssl_version 으로 갑니다.
버전을 선택합니다. 옵션은 다음과 같습니다.

값	설명
auto(기본)	조직 서버가 권장하는 버전 사용
SSLv3	SSL 3.0
TLSv1	TLS 1.0
TLSv1.1	TLS 1.1
TLSv1.2	TLS 1.2

변경을 저장하고 Database Tool을 닫습니다.
SmartConsole로 Management Server에 연결합니다.
정책을 설치합니다.

Single Sign-On

Single Sign-On 소개

Single Sign-On(SSO) 은 사용자가 Mobile Access 세션 중에 또는 세션 사이에 응용에 두 번째로 접근할 때 다시 인증할 필요를 없앱니다. Mobile Access 포털 로그인에 쓴 인증 자격을, Mobile Access로 접근하는 여러 응용 인증에 자동 재사용 할 수 있습니다. 응용용 다른 자격을 기록해 이후 사용을 위해 저장할 수도 있습니다. SSO 사용자 자격은 Mobile Access에 안전하게 저장 되므로, 사용자가 다른 클라이언트 머신에서 로그인해도 유효합니다.

지원되는 SSO 인증 프로토콜

Mobile Access는 사내 웹·기타 응용 서버 인증에 SSO를 지원합니다. 지원 인증 프로토콜은 다음과 같습니다.

프로토콜	설명
Basic Access	RFC enhancement. 보안 영향 때문에 비권장
Digest Access	RFC enhancement
Integrated Windows Authentication	RFC enhancement. NTLMv1·NTLMv2·Kerberos 지원
Credential forwarding in HTTP headers	Ad hoc 솔루션. 보안 영향 때문에 비권장
Web form(HTML) based	웹 폼 기반

HTTP 기반 SSO

HTTP 수준에서 인증하는 응용에는 자격이 HTTP 헤더로 전달되는 HTTP 기반 SSO 를 쓸 수 있습니다. Basic·Digest·Integrated Windows Authentication·Credential forwarding in HTTP headers 프로토콜에 적용됩니다. 사용자가 이런 사이트에 접근하면 브라우저별 폼 이 열려, 사용자가 그 응용의 사용자명·암호를 입력하고 OK를 누릅니다.

HTTP 기반 SSO 제약

다음 경우 SSO가 지원되지 않습니다.

웹 서버가 digest 또는 Integrated Windows Authentication 방식으로 POST 요청에 인증 을 요구하고,
서버가 ="100 Continue" 응답 전송을 지원하지 않을 때==.

Web Form 기반 SSO

대부분 웹 애플리케이션은 자체 인증 웹 폼을 가지고 있습니다. 이런 응용에 Mobile Access는 Web form(HTML) 기반 SSO 를 지원합니다. HTTP 인증보다 나은 점은, 거슬리는 브라우저별 페이지가 아니라 응용 자체의 로그인 페이지 가 사용자에게 보인다는 것입니다. OWA의 전형적 웹 폼과 함께 사용자를 돕는 Mobile Access SSO 팝업이 나타납니다.

웹 폼 인증으로 동작하도록 구성된 응용마다 Web form 기반 SSO를 쓰는 것이 권장 됩니다. 성능·연결성 유지를 위해 다른 응용에는 Web form SSO를 켜지 마세요.

쉬운 구성을 위한 응용 요구사항

Web form 기반 SSO는 기본 구성에서 SmartDashboard의 체크박스 하나로 구성됩니다. 기본 설정이 동작하려면 응용이 다음을 만족해야 합니다.

사용자가 보는 첫 번째 폼으로 로그인 폼을 제시 할 것.
로그인 성공 시 리디렉트(상태 301 또는 302) 할 것.

Web Form 기반 SSO 제약

Web form 기반 SSO는 다음을 지원하지 않습니다.

암호 교정(Password remediation) 폼.
'old/new/confirm' 암호 필드가 있는 폼. 올바로 인식되지 않아 잘못된 자격이 기록·전달 될 수 있습니다.
폼 제출에 보통의 'ACTION' 속성 대신 Ajax 요청 을 쓰는 폼.

SSO Name Format 구성

이 기능은 응용마다 요구하는 자격 형식이 달라 생기는 SSO 문제를 막습니다. 응용별로 자격 형식을 구성하면, Mobile Access Security Gateway가 조직 서버에 올바른 형식으로 자격을 보냅니다. 웹·Mobile Mail·ActiveSync 응용에 적용되며 Web Form 기반 SSO와 동작합니다.

응용에 필요한 자격 형식을 구성하려면:

SmartConsole에서 mobile application을 엽니다.
Additional Settings > Single Sign-On 을 선택합니다.
Credential Formats 영역에서 옵션을 선택합니다.
정책을 설치합니다.

SSO에 대한 응용·클라이언트 지원

각 Mobile Access 응용에 어떤 SSO 방식이 가능한지는 다음과 같습니다.

Mobile Access 응용	HTTP 기반 SSO 지원	Web Form 기반 SSO 지원
Web applications	Yes	Yes
File shares	Yes	Not relevant
Citrix services	Yes	Yes
Web Mail	Simplified	No
Native applications	No	Not relevant
Mobile Mail	Yes	Not relevant
ActiveSync	Yes	Not relevant

대부분의 Mobile Access 웹 애플리케이션·Citrix 서비스는 구성 없이 또는 최소 구성으로 Web Form SSO를 지원합니다. 일부 응용은 HTTP Post 상세를 수동 구성해야 하고, 일부는 Web Form SSO를 아예 지원하지 않습니다. Web Form SSO와 동작하는 것으로 Check Point가 인증한 일반 응용 목록은 sk35080 을 참고하세요.

웹 애플리케이션 기본 SSO 구성

SmartConsole에서 Objects > Object Explorer(Ctrl+E)를 클릭합니다.
Mobile Access 응용을 검색해 더블 클릭합니다.
탐색 트리에서 Additional Settings > Single Sign On 을 클릭합니다.
Turn on Single Sign On for this application 을 선택합니다.
응용의 로그온 방식을 구성합니다. 기본 옵션은:
- 웹 애플리케이션·File Shares·Citrix Services는 Prompt the users for their credentials and store them for future use.
- 웹메일 응용은 같은 옵션이 Prompt user for credentials 라는 이름입니다.

이 옵션에서는 응용 자격이 저장·재사용되고, 포털 자격은 응용 인증에 쓰이지 않습니다. 6. 정책을 설치합니다.

Web Form SSO 기본 구성

Web form SSO는 Mobile Access 웹 애플리케이션과 Citrix 서비스에만 지원됩니다. 기본 설정에서 Web Form SSO는 응용의 로그인 웹 페이지를 자동 분석 합니다. 기본 설정은 인증 성공 시 HTTP 리디렉트(301, 302), 인증 실패 시 리디렉트 없음 을 가정합니다.

기본 설정으로 구성하려면, Mobile Access 응용의 Single Sign On 페이지에서 This application uses a Web form to accept credentials from other users 를 선택합니다.

Native 응용용 SSO

SSL Network Extender로 접근하는 native application도 SSO 기능을 쓸 수 있습니다. SSO 지원으로, 사용자는 로그인이 필요한 native application에 자동 연결 됩니다. native application은 Mobile Access 포털 로그인 사용자명·암호 파라미터를 내부 서버에서 받습니다.

Native 응용용 SSO 구성

동적 파라미터 $$user 와 $$password 로 native application의 SSO를 구성합니다. 이 파라미터는 Security Gateway가 native application에 넘길 때 로그인 사용자의 실제 사용자명·암호로 풀립니다. 아래는 Simple native application에서 새 $$password 파라미터를 구성하는 방법입니다(Advanced native application의 application parameters에도 $$password를 쓸 수 있습니다).

절차:

SmartConsole에서 Objects > Object Explorer(Ctrl+E)를 클릭합니다.
Mobile Access 응용을 검색해 더블 클릭합니다.
객체 탐색 트리에서 Endpoint Applications 를 선택합니다.
Simple(Application is installed on the endpoint machine) 을 선택하고 다음 필드를 입력합니다.
- Path and executable name — native application 경로(예: Remote Desktop Plus는 D:\rdp.exe).
- Parameters — 사용자명·암호·대상 원격 호스트에 다음 구문을 씁니다.

     /u:acme\$$user /p:$$password /v:192.0.2.2 /f

이 설정은 로컬에 로그인한 사용자의 사용자명·암호를 Security Gateway가 native application에 보내는 방식을 정의합니다. 5. 정책을 설치합니다.

SSO를 쓰도록 SSL Network Extender 클라이언트 업그레이드

native application에서 SSO를 쓰려면 사용자 컴퓨터에 업그레이드된 SSL Network Extender 클라이언트 가 있어야 합니다. Client upgrade 설정을 다음 중 하나로 합니다.

Always upgrade — Security Gateway 업그레이드 후 사용자가 처음 접속할 때 자동 업그레이드.
Ask user — 설치 전 사용자에게 묻습니다(이 옵션을 쓰면 사용자에게 업그레이드를 확인해야 한다고 알려야 함).

업그레이드된 SSL Network Extender 클라이언트는 이전 버전 Security Gateway에도 접속할 수 있습니다.

절차:

SmartConsole에서 Security Policies > Shared Policies > Mobile Access 를 선택하고 Open Mobile Access Policy in SmartDashboard 를 클릭합니다.
탐색 트리에서 Additional Settings > VPN Clients 를 클릭합니다.
Advanced Settings for SSL Network Extender 에서 Edit 를 클릭합니다.
Deployment options 섹션에서 Client upgrade upon connection 이 Always upgrade 또는 Ask user 로 구성되어 있는지 확인합니다.
OK 를 클릭합니다.
Save 를 클릭합니다.
SmartDashboard를 닫습니다.
정책을 설치합니다.

SSO 고급 구성

다음 구성은 HTTP 기반 SSO와 Web form 기반 SSO 모두 에 적용됩니다. 고급 옵션은 웹 애플리케이션·파일 공유·Citrix 서비스에 지원됩니다. Web form SSO 전용 옵션은 위 Web Form 기반 SSO 절을 참고하세요.

고급 SSO 구성

SSO 방식은 여러 가지로, 포털 자격을 어떻게 다룰지, 응용 인증에 쓰는 다른 자격을 어떻게 다룰지 를 구성합니다.

Mobile Access 응용의 Single Sign On 페이지로 갑니다.
Advanced 옵션에서 Edit 를 클릭합니다.

사용 가능한 SSO 방식은 다음과 같습니다.

SSO 방식	SSO On/Off	포털 자격 전달	다른 자격 학습
Turn on Single Sign On for this application	Off. 항상 사용자에게 물음	No	No
Prompt users for their credentials, and store them for future use	On. 기본 방식	No	Yes
This application reuses the portal credentials. Users are not prompted.	On. 고급 방식	Yes	No
This application reuses the portal credentials. 인증 실패 시 사용자에게 물어 자격 저장	On. 고급 방식	Yes	Yes

로그인 설정 구성

로그인 설정으로 기본 Windows 도메인(Windows 인증 시), 자격이 저장된다는 알림, 올바른 자격을 돕는 힌트 를 구성합니다.

Mobile Access 응용의 Single Sign On 페이지로 갑니다.
Login Settings 섹션에서 Edit 를 클릭합니다(Login Settings 창이 열립니다).
아래 설명대로 필드를 채웁니다.

Windows Domain

The user of this application belongs to the following Windows domain — Windows 인증을 쓰면 Windows 도메인이나 작업그룹(예: LOCALDOMAIN)을 지정합니다. Integrated Windows authentication은 도메인을 사용자명·암호와 함께 전달 해야 합니다. SSO 방식이 "Accept the portal credentials from the gateway"이면 Mobile Access가 도메인을 모르므로(사용자가 포털 자격과 함께 도메인을 주지 않으므로) 여기 지정한 도메인 에서 가져옵니다.

User Notification

Notify the users that their credentials for this application are going to be stored — 사용자가 응용 로그인 페이지에 처음 접근할 때 자격이 저장된다는 메시지 를 봅니다.
Allow the users to specify that their credentials for this application will not be stored — 사용자가 처음 접근할 때 자격을 기록하지 않도록 선택할 수 있는 메시지 를 봅니다.

Administrator Message

Show the following message together with the credentials prompt — 사용자가 어떤 자격을 줘야 하는지(예: 도메인+사용자명 AD/user인지 사용자명 user만인지) 힌트 를 보여 줍니다. Help me choose credentials 링크를 클릭하면 힌트가 보입니다. 메시지는 ASCII 문자만 가능합니다.

Web Form SSO 고급 구성

다음 중 하나에 해당하는 응용을 Web form SSO로 구성할 때 고급 설정을 씁니다.

인증 성공 시 HTTP 리디렉트(301, 302)가 없음.
인증 실패 시 리디렉트가 없음.

다음에 대해 서로 다른 기준을 지정할 수 있습니다 — Sign In Success or Failure Detection(성공·실패 감지)과 Credential Handling(자격 처리).

성공·실패 감지 구성

SmartConsole에서 Objects > Object Explorer(Ctrl+E)를 클릭합니다.
Mobile Access 응용을 검색해 더블 클릭합니다(Web Application 창이 열립니다).
탐색 트리에서 Additional Settings > Single Sign On 을 클릭합니다.
Web Form 섹션에서 This application uses a Web form to accept credentials from users 를 클릭합니다.
Edit 를 클릭합니다.
Specify a criterion for success or failure 를 클릭하고 다음 중 하나를 선택합니다.
- Mobile Access regards the authentication as successful, if after signing in, this application creates a cookie with the following name — 응용이 성공 시 세션 쿠키를 둡니다. 정확한 쿠키 이름은 스니퍼나 브라우저 플러그인(예: Fiddler HTTP 디버깅 프록시) 으로 얻습니다.
- Mobile Access regards the authentication as a failure, if after signing in, this application redirects to the following URL — 응용이 실패 시 리디렉트합니다. 대상 URL은 스니퍼·플러그인으로 찾으며, 형식은 <protocol>://<host>/[<path>][?<query>] 입니다.
OK 를 클릭하고 Web Application 창을 닫습니다.
정책을 설치합니다.

자동 자격 처리(Automatic Credential Handling)

기본적으로 Mobile Access는 응용 URL에서 사용자명·암호 필드를 찾습니다. 기본 설정이 동작하지 않으면 자동 자격 감지 방식을 구성하거나 POST 상세를 직접 하드코딩합니다.

Mobile Access 응용의 Single Sign On 페이지 Web Form 섹션에서 Edit 를 클릭합니다.
Credentials Handling 섹션에서 Edit 를 클릭합니다.
Automatically handle the credentials 를 선택합니다.
Sign in Web Form Detection Settings 에서 Mobile Access regards the following URL as the sign in Web form 을 선택합니다 — 실제 로그인 폼 앞에 자격을 요구하는 폼이 있어 Mobile Access가 자동 분석하지 못하면 실제 로그인 폼 URL 을 지정할 수 있습니다.

   구문: <protocol>://<host>/[<path>][?<query>]

Password Validation Settings 에서 Mobile Access sends the following password 를 선택합니다 — 클라이언트는 사용자명·암호로 로그인 폼을 제출해야 하지만, 이후 SSO를 위해 클라이언트에 암호를 저장하는 건 안전하지 않습니다. 그래서 Mobile Access는 더미 암호(dummy password) 를 만들어 클라이언트에 보내고, 로그인 시 진짜 암호로 바꿉니다. 어떤 응용은 클라이언트 측에서 더미 암호를 검사하므로, Mobile Access 더미 암호가 응용과 호환되지 않으면 다른 더미 암호를 정의 할 수 있습니다.

수동 자격 처리(HTTP Post 설정 구성)

자동 Web form SSO가 동작하지 않으면 HTTP POST 상세를 직접 정의합니다.

Credentials Handling 창에서 Manually specify how to handle the credentials 를 선택합니다.
When the following sign in URL is requested 의 필드를 채웁니다.
- post to the following URL — 이 필드와 앞 필드의 URL은 절대 경로 여야 합니다. 형식: <protocol>://<host>/[<path>][?<query>]
- the following POST data — 반드시 다음을 포함해야 합니다.
  - $USERNAME — Mobile Access에 저장된 사용자명으로 풀림.
  - $PASSWORD — Mobile Access에 저장된 암호로 풀림.
  - $DETAILS — Mobile Access에 저장된 Windows 도메인으로 풀림.

Web form SSO에 수동 자격 처리를 구성하면, 자격이 처음 요청될 때 HTTP 인증 요청 창이 나타납니다.

Kerberos 인증 지원

Kerberos 는 사람과 컴퓨터가 비보안 네트워크에서 안전하게 인증 하게 하는 네트워크 프로토콜로, Windows 2000 이상에서 기본 인증 프로토콜입니다.

Kerberos 인증은 웹 애플리케이션(HTTP·HTTPS)에 지원 됩니다. Mobile Access가 사용자를 대신해 Kerberos 서버에 인가받을 수 있습니다.
Microsoft IIS 등 웹 서버는 HTTP 인증 헤더의 Negotiate 방식 으로 Kerberos를 씁니다.
Kerberos는 Security Gateway와 Domain Controller 간 시간 차에 민감 합니다. Mobile Access Security Gateway와 도메인 컨트롤러의 시계를 1분 이내로 동기화 하세요(NTP 시간 서버가 가장 좋습니다).
기본적으로 NTLM 인증이 Kerberos보다 우선 됩니다. Kerberos를 우선하려면 sk106848 을 따르세요.

Mobile Access에서 Kerberos를 쓰려면:

Microsoft Active Directory가 구성되어 있으면, Security Gateway가 AD Account Unit의 관련 설정으로 자동 갱신 되고 Kerberos가 켜집니다. Kerberos 설정은 $CVPNDIR/var/krb5.auto.conf 파일에서 확인할 수 있습니다.

krb5.auto.conf를 바꿔야 하면 템플릿 파일 krb5.auto.conf.template 에서 합니다(템플릿으로 krb5.auto.conf가 만들어집니다).

krb5.auto.conf.template를 편집하려면:

$CVPNDIR/var/krb5.auto.conf.template 파일을 편집해 변경을 추가합니다. 파일에는 Kerberos conf 정보와 Account Unit 설정용 자리표시자(<++PlaceHolderName++> 형식)가 있습니다.

Security Gateway에서 다음을 실행합니다.

     cvpnd_admin policy

템플릿 파일 krb5.auto.conf.template 예시:

  <++libdefaults++>
  rdns = false
  [realms]
  <++realms++>
  [domain_realm]
  <++domain_realm++>

실제 krb5.auto.conf 파일에서의 모습 예시:

  default_realm = EXAMPLE.COM
  rdns = false
  [realms]
  EXAMPLE.COM = {
  kdc = 192.168.1.1
  }
  [domain_realm]

Microsoft Active Directory가 아직 Mobile Access에 구성되지 않았지만 쓰려면 — (1) Mobile Access 마법사로 AD를 구성하고, (2) AD 서버와 SSO에 대한 SmartDashboard Network Objects를 편집합니다.
Microsoft Active Directory를 쓰지 않으려면, SSO용 Kerberos를 수동으로 구성 합니다.

Mobile Access용 Microsoft Active Directory 구성

다음 단계는 Microsoft AD 서버를 Check Point LDAP Account Unit 객체 로 정의했다고 가정합니다. 없으면 만듭니다: Objects > New > More > Server > LDAP Account Unit.

기본 설정대로 구성되었는지 확인하려면:

SmartConsole에서 Objects > Servers > LDAP Account Units 로 갑니다.
LDAP AD 서버를 우클릭하고 Edit 를 선택합니다. LDAP Account Unit Properties 창의 General 탭에서 Profile 값이 Microsoft_AD 입니다.
Domain 값이 AD 도메인에 맞는지 확인합니다.
OK 를 클릭합니다.
SmartConsole 세션을 게시합니다.

Microsoft Active Directory 서버 우선순위를 구성하려면:

Mobile Access가 켜진 Security Gateway 객체를 엽니다(여럿이면 각각 수행).
Other > User Directory 를 엽니다. 기본적으로 Security Gateway는 AD의 모든 도메인 컨트롤러 를 씁니다. 어떤 도메인 컨트롤러로의 연결성이 나쁘면 우선순위를 조정합니다.
Selected Account Units List 가 선택되어 있는지 확인합니다. 선택하면 Selected AUs 목록이 활성화됩니다. 비어 있으면 Add 로 Microsoft_AD용 LDAP Account Unit을 추가합니다.
Microsoft AD 서버를 선택합니다(Servers priorities for selected AU가 활성화됨).
Use default priorities 를 해제합니다.
AD 서버의 호스트를 선택합니다(Priority 필드가 활성화됨).
연결성 문제가 있는 호스트의 우선순위를 다른 호스트보다 낮게 설정합니다(예: Priority 1이 가장 높고 Priority 5가 낮음).
Set 를 클릭합니다.
OK 를 클릭합니다.

Kerberos 수동 구성

Microsoft AD가 아닌 디렉터리를 쓰거나 자동 구성에 문제가 있으면 Kerberos 인증을 수동 구성합니다.

$CVPNDIR/var/krb5.manual.conf 파일을 만듭니다.
도메인 주소·도메인 컨트롤러 값을 다음 형식으로 채웁니다.

   default_realm = YOUR.AD.NAME
   [realms]
   YOUR.AD.NAME = {
   admin_server = your.domain.controller.name
   default_domain = your.dns.domain
   }
   [domain_realm]
   .your.dns.domain = YOUR.AD.NAME
   your.dns.domain = YOUR.AD.NAME

파일에서: - YOUR.AD.NAME — Windows 도메인 이름. - Windows 도메인(realm)을 둘 이상 구성하려면 [realms]·[domain_realm] 섹션에 도메인을 더 추가합니다. - 각 realm에 도메인 컨트롤러가 둘 이상이면 admin_server 대신 다음 유형의 여러 문을 씁니다.

     <DOMAIN_NAME> = {
     kdc = <1st domain controller address>
     kdc = <2nd domain controller address>
     }

추가하려면 다음 cvpnd_settings 명령을 씁니다.

   cvpnd_settings $CVPNDIR/conf/cvpnd.C listAdd kerberosRealms YOUR.AD.NAME
   cvpnd_settings $CVPNDIR/conf/cvpnd.C listAdd kerberosRealms YOUR.OTHER.AD.NAME

수동 구성을 테스트합니다.
1. 셸의 KRB5_CONFIG 환경 변수를 해당 구성 파일을 가리키게 설정합니다.
  - Expert mode(Bash 셸):

        export KRB5_CONFIG=$CVPNDIR/var/krb5.manual.conf

Tcsh·Csh 셸:

        setenv KRB5_CONFIG $CVPNDIR/var/krb5.manual.conf

Mobile Access Security Gateway 명령줄에서 Expert mode(Tcsh·Csh)로 실행합니다.

      kinit your-ad-username

realm이 여럿이면 이 kinit 구문은 기본 realm 에 적용됩니다.
- 다른 realm은 다음 구문을 씁니다.

        kinit your-ad-username@YOUR.OTHER.AD.NAME

다음과 비슷한 프롬프트가 나옵니다.

      Password for your-ad-username@YOUR.DOMAIN:

암호를 입력합니다.
1. 다음을 실행합니다.

Ticket cache 목록에 티켓이 하나 보입니다. 5. 다음으로 목록을 삭제합니다.

(이어서) $CVPNDIR/conf/cvpnd.C를 편집용으로 엽니다.
kerberosConfigMode 속성 값을 auto에서 manual로 바꿉니다. 또는:

   cvpnd_settings $CVPNDIR/conf/cvpnd.C set kerberosConfigMode manual

다음을 실행합니다.

Kerberos Constrained Delegation

Kerberos constrained delegation 은 Kerberos 인증으로 사용자가 암호 입력 없이 내부 리소스에 접근 하게 하는 SSO 방식입니다. Mobile Access 포털과 Capsule Workspace 에 지원됩니다.

Kerberos constrained delegation을 켜려면:

Mobile Access Security Gateway에서 실행합니다.

   cvpnd_settings $CVPNDIR/conf/cvpnd_internal_settings.C set EnableKCD true

실행합니다.

클러스터 환경에서는 모든 클러스터 멤버 에서 반복합니다.

Kerberos Constrained Delegation 구성

시작 전 다음을 확인합니다.

사이트가 Kerberos 인증을 지원 할 것.
Mobile Access Security Gateway가 Kerberos를 지원하도록 구성 되어 있을 것.
Security Gateway와 AD 서버의 날짜·시간이 같을 것.
내부 서버 이름에 IP가 아닌 FQDN 을 쓰고, 그 FQDN이 Security Gateway와 Kerberos 서버 양쪽에서 풀릴 것.

구성은 AD 서버에 Delegate User 구성 과 Mobile Access Security Gateway에 KCD 지원 구성 으로 이뤄집니다.

AD 서버에 Delegate User 구성

Delegate user는 상위 권한 그룹에 속하지 않고도 지정 권한 을 가질 수 있습니다. KCD에서 delegate user는 지정 서비스에 대해 다른 사용자에게 접근을 허용할 수 있습니다.

AD 서버에 새 사용자를 추가합니다.
AD 서버에서 명령 프롬프트를 열어 실행합니다.

   setspn -A HTTP/<user name> <domain name>\<user name>

<user name> — 만든 사용자의 사용자명.
- <domain name> — 그 사용자가 속한 도메인 이름.
Users and Computers 트리에서 그 사용자를 우클릭해 User Properties를 엽니다.
Delegation 탭을 클릭합니다.
Trust this user for delegation to specified services only 를 선택합니다.
Use any authentication protocol 을 선택합니다.
Services to which this account can present delegated credentials 표에서 Add 를 클릭해 사용자가 접근할 수 있는 서버의 http를 추가합니다.
OK 를 클릭합니다.

Kerberos Constrained Delegation 지원 구성

KCD는 웹 애플리케이션과 Mobile Mail 응용 에 지원됩니다.

SmartConsole에서 Objects > Object Explorer(Ctrl+E)를 클릭합니다.
Mobile Access 응용을 검색합니다.
KCD를 구성할 응용을 더블 클릭합니다(Web Application 창이 열립니다).
탐색 트리에서 Additional Settings > Single Sign On 을 클릭합니다.
다음을 구성합니다.
- Turn on Single Sign On for this application 을 선택합니다.
- Advanced 를 선택합니다.
Edit 를 클릭합니다.
Advanced 창에서 This application reuses the portal credentials. Users are not prompted. 를 선택합니다.
OK 를 클릭하고 Web Application 창을 닫습니다.
정책을 설치합니다.

KCD 문제 해결:

Mobile Access Security Gateway 명령줄에 연결합니다.
$CVPNDIR/conf/cvpnd_internal_settings.C의 EnableKCD 값이 true인지 확인합니다.
cvpnrestart 명령을 실행합니다.
SmartLog의 Mobile Access 로그에 KCD 실패 항목이 있는지 봅니다.
account unit 자격에 delegate 권한이 있는지 확인합니다.
Security Gateway와 AD 서버의 날짜·시간이 동기화되었는지 확인합니다.
DNS 서버가 올바로 구성되어 Security Gateway가 웹 애플리케이션 호스트명·AD 서버를 풀 수 있는지 확인합니다.

Certificate Attribute Forwarding

Certificate attribute forwarding 은 사용자 인증서의 정보를 사용자명·암호 없이 내부 서버로 전달 하는 SSO 방식입니다. 사용자가 인증서로 로그인하면 인증서 속성을 HTTP 헤더로 내부 서버에 전달 하고, 사용자는 이후 다른 응용에 SSO로 자동 로그인할 수 있습니다.

Certificate attribute forwarding은 Mobile Access 구성 파일 $CVPNDIR/conf/cvpnd.C에 구성합니다.

활성/비활성:

활성:  :EnableCertHeadersForwarding (true)
비활성: :EnableCertHeadersForwarding (false)

전달할 인증서 속성을 구성하려면 $CVPNDIR/conf/cvpnd.C의 CertHeaders 섹션에 파라미터를 추가합니다.

전달 대상	파라미터=값 형식
Base64로 인코딩된 전체 인증서	`"<header_name>: <Certificate in Base64>"`
Certificate Issuer DN(발급자 DN)	`"<header_name> : <DN of Certificate Issuer>"`
인증서 일련번호	`"<header_name> : <Certificate Serial>"`
Subject DN(주체 DN)	`"<header_name> : <DN of Certificate Subject>"`
Alternative subject DN(대체 주체 DN)	`"<header_name> : <DN of Certificate Alternative Subject>"`
유효 시작일(이전엔 사용 불가)	`"<header_name> : <Certificate Validity Start Date>"`
인증서 만료일	`"<header_name> : <Certificate Validity End Date>"`

예시 — 인증서 Issuer DN을 전달하려면(헤더 이름이 X-Cert-IssuerDN):

:EnableCertHeadersForwarding (true)
:CertHeaders (
: ("X-Cert-IssuerDN : <DN of the Certificate Issuer>"
)

현재 로그인 사용자 이름 사용하기($$user)

Mobile Access 응용은 현재 로그인한 사용자 이름에 따라 다르게 동작 하도록 구성할 수 있습니다 — 포털 링크에 사용자 이름을 넣거나, 파일 공유가 사용자 홈 디렉터리를 가리키게 할 수 있습니다. 이를 위해 $$user 지시어를 쓰며, Mobile Access 세션 동안 현재 로그인 사용자의 로그인 이름으로 풀립니다.

이런 개인화 구성을 하려면 웹 애플리케이션·파일 공유·native application 정의의 해당 위치에 $$user를 넣습니다. 예를 들어 http://host/$$user로 정의한 웹 애플리케이션 URL은 사용자 aa에게 http://host/aa, bb에게 http://host/bb로 나타납니다. 사용자가 인증서로 인증하면 $$user는 로그인 과정에서 인증서에서 추출되어 디렉터리 서버가 인가한 사용자 이름 으로 풀립니다.