ADFS 3.0을 사용하여 Cisco Unified Communications Manager에서 SAML SSO 구성

소개

이 문서에서는 Cisco CUCM(Unified Communication Manage), Cisco CUC(Unity Connection), Expressway 제품에서 Windows 2012 R2를 사용하여 ADFS 3.0을 사용하여 Single Sign-On with Active Directory Federation Service(ADFS 3.0)를 구성하는 단계에 대해 설명합니다.Kerberos 구성 단계도 이 문서에 포함되어 있습니다.

사전 요구 사항

요구 사항

Cisco에서는 SSO(Single Sign-On) 및 Windows 제품에 대한 지식을 보유하고 있는 것이 좋습니다.

사용되는 구성 요소

이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.

• CUCM 11.5
• CUC 11.5
• 고속도로 12
• 다음 역할이 있는 Windows 2012 R2 서버:
• Active Directory 인증서 서비스
• Active Directory 페더레이션 서비스

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다.이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다.네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 이해해야 합니다.

구성 사전 확인

ADFS3을 설치하기 전에 다음 서버 역할이 환경에 이미 있어야 합니다.

· 도메인 컨트롤러 및 DNS

· 모든 서버를 포인터 레코드와 함께 A 레코드로 추가해야 합니다(IP 주소를 도메인 또는 호스트 이름으로 확인하는 DNS 레코드 유형).

A 레코드

fhlab.com에서hosts cmpubhcsc, cmsubhcsc, cucpubhcsc, cucsubhcsc, expwyc, expwye, impubhcsc 및 imsubhcsc가 추가되었습니다.

포인터(PTR) 레코드

Jabber Discovery Services에 SRV 레코드가 있어야 함

• 루트 CA(인증서가 엔터프라이즈 CA 서명)

웹 서버 인증서 템플릿을 기반으로 인증서 템플릿을 만들어야 합니다. 이 템플릿은 복제되고 이름이 변경되며, Extensions(확장) 탭에서 Application Policies(애플리케이션 정책)가 수정되어 클라이언트 인증 애플리케이션 정책이 추가됩니다.이 템플릿은 LAB 환경에서 모든 내부 인증서(CUCM, CUC, IMP 및 Expressway Core)에 서명하는 데 필요합니다. 내부 CA는 CSR(Expressway E Certificate Signing Requests)에도 서명할 수 있습니다.

CSR에 서명할 수 있도록 생성된 템플릿을 발행해야 합니다.

CA 인증서 웹에서 이전에 생성한 템플릿을 선택합니다.

CUCM, IMP 및 CUC Multi-Server CSR은 CA에서 생성하고 서명해야 합니다.인증서 용도는 tomcat이어야 합니다.

CA 루트 인증서는 Tomcat Trust에 업로드하고 서명된 인증서는 tomcat에 업로드해야 합니다.

• IIS

그렇지 않은 경우 이 섹션에서는 이러한 역할의 설치를 진행합니다.그렇지 않으면 이 섹션을 건너뛰고 Microsoft에서 ADFS3 다운로드로 직접 진행합니다.

DNS와 함께 Windows 2012 R2를 설치한 후 서버를 도메인 컨트롤러로 승격합니다.

다음 작업은 Microsoft 인증서 서비스를 설치하는 것입니다.

서버 관리자로 이동하여 새 역할을 추가합니다.

Active Directory 인증서 서비스 역할을 선택합니다. 

그리고 이러한 서비스를 먼저 구축합니다. CA(Certificate Authority) 인증서 등록 정책 웹 서비스이러한 두 역할을 설치한 후 이를 구성한 다음 Certificate Enrollment Web Service 및 Certificate Authority 웹 등록을 설치합니다.구성합니다. 

인증 기관을 설치할 때 IIS와 같은 추가 역할 서비스 및 기능도 추가됩니다.

구축에 따라 엔터프라이즈 또는 독립형 을 선택할 수 있습니다.

  

CA Type(CA 유형)에서 Root CA(루트 CA) 또는 Subordinate CA를 선택할 수 있습니다.조직에서 이미 실행 중인 다른 CA가 없는 경우 Root CA를 선택합니다.

다음 단계는 CA에 대한 개인 키를 생성하는 것입니다.

이 단계는 별도의 Windows Server 2012에 ADFS3을 설치하는 경우에만 필요합니다.CA를 구성한 후 IIS용 역할 서비스를 구성해야 합니다.이는 CA의 웹 등록에 필요합니다.대부분의 ADFS 배포의 경우 IIS에서 추가 역할을 사용하려면 응용 프로그램 개발에서 ASP.NET을 클릭하십시오.

서버 관리자에서 웹 서버 > IIS를 클릭한 다음 기본 웹 사이트를 마우스 오른쪽 단추로 클릭합니다.HTTP 외에 HTTPS도 허용하려면 바인딩을 변경해야 합니다.이는 HTTPS를 지원하기 위해 수행됩니다. 

바인딩 편집을 선택합니다.  

새 사이트 바인딩을 추가하고 HTTPS를 유형으로 선택합니다.SSL 인증서의 경우 AD 서버와 동일한 FQDN을 가져야 하는 서버 인증서를 선택합니다. 

모든 필수 구성 요소 역할이 환경에 설치되어 있으므로 이제 ADFS3 Active Directory Federation Services(Windows Server 2012)를 설치할 수 있습니다. 

Server Role(서버 역할)의 경우 Server Manager(서버 관리자) > Manage(관리) > Add Server Roles and Features(서버 역할 및 기능 추가)로 이동한 다음 Active Directory Federation Services(Active Directory Federation Services)를 선택합니다. 이 IDP를 고객 네트워크 내 프라이빗 LAN에 설치하는 경우 선택합니다. 

설치가 완료되면 작업 표시줄이나 시작 메뉴에서 열 수 있습니다. 

ADFS3 초기 컨피그레이션

이 섹션은 새로운 독립 실행형 페더레이션 서버 설치로 이동하지만 도메인 컨트롤러에 설치하는 데 사용할 수도 있습니다 

이미지에 표시된 대로 ADFS 관리 콘솔을 실행하려면 Windows를 선택하고 AD FS Management를 입력합니다.

ADFS 서버 컨피그레이션을 시작하려면 AD FS 3.0 Federation Server Configuration Wizard 옵션을 선택합니다.이러한 스크린샷은 AD FS 3에서 동일한 단계를 나타냅니다.

Create a new Federation Service(새 페더레이션 서비스 생성)를 선택하고 Next(다음)를 클릭합니다.

[독립 실행형 페더레이션 서버]를 선택하고 이미지에 표시된 대로 다음을 클릭합니다.

SSL 인증서의 목록에서 자체 서명 인증서를 선택합니다.페더레이션 서비스 이름이 자동으로 채워집니다.Next(다음)를 클릭합니다.

설정을 검토하고 Next(다음)를 클릭하여 설정을 적용합니다. 

모든 구성 요소가 성공적으로 완료되었는지 확인하고 Close(닫기)를 클릭하여 마법사를 종료하고 기본 관리 콘솔로 돌아갑니다.몇 분 정도 걸릴 수 있습니다.

이제 ADFS가 IdP(Identity Provider)로 효과적으로 활성화되고 구성됩니다. 다음으로, CUCM을 신뢰할 수 있는 신뢰 파트너로 추가해야 합니다.이 작업을 수행하려면 먼저 CUCM Administration에서 일부 컨피그레이션을 수행해야 합니다. 

ADFS를 사용하여 CUCM에서 SSO 구성

LDAP 컨피그레이션

클러스터는 Active Directory와 LDAP로 통합되어야 하며, LDAP 인증을 구성한 후에 더 진행해야 합니다.이미지에 표시된 대로 System(시스템) 탭 > LDAP System(LDAP 시스템)으로 이동합니다.

그런 다음 System(시스템) 탭 > LDAP Directory(LDAP 디렉토리)로 이동합니다.

Active Directory 사용자가 CUCM과 동기화된 후 LDAP 인증을 구성해야 합니다.

CUCM의 최종 사용자는 최종 사용자 프로필에 특정 액세스 제어 그룹을 할당해야 합니다.ACG는 표준 CCM 수퍼 유저입니다.환경이 준비되면 사용자가 SSO를 테스트하는 데 사용됩니다.

CUCM 메타데이터

이 섹션에는 CUCM 게시자에 대한 프로세스가 표시됩니다.

첫 번째 작업은 URL로 이동해야 하는 CUCM 메타데이터를 가져오는 것입니다.https://<CUCM Pub FQDN>:8443/ssosp/ws/config/metadata/sp 또는 System 탭 > SAML Single Sign-on에서 다운로드할 수 있습니다.노드 또는 Cluster Wide별로 수행할 수 있습니다.이 클러스터 전체에서 수행하는 것이 좋습니다.

다음에 필요한 sp_cucm0a.xml과 같은 의미 있는 이름으로 데이터를 로컬에 저장합니다.

ADFS 신뢰 당사자 구성

AD FS 3.0 관리 콘솔로 다시 전환합니다.

Add Relying Party Trust Wizard를 클릭합니다.

Start(시작)를 클릭하여 계속합니다.  

이전에 저장한 federationmedatada.xml 메타데이터 XML 파일을 선택하고 다음을 클릭합니다.

CUCM_Cluster_Wide_Relying_Party_trust를 표시 이름으로 사용하고 Next를 클릭합니다.

첫 번째 옵션을 선택하고 다음을 클릭합니다.

Permit all users to access this relying party(모든 사용자가 이 신뢰 당사자에 액세스하도록 허용)를 선택하고 이미지에 표시된 대로 Next(다음)를 클릭합니다.

컨피그레이션을 검토하고 이미지에 표시된 대로 Next를 클릭합니다.

확인란의 선택을 취소하고 닫기를 클릭합니다. 

보조 마우스 버튼을 사용하여 이미지에 표시된 대로 방금 생성한 Relying Party Trust(당사자 신뢰 신뢰 신뢰)와 Edit Claim Rules(클레임 규칙 수정) 컨피그레이션을 선택합니다.

이미지에 표시된 대로 Add Rule을 클릭합니다. 

Send LDAP Attributes as Claims(LDAP 특성을 클레임으로 보내기)를 선택하고 Next(다음)를 클릭합니다.

다음 매개변수를 구성합니다.

클레임 규칙 이름:이름 ID 

특성 저장소:Active Directory(드롭다운 메뉴 화살표를 두 번 클릭)

LDAP 특성:SAM 계정 이름 

발송 클레임 유형:uid 

FINISH/OK를 클릭하여 계속합니다.

uid는 소문자는 아니며 드롭다운 메뉴에 없습니다.입력합니다.

다른 규칙을 추가하려면 Add Rule을 다시 클릭합니다.

Send Claims Using a Custom Rule을 선택하고 Next를 클릭합니다.

Cluster_Side_Claim_Rule이라는 사용자 지정 규칙을 생성합니다.

여기에서 바로 규칙 창에 이 텍스트를 복사하여 붙여넣습니다.텍스트 편집기에서 편집하면 따옴표가 변경되고 SSO를 테스트할 때 규칙이 실패합니다.

c:[Type ==

"http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", 
Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, 
Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = 
"urn:oasis:names:tc:SAML:2.0:nameid-format:transient", 
Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/namequalifier"] 
= "http://<ADFS FQDN>/adfs/com/adfs/services/trust", 
Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = 
"<CUCM Pub FQDN>");

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", 
Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, 
Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = 
"urn:oasis:names:tc:SAML:2.0:nameid-format:transient", 
Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/namequalifier"] = 
"http://AD.fhlab.com/adfs/services/trust", 
Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = 
"cmpubhcsc.fhlab.com");

Finish를 클릭하여 계속합니다.

이제 ADFS에 두 개의 규칙이 정의되어야 합니다.Apply(적용) 및 OK(확인)를 클릭하여 규칙 창을 닫습니다.

이제 CUCM이 ADFS에 신뢰할 수 있는 신뢰 당사자로 추가되었습니다.

계속하기 전에 ADFS 서비스를 다시 시작하십시오.시작 메뉴 > 관리 도구 > 서비스로 이동합니다.

IDP 메타데이터

IdP에 대한 정보를 CUCM에 제공해야 합니다.이 정보는 XML 메타데이터를 사용하여 교환됩니다.ADFS가 설치된 서버에서 이 단계를 수행해야 합니다.

먼저 Firefox 브라우저를 사용하여 AD FS(IdP)에 연결하여 XML 메타데이터를 다운로드해야 합니다.https://<ADFS FQDN>/FederationMetadata/2007-06/FederationMetadata.xml으로 브라우저를 열고 메타데이터를 로컬 폴더에 저장합니다.

이제 CUCM 컨피그레이션으로 이동하여 Menu(시스템 메뉴) > SAML Single Sign-On 메뉴로 이동합니다.

CUCM Administration(CUCM 관리)으로 돌아가 SYSTEM(시스템) > SAML Single Sign-On을 선택합니다.

Enable SAML SSO(SAML SSO 활성화)를 선택합니다.

경고를 승인하려면 Continue(계속)를 클릭합니다.

SSO 화면에서 찾아보기..를 클릭하여 이전에 저장한 FederationMetadata.xml 메타데이터 XML 파일을 이미지에 표시된 대로 가져옵니다.

XML 파일을 선택하고 열기를 클릭하여 다운로드(Downloads) 아래의 즐겨찾기(Favorites)에서 CUCM에 업로드합니다. 

업로드한 후 Import IdP Metadata(IdP 메타데이터 가져오기)를 클릭하여 IdP 정보를 CUCM으로 가져옵니다.가져오기에 성공했는지 확인하고 Next(다음)를 클릭하여 계속합니다.

Standard CCM Super Users(표준 CCM 수퍼 사용자)에 속하는 사용자를 선택하고 RUN SSO TEST(SSO 테스트 실행)를 클릭합니다.

사용자 인증 대화 상자가 표시되면 적절한 사용자 이름과 비밀번호를 사용하여 로그인합니다.

모든 것이 올바르게 구성된 경우 SSO Test Succeeded!(SSO 테스트 성공!)라는 메시지가 표시됩니다.

CLOSE(닫기) 및 FINISH(마침)를 클릭하여 계속합니다. 

이제 ADFS를 사용하여 CUCM에서 SSO를 활성화하는 기본 컨피그레이션 작업을 완료했습니다. 

CUC에서 SSO 구성

Unity Connection에서 SSO를 활성화하려면 동일한 프로세스를 따를 수 있습니다.

CUC와 LDAP 통합

LDAP 인증을 구성합니다.

음성 메일이 할당될 LDAP에서 사용자 및 SSO 테스트를 위해 서비스될 사용자를 가져옵니다.

이미지에 표시된 대로 Users(사용자) > Edit(편집) > Roles(역할)로 이동합니다.

테스트 사용자에게 시스템 관리자의 역할을 할당합니다.

CUC 메타데이터

이제 CUC 메타데이터를 다운로드하고, CUC에 대해 RelyingPartyTrust를 생성하고, CUC 메타데이터를 업로드하고, ADFS 3.0에서 AD FS에서 규칙을 생성했어야 합니다.

SAML Single Sign-On으로 이동하고 Enable SAML SSO로 이동합니다.

Expressway에서 SSO 구성

Expressway C로 메타데이터 가져오기

https://<ADFS FQDN>/FederationMetadata/2007-06/FederationMetadata.xml으로 브라우저를 열고 메타데이터를 로컬 폴더에 저장합니다.

Configuration(컨피그레이션) > Unified Communications > IDP에 업로드합니다.

Expressway C에서 메타데이터 내보내기

configuration(컨피그레이션) -> Unified Communications -> IDP -> Export SAML Data(SAML 데이터 내보내기)로 이동합니다.

클러스터 모드에서는 SAML에 포함된 자체 서명 인증서(수명이 긴 인증서)를 사용합니다.

메타데이터 및 SAML 요청 서명에 사용

• 클러스터 전체 모드에서 단일 클러스터 전체 메타데이터 파일을 다운로드하려면 Download(다운로드)를 클릭합니다.

• 피어별 모드에서 개별 피어에 대한 메타데이터 파일을 다운로드하려면 피어 옆에 있는 Download를 클릭합니다..zip 파일로 모두 내보내려면 Download All을 클릭합니다.

Cisco Expressway-E에 대한 당사자 Trust 추가

먼저 Expressway-Es에 대한 당사자 트러스트를 만든 다음 ID를 UID 특성으로 보낼 클레임 규칙을 추가합니다.

새로 고침 로그인이 있는 OAuth

Cisco CUCM Enterprise Parameters(Cisco CUCM 엔터프라이즈 매개변수)에서 Refresh(새로 고침) 로그인 플로우 매개변수가 활성화된 OAuth를 확인합니다.Cisco Unified CM Administration(Cisco Unified CM 관리) > Enterprise Parameters(엔터프라이즈 매개변수) > SSO 및 OAuth Configuration(SSO 및 OAuth 컨피그레이션)으로 이동합니다.

인증 경로

• 인증 경로가 "SAML SSO 인증"으로 설정된 경우 SSO가 활성화된 Unified CM 클러스터를 사용하는 Jabber 클라이언트만 이 Expressway에서 MRA를 사용할 수 있습니다.이는 SSO 전용 컨피그레이션입니다. 
• 모든 IP 전화, 모든 TelePresence 엔드포인트 및 SSO에 대해 구성되지 않은 Unified CM 클러스터에 속한 Jabber 클라이언트에 대한 Expressway MRA를 지원하려면 인증 경로가 UCM/LDAP 인증을 포함해야 합니다. 
• 하나 이상의 Unified CM 클러스터가 Jabber SSO를 지원하는 경우 "SAML SSO 및 UCM/LDAP"를 선택하여 SSO 및 기본 인증을 모두 허용합니다. 

SSO 아키텍처

SAML은 XML 기반 개방형 표준 데이터 형식으로서 관리자가 정의된 Cisco 협업 애플리케이션 세트에 로그인한 후 해당 애플리케이션 중 하나에 원활하게 액세스할 수 있도록 합니다.SAML SSO는 SAML 2.0 프로토콜을 사용하여 Cisco 협업 솔루션에 대해 도메인 간 및 제품 간 Single Sign-On을 제공합니다. 

온프레미스 로그인 흐름

MRA 로그인 흐름 

OAuth

OAuth는 권한 부여를 지원하는 표준입니다.사용자를 인증하려면 먼저 사용자를 인증해야 합니다.권한 부여 코드 부여 흐름은 클라이언트가 리소스에 액세스하기 위해 토큰을 가져오고 새로 고치는 방법(Unified CM, IM&P, Unity 및 Expressway 서비스)을 제공합니다. 이 흐름은 리디렉션을 기반으로 하므로 클라이언트가 사용자가 제어하는 HTTP 사용자 에이전트(웹 브라우저)와 상호 작용할 수 있어야 합니다.클라이언트는 HTTPS를 사용하여 권한 부여 서버에 초기 요청을 합니다.OAuth 서버는 사용자를 인증 서비스로 리디렉션합니다.SAML SSO가 활성화된 경우 Unified CM 또는 외부 IdP에서 실행될 수 있습니다.사용 중인 인증 방법에 따라 최종 사용자에게 웹 페이지 보기가 나타나 자신을 인증할 수 있습니다.(Kerberos 인증은 웹 페이지를 표시하지 않는 예입니다.) 암시적 부여 흐름과 달리, 성공적인 인증 코드 부여 플로우는 OAuth 서버에서 웹 브라우저에 "Authorization Code"를 발급하게 됩니다.이 코드는 일회성 단기간 고유 코드로, 웹 브라우저에서 클라이언트로 다시 전달됩니다.클라이언트는 이 "권한 부여 코드"를 사전 공유 암호와 함께 권한 부여 서버에 제공하고, Exchange에서 "액세스 토큰" 및 "토큰 새로 고침"을 수신합니다.이 단계에서 사용된 클라이언트 암호는 권한 부여 서비스에서 등록 및 인증 된 클라이언트만 사용하도록 제한할 수 있습니다.토큰은 다음과 같은 용도로 사용됩니다. 

토큰 액세스/새로 고침

액세스 토큰:이 토큰은 권한 부여 서버에서 발급됩니다.클라이언트는 해당 서버의 보호된 리소스에 액세스해야 할 때 리소스 서버에 토큰을 제공합니다.리소스 서버에서 토큰을 확인하고 토큰을 사용하여 연결을 신뢰할 수 있습니다.(Cisco 액세스 토큰은 기본적으로 수명 60분으로 설정) 

토큰 새로 고침:이 토큰은 권한 부여 서버에서 다시 발급됩니다.클라이언트는 액세스 토큰이 만료되었거나 만료될 때 클라이언트 암호와 함께 이 토큰을 권한 부여 서버에 제공합니다.새로 고침 토큰이 여전히 유효한 경우 권한 부여 서버는 다른 인증 없이 새 액세스 토큰을 발급합니다.(Cisco Refresh 토큰은 기본적으로 60일의 수명을 갖습니다.) 새로 고침 토큰이 만료된 경우 새 토큰을 얻으려면 새 전체 OAuth 권한 부여 코드 부여 흐름을 시작해야 합니다. 

OAuth 권한 부여 코드 권한 부여 플로우가 더 좋음

암시적 부여 흐름에서 액세스 토큰은 HTTP 사용자 에이전트(브라우저)를 통해 Jabber 클라이언트에 전달됩니다. 권한 부여 코드 부여 흐름에서 액세스 토큰은 권한 부여 서버와 Jabber 클라이언트 간에 직접 교환됩니다.시간 제한 고유 권한 부여 코드를 사용하여 권한 부여 서버에서 토큰을 요청합니다.액세스 토큰의 직접 교환은 더 안전하며 위험 노출을 줄입니다. 

OAuth 권한 부여 코드 권한 부여 흐름은 새로 고침 토큰 사용을 지원합니다.따라서 최종 사용자는 자주 재인증할 필요가 없으므로(기본적으로 60일) 더 나은 환경을 제공할 수 있습니다. 

Kerberos 구성

Windows 인증 선택

IIS(인터넷 정보 서비스) 관리자 > 사이트 > 기본 웹 사이트 > 인증 > Windows 인증 > 고급 설정.

1. Enable Kernel-mode authentication(커널 모드 인증 활성화)을 선택 취소합니다.

2. 확장된 보호가 해제되어 있는지 확인합니다.
   
   

ADFS는 Kerberos NTLM을 모두 지원합니다.

모든 비 Windows 클라이언트는 Kerberos를 사용할 수 없고 NTLM을 사용할 수 없으므로 AD FS 버전 3.0이 Kerberos 프로토콜과 NTLM(NT LAN Manager) 프로토콜을 모두 지원하는지 확인하십시오.

오른쪽 창에서 Providers(공급자)를 선택하고 Enabled Providers(활성화된 공급자) 아래에 Negotiate(협상) 및 NTLM이 있는지 확인합니다.

Microsoft Internet Explorer 구성

Internet Explorer > Advanced > Enable Integrated Windows Authentication(통합 Windows 인증 활성화)이 선택되어 있는지 확인합니다.

Security(보안) > Intranet zones(인트라넷 영역) > Sites(사이트)에서 ADFS URL 추가

보안 > 신뢰할 수 있는 사이트에 CUCM, IMP 및 Unity 호스트 이름 추가

사용자 인증 

Internet Explorer > 보안 > 로컬 인트라넷 > 보안 수준에 대한 이 영역 > 사용자 지정 수준 > 사용자 인증 - 로그온 > 자동 로그온을 인트라넷 영역에서 확인하십시오.

SSO에서 Jabber 로그인

Cisco Jabber에는 컨피그레이션 변경이 필요하지 않습니다.Unified CM이 외부 IdP와 함께 SAML SSO를 사용하도록 구성된 경우 Unified CM 로그인 화면이 아닌 IdP의 로그인 화면이 표시될 수 있습니다. 

문제 해결

학습한 대부분의 교훈은 랩 설정 중에 있었습니다.

Internet Explorer(IE)

Jabber SSO를 테스트하기 위해 IE 브라우저의 SSO를 사용하여 CUCM/IM&P에 로그인할 수 있는지 확인합니다.

IE에 추가하는 사이트

IE의 인터넷 옵션을 클릭하고 보안 탭으로 이동합니다.Local Intranet(로컬 인트라넷) > Sites(사이트) > Advanced(고급)를 클릭합니다. 영역에 웹 사이트를 추가합니다(예: IDP FQDN을 사이트에 추가).

동기화 중단 문제

동기화 중단 오류가 발생하면 다음과 같은 오류가 발생합니다.

잘못된 SAML 응답입니다.이는 Cisco Unified Communications Manager와 IDP 서버 간에 시간이 동기화되지 않은 경우 발생할 수 있습니다.두 서버 모두에서 NTP 컨피그레이션을 확인하십시오.CLI에서 "utils ntp status"를 실행하여 Cisco Unified Communications Manager에서 이 상태를 확인합니다.CUCM과 IdP 간에 시간 불일치가 있는 경우 다음 오류가 발생합니다."잘못된 SAML 응답입니다." 이 오류는 CUCM과 IdP 서버 간에 시간이 동기화되지 않은 경우 발생할 수 있습니다.SAML SSO가 작동하려면 올바른 NTP 설정을 설치하고 IdP와 Unified Communications 애플리케이션의 시간 차이가 3초를 초과하지 않는지 확인해야 합니다.

사용자가 서버 동기화 문제의 영향을 받지 않도록 하려면 지침에 따라 "NotBefore" 속성에서 2분 이상의 기울기를 설정하십시오.

• ADFS에서 Powershell을 엽니다.

• Powershell에서 다음 명령을 실행하여 현재 NotBeforeSkew를 확인합니다.

Get-ADFSRelyingPartyTrust -identifier "application FQDN"

Get-ADFSRelyingPartyTrust -identifier "cmpubhcsc.fhlab.com" 

* 이제 NotBeforeSkew를 "3"으로 설정해야 합니다.

참고:IDP에서 SP(예: CUCM)로 메타데이터를 가져와야 할 수도 있습니다.

토큰 취소 

https://
     
     
       :8443/ssosp/token/revoke?user_id= 
       
     

https://10.89.228.146:8443/ssosp/token/revoke?user_id=farfar

{"revoked_tokens":{"status":"success","user_id":"farfar","clientID_tokens":
[{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"fa8ff04aabb4a40bc493f810f9fff09a8f735d24fb05df7c9191f294611710a3"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"9ecf6a5092f1167df085f018320e2135b487f585b9cbb3e59474a0643f1a961f"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"30ab864ce41c78b9b4324a46f865dd47add4b16d7717986d715405496119bc87"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"33d025dd7b88fefe99173757a54ada771821d763a23b71cc9ca233e1c91ffd65"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"a5f0d293d3dbbbe4ef1af9379a78df04ed9a168c450de42982e3796cef758c0f"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"252912f2af65346f7ec2887505aef7d0ee2cd918f0253662b9b53ebf45e490e8"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"28c33fcbbc4d47bc6d658855f0699bbe1b3c264c0ed7a04eedc578f6b89fd4de"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"cb5269c40cdf4cc4e2e0a0f520d719851f132691d609ffe65c143952a3f7d2d7"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"acd338a0858c8f140866962e1150bcfd1768b3d8fd959700ed70ea5bff571e83"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"3acee9b52c039e58a0be060c20b8134aea5445ba141d6daedc9fb2366e0eb4d0"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"4a4ac2e56c4663ff20797228b3e67511a56ae3fd1f831303df3642206f8a9742"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"db9ae2351f51e85a01a0dc64b35fa75f052eaa6b3793a29f9dfdb86d589dc97a"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"1118b7fbcaa407541dc8e21ed70ccc581f3e7f58a31fdb94c637d7ac1279a6b8"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"2f33962f1671acc9c7acfb6cff6dff3d9ddf7e2df0a5d7747020347c08e8f18a"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"70a46c24974499c1f87b1b167795c4654460e665f2f5f1696b0a93e2887ae442"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"c05fb1c913a0cbd2984d370365d085ad8315b916a5651511401a695d17129584"},
{"client_id":"C1b4b988f3efa1c3fc97d0d0a36f6b97f244b4fafe55e8d9d78774e305bae9ab1",
"refresh_token":"47ba99793ededfe1cba3f0b83a2738c0a79f1833979ad3c6c362291f92f8fdf8

사용자가 Jabber를 사용하지 못하도록 수동 LDAP 동기화를 수행하거나 데이터베이스에서 사용자를 삭제합니다.Jabber 클라이언트가 CUCM의 UDS 서비스에 유효한 액세스 또는 새로 고침 토큰을 제시하더라도 사용자는 CUCM 사용자 데이터베이스에서 "active"여야 인증됩니다.

Refresh Token expiry timer Enterprise 매개변수를 변경하면 해당 CUCM 클러스터에서 발급한 모든 Refresh Tokens가 자동으로 취소됩니다.

부트스트랩 파일

Jabber 사용자는 온프레미스 IM&P(Instant Messaging and Presence) 서버 대신 인증을 위해 WebEx Connect 클라우드로 전달되거나 MRA(Mobile and Remote Access)용으로 구성된 Expressway(Collaboration Edge)를 통해 전달됩니다.

Jabber-bootstrap.properties 파일 @ C:\ProgramData\Cisco Systems\Cisco Jabber file we can exclude webex 

서비스검색제외서비스:WebEx

SSO 실패 MSIS7066

SSO가 실패한 시나리오를 발견했습니다.Firefox 브라우저에서 CUCM에 대한 SSO 로그인 테스트를 수행할 때 IdP로 리디렉션되고 자격 증명을 입력했지만 CUCM에 다음 오류가 표시됩니다.

응답에 잘못된 상태 코드가 있습니다.이는 IDP의 구성 오류 때문일 수 있습니다.IDP 로그 및 컨피그레이션을 확인하십시오.

아래 위치에서 ADFS(예: IDP) 이벤트 뷰어를 살펴보았습니다.

이벤트 뷰어 -> 애플리케이션 및 서비스 로그 -> AD FS -> 관리

다음은 Error(오류)의 일부입니다.

예외 정보:

Microsoft.IdentityServer.RequestFailedException:MSIS7066:요청에 대한 인증에 실패했습니다.—> System.Security.SecurityException:사용자 이름 또는 암호가 잘못되었습니다.

도메인 컨트롤러의 관리자 자격 증명이 변경되었지만 ADFS 서비스가 업데이트되지 않았습니다.

1. 서비스 구성 창을 엽니다(Windows 제어판 > 관리 도구 또는 서비스를 입력할 때 시작 메뉴에서 액세스할 수 있음).

2. 서비스(Active Directory Federation Services)를 찾아 두 번 클릭하여 해당 속성을 열거나 마우스 오른쪽 단추를 클릭하고 속성을 선택합니다.