LDAP 문제 해결에 대해 알아보겠습니다. 우선 해결해야 할 수 있는 문제 중 하나는 유효성 검사 실패입니다.
인증서가 올바르지 않은 경우, Active Directory 또는 OpenLDAP 서버에서 그룹이 제대로 설정되지 않은 경우, 사용자 이름이 올바른 형식으로 입력되지 않은 경우 이러한 모든 문제가 발생할 수 있습니다.
따라서 쿼리 사용자의 비밀번호가 잘못된 경우 "LDAP 구성 세부 정보 검증 실패"라는 메시지가 표시되고 "Submit" 버튼을 누를 수 없습니다.
한 가지 강조하고 싶은 것은, 여기에 인증서를 업로드할 때 여기에 보이는 "AD-cert.cer"에서 ACM이 하는 일은 "Validate" 버튼을 클릭하면 기본적으로 인증서가 "User local data protection" 표시줄, config manager server_data certificates에 있는 "Certificates Directory"에 저장된다는 것입니다.
인증서가 저장되면 ACM이 해당 인증서를 ".cer"에서 ".pem" 형식으로 변환합니다. 이제 성공적인 검증이 어떤 모습인지 살펴보는 또 다른 비디오를 만들었습니다.
유효성 검사에 실패할 경우 문제를 해결하기 위해 로그에서 어떤 항목을 확인해야 할까요? 이 부분을 알아보겠습니다.
따라서 이 작업을 다시 수행하려면 "Logs Directory"로 이동하고, Esc 키를 이동한 다음 G 키를 이동한 다음 Escape 키를 사용하여 어플라이언스에서 이 configure LDAP를 검색합니다.
검색하면 "testLDAPconnection"과 같은 메시지가 표시됩니다. 조금 더 아래로 스크롤하면 ping 테스트를 수행한 다음 사용자가 성공적으로 인증되었는지, 그룹의 구성원인지 확인합니다.
그러면 LDAP connection tested successfully라는 메시지가 표시됩니다. LDAP 유효성 검사 실패에 대한 로그를 검토해 보겠습니다. 이제 실패한 유효성 검사 항목을 살펴보겠습니다.
여기서는 세부 정보를 입력하고, 일부러 잘못된 필드 중 하나를 잘못된 값으로 입력하려고 합니다. 어떻게 되는지 살펴보겠습니다. 보안 LDAP이므로 이 확인란을 선택합니다.
인증서를 업로드한 다음 검증을 수행합니다. 유효성 검사에 실패한 것 같죠. 빨간색 느낌표 위로 마우스를 가져가면 "Failed to validate LDAP configuration details"라는 메시지를 볼 수 있습니다.
다시 "ACM logs directory"로 이동하여 "server.log"를 확인하고 G를 이동하여 로그의 끝으로 이동합니다. 를 검색한 다음 LDAP Util: testConnection을 대문자 "C"로 한 단어로 검색합니다.
여기에 나온 것과 같은 메시지가 표시됩니다. 사용자 이름이나 비밀번호에 문제가 있음이 분명하죠. 이 데모에서는 비밀번호 문제였으며 테스트 연결이 실패한 것을 볼 수 있습니다.
여기까지 하셨으면 이제부터 설명할 내용은 이러한 세부 정보를 입력할 때 유의할 몇 가지 사항입니다. "Server Hostname" 또는 "LDAP Hostname"에는 FQDN(Fully Qualified Domain Name)을 입력해야 합니다. IP 주소는 사용할 수 없습니다.
쿼리 사용자 이름, 사용자는 "사용자 계정" 이름 형식으로 사용자 이름을 제공해야 합니다. 예를 들면 "Abc@domain.com"과 같이 입력하면 됩니다.
관리자 그룹 설정 Active Directory 또는 OpenLDAP 수준에서 설정된 관리자 그룹입니다. 고객이 그룹을 생성할 때 그룹 범위는 "Global"로 설정하고 유형은 "Security"로 설정해야 합니다.
"Query username"은 LDAP 관리자 그룹의 구성원이어야 합니다. 모범 사례는 모든 값에 소문자를 사용하는 것입니다. 대문자로 된 값을 사용할 때 몇 가지 문제를 일으키는 코드 결함도 있으므로 이를 알고 있어야 합니다.
보안 LDAP 구성의 경우 사용자는 루트 CA 인증서를 ".cer" 형식으로 제공해야 합니다. 중첩된 그룹은 허용되지 않으며 사용자는 LDAP 관리자 그룹의 직속 구성원이어야 합니다.
여기서 사용자는 LDAP 쿼리 사용자입니다. 예를 들어 LDAP 쿼리 사용자를 그룹에 포함하거나 해당 그룹을 관리자 그룹의 구성원으로 만들 수 없습니다. 이 방식은 사용할 수 없습니다.
또 한 가지 기억해야 할 요구 사항이 있습니다. Protection Storage 또는 Data Domain에서 LDAP 통합이 성공적으로 작동하려면 LDAP 쿼리 사용자에게 컴퓨터 오브젝트에 대한 "생성/제거" 전체 제어 권한이 있어야 합니다. 통합 중에 컴퓨터 오브젝트가 생성되기 때문입니다.
방법을 살펴보겠습니다. Active Directory에서 LDAP 쿼리 사용자를 찾고 해당 사용자가 있는 상위 OU(Organization Unit)로 이동합니다. 이것을 오른쪽 클릭한 다음 "Delegate Control"을 클릭합니다. 그러면 이런 마법사가 나타납니다. "Next"를 클릭하고 사용자, 즉 쿼리 사용자를 추가할 수 있습니다.
그러고 나서 사용자 지정 "Tasks to Delegate"를 생성합니다. 여기서 Computer objects를 선택하고 Create selected objects in this folder 또는 "Delete"를 선택하면 됩니다. 그런 다음 "Next"를 클릭합니다. "Full Control" 권한을 부여하고 "Next"와 "Finish"를 차례로 선택합니다.
이렇게 하면 Protection Storage 또는 Data Domain 측에서 원활하게 구성할 수 있습니다. 이제 LDAP 유형 문제를 해결하려면 체계적인 순서로 진행하는 것이 매우 중요합니다. 항상 Ping 테스트로 시작하는 것이 좋습니다.
Ping 명령을 사용하여 연결을 확인하고 항상 Ping에 호스트 이름 또는 FQDN을 사용합니다. 또한 IP 주소도 사용하는 것이 좋습니다. 그래야 하는 이유가 있습니다. "ping -c"를 실행할 수 있습니다. 4개의 패킷을 발급하므로 값을 "4 FQDN"으로 입력하고 기본적으로 ping을 테스트하고 성공했는지 확인할 수 있습니다.
IP와 호스트 이름 모두에 대해 Ping을 테스트하라고 한 이유는 때때로 IP에 대한 Ping은 작동하지만 그러나 ACM 또는 IDPA 내 하나 이상의 구성 요소에서 호스트 이름에는 작동하지 않습니다. 그리고 그 이유는 "/etc/resolv.conf" 파일에 DNS 검색 도메인이 누락되어 LDAP 서버 호스트 이름에 대한 Ping이 실패할 수 있기 때문입니다.
실제로 이것은 가장 일반적으로 발생하는 문제입니다. 따라서 IP 주소를 Ping 할 수 있지만 호스트 이름을 Ping 할 수 없는지 항상 확인합니다. 각 IDPA 구성 요소에서 "/etc/resolv.conf" 파일을 확인합니다. 해결 방법이 제대로 작동하려면 Active Directory 또는 환경에 대해 이 검색 도메인이 추가되어 있는지 확인합니다.
또한 특정 포트 확인을 수행하는 것이 좋습니다. LDAP 통합을 위한 포트 요구 사항을 살펴보겠습니다. 기본적으로 IDPA 구성 요소와 Active Directory 또는 "OPENLDAP" 서버 간의 통신을 위해 열려 있어야 하는 TCP 포트 389 및 636이 필요합니다. 이제 TCP 포트 88 및 464가 "Avamar"인 보호 소프트웨어, Data Domain인 보호 스토리지, Active Directory 또는 "Openldap" 서버 간의 Kerberos 인증을 위해 열려 있어야 합니다.
포트 연결을 테스트하려면 "curl" 명령을 사용합니다. 데모에서 살펴보았죠. "curl -kv :"를 실행할 수 있습니다. 389는 "비보안"이고 636은 "보안"입니다. 이 명령을 실행한 후 확인해야 할 출력은 이것입니다. Connected to "dc.x400.sh" on "port 636" "ldapsearch"를 사용한 문제 해결입니다. 이것은 매우 중요한 툴이라고 생각합니다.
이는 유효성 검사에 실패하거나 구성이 실패하는 경우에 사용할 수 있습니다. 이는 기본적으로 사용자가 보유한 LDAP 세부 정보를 사용하는 "검증"과 유사하기 때문에 테스트 연결을 수행하고 연결 가능 여부를 확인합니다. 기본적으로 "ldapsearch"는 LDAP 서버에 대한 연결을 열고 바인딩한 다음 필터를 사용하여 검색을 수행하는 명령줄 도구입니다.
결과는 LDIF(LDAP Interchange Format) 형식으로 표시됩니다. ldapsearch 툴은 ACM, DPC 검색, Avamar 등과 같은 IDPA 구성 요소에서 LDAP 서버와의 연결을 테스트하고 설정을 검증하는 데 사용할 수 있습니다. 비보안 LDAP와 보안 LDAP의 구문은 다릅니다.
비보안의 경우 "ldapsearch -h" 명령을 실행할 수 있습니다. LDAP 서버(OpenLDAP 또는 Active Directory)의 FQDN을 입력하고 "-p"를 입력합니다. 여기에 포트 번호 "-D"를 입력하고 사용자 자격 증명을 입력한 LDAP_Query "x400.sh"를 추가합니다. -b와 같은 형식으로 "Base_DN"를 입력합니다. 도메인 구성 요소가 있는 곳입니다. 예를 들면 "dc=x400, dc=2.sh"와 같이 입력한 다음 "-w", 쿼리 비밀번호를 입력합니다.
마찬가지로 보안 LDAP의 경우에도 이렇게 할 수 있습니다. ldapsearch -h, ldaps:// URL을 입력합니다. "LDAP_server_FQDN: port" 번호를 입력하고 보안 LDAP 유형을 구성할 때 중요한 것은 "openssl"이거나 인증서를 검증하는 것입니다. 그러려면 "openssl" 명령을 실행하면 됩니다. "openssl s_client -connect"를 실행합니다. Active Directory OPENLDAP 서버의 FQDN: 포트 번호를 입력합니다. 이 경우 포트 번호는 636이죠.
확인해야 할 출력 항목은 "Connected"입니다. 즉, ACM이 해당 인증서를 사용하여 포트 636을 검증하고 연결할 수 있었습니다. 이 명령을 실행할 때 "unable to validate the change" 또는 "verify the change"가 표시될 수 있습니다. 여기에서 수행하는 작업은 단순히 연결하는 것이며 Active Directory 서버에 대한 인증서를 전달하여 체인 등의 유효성을 검사하는 것이 아니므로 이런 메시지가 나타나도 괜찮습니다. 위의 출력 내용이 일부 잘렸다는 점에 유의하십시오.
쿼리 사용자 및 관리자 그룹 세부 정보 확인을 살펴보겠습니다. 특정 항목이 잘못되었다는 것을 알게 되고, 그룹이 잘못되었을 수도 있고, 쿼리 사용자에 대한 세부 정보가 올바르지 않다는 것을 알게 된 후 문제 해결의 다음 단계로 이동할 수 있다고 가정해 보겠습니다. 무엇을 해야 할까요? Active Directory 서버에서 PowerShell으로 쿼리하여 사용자 및 그룹 객체를 DN(Distinguished Name) 형식으로 가져올 수 있습니다.
"Get-ADUser" cmdlet을 통해 지정된 사용자 객체를 가져오거나 검색을 수행하여 여러 사용자 객체를 가져올 수 있습니다. 또한 "Get-ADGroup" cmdlet을 통해 그룹을 가져오거나 검색을 수행하여 Active Directory에서 여러 그룹을 가져올 수 있습니다. 왼쪽이 사용자에 대한 출력 스크린샷이고 오른쪽이 그룹에 대한 출력 스크린샷입니다. 어떤 출력이 나오는지를 볼 수 있죠.
"Distinguished Name"이 표시됩니다. 이것은 "ldap.query"이고 "Users" OU에 있습니다. 도메인 구성 요소는 "x400.sh"이고 이것만 보아도 "User Principal Name"을 확인할 수 있습니다. 이것이 "configure LDAP" 팝업 또는 대화상자에 입력해야 하는 내용입니다.
여기에서 이러한 모든 세부 정보를 확인할 수 있습니다. 그룹을 살펴보면 마찬가지로 DN 형식과 그룹 위치가 표시됩니다. 역시 "Users" OU에 있습니다. 도메인 구성 요소는 "x400"과 "sh"입니다. 그룹 범주는 "Security"입니다. 그룹 범주는 "보안"이어야 하고 그룹 범위는 "전역"이어야 한다고 말씀드렸습니다. 그것도 여기에서 확인할 수 있습니다.
또한 "SamAccountName"과 그룹 이름이 "dp_admin"으로 표시되어 있습니다. 따라서 고객의 Active Directory 수준에서도 유효성을 검사할 수 있는 좋은 방법입니다. 참고로 이전 슬라이드에서 말씀드렸듯이 IDPA에서 LDAP를 구성하면 ACM이 LDAP 구성의 세부 정보를 ldapconfig.xml에 저장합니다. 또한 이 쿼리 사용자의 비밀번호를 "Component Credentials.ReadXml"이라는 파일에 저장합니다.
그리고 구성 요소를 모니터링하는 동안 ACM은 기본 기능으로 몇 분마다 LDAP 로그인을 테스트합니다. 이때 이러한 자격 증명과 각 구성 요소에 대한 세부 정보를 사용하죠. 그 이유는 LDAP 구성이 작동 중인지, 이 사용자 및 기타 구성 요소에 대해 ACM에 저장된 LDAP 쿼리 비밀번호가 실제로 동기화되어 있는지 확인하려고 합니다. 비밀번호가 변경되지 않았는지 확인하려고 하기 때문입니다.
이제 고객이 쿼리 사용자 비밀번호를 변경한 활용 사례에서는 LDAP 인증이 모든 구성 요소에서 작동을 중지하고 ACM UI에서 "LDAP password out of sync"라는 오류 메시지를 보게 됩니다. 이 경우 기본적으로 ACM GUI에서 동일한 "Configure external LDAP" 팝업을 클릭하고 Update external LDAP password라는 확인란을 클릭하면 됩니다.
그러면 다른 모든 세부 정보가 회색으로 표시되고 비밀번호만 업데이트할 수 있습니다. 비밀번호를 업데이트하면 비밀번호가 자체적으로 또는 자격 증명이 저장된 ACM "Component Credentials.ReadXml" 파일에서 업데이트됩니다. 또한 IDPA의 각 포인트 제품 또는 구성 요소의 구성 비밀번호가 업데이트되어 인증이 계속 작동하는지 확인됩니다. 이것은 정말로 신경 써야 할 사항 중 하나입니다.
구성이 실패하거나 사용자에게 일종의 인증 문제가 발생하는 가장 일반적인 이유 중 하나는 시간이 동기화되지 않았기 때문일 수 있습니다. 시간은 매우 민감한 LDAP의 경우 IDPA 구성 요소와 Active Directory 또는 OpenLDAP 서버 간에 시간이 동기화되어야 합니다. 시간이 동기화되지 않은 경우 사용자에게 구성 오류가 발생할 수 있으며 인증 로그인 실패도 발생할 수 있습니다.
이제 매우 중요하고 일상적으로 사용하는 로그 위치와 로그 파일에 대해 살펴보겠습니다. 따라서 LDAP 문제를 해결할 때 사용자는 ACM의 다음 로그를 분석하여 모든 구성, 통합, 검증, 모니터링 유형의 오류를 확인해야 하며 이것이 "server.log"입니다.
데모에서도 살펴보았죠. 예를 들어 하나 이상의 구성 요소에 구성 장애가 발생하면 LDAP 구성이 실패한 특정 구성 요소의 로그와 ACM의 "server.log"를 분석해야 합니다. 여기에 로그 위치가 나와 있습니다. ACM에는 "server.log"가 있고, Data Protection Central에는 "elg.log"가 있습니다.
여기에 제공된 것이 전부입니다. Search에는 "cis.log"가 있고, 보호 소프트웨어에는 "userauthentication.log"가 있습니다. 그리고 경우에 따라 같은 위치에 있는 "mcserver.log.0"에서도 몇 가지 세부 정보를 찾을 수 있습니다.
Protection Storage 또는 Data Domain의 경우 "messages.engineering" 로그를 검토할 수 있으며 이를 위해서는 Bash 액세스 권한이 필요합니다. 또한 DPA의 경우 "server.log"는 opt/emc/dpa/services/logs 디렉토리입니다.
