인증 모듈 유형 (Sun Java System Access Manager 7.1 관리 설명서)

Sun Java System Access Manager 7.1 관리 설명서

인증 모듈 유형

인증 모듈은 사용자 아이디, 비밀번호와 같은 사용자 정보를 수집하고 이 정보를 데이터베이스의 항목과 비교하여 확인하는 플러그인입니다. 사용자가 인증 기준에 맞는 정보를 제공하면 요청한 자원에 대한 액세스 권한이 허용됩니다. 사용자가 인증 기준에 맞지 않는 정보를 제공하면 요청한 자원에 대한 액세스가 거부됩니다. Access Manager는 다음 15가지 유형의 인증 모듈과 함께 설치됩니다.

주 –

일부 인증 모듈의 경우 인증 인스턴스로 사용할 수 있으려면 사전 구성이 필요합니다. 필요한 경우 구성 단계가 모듈 유형 설명에 나옵니다.

핵심

Access Manager는 기본적으로 핵심 인증 모듈과 15개의 다른 인증 모듈을 제공합니다. 핵심 인증 모듈은 인증 모듈에 대한 전체 구성을 제공합니다. 활성 디렉토리, 익명, 인증서 기반, HTTP 기본, JDBC, LDAP 및 인증 모듈을 추가하고 활성화하기 전에 먼저 핵심 인증을 추가하고 활성화해야 합니다. 핵심 및 LDAP 인증 모듈은 모두 기본 영역에 대해 자동으로 활성화됩니다.

[고급 등록 정보] 버튼을 누르면 영역에 대해 정의할 수 있는 핵심 인증 속성이 표시됩니다. 전역 속성은 영역에 적용되지 않으므로 표시되지 않습니다.

활성 디렉토리

활성 디렉토리 인증 모듈은 LDAP 모듈과 비슷한 방법으로 인증을 수행하지만 LDAP 인증 모듈의 Directory Server와 반대되는 Microsoft의 Active Directory™ 서버를 사용합니다. 활성 디렉토리 서버에 대해 LDAP 인증 모듈을 구성할 수는 있지만 이 모듈을 사용하면 LDAP 및 활성 디렉토리 인증이 모두 같은 영역 아래에 있게 됩니다.

주 –

이 릴리스의 경우 활성 디렉토리 인증 모듈만 사용자 인증을 지원합니다. 비밀번호 정책은 LDAP 인증 모듈에서만 지원됩니다.

익명

기본적으로 이 모듈이 활성화되면 사용자는 Access Manager에 익명 사용자로 로그인할 수 있습니다. 또한 유효한 익명 사용자 목록 속성을 구성하여 이 모듈에 대한 익명 사용자 목록을 정의할 수 있습니다. 익명 액세스를 허용한다는 것은 비밀번호를 입력하지 않고 액세스할 수 있다는 의미입니다. 특정 액세스 유형(예: 읽기 액세스, 검색 액세스) 또는 디렉토리 내의 개별 항목이나 특정 하위 트리로 익명 액세스를 제한할 수 있습니다.

인증서

인증서 기반 인증에는 PDC(Personal Digital Certificate)를 사용한 사용자 식별 및 인증이 포함됩니다. Directory Server에 저장된 PDC에 대한 일치 및 인증서 해지 목록에 대한 확인을 수행하도록 PDC를 구성할 수 있습니다.

인증서 기반 인증 모듈을 영역에 추가하기 전에 여러가지 작업을 수행해야 합니다. 먼저, Access Manager와 함께 설치되는 웹 컨테이너를 보호하고 인증서 기반 인증에 맞게 구성해야 합니다.

주 –

SSL 사용 가능 Sun Java System Web Server 6.1 인스턴스를 사용하여 Access Manager 인증서 인증을 구성하고 인증서 기반 인증 요청 및 비인증서 기반 인증 요청을 모두 수락하도록 Web Server를 정의하려면 Web Server의 obj.conf 파일에 다음 값을 설정해야 합니다.

PathCheck fn="get-client-cert" dorequest="1" require="0"

이는 이 동작에 대한 선택적 속성을 설정할 때 Web Server 콘솔의 제한 사항으로 인한 것입니다.

인증서 기반 모듈을 활성화하기 전에 이 초기 Web Server 구성 단계에 대한 내용을 보려면 Sun ONE Web Server 6.1 관리자 설명서의 6장, “인증서 및 키 사용”을 참조하십시오. 이 문서는 다음 위치에서 확인할 수 있습니다.

http://docs.sun.com/app/docs/coll/S1_websvr61_en

또는 다음 위치에서 Sun ONE Application Sever 관리자 보안 설명서를 참조하십시오.

http://docs.sun.com/db/prod/s1appsrv#hic

주 –

인증서 기반 모듈을 사용하여 인증할 각 사용자는 사용자의 브라우저에 대한 PDC를 요청해야 합니다. 지침은 사용되는 브라우저에 따라 다릅니다. 자세한 내용은 해당 브라우저의 설명서를 참조하십시오.

이 모듈을 추가하려면 Access Manager에 영역 관리자로 로그인해야 하며 Access Manager와 웹 컨테이너에서 SSL을 구성하고 클라이언트 인증을 활성화해야 합니다. 자세한 내용은 Access Manager Post Installation Guide의 Configuring Access Manager in SSL Mode를 참조하십시오.

데이터 저장소

데이터 저장소 인증 모듈을 사용하면 영역의 Identity 저장소를 사용한 로그인 시 사용자를 인증할 수 있습니다. 데이터 저장소 모듈을 사용하면 같은 데이터 저장소에 대해 인증해야 하는 경우에도 인증 플러그인 모듈을 작성하고 인증 모듈을 로드 및 구성할 필요가 없습니다. 또한 해당 영역에서 플랫 파일 인증이 각 저장소에 필요한 경우 사용자 정의 인증 모듈을 작성할 필요가 없습니다.

Access Manager 인증을 구성할 때 이 인증 유형을 사용하면 어느 정도 편리합니다. Access Manager 7.1 이전 릴리스에서는 LDAPv3 데이터 저장소의 사용자가 해당 영역에서 인증되려면 다음을 수행해야 했습니다.

LDAPv3 데이터 저장소 구성
동일한 영역 주제를 참조하도록 LDAP 인증 모듈 인스턴스 구성

데이터 저장소 인증 모듈을 사용하면 영역의 Identity 저장소에 정의된 사용자를 인증할 수 있습니다. 이 경우 어떤 LDAP 인증 구성도 필요하지 않습니다. 예를 들어 영역의 Identity 저장소에 LDAPv3 데이터 저장소가 있고 같은 영역에서 데이터 저장소 인증을 사용한다고 가정해 보겠습니다. 이 경우 Identity 저장소에 정의된 사용자는 모두 해당 영역에서 인증될 수 있습니다.

HTTP 기본

이 모듈은 HTTP 프로토콜에서 지원하는 기본 제공 인증인 기본 인증을 사용합니다. Web Server는 아이디 및 비밀번호에 대한 클라이언트 요청을 발급하고, 해당 정보를 인증된 요청에 포함하여 서버로 다시 보냅니다. Access Manager는 사용자 아이디와 비밀번호를 수신한 다음 LDAP 인증 모듈에 대해 사용자를 내부적으로 인증합니다. HTTP 기본이 제대로 작동하게 하려면 LDAP 인증 모듈을 추가해야 합니다(HTTP 기본 모듈만 추가하면 작동되지 않음). 성공적으로 인증한 사용자는 사용자 아이디와 비밀번호를 묻는 메시지를 표시하지 않고 다시 인증할 수 있습니다.

JDBC

JDBC(Java Database Connectivity) 인증 모듈은 Access Manager가 JDBC 기술 사용 드라이버를 제공하는 SQL 데이터베이스를 통해 사용자를 인증하는 기법을 지원합니다. SQL 데이터베이스는 JDBC 드라이버나 JNDI 연결 풀을 통해 직접 연결할 수 있습니다.

주 –

이 모듈은 MySQL4.0 및 Oracle 8i에서 테스트되었습니다.

LDAP

LDAP 인증 모듈에서는 사용자가 로그인할 때 특정 사용자 DN 및 비밀번호를 사용하여 LDAP Directory Server에 바인드해야 합니다. 이는 모든 영역 기반 인증에 대한 기본 인증 모듈입니다. 사용자는 Directory Server에 있는 사용자 아이디와 비밀번호를 입력하여 유효한 Access Manager 세션에 액세스할 수 있으며 해당 세션을 사용하여 사용자를 설정할 수 있습니다. 기본 영역에서는 핵심 및 LDAP 인증 모듈을 모두 자동으로 사용할 수 있게 됩니다.

구성원

구성원 인증은 my.site.com, mysun.sun.com 등과 같은 개인 설정 사이트와 비슷하게 구현됩니다. 이 모듈이 사용 가능한 경우 사용자는 관리자의 도움 없이 계정을 만들어 사용자 설정할 수 있습니다. 사용자는 이 새 계정에 추가된 사용자로 액세스할 수 있습니다. 또한, 사용자 프로필 데이터베이스에 인증 데이터 및 사용자 기본 설정으로 저장된 뷰어 인터페이스에 액세스할 수 있습니다.

MSISDN

MSISDN(Mobile Station Integrated Services Digital Network) 인증 모듈을 사용하면 휴대 전화와 같은 장치의 이동 가입자 ISDN을 사용하여 인증할 수 있습니다. 이 모듈은 비대화식 모듈입니다. 가입자 ISDN을 검색하고 이를 Directory Server에서 검증하여 번호에 맞는 사용자를 찾습니다.

RADIUS

Access Manager를 구성하여 이미 설치된 RADIUS 서버에서 작업할 수 있습니다. 이렇게 하면 회사에서 레거시 RADIUS 서버를 사용하여 인증하는 경우에 유용합니다. RADIUS 인증 모듈을 활성화하려면 다음 2단계 프로세스를 거쳐야 합니다.

RADIUS 서버를 구성합니다.

자세한 내용은 RADIUS 서버 설명서를 참조하십시오.
RADIUS 인증 모듈을 등록하여 사용 가능하게 합니다.

Sun Java System Application Server에서 RADIUS 구성

RADUIS 클라이언트에서 이 서버에 소켓 연결을 수행할 경우 기본적으로 Application Server의 server.policy 파일에 SocketPermissions 연결 권한만 허용됩니다. RADUIS 인증이 제대로 작동하게 하려면 다음 작업에 대한 권한을 허용해야 합니다.

적용
연결
수신
결정

소켓 연결 권한을 부여하려면 Application Server의 server.policy 파일에 항목을 추가해야 합니다. SocketPermission은 호스트 사양과 해당 호스트에 연결하는 방법을 지정하는 작업 집합으로 구성됩니다. 호스트를 지정하는 구문은 다음과 같습니다.

host = hostname | IPaddress:portrange:portrange = portnumber 
| -portnumberportnumber-portnumber

host는 DNS 이름, 숫자 IP 주소 또는 로컬 호스트(로컬 시스템의 경우)로 표현됩니다. 와일드카드 “*”는 DNS 이름 호스트 규격에 한 번 포함될 수 있습니다. 와일드카드가 포함되는 경우 가장 왼쪽 위치(예: *.example.com)에 와일드카드가 있어야 합니다.

포트(또는 포트 범위)는 선택 사항입니다. N- 형식의 포트 사양은 번호가 N 이상인 모든 포트를 나타냅니다. 여기서 N은 포트 번호입니다. -N 형식의 사양은 번호가 N 이하인 모든 포트를 나타냅니다.

수신 작업은 로컬 호스트에서 사용될 때만 적용됩니다. 결정(호스트/IP 이름 서비스 조회 결정) 작업은 다른 작업이 있을 때 적용됩니다.

예를 들어, SocketPermissions을 만들 때 일부 코드에 다음 권한이 허용되는 경우 해당 코드를 machine1.example.com의 port 1645에 연결하고 해당 포트에서 연결을 적용할 수 있습니다.

permission java.net.SocketPermission machine1.example.com:1645, "connect,accept";

마찬가지로 일부 코드에 다음 권한이 허용되는 경우 해당 코드를 사용하여 로컬 호스트에서 1024에서 65535 사이의 포트에서 연결을 적용, 연결 또는 수신할 수 있습니다.

permission java.net.SocketPermission "machine1.example.com:1645", "connect,accept";
permission java.net.SocketPermission "localhost:1024-", "accept,connect,listen";

주 –

원격 호스트에 연결을 적용하거나 연결하도록 코드 권한을 허용하면 유해 코드를 통해 해당 데이터에 대한 액세스 권한이 없는 당사자 간에 기밀 데이터를 쉽게 전송 및 공유할 수 있기 때문에 문제가 발생할 수 있습니다. 포트 번호의 범위 대신 정확한 포트 번호를 지정하여 해당 사용 권한만 부여해야 합니다.

SafeWord

Access Manager를 구성하여 Secure Computing의 SafeWord™ 또는 SafeWord PremierAccess™ 인증 서버에 대한 SafeWord 인증 요청을 처리할 수 있습니다. Access Manager는 SafeWord 인증의 클라이언트 부분을 제공합니다. SafeWord 서버는 Access Manager가 설치되는 시스템이나 별도의 시스템에 위치할 수 있습니다.

Sun Java System Application Server에서 SafeWord 구성

SafeWord 클라이언트에서 이 서버에 소켓 연결을 수행할 경우 기본적으로 Application Server’의 server.policy 파일에 SocketPermissions 연결 권한만 허용됩니다. SafeWord 인증이 제대로 작동하게 하려면 다음 작업에 대한 권한을 허용해야 합니다.

적용
연결
수신
결정

host = (hostname | IPaddress)[:portrange] portrange = 
portnumber | -portnumberportnumber-[portnumber]

수신 작업은 로컬 호스트에서 사용될 때만 적용됩니다. 결정(호스트/IP 이름 서비스 조회 결정) 작업은 다른 작업이 있을 때 적용됩니다.

permission java.net.SocketPermission machine1.example.com:5030, "connect,accept";

permission java.net.SocketPermission "machine1.example.com:5030", "connect,accept";
permission java.net.SocketPermission "localhost:1024-", "accept,connect,listen";

주 –

SAML

SAML(Security Assertion Markup Language) 인증 모듈은 대상 서버에서 SAML 명제를 받아 검증합니다. SAML SSO는 업그레이드(예: Access Manager 2005Q4를 Access Manager 7.1로) 이후를 포함하여 이 모듈을 대상 컴퓨터에 구성한 경우에만 작동됩니다.

SecurID

Access Manager를 구성하여 RSA의 ACE/Server 인증 서버에 대한 SecurID 인증 요청을 처리할 수 있습니다. Access Manager는 SecurID 인증의 클라이언트 부분을 제공합니다. ACE/Server는 Access Manager가 설치되는 시스템이나 별도의 시스템에 위치할 수 있습니다. 로컬로 관리되는 사용자 아이디(admintool(1M) 참조)를 인증하려면 루트로 액세스해야 합니다.

SecurID 인증에서는 amsecuridd 인증 도우미가 사용됩니다. 이 프로세스는 Access Manager 주 프로세스와 다른 별도의 프로세스입니다. 시작 시에 이 도우미는 하나의 포트에서 구성 정보를 수신합니다. Access Manager를 설치하여 nobody 또는 루트가 아닌 사용자 아이디로 실행할 경우에도 AccessManager-base/SUNWam/share/bin/amsecuridd 프로세스는 여전히 루트로 실행되어야 합니다. amsecuridd 도우미에 대한 자세한 내용은 Access Manager Administration Reference의 “The amSecurID Helper”를 참조하십시오.

주 –

이 릴리스의 Access Manager에서는 Linux 또는 Solaris x86 플랫폼에 대해 SecurID 인증 모듈을 사용할 수 없으며, 이 두 플랫폼에서 등록, 구성 및 사용해서는 안됩니다. SPARC 시스템에만 사용할 수 있습니다.

UNIX

Access Manager를 구성하여 Access Manager가 설치된 Solaris 또는 Linux 시스템에 알려진 Unix 사용자 아이디와 비밀번호에 대한 인증 요청을 처리할 수 있습니다. 영역 속성은 하나만 있지만 Unix 인증을 위한 전역 속성이 여러 개인 경우 몇 가지 시스템 고려 사항이 있습니다. 로컬로 관리되는 사용자 아이디(admintool(1M) 참조)를 인증하려면 루트로 액세스해야 합니다.

Unix 인증에서는 amunixd 인증 도우미가 사용됩니다. 이 프로세스는 Access Manager 주 프로세스와 다른 별도의 프로세스입니다. 시작 시에 이 도우미는 하나의 포트에서 구성 정보를 수신합니다. 각 Access Manager에는 모든 영역에 서비스를 제공하는 Unix 도우미가 하나씩만 있습니다.

Access Manager를 설치하여 nobody 또는 루트가 아닌 사용자 아이디로 실행할 경우에도 AccessManager-base/SUNWam/share/bin/amunixd 프로세스는 여전히 루트로 실행되어야 합니다. Unix 인증 모듈은 localhost:58946에 대한 소켓을 열어 amunixd 데몬을 호출하여 Unix 인증 요청을 수신합니다. 기본 포트에서 amunixd 도우미 프로세스를 실행하려면 다음 명령을 입력합니다.

./amunixd

기본 포트가 아닌 포트에서 amunixd를 실행하려면 다음 명령을 입력합니다.

./amunixd [-c portnm] [ipaddress]

ipaddress 및 portnumber는AMConfig.properties의 UnixHelper.ipadrs(IPV4 형식) 및 UnixHelper.port 속성에 있습니다. amserver 명령줄 유틸리티를 통해 amunixd를 실행할 수 있습니다. amserver는 프로세스를 자동으로 실행하여 AMConfig.properties에서 포트 번호와 IP 주소를 검색합니다.

/etc/nsswitch.conf 파일의 passwd 항목에 따라 인증에 /etc/passwd 및 /etc/shadow 파일을 참조하는지 NIS를 참조하는지가 결정됩니다.

Windows 데스크탑 SSO

Windows 데스크탑 SSO 인증 모듈은 Windows 2000™에 사용되는 커버로스 기반 인증 플러그인 모듈입니다. 이 모듈을 사용하면 KDC(Kerberos Distribution Center)에 대해 이미 인증을 받은 사용자는 로그인 조건(단일 사인온)을 다시 제출하지 않고도 Access Manager에 대해 인증을 받을 수 있습니다.

사용자는 SPNEGO(Simple and Protected GSS-API Negotiation Mechanism) 프로토콜을 통해 Access Manager에 커버로스 토큰을 제공합니다. 이 인증 모듈을 통해 Access Manager에 커버로스 기반 단일 사인온을 수행하려면 클라이언트측에서 사용자를 인증하도록 SPNEGO 프로토콜을 지원해야 합니다. 일반적으로 이 프로토콜을 지원하는 사용자는 이 모듈을 사용하여 Access Manager에 인증할 수 있습니다. 클라이언트측 토큰의 가용성에 따라 이 모듈은 SPENGO 토큰 또는 커버로스 토큰(두 경우 모두 동일한 프로토콜)을 제공합니다. Windows 2000 이상에서 실행되는 Microsoft Internet Explorer(5.01 이상)는 현재 이 프로토콜을 지원합니다. 또한 Solaris(9 및 10)의 Mozilla 1.4도 SPNEGO 지원 기능이 있지만 Solaris에서 SPNEGO를 지원하지 않으므로 반환되는 토큰은 커버로스 토큰뿐입니다.

주 –

커버로스 V5 인증 모듈의 새 기능을 활용하려면 JDK 1.4 이상을 사용하고 이 SPNEGO 모듈에서 커버로스 기반 SSO를 수행하려면 Java GSS API를 사용해야 합니다.

Internet Explorer의 알려진 제한 사항

WindowsDesktopSSO 인증용으로 Microsoft Internet Explorer 6.x를 사용하고, 브라우저에 WindowsDesktopSSO 모듈에서 구성된 KDC 영역과 일치하는 사용자의 커버로스/SPNEGO 토큰에 대한 액세스 권한이 없는 경우 브라우저가 WindowsDesktopSSO 모듈 인증에 실패하면 다른 모듈에 대해 올바르게 작동하지 않습니다. 이 문제의 직접적인 원인은 Internet Explorer에서 WindowsDesktopSSO 모듈 실패 후 다른 모듈의 콜백이 프롬프트에 표시되는 경우에도 브라우저에서 이를 Access Manager에 전달할 수 없기 때문이며, 이러한 불능 상태는 브라우저를 다시 시작할 때까지 계속됩니다. 즉 null 사용자 자격 증명 때문에 WindowsDesktopSSO 실패 후 수신한 모든 모듈도 실패합니다.

자세한 내용은 다음 설명서를 참조하십시오.

http://support.microsoft.com/default.aspx?scid=kb;en-us;308074

http://www.wedgetail.com/jcsi/sso/doc/guide/troubleshooting.html#ieNTLM

주 –

이번 Access Manager 릴리스부터 Microsoft에서 이러한 제한 사항을 해결했습니다. 자세한 내용은 다음 설명서를 참조하십시오.

http://www.microsoft.com/technet/security/bulletin/ms06-042.mspx

Windows 데스크탑 SSO 구성

Windows 데스크탑 SSO 인증을 활성화하는 2단계 프로세스는 다음과 같습니다.

Windows 2000 도메인 컨트롤러에서 사용자를 만듭니다.
Internet Explorer를 설정합니다.

Windows 2000 도메인 컨트롤러에서 사용자를 만들려면

도메인 컨트롤러에서 Access Manager 인증 모듈에 사용할 사용자 계정을 만듭니다.
1. 시작 메뉴에서 프로그램>관리 도구로 이동합니다.
2. 활성 디렉토리 사용자 및 컴퓨터를 선택합니다.
3. [컴퓨터] > [새로 만들기] > [컴퓨터]로 이동하고 클라이언트 컴퓨터의 이름을 추가합니다. Windows XP를 사용하는 경우 이 단계는 도메인 컨트롤러 계정 구성 시 자동으로 수행됩니다.
4. [사용자] > [새로 만들기] > [사용자]로 이동한 다음 Access Manager 호스트 이름을 사용하여 새 사용자를 사용자 아이디(로그인 이름)로 만듭니다. Access Manager 호스트 이름에는 도메인 이름이 포함되지 않아야 합니다.

사용자 계정을 서비스 공급자 이름과 연결하고 Access Manager가 설치된 시스템으로 키탭 파일을 내보냅니다. 그러려면 다음 명령을 실행합니다.

ktpass -princ host/hostname.domainname@DCDOMAIN -pass password -mapuser userName-out 
hostname.host.keytab
ktpass -princ HTTP/hostname.domainname@DCDOMAIN -pass 
password -mapuser userName-out hostname
.HTTP.keytab

주 –

ktpass 유틸리티는 Windows 2000 서버의 일부로 설치되지 않으므로설치 CD에서 c:\program files\support 도구 디렉토리로 설치해야 합니다.

ktpass 명령에는 다음과 같은 매개 변수가 사용됩니다.

hostname. Access Manager를 실행하는 호스트 이름(도메인 이름 없음)입니다.

domainname. Access Manager 도메인 이름입니다.

DCDOMAIN. 도메인 컨트롤러의 도메인 이름입니다. Access Manager 도메인 이름과 다를 수 있습니다.

password . 사용자 계정의 비밀번호입니다. ktpass에서는 비밀번호를 확인하지 않으므로 비밀번호가 정확한지 확인합니다.

userName. 사용자 계정 아이디입니다. 호스트 이름과 같아야 합니다.

주 –

두 키탭 파일이 모두 안전하게 보존되는지 확인합니다.

서비스 템플리트 값은 다음 예와 비슷해야 합니다.

서비스 기본: HTTP/machine1.EXAMPLE.COM@ISQA.EXAMPLE.COM

키탭 파일 이름: /tmp/machine1.HTTP.keytab

커버로스 영역: ISQA.EXAMPLE.COM

커버로스 서버 이름: machine2.EXAMPLE.com

도메인 이름과 함께 기본 반환: false

인증 수준: 22

주 –

Windows 2003 또는 Windows 2003 서비스 팩을 사용하는 경우 다음 ktpass 명령 구문을 사용합니다.

ktpass /out filename /mapuser username /princ HTTP/hostname.domainname 
     /crypto encryptiontype /rndpass /ptype principaltype /target domainname

예를 들면 다음과 같습니다.

ktpass /out demo.HTTP.keytab /mapuser http 
/princ HTTP/demo.identity.sun.com@IDENTITY.SUN.COM /crypto RC4-HMAC-NT 
/rndpass /ptype KRB5_NT_PRINCIPAL /target IDENTITY.SUN.COM

구문 정의에 대한 자세한 내용은 http://technet2.microsoft.com/WindowsServer/en/library/64042138-9a5a-4981-84e9-d576a8db0d051033.mspx?mfr=true 웹 사이트를 참조하십시오.

서버를 다시 시작합니다.

Internet Explorer를 설정하려면

이 단계는 Microsoft Internet Explorer™ 6 이상에 적용됩니다. 이전 버전을 사용하는 경우 Access Manager가 브라우저의 인터넷 영역에 있고 고유한 Windows 인증을 사용하는지 확인하십시오.

[도구] 메뉴에서 [인터넷 옵션] > [고급/보안] > [보안]으로 이동합니다.

[통합된 Windows 인증 사용] 옵션을 선택합니다.

[보안] > [로컬 인터넷]으로 이동합니다.
1. [사용자 지정 수준]을 선택합니다. [사용자 인증/로그온] 창에서 [인트라넷 영역에서만 자동으로 로그온] 옵션을 선택합니다.
2. 사이트로 가서 옵션을 모두 선택합니다.
3. [고급]을 누르고 로컬 영역에 Access Manager를 추가합니다(아직 추가되지 않은 경우).

Windows NT

이미 설치된 Windows NT/Windows 2000 서버에서 작업하도록 Access Manager를 구성할 수 있습니다. Access Manager는 NT 인증의 클라이언트 부분을 제공합니다.

NT 서버를 구성합니다. 자세한 내용은 Windows NT 서버 설명서를 참조하십시오.
Windows NT 인증 모듈을 추가하여 사용 가능하게 하려면 Solaris 시스템의 Access Manager와 통신하도록 Samba 클라이언트를 설치해야 합니다.

Samba 클라이언트 설치

Windows NT 인증 모듈을 활성화하려면 Samba Client 2.2.2를 다운로드하여 다음 디렉토리에 설치해야 합니다.

AccessManager-base/SUNWam/bin

Samba 클라이언트는 별도의 Windows NT/2000 Server 없이도 Windows 시스템과 UNIX 시스템을 혼합하여 사용할 수 있는 파일 및 인쇄 서버입니다. 자세한 내용을 보거나 Samba 클라이언트를 다운로드하려면 http://wwws.sun.com/software/download/products/3e3af224.html에 액세스하십시오.

Red Hat Linux에서는 Samba 클라이언트가 다음 디렉토리에 제공됩니다.

/usr/bin

Linux용 Windows NT 인증 모듈을 사용하여 인증하려면 다음 Access Manager 디렉토리에 클라이언트 바이너리를 복사합니다.

AccessManager-base/sun/identity/bin

주 –

인터페이스가 여러 개인 경우에는 추가 구성이 필요합니다. smb.conf 파일의 구성에서 여러 인터페이스를 설정할 수 있으므로 mbclient로 전달됩니다.