ScanSafe/Cloud Web Security 컨피그레이션으로 웹 리디렉션을 위한 ISR IP Acceptions and LDAP
목차
소개
이 문서에서는 Cisco G2 Series ISR(Integrated Services Router)을 구성하는 방법에 대해 설명합니다. ISR의 인증 프록시에 IP Admission 및 LDAP(Lightweight Directory Access Protocol) 컨피그레이션을 간단히 사용할 수 있지만 일반적으로 Cisco CWS(Cloud Web Security) 리디렉션 기능과 함께 사용됩니다.따라서 이 문서는 ISR에 대한 CWS 리디렉션 구성 및 문제 해결 설명서를 보완하기 위한 참조용입니다.
사전 요구 사항
요구 사항
Cisco에서는 이 문서에 설명된 구성을 시도하기 전에 시스템이 이러한 요구 사항을 충족하도록 권장합니다.
- ISR은 버전 15.2(1)T1 이상을 실행해야 합니다.
- 시스템에 Cisco IOS®(범용)에서 사용할 수 있는 SEC(Security Feature Set) 라이센스가 있는 이미지가 있어야 합니다.
- AD(Active Directory) 도메인의 클라이언트 워크스테이션에는 웹 브라우저를 통해 액티브 인증을 수행할 수 있는 기능이 있어야 합니다.
- CWS 구독이 있어야 합니다.
사용되는 구성 요소
이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.
- Internet Explorer, Google Chrome, Mozilla Firefox(투명 NT LAN Manager(NTLM) 인증을 위한 추가 구성 필요)
- Cisco G2 800, 1900, 2900 및 3900 Series ISR
- Microsoft Windows AD 도메인 컨트롤러(ADDC)
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다.이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다.현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.
배경 정보
네트워크에 Cisco ASA(Adaptive Security Appliances)가 없는 Cisco G2 Series ISR을 설치하는 많은 관리자는 웹 필터링에 CWS 솔루션을 활용하기 위해 ISR CWS(이전의 ScanSafe) 리디렉션 기능을 활용할 수 있습니다.또한 대부분의 관리자는 CWS 포털의 웹 필터링 정책에 대한 사용자 또는 그룹 기반 정책 시행을 위해 CWS 타워에 사용자 ID 정보를 전송하기 위해 현재 AD 인프라를 활용하고자 합니다.
전체적인 개념은 몇 가지 차이점과 함께 ASA와 CDA(Context Directory Agent)의 통합과 유사합니다.가장 큰 차이점은 ISR은 수동 사용자-IP 매핑 데이터베이스를 실제로 유지 관리하지 않으므로 사용자는 ISR을 전송하고 사용자 또는 그룹 정보를 CWS 포털에 전송하기 위해 어떤 유형의 인증을 통과해야 한다는 것입니다.
이 문서에 설명된 컨피그레이션의 CWS 리디렉션 부분은 비교적 간단하지만, 일부 관리자는 인증 부분을 구성하려고 시도하는 데 어려움을 겪을 수 있습니다.이 부분은 LDAP 서버 및 구성해야 하는 AAA(Authentication, Authorization, and Accounting) 인증 문을 참조하는 ip admission 명령과 함께 작동합니다.이 문서의 목적은 네트워크 운영자에게 Cisco G2 Series ISR에서 이 구성의 IP Acceptions 및 LDAP 부분을 구성하거나 트러블슈팅하기 위한 포괄적인 참조 소스를 제공하는 것입니다.
구성
Cisco ISR을 구성하려면 이 섹션에 설명된 정보를 사용하십시오.
네트워크 다이어그램
LDAP 구성
AAA 서버의 LDAP 속성을 구성하려면 다음 단계를 완료합니다.
- 사용자가 입력한 사용자 이름이 AD의 sAMAccountName 속성과 일치하도록 강제로 LDAP 특성 맵을 구성합니다.
C-881(config)#ldap attribute-map ldap-username-map map type sAMAccountName
username
C-881(config-attr-map)#map type sAMAccountName username
show ldap attributes 명령을 사용하여 LDAP 특성 및 관련 AAA 특성 목록을 볼 수도 있습니다. - LDAP 서버 그룹을 구성합니다.
C-881(config)#aaa group server ldap LDAP_GROUP
C-881(config-ldap-sg)#server DC01 - LDAP 서버를 구성합니다.
C-881(config)#ldap server DC01
C-881(config-ldap-server)# ipv4 10.10.10.150
C-881(config-ldap-server)#attribute map ldap-username-map
C-881(config-ldap-server)# bind authenticate root-dn CN=Csco_Service,CN=Users,
DC=lab,DC=cisco,DC=com password Cisco12345!
C-881(config-ldap-server)#base-dn DC=lab,DC=cisco,DC=com
C-881(config-ldap-server)#search-filter user-object-type top
C-881(config-ldap-server)#authentication bind-first
사용자 지정 검색 필터를 구현해야 하는 경우가 아니면 일반적으로 이 컨피그레이션을 수정할 필요가 없습니다.LDAP에 대해 잘 알고 이 정보를 올바르게 입력하는 방법을 알고 있는 관리자만 맞춤형 검색 필터를 활용해야 합니다.사용해야 하는 검색 필터에 대해 잘 모르는 경우 설명된 필터를 사용합니다.일반 AD 환경에서 사용자를 찾습니다.
LDAP 컨피그레이션의 또 다른 부분에서는 bind-authenticate-root-dn 및 base-dn 명령에 필요한 DN(Distinguished Names)을 자세히 살펴봅니다.LDAP 서버에 나타나는 대로 정확히 입력해야 합니다. 그렇지 않으면 LDAP 쿼리가 실패합니다.또한 base-dn 명령은 인증된 모든 사용자가 상주하는 LDAP 트리의 최하위 부분이어야 합니다.
이전 컨피그레이션에서 base-dn 명령이 수정되는 시나리오는 다음과 같습니다.
base-dn OU=TestCompany,DC=lab,DC=cisco,DC=com
이 경우 LDAP 서버는 OU(TestCompany Organizational Unit) 및 그 내의 하위 개체만 검색하므로 CN=Users,DC=lab,DC=cisco,DC=com에 포함된 사용자에 대한 쿼리는 결과를 반환하지 않습니다.따라서 이러한 사용자는 TestCompany OU 또는 해당 하위 트리로 이동될 때까지 또는 base-dn 명령이 쿼리에 포함되도록 변경될 때까지 항상 인증에 실패합니다.
AAA 구성
이제 LDAP 서버가 구성되었으므로 IP Admission 프로세스에서 사용되는 해당 AAA 문에서 해당 서버를 참조해야 합니다.
C-881(config)#aaa authentication login SCANSAFE_AUTH group LDAP_GROUP
C-881(config)#aaa authorization network SCANSAFE_AUTH group LDAP_GROUP
IP 허용 구성
IP Admission(IP 허용) 부분은 사용자에게 인증을 요청하는 프로세스를 트리거한 다음(또는 투명 인증을 수행), 사용자 자격 증명 및 컨피그레이션에 정의된 AAA 서버를 기반으로 LDAP 쿼리를 수행합니다.사용자가 성공적으로 인증되면 콘텐츠 스캔 프로세스에 의해 사용자 ID 정보가 수집되어 리디렉션된 흐름과 함께 CWS 타워로 전송됩니다.IP Admission 프로세스는 라우터의 인그레스 인터페이스에 ip admission name 명령을 입력할 때까지 활성화되지 않습니다.따라서 이 컨피그레이션 부분은 트래픽에 영향을 미치지 않고 구현할 수 있습니다.
C-881(config)#ip admission virtual-ip 1.1.1.1 virtual-host ISR_PROXY
C-881(config)#ip admission name SCANSAFE_ADMISSION ntlm
C-881(config)#ip admission name SCANSAFE_ADMISSION method-list authentication
SCANSAFE_AUTH authorization SCANSAFE_AUTH
IP 허용 사용
다음은 IP Admission을 활성화하는 데 사용되는 컨피그레이션입니다.
C-881(config)#int vlan301 (internal LAN-facing interface)
C-881(config-if)#ip admission SCANSAFE_ADMISSION
인증에서 내부 호스트 제외
일부 관리자는 여러 가지 이유로 인증 프로세스에서 일부 내부 호스트를 제외하고자 할 수 있습니다.예를 들어, NTLM 또는 기본 인증을 지원하지 않는 내부 서버 또는 장치가 IP 가입 프로세스의 영향을 받는 것은 바람직하지 않을 수 있습니다.이러한 경우 특정 호스트 IP 또는 서브넷이 IP Admission을 트리거하지 않도록 IP Admission 컨피그레이션에 ACL(Access Control List)을 적용할 수 있습니다.
이 예에서 내부 호스트 10.10.10.150은 인증 요구 사항에서 제외되지만 다른 모든 호스트에는 인증이 계속 필요합니다.
C-881(config)#ip access-list extended NO_ADMISSION
C-881(config-ext-nacl)#deny ip host 10.10.10.150 any
C-881(config-ext-nacl)#permit ip any any
C-881(config)#ip admission name SCANSAFE_ADMISSION ntlm list NO_ADMISSION
ISR에서 HTTP 서버 활성화
HTTP 세션을 가로채고 인증 프로세스를 시작하려면 HTTP 서버를 활성화해야 합니다.
Ip http server
Ip http secure-server
CWS 리디렉션 구성
다음은 CWS 리디렉션을 위한 기본 요약 컨피그레이션입니다.
parameter-map type content-scan global
server scansafe primary name proxy139.scansafe.net port http 8080 https 8080
server scansafe secondary name proxy187.scansafe.net port http 8080 https 8080
license 0 DE749585HASDH83HGA94EA8C369
source interface Vlan302
user-group DEFAULT_GROUP username DEFAULT_USER
server scansafe on-failure allow-all
interface Vlan302 (egress interface towards Internet)
content-scan out
전체 샘플 구성
이 섹션에서는 이전 섹션에 대한 전체 컨피그레이션의 예를 제공합니다.
LDAP
aaa group server ldap LDAP_GROUP
server DC01
ldap attribute-map ldap-username-map
map type sAMAccountName username
ldap server DC01
ipv4 10.10.10.150
attribute map ldap-username-map
bind authenticate root-dn CN=Csco_Service,CN=Users,DC=lab,DC=cisco,DC=com
password Cisco12345!
base-dn dc=lab,dc=cisco,dc=com
search-filter user-object-type top
authentication bind-first
AAA
aaa new-model
aaa authentication login SCANSAFE_AUTH group LDAP_GROUP
aaa authorization network SCANSAFE_AUTH group LDAP_GROUP
IP 허용
ip admission virtual-ip 1.1.1.1 virtual-host ISR_PROXY
ip admission name SCANSAFE_ADMISSION ntlm
ip admission name SCANSAFE_ADMISSION method-list authentication
SCANSAFE_AUTH authorization SCANSAFE_AUTH
interface Vlan301
ip admission SCANSAFE_ADMISSION
HTTP 서버
ip http server
Content-Scan 및 CWS
parameter-map type content-scan global
server scansafe primary name proxy139.scansafe.net port http 8080 https 8080
server scansafe secondary name proxy187.scansafe.net port http 8080 https 8080
license 0 DE13621993BD87B306B5A5607EA8C369
source interface Vlan302
user-group DEFAULT_GROUP username DEFAULT_USER
server scansafe on-failure allow-all
interface Vlan302
content-scan out
AD에서 DN 개체 결정 - ADSI 편집
필요한 경우 사용자 또는 그룹 검색 기반에서 사용할 DN을 찾기 위해 AD 구조를 찾아볼 수 있습니다. 관리자는 AD 도메인 컨트롤러에 내장된 ADSI Edit라는 도구를 사용할 수 있습니다.ADSI Edit를 열려면 Start > Run on the AD domain controller를 선택하고 adsiedit.msc를 입력합니다.
ADSI Edit(ADSI 편집)이 열리면 OU, 그룹 또는 사용자와 같은 개체를 마우스 오른쪽 버튼으로 클릭하고 Properties(속성)를 선택하여 해당 개체의 DN을 확인합니다.그런 다음 DN 문자열을 쉽게 복사하여 라우터 컨피그레이션에 붙여넣어 입력 오류를 방지할 수 있습니다.이 그림에서는 프로세스를 보여 줍니다.
인증 방법
IP Admission(IP 허용)을 사용하는 네 가지 유형의 인증 방법이 있으며, 특히 투명 NTLM과 패시브 NTLM의 차이점은 종종 잘못 인식됩니다.다음 섹션에서는 이러한 유형의 인증 간의 차이점을 설명합니다.
활성 NTLM
투명 NTLM 인증이 실패할 경우 활성 NTLM 인증 방법은 사용자에게 인증을 요청하는 프롬프트를 표시합니다.일반적으로 클라이언트 브라우저가 통합 Microsoft Windows 인증을 지원하지 않거나 사용자가 로컬(도메인이 아닌) 자격 증명을 사용하여 워크스테이션에 로그인했기 때문입니다.활성 NTLM 인증은 제공된 자격 증명이 올바른지 확인하기 위해 도메인 컨트롤러에 대한 LDAP 쿼리를 수행합니다.
투명 NTLM
투명 NTLM 인증은 사용자가 도메인 자격 증명을 사용하여 워크스테이션에 로그인하고 해당 자격 증명이 브라우저에서 IOS 라우터로 투명하게 전달될 때 발생합니다.그런 다음 IOS 라우터는 사용자 자격 증명을 검증하기 위해 LDAP 쿼리를 수행합니다.이 기능은 일반적으로 이 기능에 가장 적합한 인증 형식입니다.
기본 인증(일반 텍스트로 HTTP를 통해)
이 인증 형식은 일반적으로 NTLM 인증이 실패하거나 Macintosh, Linux 기반 디바이스 또는 모바일 디바이스와 같은 클라이언트에서 사용할 수 없는 경우 대체 메커니즘으로 사용됩니다.이 방법을 사용하면 HTTP Secure 서버가 활성화되지 않은 경우 이러한 자격 증명은 일반 텍스트로 HTTP를 통해 전달됩니다(매우 안전하지 않음).
수동 NTLM
패시브 NTLM 인증은 사용자로부터 자격 증명을 요청하지만 도메인 컨트롤러에 대해 사용자를 실제로 인증하지는 않습니다.이렇게 하면 도메인 컨트롤러에 대한 쿼리가 실패할 경우 LDAP 관련 문제를 방지할 수 있지만 환경의 사용자도 보안 위험에 노출됩니다. 투명 인증이 실패하거나 불가능한 경우 사용자에게 자격 증명을 입력하라는 메시지가 표시됩니다.그러나 사용자는 CWS 타워에 전달되는 모든 자격 증명을 입력할 수 있습니다.따라서 정책이 적절하게 적용되지 않을 수 있습니다.
예를 들어, 사용자 A는 Firefox를 사용할 수 있습니다(기본적으로 추가 구성 없이 투명 NTLM을 허용하지 않음). 사용자 B의 사용자 이름을 비밀번호와 함께 입력하면 사용자 B에 대한 정책이 사용자 A에 적용됩니다.사용자가 모두 투명 NTLM 인증을 지원하는 브라우저를 사용하도록 강요된 경우 위험 노출을 줄일 수 있지만, 대부분의 경우 수동 인증을 사용하지 않는 것이 좋습니다.
활성 NTLM 인증을 위한 메시지 시퀀스
다음은 활성 NTLM 인증 방법에 대한 전체 메시지 시퀀스입니다.
Browser --> ISR : GET / google.com
Browser <-- ISR : 302 Page moved http://1.1.1.1/login.html
Browser --> ISR : GET /login.html 1.1.1.1
Browser <-- ISR : 401 Unauthorized..Authenticate using NTLM
Browser --> ISR : GET /login.html + NTLM Type-1 msg
ISR --> AD : LDAP Bind Request + NTLM Type-1 msg
ISR은 데이터 변경 없이 HTTP에서 LDAP로 Type-1 메시지를 바이트 단위로 복사합니다.
ISR <-- AD : LDAP Bind Response + NTLM Type-2 msg
Browser <-- ISR : 401 Unauthorized + NTLM Type-2 msg
Type-2 메시지는 LDAP에서 HTTP로 바이트 단위로 복사됩니다.따라서 PCAP에서는 1.1.1.1에서 시작된 것으로 보이지만 실제 내용은 AD에서 가져온 것입니다.
Browser --> ISR : GET /login.html + NTLM Type-3 msg
ISR --> AD : LDAP Bind Request + NTLM Type-3 msg
ISR <-- AD : LDAP Bind response - Success
Browser <-- ISR : 200OK + redirect to google.com
활성 NTLM이 구성되면 NTLM 교환 중에 ISR이 방해되지 않습니다.그러나 패시브 NTLM이 구성된 경우 ISR은 자체 Type-2 메시지를 생성합니다.
다음을 확인합니다.
현재 이 구성에 대해 사용 가능한 확인 절차가 없습니다.
문제 해결
이 섹션에서는 컨피그레이션 문제를 해결하는 데 사용할 수 있는 정보를 제공합니다.
명령 표시
컨피그레이션을 트러블슈팅하기 위해 다음 show 명령을 사용할 수 있습니다.
- IP 허용 캐시
- ip 승인 상태 표시
- ip admission 통계 표시
- ldap 서버 모두 표시
디버그 명령
컨피그레이션 문제를 해결하기 위해 사용할 수 있는 몇 가지 유용한 디버그 명령은 다음과 같습니다.
- debug ldap all - 이 명령을 사용하여 인증이 실패한 이유를 검색할 수 있습니다.
- debug ip admission detail - 이 명령은 매우 자세한 정보이며 CPU를 많이 사용합니다.Cisco에서는 IP 승인을 트리거하는 단일 테스트 클라이언트에서만 사용할 것을 권장합니다.
- debug ip admission ntlm - 이 명령을 사용하여 IP Admission 프로세스가 트리거된 이유를 검색할 수 있습니다.
- 디버그 ip admission htpd
- 디버그 ip http 트랜잭션
- 디버그 aaa 인증 디버그 aaa 권한 부여
일반적인 문제
이 섹션에서는 이 문서에 설명된 구성과 관련하여 발생하는 몇 가지 일반적인 문제에 대해 설명합니다.
IP Admission이 HTTP 요청을 가로채지 않음
이 문제는 show ip admission statistics 명령 출력을 볼 때 명백해집니다.출력에 HTTP 요청의 가로채기가 표시되지 않습니다.
C-881#show ip admission statistics
Webauth HTTPd statistics:
HTTPd process 1
Intercepted HTTP requests: 0
가능한 솔루션
이 문제에 대한 두 가지 가능한 해결책이 있습니다.첫 번째는 ip http 서버가 활성화되었는지 확인하는 것입니다.
ISR에 대한 HTTP 서버가 활성화되지 않은 경우 IP Admission은 트리거되지만 실제로 HTTP 세션을 가로채지는 않습니다.따라서 인증을 묻는 메시지가 표시됩니다.이 경우 show ip admission cache 명령에 대한 출력은 없지만, debug ip admission detail 명령의 출력에는 이러한 행의 많은 반복이 표시됩니다.
*Jan 30 20:49:35.726: ip_admission_det:proceed with process path authentication
*Jan 30 20:49:35.726: AUTH-PROXY auth_proxy_find_conn_info :
find srcaddr - 10.10.10.152, dstaddr - 192.168.1.1
ip-srcaddr 10.20.10.1
pak-srcaddr 10.10.10.152
이 문제의 두 번째 해결 방법은 사용자 IP 주소가 IP Admission 컨피그레이션의 ACL에서 제외되지 않는지 확인하는 것입니다.
사용자가 404를 찾을 수 없음 오류
이 문제는 사용자가 인증을 위해 리디렉션되고 브라우저에서 404 Not Found 오류가 발생할 때 관찰됩니다.
가능한 솔루션
ip admission virtual-ip 1.1.1.1 virtual-host ISR_PROXY의 이름이 클라이언트 DNS(Domain Name System) 서버로 성공적으로 확인할 수 있는지 확인합니다.이 경우, lab.cisco.com은 워크스테이션이 가입된 도메인의 FQDN(Fully Qualified Domain Name)이므로 클라이언트가 ISR_PROXY.lab.cisco.com에 대해 DNS 쿼리를 수행합니다.DNS 쿼리가 실패하면 클라이언트는 LLMNR(Link-Local Multicast Name Resolution) 쿼리를 보내고 로컬 서브넷으로 브로드캐스트되는 NETBIOS 쿼리를 보냅니다.
이러한 모든 확인 시도가 실패하면 404 Not Found 또는 Internet Explorer에서 웹 페이지 오류를 브라우저에 표시합니다.
프롬프트가 표시되면 사용자 인증이 실패합니다.
이는 다양한 이유로 발생할 수 있지만 일반적으로 ISR의 LDAP 컨피그레이션 또는 ISR과 LDAP 서버 간의 통신과 관련이 있습니다.ISR에서 일반적으로 IP Admission(IP 허용)이 트리거되면 사용자가 INIT 상태에 머물러 있는 경우 이 증상이 관찰됩니다.
C-881(config)#do show ip admi cac
Authentication Proxy Cache
Client Name N/A, Client IP 10.10.10.152, Port 56674, timeout 60,
Time Remaining 2, state INIT
일반적인 원인
이 문제의 일반적인 원인은 다음과 같습니다.
- 활성 인증을 위해 사용자가 잘못된 사용자 이름 및/또는 비밀번호를 입력했습니다.
- 잘못된 base-dn이 LDAP 컨피그레이션에 사용되어 검색 결과가 반환되지 않습니다.
- 사용자 이름 또는 비밀번호에 대해 잘못된 바인드 인증 root-dn이 구성되어 LDAP 바인드가 실패합니다.
- ISR과 LDAP 서버 간의 통신이 실패합니다.LDAP 서버가 LDAP 통신을 위해 지정된 TCP 포트에서 수신 대기하며 둘 사이의 모든 방화벽이 트래픽을 허용하는지 확인합니다.
- 잘못된 검색 필터로 인해 LDAP 검색에 대한 결과가 없습니다.
LDAP 문제 해결
인증에 실패하는 이유를 확인하는 가장 좋은 방법은 ISR에서 LDAP 디버그 명령을 사용하는 것입니다.과도한 출력이 있을 경우 디버그가 ISR에서 실행되는 데 비용이 많이 들고 위험할 수 있으며 라우터가 정지되고 하드 전원 주기가 필요할 수 있습니다.이는 특히 로우엔드 플랫폼에서도 마찬가지입니다.
트러블슈팅을 위해 Cisco에서는 네트워크의 단일 테스트 워크스테이션만 인증에 적용할 수 있도록 IP Admission 규칙에 ACL을 적용하는 것이 좋습니다.이렇게 하면 라우터가 트래픽을 전달하는 기능에 부정적인 영향을 줄 수 있는 최소한의 위험으로 디버그를 활성화할 수 있습니다.
LDAP 관련 문제를 해결할 때 LDAP가 ISR에서 요청을 처리하는 단계를 이해하는 것이 좋습니다.
LDAP 인증을 위한 상위 단계
다음은 LDAP 인증을 위한 고급 단계입니다.
- 지정된 포트에서 LDAP 서버에 대한 연결을 엽니다.기본 포트는 TCP 389입니다.
- bind를 사용하여 LDAP 서버에 바인딩하여 root-dn 사용자 및 비밀번호를 인증합니다.
- 인증을 시도하는 사용자에 대해 LDAP 컨피그레이션에 정의된 base-dn 및 search-filter를 사용하여 LDAP 검색을 수행합니다.
- LDAP 서버에서 LDAP 결과를 가져오고 인증이 성공한 경우 사용자에 대한 IP Admission 캐시 항목을 만들거나, 인증 실패 시 자격 증명을 다시 표시합니다.
LDAP 디버그 출력 분석
이러한 프로세스는 debug ldap all 명령의 출력에서 볼 수 있습니다.이 섹션에서는 잘못된 base-dn으로 인해 실패한 인증에 대한 LDAP 디버그 출력의 예를 제공합니다. 디버그 출력 및 관련 주석을 검토합니다. 이 설명에서는 앞서 언급한 단계에 오류가 발생할 수 있는 위치를 보여 줍니다.
*Jan 30 20:51:50.818: LDAP: LDAP: Queuing AAA request 23 for processing
*Jan 30 20:51:50.818: LDAP: Received queue event, new AAA request
*Jan 30 20:51:50.818: LDAP: LDAP authentication request
*Jan 30 20:51:50.818: LDAP: Username sanity check failed
*Jan 30 20:51:50.818: LDAP: Invalid hash index 512, nothing to remove
*Jan 30 20:51:50.818: LDAP: New LDAP request
*Jan 30 20:51:50.818: LDAP: Attempting first next available LDAP server
*Jan 30 20:51:50.818: LDAP: Got next LDAP server :DC01
*Jan 30 20:51:50.818: LDAP: Free connection not available. Open a new one.
*Jan 30 20:51:50.818: LDAP: Opening ldap connection
( 10.10.10.150, 389 )ldap_open
굵게 표시된 출력의 부분은 연결이 성공적으로 열렸기 때문에 네트워크 레이어 문제가 아님을 나타냅니다.
*Jan 30 20:51:50.822: LDAP: Root Bind on CN=Csco_Service,CN=Users,DC=lab,
DC=cisco,DC=com initiated.
*Jan 30 20:51:51.330: LDAP: Ldap Result Msg: SUCCESS, Result code =0
*Jan 30 20:51:51.330: LDAP: Root DN bind Successful on :CN=Csco_Service,
CN=Users,DC=lab,DC=cisco,DC=com
이 출력에서 Bind authenticate-dn이 올바릅니다.컨피그레이션이 잘못된 경우 바인드 실패가 표시됩니다.
*Jan 30 20:51:51.846: LDAP: Received Bind Responseldap_parse_sasl_bind_result
*Jan 30 20:51:51.846: LDAP: Ldap SASL Result Msg: SUCCESS, Result code =14
sasLres_code =14
*Jan 30 20:51:51.846: LDAP: SASL NTLM authentication do not require
further tasks
*Jan 30 20:51:51.846: LDAP: Next Task: All authentication task completed
*Jan 30 20:51:51.846: LDAP: Transaction context removed from list
[ldap reqid=14]
*Jan 30 20:51:51.846: LDAP: * * AUTHENTICATION COMPLETED SUCCESSFULLY * *
*Jan 30 20:51:51.846: LDAP: Notifying AAA: REQUEST CHALLENGED
굵게 표시된 출력의 부분은 모든 바인드 작업이 성공적으로 수행되었음을 나타내며 실제 사용자를 검색합니다.
*Jan 30 20:51:51.854: LDAP: SASL NTLM authentication done..Execute search
*Jan 30 20:51:51.854: LDAP: Next Task: Send search req
*Jan 30 20:51:51.854: LDAP: Transaction context removed from list[ldap reqid=15]
*Jan 30 20:51:51.854: LDAP: Dynamic map configured
*Jan 30 20:51:51.854: LDAP: Dynamic map found for aaa type=username
*Jan 30 20:51:51.854: LDAP: Ldap Search Req sent
ld 2293572544
base dn dc=lab1,dc=cisco,dc=comscope 2
filter (&(objectclass=top)(sAMAccountName=testuser5))
ldap_req_encode
put_filter "(&(objectclass=top)(sAMAccountName=testuser5))"
put_filter: AND
put_filter_list "(objectclass=top)(sAMAccountName=testuser5)"
put_filter "(objectclass=top)"
put_filter: simple
put_filter "(sAMAccountName=testuser5)"
put_filter: simple
Doing socket write
*Jan 30 20:51:51.854: LDAP: lctx conn index = 2
첫 번째 줄(굵게 표시됨)은 LDAP 검색 디버그 출력이 시작됨을 나타냅니다.또한 base-dn 도메인 컨트롤러는 lab1이 아닌 랩에 대해 구성해야 합니다.
*Jan 30 20:51:52.374: LDAP: LDAP Messages to be processed: 1
*Jan 30 20:51:52.374: LDAP: LDAP Message type: 101
*Jan 30 20:51:52.374: LDAP: Got ldap transaction context from reqid
16ldap_parse_result
*Jan 30 20:51:52.374: LDAP: resultCode: 10 (Referral)
*Jan 30 20:51:52.374: LDAP: Received Search Response resultldap_parse_result
ldap_err2string
*Jan 30 20:51:52.374: LDAP: Ldap Result Msg: FAILED:Referral, Result code =10
*Jan 30 20:51:52.374: LDAP: LDAP Search operation result : failedldap_msgfree
*Jan 30 20:51:52.374: LDAP: Closing transaction and reporting error to AAA
*Jan 30 20:51:52.374: LDAP: Transaction context removed from list
[ldap reqid=16]
*Jan 30 20:51:52.374: LDAP: Notifying AAA: REQUEST FAILED
굵게 표시된 출력의 부분은 검색에 결과가 반환되지 않았음을 나타냅니다. 이 경우 base-dn이 잘못되었기 때문입니다.
RFC 4511
RFC 4511(LDAP(Lightweight Directory Access Protocol):프로토콜)은 LDAP 및 기타 LDAP 프로토콜 관련 정보에 대한 결과 코드 메시지에 대한 정보를 제공하며, 이는 IETF 웹 사이트를 통해 참조할 수 있습니다.
피드백