사용자 관리

이 섹션에서는 로컬 및 원격으로 인증된 사용자를 위한 Dell SonicWALL 네트워크 보안 어플라이언스의 사용자 관리 기능을 설명합니다. 이 섹션에 포함된 하위 섹션은 다음과 같습니다.

• 사용자 관리 소개

• 사용자 > 상태에서 상태 확인

• 사용자 > 설정에서 설정 구성

• 로컬 사용자 구성

• 로컬 그룹 구성

• RADIUS 인증 구성

• SonicOS에서 LDAP 통합 구성

• Single Sign On 구성

• 여러 관리자 지원 구성

사용자 관리 소개

자세한 내용은 다음 섹션을 참조하십시오.

• 인증 시 로컬 사용자 및 그룹 사용

• 인증 시 RADIUS 사용

• LDAP/Active Directory/eDirectory 인증 사용

• Single Sign On 개요

• 여러 관리자 지원 개요

Dell SonicWALL 네트워크 보안 어플라이언스는 사용자가 인터넷의 원격 위치에서 LAN에 액세스할 수 있도록 하는 사용자 수준 인증용 메커니즘과, 인터넷에 액세스하려는 LAN 사용자에게 콘텐츠 필터링 정책을 강제 적용하거나 바이패스하는 방법을 제공합니다. 인증된 사용만 VPN 터널에 액세스하여 암호화된 연결을 통해 데이터를 보내도록 허용할 수도 있습니다. 방화벽은 WAN, VPN, WLAN 등의 여러 영역에서 사용자가 네트워크 리소스에 액세스하려고 시도하는 즉시 모든 사용자를 인증합니다. 그러면 네트워크 트래픽이 방화벽을 통과합니다. LAN에서 컴퓨터에 로그인하지만 로컬 작업만 수행하는 사용자는 방화벽을 통해 인증되지 않습니다. 로컬 사용자 데이터베이스, LDAP, RADIUS를 사용하거나 로컬 데이터베이스와 LDAP 또는 RADIUS를 조합하여 사용자 수준 인증을 수행할 수 있습니다. SonicOS에서는 SSO(Single Sign On) 기능도 제공합니다. SSO는 LDAP와 함께 사용할 수 있습니다. 방화벽의 로컬 데이터베이스는 사용자를 1,000명까지 지원할 수 있습니다. 사용자 수가 1,000명이 넘으면 인증 시 LDAP 또는 RADIUS를 사용해야 합니다.

인증 시 로컬 사용자 및 그룹 사용

Dell SonicWALL 네트워크 보안 어플라이언스는 사용자 및 그룹 정보를 저장하기 위한 로컬 데이터베이스를 제공합니다. 이 로컬 데이터베이스를 이용하여 사용자를 인증하고 사용자의 네트워크 액세스를 제어하도록 방화벽을 구성할 수 있습니다. 네트워크에 액세스하는 사용자의 수가 비교적 적을 때는 이러한 용도로 LDAP 또는 RADIUS보다 로컬 데이터베이스를 선택하는 것이 좋습니다. 여러 사용자와 그룹의 항목을 만들면 시간이 많이 걸리지만 일단 만든 항목은 유지 관리하기가 어렵지 않습니다. 사용자 수가 많은 네트워크의 경우 LDAP 또는 RADIUS 서버를 통해 사용자를 인증하는 것이 더욱 효율적일 수 있습니다.

사용자에게 CFS(콘텐츠 필터링 서비스) 정책을 적용하려면 해당 사용자가 로컬 그룹 구성원이어야 합니다. 그러면 CFS 정책을 그룹에 적용할 수 있습니다. CFS를 사용하려는 경우, 로컬 인증과 CFS를 조합하여 사용해야 LDAP 또는 RADIUS를 사용할 수 없습니다. CFS 정책을 사용하기 위해 조합된 인증 방법을 사용할 때는 로컬 그룹 이름이 LDAP 또는 RADIUS 그룹 이름과 정확하게 일치해야 합니다. LDAP + 로컬 사용자 인증 방법을 사용할 때는 LDAP 서버에서 방화벽의 로컬 데이터베이스로 그룹을 가져올 수 있습니다. 그러면 일치하는 그룹을 매우 간편하게 만들 수 있으며 해당 그룹에 CFS 정책을 적용할 수 있습니다.

SonicOS 사용자 인터페이스에서 로컬 사용자과 그룹 계정을 만들 수 있습니다. 사용자를 추가하고, 다음에 대한 설정을 비롯하여 모든 사용자의 구성을 편집할 수 있습니다.

• 그룹 구성원 자격 - 사용자는 하나 이상의 로컬 그룹에 속할 수 있습니다. 기본적으로 모든 사용자는 모두 및 신뢰할 수 있는 사용자 그룹에 속합니다. 이러한 사용자 그룹의 구성원 자격을 제거하고 다른 그룹의 구성원 자격을 추가할 수 있습니다.

• VPN 액세스 - 이 사용자가 시작한 VPN 클라이언트에 액세스 가능한 네트워크를 구성할 수 있습니다. VPN 액세스 설정을 구성할 때는 네트워크 목록에서 네트워크를 선택할 수 있습니다. 네트워크에는 주소 그룹 또는 주소 개체 이름이 지정됩니다.

참고 사용자 또는 그룹에 대한 VPN 액세스 구성은 GVC, NetExtender 및 SSL VPN Virtual Office 책갈피를 사용하여 네트워크 리소스에 액세스하는 원격 클라이언트 기능에 영향을 줍니다. GVC, NetExtender 또는 Virtual Office 사용자가 네트워크 리소스에 액세스하도록 허용하려면 네트워크 주소 개체 또는 그룹을 VPN 액세스 탭의 "허용" 목록에 추가해야 합니다.

로컬 그룹을 추가하거나 편집할 수도 있습니다. 그룹에 구성할 수 있는 설정은 다음과 같습니다.

• 그룹 설정 - 관리자 그룹의 경우 로그인 상태 팝업 창을 활성화하지 않고도 관리 인터페이스에 로그인할 수 있도록 SonicOS를 구성할 수 있습니다.

• 그룹 구성원 - 그룹은 구성원(로컬 사용자 또는 다른 로컬 그룹)을 포함할 수 있습니다.

• VPN 액세스 - 그룹에 대한 VPN 액세스는 사용자에 대한 VPN 액세스와 같은 방식으로 구성됩니다. 이 그룹의 구성원이 시작한 VPN 클라이언트에 액세스 가능한 네트워크를 구성할 수 있습니다. VPN 액세스 설정을 구성할 때는 네트워크 목록에서 네트워크를 선택할 수 있습니다. 네트워크에는 주소 그룹 또는 주소 개체 이름이 지정됩니다.

• CFS 정책 - 그룹 구성원에게 콘텐츠 필터링(CFS) 정책을 적용할 수 있습니다. 현재 고급 콘텐츠 필터링 서비스에 대한 방화벽 라이선스가 있어야만 CFS 정책 설정을 사용할 수 있습니다.

인증 시 RADIUS 사용

RADIUS(Remote Authentication Dial In User Service)는 Dell SonicWALL 네트워크 보안 어플라이언스에서 네트워크에 액세스하려는 사용자를 인증하는 데 사용하는 프로토콜입니다. RADIUS 서버는 사용자 정보가 들어 있는 데이터베이스를 포함하며 PAP(암호 인증 프로토콜), CHAP(Challenge Handshake 인증 프로토콜), MSCHAP(Microsoft CHAP) 또는 MSCHAPv2 같은 인증 체계를 통해 사용자 자격 증명을 확인합니다.

주로 보안 인증을 제공하는 RADIUS는 LDAP와 크게 다르지만 각 항목에 다양한 특성을 제공할 수도 있습니다. 여기에는 사용자 그룹 구성원 자격을 다시 전달하는 데 사용할 수 있는 여러 가지 특성이 포함됩니다. 수천 명의 사용자 정보를 저장할 수 있는 RADIUS는 많은 사용자가 네트워크에 액세스해야 할 때 사용자 인증에 이용하면 좋습니다.

LDAP/Active Directory/eDirectory 인증 사용

LDAP(Lightweight Directory Access Protocol)는 사용자 계정, 사용자 그룹, 호스트, 서버 등 네트워크 요소 관련 정보를 저장 및 관리하기 위한 디렉터리 서비스 구조를 정의합니다. 다양한 표준에서 LDAP를 통해 사용자 계정과 그룹, 권한을 관리합니다. 그중에는 LDAP를 사용하여 관리할 수 있는 Microsoft Active Directory 같은 전용 시스템도 있고, LDAP 표준의 구현인 개방형 표준 삼바도 있습니다. 또한 사용자 리포지토리 정보를 관리하기 위한 LDAP API를 제공하는 Novell eDirectory 같은 전용 시스템도 있습니다.

SonicOS에서는 RADIUS 및 로컬 사용자 데이터베이스 외에 LDAP도 사용자 인증용으로 지원하며 다양한 스키마도 함께 지원합니다. 여기에는 Microsoft AD(Active Directory), Novell eDirectory 디렉터리 서비스, 그리고 LDAP가 모든 스키마와 상호 작용할 수 있도록 하는 완전히 구성 가능한 사용자 정의 옵션이 포함됩니다.

Microsoft Active Directory는 Dell SonicWALL Single Sing On 및 Dell SonicWALL SSO 에이전트와도 함께 사용할 수 있습니다. 자세한 내용은 Single Sign On 개요를 참조하십시오.

SonicOS에서 지원되는 LDAP 디렉터리 서비스

회사 네트워크에서 가장 일반으로 사용되는 디렉터리 서비스와 통합할 수 있도록 SonicOS에서는 다음 LDAP 스키마와의 통합 기능을 지원합니다.

• Microsoft Active Directory

• RFC2798 InetOrgPerson

• RFC2307 NIS(네트워크 정보 서비스)

• 삼바 SMB

• Novell eDirectory

• 사용자 정의 스키마

SonicOS는 다음 프로토콜을 실행하는 디렉터리 서버를 지원합니다.

• LDAPv2(RFC3494)

• LDAPv3(RFC2251-2256, RFC3377)

• LDAPv3 over TLS(RFC2830)

• LDAPv3 with STARTTLS(RFC2830)

• LDAP 추천(RFC2251)

LDAP 용어

다음 용어의 의미를 숙지하면 LDAP 및 해당 변형을 사용하여 작업할 때 유용합니다.

• 스키마 – 스키마는 디렉터리에 저장할 수 있는 데이터 유형과 해당 데이터를 저장하는 방법을 정의하는 규칙 또는 구조 집합입니다. 데이터는 '항목' 형식으로 저장됩니다.

• AD(Active Directory) - 일반적으로 Windows 기반 네트워크와 함께 사용되는 Microsoft 디렉터리 서비스입니다. Microsoft Active Directory는 LDAP와 호환됩니다.

• eDirectory – Novell NetWare 기반 네트워크에 사용되는 Novell 디렉터리 서비스입니다. Novell eDirectory에는 관리 시 사용할 수 있는 LDAP 게이트웨이가 있습니다.

• 항목 – LDAP 디렉터리에 저장되는 데이터입니다. 항목은 '특성'/값 또는 이름/값 쌍으로 저장됩니다. 여기서 특성은 '개체 클래스'로 정의됩니다. 샘플 항목으로는 'cn=john' 등이 있습니다. 여기에서는 'cn'(일반 이름)이 특성이고 'john'이 값입니다.

• 개체 클래스 – 개체 클래스는 LDAP 디렉터리에 포함될 수 있는 항목 유형을 정의합니다. AD에서 사용되는 샘플 개체 클래스로는 'user' 또는 'group' 등이 있습니다.

http://msdn.microsoft.com/library/에서 Microsoft Active Directory의 클래스를 찾아볼 수 있습니다.

• 개체 - LDAP 용어에서는 디렉터리 항목을 개체로 총칭합니다. LDAP 클라이언트의 SonicOS를 구현할 때 주요 개체는 'User' 및 'Group' 개체입니다. 다른 LDAP 구현에서는 이러한 개체 클래스를 다른 방식으로 지칭할 수 있습니다. 예를 들어 Active Directory에서는 사용자 개체를 '사용자'로, 그룹 개체를 '그룹'으로 지칭하며 RFC2798에서는 사용자 개체를 'inetOrgPerson'으로, 그룹 개체를 'groupOfNames'로 지칭합니다.

• 특성 - LDAP 디렉터리의 개체에 저장되는 데이터 항목입니다. 개체는 필수 특성 또는 허용 특성을 포함할 수 있습니다. 예를 들어 'dc' 특성은 'dcObject'(도메인 구성 요소) 개체의 필수 특성입니다.

• dn - 사용자 또는 기타 개체의 전역적으로 고유한 이름(고유 이름)입니다. dn은 여러 구성 요소로 이루어지는데, 보통 일반 이름(cn) 구성 요소로 시작하고 둘 이상의 도메인 구성 요소(dc)로 지정된 도메인으로 끝납니다. 예로 'cn=john,cn=users,dc=domain,dc=com' 등을 들 수 있습니다.

• cn – '일반 이름' 특성으로, LDAP 전체에서 여러 개체 클래스의 필수 구성 요소입니다.

• ou – '조직 구성 단위' 특성으로, 대다수 LDAP 스키마 구현의 필수 구성 요소입니다.

• dc – '도메인 구성 요소' 특성으로, 보통 고유 이름의 루트에 있으며 대개 필수 특성입니다.

• TLS – Transport Layer Security의 약어로, SSL(Secure Sockets Layer)의 IETF 표준화 버전입니다. TLS 1.0이 SSL 3.0의 후속 버전입니다.

Single Sign On 개요

이 섹션에서는 SonicOS Single Sign On 기능을 소개합니다. 이 섹션에 포함된 하위 섹션은 다음과 같습니다.

• Single Sign On이란?

• SonicWALL SSO의 이점

• 플랫폼 및 지원되는 표준

• Single Sign On의 작동 방식

• SSO 에이전트의 작동 방식

• 터미널 서비스 에이전트의 작동 방식

• 브라우저 NTLM 인증의 작동 방식

• Single-Sign-On의 RADIUS 계정 작동 방식

Single Sign On이란?

SSO(Single Sign On)는 Windows 터미널 서비스나 Citrix 서버를 통해, 또는 워크스테이션에서 도메인에 한 번 로그인하면 여러 네트워크 리소스에 대한 액세스 권한을 제공하는 투명한 사용자 인증 메커니즘입니다.

Dell SonicWALL 네트워크 보안 어플라이언스는 SSO(Single Sign On) 에이전트 및 SonicWALL TSA(터미널 서비스 에이전트)를 통해 사용자 활동을 식별하여 SSO 기능을 제공합니다. SSO(Single Sign On) 에이전트는 워크스테이션 IP 주소를 기준으로 사용자를 식별합니다. TSA는 서버 IP 주소, 사용자 이름 및 도메인을 조합하여 사용자를 식별합니다.

Mac 및 Linux 사용자도 삼바와 함께 사용하는 경우 SonicWALL SSO를 사용할 수 있습니다. 또한 브라우저 NTLM 인증을 사용하면 SonicWALL SSO가 SSO 에이전트 또는 삼바 없이도 HTTP 트래픽을 보내는 사용자를 인증할 수 있습니다.

SonicOS 관리 인터페이스의 사용자 > 설정 페이지에서 SonicWALL SSO를 구성합니다. SSO는 로그인 시 인증 방법 설정과는 다르며 VPN/L2TP 클라이언트 사용자 또는 관리 사용자 인증과 동시에 사용할 수 있습니다.

방화벽은 SonicWALL SSO 에이전트 또는 TSA의 데이터를 기준으로 LDAP 또는 로컬 데이터베이스를 쿼리하여 그룹 구성원 자격을 확인합니다. 필요에 따라 방화벽 정책이 그룹 구성원 자격을 확인하여 액세스 권한이 제공되는 사용자를 제어할 수 있습니다. 또한 그룹 구성원 자격을 사용하면 콘텐츠 필터링 및 응용 프로그램 컨트롤용 정책을 선택하여 사용자가 액세스할 수 있는 항목을 제어할 수 있습니다. SSO를 통해 인식된 사용자 이름은 사용자의 트래픽 및 이벤트 로그와 AppFlow 모니터링에서 보고됩니다.

구성된 비활성 타이머는 SSO와 함께 적용되지만 세션 제한은 적용되지 않습니다. 그러나 로그아웃된 사용자는 트래픽을 추가로 전송할 때 자동으로 투명하게 다시 로그인됩니다.

도메인에 로그인하지 않고 워크스테이션 또는 터미널 서비스/Citrix 서버에 직접 로그인하는 사용자의 경우, 브라우저 NTLM 인증이 사용하도록 설정된 상태에서 HTTP 트래픽을 보내야 인증됩니다. 그러나 필요에 따라서는 인증하여 제한된 액세스 권한을 받을 수 있습니다. SonicWALL SSO에서 인증되지 않은 사용자가 추가 인증받으려면 어플라이언스에 수동으로 로그인해야 한다는 메시지가 포함된 화면이 표시됩니다.

식별은 되었지만 구성된 정책 구성에서 요구하는 그룹 구성원 자격이 없는 사용자는 액세스 차단됨 페이지로 리디렉션됩니다.

SonicWALL SSO의 이점

SonicWALL SSO는 안정적이고 시간을 절약해 주는 기능으로, 관리자가 구성한 그룹 구성원 자격 및 정책 일치를 기준으로 단일 로그인을 통해 여러 네트워크 리소스에 대한 액세스 권한을 제공합니다. SonicWALL SSO는 최종 사용자에 대해 투명하며 관리자는 최소한의 구성만 진행하면 됩니다.

SonicWALL SSO는 워크스테이션 IP 주소 트래픽 또는 서버 IP 주소에 있는 특정 사용자의 트래픽
(터미널 서비스나 Citrix의 경우)을 기준으로 사용자의 로그인/로그아웃을 자동으로 확인하므로 안전하고 편리합니다. SSO 인증은 SonicWALL Directory Connector 호환 프로토콜을 사용하여 워크스테이션 또는 터미널 서비스/Citrix 서버 IP 주소에서 사용자 ID를 반환할 수 있는 모든 외부 에이전트에서 작동합니다.

SonicWALL SSO는 사용자 수준 인증을 사용하는 방화벽의 모든 서비스에 대해 작동합니다. 여기에는 CFS(콘텐츠 필터링 서비스), 방화벽 액세스 정책, 그룹 구성원 자격/상속, 보안 서비스(IPS, GAV 및 안티스파이웨어) 포함/제외 목록 등이 포함됩니다.

그 외 SonicWALL SSO의 이점은 다음과 같습니다.

• 사용 용이성 - 사용자는 한 번만 로그인하면 여러 리소스에 대한 액세스 권한을 자동으로 받을 수 있습니다.

• 사용자 환경 개선 - 웹 브라우저를 통해 어플라이언스에 로그인하지 않고도 Windows 도메인 자격 증명을 사용하여 모든 트래픽 유형에 대해 사용자를 인증할 수 있습니다.

• 사용자 투명성 - 사용자가 인증 시 사용자 이름과 암호를 다시 입력하지 않아도 됩니다.

• 통신 보안 - 데이터 전송을 보호하기 위해 공유 키 암호화를 사용합니다.

• SonicWALL SSO 에이전트는 LAN의 모든 Windows 서버에 설치할 수 있으며 TSA는 모든 터미널 서버에 설치할 수 있습니다.

• 여러 SSO 에이전트 사용 - 대규모 설치에 필요한 용량을 제공하기 위해 에이전트가 8개까지 지원됩니다.

• 여러 TSA 사용 - 여러 터미널 서비스 에이전트(터미널 서버당 하나)가 지원됩니다. TSA의 수(8~512개)는 Dell SonicWALL 네트워크 보안 어플라이언스의 모델별로 다릅니다.

• 로그인 메커니즘은 HTTP뿐만 아니라 모든 프로토콜에서 작동합니다.

• 브라우저 NTLM 인증 - SonicWALL SSO는 SSO 에이전트를 사용하지 않고도 HTTP 트래픽을 보내는 사용자를 인증할 수 있습니다.

• Mac 및 Linux 지원 - 삼바 3.5 이상을 사용하는 경우 Mac 및 Linux 사용자에게도 SonicWALL SSO가 지원됩니다.

• 영역별 규약 - SonicWALL SSO는 방화벽 액세스 규칙 또는 보안 서비스 정책에 따라 자동으로 시작되지 않는 경우에도 모든 영역의 트래픽에 대해 트리거할 수 있으므로 이벤트 로깅 또는 AppFlow 모니터링에서 사용자를 식별할 수 있습니다.

플랫폼 및 지원되는 표준

SSO 에이전트는 SonicWALL SSO를 지원하는 모든 SonicOS 버전과 호환됩니다. TSA도 지원됩니다.

SSO 기능은 LDAP 및 로컬 데이터베이스 프로토콜을 지원합니다. SonicWALL SSO는 SonicWALL Directory Connector를 지원합니다. SonicWALL SSO의 모든 기능이 올바르게 작동하려면 Directory Connector 3.1.7 이상과 함께 SonicOS를 사용해야 합니다.

Windows 터미널 서비스 또는 Citrix와 함께 SonicWALL SSO를 사용하려면 SonicOS 6.0 이상이 필요하며, SonicWALL TSA를 서버에 설치해야 합니다.

브라우저 NTLM 인증과 함께 SonicWALL SSO를 사용하려면 SonicOS 6.0 이상이 필요합니다. SSO 에이전트는 브라우저 NTLM 인증에 필요하지 않습니다.

브라우저 NTLM 인증만 사용하는 경우를 제외하고 SonicWALL SSO를 사용하려면, Windows 도메인 내의 서버(클라이언트에 연결할 수 있고 어플라이언스에서 연결할 수 있어야 함)에 SSO 에이전트를 직접 또는 VPN 경로를 통해 설치하거나 도메인의 터미널 서버에 TSA를 설치해야 합니다.

SSO 에이전트를 실행하려면 다음 요구 사항을 충족해야 합니다.

• UDP 포트 2258(기본값)이 열려 있어야 합니다. 방화벽은 기본적으로 UDP 포트 2258을 사용하여 SonicWALL SSO 에이전트와 통신합니다. 2258 대신 사용자 지정 포트가 구성되어 있으면 이 요구 사항이 해당 사용자 지정 포트에 적용됩니다.

• 최신 서비스 팩이 적용된 Windows Server

• .NET Framework 2.0

• Net API 또는 WMI

참고 Mac 및 Linux PC는 SSO에서 사용하는 Windows 네트워크 요청을 지원하지 않으므로 SonicWALL SSO를 사용하려면 삼바 3.5 이상이 필요합니다. 삼바 없이도 Mac/Linux 사용자가 액세스 권한을 얻을 수는 있지만, 그러려면 먼저 로그인해야 합니다. 인증을 요구하도록 정책 규칙이 설정되어 있으면 Mac/Linux 사용자는 로그인 프롬프트로 리디렉션됩니다. 자세한 내용은 Mac 및 Linux 사용자 지원을 참조하십시오.

TSA를 실행하려면 다음 요구 사항을 충족해야 합니다.

• TSA가 설치된 모든 터미널 서버에서 UDP 포트 2259(기본값)가 열려 있어야 합니다. 방화벽은 기본적으로 UDP 포트 2259를 사용하여 SonicWALL TSA와 통신합니다. 2259 대신 사용자 지정 포트가 구성되어 있으면 이 요구 사항이 해당 사용자 지정 포트에 적용됩니다.

• 최신 서비스 팩이 적용된 Windows Server

• Windows 터미널 서버 시스템에 설치된 Windows 터미널 서비스 또는 Citrix

Single Sign On의 작동 방식

SonicWALL SSO는 사용자에 대해 투명하며 관리자는 최소한의 구성만 수행하면 됩니다.

SSO는 다음 상황에서 트리거됩니다.

• 사용자 인증을 요구하는 방화벽 액세스 규칙이 WAN 영역에서 수신되지 않는 트래픽에 적용되는 경우

• 액세스 규칙에 사용자 그룹이 지정되어 있지 않은데 다음 조건이 적용되는 경우(해당 조건이 적용되는 트래픽뿐만 아니라 영역의 모든 트래픽에 대해 SSO가 트리거됨)

– 영역에서 CFS가 사용하도록 설정되어 있고 여러 CFS 정책이 설정되어 있는 경우

– 영역에서 IPS가 사용하도록 설정되어 있고 인증을 요구하는 IPS 정책이 있는 경우

– 영역에서 안티스파이웨어가 사용하도록 설정되어 있고 인증을 요구하는 안티스파이웨어 정책이 있는 경우

– 인증을 요구하는 응용 프로그램 컨트롤 정책이 소스 영역에 적용되는 경우

– SSO의 영역별 규약이 영역에 대해 설정되어 있는 경우

콘텐츠 필터링, 침입 방지, 안티스파이웨어 및 응용 프로그램 컨트롤 같은 보안 서비스에 필요한 사용자 및 그룹 식별에는 SSO 사용자 테이블도 사용됩니다.

SSO 에이전트를 사용한 SonicWALL SSO 인증

SSO 워크스테이션의 SSO 에이전트는 개별 Windows 워크스테이션의 사용자에 대해 방화벽에서 요청한 인증을 처리합니다. 다음 그림에 나와 있는 것처럼 SSO 에이전트를 사용한 SonicWALL SSO 인증에서는 6단계의 작업을 수행합니다.

사용자 트래픽이 방화벽을 통과하면 SSO 인증 프로세스가 시작됩니다. 사용자가 인터넷에 액세스하는 경우를 예로 들 수 있습니다. 전송된 패킷은 방화벽이 SSO 에이전트를 실행 중인 인증 에이전트(SSO 워크스테이션)에 "사용자 이름" 요청과 워크스테이션 IP 주소를 보내는 동안 일시적으로 차단 및 저장됩니다.

SSO 에이전트를 실행 중인 인증 에이전트는 현재 워크스테이션에 로그인되어 있는 사용자 이름을 방화벽에 제공합니다. RADIUS 및 LDAP와 마찬가지로 로그인되어 있는 사용자에 대해 사용자 IP 테이블 항목이 만들어집니다.

터미널 서비스 에이전트를 사용한 SonicWALL SSO 인증

터미널 서비스 또는 Citrix 서버에서 로그인하는 사용자의 경우 TSA가 SSO 에이전트 대신 인증 프로세스를 수행합니다. 두 프로세스는 몇 가지 방식에서 차이가 있습니다.

• TSA는 사용자가 로그인하는 서버에서 실행되며, 방화벽에 대한 초기 알림에 사용자 이름 및 도메인과 서버 IP 주소를 포함합니다.

• 사용자는 사용자 번호와 IP 주소로 식별됩니다. 터미널 서비스를 이용하지 않는 사용자는 IP 주소당 사용자가 한 명뿐이므로 사용자 번호가 사용되지 않습니다. SonicOS 관리 인터페이스에 "x.x.x.x 사용자 n" 형식으로 0이 아닌 사용자 번호가 표시됩니다. 여기서 x.x.x.x는 서버 IP 주소이고, n은 사용자 번호입니다.

• TSA는 사용자가 로그아웃하면 닫기 알림을 SonicOS에 보내기 때문에 폴링은 수행되지 않습니다.

사용자가 식별되면 방화벽이 관리자 구성에 따라 LDAP 또는 로컬 데이터베이스를 쿼리하여 사용자 그룹 구성원 자격을 찾고, 해당 구성원 자격이 정책과 일치하는지 확인합니다. 그런 다음 이에 따라 사용자에게 액세스 권한을 부여하거나 제한합니다. 로그인 시퀀스가 정상적으로 완료되면 저장된 패킷이 전송됩니다. 시퀀스가 완료되기 전에 같은 원본 주소에서 패킷이 수신되면 최신 패킷만 저장됩니다.

사용자 이름은 SSO 에이전트를 실행 중인 인증 에이전트에서 <도메인>/<사용자 이름> 형식으로 반환됩니다. 로컬로 구성된 사용자 그룹의 경우, SSO 에이전트를 실행 중인 인증 에이전트에서 반환되는 전체 이름(방화벽 로컬 사용자 데이터베이스의 이름이 일치하도록 구성) 또는 도메인 구성 요소가 스트립된 간단한 사용자 이름(기본값)으로 사용자 이름을 구성할 수 있습니다.

LDAP 프로토콜의 경우, 도메인 이름과 일치하는 "dc"(도메인 구성 요소) 특성을 사용해 "domain" 클래스 개체에 대한 LDAP 검색을 만들어서 <도메인>/<사용자 이름> 형식을 LDAP 고유 이름으로 변환합니다. 해당 개체가 발견되면 개체의 고유 이름을 디렉터리 하위 트리로 사용하여 사용자 개체를 검색합니다. 예를 들어 사용자 이름이 "SV/bob"으로 반환되면 "objectClass=domain" 및 "dc=SV"인 개체를 검색합니다. 검색 결과 고유 이름이 "dc=sv,dc=us,dc=sonicwall,dc=com"인 개체가 반환되면 "objectClass=user" 및 "sAMAccountName=bob"인 개체에 대해 해당 디렉터리 하위 트리의 검색이 만들어집니다(Active Directory의 경우). 도메인 개체가 발견되지 않으면 디렉터리 트리 맨 위부터 사용자 개체를 검색합니다.

도메인 개체가 발견되면 정보가 저장되어 같은 개체를 다시 검색하지 않아도 됩니다. 저장된 도메인에서 사용자를 찾을 수 없으면 저장된 도메인 정보가 삭제되고 도메인 개체를 다시 검색합니다.

TSA에서 SSO를 사용하는 경우와 SSO 에이전트를 사용하는 경우 SonicWALL SSO에서 사용자 로그아웃을 처리하는 방식이 약간 다릅니다. 방화벽은 SSO 에이전트를 실행 중인 인증 에이전트를 구성 가능한 속도로 폴링하여 사용자가 로그아웃한 시간을 확인합니다. 사용자 로그아웃 시 SSO 에이전트를 실행 중인 인증 에이전트는 방화벽으로 사용자 로그아웃됨 응답을 보내 사용자가 로그아웃했음을 확인하고 SSO 세션을 종료합니다. 반면 TSA는 방화벽이 폴링을 수행하지 않고 터미널 서비스/Citrix 서버에서 로그아웃 이벤트를 직접 모니터링하며, 이벤트 발생 시 방화벽에 알리고 SSO 세션을 종료합니다. 두 에이전트에서 모두 구성 가능한 비활성 타이머를 설정할 수 있으며, SSO 에이전트에서는 사용자 이름 요청 폴링 속도를 구성할 수 있습니다. 로그아웃을 빠르게 감지하려면 폴링 시간을 짧게 설정하고, 시스템 오버헤드를 줄이려면 폴링 시간을 길게 설정합니다.

브라우저 NTLM 인증을 사용한 SonicWALL SSO 인증

방화벽은 Internet Explorer, Firefox, Chrome, Safari 등 Mozilla 기반 브라우저로 검색하는 사용자를 NTLM(NT LAN 관리자) 인증을 통해 식별할 수 있도록 지원합니다. NTLM은 "통합 Windows 보안"이라는 브라우저 인증 제품군의 일부로, 모든 Mozilla 기반 브라우저에서 지원됩니다. 또한 SSO 에이전트를 사용하지 않고도 어플라이언스에서 브라우저로 직적 인증을 요청할 수 있습니다. 사용자가 웹을 통해 원격으로 인증하는 경우처럼 도메인 컨트롤러를 사용할 수 없을 때 NTLM이 사용되는 경우가 많습니다.

NTLM 인증은 현재 HTTP에는 사용할 수 있지만 HTTPS 트래픽에는 사용할 수 없습니다.

SSO 에이전트가 사용자 정보를 확보하려고 시도하기 전이나 시도한 후에 브라우저 NTLM 인증을 시도할 수 있습니다. 예를 들어 SSO 에이전트에서 먼저 인증을 시도했는데 사용자를 식별하지 못한 경우 트래픽이 HTTP이면 NTLM을 시도합니다.

Linux 또는 Mac 클라이언트와 Windows 클라이언트에서 모두 이 방법을 사용하려면 SSO를 사용하도록 설정하여 SSO 에이전트에 구성된 항목에 따라 클라이언트에서 NetAPI 또는 WMI를 검색해도 됩니다. 그러면 방화벽이 SSO 에이전트에 사용자 식별을 요청하기 전 NetAPI/WMI 포트에서 응답을 검색합니다. 응답이 없으면 이러한 장치가 SSO에 즉각 실패합니다. 개인 방화벽에서 차단된 경우가 아니면 Windows PC에서 대개 검색이 작동하며 SSO 에이전트가 사용됩니다. 삼바 서버를 실행하도록 설정되지 않았다고 가정하는 경우 Linux/Mac PC에서는 검색에 실패하고 SSO 에이전트를 바이패스하며 HTTP 트래픽 전송 시 NTLM 인증이 사용됩니다.

NTLM은 HTTP를 사용하여 찾아보기 전까지는 사용자를 식별할 수 없으므로, 사용자를 찾아보기 전에 전송되는 모든 트래픽은 식별되지 않은 것으로 처리됩니다. 그러면 기본 CFS 정책이 적용되며, 인증된 사용자를 요구하는 모든 규칙에서 트래픽 통과를 허용하지 않습니다.

SSO 에이전트 전에 NTLM을 사용하도록 구성되어 있으면 HTTP 트래픽이 먼저 수신되고 사용자가 NTLM을 통해 인증됩니다. HTTP가 아닌 트래픽이 먼저 수신되면 인증에 SSO 에이전트가 사용됩니다.

SSO 에이전트의 작동 방식

SSO 에이전트는 IP 주소를 직접 사용하거나 VPN 등의 경로를 사용하여 클라이언트 및 방화벽과 통신할 수 있는 Windows 도메인이 포함된 모든 워크스테이션에 설치할 수 있습니다. SSO 에이전트 설치 지침은 SonicWALL SSO 에이전트 설치를 참조하십시오.

사용자가 수천 명인 대규모 설치를 수행할 수 있도록 여러 SSO 에이전트가 지원됩니다. 각 네트워크의 고성능 전용 PC에서 실행되는 SSO 에이전트를 8개까지 구성할 수 있습니다. 고속 PC의 단일 SSO 에이전트는 사용자를 2,500명까지 지원할 수 있습니다.

SSO 에이전트는 클라이언트 및 방화벽과만 통신할 수 있습니다. SSO 에이전트는 방화벽과 SSO 에이전트 간의 메시지 암호화에 공유 키를 사용합니다.

참고 공유 키는 SSO 에이전트에서 생성되며, SSO를 구성할 때 방화벽에서 입력하는 키는 SSO 에이전트에서 생성된 키와 정확하게 일치해야 합니다.

방화벽은 기본 포트 2258을 통해 SSO 에이전트를 쿼리합니다. 그러면 SSO 에이전트는 클라이언트와 방화벽 사이에서 통신하여 클라이언트의 사용자 ID를 확인합니다. SSO 에이전트는 방화벽에 따라 관리자가 구성할 수 있는 속도로 폴링되어 사용자 로그인 상태를 지속적으로 확인합니다.

로깅

SSO 에이전트는 관리자가 선택한 로깅 수준에 따라 로그 이벤트 메시지를 Windows 이벤트 로그로 보냅니다.

방화벽은 해당 이벤트 로그에 SSO 에이전트 관련 이벤트도 기록합니다. 아래에는 방화벽에서 보내는 SSO 에이전트 관련 로그 이벤트 메시지의 목록이 나와 있습니다.

• 사용자 로그인 거부됨 - 정책 규칙에서 허용하지 않음 – 사용자가 식별되었지만 사용자 트래픽을 차단하는 정책에서 허용되는 사용자 그룹에 속하지 않습니다.

• 사용자 로그인 거부됨 - 로컬에서 발견되지 않았음 – 사용자를 로컬에서 찾을 수 없으며 방화벽에서 로컬 목록의 사용자만 허용이 선택되어 있습니다.

• 사용자 로그인 거부됨 - SSO 에이전트 에이전트 시간 초과 – SSO 에이전트를 연결하려는 시도가 시간 초과되었습니다.

• 사용자 로그인 거부됨 - SSO 에이전트 구성 오류 – SSO 에이전트가 해당 사용자에 대한 액세스를 허용하도록 올바르게 구성되어 있지 않습니다.

• 사용자 로그인 거부됨 - SSO 에이전트 통신 문제 – SSO 에이전트를 실행 중인 워크스테이션과 통신하는 데 문제가 있습니다.

• 사용자 로그인 거부됨 - SSO 에이전트 에이전트 이름 확인 실패 – SSO 에이전트가 사용자 이름을 확인할 수 없습니다.

• SSO 에이전트에서 너무 긴 사용자 이름을 반환함 – 사용자 이름이 너무 깁니다.

• SSO 에이전트에서 너무 긴 도메인 이름을 반환함 – 도메인 이름이 너무 깁니다.

참고 SSO 에이전트와 관련된 로그 메시지의 참고 필드에는 <도메인/사용자 이름>, ***SSO 에이전트에서 인증 텍스트가 포함됩니다.

터미널 서비스 에이전트의 작동 방식

TSA는 터미널 서비스 또는 Citrix가 설치되어 있는 모든 Windows Server 시스템에 설치할 수 있습니다. 서버는 IP 주소를 직접 사용하거나 VPN 등의 경로를 사용하여 방화벽과 통신할 수 있는 Windows 도메인에 속해야 합니다.

TSA 설치 지침은 SonicWALL 터미널 서비스 에이전트 설치를 참조하십시오.

TSA에 대한 내용은 다음 섹션을 참조하십시오.

• 여러 TSA 지원

• TSA 메시지 암호화 및 세션 ID 사용

• 로컬 서브넷 연결

• 터미널 서버의 비도메인 사용자 트래픽

• 터미널 서버에서의 비사용자 트래픽

여러 TSA 지원

사용자가 수천 명인 대규모 설치를 수행하기 위해 여러 터미널 서비스 에이전트(터미널 서버당 하나)를 사용하는 작업에 방화벽을 구성할 수 있습니다. 지원되는 에이전트 수는 표 10에 나와 있는 것처럼 모델에 따라 다릅니다.

표 1 모델별로 지원하는 여러 TSA

Dell SonicWALL 9000 시리즈 네트워크 보안 어플라이언스의 경우 터미널 서버별로 IP 주소가 32개까지 지원됩니다.

TSA 메시지 암호화 및 세션 ID 사용

TSA는 사용자 이름과 도메인이 메시지에 포함되어 있을 때 TSA와 방화벽 간의 메시지 암호화에 공유 키를 사용합니다. TSA에는 사용자 이름과 도메인이 포함되어 있기 때문에 사용자에 대한 첫 번째 시작 알림은 항상 암호화됩니다.

참고 공유 키는 TSA에서 만들어지며, SSO 구성 중에 방화벽에서 입력하는 키는 TSA 키와 정확하게 일치해야 합니다.

TSA는 항상 사용자 이름과 도메인을 포함하는 대신 모든 알림에 사용자 세션 ID를 포함합니다. 이 방식은 효율적이고 안전하며, 에이전트가 다시 시작된 후 TSA를 통해 터미널 서비스 사용자와 다시 동기화할 수 있습니다.

로컬 서브넷 연결

TSA는 어플라이언스에서 반환된 정보를 기준으로 네트워크 토폴로지를 동적으로 인식하며, 인식 후에는 어플라이언스를 통과하지 않는 후속 사용자 연결에 대한 알림을 어플라이언스로 보내지 않습니다. TSA에서 이러한 로컬 대상의 "인식을 취소"하는 메커니즘은 없으므로 어플라이언스의 인터페이스 간에 서브넷을 이동할 때는 TSA를 다시 시작해야 합니다.

터미널 서버의 비도메인 사용자 트래픽

방화벽에는 비도메인 사용자, 즉 도메인이 아닌 로컬 시스템에 로그인한 사용자에게 필요시 제한된 액세스 권한을 제공하기 위한 비도메인 사용자에 대해 제한된 액세스 허용 설정이 있습니다. 이 설정은 다른 SSO 사용자에 대해 작동하는 것과 같이 터미널 서비스 사용자에 대해서도 작동합니다.

개인 방화벽을 실행 중인 Windows 이외 장치 또는 Windows 컴퓨터가 네트워크에 포함되어 있으면 다음에 대한 사용자 검색 옆의 확인란을 선택하고 SSO 에이전트에 구성된 항목에 따라 NetAPI 또는 WMI의 라디오 단추를 선택합니다. 그러면 방화벽이 SSO 에이전트에 사용자 식별을 요청하기 전 NetAPI/WMI 포트에서 응답을 검색합니다. 응답이 없으면 이러한 장치가 SSO에 즉각 실패합니다. 이러한 장치는 SSO 에이전트에서 사용자를 식별하는 데 사용하는 Windows 네트워킹 메시지에 응답하지 않거나 해당 메시지를 차단할 수 있습니다.

터미널 서버에서의 비사용자 트래픽

비사용자 연결은 Windows 업데이트 및 안티바이러스 업데이트용 터미널 서버에서 열립니다. TSA는 로그인된 서비스의 연결을 비사용자 연결로 식별할 수 있으며, 어플라이언스에 대한 알림에 해당 내용을 표시합니다.

이러한 비사용자 연결 처리 과정을 제어할 수 있도록 어플라이언스의 TSA 구성에서 ***터미널 서버 비사용자 트래픽이 액세스 규칙의 사용자 인증을 바이패스하도록 허용 확인란이 제공됩니다. 이 확인란을 선택하면 해당 연결이 허용됩니다. 이 확인란을 선택하지 않으면 서비스가 로컬 사용자로 처리됩니다. 비도메인 사용자에 대해 제한된 액세스 허용 설정을 선택하고 어플라이언스에서 해당 서비스 이름으로 사용자 계정을 만들면 이러한 서비스에 대해 액세스 권한을 제공할 수 있습니다.

브라우저 NTLM 인증의 작동 방식

다음 섹션을 참조하십시오.

• 도메인 사용자의 NTLM 인증

• 비도메인 사용자의 NTLM 인증

• 브라우저의 NTLM 인증용 자격 증명

도메인 사용자의 NTLM 인증

도메인 사용자의 경우 RADIUS의 MSCHAP 메커니즘을 통해 NTLM 응답이 인증됩니다. 이 경우 어플라이언스에서 RADIUS가 사용하도록 설정되어 있어야 합니다.

NTLM 인증을 구성할 때는 SSO 구성의 사용자 탭에 있는 다음 설정이 적용됩니다.

• 로컬 목록의 사용자만 허용

• 로컬 데이터베이스의 간단한 사용자 이름

• 사용자 그룹 구성원 자격 설정용 메커니즘(LDAP 또는 로컬)

• 사용자 그룹 구성원 자격은 로컬에서 LDAP 사용자 이름을 복제하여 설정할 수 있음(LDAP 구성에서 설정하며 사용자 그룹 구성원 자격 메커니즘이 LDAP이면 적용됨)

• 폴링 속도

비도메인 사용자의 NTLM 인증

NTLM에서 비도메인 사용자는 도메인이 아닌 PC에 로그인하는 사용자이거나, 사용자 이름과 암호를 입력하라는 메시지가 표시되었을 때 도메인 자격 증명 이외의 정보를 입력한 사용자일 수 있습니다. 두 가지 경우 모두 NTLM에서는 이러한 사용자와 도메인 사용자를 구분할 수 있습니다.

사용자 이름이 방화벽의 로컬 사용자 계정과 일치하면 해당 계정의 암호에 대해 NTLM 응답의 유효성을 로컬로 검사합니다. 유효성 검사에 성공하면 사용자가 로그인되고 해당 계정을 기준으로 권한이 제공됩니다. 사용자 그룹 구성원 자격은 LDAP가 아닌 로컬 계정에서 설정되며, 암호의 유효성을 로컬로 검사했기 때문에 신뢰할 수 있는 사용자 그룹의 구성원 자격을 포함합니다.

사용자 이름이 로컬 사용자 계정과 일치하지 않으면 사용자는 로그인되지 않습니다. NTLM을 통해 인증된 사용자에게는 비도메인 사용자에 대해 제한된 액세스 허용 옵션이 적용되지 않습니다.

브라우저의 NTLM 인증용 자격 증명

NTLM 인증에서는 사용자가 도메인에 로그인한 경우 브라우저가 도메인 자격 증명을 사용하여 전체 Single Sign On 기능을 제공하거나, 액세스 중인 웹 사이트(여기서는 방화벽)에 대한 이름 및 암호를 입력하라는 메시지를 사용자에게 표시합니다. 사용자가 도메인에 로그인할 때 브라우저가 도메인 자격 증명을 사용하는 기능은 다양한 요인의 영향을 받습니다. 이러한 요인은 사용 중인 브라우저의 유형에 따라 달라집니다.

• Internet Explorer – Internet Explorer는 방화벽에 로그인하는 웹 사이트가 로컬 인트라넷에 있으면 인터넷 옵션의 보안 탭 설정에 따라 사용자의 도메인 자격 증명을 이용하여 투명하게 인증합니다. 이 과정을 진행하려면 인터넷 옵션의 로컬 인트라넷 영역에서 방화벽을 웹 사이트 목록에 추가해야 합니다.

이 작업은 영역에 대한 사이트 할당 목록의 컴퓨터 구성, 관리 템플릿, Windows 구성 요소, Internet Explorer, 인터넷 제어판, 보안 페이지에서 도메인 그룹 정책을 통해 수행할 수 있습니다.

• Google Chrome – Chrome도 인터넷 옵션의 로컬 인트라넷 영역에서 방화벽을 웹 사이트 목록에 추가해야 하는 등 Internet Explorer와 똑같은 방식으로 작동합니다.

• Firefox – Firefox는 방화벽에 로그인하는 웹 사이트가 해당 구성(Firefox 주소 표시줄에 about:config를 입력하여 액세스)의 network.automatic-ntlm-auth.trusted-uris 항목에 포함되어 있으면 사용자의 도메인 자격 증명을 이용하여 투명하게 인증합니다.

• Safari – Safari에서도 NTLM을 지원하기는 하지만 사용자의 도메인 자격 증명을 사용하는 완전히 투명한 로그온 서비스는 현재 지원하지 않습니다.

• PC 이외 플랫폼의 브라우저 – Linux/Mac 같은 PC가 아닌 플랫폼에서는 삼바를 통해 Windows 도메인 리소스에 액세스할 수 있지만, 이 플랫폼에는 Windows PC 같은 "도메인에 PC 로그인" 개념은 없습니다. 따라서 이러한 플랫폼의 브라우저는 사용자 도메인 자격 증명에 액세스할 수 없으며 해당 자격 증명을 NTLM에 사용할 수 없습니다.

사용자가 도메인에 로그인되어 있지 않거나 브라우저에서 사용자의 도메인 자격 증명을 사용할 수 없으면 이름과 암호를 입력하라는 메시지를 표시하거나, 사용자가 이전에 자격 증명을 저장하도록 선택한 경우 캐시된 자격 증명을 사용합니다.

어떤 경우든 사용자 도메인 자격 증명 사용 시 인증이 실패하면(사용자에게 액세스 권한을 받는 데 필요한 권한이 없기 때문일 수 있음) 브라우저에서는 이름과 암호를 입력하라는 메시지를 사용자에게 표시합니다. 그러면 사용자가 도메인 자격 증명과는 다른 자격 증명을 입력하여 액세스 권한을 얻을 수 있습니다.

Single-Sign-On의 RADIUS 계정 작동 방식

다음 섹션을 참조하십시오.

• RADIUS 계정 메시지

• 타사 네트워크 어플라이언스와의 Dell SonicWALL 호환성

• 프록시 전달

• 비도메인 사용자

• IPv6 고려 사항

RADIUS 계정은 사용자 로그인 세션 계정 메시지를 계정 서버에 보내기 위한 NAS(네트워크 액세스 서버)용 메커니즘으로 RFC 2866에 지정됩니다. 이러한 메시지는 사용자 로그인 및 로그오프 시 전송됩니다. 필요에 따라서는 사용자 세션 중에 메시지를 정기적으로 전송할 수도 있습니다.

고객이 타사 네트워크 액세스 어플라이언스를 통해 사용자 인증을 수행하는 경우(대개 원격 또는 무선 액세스용) 해당 어플라이언스가 RADIUS 계정을 지원하면 Dell SonicWALL 어플라이언스가 RADIUS 계정 서버로 사용될 수 있으며, 고객의 네트워크 액세스 서버에서 전송되는 RADIUS 계정 메시지를 네트워크의 SSO(Single Sign On)에 사용할 수 있습니다.

원격 사용자가 타사 어플라이언스를 통해 연결하면 타사 어플라이언스가 RADIUS 계정 서버로 구성된 Dell SonicWALL 어플라이언스로 계정 메시지를 보냅니다. Dell SonicWALL 어플라이언스는 계정 메시지의 정보를 기준으로 로그인된 사용자의 내부 데이터베이스에 해당 사용자를 추가합니다.

사용자가 로그아웃하면 타사 어플라이언스가 Dell SonicWALL 어플라이언스로 또 다른 계정 메시지를 보냅니다. 그러면 Dell SonicWALL 어플라이언스가 사용자를 로그아웃시킵니다.

참고 NAS(네트워크 액세스 서버)는 RADIUS 계정 메시지를 보낼 때 RADIUS를 통해 사용자를 인증하도록 요구하지 않습니다. 즉 NAS는 타사 어플라이언스가 LDAP, 로컬 데이터베이스 또는 기타 메커니즘을 통해 사용자를 인증하더라도 RADIUS 계정 메시지를 보낼 수 있습니다.

RADIUS 계정 메시지는 암호화되지 않습니다. RADIUS 계정은 요청 인증자 및 공유 비밀을 사용하므로 기본적으로 스푸핑에 대해 안전합니다. RADIUS 계정을 사용하려면 RADIUS 계정 메시지를 보낼 수 있는 NAS(네트워크 액세스 서버) 목록을 어플라이언스에 구성해야 합니다. 이 구성에서는 각 NAS에 대해 IP 주소 및 공유 비밀키를 제공합니다.

RADIUS 계정 메시지

RADIUS 계정에서는 두 가지 유형의 계정 메시지를 사용합니다.

• 계정 요청

• 계정 응답

계정 요청은 상태 유형 특성으로 지정된 세 가지 요청 유형을 보낼 수 있습니다.

• 시작 - 사용자가 로그인하면 전송됩니다.

• 중지 - 사용자가 로그아웃하면 전송됩니다.

• 중간 업데이트 - 사용자 로그인 세션 중에 주기적으로 전송됩니다.

계정 메시지는 RFC 2866에 지정된 RADIUS 표준을 따릅니다. 각 메시지는 공유 비밀을 통해 유효성이 검사되는 인증자와 특정 목록을 포함합니다.

SSO와 관련된 다음 특성은 계정 요청에 포함되어 전송됩니다.

• 상태 유형 - 계정 요청의 유형(시작, 중지 또는 중간 업데이트)입니다.

• 사용자 이름 - 사용자의 로그인 이름입니다. 형식은 RFC에 지정되지 않으며 로그인 이름, 도메인, DN(고유 이름) 등 다양한 값을 포함하는 문자열이나 간단한 로그인 이름일 수 있습니다.

• 프레임 IP 주소 - 사용자의 IP 주소입니다. NAT를 사용하는 경우 사용자의 내부 IP 주소여야 합니다.

• 호출 스테이션 ID - Aventail 등의 일부 어플라이언스에 사용되는 사용자 IP 주소의 문자열 표시입니다.

• 프록시 상태 - 다른 RADIUS 계정 서버로 요청을 전달하는 데 사용되는 통과 상태입니다.

타사 네트워크 어플라이언스와의 Dell SonicWALL 호환성

Dell SonicWALL 어플라이언스가 RADIUS 계정을 통해 SSO용 타사 네트워크 어플라이언스와 호환되려면 타사 어플라이언스에서 다음이 가능해야 합니다.

• RADIUS 계정을 지원해야 합니다.

• 시작 및 중지 메시지를 모두 보낼 수 있어야 합니다. 중간 업데이트 메시지는 보내지 않아도 됩니다.

• 시작 및 중지 메시지에서 모두 프레임 IP 주소 또는 호출 스테이션 ID 특성에 포함된 사용자 IP를 보낼 수 있어야 합니다.

참고 NAT를 통해 사용자의 외부 공용 IP 주소를 변환하는 원격 액세스 서버의 경우 특성이 내부 네트워크에서 사용되는 내부 IP 주소를 제공해야 하며, 이 주소가 사용자의 고유 IP 주소여야 합니다. 두 특성을 모두 사용하는 경우 프레임 IP 주소 특성은 내부 IP 주소를, 호출 스테이션 ID 특성은 외부 IP 주소를 사용해야 합니다.

시작 메시지 및 중간 업데이트 메시지의 사용자 이름 특성에서 사용자 로그인 이름을 전송해야 합니다. 중지 메시지의 사용자 이름 특성에서 사용자 로그인 이름을 전송할 수도 있지만 반드시 이렇게 할 필요는 없습니다. 사용자 이름 특성은 사용자 계정 이름을 포함해야 하며 도메인도 포함할 수 있습니다. 그렇지 않으면 사용자의 DN(고유 이름)을 포함해야 합니다.

프록시 전달

RADIUS 계정 서버로 사용되는 Dell SonicWALL 어플라이언스는 각 NAS(네트워크 액세스 서버)에 대해 최대 4개의 다른 RADIUS 계정 서버로 요청을 프록시 전달할 수 있습니다. 각 NAS에 대해 개별 RADIUS 계정 서버를 별도로 구성할 수 있습니다.

각 NAS에 대해 구성 세부 정보를 다시 입력하지 않아도 되도록, SonicOS에서는 구성된 서버 목록의 각 NAS에 대한 전달을 선택할 수 있습니다.

각 NAS 클라이언트에 대한 프록시 전달 구성에는 타임아웃 및 재시도 횟수가 포함됩니다. 다음 옵션을 선택하여 둘 이상의 서버로 요청을 전달하는 방법을 구성할 수 있습니다.

• ***시간 초과 시 다음 서버 시도

• ***모든 서버로 각 요청 전달