이 문서에서는 Cisco Secure Firewall에서 종속 포털(활성 인증)과 함께 사용할 Microsoft Azure Entra ID의 컨피그레이션에 대해 설명합니다.
Cisco에서는 다음 항목에 대한 지식을 권장합니다.
이벤트 허브 생성을 위해 Azure에서 사용 가능한 표준 가격 책정 계층이 있어야 합니다. 또한 내보내기 제어 기능을 통해 활성화된 Smart Licensing으로 디바이스를 활성화해야 합니다.
이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.
기존의 IP 기반 보안 아키텍처가 동적인 하이브리드 작업 환경에 발맞추는 데 어려움을 겪는 가운데, SAML 통합을 지원하는 Cisco Secure Firewall Active Authentication은 강력한 ID 중심 솔루션을 제공합니다. Microsoft Azure AD(Entra ID)를 중앙 집중식 ID 공급자로 활용함으로써 관리자는 이 구성을 통해 정적 네트워크 규칙을 벗어나 휘발성 네트워크 주소보다는 확인된 사용자 ID를 기반으로 세분화된 액세스 제어를 시행할 수 있습니다. 이러한 통합은 원활한 SSO(Single Sign-On) 및 필수 MFA(Multi-Factor Authentication)를 통해 사용자 환경을 간소화하는 동시에 경계가 없는 네트워크에서 엄격한 가시성 및 정책 시행을 유지하는 통합된 보안 상태를 보장합니다.
EndPoint와 Azure Entra 사이의 종속 포털
참고: 이 실습에서는 클라우드 기반 cdFMC(Firewall Management Center)를 사용합니다. 그러나 온프레미스 FMC의 단계는 동일합니다.
1) Integrations(통합) > Dynamic Attributes Connector(동적 특성 커넥터)를 선택합니다.
Integrations Dynamic Attributes Connector(통합 동적 특성 커넥터)를 선택합니다.
2) Disabled 문자열 옆에 있는 컨트롤을 클릭하여 CSDAC를 활성화합니다.
Cisco Dynamic Attributes 커넥터 활성화
c) CSDAC 활성화가 완료되면 Done(완료)을 클릭합니다.
Cisco Dynamic Attributes 커넥터 상태 활성화
1) Objects(개체) > Add Network(네트워크 추가) > Add Object(개체 추가)를 선택합니다.
새 정규화된 도메인 이름 네트워크 개체 만들기
2) FQDN(Fully Qualified Domain Name)으로 구성된 네트워크 개체의 이름을 지정합니다. FQDN을 입력하고 적절한 라디오 버튼을 클릭하여 네트워크 개체를 FQDN 유형으로 할당합니다. 저장을 클릭합니다.
FQDN 네트워크 개체 변수 구성
1) 여기에 표시된 예에서는 Windows Server 2025를 사용합니다. 필요에 따라 특정 이름 확인 서버에 대한 설명서를 참조하십시오.
Windows Server DNS A 레코드 구성
참고: 액티브 인증을 수행하는 클라이언트는 이 DNS A 레코드를 확인할 수 있어야 합니다.
내부 CA(Certificate Authority)를 활성 인증 컨피그레이션의 PKI(Public Key Infrastructure)로 사용할 수 있습니다. Cisco FMC 및 FTD는 필요한 SSL 가로채기 및 Decrypt-Resign 작업을 수행하기 위해 내부 CA 공개 키 및 페어링된 개인 키를 내부 CA 객체로 업로드해야 합니다. 또한 내부 CA는 활성 인증이 수행되는 클라이언트 브라우저 내에서 신뢰되어야 합니다. 브라우저에서 인증서를 신뢰하는지 확인하는 방법은 클라이언트 브라우저 설명서를 참조하십시오.
1) Objects(개체) > PKI > Internal CAs(내부 CA)를 선택합니다. Import CA(CA 가져오기)를 클릭합니다.
참고: 내부 CA는 FMC에서 직접 생성할 수도 있습니다.
내부 인증 기관을 방화벽 관리 센터로 가져오기
참고: 이 문서의 내용 내에서 이미지의 다양한 필드 값을 다루는 공백이 나타나며 이 문서의 게시물별로 의도적입니다. 실제 값은 구성에 따라 환경에 반영됩니다.
1) SP(서비스 공급자) 인증서는 신뢰할 수 있는 CA(Certificate Authority)에서 서명하고 PKCS#12(.p12) 형식으로 반환해야 합니다.
참고: 이 CA는 내부적으로 서명할 수 있습니다. 유일한 주의 사항은 클라이언트 디바이스에서 내부 CA를 신뢰해야 한다는 것입니다.
1) Devices > Certificates를 선택합니다.
디바이스 및 인증서로 이동
2) Add Certificates(인증서 추가)를 클릭합니다.
새 디바이스 인증서 추가
3) Active Authentication(활성 인증)을 실행하는 드롭다운 목록에서 디바이스를 클릭한 다음 + 아이콘을 클릭하여 새 Certificate Enrollment(인증서 등록)를 생성합니다.
FTD를 선택하고 Add New Certificate Enrollment를 추가합니다.
4) Certificate Enrollment(인증서 등록)의 이름을 지정하고 Enrollment Type(등록 유형) 드롭다운 목록에서 PKCS12 파일을 선택합니다.
인증서 등록 설정 및 유형
5) Browse PKCS12 File(PKCS12 파일 찾아보기)을 클릭하여 PKCS#12 파일을 가져오고 필요한 암호를 입력합니다. 저장을 클릭합니다.
PKCS12 파일 찾아보기 및 가져오기
6) 등록 세부 정보가 정확한지 확인하고 Add(추가)를 클릭합니다.
인증서 등록 세부 정보 확인
7) 가져오기에 진행 중이 반영됩니다.

인증서 가져오기 진행 중 상태
1) Enterprise Applications를 검색하고 클릭합니다.
엔터프라이즈 애플리케이션 검색 및 액세스
2) + New Application을 클릭합니다.
엔터프라이즈 애플리케이션 내에서 새 애플리케이션 선택
3) Microsoft Entra SAML Toolkit을 검색하고 축소판 그림을 클릭합니다.
Microsoft Entra SAML 툴킷 검색 및 선택
4) Microsoft Entra SAML Toolkit Enterprise Application에 이름을 지정하고 Create를 클릭합니다. (Microsoft 참조: Microsoft Entra SAML Toolkit 통합 자습서를 읽어 보십시오.
SAML 툴킷 애플리케이션에 이름 할당
5) 개요 페이지에서 특정 사용자 및 그룹을 SAML 툴킷 엔터프라이즈 애플리케이션에 할당합니다. 이 예에서 테스트 계정(captive-portal-user)은 active-auth-lab 그룹의 멤버입니다.
애플리케이션에 사용자 및 그룹 할당
6) 이 엔터프라이즈 애플리케이션 컨피그레이션은 이후 단계에서 계속됩니다.
1) Entra ID로 다시 이동하고 왼쪽 탐색 메뉴에서 App registrations(앱 등록)를 선택합니다. All applications(모든 애플리케이션) 필터를 클릭하고 Enterprise Application(엔터프라이즈 애플리케이션)에 지정된 이름을 검색합니다. 적절한 애플리케이션을 클릭합니다.
App Registrations And All Applications(앱 등록 및 모든 애플리케이션)로 이동합니다.
2) Enterprise App Registration 아래에서 Essentials 값을 수집하고 기록합니다.
중요: 값 위에 마우스 커서를 올려 놓으면 클립보드에 복사가 표시되고 개요 페이지의 Essentials 아래에 값을 수집합니다.
표시 및 응용 프로그램과 디렉터리 ID 값 수집
3) Add certificate or secret 하이퍼링크를 클릭합니다.
Add Certificate Or Secret 하이퍼링크
4) + 새 클라이언트 암호를 클릭합니다.
새 클라이언트 암호 추가
5) 비밀에 대한 설명을 제공하고 필요에 따라 만료를 조정합니다. Add(추가)를 클릭합니다.
클라이언트 암호에 대한 설명 제공
6) 암호를 복사합니다.
중요: 클립보드에 복사된 비밀 값을 기록해 둡니다.
클라이언트 암호 값 복사
1) 왼쪽의 탐색 메뉴에서 API Permissions(API 권한)를 선택한 다음 + Add a permission(권한 추가)을 클릭합니다.
API 권한 구성
2) Microsoft Graph API를 클릭합니다.
Microsoft Graph API 선택
3) 위임된 사용자에게 권한을 부여합니다. 권한을 읽은 다음 권한 추가를 클릭합니다.
위임된 사용자에게 읽기 권한 부여
4) 응용 프로그램 User.Read.All 권한 부여(확인란 선택)
응용 프로그램 읽기 모든 권한 부여
5) Group.Read.All 확인란을 검색하여 선택하면 Group Read 권한도 부여됩니다. Add permissions(권한 추가)를 클릭합니다.
API 권한 저장
6) 구성된 권한이 일치하는지 확인하고, 해당 권한에 대한 관리 동의를 부여합니다.
권한에 대한 관리 동의 부여
7) 관리자 동의가 부여되면 출력이 표시됩니다.
관리 동의가 부여된 출력
1) Event Hubs를 검색하고 클릭합니다.
이벤트 허브 구성 검색
2) 새 EH 네임스페이스를 만듭니다.
이벤트 허브 네임스페이스 만들기
3) EH 네임스페이스를 구성합니다.
참고: 표준 가격 책정 계층 이상을 선택해야 합니다. 기본 가격 책정 계층은 영역 사용을 차단합니다.
이벤트 허브 고급 설정 및 특정 요구 사항에 대한 적용 가능성에 대한 자세한 내용은 Azure 이벤트 허브 설명서를 참조하십시오.
Review(검토) + Create(생성)를 클릭합니다.
이벤트 허브 네임스페이스 설정 구성
4) 검증이 성공하면 Create(생성)를 클릭합니다.
이벤트 허브 네임스페이스 배포 만들기
5) 구축이 완료되었는지 확인한 후 리소스로 이동을 클릭합니다.
이벤트 허브 네임스페이스 리소스로 이동
1) 왼쪽 탐색 메뉴에서 Settings(설정) > Shared access policies(공유 액세스 정책)를 선택합니다.
공유 액세스 정책으로 이동
2) + Add(추가)를 클릭하고 새 정책 이름을 입력한 다음 Manage(관리) 확인란을 선택합니다. Add SAS Policy(SAS 정책 추가) 메뉴 패널의 하단에서 Create(생성)를 클릭합니다.
새 공유 액세스 정책 추가
공유 액세스 정책 생성
1) 새 공유 액세스 정책을 클릭합니다. eh SAS Policy(EH SAS 정책)가 오른쪽 측면 패널에 나타납니다.
기본 연결 문자열 복사
중요: 기본 연결 문자열을 복사하여 기록합니다.
1) [네임스페이스] 메뉴에서 [엔터티] > [이벤트 허브]를 선택합니다. 새 EH 인스턴스를 생성하려면 + Event Hub를 클릭합니다.
새 이벤트 허브 인스턴스 만들기
2) 새 EH 인스턴스에 이름을 할당한 다음 Review + create를 클릭합니다.
이벤트 허브 인스턴스에 이름 할당
3) 검증이 성공하면 Create(생성)를 클릭하여 Event Hub 인스턴스를 프로비저닝합니다.
이벤트 허브 인스턴스 프로비전
중요: 이벤트 허브 인스턴스 이름을 복사하여 기록해 둡니다.
1) 이전 단계에서 구성한 새 EH 인스턴스를 클릭합니다.
액세스 이벤트 허브 인스턴스 컨피그레이션
2) EH 인스턴스에서 Entities(엔터티) > Consumer groups(소비자 그룹)를 선택하고 새 Consumer group(소비자 그룹)을 만듭니다.
소비자 그룹 생성
3) 소비자 그룹의 이름을 지정하고 Create(생성)를 클릭합니다.
소비자 그룹에 이름 할당
중요: Event Hub 인스턴스 Consumer 그룹 이름을 복사하여 기록합니다.
1) 이 시점에서, 이전 단계의 이 값을 기록한다. 값이 기록되지 않은 경우 해당 값이 수집되는 단계를 참조하십시오.
1) Entra ID 테넌트 구성으로 다시 이동합니다.
Entra ID Tenant Configuration(ID 테넌트 컨피그레이션)을 검색하고 탐색합니다.
2) 왼쪽 메뉴에서 Monitoring(모니터링) > Diagnostic Settings(진단 설정)를 선택합니다.
진단 설정 모니터링
3) Diagnostic settings(진단 설정) > General(일반)을 선택하고 + Add diagnostic settings(진단 설정 추가)를 클릭합니다.
새 진단 설정 추가
4) 진단 설정에 필요한 이름을 지정하고, AuditLogs(감사 로그) 확인란을 선택하여 로깅하고, Stream to an event hub(이벤트 허브에 스트림) 확인란을 선택합니다. 이전 컨피그레이션에서 명시한 값을 참조하고 완료되면 Save(저장)를 클릭합니다.
이벤트 허브에 감사 로그 스트리밍
1) FMC에서 Integrations(통합) > Identity(ID) > Realms(영역)를 선택합니다.
ID 영역 컨피그레이션
2) 영역 추가 드롭다운 목록을 클릭하고 SAML - Azure AD를 선택합니다.
SAML Azure AD 영역 추가
3) Azure 영역에 이름 및 설명을 할당하여 사용을 설명하고 Azure AD를 사용하여 수동으로 인증하거나 Azure AD를 사용하여 종속 포털을 사용하는 것이 구성 유형 드롭다운 목록에서 선택되었는지 확인합니다. Next(다음)를 클릭합니다.
Azure AD 영역 설정 구성
4) 이전에 구성한 FQDN 객체를 Base URL로 선택합니다. 다음과 같이 문자열 형식으로 엔티티 ID를 입력합니다.
https://<fqdn-base-url>/<uniqueSuffix>
기본 URL 및 엔티티 ID 구성, SAML 메타데이터 다운로드
5) Next(다음)를 클릭하여 Realm(영역) 컨피그레이션의 Sequence 3(시퀀스 3)으로 이동합니다.
1) 다시 Azure로 이동하고 Enterprise ID > 관리 > 엔터프라이즈 응용 프로그램을 선택합니다. 이전에 생성한 Microsoft Entra SAML Toolkit Enterprise Application 인스턴스를 검색합니다.
Microsoft Entra SAML 툴킷 애플리케이션 찾기
2) 측면 탐색 메뉴에서 Manage(관리) > Single Sign-On을 선택합니다.
단일 사인온 구성 관리
3) SAML SSO(Single Sign-On) 모드를 클릭합니다.
SAML 단일 사인온 모드 선택
4) Upload metadata file(메타데이터 파일 업로드)을 클릭하고 파란색 폴더 아이콘을 클릭하여 FMC에서 다운로드한 SAML 메타데이터 파일에 대한 로컬 파일 시스템을 찾습니다.
방화벽 관리 센터에서 메타데이터 파일 업로드
5) 업로드가 완료되면 Add를 클릭합니다.
SAML 컨피그레이션 애플리케이션 추가
6) Basic SAML Configuration(기본 SAML 컨피그레이션)의 측면 패널이 나타나고 업로드 및 자동으로 적용되는 FMC에서 생성된 SP 메타데이터 XML 파일에서 식별자(엔티티 ID) 및 ACS URL과 같은 값이 추출됩니다. 그러나 로그인 URL은 채워지지 않으며 저장하기 전에 필요합니다.
기본 SAML 컨피그레이션 추출
7) 지정된 로그인 URL 패턴을 사용하여 값을 복사하여 붙여넣은 다음, 완료 시 상단의 저장을 클릭합니다.
로그온 URL 컨피그레이션 항목
페더레이션 메타데이터 XML 파일 내보내기
1) FMC로 다시 이동합니다. 시퀀스 3의 SAML IdP(Identity Provider) 메타데이터에서 Azure에서 다운로드한 내보낸 페더레이션 메타데이터 XML 파일을 FMC에 업로드하여 필요한 값을 자동으로 채웁니다.
페더레이션 메타데이터 XML 파일 업로드
2) 업로드되면 표시된 대로 값이 채워집니다.
자동으로 채워진 SAML ID 공급자 값
참고: 부분 출력이 이미지에 표시됩니다.
3) 이 시점까지 구현 프로세스 전반에 걸쳐 수집된 값을 입력합니다.
애플리케이션 및 이벤트 허브 정보 입력
입력을 마치면 테스트를 클릭하여 연결을 확인하고 제공된 정보로 Azure에 연결할 수 있는지 확인합니다.
참고: 해당되는 경우, Excluded/Included User Groups(제외된/포함된 사용자 그룹)가 Entra 컨피그레이션과 일치하는지 확인합니다
4) 마법사의 마지막 단계에서 SAML 종속 포털 사용자 시간 초과를 구성할 수 있습니다. 기본값은 1440분입니다.
종속 포털 시간 초과 구성
5) Next(다음)를 클릭하여 계속 진행합니다.
Azure AD 영역 구성을 사용하여 앞으로 이동
6) 마법사가 구현된 구성에 대한 요약을 제공합니다. 입력한 값을 검증하고 확인한 후 요약 끝에 있는 저장을 누릅니다.
영역 구성 요약 저장 버튼
1) Integrations(통합) > Identity(ID) > Realms(영역) 워크플로의 Download Now(지금 다운로드) 버튼을 사용하여 Azure Entra에서 사용자를 다운로드할 수 있는지 확인합니다.
Azure AD에서 사용자 다운로드
2) 대화 프롬프트에 대한 응답으로 Yes(예)를 클릭합니다.
Azure AD에서 사용자 다운로드 확인
3) Notifications(알림) > Tasks(작업)에서 확인한 대로 다운로드 작업에서 사용자 1명과 그룹 1명이 다운로드됩니다.
Azure AD에서 사용자 다운로드를 위한 알림 항목
1) FMC에서 Policies(정책) > Security Policies(보안 정책) > Decryption(해독)을 선택합니다.
암호 해독 정책으로 이동
2) Create New(새로 만들기) 드롭다운 목록을 클릭하고 Decryption Policy (Rule-Based)(암호 해독 정책(규칙 기반)을 선택합니다.
새 규칙 기반 암호 해독 정책 생성
3) 새로운 규칙 기반 암호 해독 정책에 이름 및 설명(원하는 경우)을 지정하고 Outbound Connections (User Protection)(아웃바운드 연결(사용자 보호)) 탭 옵션을 클릭하여 종속 포털 인증(활성 인증)에 필요한 Decrypt-Resign 기능을 구현합니다.
아웃바운드 연결 정책 세부 정보 구현
4) 동일한 대화 상자의 해당 드롭다운 목록에서 이전에 적용된 내부 CA를 선택합니다. Next(다음)를 클릭합니다.
5) 필요에 따라 옵션을 사용자 지정합니다.
암호 해독 정책 옵션 사용자 지정
6) 이 예에서는 필수 Policy Details(정책 세부사항)를 제외하고 기본값이 사용됩니다. Create Policy(정책 생성)를 클릭하여 컨피그레이션 마법사를 완료합니다.
최종 암호 해독 정책 생성
1) 규칙 기반 암호 해독 정책의 기본 레이아웃이 여기에 표시됩니다. 해독 불가 도메인 이름의 사전 할당 목록을 참조하는 규칙 3 및 해독 불가 태그가 지정된 애플리케이션을 참조하는 규칙 6과 같이 기본 활성화된 규칙과 일치하지 않는 트래픽은 규칙 7에서 Decrypt - Resign 작업을 받습니다. 이러한 기본값은 기본 작업과 함께 필요에 따라 수정할 수 있습니다. 기본적으로 다른 규칙과 매칭하지 않는 트래픽은 Do Not Decrypt로 구성됩니다.
검사를 위해 Azure 인증 서비스 트래픽의 암호를 해독해서는 안 되므로 이에 대한 전용 규칙이 만들어집니다. 시작하려면 + Add Rule을 클릭합니다.
규칙 추가 및 기본 규칙 기반 암호 해독 레이아웃 표시
2) 새 암호 해독 정책 규칙 항목에 이름을 지정하고 Action 드롭다운 목록에서 Do not decrypt를 선택한 다음, 덜 구체적인 규칙의 맨 위에 규칙을 놓습니다. 소스/대상 영역도 구현하여 규칙을 더 좁힙니다.
Do Not Decrypt 규칙 구성
3) 규칙을 추가하기 전에 [응용 프로그램] 탭을 클릭하고 Azure 인증 서비스 응용 프로그램을 검색하여 클릭합니다. [규칙에 추가]를 클릭한 다음 [추가]를 클릭합니다.
Azure 인증 서비스 응용 프로그램 규칙 추가
4) Save를 클릭합니다.
암호 해독 정책 저장
1) ID 정책을 생성하려면 Policies > Security Policies > Identity를 선택합니다.
ID 정책 생성
2) 새 ID 정책을 만들고 Add a new policy(새 정책 추가)를 클릭합니다.
새 ID 정책 구성 추가
3) 이름을 할당하고, 해당되는 경우 새 ID 정책에 대한 설명을 할당합니다. 저장을 클릭합니다.
새 ID 정책 이름 지정
1) + Add Rule을 클릭하여 새 규칙을 추가합니다.
새 ID 정책 규칙 추가
2) 새 규칙의 이름을 지정하고, Action 드롭다운 목록에서 Active Authentication을 선택하고, Active Authentication을 수행하기 위해 규칙과 일치해야 하는 특정 영역/네트워크의 범위를 좁힙니다.
활성 인증 규칙 설정 구성
3) Add(추가)를 클릭하기 전에 Rule Editor(규칙 편집기)에서 Realm and Settings(영역 및 설정) 탭을 클릭합니다. 이전 단계에서 구성된 영역이 인증 영역으로 선택되었는지 확인한 다음 Add를 클릭합니다.
Id 규칙에 대한 영역 및 설정 구성
4) 규칙이 추가 및 구성됩니다. 저장을 클릭합니다.
ID 정책 규칙 컨피그레이션 저장
1) Policies > Security Policies > Access Control을 선택하고 FTD가 할당된 Access Control Policy를 클릭합니다.
액세스 제어 정책 컨피그레이션
2) 이전 단계에서 구성한 암호 해독 정책이 액세스 제어 정책에 적용되는지 확인합니다.
액세스 제어에 암호 해독 정책 적용
3) 이전 단계에서 구성한 ID 정책이 액세스 제어 정책에도 적용되는지 확인합니다. 정책 변경 사항을 저장합니다.
액세스 제어에 ID 정책 적용
4) 액티브 인증에 성공한 후 보안 방화벽을 통과하는 클라이언트 데이터 플레인 트래픽을 허용하는 규칙이 있는지 확인합니다. 여기에 표시된 예에서는 랩 환경에 따라 더 넓은 규칙 집합을 사용합니다.
사용자 데이터 플레인 트래픽 규칙 집합
배포되면 트래픽을 전송하는 클라이언트에 Microsoft 로그인 웹 페이지를 통해 Azure Entra를 통한 활성 인증을 수행하도록 프롬프트가 표시됩니다.
여기에 설명된 프로세스에 대한 추가 컨텍스트는 활성 인증(종속 포털)을 위한 Microsoft Azure AD(SAML) 영역 만들기 - 장을 참조하십시오. FMC 디바이스 컨피그레이션 가이드 10.x의 영역.
이 섹션을 사용하여 컨피그레이션이 제대로 작동하는지 확인하십시오.
FMC에서 사용자 세션 및 활동을 검증합니다.
FMC 활성 세션 출력
FMC 사용자 활동 출력
Azure에서 Microsoft Entra 관리 센터로 이동합니다.
Azure Enterprise 관리 센터 엔터프라이즈 앱 탐색
Azure 엔터프라이즈 응용 프로그램 로그인 활동 로그
> debug menu captive-portal 6
SAML passed requests captive-portal 14
SAML failed requests captive-portal 0
SAML passed responses captive-portal 4
SAML failed responses captive-portal 0
Total captive-portal bee-client messages processed 4
Total captive-portal bee-client messages successful 4
Total captive-portal bee-client messages failed 0
Total bee-client reconnects 0
> system support captive-portal-debug
Enable firewall-debug too? [n]: y
Enable identity-debug too? [n]: y
Please specify an IP protocol: tcp
Please specify a client IP address: 192.168.20.200
Please specify a client port:
Please specify a server IP address:
Please specify a server port:
Enable daq-debug too? (WARNING: current packet debug configs and logs will be overwritten) [n]:
Monitoring captive_portal and firewall and identity debug messages
!--- Baseline output pending user Captive Portal authentication
...
192.168.20.200 53650 -> 198.51.100.1 443 6 AS=0 ID=1 GR=1-1 match rule order 1, id 1 action Captive portal, active auth realm id 2
192.168.20.200 53650 -> 198.51.100.1 443 6 AS=0 ID=1 GR=1-1 didn't find active binding, initiating captive portal
192.168.20.200 53650 -> 198.51.100.1 443 6 AS=0 ID=1 GR=1-1 captive portal authentication started
192.168.20.200 53650 -> 198.51.100.1 443 6 AS=0 ID=1 GR=1-1 defer trust until captive portal redirect is sent.
192.168.20.200 53650 -> 198.51.100.1 443 6 AS=0 ID=1 GR=1-1 Current state = S_INIT, Event = EVT_CP_RULE, Next state = S_PENDING_USER
...
!--- Captive Portal probe intercepted and redirected to SAML IdP (generate_204)
...
192.168.20.200 53659 -> 198.51.100.2 80 6 AS=0 ID=1 GR=1-1 AppID session with service_id: 676, url: http://browserportal.example.com
192.168.20.200 53659 -> 198.51.100.2 80 6 AS=0 ID=1 GR=1-1 Current state = S_PENDING_USER, Event = EVT_APPID_HTTP_HEADERS, Next state = S_REDIRECTING
192.168.20.200 53659 -> 198.51.100.2 80 6 AS=0 ID=1 GR=1-1 app event changes: service, client, host, url, user-agent, client-info
192.168.20.200 53659 -> 198.51.100.2 80 6 AS=0 ID=1 GR=1-1 using ipv4 address 192.168.20.1 for redirect
192.168.20.200 53659 -> 198.51.100.2 80 6 AS=0 ID=1 GR=1-1 encrypted redirect url: https://ftd-inside.example.com/+CSCOE+/saml/sp/login?tgname=azure-entra-saml&s=xxxx=http%3A%2F%2Fbrowserportal.example.com%2Fgenerate_204
192.168.20.200 53659 -> 198.51.100.2 80 6 AS=0 ID=1 GR=1-1 Current state = S_REDIRECTING, Event = EVT_FINALIZE, Next state = S_REDIRECTED
...
!--- SAML authentication completes, identity binding created
...
192.168.20.200 54023 -> 198.51.100.2 80 6 AS=0 ID=2 GR=1-1 looked for user_id with realm_id 2 auth_type 2, returning realm_id 2 auth_type 8 user_id 0
192.168.20.200 54023 -> 198.51.100.280 6 AS=0 ID=2 GR=1-1 found active binding for user_id 0 usernames azure-entra-saml\captive-portal-user@onmicrosoft.example.com in realm 2
192.168.20.200 54023 -> 198.51.100.2 80 6 AS=0 ID=2 GR=1-1 IdentityFlowSetupEventHandler Retrieved identity info: user_id 0, username azure-entra-saml\captive-portal-user@onmicrosoft.example.com, authRealmId 2, src sgt 0, src sgt type unknown, dst sgt 0, dst sgt type unknown, deviceType 0, locationIP ::
192.168.20.200 54023 -> 198.51.100.2 80 6 AS=0 ID=2 GR=1-1 New firewall session
192.168.20.200 54023 -> 198.51.100.2 80 6 AS=0 ID=2 GR=1-1 allow action
...
!--- Authenticated binding persists across subsequent, unrelated destinations (no further redirects)
...
192.168.20.200 54024 -> 198.51.100.2 80 6 AS=0 ID=2 GR=1-1 found active binding for user_id 0 usernames azure-entra-saml\captive-portal-user@onmicrosoft.example.com in realm 2
192.168.20.200 54025 -> 198.51.100.1 443 6 AS=0 ID=1 GR=1-1 found active binding for user_id 0 usernames azure-entra-saml\captive-portal-user@onmicrosoft.example.com in realm 2
192.168.20.200 54026 -> 198.51.100.2 80 6 AS=0 ID=1 GR=1-1 found active binding for user_id 0 usernames azure-entra-saml\captive-portal-user@onmicrosoft.example.com in realm 2
192.168.20.200 54027 -> 198.51.100.3 443 6 AS=0 ID=1 GR=1-1 found active binding for user_id 0 usernames azure-entra-saml\captive-portal-user@onmicrosoft.example.com in realm 2
192.168.20.200 19935 -> 198.51.100.4 443 6 AS=0 ID=1 GR=1-1 found active binding for user_id 0 usernames azure-entra-saml\captive-portal-user@onmicrosoft.example.com in realm 2
...
> system support firewall-engine-dump-user-identity-data
Successfully commanded snort.
>
> expert
admin@ftd:~$ sudo su
Password:
root@ftd:/home/admin#
root@ftd:/home/admin# ls -lah /ngfw/var/sf/user_enforcement/user_identity.dump
-rw------- 1 root root 5.6K Oct 7 07:51 /ngfw/var/sf/user_enforcement/user_identity.dump
root@ftd:/home/admin#
root@ftd:/home/admin# less /ngfw/var/sf/user_enforcement/user_identity.dump
...
----------------
IP:USER
----------------
!--- Host IP is aligned with the user authenticated via Captive Portal/Active Authentication
----------------
Host ::ffff:192.168.20.200
----------------
::ffff:192.168.20.200:0 realm 2 type 8, username azure-entra-saml\captive-portal-user@onmicrosoft.example.com
::ffff:192.168.20.200: SXP initialized 0 sgt 0
ABP values: None
-------------------
SXP MAPPING:
-------------------
...
문제: 인증을 시도할 때 클라이언트 브라우저에서 알 수 없는 발급자 오류를 반환합니다.
가능한 원인: 클라이언트 브라우저 내에서 내부 인증 기관을 신뢰할 수 없습니다.
해결: 브라우저 내에서 CA를 신뢰할 수 있는지 확인합니다. 여기에 표시된 예에서는 내부 CA 인증서를 신뢰할 수 있음을 확인합니다.
문제: 클라이언트 브라우저가 종속 포털을 로드하려고 시도하면 기본 URL에 연결하려고 시도하는 동안 기본 URL에 대해 "Server Not Found"가 반환됩니다.
가능한 원인: DNS 연결 또는 DNS 잘못된 컨피그레이션입니다.
해결: 클라이언트에 A 레코드를 확인하도록 구성된 적절한 DNS 서버가 있는지 확인합니다. 서버에 FQDN에 매핑된 A 레코드가 있는지, 그리고 서버에 연결할 수 있으며 응답이 있는지 확인합니다.
| 개정 | 게시 날짜 | 의견 |
|---|---|---|
1.0 |
15-Oct-2026
|
최초 릴리스 |