Office Communicator 로그인 및 검색

마지막으로 수정된 항목: 2009-04-02

Office Communicator에서는 사용자의 URI(예: jeremy@contoso.com) 및 클라이언트에 구성된 수동 설정을 사용하여 로그온할 서버를 결정해야 합니다. 수동 설정이 제공된 경우 사용할 서버를 쉽게 결정할 수 있지만 URI가 제공된 유일한 지표인 경우에는 약간의 검색이 필요합니다.

Communicator 검색은 구성에 따라 다릅니다. 클라이언트가 연결할 서버를 검색한 후에는 TCP 또는 TCP를 통한 TLS를 사용하여 연결하려고 합니다. TLS가 사용되는 경우 서버에서 서버 자체를 클라이언트에 인증하기 위한 인증서를 제공합니다. 클라이언트는 계속하기 전에 인증서의 유효성을 검사해야 합니다. 클라이언트는 압축을 협상(TCP를 통한 TLS를 사용할 경우)한 다음 SIP 등록을 시작할 수 있습니다.

그런 다음 클라이언트는 자격 증명 없이 SIP REGISTER 메시지를 서버에 보냅니다. 그러면 Office Communications Server에서 사용자 자격 증명을 입력하라는 메시지가 표시되고 Communicator 클라이언트에 허용되는 인증 프로토콜을 지정합니다.

자격 증명 제공과 관련하여 Communicator에서는 두 가지 옵션을 제공합니다. 즉, 사용자의 최신 Windows 자격 증명을 사용하여 로그온하거나 사용자에게 자격 증명을 입력하라는 메시지를 표시할 수 있습니다.

[!참고] Windows의 자격 증명 관리자를 사용하여 자격 증명을 관리할 수도 있습니다. 자격 증명 관리자에 대한 자세한 내용은 Microsoft TechNet 문서 Windows XP 리소스 키트: 로그온 및 인증 이해(https://go.microsoft.com/fwlink/?Linkid=133674)(영문)에서 저장된 사용자 이름 및 암호 섹션을 참조하십시오.

로그온 처리 첫 부분에서 인증 실패가 발생할 수 있습니다. 이 문제는 자격 증명을 아직 저장하지 않았거나 데스크톱 자격 증명이 Communicator에서 사용하려고 하는 계정과 일치하지 않는 경우에 발생할 수 있습니다. 또한 SIP URI, 계정 이름 또는 암호를 잘못 입력하거나 자격 증명과 SIP URI가 일치하지 않는 경우에도 발생할 수 있습니다. 이러한 경우의 예로 Jeremy가 URI sip:jeremy@contoso.com을 사용하여 로그온하려고 하지만 계정 소유자의 자체 자격 증명인 CONTOSO\jeremy 대신 CONTOSO\vadim의 사용자 계정과 암호를 사용하는 경우를 들 수 있습니다.

클라이언트 자동 구성 및 DNS 검색 이해

자동 구성을 사용할 조직의 경우 클라이언트 로그인 요청을 처리하는 엔터프라이즈 풀 또는 Standard Edition 서버의 FQDN(정규화된 도메인 이름)에 다음 레코드 중 하나를 매핑하는 내부 DNS SRV 레코드를 서버 배포 시 만들어야 합니다.

• _sipinternaltls._tcp.<도메인>(내부 TLS 연결의 경우)
• _sipinternal._tcp.<도메인>(내부 TCP 연결의 경우, TCP가 허용되는 경우에만 수행)

자동 구성을 사용하도록 설정된 클라이언트는 사용자가 제공한 SIP URI를 사용하여 로그인해야 하는 서버를 검색합니다. Communicator는 SIP URI의 도메인 부분에 대해 게시된 DNS SRV 레코드를 사용하여 이 작업을 수행합니다.

예를 들어 사용자가 sip:jeremy@contoso.com이라는 URI를 입력하면 Communicator는 contoso.com을 사용하여 DNS를 사용하는 SIP 서버를 검색합니다. Communicator는 적절한 서버를 검색할 때 다음 SRV 레코드를 검색합니다.

• _sipinternaltls._tcp.contoso.com
• _sipinternal._tcp.contoso.com
• _sip._tls.contoso.com

이러한 레코드가 없으면 Communicator는 다음과 같은 호스트(A) 레코드를 쿼리합니다.

• sipinternal.contoso.com
• sipexternal.contoso.com

첫 번째 쿼리에서는 클라이언트에 대해 TCP를 통한 TLS를 지원하는 포트를 제공하는 contoso.com 도메인의 내부 서버를 검색합니다. 두 번째 쿼리에서는 클라이언트에 대해 TCP 포트를 제공하는 contoso.com 도메인의 내부 서버를 검색합니다. 마지막으로 세 번째 쿼리에서는 클라이언트에 대해 TCP를 통한 TLS를 지원하는 포트를 제공하는 contoso.com 도메인의 인터넷 연결 가능 서버를 검색합니다. 인터넷에서 일반 텍스트 SIP를 사용하는 것은 보안상 적합하지 않으므로 Communicator에서는 TCP를 지원하는 인터넷 연결 가능 서버는 검색하지 않습니다. 즉, Communicator는 사용할 네트워크가 내부 네트워크인지 또는 외부 네트워크인지를 인식하지 못합니다. Communicator는 모든 DNS SRV 레코드를 쿼리하지만 먼저 TCP를 통한 TLS 연결을 시도합니다. TCP를 통한 TLS는 에지 서버를 통해 적용됩니다(보안되지 않은 TCP 연결을 허용하는 옵션 없음).

마지막으로 모든 DNS SRV 레코드가 없는 경우(레코드가 잘못된 경우가 아니라 전혀 없는 경우에만) 클라이언트는 다시 sipinternal.<URI 도메인>으로 돌아가 해당 호스트 이름을 확인하려고 합니다. 호스트 이름이 IP 주소로 확인되면 Communicator는 정책에서 무엇이 허용되는지에 따라 TCP를 통한 TLS나 TCP 또는 둘 다를 사용하여 연결하려고 합니다. 연결에 실패하면 sipexternal.<URI 도메인>을 사용하여 마지막으로 한 번만 더 시도합니다.

Communicator 정책을 적용하여 TCP가 사용되지 않게 하면 두 번째 쿼리가 발급되지 않게 할 수 있습니다. 검색되는 컴퓨터에 엄격한 이름을 사용하도록 하는 EnableStrictDNSNaming 정책을 지정할 수도 있습니다. 이 경우 이름이 사용자 SIP URI 도메인 부분의 도메인과 일치하는 경우나 FQDN이 **sip.<URI 도메인>**인 경우에만 Communicator가 서버에 연결할 수 있습니다. 이 정책이 사용되지 않는 경우 <서버 이름>.<URI 도메인> 형식의 모든 서버 이름을 사용할 수 있습니다. 예를 들어 sip:jeremy@contoso.com의 경우 호스트 sip.contoso.com은 엄격한 정책이 사용되는지 여부와 상관없이 항상 허용됩니다. Server77.contoso.com, sipfed.contoso.com 및 ap.contoso.com도 엄격한 명명 정책이 사용되지 않는 경우 모두 허용됩니다. sip.eng.contoso.com, sip.contoso.net, sip.com, sip.contoso.com.cpandl.com 등과 같은 서버 이름은 사용자 URI에 지정된 도메인과 정확히 일치하지 않으므로 클라이언트에서 이러한 서버를 유효한 로그온 지점으로 신뢰하지 않습니다.

호스트 이름과 URI 간의 이러한 엄격한 유효성 검사는 특히 클라이언트에 제공되는 구성이 SIP URI뿐이기 때문에 수행됩니다. 이 때문에 클라이언트는 메시지 가로채기(man-in-the-middle)에 연결하여 Communicator 트래픽을 볼 수 있게 하는 DNS 공격을 당하지 않도록 주의해야 합니다. 로그온이 허용된 호스트 이름 및 URI 간의 밀접한 연결을 통해 Communicator는 사용자가 로그온하려고 하는 도메인에 대한 권한이 사용자가 유효성을 검사하는 인증서에 실제로 있는지를 보다 잘 확인할 수 있습니다.

호스트 이름이 식별되면 Communicator는 호스트 이름을 IP 주소로도 확인합니다. 이는 일반적으로 DNS SRV 요청의 결과로 이루어지지만 IP 주소가 확인되기 전까지는 Communicator가 연결할 수 없습니다. 이것도 로그온 중에 문제가 될 수 있습니다.

최신 버전의 Communicator를 사용하면 로그온할 내부 및 외부 서버를 모두 수동으로 지정할 수 있습니다. Communicator는 사용 가능한 경우 항상 내부 서버에 연결하려고 하지만 외부 서버에 연결하기도 합니다. 이전에는 Communicator에서 한 번의 수동 입력만 허용하여 모바일 직원에게 문제가 되었습니다. 이제는 내부 및 외부 서버를 지정할 수 있는 기능을 통해 관리자가 내부 및 외부 네트워크에서 작동하는 랩톱 구성을 쉽게 구성하고 사용할 수 있습니다. 이러한 개선된 기능은 사용자 URI의 도메인이 SIP 엔터프라이즈 서버 도메인과 다른 회사에게도 중요합니다. 관리자가 예를 들어 랩톱에서 Communicator를 한 번만 구성하면 사용자는 내부 또는 외부 서버를 기억할 필요가 없고 관리자는 원격 액세스 사용자에 대해 지원할 모든 도메인에 대해 DNS SRV 레코드를 게시할 필요가 없습니다.

Office Communicator 클라이언트를 사용하면 서버 이름을 실제로 입력하지 않고도 적절한 Office Communications Server에 자동으로 연결할 수 있습니다. 클라이언트가 내부 네트워크 내에 있는지 또는 외부에서 작동 중인지에 상관없이 이 기능은 클라이언트를 리디렉션하여 클라이언트가 자체의 Office Communications Server(Standard Edition의 경우) 또는 홈 풀(Enterprise Edition의 경우)에 인증 및 연결할 수 있게 합니다. 이 기능은 DNS에 크게 의존합니다. 이 기능이 작동하려면 적절한 SRV 레코드를 내부 및 외부로 게시해야 합니다.

Office Communicator 클라이언트가 처음으로 시작되어 사용자가 연결하려고 할 때 Office Communicator는 항상 동일한 도메인의 서버 또는 홈 풀에 연결하거나 로그인 주소에 있는 것과 동일한 SIP URI를 사용하여 연결하려고 합니다. 예를 들어 사용되는 로그인 이름이 kim.akers@fabrikam.com이면 Office Communicator는 동일한 DNS 네임스페이스 fabrikam.com에서 홈 풀 또는 Office Communications Server를 검색합니다. 결국 클라이언트를 올바른 도메인의 홈 풀 또는 서버에 대한 FQDN으로 가리키는 DNS SRV 레코드를 사용하면 이 프로세스가 더 간단해집니다. 이 프로세스는 클라이언트가 내부 네트워크에 있든지 또는 외부 네트워크에 있든지 동일하게 작동합니다.

클라이언트는 SRV 레코드 쿼리를 시작하고 기본적으로 항상 TLS를 사용하여 인증하려고 시도합니다. TLS가 실패한 경우에만 다시 TCP(Transmission Control Protocol)를 사용합니다.

• _sipinternaltls._tcp.fabrikam.com
• _sipinternal._tcp.fabrikam.com

이러한 처음 두 개의 DNS 레코드 중 하나가 내부 DNS 네임스페이스에 게시되어 사용 가능해야 합니다. 따라서 클라이언트가 호스트 이름을 반환받는 경우 홈 풀 또는 Office Communications Server에 직접 연결합니다. 그렇지 않은 경우 클라이언트가 현재 내부 네트워크에 없는 것으로 간주하고 쿼리 프로세스를 계속 진행합니다.

• _sip._tls.fabrikam.com
• _sip._tcp.fabrikam.com

이러한 쿼리 중 하나가 성공하면 클라이언트는 액세스 에지 서버의 외부 에지로 리디렉션된 후 내부 홈 풀이나 Office Communications Server로 리디렉션됩니다. 그러나 쿼리가 계속 실패하면 마지막 시도에서 다음 두 가지 예에서처럼 호스트 레코드를 직접 조회하려고 합니다. 설정을 자동으로 구성하려는 이 시도가 실패하면 Office Communicator가 실패하고 사용자의 수동 작업이 필요합니다.

• sip.fabrikam.com
• sipinternal.fabrikam.com