Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

B.2. Identity Management 복제

이 가이드에서는 Red Hat Enterprise Linux의 ID 관리의 일반적인 복제 문제에 대해 설명합니다.
추가 리소스:

B.2.1. 새 복제본 Fails에 AD 사용자 인증

ID 관리 - Active Directory 신뢰 설정에 새 복제본을 설치한 후 IdM 복제본에 대해 AD(Active Directory) 사용자를 인증하려고 하면 실패합니다.

이것이 의미하는 바:

복제본은 신뢰 컨트롤러와 신뢰 에이전트가 아닙니다. 이 때문에 AD 신뢰에서 정보를 제공할 수 없습니다.

문제를 해결하려면 다음을 수행합니다.

복제본을 신뢰 에이전트로 구성합니다. Windows 통합 가이드에서 신뢰 컨트롤러 및 신뢰 에이전트 를 참조하십시오.

B.2.2. 디렉터리 서버 로그에서 SASL, GSS-API 및 Kerberos 오류를 사용한 복제 시작

복제본이 시작되면 일련의 SASL 바인드 오류가 Directory Server (DS) 로그에 기록됩니다. 오류에서는 인증 정보 캐시를 찾을 수 없기 때문에 GSS-API 연결에 실패했습니다. 
slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_496' not found)) ...
또한 서버에서 호스트 주체의 Kerberos 자격 증명을 얻을 수 없다는 다른 메시지가 표시될 수 있습니다. 
set_krb5_creds - Could not get initial credentials for principal [ldap/ replica1.example.com] in keytab [WRFILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error)

이것이 의미하는 바:

IdM은 Kerberos 연결에 GSS-API를 사용합니다. DS 인스턴스는 Kerberos 자격 증명 캐시를 메모리에 유지합니다. IdM 복제본이 중지될 때와 같이 DS 프로세스가 종료되면 자격 증명 캐시가 삭제됩니다.
복제본이 다시 시작되면 KDC 서버가 시작되기 전에 DS가 시작됩니다. 이 시작 순서로 인해 DS가 시작되면 Kerberos 자격 증명이 아직 자격 증명 캐시에 저장되지 않으므로 오류가 발생합니다.
초기 실패 후 DS는 KDC가 시작된 후 GSS-API 연결을 다시 설정하려고 시도합니다. 이 두 번째 시도는 성공적으로 수행되며 복제본이 예상대로 작동하는지 확인합니다.
GSS-API 연결이 성공적으로 설정되고 복제본이 예상대로 작동하는 한 설명된 시작 오류는 무시할 수 있습니다. 다음 메시지는 연결에 성공했음을 보여줍니다. 
Replication bind with GSSAPI auth resumed

B.2.3. DNS 전달 레코드가 역방향 주소와 일치하지 않음

새 복제본을 구성할 때 일련의 인증서 오류로 인해 설치에 실패하고 DNS 전달 레코드가 역방향 주소와 일치하지 않음을 나타내는 DNS 오류가 발생합니다. 
ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer
ipa: DEBUG: cert valid True for "CN=replica.example.com,O=EXAMPLE.COM"
ipa: DEBUG: handshake complete, peer = 192.0.2.2:9444
Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)

...

ipa: DEBUG: Created connection context.ldap2_21534032
ipa: DEBUG: Destroyed connection context.ldap2_21534032
The DNS forward record replica.example.com. does not match the reverse address replica.example.org

이것이 의미하는 바:

단일 PTR 레코드에 여러 호스트 이름이 사용됩니다. DNS 표준은 이러한 구성을 허용하지만 IdM 복제본 설치에 실패합니다.

문제를 해결하려면 다음을 수행합니다.

“정방향 및 역방향 DNS 구성 확인” 에 설명된 대로 DNS 구성을 확인합니다.

B.2.4. 일련 번호를 찾을 수 없음

참고
이 솔루션은 도메인 수준 0 에 적용됩니다. 자세한 내용은 7장. 도메인 수준 표시 및 승격 을 참조하십시오.
인증서 일련 번호를 찾을 수 없다는 오류가 복제된 서버에 표시됩니다. 
Certificate operation cannot be completed: EXCEPTION (Certificate serial number 0x2d not found)

이것이 의미하는 바:

두 복제본 간 인증서 복제 연결이 제거되었지만 데이터 복제 연결은 아직 진행 중입니다. 두 복제본 모두 여전히 인증서를 발행하지만 인증서에 대한 정보는 더 이상 복제되지 않습니다.
예제 상황:
  1. Replication A에서 인증서를 호스트에 발행합니다.
  2. 복제본에 인증서 복제 연결이 설정되어 있지 않으므로 인증서가 복제본 B에 복제되지 않습니다.
  3. 사용자는 복제본 B를 사용하여 호스트를 관리하려고 시도합니다.
  4. replica B는 호스트의 인증서 일련 번호를 확인할 수 없는 오류를 반환합니다. 복제본 B에는 데이터 디렉터리에 호스트에 대한 정보가 있지만 인증서 디렉터리에 호스트 인증서가 없기 때문입니다.

문제를 해결하려면 다음을 수행합니다.

  1. ipa-csreplica-manage connect 명령을 사용하여 두 복제본 간에 인증서 서버 복제를 활성화합니다. D.3.3절. “복제 계약 생성 및 제거” 참조하십시오.
  2. 다른 복제본에서 복제본 중 하나를 다시 초기화하여 동기화합니다. D.3.5절. “복제 다시 초기화” 참조하십시오.
    주의
    다시 초기화된 복제본의 데이터를 다른 복제본의 데이터로 재초기화합니다. 일부 정보가 손실될 수 있습니다.

B.2.5. 복제 업데이트 벡터(RUV) 오류 정리

참고
이 솔루션은 도메인 수준 0 에 적용됩니다. 자세한 내용은 7장. 도메인 수준 표시 및 승격 을 참조하십시오.
IdM 토폴로지에서 복제본이 제거되면 더 이상 사용되지 않는 RUV 레코드가 나머지 하나 이상의 복제본에 표시됩니다.
가능한 원인:
  • “복제 계약 제거” 에 설명된 대로 복제 계약을 제대로 제거하지 않고 복제본이 제거되었습니다.
  • 다른 복제본이 오프라인 상태였을 때 복제본이 제거되었습니다.

이것이 의미하는 바:

다른 복제본은 여전히 제거된 복제본에서 업데이트를 수신할 것으로 예상됩니다.
참고
복제를 제거하는 올바른 절차는 D.3.6절. “복제 제거” 에 설명되어 있습니다.

문제를 해결하려면 다음을 수행합니다.

업데이트를 수신할 복제본에서 RUV 레코드를 정리합니다.
  1. ipa-replica-manage list-ruv 명령을 사용하여 더 이상 사용되지 않는 RUV에 대한 세부 정보를 나열합니다. 명령은 복제본 ID를 표시합니다. 
    # ipa-replica-manage list-ruv
server1.example.com:389: 6
server2.example.com:389: 5
server3.example.com:389: 4
server4.example.com:389: 12
  2. ipa-replica-manage clean-ruv replica_ID 명령을 사용하여 손상된 RUV를 지웁니다. 명령은 지정된 복제본과 연결된 모든 RUV를 제거합니다.
    더 이상 사용되지 않는 RUV를 사용하여 모든 복제본에 대해 명령을 반복합니다. 예를 들어 다음과 같습니다. 
    # ipa-replica-manage clean-ruv 6
# ipa-replica-manage clean-ruv 5
# ipa-replica-manage clean-ruv 4
# ipa-replica-manage clean-ruv 12
    주의
    ipa-replica-manage clean-ruv 를 사용할 때 매우 주의를 기울입니다. 유효한 복제본 ID에 대해 명령을 실행하면 복제 데이터베이스에서 해당 복제본과 연결된 모든 데이터가 손상됩니다.
    이 경우 D.3.5절. “복제 다시 초기화” 에 설명된 대로 다른 복제본에서 복제본을 다시 초기화합니다.
  3. ipa-replica-manage list-ruv 를 다시 실행합니다.
    • 명령이 손상된 RUV를 더 이상 표시하지 않으면 레코드가 성공적으로 정리되었습니다.
    • 명령에서 손상된 RUV를 계속 표시하는 경우 이 작업을 사용하여 수동으로 지웁니다. 
      dn: cn=clean replica_ID, cn=cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: dc=example,dc=com
replica-id: replica_ID
replica-force-cleaning: no
cn: clean replica_ID
RUV를 정리할 복제본이 확실하지 않은 경우 다음을 수행하십시오.
  1. 모든 서버에서 활성 복제본 ID를 검색합니다. 수정되지 않고 신뢰할 수 있는 복제 ID 목록을 만듭니다.
    유효한 복제본의 ID를 찾으려면 토폴로지의 모든 노드에 대해 이 LDAP 쿼리를 실행합니다. 
    # ldapsearch -p 389 -h IdM_node -D "cn=directory manager" -W -b "cn=config" "(objectclass=nsds5replica)" nsDS5ReplicaId
  2. 모든 서버에서 ipa-replica-manage list-ruv 를 실행합니다. 손상되지 않은 복제본 ID 목록에 없는 모든 복제본 ID를 확인합니다.
  3. 손상된 모든 복제본 ID에 대해 ipa-replica-manage clean-ruv replica_ID 를 실행합니다.

B.2.6. 손실된 CA 서버 복구

참고
이 솔루션은 도메인 수준 0 에 적용됩니다. 자세한 내용은 7장. 도메인 수준 표시 및 승격 을 참조하십시오.
CA가 설치된 서버가 하나뿐이었습니다. 이 서버가 실패하고 이제 손실됩니다.

이것이 의미하는 바:

IdM 도메인의 CA 구성을 더 이상 사용할 수 없습니다.

문제를 해결하려면 다음을 수행합니다.

원래 CA 서버의 백업이 있는 경우 서버를 복원하고 복제에 CA를 설치할 수 있습니다.
  1. 백업에서 CA 서버를 복구합니다. 자세한 내용은 9.2절. “백업 복원” 을 참조하십시오.
    그러면 복제본에서 CA 서버를 사용할 수 있습니다.
  2. 복제 충돌을 방지하려면 초기 서버와 복제본 간 복제 계약을 삭제합니다. D.3.3절. “복제 계약 생성 및 제거” 참조하십시오.
  3. 복제에 CA를 설치합니다. 6.5.2절. “마스터 CA 서버로 복제 승격” 참조하십시오.
  4. 원래 CA 서버를 폐기합니다. D.3.6절. “복제 제거” 참조하십시오.
원래 CA 서버의 백업이 없는 경우 서버가 실패하면 CA 구성이 손실되어 복구할 수 없습니다.