IdM 사용자, 그룹, 호스트 및 액세스 제어 규칙 관리

Red Hat Enterprise Linux 8

사용자 및 호스트 구성, 그룹에서 관리, 호스트 기반 및 역할 기반 액세스 제어 규칙으로 액세스 제어

Red Hat Customer Content Services

초록

Red Hat IdM(Identity Management)의 주요 기능은 사용자, 그룹, 호스트, 액세스 제어(HBAC) 및 역할 기반 액세스 제어(RBAC)와 같은 사용자, 그룹, 호스트 및 액세스 제어 규칙을 관리하는 것입니다. 명령줄, IdM 웹 UI 및 Ansible 플레이북을 사용하여 구성할 수 있습니다.
관리 작업에는 Kerberos 정책 및 보안 구성, 그룹 멤버십 자동화, 권한 위임이 포함됩니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서 및 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

Identity Management에서 계획된 용어 교체는 다음과 같습니다.

  • 차단 목록 대체 블랙리스트
  • 목록 교체 허용 화이트리스트
  • 2차 대체 슬레이브
  • master 라는 단어는 컨텍스트에 따라 더 정확한 언어로 교체됩니다.

    • IdM 서버가 IdM 마스터교체
    • CA 갱신 서버가 CA 갱신 마스터교체
    • CRL 게시자 서버가 CRL 마스터교체
    • 멀티 공급자 대체 멀티 마스터

Red Hat 문서에 관한 피드백 제공

문서에 대한 피드백에 감사드립니다. 어떻게 개선할 수 있는지 알려주십시오.

특정 문구에 대한 의견 제출

  1. Multi-page HTML 형식으로 설명서를 보고 페이지가 완전히 로드된 후 오른쪽 상단 모서리에 피드백 버튼이 표시되는지 확인합니다.
  2. 커서를 사용하여 주석 처리할 텍스트 부분을 강조 표시합니다.
  3. 강조 표시된 텍스트 옆에 표시되는 피드백 추가 버튼을 클릭합니다.
  4. 의견을 추가하고 제출 을 클릭합니다.

Jira를 통해 피드백 제출 (등록 필요)

  1. Jira 웹 사이트에 로그인합니다.
  2. 상단 탐색 모음에서 생성 을 클릭합니다.
  3. Summary (요약) 필드에 설명 제목을 입력합니다.
  4. Description (설명) 필드에 개선을 위한 제안을 입력합니다. 문서의 관련 부분에 대한 링크를 포함합니다.
  5. 대화 상자 하단에서 생성 을 클릭합니다.

1장. IdM 명령줄 유틸리티 소개

IdM(Identity Management) 명령줄 유틸리티 사용의 기본 사항에 대해 자세히 알아보십시오.

사전 요구 사항

1.1. IPA 명령줄 인터페이스란 무엇입니까?

IPA 명령줄 인터페이스(CLI)는 IdM(Identity Management) 관리를 위한 기본 명령줄 인터페이스입니다.

IdM을 관리하는 다양한 하위 명령(예: ipa user-add 명령)을 지원하여 새 사용자를 추가합니다.

IPA CLI를 사용하면 다음을 수행할 수 있습니다.

  • 네트워크에서 사용자, 그룹, 호스트 및 기타 오브젝트를 추가, 관리 또는 제거합니다.
  • 인증서를 관리합니다.
  • 검색 항목.
  • 오브젝트를 표시하고 나열합니다.
  • 액세스 권한을 설정합니다.
  • 올바른 명령 구문에 대한 도움말을 가져옵니다.

1.2. IPA 도움말이란 무엇입니까?

IPA 도움말은 IdM 서버를 위한 기본 제공 문서 시스템입니다.

IPA 명령줄 인터페이스(CLI)는 로드된 IdM 플러그인 모듈의 사용 가능한 도움말 주제를 생성합니다. IPA 도움말 유틸리티를 사용하려면 다음이 필요합니다.

  • IdM 서버가 설치되어 실행 중이어야 합니다.
  • 유효한 Kerberos 티켓을 사용하여 인증합니다.

옵션 없이 ipa help 명령을 입력하면 기본 도움말 사용과 가장 일반적인 명령 예제에 대한 정보가 표시됩니다.

다음 옵션을 다양한 ipa 도움말 사용 사례에 사용할 수 있습니다.

$ ipa help [TOPIC | COMMAND | topics | commands]
  • [] "모든 매개변수는 선택 사항이며 ipa 도움말 만 쓸 수 있으며 명령을 실행할 수 있습니다.
  • | 파이프 문자는 또는 을 의미합니다. 따라서 기본 ipa help 명령을 사용하여 topIC , COMMAND 또는 주제 또는 명령을 지정할 수 있습니다.

    • 주제: ipa 도움말 주제를 실행하여 IPA 도움말 (예: 사용자, 인증서,서버 등)의 항목 목록을 표시할 수 있습니다.
    • top /Enical letters 있는 I/E는 변수입니다. 따라서 특정 주제(예: ipa help 사용자 )를 지정할 수 있습니다.
    • ipa help 명령을 입력하여 IPA 도움말(예: user-add,ca-enable,server-show 등)의 명령 목록을 표시할 수 있습니다.
    •  /도: 대문자로 된 Command MAND는 변수입니다. 따라서 ipa help user-add 와 같은 특정 명령을 지정할 수 있습니다.

1.3. IPA 도움말 주제 사용

다음 절차에서는 명령줄 인터페이스에서 IPA 도움말을 사용하는 방법을 설명합니다.

절차

  1. 터미널을 열고 IdM 서버에 연결합니다.
  2. ipa 도움말 주제를 입력하여 도움말에서 다루는 주제 목록을 표시합니다.

    $ ipa help topics
  3. 주제 중 하나를 선택하고 다음 패턴에 따라 명령을 만듭니다. ipa help [topic_name]. topic_name 문자열 대신 이전 단계에서 나열한 주제 중 하나를 추가합니다.

    이 예제에서는 다음 주제를 사용합니다. user

    $ ipa help user
  4. IPA 도움말 출력이 너무 길어 전체 텍스트를 볼 수 없는 경우 다음 구문을 사용하십시오.

    $ ipa help user | less

    그런 다음 아래로 스크롤하여 전체 도움을 읽을 수 있습니다.

IPA CLI에는 사용자 항목에 대한 도움말 페이지가 표시됩니다. 개요를 읽은 후 주제 명령 작업을 위한 패턴의 많은 예제를 볼 수 있습니다.

1.4. IPA 도움말 명령 사용

다음 절차에서는 명령줄 인터페이스에서 IPA 도움말 명령을 만드는 방법을 설명합니다.

절차

  1. 터미널을 열고 IdM 서버에 연결합니다.
  2. ipa help 명령을 입력하여 도움말에서 다루는 명령 목록을 표시합니다.

    $ ipa help commands
  3. 명령 중 하나를 선택하고 다음 패턴에 따라 help 명령을 생성합니다. ipa help < COMMAND>. &lt ;COMMAND& gt; 문자열 대신 이전 단계에서 나열한 명령 중 하나를 추가합니다.

    $ ipa help user-add

추가 리소스

  • ipa man 페이지.

1.5. IPA 명령 구조

IPA CLI는 다음 유형의 명령을 구분합니다.

  • IdM 서버에서 기본 제공 명령 tekton-databind built-in 명령을 모두 사용할 수 있습니다.
  • 플러그인 제공 명령

IPA 명령의 구조를 사용하면 다양한 유형의 오브젝트를 관리할 수 있습니다. 예를 들면 다음과 같습니다.

  • 사용자,
  • 호스트,
  • DNS 레코드,
  • 인증서,

그리고 더 많은

이러한 오브젝트 대부분에서 IPA CLI에는 다음과 같은 명령이 포함되어 있습니다.

  • 추가(추가)
  • 수정 (mod)
  • 삭제(del)
  • 검색 (찾기)
  • 표시(표시)

명령에는 다음과 같은 구조가 있습니다.

ipa user-add, ipa user-mod, ipa user-del, ipa user-find, ipa user-show

ipa host-add, ipa host-mod, ipa host-del, ipa host-find, ipa host-show

ipa dns record-add,ipa dns records-mod,ipa dns records-del,ipa dns records-find,ipa dn records-show

ipa user-add [options] 를 사용하여 사용자를 생성할 수 있습니다. 여기서 [options] 는 선택 사항입니다. ipa user-add 명령만 사용하면 스크립트에서 하나씩 세부 정보를 요청합니다.

기존 오브젝트를 변경하려면 오브젝트를 정의해야 합니다. 따라서 명령에는 오브젝트 ipa user-mod USER_NAME [options] 도 포함됩니다.

1.6. IPA 명령을 사용하여 IdM에 사용자 계정 추가

다음 절차에서는 명령줄을 사용하여 IdM(Identity Management) 데이터베이스에 새 사용자를 추가하는 방법을 설명합니다.

사전 요구 사항

  • IdM 서버에 사용자 계정을 추가하려면 관리자 권한이 있어야 합니다.

절차

  1. 터미널을 열고 IdM 서버에 연결합니다.
  2. 새 사용자를 추가하려면 명령을 입력합니다.

    $ ipa user-add

    이 명령은 사용자 계정을 생성하는 데 필요한 기본 데이터를 제공하도록 요청하는 스크립트를 실행합니다.

  3. First name: 필드에 새 사용자의 첫 번째 이름을 입력하고 Enter 키를 누릅니다.
  4. 성: 필드에 새 사용자의 성을 입력하고 Enter 키를 누릅니다.
  5. User login [suggested user name]: 사용자 이름을 입력하거나 Enter 키를 눌러 제안된 사용자 이름을 수락합니다.

    사용자 이름은 전체 IdM 데이터베이스에 대해 고유해야 합니다. 해당 사용자 이름이 이미 존재하기 때문에 오류가 발생하면 ipa user-add 명령을 사용하여 프로세스를 반복하고 다른 고유한 사용자 이름을 사용합니다.

사용자 이름을 추가한 후 사용자 계정이 IdM 데이터베이스에 추가되고 IPA 명령줄 인터페이스(CLI)는 다음 출력을 출력합니다.

----------------------
Added user "euser"
----------------------
User login: euser
First name: Example
Last name: User
Full name: Example User
Display name: Example User
Initials: EU
Home directory: /home/euser
GECOS: Example User
Login shell: /bin/sh
Principal name: euser@IDM.EXAMPLE.COM
Principal alias: euser@IDM.EXAMPLE.COM
Email address: euser@idm.example.com
UID: 427200006
GID: 427200006
Password: False
Member of groups: ipausers
Kerberos keys available: False
참고

기본적으로 사용자 암호는 사용자 계정에 설정되어 있지 않습니다. 사용자 계정을 생성하는 동안 암호를 추가하려면 다음 구문과 함께 ipa user-add 명령을 사용합니다.

$ ipa user-add --first=Example --last=User --password

IPA CLI에서 사용자 이름과 암호를 추가하거나 확인하라는 메시지가 표시됩니다.

사용자가 이미 생성된 경우 ipa user-mod 명령을 사용하여 암호를 추가할 수 있습니다.

추가 리소스

  • 매개변수에 대한 자세한 내용을 보려면 ipa help user-add 명령을 실행합니다.

1.7. IPA 명령을 사용하여 IdM에서 사용자 계정 수정

각 사용자 계정에 대한 여러 매개 변수를 변경할 수 있습니다. 예를 들어 사용자에게 새 암호를 추가할 수 있습니다.

기본 명령 구문은 변경을 수행할 기존 사용자 계정을 정의해야 하므로 user-add 구문과 다릅니다(예: 암호 추가).

사전 요구 사항

  • 사용자 계정을 수정하려면 관리자 권한이 있어야 합니다.

절차

  1. 터미널을 열고 IdM 서버에 연결합니다.
  2. ipa user-mod 명령을 입력하고 수정할 사용자를 지정하고, 암호를 추가하기 위해 --password 와 같은 옵션을 지정합니다.

    $ ipa user-mod euser --password

    이 명령은 새 암호를 추가할 수 있는 스크립트를 실행합니다.

  3. 새 암호를 입력하고 Enter 키를 누릅니다.

IPA CLI는 다음 출력을 출력합니다.

----------------------
Modified user "euser"
----------------------
User login: euser
First name: Example
Last name: User
Home directory: /home/euser
Principal name: euser@IDM.EXAMPLE.COM
Principal alias: euser@IDM.EXAMPLE.COM
Email address: euser@idm.example.com
UID: 427200006
GID: 427200006
Password: True
Member of groups: ipausers
Kerberos keys available: True

이제 계정에 사용자 암호가 설정되어 사용자가 IdM에 로그인할 수 있습니다.

추가 리소스

  • 매개변수에 대한 자세한 내용은 ipa help user-mod 명령을 실행합니다.

1.8. IdM 유틸리티에 값 목록을 제공하는 방법

IdM(Identity Management)은 목록에 다중 값 특성 값을 저장합니다.

IdM은 다음과 같은 다중 값 목록을 제공하는 방법을 지원합니다.

  • 동일한 명령 호출 내에서 동일한 명령줄 인수를 여러 번 사용합니다.

    $ ipa permission-add --right=read --permissions=write --permissions=delete ...
  • 또는 목록을 중괄호로 묶을 수 있습니다. 이 경우 쉘이 확장을 수행합니다.

    $ ipa permission-add --right={read,write,delete} ...

위의 예제에서는 오브젝트에 권한을 추가하는 permission-add 명령을 보여줍니다. 이 예제에서는 개체를 언급하지 않습니다. …​ 대신 권한을 추가할 오브젝트를 추가해야 합니다.

명령줄에서 이러한 다중 값 속성을 업데이트하면 IdM에서 이전 값 목록을 새 목록으로 완전히 덮어씁니다. 따라서 다중 값 특성을 업데이트할 때 추가하려는 단일 값이 아닌 전체 새 목록을 지정해야 합니다.

예를 들어 위의 명령에서 권한 목록에 읽기, 쓰기 및 삭제가 포함됩니다. permission-mod 명령으로 목록을 업데이트하려면 모든 값을 추가해야 합니다. 그렇지 않으면 언급되지 않은 값이 삭제됩니다.

예 1: ipa permission-mod 명령은 이전에 추가된 모든 권한을 업데이트합니다.

$ ipa permission-mod --right=read --right=write --right=delete ...

또는

$ ipa permission-mod --right={read,write,delete} ...

예 2 ​​ - ipa permission-mod 명령은 명령에 포함되지 않기 때문에 --right=delete 인수를 삭제합니다.

$ ipa permission-mod --right=read --right=write ...

또는

$ ipa permission-mod --right={read,write} ...

1.9. IdM 유틸리티와 특수 문자를 사용하는 방법

ipa 명령에 특수 문자가 포함된 명령줄 인수를 전달할 때 이러한 문자를 백슬래시(\)로 이스케이프합니다. 예를 들어, 일반적인 특수 문자에는 각도 대괄호(< 및 >), 앰퍼샌드(&), 별표(*) 또는 수직 표시줄(|)이 포함됩니다.

예를 들어 별표(*)를 이스케이프하려면 다음을 수행합니다.

$ ipa certprofile-show certificate_profile --out=exported\*profile.cfg

쉘에서 이러한 문자를 올바르게 구문 분석할 수 없기 때문에 이스케이프되지 않은 특수 문자가 포함된 명령은 예상대로 작동하지 않습니다.

2장. 명령줄을 사용하여 사용자 계정 관리

IdM(Identity Management)의 사용자 라이프사이클에는 다음을 포함하여 여러 단계가 있습니다.

  • 사용자 계정 만들기
  • 단계 사용자 계정 활성화
  • 사용자 계정 보존
  • 활성, 스테이징 또는 사용자 계정 삭제
  • 보존된 사용자 계정 복원

2.1. 사용자 라이프 사이클

IdM(Identity Management)은 세 가지 사용자 계정 상태를 지원합니다.

  • 스테이징 사용자는 인증이 허용되지 않습니다. 초기 상태입니다. 활성 사용자에게 필요한 일부 사용자 계정 속성은 예를 들어 그룹 멤버십을 설정할 수 없습니다.
  • 활성 사용자는 인증을 허용합니다. 필요한 모든 사용자 계정 속성은 이 상태에서 설정해야 합니다.
  • 보존된 사용자는 비활성으로 간주되고 IdM에 인증할 수 없는 이전 활성 사용자입니다. 보존된 사용자는 활성 사용자로 보유한 계정 속성의 대부분을 유지하지만 사용자 그룹의 일부가 아닙니다.

A flow chart displaying 4 items: Active users - Stage users - Preserved users - Deleted users. Arrows communicate the relationships between each kind of user: Active users can be "preserved" as Preserved users. Preserved users can be "restored" as Active users. Preserved users can be "staged" as Stage users and Stage users can be "activated" into Active users. All users can be deleted to become "Deleted users".

IdM 데이터베이스에서 영구적으로 사용자 항목을 삭제할 수 있습니다.

중요

삭제된 사용자 계정은 복원할 수 없습니다. 사용자 계정을 삭제하면 계정과 연결된 모든 정보가 영구적으로 손실됩니다.

새 관리자는 기본 admin 사용자와 같은 관리자 권한이 있는 사용자만 만들 수 있습니다. 모든 관리자 계정을 실수로 삭제한 경우 Directory Manager에서 Directory Server에서 새 관리자를 수동으로 생성해야 합니다.

주의

admin 사용자를 삭제하지 마십시오. admin 은 IdM에 필요한 사전 정의된 사용자이므로 이 작업으로 인해 특정 명령에서 문제가 발생합니다. 대체 admin 사용자를 정의하고 사용하려는 경우 하나 이상의 다른 사용자에게 admin 권한을 부여한 후 ipa 사용자 비활성화 admin으로 사전 정의된 admin 사용자를 비활성화합니다.

주의

IdM에 로컬 사용자를 추가하지 마십시오. NSS(Name Service Switch)는 로컬 사용자 및 그룹을 확인하기 전에 항상 IdM 사용자 및 그룹을 확인합니다. 즉, IdM 그룹 멤버십은 로컬 사용자에게 작동하지 않습니다.

2.2. 명령줄을 사용하여 사용자 추가

다음과 같이 사용자를 추가할 수 있습니다.

  • 활성 메세지 - 사용자가 적극적으로 사용할 수 있는 사용자 계정.
  • 스테이징 -암호사용자는 이러한 계정을 사용할 수 없습니다. 새 사용자 계정을 준비하려면 이 파일을 사용합니다. 사용자가 자신의 계정을 사용할 준비가 되면 활성화할 수 있습니다.

다음 절차에서는 ipa user-add 명령을 사용하여 IdM 서버에 활성 사용자를 추가하는 방법을 설명합니다.

마찬가지로 ipa stageuser-add 명령을 사용하여 스테이징 사용자 계정을 생성할 수 있습니다.

참고

IdM은 고유한 사용자 ID(UID)를 새 사용자 계정에 자동으로 할당합니다. 이 작업을 수동으로 수행할 수도 있지만 서버에서 UID 번호가 고유한지 여부를 확인하지 않습니다. 이로 인해 여러 사용자 항목이 동일한 ID 번호가 할당될 수 있습니다. 동일한 UID가 있는 여러 항목이 없는 것을 방지하는 것이 좋습니다.

사전 요구 사항

절차

  1. 터미널을 열고 IdM 서버에 연결합니다.
  2. 사용자 로그인, 사용자의 이름, 성을 추가하고 필요한 경우 이메일 주소를 추가할 수도 있습니다.

    $ ipa user-add user_login --first=first_name --last=last_name --email=email_address

    IdM에서는 다음 정규식으로 설명할 수 있는 사용자 이름을 지원합니다.

    [a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?
    참고

    후행 달러 기호($)로 끝나는 사용자 이름은 Samba 3.x 시스템 지원을 활성화하기 위해 지원됩니다.

    대문자가 포함된 사용자 이름을 추가하는 경우 IdM은 자동으로 이름을 저장할 때 소문자로 변환합니다. 따라서 IdM은 로그인할 때 항상 사용자 이름을 소문자로 입력해야 합니다. 또한 사용자 및 사용자 등 문자 캐싱에서만 다른 사용자 이름을 추가할 수 없습니다 .

    사용자 이름의 기본 최대 길이는 32자입니다. 변경하려면 ipa config-mod --maxusername 명령을 사용합니다. 예를 들어 최대 사용자 이름 길이를 64자로 늘리려면 다음을 수행합니다.

    $ ipa config-mod --maxusername=64
     Maximum username length: 64
     ...

    ipa user-add 명령에는 많은 매개 변수가 포함되어 있습니다. 모두 나열하려면 ipa help 명령을 사용합니다.

    $ ipa help user-add

    ipa help 명령에 대한 자세한 내용은 IPA 도움말을 참조하십시오.

모든 IdM 사용자 계정을 나열하여 새 사용자 계정이 성공적으로 생성되었는지 확인할 수 있습니다.

$ ipa user-find

이 명령은 세부 정보가 있는 모든 사용자 계정을 나열합니다.

2.3. 명령줄을 사용하여 사용자 활성화

사용자 계정을 스테이지에서 활성으로 이동하여 활성화하려면 ipa stageuser-activate 명령을 사용합니다.

사전 요구 사항

절차

  1. 터미널을 열고 IdM 서버에 연결합니다.
  2. 다음 명령으로 사용자 계정을 활성화합니다.

    $ ipa stageuser-activate user_login
    -------------------------
    Stage user user_login activated
    -------------------------
    ...

모든 IdM 사용자 계정을 나열하여 새 사용자 계정이 성공적으로 생성되었는지 확인할 수 있습니다.

$ ipa user-find

이 명령은 세부 정보가 있는 모든 사용자 계정을 나열합니다.

2.4. 명령줄을 사용하여 사용자 보존

사용자 계정을 삭제하려면 보존할 수 있지만 나중에 복원할 수 있는 옵션을 유지합니다. 사용자 계정을 유지하려면 ipa user-del 또는 ipa stageuser-del 명령과 함께 --preserve 옵션을 사용합니다.

사전 요구 사항

절차

  1. 터미널을 열고 IdM 서버에 연결합니다.
  2. 다음 명령을 사용하여 사용자 계정을 보존합니다.

    $ ipa user-del --preserve user_login
    --------------------
    Deleted user "user_login"
    --------------------
    참고

    사용자 계정이 삭제되었다는 출력에도 불구하고 보존되었습니다.

2.5. 명령줄을 사용하여 사용자 삭제

IdM(ID 관리)을 사용하면 사용자를 영구적으로 삭제할 수 있습니다. 다음을 삭제할 수 있습니다.

  • 다음 명령을 사용하는 활성 사용자: ipa user-del
  • 다음 명령을 사용하여 사용자 준비: ipa stageuser-del
  • 다음 명령을 사용하여 사용자 보존: ipa user-del

여러 사용자를 삭제하는 경우 --continue 옵션을 사용하여 오류에 관계없이 명령이 계속되도록 합니다. 명령이 완료되면 성공 및 실패한 작업의 요약이 stdout 표준 출력 스트림에 출력됩니다.

$ ipa user-del --continue user1 user2 user3

--continue 를 사용하지 않는 경우 명령은 오류가 발생할 때까지 사용자 삭제를 진행합니다. 이 경우 이 명령이 중지되고 종료됩니다.

사전 요구 사항

절차

  1. 터미널을 열고 IdM 서버에 연결합니다.
  2. 다음 명령을 사용하여 사용자 계정을 삭제합니다.

    $ ipa user-del user_login
    --------------------
    Deleted user "user_login"
    --------------------

사용자 계정이 IdM에서 영구적으로 삭제되었습니다.

2.6. 명령줄을 사용하여 사용자 복원

보존된 사용자를 다음과 같이 복원할 수 있습니다.

  • 활성 사용자: ipa user-undel
  • 단계 사용자: ipa 사용자 단계

사용자 계정을 복원해도 계정의 이전 속성이 모두 복원되지는 않습니다. 예를 들어 사용자의 암호가 복원되지 않으므로 다시 설정해야 합니다.

사전 요구 사항

절차

  1. 터미널을 열고 IdM 서버에 연결합니다.
  2. 다음 명령으로 사용자 계정을 활성화합니다.

    $ ipa user-undel user_login
    ------------------------------
    Undeleted user account "user_login"
    ------------------------------

    또는 사용자 계정을 스테이징된 상태로 복원할 수 있습니다.

    $ ipa user-stage user_login
    ------------------------------
    Staged user account "user_login"
    ------------------------------

검증 단계

  • 모든 IdM 사용자 계정을 나열하여 새 사용자 계정이 성공적으로 생성되었는지 확인할 수 있습니다.

    $ ipa user-find

    이 명령은 세부 정보가 있는 모든 사용자 계정을 나열합니다.

3장. IdM 웹 UI를 사용하여 사용자 계정 관리

IdM(Identity Management)은 다양한 사용자 라이프사이클 상황을 관리하는 데 도움이 되는 여러 단계를 제공합니다.

사용자 계정 생성

직원이 회사에서 경력을 시작하기 전에 단계 사용자 계정을 만들고 직원이 사무실에 나타나면 계정을 활성화하려는 날을 미리 준비하십시오.

이 단계를 생략하고 활성 사용자 계정을 직접 만들 수 있습니다. 절차는 stage 사용자 계정 생성과 유사합니다.

사용자 계정 활성화
직원의 첫 근무일 계정 활성화.
사용자 계정 비활성화
사용자가 몇 개월 동안 부모의 휴가 로 이동하는 경우 계정을 일시적으로 비활성화해야 합니다.
사용자 계정 활성화
사용자가 반환되면 계정을 다시 활성화해야 합니다.
사용자 계정 보존
사용자가 퇴사하려는 경우 계정이 다시 복원될 가능성이 있는 경우 나중에 회사로 돌아갈 수 있기 때문에 계정을 삭제해야 합니다.
사용자 계정 복원
2년 후 사용자가 다시 시작되어 보존된 계정을 복원해야 합니다.
사용자 계정 삭제
직원이 차감된 경우 백업없이 계정을 삭제합니다.

3.1. 사용자 라이프 사이클

IdM(Identity Management)은 세 가지 사용자 계정 상태를 지원합니다.

  • 스테이징 사용자는 인증이 허용되지 않습니다. 초기 상태입니다. 활성 사용자에게 필요한 일부 사용자 계정 속성은 예를 들어 그룹 멤버십을 설정할 수 없습니다.
  • 활성 사용자는 인증을 허용합니다. 필요한 모든 사용자 계정 속성은 이 상태에서 설정해야 합니다.
  • 보존된 사용자는 비활성으로 간주되고 IdM에 인증할 수 없는 이전 활성 사용자입니다. 보존된 사용자는 활성 사용자로 보유한 계정 속성의 대부분을 유지하지만 사용자 그룹의 일부가 아닙니다.

A flow chart displaying 4 items: Active users - Stage users - Preserved users - Deleted users. Arrows communicate the relationships between each kind of user: Active users can be "preserved" as Preserved users. Preserved users can be "restored" as Active users. Preserved users can be "staged" as Stage users and Stage users can be "activated" into Active users. All users can be deleted to become "Deleted users".

IdM 데이터베이스에서 영구적으로 사용자 항목을 삭제할 수 있습니다.

중요

삭제된 사용자 계정은 복원할 수 없습니다. 사용자 계정을 삭제하면 계정과 연결된 모든 정보가 영구적으로 손실됩니다.

새 관리자는 기본 admin 사용자와 같은 관리자 권한이 있는 사용자만 만들 수 있습니다. 모든 관리자 계정을 실수로 삭제한 경우 Directory Manager에서 Directory Server에서 새 관리자를 수동으로 생성해야 합니다.

주의

admin 사용자를 삭제하지 마십시오. admin 은 IdM에 필요한 사전 정의된 사용자이므로 이 작업으로 인해 특정 명령에서 문제가 발생합니다. 대체 admin 사용자를 정의하고 사용하려는 경우 하나 이상의 다른 사용자에게 admin 권한을 부여한 후 ipa 사용자 비활성화 admin으로 사전 정의된 admin 사용자를 비활성화합니다.

주의

IdM에 로컬 사용자를 추가하지 마십시오. NSS(Name Service Switch)는 로컬 사용자 및 그룹을 확인하기 전에 항상 IdM 사용자 및 그룹을 확인합니다. 즉, IdM 그룹 멤버십은 로컬 사용자에게 작동하지 않습니다.

3.2. 웹 UI에서 사용자 추가

일반적으로 새 직원이 작동하기 전에 새 사용자 계정을 만들어야 합니다. 이러한 단계 계정에 액세스할 수 없으며 나중에 활성화해야 합니다.

참고

또는 활성 사용자 계정을 직접 만들 수도 있습니다. 활성 사용자를 추가하려면 아래 절차를 따르고 Active users (활성 사용자) 탭에 사용자 계정을 추가합니다.

사전 요구 사항

  • IdM 또는 사용자 관리자 역할을 관리하기 위한 관리자 권한.

절차

  1. IdM 웹 UI에 로그인합니다.

    자세한 내용은 웹 브라우저에서 IdM 웹 UI 액세스를 참조하십시오.

  2. 사용자 → 사용자 단계 탭으로 이동합니다.

    또는 사용자 → 활성 사용자에게 사용자 계정을 추가할 수도 있지만 계정에 사용자 그룹을 추가할 수는 없습니다.

  3. + Add(추가) 아이콘을 클릭합니다.
  4. Add stage user ( 단계 사용자 추가) 대화 상자에 새 사용자의 이름 및 이름을 입력합니다.
  5. [선택 사항] 사용자 로그인 필드에 로그인 이름을 추가합니다.

    비워 두면 IdM 서버에서 다음 패턴으로 로그인 이름을 생성합니다. 이름 및 성의 첫 글자. 전체 로그인 이름은 최대 32자를 가질 수 있습니다.

  6. [선택 사항] GID 드롭다운 메뉴에서 사용자가 포함해야 하는 그룹을 선택합니다.
  7. [선택 사항] PasswordVerify password 필드에 암호를 입력하고 확인하고 둘 다 일치하는지 확인합니다.
  8. Add(추가) 단추를 클릭합니다.

    Screenshot of the "Add stage user" pop-up window with the "New Password" the "Verify Password" fields filled in. The "Add" button is at the bottom left.

이때 Stage Users (사용자 단계) 테이블에 사용자 계정을 볼 수 있습니다.

Screenshot of the IdM Web UI showing user entries in the Stage Users table. This is selected from the Identity tab - the Users sub-tab - and the Stage users category listed on the left.

참고

사용자 이름을 클릭하면 전화 번호, 주소 또는 바우처 추가와 같은 고급 설정을 편집할 수 있습니다.

3.3. IdM 웹 UI에서 단계 사용자 활성화

사용자가 IdM에 로그인하기 전에 및 IdM 그룹에 사용자를 추가하기 전에 stage 사용자 계정을 활성화하려면 다음 절차를 따라야 합니다.

사전 요구 사항

  • IdM 웹 UI 또는 사용자 관리자 역할을 관리하는 관리자 권한.
  • IdM에서 하나 이상의 준비 사용자 계정.

절차

  1. IdM 웹 UI에 로그인합니다.

    자세한 내용은 웹 브라우저에서 IdM 웹 UI 액세스를 참조하십시오.

  2. 사용자 → 사용자 탭으로 이동합니다.
  3. 활성화하려는 사용자 계정의 확인란을 클릭합니다.
  4. Activate(활성화 ) 버튼을 클릭합니다.

    Screenshot of the IdM Web UI showing user entries in the "Stage Users" table. This is selected from the Identity tab - the Users sub-tab - and the Stage users category listed on the left.

  5. 확인 대화 상자에서 확인을 클릭합니다.

활성화에 성공하면 IdM 웹 UI에 사용자가 활성화되고 사용자 계정이 Active users 로 이동한 녹색 확인이 표시됩니다. 계정이 활성 상태이며 사용자가 IdM 도메인 및 IdM 웹 UI에 인증할 수 있습니다. 처음 로그인할 때 암호를 변경하라는 메시지가 표시됩니다.

Screenshot of the IdM Web UI showing the "staged.user" user entry in the "Active Users" table. Its status is "enabled."

참고

이 단계에서는 활성 사용자 계정을 사용자 그룹에 추가할 수 있습니다.

3.4. 웹 UI에서 사용자 계정 비활성화

활성 사용자 계정을 비활성화할 수 있습니다. 사용자 계정을 비활성화하면 계정을 비활성화하므로 사용자 계정을 사용하여 Kerberos와 같은 IdM 서비스를 인증하거나 모든 작업을 수행할 수 없습니다.

비활성화된 사용자 계정은 IdM 내에 계속 있으며 연결된 모든 정보는 변경되지 않습니다. 보존된 사용자 계정과 달리 비활성화된 사용자 계정이 활성 상태로 유지되며 사용자 그룹의 멤버가 될 수 있습니다.

참고

사용자 계정을 비활성화한 후 기존 연결은 사용자의 Kerberos TGT 및 기타 티켓이 만료될 때까지 유효합니다. 티켓이 만료되면 사용자는 이를 갱신할 수 없습니다.

사전 요구 사항

  • IdM 웹 UI 또는 사용자 관리자 역할을 관리하는 관리자 권한.

절차

  1. IdM 웹 UI에 로그인합니다.

    자세한 내용은 웹 브라우저에서 IdM 웹 UI 액세스를 참조하십시오.

  2. 사용자 → 활성 사용자 탭으로 이동합니다.
  3. 비활성화하려는 사용자 계정의 확인란을 클릭합니다.
  4. Disable(비활성화 ) 버튼을 클릭합니다.

    Screenshot of the "Active Users" page with a table displaying attributes for several users such as User login - First name - Last name - Status - UID - Email address - Telephone Number - Job Title. The entry for the "euser" account has been highlighted and so have the "Enable" and "Disable" buttons at the top right.

  5. Confirmation(확인 ) 대화 상자에서 OK (확인) 버튼을 클릭합니다.

비활성화 절차가 성공한 경우 Active users (활성 사용자) 테이블의 Status(상태) 열에서 확인할 수 있습니다.

Screenshot of the same "Active Users" page with the table displaying attributes for several users. The "euser" account is now greyed-out and shows "Disabled" in its "Status" column.

3.5. 웹 UI에서 사용자 계정 활성화

IdM을 사용하면 비활성화된 활성 사용자 계정을 활성화할 수 있습니다. 사용자 계정을 활성화하면 비활성화된 계정을 활성화합니다.

사전 요구 사항

  • IdM 웹 UI 또는 사용자 관리자 역할을 관리하는 관리자 권한.

절차

  1. IdM 웹 UI에 로그인합니다.
  2. 사용자 → 활성 사용자 탭으로 이동합니다.
  3. 활성화하려는 사용자 계정의 확인란을 클릭합니다.
  4. Enable 단추를 클릭합니다.

    Screenshot of the "Active Users" page with a table displaying attributes for several users such as User login - First name - Last name - Status - UID - Email address - Telephone Number - Job Title. The entry for the "euser" account has been highlighted and so have the "Enable" and "Disable" buttons at the top right.

  5. Confirmation(확인 ) 대화 상자에서 OK (확인) 버튼을 클릭합니다.

변경이 성공적으로 수행된 경우 Active users (활성 사용자) 테이블의 Status(상태) 열에서 확인할 수 있습니다.

3.6. IdM 웹 UI에서 활성 사용자 보존

사용자 계정을 보존하면 Active users 탭에서 계정을 제거할 수 있지만 이러한 계정을 IdM에 유지할 수 있습니다.

직원이 퇴사하는 경우 사용자 계정을 보존합니다. 몇 주 또는 몇 달 동안 사용자 계정을 비활성화하려면(예:임시 휴가) 계정을 비활성화하십시오. 자세한 내용은 웹 UI에서 사용자 계정 비활성화를 참조하십시오. 보존된 계정은 활성 상태가 아니므로 사용자가 내부 네트워크에 액세스하는 데 사용할 수 없지만 계정은 모든 데이터가 있는 데이터베이스에 남아 있습니다.

복원된 계정을 활성 모드로 다시 이동할 수 있습니다.

참고

보존 상태에 있는 사용자 목록은 과거 사용자 계정 기록을 제공할 수 있습니다.

사전 요구 사항

  • IdM(ID 관리) 웹 UI 또는 사용자 관리자 역할을 관리하는 관리자 권한.

절차

  1. IdM 웹 UI에 로그인합니다.

    자세한 내용은 웹 브라우저에서 IdM 웹 UI 액세스를 참조하십시오.

  2. 사용자 → 활성 사용자 탭으로 이동합니다.
  3. 보존할 사용자 계정의 확인란을 클릭합니다.
  4. Delete(삭제) 단추를 클릭합니다.

    A screenshot of the "Active Users" page displaying a table of users. The checkbox for the entry for the "preserved.user" account has been checked and the "Delete" button at the top is highlighted.

  5. Remove users(사용자 제거 ) 대화 상자에서 Delete mode(삭제 모드) 라디오 버튼을 전환하여 보존합니다.
  6. Delete(삭제) 단추를 클릭합니다.

    A screenshot of a pop-up window titled "Remove users." The contents say "Are you sure you want to delete selected entries?" and specifies "preserved.user" below. There is a label "Delete mode" with two radial options: "delete" and "preserve" (which is selected). There are "Delete" and "Cancel" buttons at the bottom right corner of the window.

결과적으로 사용자 계정이 보존된 사용자로 이동됩니다.

보존된 사용자를 복원해야 하는 경우 IdM 웹 UI에서 사용자 복원을 참조하십시오.

3.7. IdM 웹 UI에서 사용자 복원

IdM(Identity Management)을 사용하면 보존된 사용자 계정을 활성 상태로 다시 복원할 수 있습니다. 보존된 사용자를 활성 사용자 또는 단계 사용자로 복원할 수 있습니다.

사전 요구 사항

  • IdM 웹 UI 또는 사용자 관리자 역할을 관리하는 관리자 권한.

절차

  1. IdM 웹 UI에 로그인합니다.

    자세한 내용은 웹 브라우저에서 IdM 웹 UI 액세스를 참조하십시오.

  2. 사용자 → 보존된 사용자 탭으로 이동합니다.
  3. 복원할 사용자 계정에서 체크박스를 클릭합니다.
  4. Restore (복구) 버튼을 클릭합니다.

    A screenshot of the "Preserved users" page displaying a table of users and their attributes. The checkbox next to one user entry is checked and the "Restore" button at the top right is highlighted.

  5. Confirmation(확인 ) 대화 상자에서 OK (확인) 버튼을 클릭합니다.

IdM 웹 UI는 녹색 확인을 표시하고 사용자 계정을 Active users (활성 사용자) 탭으로 이동합니다.

3.8. IdM 웹 UI에서 사용자 삭제

사용자를 삭제하는 것은 되돌릴 수 없는 작업이므로 그룹 멤버십 및 암호를 포함하여 사용자 계정이 IdM 데이터베이스에서 영구적으로 삭제됩니다. 시스템 계정 및 홈 디렉터리와 같은 사용자의 외부 구성은 삭제되지 않지만 IdM을 통해 더 이상 액세스할 수 없습니다.

다음을 삭제할 수 있습니다.

  • 활성 사용자 정보 - IdM 웹 UI는 다음과 같은 옵션을 제공합니다.

  • 스테이징 사용자 - 단계 사용자를 영구적으로 삭제할 수 있습니다.
  • 보존된 사용자 - 보존된 사용자를 영구적으로 삭제할 수 있습니다.

다음 절차에서는 활성 사용자 삭제를 설명합니다. 마찬가지로 다음에서 사용자 계정을 삭제할 수 있습니다.

  • Stage users(단계 사용자 ) 탭
  • 보존된 사용자

사전 요구 사항

  • IdM 웹 UI 또는 사용자 관리자 역할을 관리하는 관리자 권한.

절차

  1. IdM 웹 UI에 로그인합니다.

    자세한 내용은 웹 브라우저에서 IdM 웹 UI 액세스를 참조하십시오.

  2. 사용자 → 활성 사용자 탭으로 이동합니다.

    또는 사용자 → 사용자 단계 또는 사용자 → 보존된 사용자의 사용자 계정을 삭제할 수 있습니다.

  3. Delete(삭제) 아이콘을 클릭합니다.
  4. Remove users(사용자 제거 ) 대화 상자에서 Delete mode(삭제 모드 ) 라디오 버튼을 삭제 하도록 전환합니다.
  5. Delete(삭제) 단추를 클릭합니다.

사용자 계정이 IdM에서 영구적으로 삭제되었습니다.

4장. Ansible 플레이북을 사용하여 사용자 계정 관리

Ansible 플레이북을 사용하여 IdM에서 사용자를 관리할 수 있습니다. 사용자 라이프사이클 을 제공한 후 이 장에서는 다음 작업에 Ansible 플레이북을 사용하는 방법을 설명합니다.

4.1. 사용자 라이프 사이클

IdM(Identity Management)은 세 가지 사용자 계정 상태를 지원합니다.

  • 스테이징 사용자는 인증이 허용되지 않습니다. 초기 상태입니다. 활성 사용자에게 필요한 일부 사용자 계정 속성은 예를 들어 그룹 멤버십을 설정할 수 없습니다.
  • 활성 사용자는 인증을 허용합니다. 필요한 모든 사용자 계정 속성은 이 상태에서 설정해야 합니다.
  • 보존된 사용자는 비활성으로 간주되고 IdM에 인증할 수 없는 이전 활성 사용자입니다. 보존된 사용자는 활성 사용자로 보유한 계정 속성의 대부분을 유지하지만 사용자 그룹의 일부가 아닙니다.

A flow chart displaying 4 items: Active users - Stage users - Preserved users - Deleted users. Arrows communicate the relationships between each kind of user: Active users can be "preserved" as Preserved users. Preserved users can be "restored" as Active users. Preserved users can be "staged" as Stage users and Stage users can be "activated" into Active users. All users can be deleted to become "Deleted users".

IdM 데이터베이스에서 영구적으로 사용자 항목을 삭제할 수 있습니다.

중요

삭제된 사용자 계정은 복원할 수 없습니다. 사용자 계정을 삭제하면 계정과 연결된 모든 정보가 영구적으로 손실됩니다.

새 관리자는 기본 admin 사용자와 같은 관리자 권한이 있는 사용자만 만들 수 있습니다. 모든 관리자 계정을 실수로 삭제한 경우 Directory Manager에서 Directory Server에서 새 관리자를 수동으로 생성해야 합니다.

주의

admin 사용자를 삭제하지 마십시오. admin 은 IdM에 필요한 사전 정의된 사용자이므로 이 작업으로 인해 특정 명령에서 문제가 발생합니다. 대체 admin 사용자를 정의하고 사용하려는 경우 하나 이상의 다른 사용자에게 admin 권한을 부여한 후 ipa 사용자 비활성화 admin으로 사전 정의된 admin 사용자를 비활성화합니다.

주의

IdM에 로컬 사용자를 추가하지 마십시오. NSS(Name Service Switch)는 로컬 사용자 및 그룹을 확인하기 전에 항상 IdM 사용자 및 그룹을 확인합니다. 즉, IdM 그룹 멤버십은 로컬 사용자에게 작동하지 않습니다.

4.2. Ansible 플레이북을 사용하여 IdM 사용자가 있는지 확인

다음 절차에서는 Ansible 플레이북을 사용하여 IdM에 사용자가 있는지 확인하는 방법을 설명합니다.

사전 요구 사항

  • IdM 관리자 암호를 알고 있습니다.
  • 다음 요구 사항을 충족하도록 Ansible 제어 노드를 구성했습니다.

    • Ansible 버전 2.14 이상을 사용하고 있습니다.
    • Ansible 컨트롤러에 ansible-freeipa 패키지가 설치되어 있습니다.
    • 이 예제에서는 ~/MyPlaybook/ 디렉터리에서 IdM 서버의 FQDN(정규화된 도메인 이름)을 사용하여 Ansible 인벤토리 파일을 생성했다고 가정합니다.
    • 이 예제에서는 secret.yml Ansible 자격 증명 모음이 ipaadmin_password 를 저장하는 것으로 가정합니다.

절차

  1. 인벤토리 파일(예: inventory.file )을 생성하고 여기에 ipaserver 를 정의합니다.

    [ipaserver]
    server.idm.example.com
  2. IdM에 있는 사용자의 데이터를 사용하여 Ansible 플레이북 파일을 생성합니다. 이 단계를 간소화하기 위해 /usr/share/doc/ansible-freeipa/playbooks/user/add-user.yml 파일에서 예제를 복사하고 수정할 수 있습니다. 예를 들어 idm_user 라는 사용자를 생성하고 Password123 을 사용자 암호로 추가하려면 다음을 수행합니다.

    ---
    - name: Playbook to handle users
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Create user idm_user
        ipauser:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: idm_user
          first: Alice
          last: Acme
          uid: 1000111
          gid: 10011
          phone: "+555123457"
          email: idm_user@acme.com
          passwordexpiration: "2023-01-19 23:59:59"
          password: "Password123"
          update_password: on_create

    사용자를 추가하려면 다음 옵션을 사용해야 합니다.

    • name: 로그인 이름
    • first: 첫 번째 이름 문자열
    • last: 성 문자열

    사용 가능한 사용자 옵션의 전체 목록은 /usr/share/doc/ansible-freeipa/README-user.md Markdown 파일을 참조하십시오.

    참고

    update_password: on_create 옵션을 사용하는 경우 Ansible은 사용자를 생성할 때만 사용자 암호를 생성합니다. 사용자가 이미 암호를 사용하여 생성된 경우 Ansible에서 새 암호를 생성하지 않습니다.

  3. 플레이북을 실행합니다.

    $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-IdM-user.yml

검증 단계

  • ipa user-show 명령을 사용하여 새 사용자 계정이 IdM에 있는지 확인할 수 있습니다.

    1. admin으로 ipaserver 에 로그인합니다.

      $ ssh admin@server.idm.example.com
      Password:
      [admin@server /]$
    2. 관리자용 Kerberos 티켓을 요청합니다.

      $ kinit admin
      Password for admin@IDM.EXAMPLE.COM:
    3. idm_user 에 대한 정보를 요청합니다.

      $ ipa user-show idm_user
        User login: idm_user
        First name: Alice
        Last name: Acme
        ....

    이름이 idm_user 인 사용자는 IdM에 있습니다.

4.3. Ansible Playbook을 사용하여 여러 IdM 사용자가 있는지 확인

다음 절차에서는 Ansible 플레이북을 사용하여 IdM에 여러 사용자가 있는지 확인하는 방법을 설명합니다.

사전 요구 사항

  • IdM 관리자 암호를 알고 있습니다.
  • 다음 요구 사항을 충족하도록 Ansible 제어 노드를 구성했습니다.

    • Ansible 버전 2.14 이상을 사용하고 있습니다.
    • Ansible 컨트롤러에 ansible-freeipa 패키지가 설치되어 있습니다.
    • 이 예제에서는 ~/MyPlaybook/ 디렉터리에서 IdM 서버의 FQDN(정규화된 도메인 이름)을 사용하여 Ansible 인벤토리 파일을 생성했다고 가정합니다.
    • 이 예제에서는 secret.yml Ansible 자격 증명 모음이 ipaadmin_password 를 저장하는 것으로 가정합니다.

절차

  1. 인벤토리 파일(예: inventory.file )을 생성하고 여기에 ipaserver 를 정의합니다.

    [ipaserver]
    server.idm.example.com
  2. IdM에서 확인할 사용자의 데이터로 Ansible 플레이북 파일을 생성합니다. 이 단계를 간소화하기 위해 /usr/share/doc/ansible-freeipa/playbooks/user/ensure-users-present.yml 파일에서 예제를 복사하고 수정할 수 있습니다. 예를 들어 idm_user_1, idm_user _2 및 idm_user _3 사용자를 생성하고, Password123idm_user_1 의 암호로 추가하려면 다음을 수행합니다.

    ---
    - name: Playbook to handle users
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Create user idm_users
        ipauser:
          ipaadmin_password: "{{ ipaadmin_password }}"
          users:
          - name: idm_user_1
            first: Alice
            last: Acme
            uid: 10001
            gid: 10011
            phone: "+555123457"
            email: idm_user@acme.com
            passwordexpiration: "2023-01-19 23:59:59"
            password: "Password123"
          - name: idm_user_2
            first: Bob
            last: Acme
            uid: 100011
            gid: 10011
          - name: idm_user_3
            first: Eve
            last: Acme
            uid: 1000111
            gid: 10011
    참고

    update_password: on_create 옵션을 지정하지 않으면 Ansible은 플레이북을 실행할 때마다 사용자 암호를 다시 설정합니다. 플레이북이 마지막으로 실행된 이후 사용자가 암호를 변경한 경우 Ansible은 암호를 다시 설정합니다.

  3. 플레이북을 실행합니다.

    $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-users.yml

검증 단계

  • ipa user-show 명령을 사용하여 사용자 계정이 IdM에 있는지 확인할 수 있습니다.

    1. 관리자로 ipaserver 에 로그인합니다.

      $ ssh administrator@server.idm.example.com
      Password:
      [admin@server /]$
    2. idm_user_1 에 대한 정보 표시:

      $ ipa user-show idm_user_1
        User login: idm_user_1
        First name: Alice
        Last name: Acme
        Password: True
        ....

    IdM에 idm_user_1 이라는 사용자가 있습니다.

4.4. Ansible 플레이북을 사용하여 JSON 파일에서 여러 IdM 사용자가 있는지 확인

다음 절차에서는 Ansible 플레이북을 사용하여 IdM에 여러 사용자가 있는지 확인하는 방법을 설명합니다. 사용자는 JSON 파일에 저장됩니다.

사전 요구 사항

  • IdM 관리자 암호를 알고 있습니다.
  • 다음 요구 사항을 충족하도록 Ansible 제어 노드를 구성했습니다.

    • Ansible 버전 2.14 이상을 사용하고 있습니다.
    • Ansible 컨트롤러에 ansible-freeipa 패키지가 설치되어 있습니다.
    • 이 예제에서는 ~/MyPlaybook/ 디렉터리에서 IdM 서버의 FQDN(정규화된 도메인 이름)을 사용하여 Ansible 인벤토리 파일을 생성했다고 가정합니다.
    • 이 예제에서는 secret.yml Ansible 자격 증명 모음이 ipaadmin_password 를 저장하는 것으로 가정합니다.

절차

  1. 인벤토리 파일(예: inventory.file )을 생성하고 여기에 ipaserver 를 정의합니다.

    [ipaserver]
    server.idm.example.com
  2. 필요한 작업을 사용하여 Ansible 플레이북 파일을 생성합니다. 확인하고자 하는 사용자의 데이터로 JSON 파일을 참조합니다. 이 단계를 간소화하기 위해 /usr/share/doc/ansible-freeipa/ensure-users-present-ymlfile.yml 파일에서 예제를 복사하고 수정할 수 있습니다.

    ---
    - name: Ensure users' presence
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Include users.json
        include_vars:
          file: users.json
    
      - name: Users present
        ipauser:
          ipaadmin_password: "{{ ipaadmin_password }}"
          users: "{{ users }}"
  3. users.json 파일을 생성하고 IdM 사용자를 추가합니다. 이 단계를 간소화하기 위해 /usr/share/doc/ansible-freeipa/playbooks/user/users.json 파일에서 예제를 복사하고 수정할 수 있습니다. 예를 들어 idm_user_1, idm_user _2 및 idm_user _3 사용자를 생성하고, Password123idm_user_1 의 암호로 추가하려면 다음을 수행합니다.

    {
      "users": [
       {
        "name": "idm_user_1",
        "first": "Alice",
        "last": "Acme",
        "password": "Password123"
       },
       {
        "name": "idm_user_2",
        "first": "Bob",
        "last": "Acme"
       },
       {
        "name": "idm_user_3",
        "first": "Eve",
        "last": "Acme"
       }
      ]
    }
  4. Ansible 플레이북을 실행합니다. Playbook 파일, secret.yml 파일을 보호하는 암호를 저장하는 파일, 인벤토리 파일을 지정합니다.

    $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-users-present-jsonfile.yml

검증 단계

  • ipa user-show 명령을 사용하여 사용자 계정이 IdM에 있는지 확인할 수 있습니다.

    1. 관리자로 ipaserver 에 로그인합니다.

      $ ssh administrator@server.idm.example.com
      Password:
      [admin@server /]$
    2. idm_user_1 에 대한 정보 표시:

      $ ipa user-show idm_user_1
        User login: idm_user_1
        First name: Alice
        Last name: Acme
        Password: True
        ....

    IdM에 idm_user_1 이라는 사용자가 있습니다.

4.5. Ansible 플레이북을 사용하여 사용자가 없는지 확인

다음 절차에서는 Ansible 플레이북을 사용하여 특정 사용자가 IdM에 없는지 확인하는 방법을 설명합니다.

사전 요구 사항

  • IdM 관리자 암호를 알고 있습니다.
  • 다음 요구 사항을 충족하도록 Ansible 제어 노드를 구성했습니다.

    • Ansible 버전 2.14 이상을 사용하고 있습니다.
    • Ansible 컨트롤러에 ansible-freeipa 패키지가 설치되어 있습니다.
    • 이 예제에서는 ~/MyPlaybook/ 디렉터리에서 IdM 서버의 FQDN(정규화된 도메인 이름)을 사용하여 Ansible 인벤토리 파일을 생성했다고 가정합니다.
    • 이 예제에서는 secret.yml Ansible 자격 증명 모음이 ipaadmin_password 를 저장하는 것으로 가정합니다.

절차

  1. 인벤토리 파일(예: inventory.file )을 생성하고 여기에 ipaserver 를 정의합니다.

    [ipaserver]
    server.idm.example.com
  2. IdM에 없는 사용자로 Ansible 플레이북 파일을 생성합니다. 이 단계를 간소화하기 위해 /usr/share/doc/ansible-freeipa/playbooks/user/ensure-users-present.yml 파일에서 예제를 복사하고 수정할 수 있습니다. 예를 들어 idm_user_1, idm_user _2 및 idm_user _3 사용자를 삭제하려면 다음을 수행합니다.

    ---
    - name: Playbook to handle users
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Delete users idm_user_1, idm_user_2, idm_user_3
        ipauser:
          ipaadmin_password: "{{ ipaadmin_password }}"
          users:
          - name: idm_user_1
          - name: idm_user_2
          - name: idm_user_3
          state: absent
  3. Ansible 플레이북을 실행합니다. Playbook 파일, secret.yml 파일을 보호하는 암호를 저장하는 파일, 인벤토리 파일을 지정합니다.

    $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/delete-users.yml

검증 단계

ipa user-show 명령을 사용하여 사용자 계정이 IdM에 없는지 확인할 수 있습니다.

  1. 관리자로 ipaserver 에 로그인합니다.

    $ ssh administrator@server.idm.example.com
    Password:
    [admin@server /]$
  2. idm_user_1 에 대한 정보를 요청합니다.

    $ ipa user-show idm_user_1
    ipa: ERROR: idm_user_1: user not found

    이름이 idm_user_1 인 사용자는 IdM에 없습니다.

4.6. 추가 리소스

  • /usr/share/doc/ansible-freeipa/ 디렉토리의 README-user.md Markdown 파일을 참조하십시오.
  • /usr/share/doc/ansible-freeipa/playbooks/user 디렉터리에서 샘플 Ansible 플레이북을 참조하십시오.

5장. IdM에서 사용자 암호 관리

5.1. IdM 사용자 암호 및 방법을 변경할 수 있는 사람

다른 사용자의 암호를 변경할 수 있는 권한이 없는 일반 사용자는 자신의 개인 암호만 변경할 수 있습니다. 새 암호는 사용자가 멤버인 그룹에 적용되는 IdM 암호 정책을 충족해야 합니다. 암호 정책 구성에 대한 자세한 내용은 IdM 암호 정책 정의를 참조하십시오.

암호 변경 권한이 있는 관리자와 사용자는 새 사용자의 초기 암호를 설정하고 기존 사용자의 암호를 재설정할 수 있습니다. 이러한 암호:

참고

LDAP Directory Manager(DM) 사용자는 LDAP 도구를 사용하여 사용자 암호를 변경할 수 있습니다. 새 암호는 IdM 암호 정책을 덮어쓸 수 있습니다. DM에서 설정한 암호는 첫 번째 로그인 후 만료되지 않습니다.

5.2. IdM 웹 UI에서 사용자 암호 변경

IdM(Identity Management) 사용자는 IdM 웹 UI에서 사용자 암호를 변경할 수 있습니다.

사전 요구 사항

  • IdM 웹 UI에 로그인되어 있습니다.

절차

  1. 오른쪽 상단에서 사용자 이름 → 암호 변경을 클릭합니다.

    그림 5.1. 암호 재설정

    사용자 변경 pwd
  2. 현재 및 새 암호를 입력합니다.

5.3. IdM 웹 UI에서 다른 사용자의 암호 재설정

IdM(Identity Management)의 관리 사용자는 IdM 웹 UI에서 다른 사용자의 암호를 변경할 수 있습니다.

사전 요구 사항

  • IdM 웹 UI에 관리자로 로그인되어 있습니다.

절차

  1. IdentityUsers 를 선택합니다.
  2. 편집할 사용자 이름을 클릭합니다.
  3. ActionsReset password (암호 재설정)를 클릭합니다.

    그림 5.2. 암호 재설정

    pwd reset1
  4. 새 암호를 입력하고 암호 재설정 을 클릭합니다.

    그림 5.3. 새 암호 확인

    pwd 재설정2

5.4. Directory Manager 사용자 암호 재설정

IdM(Identity Management) Directory Manager 암호가 손실되면 재설정할 수 있습니다.

사전 요구 사항

  • IdM 서버에 대한 루트 액세스 권한이 있습니다.

절차

  1. pwdhash 명령을 사용하여 새 암호 해시를 생성합니다. 예를 들면 다음과 같습니다.

    # pwdhash -D /etc/dirsrv/slapd-IDM-EXAMPLE-COM password
    {PBKDF2_SHA256}AAAgABU0bKhyjY53NcxY33ueoPjOUWtl4iyYN5uW...

    Directory Server 구성의 경로를 지정하면 nsslapd-rootpwstoragescheme 속성에 설정된 암호 스토리지 스키마를 자동으로 사용하여 새 암호를 암호화합니다.

  2. 토폴로지의 모든 IdM 서버에서 다음 단계를 실행합니다.

    1. 서버에 설치된 모든 IdM 서비스를 중지합니다.

      # ipactl stop
    2. /etc/dirsrv/IDM-EXAMPLE-COM/dse.ldif 파일을 편집하고 nsslapd-rootpw 속성을 pwdhash 명령으로 생성된 값으로 설정합니다.

      nsslapd-rootpw: {PBKDF2_SHA256}AAAgABU0bKhyjY53NcxY33ueoPjOUWtl4iyYN5uW...
    3. 서버에 설치된 모든 IdM 서비스를 시작합니다.
    # ipactl start

5.5. 사용자 암호 변경 또는 IdM CLI에서 다른 사용자의 암호 재설정

IdM(Identity Management) 명령줄 인터페이스(CLI)를 사용하여 사용자 암호를 변경할 수 있습니다. 관리자인 경우 CLI를 사용하여 다른 사용자의 암호를 재설정할 수 있습니다.

사전 요구 사항

  • IdM 사용자를 위한 TGT( ticket-granting 티켓)가 있습니다.
  • 다른 사용자의 암호를 재설정하는 경우 IdM에서 관리자용 TGT를 받아야 합니다.

절차

  • 사용자 이름과 --password 옵션을 사용하여 ipa user-mod 명령을 입력합니다. 명령에서 새 암호를 입력하라는 메시지를 표시합니다.

    $ ipa user-mod idm_user --password
    Password:
    Enter Password again to verify:
    --------------------
    Modified user "idm_user"
    --------------------
    ...
참고

ipa user-mod 대신 ipa passwd idm_user 명령을 사용할 수도 있습니다.

5.6. 다음 로그인 시 사용자에게 암호 변경을 요청하지 않고 IdM에서 암호 재설정 활성화

기본적으로 관리자가 다른 사용자의 암호를 재설정하면 로그인 후 암호가 만료됩니다. IdM 디렉터리 관리자는 개별 IdM 관리자에게 다음 권한을 지정할 수 있습니다.

  • 사용자가 첫 번째 로그인 시 나중에 암호를 변경할 필요 없이 암호 변경 작업을 수행할 수 있습니다.
  • 암호 정책을 바이패스할 수 있으므로 강점이나 기록 적용이 적용되지 않습니다.
주의

암호 정책을 우회하는 것은 보안 위협 일 수 있습니다. 이러한 추가 권한을 부여할 사용자를 선택할 때는 주의하십시오.

사전 요구 사항

  • Directory Manager 비밀번호를 알고 있습니다.

절차

  1. 도메인의 모든 IdM(Identity Management) 서버에서 다음과 같이 변경합니다.

    1. ldapmodify 명령을 입력하여 LDAP 항목을 수정합니다. IdM 서버 이름과 389 포트의 이름을 지정하고 Enter 키를 누릅니다.

      $ ldapmodify -x -D "cn=Directory Manager" -W -h server.idm.example.com -p 389
      Enter LDAP Password:
    2. Directory Manager 암호를 입력합니다.
    3. ipa_pwd_extop 암호 동기화 항목의 고유 이름을 입력하고 Enter 키를 누릅니다.

      dn: cn=ipa_pwd_extop,cn=plugins,cn=config
    4. 변경 유형 지정 및 Enter 키를 누릅니다.

      changetype: modify
    5. 실행할 LDAP와 어떤 속성에 대해 수정 유형을 지정합니다. Enter를 누릅니다.

      add: passSyncManagersDNs
    6. passSyncManagersDNs 속성에 관리 사용자 계정을 지정합니다. 속성은 다중 값입니다. 예를 들어 admin 사용자에게 Directory Manager의 전원을 재설정하는 암호를 부여하려면 다음을 수행합니다.

      passSyncManagersDNs: \
      uid=admin,cn=users,cn=accounts,dc=example,dc=com
    7. Enter를 두 번 눌러 항목 편집을 중지합니다.

전체 절차는 다음과 같습니다.

$ ldapmodify -x -D "cn=Directory Manager" -W -h server.idm.example.com -p 389
Enter LDAP Password:
dn: cn=ipa_pwd_extop,cn=plugins,cn=config
changetype: modify
add: passSyncManagersDNs
passSyncManagersDNs: uid=admin,cn=users,cn=accounts,dc=example,dc=com

passSyncManagerDNs 에 나열된 admin 사용자에게는 이제 추가 권한이 있습니다.

5.7. IdM 사용자 계정이 잠겼는지 확인

IdM(Identity Management) 관리자는 IdM 사용자 계정이 잠겼는지 확인할 수 있습니다. 이를 위해 사용자의 최대 실패한 로그인 시도 횟수를 사용자의 실제 실패한 로그인 수와 비교해야 합니다.

사전 요구 사항

  • IdM에서 관리자의 TGT( ticket-granting ticket)를 받으셨습니다.

절차

  1. 사용자 계정 상태를 표시하여 실패한 로그인 수를 확인합니다.

    $ ipa user-status example_user
    -----------------------
    Account disabled: False
    -----------------------
      Server: idm.example.com
      Failed logins: 8
      Last successful authentication: N/A
      Last failed authentication: 20220229080317Z
      Time now: 2022-02-29T08:04:46Z
    ----------------------------
    Number of entries returned 1
    ----------------------------
  2. 특정 사용자에 대해 허용된 로그인 시도 횟수를 표시합니다.

    1. IdM 관리자로 IdM 웹 UI에 로그인합니다.
    2. Identity → 사용자 → 활성 사용자 탭을 엽니다.

    A screenshot of the IdM Web UI displaying the "Active Users" page which is a sub-page of the Users submenu from the Identity tab.

    1. 사용자 이름을 클릭하여 사용자 설정을 엽니다.
    2. 암호 정책 섹션에서 최대 실패 항목을 찾습니다.
  3. ipa user-status 명령 출력에 표시된 실패한 로그인 수와 IdM 웹 UI에 표시된 최대 오류 수를 비교합니다. 실패한 로그인 수가 허용되는 최대 로그인 시도 횟수와 동일한 경우 사용자 계정이 잠깁니다.

5.8. IdM에서 암호 실패 후 사용자 계정 잠금 해제

사용자가 잘못된 암호를 사용하여 로그인하려고 하면 IdM(Identity Management)이 사용자 계정을 잠금하여 사용자가 로그인하지 못하도록 합니다. 보안상의 이유로 IdM은 사용자 계정이 잠겼는 경고 메시지를 표시하지 않습니다. 대신 CLI 프롬프트에서 사용자에게 암호를 다시 요청합니다.

IdM은 지정된 시간이 지난 후 사용자 계정의 잠금을 자동으로 해제합니다. 또는 다음 절차에 따라 사용자 계정의 잠금을 수동으로 해제할 수 있습니다.

사전 요구 사항

  • IdM 관리자의 티켓 분리 티켓이 있습니다.

절차

  • 사용자 계정 잠금을 해제하려면 ipa user-unlock 명령을 사용합니다.

    $ ipa user-unlock idm_user
    -----------------------
    Unlocked account "idm_user"
    -----------------------

    이 후 사용자는 다시 로그인할 수 있습니다.

5.9. IdM에서 사용자를 위해 마지막으로 성공한 Kerberos 인증 추적 활성화

성능상의 이유로 Red Hat Enterprise Linux 8에서 실행되는 IdM(Identity Management)은 사용자의 마지막 성공적인 Kerberos 인증 타임스탬프를 저장하지 않습니다. 결과적으로 ipa user-status 와 같은 특정 명령은 타임스탬프를 표시하지 않습니다.

사전 요구 사항

  • IdM에서 관리자의 TGT( ticket-granting ticket)를 받으셨습니다.
  • 프로시저를 실행하는 IdM 서버에 대한 루트 액세스 권한이 있습니다.

절차

  1. 현재 활성화된 암호 플러그인 기능을 표시합니다.

    # ipa config-show | grep "Password plugin features"
      Password plugin features: AllowNThash, KDC:Disable Last Success

    출력에 DASD :Disable Last Success 플러그인이 활성화되어 있음을 보여줍니다. 플러그인은 ipa user-status 출력에 마지막으로 성공한 Kerberos 인증 시도가 표시되지 않도록 숨깁니다.

  2. ArgoCD :Disable Last Success 를 제외하고 현재 활성화된 ipa config-mod 명령에 모든 기능에 대해 --ipaconfigstring=feature 매개 변수를 추가합니다.

    # ipa config-mod --ipaconfigstring='AllowNThash'

    이 명령은 AllowNThash 플러그인만 활성화합니다. 여러 기능을 활성화하려면 각 기능에 대해 --ipaconfigstring=기능 매개변수를 별도로 지정합니다.

  3. IdM을 다시 시작하십시오.

    # ipactl restart

6장. IdM 암호 정책 정의

이 장에서는 IdM(Identity Management) 암호 정책 및 Ansible 플레이북을 사용하여 IdM에 새 암호 정책을 추가하는 방법을 설명합니다.

6.1. 암호 정책이란 무엇입니까?

암호 정책은 암호가 충족해야 하는 일련의 규칙입니다. 예를 들어 암호 정책은 최소 암호 길이 및 최대 암호 수명을 정의할 수 있습니다. 이 정책의 영향을 받는 모든 사용자는 충분히 긴 암호를 설정하고 지정된 조건을 충족하기에 충분히 자주 변경해야 합니다. 이렇게 하면 암호 정책을 사용하면 누군가가 사용자의 암호를 검색하고 잘못 사용할 위험을 줄일 수 있습니다.

6.2. IdM의 암호 정책

암호는 IdM(Identity Management) 사용자가 IdM Kerberos 도메인에 인증하는 가장 일반적인 방법입니다. 암호 정책은 이러한 IdM 사용자 암호가 충족해야 하는 요구 사항을 정의합니다.

참고

IdM 암호 정책은 기본 LDAP 디렉터리에 설정되어 있지만 Kerberos KDC(Key Distribution Center)는 암호 정책을 적용합니다.

암호 정책 속성에 는 IdM에서 암호 정책을 정의하는 데 사용할 수 있는 속성이 나열됩니다.

표 6.1. 암호 정책 속성

속성설명예제

최대 수명

사용자가 암호를 재설정하기 전에 암호가 유효한 최대 시간(일)입니다. 기본값은 90일입니다.

속성이 0으로 설정되면 암호가 만료되지 않습니다.

최대 수명 = 180

사용자 암호는 180일 동안만 유효합니다. 그러면 IdM에서 사용자에게 변경하라는 메시지를 표시합니다.

최소 수명

두 암호 변경 작업 간에 전달해야 하는 최소 시간(시간)입니다.

최소 수명 = 1

사용자가 암호를 변경한 후에는 암호를 변경하기 전에 1시간 이상 기다려야 합니다.

기록 크기

저장된 이전 암호 수입니다. 사용자는 암호 기록에서 암호를 재사용할 수 없지만 저장되지 않은 이전 암호를 재사용할 수 있습니다.

기록 크기 = 0

이 경우 암호 기록이 비어 있으며 사용자는 이전 암호를 재사용할 수 있습니다.

문자 클래스

사용자가 암호에서 사용해야 하는 다른 문자 클래스의 수입니다. 문자 클래스는 다음과 같습니다.

* 대문자

* 소문자

* 숫자

* comma (,), 마침표(.), 별표(*)와 같은 특수 문자

* 다른 UTF-8 문자

행에서 문자를 세 번 이상 사용하면 문자 클래스가 하나씩 감소합니다. 예를 들면 다음과 같습니다.

* Secret1 에는 대문자, 소문자, 숫자 3개가 있습니다.

* Secret111 에는 대문자, 소문자, 숫자 및 1 을 반복적으로 사용하기 위한 -1의 문자 클래스가 있습니다.

문자 클래스 = 0

기본 클래스 수는 0입니다. 번호를 구성하려면 --minclasses 옵션과 함께 ipa pwpolicy-mod 명령을 실행합니다.

이 표 아래에 있는 중요한 참고 사항도 참조하십시오.

최소 길이

암호의 최소 문자 수입니다.

추가 암호 정책 옵션이 설정되어 있으면 최소 암호 길이는 6자입니다.

최소 길이 = 8

사용자는 8자 미만의 암호를 사용할 수 없습니다.

최대 실패

IdM이 사용자 계정을 잠기 전에 실패한 로그인 시도 횟수입니다.

최대 실패 = 6

사용자가 행에 잘못된 암호 7번을 입력하면 IdM에서 사용자 계정을 잠급니다.

실패 재설정 간격

IdM이 현재 실패한 로그인 시도 횟수를 재설정한 후 시간(초)입니다.

실패 재설정 간격 = 60

사용자가 최대 실패에 정의된 로그인 시도 횟수가 1분 이상 대기하는 경우 사용자는 사용자 계정 잠금에 위험을 주지 않고 다시 로그인을 시도할 수 있습니다.

Lockout 기간

최대 실패 시 정의된 로그인 시도 횟수 후 사용자 계정이 잠겼는 시간(초)입니다.

Lockout 기간 = 600

연결된 계정이 있는 사용자는 10분 동안 로그인할 수 없습니다.

중요

국제 문자 및 기호에 액세스할 수 없는 다양한 하드웨어 세트가 있는 경우 문자 클래스 요구 사항에 대한 영어 알파벳과 공통 기호를 사용하십시오. 암호의 문자 클래스 정책에 대한 자세한 내용은 Red Hat Knowledgebase의 암호에서 유효한 문자는 무엇입니까? 를 참조하십시오.

6.3. Ansible 플레이북을 사용하여 IdM에 암호 정책이 있는지 확인

Ansible 플레이북을 사용하여 IdM(Identity Management)에 암호 정책이 있는지 확인하려면 다음 절차를 따르십시오.

IdM의 기본 global_policy 암호 정책에서 암호에 있는 다른 문자 클래스의 수는 0으로 설정됩니다. 또한 기록 크기는 0으로 설정됩니다.

Ansible 플레이북을 사용하여 IdM 그룹에 대해 강력한 암호 정책을 적용하려면 이 절차를 완료합니다.

참고

IdM 그룹에 대한 암호 정책만 정의할 수 있습니다. 개별 사용자의 암호 정책을 정의할 수 없습니다.

사전 요구 사항

  • 다음 요구 사항을 충족하도록 Ansible 제어 노드를 구성했습니다.

    • Ansible 버전 2.14 이상을 사용하고 있습니다.
    • Ansible 컨트롤러에 ansible-freeipa 패키지가 설치되어 있습니다.
    • 이 예제에서는 ~/MyPlaybook/ 디렉터리에서 IdM 서버의 FQDN(정규화된 도메인 이름)을 사용하여 Ansible 인벤토리 파일을 생성했다고 가정합니다.
    • 이 예제에서는 secret.yml Ansible 자격 증명 모음이 ipaadmin_password 를 저장하는 것으로 가정합니다.
  • IdM 관리자 암호를 알고 있습니다.
  • IdM에 암호 정책이 있는지 확인하는 그룹입니다.

절차

  1. 인벤토리 파일(예: inventory.file )을 생성하고 [ipaserver] 섹션에 IdM 서버의 FQDN 을 정의합니다.

    [ipaserver]
    server.idm.example.com
  2. 확인하려는 암호 정책을 정의하는 Ansible 플레이북 파일을 생성합니다. 이 단계를 단순화하려면 /usr/share/doc/ansible-freeipa/playbooks/pwpolicy/pwpolicy_present.yml 파일의 예제를 복사하고 수정합니다.

    ---
    - name: Tests
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Ensure presence of pwpolicy for group ops
        ipapwpolicy:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: ops
          minlife: 7
          maxlife: 49
          history: 5
          priority: 1
          lockouttime: 300
          minlength: 8
          minclasses: 4
          maxfail: 3
          failinterval: 5

    개별 변수가 무엇을 의미하는지에 대한 자세한 내용은 Password policy attributes 을 참조하십시오.

  3. 플레이북을 실행합니다.

    $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory_/new_pwpolicy_present.yml

Ansible 플레이북을 성공적으로 사용하여 IdM에 대한 암호 정책이 IdM에 있는지 확인합니다.

중요

controlPlane 암호 정책 우선 순위는 1 로 설정되지만 global_policy 암호 정책에는 우선순위가 설정되지 않습니다. 이러한 이유로 EgressIP 정책은 ActiveDirectory 그룹의 전역_policy자동으로 대체하며 즉시 적용됩니다.

global_policy 는 사용자에 대해 그룹 정책이 설정되지 않은 경우 대체 정책 역할을 하며 그룹 정책보다 우선할 수 없습니다.

추가 리소스

  • /usr/share/doc/ansible-freeipa/ 디렉토리에서 README-pwpolicy.md 파일을 참조하십시오.
  • 암호 정책 우선 순위를 참조하십시오.

6.4. IdM의 추가 암호 정책 옵션

IdM(Identity Management) 관리자는 libpwquality 기능 세트를 기반으로 추가 암호 정책 옵션을 활성화하여 기본 암호 요구 사항을 강화할 수 있습니다. 추가 암호 정책 옵션에는 다음이 포함됩니다.

--maxrepeat
새 암호에서 허용되는 최대 연속 문자 수를 지정합니다.
--maxsequence
새 암호에서 monotonic 문자 시퀀스의 최대 길이를 지정합니다. 이러한 시퀀스의 예로는 12345 또는 fedcb 가 있습니다. 이러한 암호의 대부분은 단순성 검사를 통과하지 않습니다.
--dictcheck
0이 아닌 경우 가능한 수정 사항이 있는 암호가 사전의 단어와 일치하는지 확인합니다. 현재 libpwqualityCracklib 라이브러리를 사용하여 사전 검사를 수행합니다.
--usercheck
0이 아닌 경우 가능한 수정 가능한 암호에 일부 형식의 사용자 이름이 포함되어 있는지 확인합니다. 3자 미만의 사용자 이름에는 적용되지 않습니다.

추가 암호 정책 옵션을 기존 암호에 적용할 수 없습니다. 추가 옵션을 적용하면 IdM에서 --minlength 옵션, 최소 문자 수를 6 자로 설정합니다.

참고

RHEL 7 및 RHEL 8 서버와 혼합된 환경에서는 RHEL 8.4 이상에서 실행되는 서버에서만 추가 암호 정책 설정을 적용할 수 있습니다. 사용자가 IdM 클라이언트에 로그인되어 있고 IdM 클라이언트가 RHEL 8.3 이상에서 실행되는 IdM 서버와 통신하는 경우 시스템 관리자가 설정한 새로운 암호 정책 요구 사항이 적용되지 않습니다. 일관된 동작을 위해 모든 서버를 RHEL 8.4 이상으로 업그레이드하거나 업데이트합니다.

추가 리소스:

6.5. IdM 그룹에 추가 암호 정책 옵션 적용

IdM(Identity Management)의 추가 암호 정책 옵션을 적용하려면 다음 절차를 따르십시오. 이 예제에서는 새 암호에 사용자의 각 사용자 이름이 포함되지 않고 암호에 두 개 이상의 동일한 문자가 포함되어 있는지 확인하여 managers 그룹에 대한 암호 정책을 적용하는 방법을 설명합니다.

사전 요구 사항

  • IdM 관리자로 로그인되어 있습니다.
  • managers 그룹은 IdM에 있습니다.
  • managers 암호 정책은 IdM에 있습니다.

절차

  1. managers 그룹의 사용자가 지정한 모든 새 암호에 사용자 이름 검사를 적용합니다.

    $ ipa pwpolicy-mod --usercheck=True managers
    참고

    암호 정책의 이름을 지정하지 않으면 기본 global_policy 가 수정됩니다.

  2. managers 암호 정책에서 동일한 연속 문자의 최대 수를 2로 설정합니다.

    $ ipa pwpolicy-mod --maxrepeat=2 managers

    2개 이상의 연속 문자가 포함된 경우 암호를 사용할 수 없습니다. 예를 들어 eR873mUi111YJQ 조합은 연속 3 s가 포함되어 있기 때문에 허용되지 않습니다.

검증

  1. test_user 라는 테스트 사용자를 추가합니다.

    $ ipa user-add test_user
    First name: test
    Last name: user
    ----------------------------
    Added user "test_user"
    ----------------------------
  2. managers 그룹에 test 사용자를 추가합니다.

    1. IdM 웹 UI에서 IdentityGroupsUser Groups (사용자 그룹) 를 클릭합니다.
    2. 관리자.
    3. 추가를 클릭합니다.
    4. 사용자 그룹 'managers'에 사용자 사용자 추가 페이지에서 test_user 를 확인합니다.
    5. &gt ; 화살표를 클릭하여 사용자를 Prospective 열로 이동합니다.
    6. 추가를 클릭합니다.
  3. test 사용자의 암호를 재설정합니다.

    1. IdentityUsers 로 이동합니다.
    2. test_user 를 클릭합니다.
    3. 작업 메뉴에서 암호 재설정 을 클릭합니다.
    4. 사용자에 대한 임시 암호를 입력합니다.
  4. 명령줄에서 test_user 에 대한 Kerberos TGT( ticket-granting ticket)를 받으십시오.

    $ kinit test_user
    1. 임시 암호를 입력합니다.
    2. 시스템에서 암호를 변경해야 함을 알려줍니다. test_user 의 사용자 이름이 포함된 암호를 입력합니다.

      Password expired. You must change it now.
      Enter new password:
      Enter it again:
      Password change rejected: Password not changed.
      Unspecified password quality failure while trying to change password.
      Please try again.
      참고

      Kerberos는 세분화된 오류 암호 정책 보고가 없으며, 경우에 따라 암호가 거부된 명확한 이유를 제공하지 않습니다.

    3. 시스템에서 입력한 암호가 거부되었음을 알려줍니다. 3개 이상의 동일한 문자가 포함된 암호를 입력합니다.

      Password change rejected: Password not changed.
      Unspecified password quality failure while trying to change password.
      Please try again.
      
      Enter new password:
      Enter it again:
    4. 시스템에서 입력한 암호가 거부되었음을 알려줍니다. 관리자 암호 정책의 기준을 충족하는 암호를 입력합니다.

      Password change rejected: Password not changed.
      Unspecified password quality failure while trying to change password.
      Please try again.
      
      Enter new password:
      Enter it again:
  5. 가져온 TGT를 확인합니다.

    $ klist
    Ticket cache: KCM:0:33945
    Default principal: test_user@IDM.EXAMPLE.COM
    
    Valid starting       Expires              Service principal
    07/07/2021 12:44:44  07/08/2021 12:44:44  krbtgt@IDM.EXAMPLE.COM@IDM.EXAMPLE.COM

이제 managers 암호 정책이 managers 그룹의 사용자에게 올바르게 작동합니다.

추가 리소스

6.6. Ansible 플레이북을 사용하여 IdM 그룹에 추가 암호 정책 옵션 적용

Ansible Playbook을 사용하여 특정 IdM 그룹에 대한 암호 정책 요구 사항을 강화하기 위해 추가 암호 정책 옵션을 적용할 수 있습니다. 이를 위해 maxrepoy,maxsequence,dictcheckusercheck 암호 정책 옵션을 사용할 수 있습니다. 이 예제에서는 managers 그룹에 다음 요구 사항을 설정하는 방법을 설명합니다.

  • 사용자의 새 암호에는 사용자의 각 사용자 이름이 포함되어 있지 않습니다.
  • 암호에는 연속에 두 개 이상의 동일한 문자가 포함되어 있지 않습니다.
  • 암호의 단조 문자 시퀀스는 3자를 넘지 않습니다. 즉, 시스템은 1234 또는 abcd 와 같은 시퀀스의 암호를 허용하지 않습니다.

사전 요구 사항

  • 다음 요구 사항을 충족하도록 Ansible 제어 노드를 구성했습니다.

    • Ansible 버전 2.14 이상을 사용하고 있습니다.
    • Ansible 컨트롤러에 ansible-freeipa 패키지가 설치되어 있습니다.
    • ~/MyPlaybook/ 디렉터리에 IdM 서버의 FQDN(정규화된 도메인 이름)을 사용하여 Ansible 인벤토리 파일을 생성했습니다.
    • ipaadmin_passwordsecret.yml Ansible 자격 증명에 저장했습니다.
  • IdM에 암호 정책이 있는지 확인하는 그룹입니다.

절차

  1. 확인하려는 암호 정책을 정의하는 Ansible 플레이북 파일 manager_pwpolicy_present.yml 을 생성합니다. 이 단계를 간소화하려면 다음 예제를 복사 및 수정합니다.

    ---
    - name: Tests
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Ensure presence of usercheck and maxrepeat pwpolicy for group managers
        ipapwpolicy:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: managers
          usercheck: True
          maxrepeat: 2
          maxsequence: 3
  2. 플레이북을 실행합니다.

    $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory_/manager_pwpolicy_present.yml

검증

  1. test_user 라는 테스트 사용자를 추가합니다.

    $ ipa user-add test_user
    First name: test
    Last name: user
    ----------------------------
    Added user "test_user"
    ----------------------------
  2. managers 그룹에 test 사용자를 추가합니다.

    1. IdM 웹 UI에서 IdentityGroupsUser Groups (사용자 그룹) 를 클릭합니다.
    2. 관리자.
    3. 추가를 클릭합니다.
    4. 사용자 그룹 'managers'에 사용자 사용자 추가 페이지에서 test_user 를 확인합니다.
    5. &gt ; 화살표를 클릭하여 사용자를 Prospective 열로 이동합니다.
    6. 추가를 클릭합니다.
  3. test 사용자의 암호를 재설정합니다.

    1. IdentityUsers 로 이동합니다.
    2. test_user 를 클릭합니다.
    3. 작업 메뉴에서 암호 재설정 을 클릭합니다.
    4. 사용자에 대한 임시 암호를 입력합니다.
  4. 명령줄에서 test_user 에 대한 Kerberos TGT( ticket-granting ticket)를 받으십시오.

    $ kinit test_user
    1. 임시 암호를 입력합니다.
    2. 시스템에서 암호를 변경해야 함을 알려줍니다. test_user 의 사용자 이름이 포함된 암호를 입력합니다.

      Password expired. You must change it now.
      Enter new password:
      Enter it again:
      Password change rejected: Password not changed.
      Unspecified password quality failure while trying to change password.
      Please try again.
      참고

      Kerberos는 세분화된 오류 암호 정책 보고가 없으며, 경우에 따라 암호가 거부된 명확한 이유를 제공하지 않습니다.

    3. 시스템에서 입력한 암호가 거부되었음을 알려줍니다. 3개 이상의 동일한 문자가 포함된 암호를 입력합니다.

      Password change rejected: Password not changed.
      Unspecified password quality failure while trying to change password.
      Please try again.
      
      Enter new password:
      Enter it again:
    4. 시스템에서 입력한 암호가 거부되었음을 알려줍니다. 3자를 초과하는 단조 문자 시퀀스가 포함된 암호를 입력합니다. 이러한 서열의 예는 1234fedc 를 포함한다:

      Password change rejected: Password not changed.
      Unspecified password quality failure while trying to change password.
      Please try again.
      
      Enter new password:
      Enter it again:
    5. 시스템에서 입력한 암호가 거부되었음을 알려줍니다. 관리자 암호 정책의 기준을 충족하는 암호를 입력합니다.

      Password change rejected: Password not changed.
      Unspecified password quality failure while trying to change password.
      Please try again.
      
      Enter new password:
      Enter it again:
  5. 유효한 암호를 입력한 후에만 TGT를 받을 수 있는지 확인합니다.

    $ klist
    Ticket cache: KCM:0:33945
    Default principal: test_user@IDM.EXAMPLE.COM
    
    Valid starting       Expires              Service principal
    07/07/2021 12:44:44  07/08/2021 12:44:44  krbtgt@IDM.EXAMPLE.COM@IDM.EXAMPLE.COM

추가 리소스

7장. 암호 만료 알림 관리

ipa-client-epn 패키지에서 제공하는 만료된 암호 알림(EPN) 툴을 사용하여 구성된 시간 내에 암호가 만료되는 IdM(Identity Management) 사용자 목록을 빌드할 수 있습니다. EPN 툴을 설치, 구성 및 사용하려면 관련 섹션을 참조하십시오.

7.1. 암호 알림 만료 툴은 무엇입니까?

만료된 암호 알림(EPN) 툴은 구성된 시간 내에 암호가 만료되는 IdM(Identity Management) 사용자 목록을 빌드하는 데 사용할 수 있는 독립 실행형 툴입니다.

IdM 관리자는 EPN을 사용하여 다음을 수행할 수 있습니다.

  • 시험 실행 모드에서 실행할 때 생성되는 JSON 형식으로 영향을 받는 사용자 목록을 표시합니다.
  • 지정된 날짜 또는 날짜 범위에 대해 전송할 이메일 수를 계산합니다.
  • 사용자에게 암호 만료 이메일 알림을 보냅니다.
  • EPN 툴을 매일 실행하고 정의된 향후 날짜 범위 내에서 암호가 만료되는 사용자에게 이메일을 전송하도록 ipa-epn.timer 를 구성합니다.
  • 사용자에게 보낼 이메일 알림을 사용자 지정합니다.
참고

사용자 계정이 비활성화된 경우 암호가 만료되면 이메일 알림이 전송되지 않습니다.

7.2. 암호 알림 만료 도구 설치

EPN(Expiring Password Notification) 툴을 설치하려면 다음 절차를 따르십시오.

사전 요구 사항

  • 스마트 호스트로 구성된 로컬 Postfix SMTP 서버를 사용하여 IdM(Identity Management) 복제본 또는 IdM 클라이언트에 EPN 툴을 설치합니다.

절차

  • EPN 툴을 설치합니다.

    # yum install ipa-client-epn

7.3. 암호가 만료되는 사용자에게 이메일을 전송하도록 EPN 툴 실행

Expiring Password Notification (EPN) 툴을 실행하여 암호가 만료되는 사용자에게 이메일을 보내려면 다음 절차를 따르십시오.

참고

EPN 툴은 스테이트리스(stateless)입니다. EPN 툴이 지정된 날에 암호가 만료되는 모든 사용자에게 이메일을 보내지 못하면 EPN 툴에서 해당 사용자 목록을 저장하지 않습니다.

사전 요구 사항

절차

  1. epn.conf 구성 파일을 업데이트하여 EPN 툴에 대한 옵션을 설정하여 향후 암호 만료를 사용자에게 알립니다.

    # vi /etc/ipa/epn.conf
  2. 필요에 따라 notify_ttls 를 업데이트합니다. 기본값은 암호가 28, 14, 7, 3 및 1일 후에 만료되는 사용자에게 알리는 것입니다.

    notify_ttls = 28, 14, 7, 3, 1
  3. SMTP 서버 및 포트를 구성합니다.

    smtp_server = localhost
    smtp_port = 25
  4. 이메일 만료 알림이 전송되는 이메일 주소를 지정합니다. 실패한 모든 이메일은 이 주소로 반환됩니다.

    mail_from =admin-email@example.com
  5. /etc/ipa/epn.conf 파일을 저장합니다.
  6. 시험 실행 모드에서 EPN 도구를 실행하여 --dry-run 옵션 없이 도구를 실행하면 암호 만료 이메일 알림이 전송되는 사용자 목록을 생성합니다.

    ipa-epn --dry-run
    [
        {
         "uid": "user5",
         "cn": "user 5",
         "krbpasswordexpiration": "2020-04-17 15:51:53",
         "mail": "['user5@ipa.test']"
        }
    ]
    [
        {
         "uid": "user6",
         "cn": "user 6",
         "krbpasswordexpiration": "2020-12-17 15:51:53",
         "mail": "['user5@ipa.test']"
         }
    ]
    The IPA-EPN command was successful
    참고

    반환된 사용자 목록이 매우 크고 --dry-run 옵션 없이 툴을 실행하면 이메일 서버에 문제가 발생할 수 있습니다.

  7. dry-run 옵션 없이 EPN 도구를 실행하여 시험 실행 모드에서 EPN 도구를 실행할 때 반환된 모든 사용자 목록에 만료 이메일을 보냅니다.

    ipa-epn
    [
      {
         "uid": "user5",
         "cn": "user 5",
         "krbpasswordexpiration": "2020-10-01 15:51:53",
         "mail": "['user5@ipa.test']"
      }
    ]
    [
      {
        "uid": "user6",
        "cn": "user 6",
        "krbpasswordexpiration": "2020-12-17 15:51:53",
        "mail": "['user5@ipa.test']"
      }
    ]
    The IPA-EPN command was successful
  8. 모든 모니터링 시스템에 EPN을 추가하고 --from-nbdays--to-nbdays 옵션을 사용하여 호출할 수 있습니다.

    # ipa-epn --from-nbdays 8 --to-nbdays 12
    참고

    --from-nbdays--to-nbdays 옵션과 함께 EPN 도구를 호출하면 시험 실행 모드에서 자동으로 실행됩니다.

검증 단계

  • EPN 도구를 실행하고 이메일 알림이 전송되었는지 확인합니다.

추가 리소스

  • ipa-epn 매뉴얼 페이지를 참조하십시오.
  • epn.conf 매뉴얼 페이지를 참조하십시오.

7.4. ipa-epn.timer에서 암호가 만료되는 모든 사용자에게 이메일을 전송하도록 활성화

ipa-epn.timer 를 사용하여 Expiring Password Notification (EPN) 툴을 실행하여 암호가 만료되는 사용자에게 이메일을 보냅니다. ipa-epn.timerepn.conf 파일을 구문 분석하고 해당 파일에 구성된 정의된 향후 날짜 범위 내에서 암호가 만료되는 사용자에게 이메일을 보냅니다.

사전 요구 사항

절차

  • ipa-epn.timer 시작:

    systemctl start ipa-epn.timer

기본적으로 타이머를 시작하면 EPN 도구가 매일 오전 1시 실행됩니다.

추가 리소스

  • ipa-epn 매뉴얼 페이지를 참조하십시오.

7.5. 암호 알림 만료 이메일 템플릿 수정

EPN(Expiring Password Notification) 이메일 메시지 템플릿을 사용자 지정하려면 다음 절차를 따르십시오.

사전 요구 사항

  • ipa-client-epn 패키지가 설치되어 있습니다.

절차

  1. EPN 메시지 템플릿을 엽니다.

    # vi /etc/ipa/epn/expire_msg.template
  2. 필요에 따라 템플릿 텍스트를 업데이트합니다.

    Hi {{ fullname }},
    
    Your password will expire on {{ expiration }}.
    
    Please change it as soon as possible.

    템플릿에서 다음 변수를 사용할 수 있습니다.

    • 사용자 ID: uid
    • 전체 이름: fullname
    • 첫 번째 이름: first
    • 성: last
    • 암호 만료일: 만료
  3. 메시지 템플릿 파일을 저장합니다.

검증 단계

  • EPN 툴을 실행하고 이메일 알림에 업데이트된 텍스트가 포함되어 있는지 확인합니다.

추가 리소스

  • ipa-epn 매뉴얼 페이지를 참조하십시오.

8장. IdM 클라이언트의 IdM 사용자에게 sudo 액세스 권한 부여

Identity Management에서 사용자에게 sudo 액세스 권한을 부여하는 방법에 대해 자세히 알아보십시오.

8.1. IdM 클라이언트에서 sudo 액세스

시스템 관리자는 루트가 아닌 사용자가 일반적으로 root 사용자에게 예약된 관리 명령을 실행할 수 있도록 sudo 액세스 권한을 부여할 수 있습니다. 따라서 사용자가 일반적으로 root 사용자로 예약된 관리 명령을 수행해야 하는 경우 sudo 를 사용하여 해당 명령 앞에 추가합니다. 암호를 입력한 후에는 루트 사용자인 것처럼 명령이 실행됩니다. 데이터베이스 서비스 계정과 같은 다른 사용자 또는 그룹으로 sudo 명령을 실행하려면 sudo 규칙에 대해 RunAs 별칭 을 구성할 수 있습니다.

RHEL(Red Hat Enterprise Linux) 8 호스트가 IdM(Identity Management) 클라이언트에 등록된 경우 다음 방법으로 호스트에서 수행할 수 있는 IdM 사용자를 정의하는 sudo 규칙을 지정할 수 있습니다.

  • 로컬로 /etc/sudoers 파일에서
  • IdM에서 중앙 집중식으로

CLI(명령줄 인터페이스) 및 IdM 웹 UI를 사용하여 IdM 클라이언트에 대한 중앙 sudo 규칙을 생성할 수 있습니다.

RHEL 8.4 이상에서는 UNIX 기반 운영 체제가 Kerberos 서비스에 액세스하고 인증하는 기본 방법인 GSSAPI(Generic Security Service Application Programming Interface)를 사용하여 sudo 에 대해 암호 없는 인증을 구성할 수도 있습니다. pam_sss_gss.so PAM(Pluggable Authentication Module)을 사용하여 SSSD 서비스를 통해 GSSAPI 인증을 호출할 수 있으므로 사용자는 유효한 Kerberos 티켓을 사용하여 sudo 명령을 인증할 수 있습니다.

추가 리소스

8.2. CLI를 사용하여 IdM 클라이언트의 IdM 사용자에게 sudo 액세스 권한 부여

IdM(Identity Management)에서는 특정 IdM 호스트의 IdM 사용자 계정에 대한 sudo 액세스 권한을 특정 명령에 부여할 수 있습니다. 먼저 sudo 명령을 추가한 다음 하나 이상의 명령에 대한 sudo 규칙을 만듭니다.

예를 들어 idm_user _reboot sudo 규칙을 생성하여 idmclient 시스템에서 /usr/sbin/reboot 명령을 실행할 수 있는 권한을 부여합니다.

사전 요구 사항

  • IdM 관리자로 로그인했습니다.
  • IdM에 idm_user 의 사용자 계정을 생성하고 사용자 암호를 생성하여 계정 잠금을 해제합니다. CLI를 사용하여 새 IdM 사용자를 추가하는 방법에 대한 자세한 내용은 명령줄을 사용하여 사용자 추가를 참조하십시오.
  • idmclient 호스트에 로컬 idm_user 계정이 없습니다. idm_user 사용자는 로컬 /etc/passwd 파일에 나열되지 않습니다.

절차

  1. IdM 관리자로 Kerberos 티켓을 검색합니다.

    [root@idmclient ~]# kinit admin
  2. /usr/sbin/reboot 명령을 sudo 명령의 IdM 데이터베이스에 추가합니다.

    [root@idmclient ~]# ipa sudocmd-add /usr/sbin/reboot
    -------------------------------------
    Added Sudo Command "/usr/sbin/reboot"
    -------------------------------------
      Sudo Command: /usr/sbin/reboot
  3. idm_user_reboot:라는 sudo 규칙을 만듭니다.

    [root@idmclient ~]# ipa sudorule-add idm_user_reboot
    ---------------------------------
    Added Sudo Rule "idm_user_reboot"
    ---------------------------------
      Rule name: idm_user_reboot
      Enabled: TRUE
  4. /usr/sbin/reboot 명령을 idm_user_reboot 규칙에 추가합니다.

    [root@idmclient ~]# ipa sudorule-add-allow-command idm_user_reboot --sudocmds '/usr/sbin/reboot'
      Rule name: idm_user_reboot
      Enabled: TRUE
      Sudo Allow Commands: /usr/sbin/reboot
    -------------------------
    Number of members added 1
    -------------------------
  5. IdM idmclient 호스트에 idm_user_reboot 규칙을 적용합니다.

    [root@idmclient ~]# ipa sudorule-add-host idm_user_reboot --hosts idmclient.idm.example.com
    Rule name: idm_user_reboot
    Enabled: TRUE
    Hosts: idmclient.idm.example.com
    Sudo Allow Commands: /usr/sbin/reboot
    -------------------------
    Number of members added 1
    -------------------------
  6. idm_user 계정을 idm_user_reboot 규칙에 추가합니다.

    [root@idmclient ~]# ipa sudorule-add-user idm_user_reboot --users idm_user
    Rule name: idm_user_reboot
    Enabled: TRUE
    Users: idm_user
    Hosts: idmclient.idm.example.com
    Sudo Allow Commands: /usr/sbin/reboot
    -------------------------
    Number of members added 1
    -------------------------
  7. 선택적으로 idm_user_reboot 규칙의 유효성을 정의합니다.

    1. sudo 규칙이 유효한 시간을 정의하려면 ipa sudo rule-mod sudo_rule_name 명령과 --setattr sudonotbefore=DATE 옵션을 사용합니다. DATE 값은 yyyymmddHHMMSSZ 형식을 따라야 하며, 초는 명시적으로 지정해야 합니다. 예를 들어, idm_user_reboot 규칙의 유효성 시작을 2025년 12월 31일 12:34:00으로 설정하려면 다음을 입력합니다.

      [root@idmclient ~]# ipa sudorule-mod idm_user_reboot --setattr sudonotbefore=20251231123400Z
    2. sudo 규칙이 유효한 중지 시간을 정의하려면 --setattr sudonotafter=DATE 옵션을 사용합니다. 예를 들어, idm_user_reboot 규칙 유효 기간을 2026년 12월 31일 12:34:00으로 설정하려면 다음을 입력합니다.

      [root@idmclient ~]# ipa sudorule-mod idm_user_reboot --setattr sudonotafter=20261231123400Z
참고

서버에서 클라이언트로 변경 사항을 전파하는 데 몇 분이 걸릴 수 있습니다.

검증 단계

  1. idmclient 호스트에 idm_user 계정으로 로그인합니다.
  2. idm_user 계정에서 수행할 수 있는 sudo 규칙을 표시합니다.

    [idm_user@idmclient ~]$ sudo -l
    Matching Defaults entries for idm_user on idmclient:
        !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
        env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
        env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
        env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
        env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
        env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY KRB5CCNAME",
        secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
    
    User idm_user may run the following commands on idmclient:
        (root) /usr/sbin/reboot
  3. sudo 를 사용하여 시스템을 재부팅합니다. 메시지가 표시되면 idm_user 의 암호를 입력합니다.

    [idm_user@idmclient ~]$ sudo /usr/sbin/reboot
    [sudo] password for idm_user:

8.3. CLI를 사용하여 IdM 클라이언트의 AD 사용자에게 sudo 액세스 권한 부여

IdM(Identity Management) 시스템 관리자는 IdM 사용자 그룹을 사용하여 IdM 사용자에 대한 액세스 권한, 호스트 기반 액세스 제어, sudo 규칙 및 기타 제어를 설정할 수 있습니다. IdM 사용자 그룹은 IdM 도메인 리소스에 대한 액세스 권한을 부여하고 제한합니다.

AD(Active Directory) 사용자와 AD 그룹을 모두 IdM 사용자 그룹에 추가할 수 있습니다. 다음을 수행하려면 다음을 수행합니다.

  1. POSIX가 아닌 외부 IdM 그룹에 AD 사용자 또는 그룹을 추가합니다.
  2. POSIX 이외의 외부 IdM 그룹을 IdM POSIX 그룹에 추가합니다.

그런 다음 POSIX 그룹의 권한을 관리하여 AD 사용자의 권한을 관리할 수 있습니다. 예를 들어 특정 IdM 호스트의 IdM POSIX 사용자 그룹에 특정 명령에 대한 sudo 액세스 권한을 부여할 수 있습니다.

참고

AD 사용자 그룹을 IdM 외부 그룹의 멤버로 추가할 수도 있습니다. 이렇게 하면 단일 AD 영역 내에서 사용자와 그룹 관리를 유지하여 Windows 사용자에 대한 정책을 보다 쉽게 정의할 수 있습니다.

중요

IdM의 SUDO 규칙에 AD 사용자의 ID 덮어쓰기를 사용하지 마십시오. AD 사용자의 ID 덮어쓰기는 AD 사용자가 아닌 AD 사용자의 POSIX 속성만 나타냅니다.

그룹 멤버로 ID 덮어쓰기를 추가할 수 있습니다. 그러나 이 기능은 IdM API에서 IdM 리소스를 관리하는 데만 사용할 수 있습니다. 그룹 멤버가 POSIX 환경으로 확장되지 않으므로 ID 덮어쓰기를 POSIX 환경으로 확장할 수 없으므로 sudo 또는 HBAC(Host-based Access Control) 규칙의 멤버십에는 사용할 수 없습니다.

다음 절차에 따라 administrator@ad-domain.com AD 사용자에게 root 사용자를 위해 예약된 idmclient IdM 호스트에서 /usr/sbin/reboot 명령을 실행할 수 있는 권한을 부여하는 ad_users_reboot sudo 규칙을 생성합니다. administrator@ad-domain.comad_users_external 비POSIX 그룹의 멤버입니다. 다음으로 ad_users POSIX 그룹의 멤버입니다.

사전 요구 사항

  • IdM admin Kerberos 티켓(TGT)이 있습니다.
  • IdM 도메인과 ad-domain.com AD 도메인 사이에 교차 신뢰가 있습니다.
  • idmclient 호스트에 로컬 관리자 계정이 없습니다. administrator 사용자는 로컬 /etc/passwd 파일에 나열되지 않습니다.

절차

  1. administrator@ad-domain 멤버가 있는 ad_users _external 그룹이 포함된 ad_users 그룹을 생성합니다.

    1. 선택 사항: IdM 영역에서 AD 사용자를 관리하는 데 사용할 AD 도메인에서 해당 그룹을 생성하거나 선택합니다. 여러 AD 그룹을 사용하여 IdM 측면의 다른 그룹에 추가할 수 있습니다.
    2. ad_users_external 그룹을 생성하고 --external 옵션을 추가하여 IdM 도메인 외부에서 멤버가 포함되어 있음을 나타냅니다.

      [root@ipaserver ~]# ipa group-add --desc='AD users external map' ad_users_external --external
      -------------------------------
      Added group "ad_users_external"
      -------------------------------
        Group name: ad_users_external
        Description: AD users external map
      참고

      여기에서 지정하는 외부 그룹이 Active Directory 보안 그룹 문서에 정의된 대로 글로벌 또는 Universal 그룹 범위가 있는 AD 보안 그룹 인지 확인합니다. 예를 들어, 해당 그룹 범위가 도메인 로컬 이므로 도메인 사용자 또는 도메인 관리자 AD 보안 그룹을 사용할 수 없습니다.

    3. ad_users 그룹을 생성합니다.

      [root@ipaserver ~]# ipa group-add --desc='AD users' ad_users
      ----------------------
      Added group "ad_users"
      ----------------------
        Group name: ad_users
        Description: AD users
        GID: 129600004
    4. administrator@ad-domain.com AD 사용자를 ad_users_external 에 외부 멤버로 추가합니다.

      [root@ipaserver ~]# ipa group-add-member ad_users_external --external "administrator@ad-domain.com"
       [member user]:
       [member group]:
        Group name: ad_users_external
        Description: AD users external map
        External member: S-1-5-21-3655990580-1375374850-1633065477-513
      -------------------------
      Number of members added 1
      -------------------------

      AD 사용자는 DOMAIN\user_name 또는 user_name@DOMAIN 과 같은 정규화된 이름으로 식별되어야 합니다. 그러면 AD ID가 사용자의 AD SID에 매핑됩니다. AD 그룹 추가에도 동일하게 적용됩니다.

    5. ad_users_externalad_users 에 멤버로 추가합니다.

      [root@ipaserver ~]# ipa group-add-member ad_users --groups ad_users_external
        Group name: ad_users
        Description: AD users
        GID: 129600004
        Member groups: ad_users_external
      -------------------------
      Number of members added 1
      -------------------------
  2. ad_users 의 멤버에게 idmclient 호스트에서 /usr/sbin/reboot 를 실행할 수 있는 권한을 부여합니다.

    1. /usr/sbin/reboot 명령을 sudo 명령의 IdM 데이터베이스에 추가합니다.

      [root@idmclient ~]# ipa sudocmd-add /usr/sbin/reboot
      -------------------------------------
      Added Sudo Command "/usr/sbin/reboot"
      -------------------------------------
        Sudo Command: /usr/sbin/reboot
    2. ad_users_reboot:라는 sudo 규칙을 만듭니다.

      [root@idmclient ~]# ipa sudorule-add ad_users_reboot
      ---------------------------------
      Added Sudo Rule "ad_users_reboot"
      ---------------------------------
        Rule name: ad_users_reboot
        Enabled: True
    3. ad_users_reboot 규칙에 /usr/sbin/reboot 명령을 추가합니다.

      [root@idmclient ~]# ipa sudorule-add-allow-command ad_users_reboot --sudocmds '/usr/sbin/reboot'
        Rule name: ad_users_reboot
        Enabled: True
        Sudo Allow Commands: /usr/sbin/reboot
      -------------------------
      Number of members added 1
      -------------------------
    4. IdM idmclient 호스트에 ad_users_reboot 규칙을 적용합니다.

      [root@idmclient ~]# ipa sudorule-add-host ad_users_reboot --hosts idmclient.idm.example.com
      Rule name: ad_users_reboot
      Enabled: True
      Hosts: idmclient.idm.example.com
      Sudo Allow Commands: /usr/sbin/reboot
      -------------------------
      Number of members added 1
      -------------------------
    5. ad_users _ reboot 규칙에 ad_users 그룹을 추가합니다.

      [root@idmclient ~]# ipa sudorule-add-user ad_users_reboot --groups ad_users
      Rule name: ad_users_reboot
      Enabled: TRUE
      User Groups: ad_users
      Hosts: idmclient.idm.example.com
      Sudo Allow Commands: /usr/sbin/reboot
      -------------------------
      Number of members added 1
      -------------------------
참고

서버에서 클라이언트로 변경 사항을 전파하는 데 몇 분이 걸릴 수 있습니다.

검증 단계

  1. idmclient 호스트에 administrator@ad-domain.com, ad_users 그룹의 간접 멤버로 로그인합니다.

    $ ssh administrator@ad-domain.com@ipaclient
    Password:
  2. 필요한 경우 administrator@ad-domain.com 을 실행할 수 있는 sudo 명령을 표시합니다.

    [administrator@ad-domain.com@idmclient ~]$ sudo -l
    Matching Defaults entries for administrator@ad-domain.com on idmclient:
        !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
        env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
        env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
        env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
        env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
        env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY KRB5CCNAME",
        secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
    
    User administrator@ad-domain.com may run the following commands on idmclient:
        (root) /usr/sbin/reboot
  3. sudo 를 사용하여 시스템을 재부팅합니다. 메시지가 표시되면 administrator@ad-domain.com 의 암호를 입력합니다.

    [administrator@ad-domain.com@idmclient ~]$ sudo /usr/sbin/reboot
    [sudo] password for administrator@ad-domain.com:

8.4. IdM 웹 UI를 사용하여 IdM 클라이언트의 IdM 사용자에게 sudo 액세스 권한 부여

IdM(Identity Management)에서는 특정 IdM 호스트의 IdM 사용자 계정에 대한 sudo 액세스 권한을 특정 명령에 부여할 수 있습니다. 먼저 sudo 명령을 추가한 다음 하나 이상의 명령에 대한 sudo 규칙을 만듭니다.

idm_user_reboot sudo 규칙을 생성하여 idm _user 계정에 idm client 시스템에서 /usr/sbin/reboot 명령을 실행할 수 있는 권한을 부여하려면 이 절차를 완료합니다.

사전 요구 사항

  • IdM 관리자로 로그인했습니다.
  • IdM에서 idm_user 에 대한 사용자 계정을 생성하고 사용자의 암호를 만들어 계정의 잠금을 해제했습니다. 명령줄 인터페이스를 사용하여 새 IdM 사용자를 추가하는 방법에 대한 자세한 내용은 명령줄을 사용하여 사용자 추가를 참조하십시오.
  • idmclient 호스트에 로컬 idm_user 계정이 없습니다. idm_user 사용자는 로컬 /etc/passwd 파일에 나열되지 않습니다.

절차

  1. /usr/sbin/reboot 명령을 sudo 명령의 IdM 데이터베이스에 추가합니다.

    1. 정책Sudo → Sudo 명령으로 이동합니다.
    2. 오른쪽 상단 모서리에서 Add (추가)를 클릭하여 Add sudo 명령 대화 상자를 엽니다.
    3. sudo:/usr/sbin/reboot 를 사용하여 사용자가 수행할 수 있는 명령을 입력합니다.

      그림 8.1. IdM sudo 명령 추가

      "Add sudo command( sudo 명령 추가)"라는 팝업 창의 스크린샷입니다. "/usr/sbin/reboot" 내용의 "Sudo 명령"이라는 레이블이 지정된 필수 필드가 있습니다. "설명" 필드가 비어 있습니다. 창의 오른쪽 아래에는 다음 네 개의 버튼이 있습니다. "add" - "Add and Add Other" - "Add and Edit" - "Cancel".
    4. 추가를 클릭합니다.
  2. sudo 명령 항목을 사용하여 idm_user가 idm client 시스템을 재부팅할 수 있도록 sudo 규칙을 생성합니다.

    1. 정책Sudo → Sudo 규칙으로 이동합니다.
    2. 오른쪽 상단 모서리에서 Add(추가 )를 클릭하여 Add sudo rule( sudo 규칙 추가) 대화 상자를 엽니다.
    3. sudo 규칙의 이름을 idm_user_reboot 로 입력합니다.
    4. Add and Edit(추가 및 편집)를 클릭합니다.
    5. 사용자를 지정합니다.

      1. who(사용자 ) 섹션에서 Specified Users and Groups(지정된 사용자 및 그룹 ) 라디오 단추를 선택합니다.
      2. User 카테고리에서 규칙이 하위 섹션에 적용되는 경우 Add(추가)를 클릭하여 Add users into sudo rule "idm_user_reboot" 대화 상자를 엽니다.
      3. Add users into sudo rule "idm_user_reboot" 대화 상자의 Available 열에서 idm_user 확인란을 선택하고 Prospective 열로 이동합니다.
      4. 추가를 클릭합니다.
    6. 호스트를 지정합니다.

      1. Access this host (이 호스트에 액세스) 섹션에서 Specified Hosts and Groups(지정된 호스트 및 그룹 ) 라디오 단추를 선택합니다.
      2. 호스트 범주에서 이 규칙이 하위 섹션에 적용되는 경우 Add(추가 )를 클릭하여 Add hosts into sudo rule "idm_user_reboot" 대화 상자를 엽니다.
      3. Add hosts to sudo rule "idm_user_reboot" 대화 상자의 Available 열에서 idmclient.idm.example.com 확인란을 선택하고 Prospective 열로 이동합니다.
      4. 추가를 클릭합니다.
    7. 명령을 지정합니다.

      1. Command 카테고리에서 규칙이 Run Commands(명령 실행) 섹션의 하위 섹션에 적용되는 경우 Specified Commands and Groups(지정된 명령) 및 Groups (그룹) 라디오 버튼을 선택합니다.
      2. Sudo Allow Commands (Sudo Allow Commands) 하위 섹션에서 Add allow sudo 명령을 sudo rule "idm_user_reboot" 대화 상자에 엽니다.
      3. Add allow sudo 명령을 sudo 규칙 "idm_user_reboot" 대화 상자의 Available 열에서 /usr/sbin/reboot 확인란을 선택하고 Prospective 열로 이동합니다.
      4. Add(추가 )를 클릭하여 idm_sudo_reboot 페이지로 돌아갑니다.

      그림 8.2. IdM sudo 규칙 추가

      추가된 sudo 규칙의 개요에 대한 스크린샷입니다. 규칙이 적용되는 사용자 테이블이 있는 "Who" 섹션이 있습니다. 규칙이 적용되는 호스트 테이블이 있는 "이 호스트 액세스" 섹션이 있습니다. 규칙에 관련된 명령 테이블이 있는 "실행 명령" 섹션이 있습니다.
    8. 왼쪽 상단 모서리에서 Save(저장 )를 클릭합니다.

새 규칙은 기본적으로 활성화되어 있습니다.

참고

서버에서 클라이언트로 변경 사항을 전파하는 데 몇 분이 걸릴 수 있습니다.

검증 단계

  1. idmclient에 idm _user 로 로그인합니다.
  2. sudo 를 사용하여 시스템을 재부팅합니다. 메시지가 표시되면 idm_user 의 암호를 입력합니다.

    $ sudo /usr/sbin/reboot
    [sudo] password for idm_user:

sudo 규칙이 올바르게 구성되면 시스템이 재부팅됩니다.

8.5. IdM 클라이언트에서 서비스 계정으로 명령을 실행하는 CLI에 sudo 규칙 생성

IdM에서는 RunAs 별칭 을 사용하여 sudo 규칙을 구성하여 다른 사용자 또는 그룹으로 sudo 명령을 실행할 수 있습니다. 예를 들어 데이터베이스 애플리케이션을 호스팅하는 IdM 클라이언트가 있을 수 있으며 해당 애플리케이션에 해당하는 로컬 서비스 계정으로 명령을 실행해야 합니다.

이 예제를 사용하여 run_ third-party-app_report 라는 명령에 sudo 규칙을 생성하여 idm_user 계정이 idmclient 호스트의 thirdpartyapp 서비스 계정으로 /opt/ third-party-app/bin/report 명령을 실행할 수 있도록 합니다.

사전 요구 사항

  • IdM 관리자로 로그인했습니다.
  • IdM에서 idm_user 에 대한 사용자 계정을 생성하고 사용자의 암호를 만들어 계정의 잠금을 해제했습니다. CLI를 사용하여 새 IdM 사용자를 추가하는 방법에 대한 자세한 내용은 명령줄을 사용하여 사용자 추가를 참조하십시오.
  • idmclient 호스트에 로컬 idm_user 계정이 없습니다. idm_user 사용자는 로컬 /etc/passwd 파일에 나열되지 않습니다.
  • idmclient 호스트에 타사-app 이라는 사용자 지정 애플리케이션이 설치되어 있습니다.
  • 타사 애플리케이션에 대한 report 명령이 /opt/ third-party-app /bin/report 디렉터리에 설치됩니다.
  • third-party-app 애플리케이션에 대한 명령을 실행하도록 thirdpartyapp 이라는 로컬 서비스 계정을 생성했습니다.

절차

  1. IdM 관리자로 Kerberos 티켓을 검색합니다.

    [root@idmclient ~]# kinit admin
  2. sudo 명령의 IdM 데이터베이스에 /opt/ third-party-app/bin/report 명령을 추가합니다.

    [root@idmclient ~]# ipa sudocmd-add /opt/third-party-app/bin/report
    ----------------------------------------------------
    Added Sudo Command "/opt/third-party-app/bin/report"
    ----------------------------------------------------
      Sudo Command: /opt/third-party-app/bin/report
  3. run_ third-party-app_report 라는 sudo 규칙을 만듭니다.

    [root@idmclient ~]# ipa sudorule-add run_third-party-app_report
    --------------------------------------------
    Added Sudo Rule "run_third-party-app_report"
    --------------------------------------------
      Rule name: run_third-party-app_report
      Enabled: TRUE
  4. --users=<user> 옵션을 사용하여 sudorule-add-runasuser 명령에 대해 RunAs 사용자를 지정합니다.

    [root@idmclient ~]# ipa sudorule-add-runasuser run_third-party-app_report --users=thirdpartyapp
      Rule name: run_third-party-app_report
      Enabled: TRUE
      RunAs External User: thirdpartyapp
    -------------------------
    Number of members added 1
    -------------------------

    --groups=* 옵션으로 지정된 사용자(또는 그룹 그룹)는 로컬 서비스 계정 또는 Active Directory 사용자와 같은 IdM 외부일 수 있습니다. 그룹 이름에 % 접두사를 추가하지 마십시오.

  5. /opt/ bad-party-app/bin/report 명령을 run_knative-party-app_report 규칙에 추가합니다.

    [root@idmclient ~]# ipa sudorule-add-allow-command run_third-party-app_report --sudocmds '/opt/third-party-app/bin/report'
    Rule name: run_third-party-app_report
    Enabled: TRUE
    Sudo Allow Commands: /opt/third-party-app/bin/report
    RunAs External User: thirdpartyapp
    -------------------------
    Number of members added 1
    -------------------------
  6. IdM idmclient 호스트에 run_ third-party-app_report 규칙을 적용합니다.

    [root@idmclient ~]# ipa sudorule-add-host run_third-party-app_report --hosts idmclient.idm.example.com
    Rule name: run_third-party-app_report
    Enabled: TRUE
    Hosts: idmclient.idm.example.com
    Sudo Allow Commands: /opt/third-party-app/bin/report
    RunAs External User: thirdpartyapp
    -------------------------
    Number of members added 1
    -------------------------
  7. idm_user 계정을 run_ third-party-app_report 규칙에 추가합니다.

    [root@idmclient ~]# ipa sudorule-add-user run_third-party-app_report --users idm_user
    Rule name: run_third-party-app_report
    Enabled: TRUE
    Users: idm_user
    Hosts: idmclient.idm.example.com
    Sudo Allow Commands: /opt/third-party-app/bin/report
    RunAs External User: thirdpartyapp
    -------------------------
    Number of members added 1
참고

서버에서 클라이언트로 변경 사항을 전파하는 데 몇 분이 걸릴 수 있습니다.

검증 단계

  1. idmclient 호스트에 idm _user 계정으로 로그인합니다.
  2. 새 sudo 규칙을 테스트합니다.

    1. idm_user 계정이 수행할 수 있는 sudo 규칙을 표시합니다.

      [idm_user@idmclient ~]$ sudo -l
      Matching Defaults entries for idm_user@idm.example.com on idmclient:
          !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
          env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
          env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
          env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
          env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
          env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY KRB5CCNAME",
          secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
      
      User idm_user@idm.example.com may run the following commands on idmclient:
          (thirdpartyapp) /opt/third-party-app/bin/report
    2. thirdpartyapp 서비스 계정으로 report 명령을 실행합니다.

      [idm_user@idmclient ~]$ sudo -u thirdpartyapp /opt/third-party-app/bin/report
      [sudo] password for idm_user@idm.example.com:
      Executing report...
      Report successful.

8.6. IdM 클라이언트에서 서비스 계정으로 명령을 실행하는 IdM WebUI에서 sudo 규칙 생성

IdM에서는 RunAs 별칭 을 사용하여 sudo 규칙을 구성하여 다른 사용자 또는 그룹으로 sudo 명령을 실행할 수 있습니다. 예를 들어 데이터베이스 애플리케이션을 호스팅하는 IdM 클라이언트가 있을 수 있으며 해당 애플리케이션에 해당하는 로컬 서비스 계정으로 명령을 실행해야 합니다.

이 예제를 사용하여 idm_user 계정이 idmclient 호스트에서 타사 서비스 계정으로 /opt/ third-party-app/report 명령을 실행할 수 있도록 run_ third-party- app _report 라는 IdM 웹 UI에 sudo 규칙을 생성합니다.

사전 요구 사항

  • IdM 관리자로 로그인했습니다.
  • IdM에서 idm_user 에 대한 사용자 계정을 생성하고 사용자의 암호를 만들어 계정의 잠금을 해제했습니다. CLI를 사용하여 새 IdM 사용자를 추가하는 방법에 대한 자세한 내용은 명령줄을 사용하여 사용자 추가를 참조하십시오.
  • idmclient 호스트에 로컬 idm_user 계정이 없습니다. idm_user 사용자는 로컬 /etc/passwd 파일에 나열되지 않습니다.
  • idmclient 호스트에 타사-app 이라는 사용자 지정 애플리케이션이 설치되어 있습니다.
  • 타사 애플리케이션에 대한 report 명령이 /opt/ third-party-app /bin/report 디렉터리에 설치됩니다.
  • third-party-app 애플리케이션에 대한 명령을 실행하도록 thirdpartyapp 이라는 로컬 서비스 계정을 생성했습니다.

절차

  1. sudo 명령의 IdM 데이터베이스에 /opt/ third-party-app/bin/report 명령을 추가합니다.

    1. 정책Sudo → Sudo 명령으로 이동합니다.
    2. 오른쪽 상단 모서리에서 Add (추가)를 클릭하여 Add sudo 명령 대화 상자를 엽니다.
    3. /opt/ third-party-app/bin/report 명령을 입력합니다.

      "Add sudo command( sudo 명령 추가)"라는 팝업 창의 스크린샷입니다. "/opt/ third-party-app/bin/report" 콘텐츠와 함께 "Sudo 명령" 레이블이 지정된 필수 필드가 있습니다. "설명" 필드가 비어 있습니다. 창의 오른쪽 아래에는 다음 네 개의 버튼이 있습니다. "add" - "Add and Add Other" - "Add and Edit" - "Cancel".
    4. 추가를 클릭합니다.
  2. sudo 명령 항목을 사용하여 새 sudo 규칙을 만듭니다.

    1. 정책Sudo → Sudo 규칙으로 이동합니다.
    2. 오른쪽 상단 모서리에서 Add(추가 )를 클릭하여 Add sudo rule( sudo 규칙 추가) 대화 상자를 엽니다.
    3. sudo 규칙의 이름을 입력합니다. run_ third-party-app_report.

      "Add sudo rule"이라는 팝업 창의 스크린샷입니다. "run_ third-party-app_report" 콘텐츠를 사용하여 "Rule name"이라는 필수 필드가 있습니다. 창의 오른쪽 아래에는 다음 네 개의 버튼이 있습니다. "add" - "Add and Add Other" - "Add and Edit" - "Cancel".
    4. Add and Edit(추가 및 편집)를 클릭합니다.
    5. 사용자를 지정합니다.

      1. who(사용자 ) 섹션에서 Specified Users and Groups(지정된 사용자 및 그룹 ) 라디오 단추를 선택합니다.
      2. User category the rule applies to 하위 섹션에 적용되는 규칙 추가 를 클릭하여 sudo 규칙 "run_ third-party-app_report" 대화 상자에 사용자 추가 를 엽니다.
      3. Add users into sudo rule "run_ third-party-app_report" 대화 상자에서 Available 열의 idm_user 확인란을 확인하고 Prospective 열로 이동합니다.

        "Add users into sudo rule"이라는 팝업 창의 스크린샷입니다. 왼쪽의 Available 목록에서 사용자를 선택하고 오른쪽의 Prospective 열로 이동할 수 있습니다. 창의 오른쪽 아래에는 두 개의 버튼이 있습니다. "Add" - "Cancel".
      4. 추가를 클릭합니다.
    6. 호스트를 지정합니다.

      1. Access this host (이 호스트에 액세스) 섹션에서 Specified Hosts and Groups(지정된 호스트 및 그룹 ) 라디오 단추를 선택합니다.
      2. Host category this rule applies to 하위 섹션에 적용되는 규칙 추가 를 클릭하여 sudo 규칙 "run_ third-party-app_report" 대화 상자에 호스트 추가 를 엽니다.
      3. Available 열의 Add hosts into sudo 규칙 "run_ third-party-app_report" 대화 상자에서 idmclient.idm.example.com 확인란을 선택하고 이를 Prospective 열로 이동합니다.

        "Add host into sudo rule"이라는 팝업 창의 스크린샷입니다. 왼쪽의 Available 목록에서 호스트를 선택하고 오른쪽의 Prospective 열로 이동할 수 있습니다. 창의 오른쪽 아래에는 두 개의 버튼이 있습니다. "Add" - "Cancel".
      4. 추가를 클릭합니다.
    7. 명령을 지정합니다.

      1. Command 카테고리에서 규칙이 Run Commands(명령 실행) 섹션의 하위 섹션에 적용되는 경우 Specified Commands and Groups(지정된 명령) 및 Groups (그룹) 라디오 버튼을 선택합니다.
      2. Sudo Allow Commands 하위 섹션에서 Add 를 클릭하여 Add allow sudo 명령을 sudo 규칙 "run_ third-party-app_report" 대화 상자에 엽니다.
      3. Add allow sudo 명령의 Available 열의 sudo 규칙 "run_ third-party-app_report" 대화 상자에서 /opt/ third-party-app/bin/report 확인란을 선택하고 이를 Prospective 열로 이동합니다.

        "Add allow sudo commands into sudo rule"이라는 팝업 창의 스크린샷입니다. 왼쪽의 Available 목록에서 sudo 명령을 선택하고 오른쪽의 Prospective 열로 이동할 수 있습니다. 창의 오른쪽 아래에는 두 개의 버튼이 있습니다. "Add" - "Cancel".
      4. Add 를 클릭하여 run_ third-party-app_report 페이지로 돌아갑니다.
    8. RunAs 사용자를 지정합니다.

      1. As whom 섹션에서 지정된 사용자 및 그룹 라디오 버튼을 확인합니다.
      2. RunAs Users 하위 섹션에서 Add 를 클릭하여 Add RunAs 사용자를 sudo 규칙 "run_ third-party-app_report" 대화 상자에 엽니다.
      3. Add RunAs users into sudo rule "run_ third-party-app_report" 대화 상자에서 External 상자에 third partyapp 서비스 계정을 입력하고 Prospective 열로 이동합니다.

        " thirdpartyapp" 서비스 계정을 외부 사용자로 지정할 수 있는 대화 상자의 스크린샷입니다.
      4. Add 를 클릭하여 run_ third-party-app_report 페이지로 돌아갑니다.
    9. 왼쪽 상단 모서리에서 Save(저장 )를 클릭합니다.

새 규칙은 기본적으로 활성화되어 있습니다.

그림 8.3. sudo 규칙의 세부 사항

추가된 sudo 규칙의 개요에 대한 스크린샷입니다. "Who" 섹션에는 "idm_user"에 대한 항목이 있습니다. "Access this host" 섹션에는 "idmclient.idm.example.com"이 있습니다. "실행 명령" 섹션에는 "/opt/ third-party-app/bin/report" 명령이 있습니다. "제목" 섹션에는 " thirdpartyapp" 계정이 나열됩니다.
참고

서버에서 클라이언트로 변경 사항을 전파하는 데 몇 분이 걸릴 수 있습니다.

검증 단계

  1. idmclient 호스트에 idm _user 계정으로 로그인합니다.
  2. 새 sudo 규칙을 테스트합니다.

    1. idm_user 계정이 수행할 수 있는 sudo 규칙을 표시합니다.

      [idm_user@idmclient ~]$ sudo -l
      Matching Defaults entries for idm_user@idm.example.com on idmclient:
          !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
          env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
          env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
          env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
          env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
          env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY KRB5CCNAME",
          secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
      
      User idm_user@idm.example.com may run the following commands on idmclient:
          (thirdpartyapp) /opt/third-party-app/bin/report
    2. thirdpartyapp 서비스 계정으로 report 명령을 실행합니다.

      [idm_user@idmclient ~]$ sudo -u thirdpartyapp /opt/third-party-app/bin/report
      [sudo] password for idm_user@idm.example.com:
      Executing report...
      Report successful.

8.7. IdM 클라이언트에서 sudo에 대해 GSSAPI 인증 활성화

다음 절차에서는 pam_sss_gss.so PAM 모듈을 통해 sudosudo -i 명령에 대한 IdM 클라이언트에서 Generic Security Service Application Program Interface(GSSAPI) 인증을 활성화하는 방법을 설명합니다. 이 구성을 통해 IdM 사용자는 Kerberos 티켓을 사용하여 sudo 명령으로 인증할 수 있습니다.

사전 요구 사항

  • IdM 호스트에 적용되는 IdM 사용자에 대한 sudo 규칙을 생성했습니다. 이 예제에서는 idm_user 계정에 idm_ sbin/reboot 명령을 실행할 수 있는 권한을 부여하는 idm _user_ reboot sudo 규칙을 생성했습니다.
  • idmclient 호스트는 RHEL 8.4 이상을 실행하고 있습니다.
  • /etc/ pam.d / 디렉토리에서 /etc/sssd/sssd.conf 파일과 PAM 파일을 수정하려면 root 권한이 필요합니다.

절차

  1. /etc/sssd/sssd.conf 구성 파일을 엽니다.
  2. 다음 항목을 [domain/<domain_name>] 섹션에 추가합니다.

    [domain/<domain_name>]
    pam_gssapi_services = sudo, sudo-i
  3. /etc/sssd/sssd.conf 파일을 저장하고 닫습니다.
  4. SSSD 서비스를 다시 시작하여 구성 변경 사항을 로드합니다.

    [root@idmclient ~]# systemctl restart sssd
  5. RHEL 8.8 이상을 실행하는 경우:

    1. [선택 사항] sssd authselect 프로필을 선택한 경우 확인합니다.

      # authselect current
      Profile ID: sssd

      출력에 sssd authselect 프로필이 선택됩니다.

    2. sssd authselect 프로필이 선택된 경우 GSSAPI 인증을 활성화합니다.

      # authselect enable-feature with-gssapi
    3. sssd authselect 프로필이 선택되어 있지 않으면 해당 프로필을 선택하고 GSSAPI 인증을 활성화합니다.

      # authselect select sssd with-gssapi
  6. RHEL 8.7 이하를 실행하는 경우:

    1. /etc/pam.d/sudo PAM 구성 파일을 엽니다.
    2. 다음 항목을 /etc/pam.d/sudo 파일에 있는 auth 섹션의 첫 번째 행으로 추가합니다.

      #%PAM-1.0
      auth sufficient pam_sss_gss.so
      auth       include      system-auth
      account    include      system-auth
      password   include      system-auth
      session    include      system-auth
    3. /etc/pam.d/sudo 파일을 저장하고 닫습니다.

검증 단계

  1. idm_user 계정으로 호스트에 로그인합니다.

    [root@idm-client ~]# ssh -l idm_user@idm.example.com localhost
    idm_user@idm.example.com's password:
  2. 티켓이 idm_user 계정으로 티켓을 부여했는지 확인합니다.

    [idmuser@idmclient ~]$ klist
    Ticket cache: KCM:1366201107
    Default principal: idm_user@IDM.EXAMPLE.COM
    
    Valid starting       Expires              Service principal
    01/08/2021 09:11:48  01/08/2021 19:11:48  krbtgt/IDM.EXAMPLE.COM@IDM.EXAMPLE.COM
    	renew until 01/15/2021 09:11:44
  3. (선택 사항) idm_user 계정에 대한 Kerberos 인증 정보가 없는 경우 현재 Kerberos 자격 증명을 삭제하고 올바른 정보를 요청합니다.

    [idm_user@idmclient ~]$ kdestroy -A
    
    [idm_user@idmclient ~]$ kinit idm_user@IDM.EXAMPLE.COM
    Password for idm_user@idm.example.com:
  4. 암호를 지정하지 않고 sudo 를 사용하여 시스템을 재부팅합니다.

    [idm_user@idmclient ~]$ sudo /usr/sbin/reboot

8.8. GSSAPI 인증 활성화 및 IdM 클라이언트에서 sudo에 대한 Kerberos 인증 표시기 적용

다음 절차에서는 pam_sss_gss.so PAM 모듈을 통해 sudosudo -i 명령에 대한 IdM 클라이언트에서 Generic Security Service Application Program Interface(GSSAPI) 인증을 활성화하는 방법을 설명합니다. 또한 스마트 카드로 로그인한 사용자만 Kerberos 티켓을 사용하여 해당 명령에 인증됩니다.

참고

이 절차를 템플릿으로 사용하여 다른 PAM 인식 서비스에 대해 SSSD를 사용하여 GSSAPI 인증을 구성하고, Kerberos 티켓에 특정 인증 표시기가 연결된 사용자에게만 액세스를 제한할 수 있습니다.

사전 요구 사항

  • IdM 호스트에 적용되는 IdM 사용자에 대한 sudo 규칙을 생성했습니다. 이 예제에서는 idm_user 계정에 idm_ sbin/reboot 명령을 실행할 수 있는 권한을 부여하는 idm _user_ reboot sudo 규칙을 생성했습니다.
  • idmclient 호스트에 대해 스마트 카드 인증을 구성했습니다.
  • idmclient 호스트는 RHEL 8.4 이상을 실행하고 있습니다.
  • /etc/ pam.d / 디렉토리에서 /etc/sssd/sssd.conf 파일과 PAM 파일을 수정하려면 root 권한이 필요합니다.

절차

  1. /etc/sssd/sssd.conf 구성 파일을 엽니다.
  2. 다음 항목을 [domain/<domain_name>] 섹션에 추가합니다.

    [domain/<domain_name>]
    pam_gssapi_services = sudo, sudo-i
    pam_gssapi_indicators_map = sudo:pkinit, sudo-i:pkinit
  3. /etc/sssd/sssd.conf 파일을 저장하고 닫습니다.
  4. SSSD 서비스를 다시 시작하여 구성 변경 사항을 로드합니다.

    [root@idmclient ~]# systemctl restart sssd
  5. /etc/pam.d/sudo PAM 구성 파일을 엽니다.
  6. 다음 항목을 /etc/pam.d/sudo 파일에 있는 auth 섹션의 첫 번째 행으로 추가합니다.

    #%PAM-1.0
    auth sufficient pam_sss_gss.so
    auth       include      system-auth
    account    include      system-auth
    password   include      system-auth
    session    include      system-auth
  7. /etc/pam.d/sudo 파일을 저장하고 닫습니다.
  8. /etc/pam.d/sudo-i PAM 구성 파일을 엽니다.
  9. 다음 항목을 /etc/pam.d/sudo-i 파일에 있는 auth 섹션의 첫 행으로 추가합니다.

    #%PAM-1.0
    auth sufficient pam_sss_gss.so
    auth       include      sudo
    account    include      sudo
    password   include      sudo
    session    optional     pam_keyinit.so force revoke
    session    include      sudo
  10. /etc/pam.d/sudo-i 파일을 저장하고 닫습니다.

검증 단계

  1. idm_user 계정으로 호스트에 로그인하고 스마트 카드로 인증합니다.

    [root@idmclient ~]# ssh -l idm_user@idm.example.com localhost
    PIN for smart_card
  2. 스마트 카드 사용자로 티켓이 제공된지 확인합니다.

    [idm_user@idmclient ~]$ klist
    Ticket cache: KEYRING:persistent:1358900015:krb_cache_TObtNMd
    Default principal: idm_user@IDM.EXAMPLE.COM
    
    Valid starting       Expires              Service principal
    02/15/2021 16:29:48  02/16/2021 02:29:48  krbtgt/IDM.EXAMPLE.COM@IDM.EXAMPLE.COM
    	renew until 02/22/2021 16:29:44
  3. idm_user 계정이 수행할 수 있는 sudo 규칙을 표시합니다.

    [idm_user@idmclient ~]$ sudo -l
    Matching Defaults entries for idmuser on idmclient:
        !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
        env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
        env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
        env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
        env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
        env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY KRB5CCNAME",
        secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
    
    User idm_user may run the following commands on idmclient:
        (root) /usr/sbin/reboot
  4. 암호를 지정하지 않고 sudo 를 사용하여 시스템을 재부팅합니다.

    [idm_user@idmclient ~]$ sudo /usr/sbin/reboot

8.9. PAM 서비스에 대한 GSSAPI 인증을 제어하는 SSSD 옵션

/etc/sssd/sssd.conf 구성 파일에 다음 옵션을 사용하여 SSSD 서비스 내에서 GSSAPI 구성을 조정할 수 있습니다.

pam_gssapi_services
SSSD를 사용한 GSSAPI 인증은 기본적으로 비활성화되어 있습니다. 이 옵션을 사용하여 pam_ss_gss.so PAM 모듈을 사용하여 GSSAPI 인증을 시도할 수 있는 PAM 서비스의 쉼표로 구분된 목록을 지정할 수 있습니다. GSSAPI 인증을 명시적으로 비활성화하려면 이 옵션을 - 로 설정합니다.
pam_gssapi_indicators_map

이 옵션은 IdM(Identity Management) 도메인에만 적용됩니다. 이 옵션을 사용하여 서비스에 대한 PAM 액세스 권한을 부여하는 데 필요한 Kerberos 인증 표시기를 나열합니다. 쌍은 <PAM_service> :_< required_authentication_indicator>_ 형식이어야 합니다.

유효한 인증 표시기는 다음과 같습니다.

  • 이중 인증을 위한 OTP
  • RADIUS 인증을 위한 준비
  • PKINIT, 스마트 카드 또는 인증서 인증을 위한 Pk init
  • 강화된 암호를 위한 강화
pam_gssapi_check_upn
이 옵션은 활성화되어 있으며 기본적으로 true 로 설정됩니다. 이 옵션을 활성화하면 SSSD 서비스에 사용자 이름이 Kerberos 자격 증명과 일치해야 합니다. false인 경우 pam_sss_gss.so PAM 모듈은 필수 서비스 티켓을 가져올 수 있는 모든 사용자를 인증합니다.

다음 옵션을 사용하면 sudo 및 sudo -i 서비스에 Kerberos 인증을 사용하려면 sudo 사용자가 일회성 암호로 인증해야 하며 사용자 이름은 Kerberos 주체와 일치해야 합니다. 이러한 설정은 [pam] 섹션에 있으므로 모든 도메인에 적용됩니다.

[pam]
pam_gssapi_services = sudo, sudo-i
pam_gssapi_indicators_map = sudo:otp
pam_gssapi_check_upn = true

이러한 옵션을 개별 [domain] 섹션에 설정하여 [pam] 섹션의 전역 값을 덮어쓸 수도 있습니다. 다음 옵션은 각 도메인에 다른 GSSAPI 설정을 적용합니다.

idm.example.com 도메인의 경우
  • sudo 및 sudo -i 서비스에 대해 GSSAPI 인증을 활성화합니다.
  • sudo 명령에는 인증서 또는 스마트 카드 인증 인증기가 필요합니다.
  • sudo -i 명령에 대해 일회성 암호 인증 프로그램이 필요합니다.
  • 일치하는 사용자 이름과 Kerberos 주체 적용.
ad.example.com 도메인의 경우
  • sudo 서비스에 대해서만 GSSAPI 인증을 활성화합니다.
  • 일치하는 사용자 이름과 주체를 적용하지 마십시오.
[domain/idm.example.com]
pam_gssapi_services = sudo, sudo-i
pam_gssapi_indicators_map = sudo:pkinit, sudo-i:otp
pam_gssapi_check_upn = true
...

[domain/ad.example.com]
pam_gssapi_services = sudo
pam_gssapi_check_upn = false
...

추가 리소스

8.10. sudo에 대한 GSSAPI 인증 문제 해결

IdM에서 Kerberos 티켓을 사용하여 sudo 서비스를 인증할 수 없는 경우 다음 시나리오를 사용하여 구성 문제를 해결합니다.

사전 요구 사항

절차

  • 다음 오류가 표시되면 Kerberos 서비스에서 호스트 이름을 기반으로 서비스 티켓에 대한 올바른 영역을 확인할 수 없습니다.

    Server not found in Kerberos database

    이 경우 /etc/krb5.conf Kerberos 구성 파일의 [domain_realm] 섹션에 직접 호스트 이름을 추가합니다.

    [idm-user@idm-client ~]$ cat /etc/krb5.conf
    ...
    
    [domain_realm]
     .example.com = EXAMPLE.COM
     example.com = EXAMPLE.COM
     server.example.com = EXAMPLE.COM
  • 다음 오류가 표시되면 Kerberos 인증 정보가 없습니다.

    No Kerberos credentials available

    이 경우 kinit 유틸리티를 사용하여 Kerberos 인증 정보를 검색하거나 SSSD로 인증합니다.

    [idm-user@idm-client ~]$ kinit idm-user@IDM.EXAMPLE.COM
    Password for idm-user@idm.example.com:
  • /var/log/sssd/sssd_pam.log 로그 파일에 다음 중 하나가 표시되면 Kerberos 자격 증명이 현재 로그인한 사용자의 사용자 이름과 일치하지 않습니다.

    User with UPN [<UPN>] was not found.
    
    UPN [<UPN>] does not match target user [<username>].

    이 경우 SSSD로 인증했는지 또는 /etc/sssd/sssd.conf 파일에서 pam_gssapi_check_upn 옵션을 비활성화하는 것이 좋습니다.

    [idm-user@idm-client ~]$ cat /etc/sssd/sssd.conf
    ...
    
    pam_gssapi_check_upn = false
  • 추가 문제 해결을 위해 pam_sss_gss.so PAM 모듈에 대한 디버깅 출력을 활성화할 수 있습니다.

    • PAM 파일의 모든 pam_sss_gss.so 항목(예: /etc/pam.d/ sudo 및 /etc/pam.d/sudo -i)의 끝에 debug 옵션을 추가합니다.

      [root@idm-client ~]# cat /etc/pam.d/sudo
      #%PAM-1.0
      auth       sufficient   pam_sss_gss.so   debug
      auth       include      system-auth
      account    include      system-auth
      password   include      system-auth
      session    include      system-auth
      [root@idm-client ~]# cat /etc/pam.d/sudo-i
      #%PAM-1.0
      auth       sufficient   pam_sss_gss.so   debug
      auth       include      sudo
      account    include      sudo
      password   include      sudo
      session    optional     pam_keyinit.so force revoke
      session    include      sudo
    • pam_sss_gss.so 모듈로 인증을 시도하고 콘솔 출력을 검토합니다. 이 예제에서 사용자에게 Kerberos 자격 증명이 없습니다.

      [idm-user@idm-client ~]$ sudo ls -l /etc/sssd/sssd.conf
      pam_sss_gss: Initializing GSSAPI authentication with SSSD
      pam_sss_gss: Switching euid from 0 to 1366201107
      pam_sss_gss: Trying to establish security context
      pam_sss_gss: SSSD User name: idm-user@idm.example.com
      pam_sss_gss: User domain: idm.example.com
      pam_sss_gss: User principal:
      pam_sss_gss: Target name: host@idm.example.com
      pam_sss_gss: Using ccache: KCM:
      pam_sss_gss: Acquiring credentials, principal name will be derived
      pam_sss_gss: Unable to read credentials from [KCM:] [maj:0xd0000, min:0x96c73ac3]
      pam_sss_gss: GSSAPI: Unspecified GSS failure.  Minor code may provide more information
      pam_sss_gss: GSSAPI: No credentials cache found
      pam_sss_gss: Switching euid from 1366200907 to 0
      pam_sss_gss: System error [5]: Input/output error

8.11. Ansible 플레이북을 사용하여 IdM 클라이언트에서 IdM 사용자에 대한 sudo 액세스 권한 확인

IdM(Identity Management)에서는 특정 명령에 대한 sudo 액세스 권한이 특정 IdM 호스트의 IdM 사용자 계정에 부여되도록 할 수 있습니다.

idm_user_reboot 라는 sudo 규칙이 있는지 확인하려면 다음 절차를 완료합니다. 규칙은 idm_useridmclient 시스템에서 /usr/sbin/reboot 명령을 실행할 수 있는 권한을 부여합니다.

사전 요구 사항

절차

  1. 인벤토리 파일(예: inventory.file )을 생성하고 여기에 ipaservers 를 정의합니다.

    [ipaservers]
    server.idm.example.com
  2. 하나 이상의 sudo 명령을 추가합니다.

    1. sudo 명령의 IdM 데이터베이스에 /usr/sbin/ reboot 명령이 있는지 확인하는 ensure-reboot -sudocmd-is-present.yml Ansible 플레이북을 생성합니다. 이 단계를 간소화하기 위해 /usr/share/doc/ansible-freeipa/playbooks/sudocmd/ensure-sudocmd-is-present.yml 파일에서 예제를 복사하고 수정할 수 있습니다.

      ---
      - name: Playbook to manage sudo command
        hosts: ipaserver
      
        vars_files:
        - /home/user_name/MyPlaybooks/secret.yml
        tasks:
        # Ensure sudo command is present
        - ipasudocmd:
            ipaadmin_password: "{{ ipaadmin_password }}"
            name: /usr/sbin/reboot
            state: present
    2. 플레이북을 실행합니다.

      $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-reboot-sudocmd-is-present.yml
  3. 명령을 참조하는 sudo 규칙을 생성합니다.

    1. sudo 명령 항목을 사용하여 sudo 규칙이 있는지 확인하는 ensure-sudorule-for-idmuser-on-idmclient-is-present.yml Ansible 플레이북을 만듭니다. sudo 규칙을 사용하면 idm_useridmclient 시스템을 재부팅할 수 있습니다. 이 단계를 간소화하기 위해 /usr/share/doc/ansible-freeipa/playbooks/sudorule/ensure-sudorule-is-present.yml 파일에서 예제를 복사하고 수정할 수 있습니다.

      ---
      - name: Tests
        hosts: ipaserver
      
        vars_files:
        - /home/user_name/MyPlaybooks/secret.yml
        tasks:
        # Ensure a sudorule is present granting idm_user the permission to run /usr/sbin/reboot on idmclient
        - ipasudorule:
            ipaadmin_password: "{{ ipaadmin_password }}"
            name: idm_user_reboot
            description: A test sudo rule.
            allow_sudocmd: /usr/sbin/reboot
            host: idmclient.idm.example.com
            user: idm_user
            state: present
    2. 플레이북을 실행합니다.

      $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-sudorule-for-idmuser-on-idmclient-is-present.yml

검증 단계

idm _usersudo 를 사용하여 idmclient 를 재부팅할 수 있는지 확인하여 IdM 서버에서 IdM 서버가 작동하는지 확인하는 sudo 규칙이 idmclient 에서 작동하는지 테스트합니다. 서버에서 변경한 사항이 클라이언트에 적용되는 데 몇 분이 걸릴 수 있습니다.

  1. idmclient에 idm _user 로 로그인합니다.
  2. sudo 를 사용하여 시스템을 재부팅합니다. 메시지가 표시되면 idm_user 의 암호를 입력합니다.

    $ sudo /usr/sbin/reboot
    [sudo] password for idm_user:

sudo 가 올바르게 구성되면 시스템이 재부팅됩니다.

추가 리소스

  • /usr/share/doc/ansible-freeipa/ 디렉터리에서README-sudocmdgroup.md, README-sudorule.md 파일을 참조하십시오.

9장. ldapmodify를 사용하여 IdM 사용자 외부 관리

IdM 관리자는 ipa 명령을 사용하여 디렉터리 콘텐츠를 관리할 수 있습니다. 또는 ldapmodify 명령을 사용하여 유사한 목표를 달성할 수 있습니다. 이 명령을 대화형으로 사용하고 명령줄에서 모든 데이터를 직접 제공할 수 있습니다. LDAP Data Interchange Format(LDIF)에서 ldapmodify 명령에 데이터를 제공할 수도 있습니다.

9.1. 외부에서 IdM 사용자 계정을 관리하는 템플릿

다음 템플릿은 IdM의 다양한 사용자 관리 작업에 사용할 수 있습니다. 템플릿은 다음 목표를 달성하기 위해 ldapmodify 를 사용하여 수정해야 하는 속성을 표시합니다.

  • 새 단계 사용자 추가
  • 사용자 속성 수정
  • 사용자 활성화
  • 사용자 비활성화
  • 사용자 보존

템플릿은 LDAP(LDIF)로 포맷됩니다. LDIF는 LDAP 디렉터리 콘텐츠를 표시하고 요청을 업데이트하기 위한 표준 일반 텍스트 데이터 교환 형식입니다.

템플릿을 사용하여 IdM 사용자 계정을 관리하도록 프로비저닝 시스템의 LDAP 프로바이더를 구성할 수 있습니다.

자세한 예제 절차는 다음 섹션을 참조하십시오.

새 스테이징 사용자를 추가하기 위한 템플릿

  • UID 및 GID가 자동으로 할당된 사용자를 추가하는 템플릿. 생성된 항목의 고유 이름(DN)은 uid=user_login 으로 시작해야 합니다.

    dn: uid=user_login,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
    changetype: add
    objectClass: top
    objectClass: inetorgperson
    uid: user_login
    sn: surname
    givenName: first_name
    cn: full_name
  • 정적으로 UID 및 GID가 할당된 사용자를 추가하는 템플릿 :

    dn: uid=user_login,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
    changetype: add
    objectClass: top
    objectClass: person
    objectClass: inetorgperson
    objectClass: organizationalperson
    objectClass: posixaccount
    uid: user_login
    uidNumber: UID_number
    gidNumber: GID_number
    sn: surname
    givenName: first_name
    cn: full_name
    homeDirectory: /home/user_login

    스테이징 사용자를 추가할 때 IdM 오브젝트 클래스를 지정할 필요는 없습니다. IdM은 사용자가 활성화된 후 이러한 클래스를 자동으로 추가합니다.

기존 사용자 수정을 위한 템플릿

  • 사용자의 속성 수정:

    dn: distinguished_name
    changetype: modify
    replace: attribute_to_modify
    attribute_to_modify: new_value
  • 사용자 비활성화:

    dn: distinguished_name
    changetype: modify
    replace: nsAccountLock
    nsAccountLock: TRUE
  • 사용자 활성화:

    dn: distinguished_name
    changetype: modify
    replace: nsAccountLock
    nsAccountLock: FALSE

    nssAccountLock 특성을 업데이트해도 단계 및 보존된 사용자에게는 영향을 미치지 않습니다. 업데이트 작업이 성공적으로 완료되었지만 속성 값은 nssAccountLock으로 유지됩니다. TRUE.

  • 사용자 보존:

    dn: distinguished_name
    changetype: modrdn
    newrdn: uid=user_login
    deleteoldrdn: 0
    newsuperior: cn=deleted users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
참고

사용자를 수정하기 전에 사용자의 로그인을 통해 검색하여 사용자의 고유 이름(DN)을 획득합니다. 다음 예에서 user_allowed_to_modify_user_entries 사용자는 활성화 기 또는 IdM 관리자와 같이 사용자 및 그룹 정보를 수정할 수 있는 사용자입니다. 예제의 암호는 이 사용자의 암호입니다.

[...]
# ldapsearch -LLL -x -D "uid=user_allowed_to_modify_user_entries,cn=users,cn=accounts,dc=idm,dc=example,dc=com" -w "Secret123" -H ldap://r8server.idm.example.com -b "cn=users,cn=accounts,dc=idm,dc=example,dc=com" uid=test_user
dn: uid=test_user,cn=users,cn=accounts,dc=idm,dc=example,dc=com
memberOf: cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=example,dc=com

9.2. 외부에서 IdM 그룹 계정을 관리하는 템플릿

다음 템플릿은 IdM의 다양한 사용자 그룹 관리 작업에 사용할 수 있습니다. 템플릿은 다음 목표를 달성하기 위해 ldapmodify 를 사용하여 수정해야 하는 속성을 표시합니다.

  • 새 그룹 생성
  • 기존 그룹 삭제
  • 그룹에 구성원 추가
  • 그룹에서 멤버 제거

템플릿은 LDAP(LDIF)로 포맷됩니다. LDIF는 LDAP 디렉터리 콘텐츠를 표시하고 요청을 업데이트하기 위한 표준 일반 텍스트 데이터 교환 형식입니다.

템플릿을 사용하여 IdM 그룹 계정을 관리하도록 프로비저닝 시스템의 LDAP 프로바이더를 구성할 수 있습니다.

새 그룹 생성

dn: cn=group_name,cn=groups,cn=accounts,dc=idm,dc=example,dc=com
changetype: add
objectClass: top
objectClass: ipaobject
objectClass: ipausergroup
objectClass: groupofnames
objectClass: nestedgroup
objectClass: posixgroup
uid: group_name
cn: group_name
gidNumber: GID_number

그룹 수정

  • 기존 그룹 삭제:

    dn: group_distinguished_name
    changetype: delete
  • 그룹에 멤버 추가:

    dn: group_distinguished_name
    changetype: modify
    add: member
    member: uid=user_login,cn=users,cn=accounts,dc=idm,dc=example,dc=com

    스테이징 또는 보존된 사용자를 그룹에 추가하지 마십시오. 업데이트 작업이 성공적으로 완료되었지만 사용자는 그룹의 구성원으로 업데이트되지 않습니다. 활성 사용자만 그룹에 속할 수 있습니다.

  • 그룹에서 멤버 제거:

    dn: distinguished_name
    changetype: modify
    delete: member
    member: uid=user_login,cn=users,cn=accounts,dc=idm,dc=example,dc=com
참고

그룹을 수정하기 전에 그룹 이름을 사용하여 검색하여 그룹의 고유 이름(DN)을 가져옵니다.

# ldapsearch -YGSSAPI -H ldap://server.idm.example.com -b "cn=groups,cn=accounts,dc=idm,dc=example,dc=com" "cn=group_name"
dn: cn=group_name,cn=groups,cn=accounts,dc=idm,dc=example,dc=com
ipaNTSecurityIdentifier: S-1-5-21-1650388524-2605035987-2578146103-11017
cn: testgroup
objectClass: top
objectClass: groupofnames
objectClass: nestedgroup
objectClass: ipausergroup
objectClass: ipaobject
objectClass: posixgroup
objectClass: ipantgroupattrs
ipaUniqueID: 569bf864-9d45-11ea-bea3-525400f6f085
gidNumber: 1997010017

9.3. ldapmodify 명령을 대화형으로 사용

대화형 모드에서 LDAP(Lightweight Directory Access Protocol) 항목을 수정할 수 있습니다.

절차

  1. 명령줄에서 LDAP Data Interchange Format(LDIF) 문을 ldapmodify 명령 뒤에 입력합니다.

    예 9.1. testuser의 전화 번호 변경

    # ldapmodify -Y GSSAPI -H ldap://server.example.com
    dn: uid=testuser,cn=users,cn=accounts,dc=example,dc=com
    changetype: modify
    replace: telephoneNumber
    telephonenumber: 88888888

    -Y 옵션을 사용하려면 Kerberos 티켓을 받아야 합니다.

  2. Ctlr+D 를 눌러 대화형 모드를 종료합니다.
  3. 또는 ldapmodify 명령 뒤에 LDIF 파일을 제공합니다.

    예 9.2. ldapmodify 명령은 LDIF 파일에서 수정 데이터를 읽습니다.

    # ldapmodify -Y GSSAPI -H ldap://server.example.com -f ~/example.ldif

추가 리소스

  • ldapmodify 명령을 사용하는 방법에 대한 자세한 내용은 ldapmodify(1) 매뉴얼 페이지를 참조하십시오.
  • LDIF 구조에 대한 자세한 내용은 ldif(5) 도움말 페이지를 참조하십시오.

9.4. ldapmodify를 사용하여 IdM 사용자 보존

ldapmodify 를 사용하여 IdM 사용자를 보존하려면 다음 절차를 따르십시오. 즉, 직원이 퇴사한 후 사용자 계정을 비활성화하는 방법을 따르십시오.

사전 요구 사항

  • 사용자를 보존하기 위해 역할로 IdM 사용자로 인증할 수 있습니다.

절차

  1. 사용자를 보존하려면 역할을 가진 IdM 사용자로 로그인합니다.

    $ kinit admin
  2. ldapmodify 명령을 입력하고 인증에 사용할 SASL(Simple Authentication and Security Layer) 메커니즘으로 GSSAPI(Generic Security Services API)를 지정합니다.

    # ldapmodify -Y GSSAPI
    SASL/GSSAPI authentication started
    SASL username: admin@IDM.EXAMPLE.COM
    SASL SSF: 256
    SASL data security layer installed.
  3. 보존할 사용자의 dn 을 입력합니다.

    dn: uid=user1,cn=users,cn=accounts,dc=idm,dc=example,dc=com
  4. 수행할 변경 유형으로 modrdn 을 입력합니다.

    changetype: modrdn
  5. 사용자에 대한 newrdn 을 지정합니다.

    newrdn: uid=user1
  6. 사용자를 보존할 것을 나타냅니다.

    deleteoldrdn: 0
  7. 새로운 우수 DN 을 지정합니다.

    newsuperior: cn=deleted users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com

    사용자를 보존하면 DIT(디렉토리 정보 트리)의 새 위치로 항목을 이동합니다. 따라서 새 상위 항목의 DN을 새 우수한 DN으로 지정해야 합니다.

  8. Enter 를 다시 눌러 이것이 항목의 끝인지 확인합니다.

    [Enter]
    
    modifying rdn of entry "uid=user1,cn=users,cn=accounts,dc=idm,dc=example,dc=com"
  9. Ctrl + C 사용하여 연결을 종료합니다.

검증 단계

  • 보존된 모든 사용자를 나열하여 사용자가 보존되었는지 확인합니다.

    $ ipa user-find --preserved=true
    --------------
    1 user matched
    --------------
      User login: user1
      First name: First 1
      Last name: Last 1
      Home directory: /home/user1
      Login shell: /bin/sh
      Principal name: user1@IDM.EXAMPLE.COM
      Principal alias: user1@IDM.EXAMPLE.COM
      Email address: user1@idm.example.com
      UID: 1997010003
      GID: 1997010003
      Account disabled: True
      Preserved user: True
    ----------------------------
    Number of entries returned 1
    ----------------------------

10장. ldapsearch 명령을 사용하여 IdM 항목 검색

ipa find 명령을 사용하여 Identity Management 항목을 검색할 수 있습니다. ipa 명령에 대한 자세한 내용은 IPA 명령 섹션 을 참조하십시오.

이 섹션에서는 ID 관리 항목을 통해 ldapsearch 명령줄 명령을 사용하여 대체 검색 옵션의 기본 사항을 소개합니다.

10.1. ldapsearch 명령 사용

ldapsearch 명령에는 다음 형식이 있습니다.

# ldapsearch [-x | -Y mechanism] [options] [search_filter] [list_of_attributes]
  • 인증 방법을 구성하려면 간단한 바인딩 또는 -Y 옵션을 사용하여 Simple Authentication and Security Layer(ECDHEL) 메커니즘을 설정하는 -x 옵션을 지정합니다. -Y GSSAPI 옵션을 사용하는 경우 Kerberos 티켓을 받아야 합니다.
  • 옵션은 아래 표에 설명된 ldapsearch 명령 옵션입니다.
  • search_filter 는 LDAP 검색 필터입니다.
  • list_of_attributes 는 검색 결과가 반환하는 속성 목록입니다.

예를 들어 사용자 이름 user01 에 대해 기본 LDAP 트리의 모든 항목을 검색하려고 합니다.

# ldapsearch -x -H ldap://ldap.example.com -s sub "(uid=user01)"
  • -x 옵션은 간단한 바인딩으로 인증하도록 ldapsearch 명령을 지시합니다. -D 옵션과 함께 Distinguish Name (DN)을 제공하지 않으면 인증은 익명입니다.
  • -H 옵션은 ldap://ldap.example.com 에 연결합니다.
  • s 하위 옵션은 ldapsearch 명령에 기본 DN부터 이름이 user01 인 사용자의 모든 항목을 검색하도록 지시합니다. "(uid=user01)" 는 필터입니다.

-b 옵션을 사용하여 검색 시작점을 제공하지 않으면 명령은 기본 트리에서 검색합니다. etc/openldap/ldap.conf 파일의 BASE 매개변수에 지정됩니다.

표 10.1. ldapsearch 명령 옵션

옵션설명

-b

검색을 위한 시작점입니다. 검색 매개변수에 별표(*) 또는 기타 문자가 포함된 경우 명령줄이 코드로 해석할 수 있는 경우 값을 단일 또는 이중 따옴표로 래핑해야 합니다. 예: -b cn=user,ou=Product Development,dc=example,dc=com.

-D

인증하려는 Distinguished Name(DN)입니다.

-H

서버에 연결할 LDAP URL입니다. -H 옵션은 -h-p 옵션을 대체합니다.

-l

검색 요청이 완료될 때까지 대기하는 시간 제한(초)입니다.

-s 범위

검색 범위입니다. 범위에 대해 다음 중 하나를 선택할 수 있습니다.

  • base-b 옵션에서 항목만 검색하거나 LDAP_BASEDN 환경 변수로 정의합니다.
  • 하나는 -b 옵션에서 항목의 하위 항목만 검색합니다.
  • -b 옵션 시작점에서 하위 트리를 검색합니다.

-W

암호 요청입니다.

-x

간단한 바인딩을 허용하도록 기본 SASL 연결을 비활성화합니다.

-Y SASL_mechanism

인증에 대한 SASL 메커니즘을 설정합니다.

-z number

검색 결과에서 최대 항목 수입니다.

참고: ldapsearch 명령을 사용하여 -x 또는 -Y 옵션을 사용하여 인증 메커니즘 중 하나를 지정해야 합니다.

추가 리소스

  • ldapsearch 사용 방법에 대한 자세한 내용은 ldapsearch(1) 매뉴얼 페이지를 참조하십시오.

10.2. ldapsearch 필터 사용

ldapsearch 필터를 사용하면 검색 결과를 축소할 수 있습니다.

예를 들어 검색 결과에 공통 이름이 example으로 설정된 모든 항목이 포함되도록 합니다.For example, you want the search result to contain all the entries with a common names set to example:

"(cn=example)"

이 경우 등호(=) 는 연산자이고 example 은 값입니다.

표 10.2. ldapsearch 필터 연산자

검색 유형Operator설명

Equal

=

값과 정확히 일치하는 항목을 반환합니다. 예: cn=example.

하위 문자열

=string* 문자열

하위 문자열이 일치하는 항목을 모두 반환합니다. 예를 들면 cn=exa*l 입니다. 별표*는 0개 이상의 문자를 나타냅니다.

크거나 같음

>=

값보다 크거나 같은 특성을 사용하여 모든 항목을 반환합니다. 예를 들면 uidNumber >= 5000 입니다.

작거나 같음

<=

값보다 작거나 같은 특성을 사용하여 모든 항목을 반환합니다. 예를 들면 uidNumber <= 5000.

presence

=*

하나 이상의 특성을 사용하여 모든 항목을 반환합니다. 예: cn=*.

대략

~=

value 속성과 유사한 모든 항목을 반환합니다. 예를 들어 l~=san fransicol=san francisco 를 반환할 수 있습니다.

부울 연산자를 사용하여 여러 필터를 ldapsearch 명령에 결합할 수 있습니다.

표 10.3. ldapsearch 필터 부울 연산자

검색 유형Operator설명

&

필터의 모든 구문이 true인 항목을 반환합니다. 예: (&(filter)(filter)(filter)…​).

또는

|

필터에서 하나 이상의 문이 true인 모든 항목을 반환합니다. 예: (|(filter)(filter)(filter)…​).

제공되지 않음

!

필터의 구문이 true가 아닌 모든 항목을 반환합니다. 예를 들면 (!(filter)) 입니다.

11장. 사용자의 외부 프로비저닝을 위한 IdM 구성

시스템 관리자는 ID 관리를 위해 외부 솔루션에서 사용자의 프로비저닝을 지원하도록 IdM(Identity Management)을 구성할 수 있습니다.

ipa 유틸리티를 사용하는 대신 외부 프로비저닝 시스템 관리자는 ldapmodify 유틸리티를 사용하여 IdM LDAP에 액세스할 수 있습니다. 관리자는 ldapmodify 또는 LDIF 파일을 사용하여 CLI에서 개별 단계 사용자를 추가할 수 있습니다.

IdM 관리자는 검증된 사용자만 추가하도록 외부 프로비저닝 시스템을 완전히 신뢰한다고 가정합니다. 그러나 동시에 외부 프로비저닝 시스템의 관리자에게 사용자 관리자의 IdM 역할을 할당하여 새 활성 사용자를 직접 추가할 수 없습니다.

외부 프로비저닝 시스템에서 생성한 스테이징된 사용자를 활성 사용자로 자동으로 이동하도록 스크립트를 구성할 수 있습니다.

이 장에는 다음 섹션이 포함되어 있습니다.

  1. 외부 프로비저닝 시스템을 사용하여 IdM(Identity Management) 을 준비하여 IdM에 단계 사용자를 추가합니다.
  2. 외부 프로비저닝 시스템에서 추가한 사용자를 스테이지에서 활성 사용자로 이동하는 스크립트를 생성합니다.
  3. 외부 프로비저닝 시스템을 사용하여 IdM 단계 사용자 추가. 다음 두 가지 방법으로 이를 수행할 수 있습니다.

11.1. 단계 사용자 계정의 자동 활성화를 위한 IdM 계정 준비

다음 절차에서는 외부 프로비저닝 시스템에서 사용할 두 개의 IdM 사용자 계정을 구성하는 방법을 설명합니다. 적절한 암호 정책이 있는 그룹에 계정을 추가하면 외부 프로비저닝 시스템에서 IdM의 사용자 프로비저닝을 관리할 수 있습니다. 다음에서는 외부 시스템에서 단계 사용자를 추가하는 데 사용하는 사용자 계정은 provisionator 라고 합니다. 스테이징 사용자를 자동으로 활성화하는 데 사용할 사용자 계정은 활성화 기라고 합니다.

사전 요구 사항

  • 절차를 수행하는 호스트는 IdM에 등록됩니다.

절차

  1. IdM 관리자로 로그인합니다.

    $ kinit admin
  2. 스테이징 사용자를 추가할 권한이 있는 provisionator 라는 사용자를 만듭니다.

    1. provisionator 사용자 계정을 추가합니다.
    $ ipa user-add provisionator --first=provisioning --last=account --password
    1. 프로비저너 사용자에게 필요한 권한을 부여합니다.

      1. 사용자 지정 역할인 System Provisioning 을 생성하여 스테이징 사용자 추가를 관리합니다.

        $ ipa role-add --desc "Responsible for provisioning stage users" "System Provisioning"
      2. 역할에 Stage User Provisioning(사용자 프로비저닝 단계) 권한을 추가합니다. 이 권한은 스테이징 사용자를 추가할 수 있는 기능을 제공합니다.

        $ ipa role-add-privilege "System Provisioning" --privileges="Stage User Provisioning"
      3. provisionator 사용자를 역할에 추가합니다.

        $ ipa role-add-member --users=provisionator "System Provisioning"
      4. 프로비저너가 IdM에 있는지 확인합니다.
      $ ipa user-find provisionator --all --raw
      --------------
      1 user matched
      --------------
        dn: uid=provisionator,cn=users,cn=accounts,dc=idm,dc=example,dc=com
        uid: provisionator
        [...]
  3. 사용자 계정을 관리할 수 있는 권한을 가진 사용자 활성화 기를 만듭니다.

    1. 활성화기 사용자 계정을 추가합니다.

      $ ipa user-add activator --first=activation --last=account --password
    2. 사용자를 기본 User Administrator 역할에 추가하여 필요한 권한을 활성화 사용자에게 부여합니다.

      $ ipa role-add-member --users=activator "User Administrator"
  4. 애플리케이션 계정의 사용자 그룹을 생성합니다.

    $ ipa group-add application-accounts
  5. 그룹의 암호 정책을 업데이트합니다. 다음 정책은 계정의 암호 만료 및 잠금을 방지하지만 복잡한 암호를 요구하여 잠재적인 위험을 보상합니다.

    $ ipa pwpolicy-add application-accounts --maxlife=10000 --minlife=0 --history=0 --minclasses=4 --minlength=8 --priority=1 --maxfail=0 --failinterval=1 --lockouttime=0
  6. (선택 사항) 암호 정책이 IdM에 있는지 확인합니다.

    $ ipa pwpolicy-show application-accounts
      Group: application-accounts
      Max lifetime (days): 10000
      Min lifetime (hours): 0
      History size: 0
    [...]
  7. 애플리케이션 계정의 그룹에 프로비저닝 및 활성화 계정을 추가합니다.

    $ ipa group-add-member application-accounts --users={provisionator,activator}
  8. 사용자 계정의 암호를 변경합니다.

    $ kpasswd provisionator
    $ kpasswd activator

    새 IdM 사용자 암호가 즉시 만료되기 때문에 암호를 변경해야 합니다.

추가 리소스:

11.2. IdM 스테이징 사용자 계정의 자동 활성화 구성

다음 절차에서는 스테이징 사용자를 활성화하는 스크립트를 생성하는 방법을 설명합니다. 시스템은 지정된 시간 간격에 따라 자동으로 스크립트를 실행합니다. 이렇게 하면 새 사용자 계정이 자동으로 활성화되고 생성된 직후 사용할 수 있습니다.

중요

이 절차에서는 외부 프로비저닝 시스템의 소유자가 이미 사용자를 검증했으며 스크립트에서 IdM에 추가 검증이 필요하지 않다고 가정합니다.

IdM 서버 중 하나에서만 활성화 프로세스를 활성화할 수 있습니다.

사전 요구 사항

절차

  1. 활성화 계정에 대한 keytab 파일을 생성합니다.

    # ipa-getkeytab -s server.idm.example.com -p "activator" -k /etc/krb5.ipa-activation.keytab

    둘 이상의 IdM 서버에서 활성화 프로세스를 활성화하려면 하나의 서버에만 keytab 파일을 생성합니다. 그런 다음 키탭 파일을 다른 서버에 복사합니다.

  2. 다음 내용으로 /usr/local/sbin/ipa-activate-all 스크립트를 생성하여 모든 사용자를 활성화합니다.

    #!/bin/bash
    
    kinit -k -i activator
    
    ipa stageuser-find --all --raw | grep "  uid:" | cut -d ":" -f 2 | while read uid; do ipa stageuser-activate ${uid}; done
  3. ipa-activate-all 스크립트의 권한 및 소유권을 편집하여 실행 가능하게 만듭니다.

    # chmod 755 /usr/local/sbin/ipa-activate-all
    # chown root:root /usr/local/sbin/ipa-activate-all
  4. 다음 콘텐츠를 사용하여 systemd 장치 파일 /etc/systemd/system/ipa-activate-all.service 를 만듭니다.

    [Unit]
    Description=Scan IdM every minute for any stage users that must be activated
    
    [Service]
    Environment=KRB5_CLIENT_KTNAME=/etc/krb5.ipa-activation.keytab
    Environment=KRB5CCNAME=FILE:/tmp/krb5cc_ipa-activate-all
    ExecStart=/usr/local/sbin/ipa-activate-all
  5. 다음 내용을 사용하여 systemd 타이머 /etc/systemd/system/ipa-activate-all.timer 을 만듭니다.

    [Unit]
    Description=Scan IdM every minute for any stage users that must be activated
    
    [Timer]
    OnBootSec=15min
    OnUnitActiveSec=1min
    
    [Install]
    WantedBy=multi-user.target
  6. 새 구성을 다시 로드합니다.

    # systemctl daemon-reload
  7. ipa-activate-all.timer:

    # systemctl enable ipa-activate-all.timer
  8. ipa-activate-all.timer 시작 :

    # systemctl start ipa-activate-all.timer
  9. (선택 사항) ipa-activate-all.timer 데몬이 실행 중인지 확인합니다.

    # systemctl status ipa-activate-all.timer
    ● ipa-activate-all.timer - Scan IdM every minute for any stage users that must be activated
       Loaded: loaded (/etc/systemd/system/ipa-activate-all.timer; enabled; vendor preset: disabled)
       Active: active (waiting) since Wed 2020-06-10 16:34:55 CEST; 15s ago
      Trigger: Wed 2020-06-10 16:35:55 CEST; 44s left
    
    Jun 10 16:34:55 server.idm.example.com systemd[1]: Started Scan IdM every minute for any stage users that must be activated.

11.3. LDIF 파일에 정의된 IdM 단계 사용자 추가

IdM LDAP에 액세스하고 LDIF 파일을 사용하여 스테이징 사용자를 추가하려면 다음 절차를 따르십시오. 아래 예제에서는 단일 사용자를 추가하는 방법을 보여주지만, 일괄 모드로 하나의 파일에 여러 사용자를 추가할 수 있습니다.

사전 요구 사항

  • IdM 관리자가 프로비저너 계정 과 암호를 생성했습니다. 자세한 내용은 단계 사용자 계정 자동 활성화를 위한 IdM 계정 준비를 참조하십시오.
  • 외부 관리자가 프로비저너 계정의 암호를 알고 있습니다.
  • LDAP 서버에서 IdM 서버에 SSH로 연결할 수 있습니다.
  • IdM 단계 사용자가 사용자 라이프사이클의 올바른 처리를 허용해야 하는 최소한의 속성 세트를 제공할 수 있습니다.

    • 고유 이름 (dn)
    • 일반 이름 (cn)
    • (sn)
    • uid

절차

  1. 외부 서버에서 새 사용자에 대한 정보가 포함된 LDIF 파일을 생성합니다.

    dn: uid=stageidmuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
    changetype: add
    objectClass: top
    objectClass: inetorgperson
    uid: stageidmuser
    sn: surname
    givenName: first_name
    cn: full_name
  2. LDIF 파일을 외부 서버에서 IdM 서버로 전송합니다.

    $ scp add-stageidmuser.ldif provisionator@server.idm.example.com:/provisionator/
    Password:
    add-stageidmuser.ldif                                                                                          100%  364   217.6KB/s   00:00
  3. SSH 프로토콜을 사용하여 IdM 서버에 프로비저너로 연결합니다.

    $ ssh provisionator@server.idm.example.com
    Password:
    [provisionator@server ~]$
  4. IdM 서버에서 프로비저너 계정의 Kerberos 티켓을 받습니다.

    [provisionator@server ~]$ kinit provisionator
  5. f 옵션과 LDIF 파일의 이름을 사용하여 ldapadd 명령을 입력합니다. IdM 서버의 이름과 포트 번호를 지정합니다.

    ~]$ ldapadd -h server.idm.example.com -p 389 -f  add-stageidmuser.ldif
    SASL/GSSAPI authentication started
    SASL username: provisionator@IDM.EXAMPLE.COM
    SASL SSF: 256
    SASL data security layer installed.
    adding the entry "uid=stageidmuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com"

11.4. ldapmodify를 사용하여 CLI에서 직접 IdM 단계 사용자 추가

다음 절차에 따라 IdM(Identity Management) LDAP에 액세스하고 ldapmodify 유틸리티를 사용하여 스테이징 사용자를 추가합니다.

사전 요구 사항

  • IdM 관리자가 프로비저너 계정 과 암호를 생성했습니다. 자세한 내용은 단계 사용자 계정 자동 활성화를 위한 IdM 계정 준비를 참조하십시오.
  • 외부 관리자가 프로비저너 계정의 암호를 알고 있습니다.
  • LDAP 서버에서 IdM 서버에 SSH로 연결할 수 있습니다.
  • IdM 단계 사용자가 사용자 라이프사이클의 올바른 처리를 허용해야 하는 최소한의 속성 세트를 제공할 수 있습니다.

    • 고유 이름 (dn)
    • 일반 이름 (cn)
    • (sn)
    • uid

절차

  1. IdM ID 및 자격 증명을 사용하여 SSH 프로토콜을 사용하여 IdM 서버에 연결합니다.

    $ ssh provisionator@server.idm.example.com
    Password:
    [provisionator@server ~]$
  2. 새 단계 사용자를 추가하는 역할의 IdM 사용자인 프로비저너 계정의 TGT를 가져옵니다.

    $ kinit provisionator
  3. ldapmodify 명령을 입력하고 인증에 사용할 SASL(Simple Authentication and Security Layer) 메커니즘으로 GSSAPI(Generic Security Services API)를 지정합니다. IdM 서버 이름 및 포트를 지정합니다.

    # ldapmodify -h server.idm.example.com -p 389 -Y GSSAPI
    SASL/GSSAPI authentication started
    SASL username: provisionator@IDM.EXAMPLE.COM
    SASL SSF: 56
    SASL data security layer installed.
  4. 추가하려는 사용자의 dn 을 입력합니다.

    dn: uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
  5. 수행 중인 변경 유형으로 add 를 입력합니다.

    changetype: add
  6. 사용자 라이프 사이클의 올바른 처리를 허용하는 데 필요한 LDAP 오브젝트 클래스 범주를 지정합니다.

    objectClass: top
    objectClass: inetorgperson

    추가 오브젝트 클래스를 지정할 수 있습니다.

  7. 사용자의 uid 를 입력합니다.

    uid: stageuser
  8. 사용자의 cn 을 입력합니다.

    cn: Babs Jensen
  9. 사용자의 성을 입력합니다.

    sn: Jensen
  10. Enter 를 다시 눌러 이것이 항목의 끝인지 확인합니다.

    [Enter]
    
    adding new entry "uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com"
  11. Ctrl + C 사용하여 연결을 종료합니다.

검증 단계

stage 항목의 콘텐츠를 확인하여 프로비저닝 시스템에서 필요한 모든 POSIX 특성을 추가하고 stage 항목을 활성화할 준비가 되었는지 확인합니다.

  • 새 stage 사용자의 LDAP 속성을 표시하려면 ipa stageuser-show --all --raw 명령을 입력합니다.

    $ ipa stageuser-show stageuser --all --raw
      dn: uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
      uid: stageuser
      sn: Jensen
      cn: Babs Jensen
      has_password: FALSE
      has_keytab: FALSE
      nsaccountlock: TRUE
      objectClass: top
      objectClass: inetorgperson
      objectClass: organizationalPerson
      objectClass: person
    1. 사용자는 nsaccountlock 특성에 의해 명시적으로 비활성화됩니다.

11.5. 추가 리소스

12장. PAC 정보를 사용하여 Kerberos 보안 강화

RHEL 8.5 이후 기본적으로 PAC(권한 속성 인증서) 정보와 함께 IdM(Identity Management)을 사용할 수 있습니다. 또한 RHEL 8.5 이전에 설치된 IdM 배포에서 SID(Security Identifiers)를 활성화할 수 있습니다.

12.1. IdM에서 권한 속성 인증서(PAC) 사용

RHEL IdM(Identity Management)은 이제 새로운 배포에서 기본적으로 Privilege Attribute Certificate (PAC) 정보를 사용하여 Kerberos 티켓을 발행합니다. PAC에는 SID(Security Identifier), 그룹 멤버십 및 홈 디렉토리 정보를 포함하여 Kerberos 주체에 대한 풍부한 정보가 있습니다.

기본적으로 Microsoft Active Directory(AD)가 사용하는 STSS는 전역적으로 고유한 식별자로 재사용되지 않습니다. STSS는 여러 네임스페이스를 표현합니다. 각 도메인에는 각 오브젝트의 STS에 접두사가 있는 STS가 있습니다.

RHEL 8.5부터 IdM 서버 또는 복제본을 설치할 때 설치 스크립트는 기본적으로 사용자 및 그룹에 대한 STS를 생성합니다. 이를 통해 IdM은 PAC 데이터로 작업할 수 있습니다. RHEL 8.5 이전의 IdM을 설치하고 AD 도메인에 대한 트러스트를 구성하지 않은 경우 IdM 오브젝트에 대해 STS를 생성하지 못할 수 있습니다. IdM 오브젝트의 STS를 생성하는 방법에 대한 자세한 내용은 IdM 의 SID(보안 식별자) 활성화를 참조하십시오.

Kerberos 티켓에서 PAC 정보를 평가하면 훨씬 더 자세히 리소스 액세스를 제어할 수 있습니다. 예를 들어, 한 도메인의 Administrator 계정은 다른 도메인의 Administrator 계정과 고유한 SID를 갖습니다. AD 도메인에 대한 신뢰가 있는 IdM 환경에서는 UID가 0인 모든 Linux 루트 계정과 같이 다른 위치에서 반복할 수 있는 간단한 사용자 이름 또는 UID 대신, 전역적으로 고유한 SID를 기반으로 액세스 제어를 설정할 수 있습니다.

12.2. IdM에서 SID(Security Identifiers) 활성화

RHEL 8.5 이전의 IdM을 설치하고 AD 도메인에 대한 트러스트를 구성하지 않은 경우 IdM 오브젝트에 대해 SID(Security Identifiers)가 생성되지 않을 수 있습니다. 이전에는 SIDs를 생성하는 유일한 방법은 ipa-adtrust-install 명령을 실행하여 IdM 서버에 Trust Controller 역할을 추가하기 때문입니다.

RHEL 8.6부터 IdM의 Kerberos에는 IdM 오브젝트에PAC(Privilege Access Certificate) 정보를 기반으로 보안에 필요한 STS가 있어야 합니다.

사전 요구 사항

  • RHEL 8.5 이전에 IdM을 설치했습니다.
  • Active Directory 도메인을 사용한 신뢰 구성의 일부인 ipa-sidgen 작업을 실행하지 않았습니다.
  • IdM 관리자 계정으로 인증할 수 있습니다.

절차

  • STS를 사용하고 HEAD gen 작업을 트리거하여 기존 사용자 및 그룹에 대한 SID를 생성합니다. 이 작업은 리소스 집약적일 수 있습니다.

    [root@server ~]# ipa config-mod --enable-sid --add-sids

검증

  • IdM admin 사용자 계정 항목에 도메인 관리자용으로 예약된 -500 로 끝나는 libc가 있는 ipantsecurity tekton 속성이 있는지 확인합니다.

    [root@server ~]# ipa user-show admin --all | grep ipantsecurityidentifier
      ipantsecurityidentifier: S-1-5-21-2633809701-976279387-419745629-500

13장. Kerberos 티켓 정책 관리

IdM(Identity Management)의 Kerberos 티켓 정책은 Kerberos 티켓 액세스, 기간 및 갱신에 대한 제한을 설정합니다. IdM 서버에서 실행되는 KDC(Key Distribution Center)에 대한 Kerberos 티켓 정책을 구성할 수 있습니다.

Kerberos 티켓 정책을 관리할 때 다음 개념과 작업이 수행됩니다.

13.1. IdM NetNamespace의 역할

Identity Management의 인증 메커니즘은 KDC(Key Distribution Center)가 설정한 Kerberos 인프라를 사용합니다. NetNamespace는 인증 정보 정보를 저장하고 IdM 네트워크 내의 엔티티에서 시작된 데이터의 신뢰성을 보장하는 신뢰할 수 있는 기관입니다.

각 IdM 사용자, 서비스 및 호스트는 Kerberos 클라이언트 역할을 하며 고유한 Kerberos 주체 로 식별됩니다.

  • 사용자의 경우: 식별자@REALM (예: admin@EXAMPLE.COM)
  • 서비스의 경우: service/fully-qualified-hostname@REALM (예: http/server.example.com@EXAMPLE.COM)
  • 호스트의 경우: host/fully-qualified-hostname@REALM (예: host/client.example.com@EXAMPLE.COM)

다음 이미지는 Kerberos 클라이언트, NetNamespace 및 클라이언트가 통신하려는 Kerberized 애플리케이션 간의 통신을 간소화한 것입니다.

Kerberos NetNamespace 흐름의 통신
  1. Kerberos 클라이언트는 Kerberos 보안 주체로 인증하여 NetNamespace에 자신을 식별합니다. 예를 들어 IdM 사용자는 kinit 사용자 이름을 수행하고 암호를 제공합니다.
  2. NetNamespace는 데이터베이스의 주체를 확인하고, 클라이언트를 인증하고, Kerberos 티켓 정책을 평가하여 요청을 부여할지 여부를 결정합니다.
  3. NetNamespace는 클라이언트에 적절한 티켓 정책에 따른 라이프사이클 및 인증 지표로 TGT(티켓 분석 티켓)를 발행합니다.
  4. TGT를 사용하면 클라이언트는 NetNamespace에서 서비스 티켓을 요청하여 대상 호스트의 Kerberized 서비스와 통신합니다.
  5. NetNamespace는 클라이언트의 TGT가 여전히 유효한지 확인하고 티켓 정책에 대해 서비스 티켓 요청을 평가합니다.
  6. NetNamespace는 클라이언트에 서비스 티켓을 발행합니다.
  7. 서비스 티켓으로 클라이언트는 대상 호스트에서 서비스와 암호화된 통신을 시작할 수 있습니다.

13.2. IdM Kerberos 티켓 정책 유형

IdM Kerberos 티켓 정책은 다음 티켓 정책 유형을 구현합니다.

연결 정책

다양한 수준의 보안으로 Kerberized 서비스를 보호하기 위해 연결 정책을 정의하여 클라이언트가 티켓 통합 티켓(TGT)을 검색하는 데 사용되는 사전 인증 메커니즘에 따라 규칙을 적용할 수 있습니다.

예를 들어 client1.example.com 에 연결하기 위해 스마트 카드 인증이 필요할 수 있으며, client2.example.com 에서 testservice 애플리케이션에 액세스하려면 이중 인증이 필요할 수 있습니다.

연결 정책을 적용하려면 인증 지표를 서비스와 연결합니다. 서비스 티켓 요청에 필요한 인증 지표가 있는 클라이언트만 해당 서비스에 액세스할 수 있습니다. 자세한 내용은 Kerberos 인증 표시기 를 참조하십시오.

티켓 라이프사이클 정책

각 Kerberos 티켓에는 라이프사이클이 있고 잠재적인 갱신 기간이 있습니다. : 최대 수명에 도달하기 전에 티켓을 갱신할 수 있지만 최대 갱신 기간을 초과한 후에는 티켓이 갱신할 수 없습니다.

기본 글로벌 티켓 수명은 1일(86400초)이며 기본 글로벌 갱신 기간은 1주(604800초)입니다. 이러한 글로벌 값을 조정하려면 글로벌 티켓 라이프사이클 정책 구성을 참조하십시오.

자체 티켓 수명 주기 정책을 정의할 수도 있습니다.

  • 각 인증 표시기에 대해 서로 다른 글로벌 티켓 라이프사이클 값을 구성하려면 인증 지표 당 글로벌 티켓 정책 구성을 참조하십시오.
  • 사용된 인증 방법에 관계없이 단일 사용자의 티켓 라이프사이클 값을 정의하려면 사용자의 기본 티켓 정책 구성을 참조하십시오.
  • 단일 사용자에게만 적용되는 각 인증 표시기의 개별 티켓 라이프사이클 값을 정의하려면 사용자의 개별 인증 지표 티켓 정책 구성을 참조하십시오.

13.3. Kerberos 인증 지표

Kerberos Key Distribution Center(KDC)는 클라이언트가 ID를 증명하는 데 사용되는 사전 인증 메커니즘에 따라 인증 지표를 TGT( ticket-granting ticket)에 연결합니다.

otp
이중 인증 (암호 + 일회성 암호)
반경
RADIUS 인증 (일반적으로 802.1x 인증용)
pkinit
PKINIT, 스마트 카드 또는 인증서 인증
강화된
강화된 암호(SPAKE 또는 FAST)[1]

그런 다음 NetNamespace는 TGT의 인증 지표를 TGT의 모든 서비스 티켓 요청에 연결합니다. NetNamespace는 인증 지표에 따라 서비스 액세스 제어, 최대 티켓 수명 및 갱신 가능한 최대 기간과 같은 정책을 적용합니다.

인증 지표 및 IdM 서비스

서비스 또는 호스트를 인증 표시기와 연결하면 해당 인증 메커니즘을 사용한 클라이언트만 TGT에 액세스할 수 있습니다. 애플리케이션 또는 서비스가 아닌 NetNamespace는 서비스 티켓 요청의 인증 지표를 확인하고, Kerberos 연결 정책을 기반으로 요청을 허용하거나 거부합니다.

예를 들어, VPN(Virtual Private Network)에 연결하는 데 2단계 인증이 필요한 경우 otp 인증 표시기를 해당 서비스와 연결합니다. 고유한 TGT를 받기 위해 일회성 암호를 사용한 사용자만 VPN에 로그인할 수 있습니다.

그림 13.1. otp 인증 표시기가 필요한 VPN 서비스의 예

인증 지표

서비스 또는 호스트에 인증 지표가 할당되지 않은 경우 모든 메커니즘에서 인증된 티켓을 수락합니다.



[1] 강화된 암호는FAST(Secure robusting)를 통해 SPAKE(Single-party Public-Key Authenticated Key Exchange) 사전 인증 및/또는 flexible 인증을 사용하여 brute-force 암호 사전 검사 공격을 보호합니다.

13.4. IdM 서비스의 인증 지표 시행

IdM(Identity Management)에서 지원하는 인증 메커니즘은 인증력에 따라 다릅니다. 예를 들어 표준 암호와 함께 일회용 암호(TGT)를 사용하여 초기 Kerberos 티켓 통합 티켓(TGT)을 가져오는 것은 표준 암호만 사용하는 인증보다 더 안전합니다.

인증 지표를 특정 IdM 서비스와 연결하면 IdM 관리자로서 특정 사전 인증 메커니즘을 사용하여 TGT(TGT)를 사용한 사용자만 서비스에 액세스할 수 있도록 서비스를 구성할 수 있습니다.

이렇게 하면 다음과 같이 다양한 IdM 서비스를 구성할 수 있습니다.

  • OTP(one-time password)와 같은 초기 TGT를 얻기 위해 강력한 인증 방법을 사용한 사용자만 VPN과 같은 보안에 중요한 서비스에 액세스할 수 있습니다.
  • 더 간단한 인증 방법을 사용하여 암호와 같은 초기 TGT를 가져오는 사용자는 로컬 로그인과 같은 중요하지 않은 서비스에만 액세스할 수 있습니다.

그림 13.2. 다른 기술을 사용하여 인증의 예

인증 지표

이 절차에서는 IdM 서비스를 생성하고 들어오는 서비스 티켓 요청에서 특정 Kerberos 인증 지표가 필요하도록 구성하는 방법을 설명합니다.

13.4.1. IdM 서비스 항목 및 Kerberos 키탭 생성

IdM 호스트에서 실행 중인 서비스에 IdM 서비스 항목을 추가하면 해당 Kerberos 주체가 생성되고 서비스에서 SSL 인증서, Kerberos 키탭 또는 둘 다를 요청할 수 있습니다.

다음 절차에서는 IdM 서비스 항목을 생성하고 해당 서비스와의 통신을 암호화하기 위해 관련 Kerberos 키탭을 생성하는 방법을 설명합니다.

사전 요구 사항

  • 서비스는 Kerberos 보안 주체, SSL 인증서 또는 둘 다를 저장할 수 있습니다.

절차

  1. ipa service-add 명령과 함께 IdM 서비스를 추가하여 연결된 Kerberos 주체를 생성합니다. 예를 들어 호스트 client.example.com 에서 실행되는 testservice 애플리케이션에 대한 IdM 서비스 항목을 생성하려면 다음을 수행합니다.

    [root@client ~]# ipa service-add testservice/client.example.com
    -------------------------------------------------------------
    Modified service "testservice/client.example.com@EXAMPLE.COM"
    -------------------------------------------------------------
      Principal name: testservice/client.example.com@EXAMPLE.COM
      Principal alias: testservice/client.example.com@EXAMPLE.COM
      Managed by: client.example.com
  2. 클라이언트에 서비스에 대한 Kerberos 키탭을 생성하고 저장합니다.

    [root@client ~]# ipa-getkeytab -k /etc/testservice.keytab -p testservice/client.example.com
    Keytab successfully retrieved and stored in: /etc/testservice.keytab

검증 단계

  1. ipa service-show 명령을 사용하여 IdM 서비스에 대한 정보를 표시합니다.

    [root@server ~]# ipa service-show testservice/client.example.com
      Principal name: testservice/client.example.com@EXAMPLE.COM
      Principal alias: testservice/client.example.com@EXAMPLE.COM
      Keytab: True
      Managed by: client.example.com
  2. klist 명령을 사용하여 서비스의 Kerberos keytab 콘텐츠를 표시합니다.

    [root@server etc]# klist -ekt /etc/testservice.keytab
    Keytab name: FILE:/etc/testservice.keytab
    KVNO Timestamp           Principal
    ---- ------------------- ------------------------------------------------------
       2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
       2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96)
       2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (camellia128-cts-cmac)
       2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (camellia256-cts-cmac)

13.4.2. IdM CLI를 사용하여 인증 지표를 IdM 서비스와 연결

IdM(Identity Management) 관리자는 클라이언트 애플리케이션에서 제공하는 서비스 티켓에 특정 인증 지표가 포함되도록 호스트 또는 서비스를 구성할 수 있습니다. 예를 들어 Kerberos 티켓 통합 티켓(TGT)을 가져올 때 유효한 IdM 2 단계 인증 토큰을 사용하는 사용자만 해당 호스트 또는 서비스에 액세스할 수 있는지 확인할 수 있습니다.

서비스 티켓 요청에서 특정 Kerberos 인증 지표를 요구하도록 서비스를 구성하려면 다음 절차를 따르십시오.

사전 요구 사항

주의

내부 IdM 서비스에 인증 지표를 할당 하지 마십시오. 다음 IdM 서비스는 PKINIT 및 다단계 인증 방법에 필요한 대화형 인증 단계를 수행할 수 없습니다.

host/server.example.com@EXAMPLE.COM
HTTP/server.example.com@EXAMPLE.COM
ldap/server.example.com@EXAMPLE.COM
DNS/server.example.com@EXAMPLE.COM
cifs/server.example.com@EXAMPLE.COM

절차

  • ipa service-mod 명령을 사용하여 --auth-ind 인수로 식별되는 서비스에 대한 필수 인증 지표를 하나 이상 지정합니다.

    인증 방법--auth-ind value

    이중 인증

    otp

    RADIUS 인증

    반경

    PKINIT, 스마트 카드 또는 인증서 인증

    pkinit

    강화된 암호(SPAKE 또는 FAST)

    강화된

    예를 들어, 사용자가 스마트 카드 또는 OTP 인증을 통해 호스트 client.example.comtestservice principal에 대한 서비스 티켓을 검색하도록 요구하려면 다음을 수행합니다.

    [root@server ~]# ipa service-mod testservice/client.example.com@EXAMPLE.COM --auth-ind otp --auth-ind pkinit
    -------------------------------------------------------------
    Modified service "testservice/client.example.com@EXAMPLE.COM"
    -------------------------------------------------------------
      Principal name: testservice/client.example.com@EXAMPLE.COM
      Principal alias: testservice/client.example.com@EXAMPLE.COM
      Authentication Indicators: otp, pkinit
      Managed by: client.example.com
참고

서비스에서 모든 인증 지표를 제거하려면 빈 지표 목록을 제공하십시오.

[root@server ~]# ipa service-mod testservice/client.example.com@EXAMPLE.COM --auth-ind ''
------------------------------------------------------
Modified service "testservice/client.example.com@EXAMPLE.COM"
------------------------------------------------------
  Principal name: testservice/client.example.com@EXAMPLE.COM
  Principal alias: testservice/client.example.com@EXAMPLE.COM
  Managed by: client.example.com

검증 단계

  • ipa service-show 명령을 사용하여 필요한 인증 지표를 포함하여 IdM 서비스에 대한 정보를 표시합니다.

    [root@server ~]# ipa service-show testservice/client.example.com
      Principal name: testservice/client.example.com@EXAMPLE.COM
      Principal alias: testservice/client.example.com@EXAMPLE.COM
      Authentication Indicators: otp, pkinit
      Keytab: True
      Managed by: client.example.com

13.4.3. IdM 웹 UI를 사용하여 인증 지표를 IdM 서비스와 연결

IdM(Identity Management) 관리자는 클라이언트 애플리케이션에서 제공하는 서비스 티켓이 특정 인증 표시기를 포함하도록 호스트 또는 서비스를 구성할 수 있습니다. 예를 들어 Kerberos 티켓 통합 티켓(TGT)을 가져올 때 유효한 IdM 2 단계 인증 토큰을 사용하는 사용자만 해당 호스트 또는 서비스에 액세스할 수 있는지 확인할 수 있습니다.

IdM 웹 UI를 사용하여 수신되는 티켓 요청에서 특정 Kerberos 인증 지표를 요구하도록 호스트 또는 서비스를 구성하려면 다음 절차를 따르십시오.

사전 요구 사항

  • IdM 웹 UI에 관리자로 로그인했습니다.

절차

  1. ID호스트 또는 ID서비스를 선택합니다.
  2. 필요한 호스트 또는 서비스의 이름을 클릭합니다.
  3. 인증 표시기 에서 필요한 인증 방법을 선택합니다.

    • 예를 들어, OTP 를 선택하면 Kerberos TGT를 가져올 때 유효한 IdM 2 단계 인증 토큰을 사용하는 사용자만 호스트 또는 서비스에 액세스할 수 있습니다.
    • OTPRADIUS 를 모두 선택한 경우 Kerberos TGT를 얻기 위해 RADIUS 서버를 사용하여 RADIUS 서버를 사용하여 유효한 IdM 2 단계 인증 토큰을 암호로 사용한 사용자 모두 액세스할 수 있습니다.
  4. 페이지 상단에서 저장을 클릭합니다.

13.4.4. IdM 서비스에 대한 Kerberos 서비스 티켓 검색

다음 절차에서는 IdM 서비스에 대한 Kerberos 서비스 티켓 검색에 대해 설명합니다. 이 절차를 사용하여 특정 Kerberos 인증 지표가 TGT( ticket-granting 티켓)에 존재하는지와 같은 Kerberos 티켓 정책을 테스트할 수 있습니다.

사전 요구 사항

절차

  • 서비스 티켓을 검색하려면 kvno 명령을 -S 옵션과 함께 사용하고 IdM 서비스의 이름과 이를 관리하는 호스트의 정규화된 도메인 이름을 지정합니다.

    [root@server ~]# kvno -S testservice client.example.com
    testservice/client.example.com@EXAMPLE.COM: kvno = 1
참고

IdM 서비스에 액세스해야 하는 경우 현재 TGT( ticket-granting ticket)에 연결된 Kerberos 인증 지표가 없는 경우 kdestroy 명령을 사용하여 현재 Kerberos 자격 증명 캐시를 지우고 새 TGT를 검색합니다.

[root@server ~]# kdestroy

예를 들어 암호로 인증하여 TGT를 검색하고, 연결된 pkinit 인증 지표가 있는 IdM 서비스에 액세스해야 하는 경우 현재 자격 증명 캐시를 제거하고 스마트 카드로 다시 인증해야 합니다. Kerberos 인증 표시기 를 참조하십시오.

검증 단계

  • klist 명령을 사용하여 서비스 티켓이 기본 Kerberos 인증 정보 캐시에 있는지 확인합니다.

    [root@server etc]# klist_
    Ticket cache: KCM:1000
    Default principal: admin@EXAMPLE.COM
    
    Valid starting       Expires              Service principal
    04/01/2020 12:52:42  04/02/2020 12:52:39  krbtgt/EXAMPLE.COM@EXAMPLE.COM
    04/01/2020 12:54:07 04/02/2020 12:52:39 testservice/client.example.com@EXAMPLE.COM

13.4.5. 추가 리소스

13.5. 글로벌 티켓 라이프사이클 정책 구성

글로벌 티켓 정책은 모든 서비스 티켓 및 사용자별 티켓 정책이 정의되어 있지 않은 사용자에게 적용됩니다.

다음 절차에서는 ipa jenkinsfiletpolicy-mod 명령을 사용하여 글로벌 Kerberos 티켓 정책의 최대 티켓 수명 및 최대 티켓 갱신 기간을 조정하는 방법을 설명합니다.

ipa-02-tpolicy-mod 명령을 사용하는 동안 다음 인수 중 하나를 지정합니다.

  • --maxlife for the maximum ticket lifetime in seconds
  • --maxrenew - 갱신 가능한 최대 기간(초)

절차

  1. 글로벌 티켓 정책을 수정하려면 다음을 수행합니다.

    [root@server ~]# ipa krbtpolicy-mod --maxlife=$((8*60*60)) --maxrenew=$((24*60*60))
      Max life: 28800
      Max renew: 86400

    이 예에서 최대 수명은 8시간 (8 * 60분 * 60초)으로 설정되고 최대 갱신 기간은 1일 (24 * 60 분 * 60 초)으로 설정됩니다.

  2. 선택 사항: 글로벌 Kerberos 티켓 정책을 기본 설치 값으로 재설정하려면 다음을 수행합니다.

    [root@server ~]# ipa krbtpolicy-reset
      Max life: 86400
      Max renew: 604800

검증 단계

  • 글로벌 티켓 정책을 표시합니다.

    [root@server ~]# ipa krbtpolicy-show
      Max life: 28800
      Max renew: 86640

13.6. 인증 지표당 글로벌 티켓 정책 구성

각 인증 표시기에 대해 글로벌 최대 티켓 수명 및 최대 갱신 가능 기간을 조정하려면 다음 절차를 따르십시오. 이러한 설정은 사용자별 티켓 정책이 정의되지 않은 사용자에게 적용됩니다.

ipa jenkinsfiletpolicy-mod 명령을 사용하여 연결된 인증 지표에 따라 Kerberos 티켓에 대해 최대 수명 또는 최대 갱신 가능 기간을 지정합니다.

절차

  • 예를 들어 글로벌 2 단계 티켓 수명 및 갱신 기간 값을 1주일으로 설정하고 글로벌 스마트 카드 티켓 수명 및 갱신 기간 값을 2주로 설정하려면 다음을 수행합니다.

    [root@server ~]# ipa krbtpolicy-mod --otp-maxlife=604800 --otp-maxrenew=604800 --pkinit-maxlife=172800 --pkinit-maxrenew=172800

검증 단계

  • 글로벌 티켓 정책을 표시합니다.

    [root@server ~]# ipa krbtpolicy-show
      Max life: 86400
      OTP max life: 604800
      PKINIT max life: 172800
      Max renew: 604800
      OTP max renew: 604800
      PKINIT max renew: 172800

    OTP 및 PKINIT 값은 글로벌 기본 최대 수명 및 Max 갱신 값과 다릅니다.

13.7. 사용자의 기본 티켓 정책 구성

단일 사용자에게만 적용되는 고유한 Kerberos 티켓 정책을 정의할 수 있습니다. 이러한 사용자별 설정은 모든 인증 지표에 대한 글로벌 티켓 정책을 재정의합니다.

ipa-02-tpolicy-mod username 명령을 사용하고 다음 인수 중 하나를 지정합니다.

  • --maxlife for the maximum ticket lifetime in seconds
  • --maxrenew - 갱신 가능한 최대 기간(초)

절차

  1. 예를 들어 IdM 관리자 의 최대 티켓 수명을 2일로 설정하고 최대 갱신 기간을 2주로 설정하려면 다음을 수행합니다.

    [root@server ~]# ipa krbtpolicy-mod admin --maxlife=172800 --maxrenew=1209600
      Max life: 172800
      Max renew: 1209600
  2. 선택 사항: 사용자의 티켓 정책을 재설정하려면 다음을 수행합니다.

    [root@server ~]# ipa krbtpolicy-reset admin

검증 단계

  • 사용자에게 적용되는 효과적인 Kerberos 티켓 정책을 표시합니다.

    [root@server ~]# ipa krbtpolicy-show admin
      Max life: 172800
      Max renew: 1209600

추가 리소스

13.8. 사용자의 개별 인증 지표 티켓 정책 구성

관리자는 인증 지표마다 다른 사용자의 Kerberos 티켓 정책을 정의할 수 있습니다. 예를 들어, IdM 관리자가 OTP 인증을 통해 얻은 경우 2일 및 스마트 카드 인증을 통해 얻은 경우 1주일 동안 티켓을 갱신할 수 있도록 정책을 구성할 수 있습니다.

이러한 인증별 지표 설정은 사용자의 기본 티켓 정책, 글로벌 기본 티켓 정책 및 모든 글로벌 인증 지표 티켓 정책을 재정의합니다.

ipa-02-tpolicy-mod username 명령을 사용하여 연결된 인증 지표에 따라 사용자의 Kerberos 티켓에 대해 사용자 정의 수명 및 최대 갱신 가능 기간을 설정합니다.

절차

  1. 예를 들어, IdM 관리자 사용자가 일회성 암호 인증을 사용하여 얻은 경우 Kerberos 티켓을 2일 동안 갱신할 수 있도록 하려면 --otp-maxrenew 옵션을 설정합니다.

    [root@server ~]# ipa krbtpolicy-mod admin --otp-maxrenew=$((2*24*60*60))
      OTP max renew: 172800
  2. 선택 사항: 사용자의 티켓 정책을 재설정하려면 다음을 수행합니다.

    [root@server ~]# ipa krbtpolicy-reset username

검증 단계

  • 사용자에게 적용되는 효과적인 Kerberos 티켓 정책을 표시합니다.

    [root@server ~]# ipa krbtpolicy-show admin
      Max life: 28800
      Max renew: 86640

13.9. jenkinsfile tpolicy-mod 명령의 인증 지표 옵션

다음 인수를 사용하여 인증 지표의 값을 지정합니다.

표 13.1. jenkinsfile tpolicy-mod 명령의 인증 지표 옵션

인증 표시기최대 수명에 대한 인수최대 갱신 기간에 대한 인수

otp

--otp-maxlife

--otp-maxrenew

반경

--radius-maxlife

--radius-maxrenew

pkinit

--pkinit-maxlife

--pkinit-maxrenew

강화된

--hardened-maxlife

--hardened-maxrenew

14장. IdM Kerberos 키탭 파일 유지

Kerberos keytab 파일이 무엇인지, IdM(Identity Management)에서 이를 사용하여 서비스가 Kerberos로 안전하게 인증하는 방법에 대해 자세히 알아보십시오.

이 정보를 사용하여 중요한 파일을 보호하고 IdM 서비스 간의 통신 문제를 해결해야 하는 이유를 파악할 수 있습니다.

자세한 내용은 다음 항목을 참조하십시오.

14.1. Identity Management에서 Kerberos 키탭 파일을 사용하는 방법

Kerberos keytab은 Kerberos 보안 주체 및 해당 암호화 키를 포함하는 파일입니다. 호스트, 서비스, 사용자 및 스크립트는 키탭을 사용하여 KDC(Kerberos 키 배포 센터)에 안전하게 인증할 수 있습니다.

IdM 서버의 모든 IdM 서비스에는 Kerberos 데이터베이스에 저장된 고유한 Kerberos 사용자가 있습니다. 예를 들어 IdM 서버 east.idm.example.com 에서 DNS 서비스를 제공하는 경우, IdM은 이러한 서비스를 확인하기 위해 두 개의 고유한 DNS Kerberos 주체를 생성하여 이름 지정 규칙 < service>/host.domain.com@REALM.COM:

  • DNS/east.idm.example.com@IDM.EXAMPLE.COM
  • DNS/west.idm.example.com@IDM.EXAMPLE.COM

IdM은 이러한 서비스마다 서버에 키 탭을 생성하여 Kerberos 키의 로컬 사본을 KVNO(Key Version Numbers)와 함께 저장합니다. 예를 들어 기본 키탭 파일 /etc/krb5.keytab 은 Kerberos 영역에서 해당 시스템을 나타내며 로그인 인증에 사용되는 호스트 주체를 저장합니다. NetNamespace는 aes256-cts-hmac-sha1-96es128 -cts-hmac-sha1-96과 같이 지원하는 다양한 암호화 알고리즘에 대한 암호화 키를 생성합니다.

klist 명령을 사용하여 키탭 파일의 내용을 표시할 수 있습니다.

[root@idmserver ~]# klist -ekt /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   2 02/24/2022 20:28:09 host/idmserver.idm.example.com@IDM.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
   2 02/24/2022 20:28:09 host/idmserver.idm.example.com@IDM.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
   2 02/24/2022 20:28:09 host/idmserver.idm.example.com@IDM.EXAMPLE.COM (camellia128-cts-cmac)
   2 02/24/2022 20:28:09 host/idmserver.idm.example.com@IDM.EXAMPLE.COM (camellia256-cts-cmac)

14.2. Kerberos 키탭 파일이 IdM 데이터베이스와 동기화되어 있는지 확인

Kerberos 암호를 변경하면 IdM에서 해당하는 Kerberos 키를 자동으로 생성하고 KVNO(키 버전 번호)를 늘립니다. Kerberos 키탭이 새 키 및 KVNO로 업데이트되지 않은 경우 유효한 키를 검색하기 위해 해당 키탭에 의존하는 모든 서비스는 Kerberos Key Distribution Center(KDC)에 인증되지 못할 수 있습니다.

IdM 서비스 중 하나가 다른 서비스와 통신할 수 없는 경우 다음 절차에 따라 Kerberos 키탭 파일이 IdM 데이터베이스에 저장된 키와 동기화되어 있는지 확인합니다. 동기화되지 않은 경우 업데이트된 키와 KVNO를 사용하여 Kerberos 키 탭을 검색합니다. 이 예에서는 IdM 서버에 대해 업데이트된 DNS 주체를 비교하고 검색합니다.

사전 요구 사항

  • 키탭 파일을 검색하려면 IdM 관리자 계정으로 인증해야 합니다.
  • 다른 사용자가 소유한 키탭 파일을 수정하려면 root 계정으로 인증해야 합니다.

절차

  1. 확인 중인 키 탭에 보안 주체의 KVNO를 표시합니다. 다음 예에서 /etc/named.keytab 파일에는 DNS/server1.idm.example.com@EXAMPLE.COM 의 KVNO가 2인 키가 있습니다.

    [root@server1 ~]# klist -ekt /etc/named.keytab
    Keytab name: FILE:/etc/named.keytab
    KVNO Timestamp           Principal
    ---- ------------------- ------------------------------------------------------
       2 11/26/2021 13:51:11 DNS/server1.idm.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
       2 11/26/2021 13:51:11 DNS/server1.idm.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96)
       2 11/26/2021 13:51:11 DNS/server1.idm.example.com@EXAMPLE.COM (camellia128-cts-cmac)
       2 11/26/2021 13:51:11 DNS/server1.idm.example.com@EXAMPLE.COM (camellia256-cts-cmac)
  2. IdM 데이터베이스에 저장된 보안 주체의 KVNO를 표시합니다. 이 예에서 IdM 데이터베이스의 키 KVNO는 키 탭의 KVNO와 일치하지 않습니다.

    [root@server1 ~]# kvno DNS/server1.idm.example.com@EXAMPLE.COM
    DNS/server1.idm.example.com@EXAMPLE.COM: kvno = 3
  3. IdM 관리자 계정으로 인증합니다.

    [root@server1 ~]# kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  4. 보안 주체에 대해 업데이트된 Kerberos 키를 검색하여 해당 키 탭에 저장합니다. 이름이 지정된 사용자가 소유한 /etc/ named.keytab 파일을 수정할 수 있도록 이 단계를 root 사용자로 수행합니다.

    [root@server1 ~]# ipa-getkeytab -s server1.idm.example.com -p DNS/server1.idm.example.com -k /etc/named.keytab

검증

  1. 키 탭에 보안 주체의 업데이트된 KVNO를 표시합니다.

    [root@server1 ~]# klist -ekt /etc/named.keytab
    Keytab name: FILE:/etc/named.keytab
    KVNO Timestamp           Principal
    ---- ------------------- ------------------------------------------------------
       4 08/17/2022 14:42:11 DNS/server1.idm.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
       4 08/17/2022 14:42:11 DNS/server1.idm.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96)
       4 08/17/2022 14:42:11 DNS/server1.idm.example.com@EXAMPLE.COM (camellia128-cts-cmac)
       4 08/17/2022 14:42:11 DNS/server1.idm.example.com@EXAMPLE.COM (camellia256-cts-cmac)
  2. IdM 데이터베이스에 저장된 보안 주체의 KVNO를 표시하고 키탭의 KVNO와 일치하는지 확인합니다.

    [root@server1 ~]# kvno DNS/server1.idm.example.com@EXAMPLE.COM
    DNS/server1.idm.example.com@EXAMPLE.COM: kvno = 4

14.3. IdM Kerberos keytab 파일 및 해당 콘텐츠 목록

다음 표에는 IdM Kerberos 키탭 파일의 위치, 콘텐츠, 용도가 표시되어 있습니다.

표 14.1. 테이블

키탭 위치내용목적

/etc/krb5.keytab

호스트 주체

nfs 주체가 없는 경우 NFS에서 사용하는 로그인 시 사용자 자격 증명 확인

/etc/dirsrv/ds.keytab

LDAP 주체

IdM 데이터베이스에 사용자 인증, IdM 복제본 간에 데이터베이스 콘텐츠를 안전하게 복제

/var/lib/ipa/gssproxy/http.keytab

HTTP 주체

Apache 서버에 인증

/etc/named.keytab

DNS 주체

DNS 레코드 보안 업데이트

/etc/ipa/dnssec/ipa-dnskeysyncd.keytab

ipa-dnskeysyncd principal

LDAP와 OpenDNSSEC 동기화

/etc/pki/pki-tomcat/dogtag.keytab

Dogtag principal

CA(인증 기관)와의 통신

/etc/samba/samba.keytab

CIFS호스트 주체

Samba 서비스와의 통신

/var/lib/sss/keytabs/ad-domain.com.keytab

HOSTNAME$@AD-DOMAIN.COM형식의 활성 디렉터리(AD) 도메인 컨트롤러(DC) 보안 주체

IdM-AD 트러스트를 통해 AD DC와 통신

14.4. IdM 마스터 키의 암호화 유형 보기

IdM(Identity Management) 관리자는 IdM 마스터 키의 암호화 유형을 볼 수 있습니다. 이 키는 IdM Kerberos 배포 센터(KDC)에서 저장 시 다른 모든 주체를 암호화하는 데 사용하는 키입니다. 암호화 유형을 알고 있으면 FIPS 표준과 배포의 호환성을 결정하는 데 도움이 됩니다.

RHEL 8.7부터 암호화 유형은 aes256-cts-hmac-sha384-192 입니다. 이 암호화 유형은 FIPS 140-3을 준수하려는 기본 RHEL 9 FIPS 암호화 정책과 호환됩니다.

이전 RHEL 버전에서 사용된 암호화 유형은 FIPS 140-3 표준을 준수하는 RHEL 9 시스템과 호환되지 않습니다. RHEL 8 FIPS CHAP 배포와 호환되는 FIPS 모드에서 RHEL 9 시스템을 만들려면 RHEL 9 시스템에서 FIPS:AD-SUPPORT 암호화 정책을 활성화합니다.

참고

Microsoft의 Active Directory 구현에서는 SHA-2 HMAC를 사용하는 RFC8009 Kerberos 암호화 유형을 아직 지원하지 않습니다. IdM-AD 신뢰가 구성된 경우 IdM 마스터 키의 암호화 유형이 aes256-cts-hmac-sha384-192 인 경우에도 FIPS:AD-SUPPORT 암호화 하위 정책 사용이 필요합니다.

사전 요구 사항

  • IdM 배포의 모든 RHEL 8 복제본에 대한 루트 액세스 권한이 있습니다.

절차

  • 복제본에서 명령줄 인터페이스의 암호화 유형을 확인합니다.

    # kadmin.local getprinc K/M | grep -E '^Key:'
    Key: vno 1, aes256-cts-hmac-sha1-96

    출력의 aes256-cts-hmac-sha1-96 키는 IdM 배포가 RHEL 8.6 이하를 실행하는 서버에 설치되었음을 나타냅니다. 출력에 aes256-cts-hmac-sha384-192 키가 있으면 IdM 배포가 RHEL 8.7 이상을 실행하는 서버에 설치되었음을 나타냅니다.

15장. IdM에서 NetNamespace 프록시 사용

일부 관리자는 배포에서 기본 Kerberos 포트에 액세스할 수 없도록 설정할 수 있습니다. 사용자, 호스트 및 서비스가 Kerberos 자격 증명을 가져올 수 있도록 허용하려면 HTTPS 서비스를 HTTPS 포트 443을 통해 Kerberos와 통신하는 프록시로 사용할 수 있습니다.

IdM(Identity Management)에서 KKDCP( Kerberos Key Distribution Center Proxy )는 이 기능을 제공합니다.

IdM 서버에서 KKDCP는 기본적으로 활성화되어 있으며 https://server.idm.example.com/KdcProxy 에서 사용할 수 있습니다. IdM 클라이언트에서 KKDCP에 액세스하려면 Kerberos 구성을 변경해야 합니다.

15.1. KKDCP를 사용하도록 IdM 클라이언트 구성

IdM(Identity Management) 시스템 관리자는 IdM 서버에서 Kerberos KKDCP(Kerberos Key Distribution Center Proxy)를 사용하도록 IdM 클라이언트를 구성할 수 있습니다. 이 기능은 IdM 서버에서 기본 Kerberos 포트에 액세스할 수 없고 HTTPS 포트 443이 Kerberos 서비스에 액세스하는 유일한 방법입니다.

사전 요구 사항

  • IdM 클라이언트에 대한 루트 액세스 권한이 있습니다.

절차

  1. 편집할 /etc/krb5.conf 파일을 엽니다.
  2. [realms] 섹션에 kdc,admin_server, kpasswd_server 옵션에 KKDCP의 URL을 입력합니다.

    [realms]
    EXAMPLE.COM = {
      kdc = https://kdc.example.com/KdcProxy
      admin_server = https://kdc.example.com/KdcProxy
      kpasswd_server = https://kdc.example.com/KdcProxy
      default_domain = example.com
    }

    중복성을 위해 kdc,admin_serverkpasswd_server 매개 변수를 여러 번 추가하여 다른 KKDCP 서버를 표시할 수 있습니다.

  3. sssd 서비스를 다시 시작하여 변경 사항을 적용합니다.

    ~]# systemctl restart sssd

15.2. IdM 서버에서 KKDCP가 활성화되어 있는지 확인

IdM(Identity Management) 서버에서 속성 및 값 쌍 ipaConfigString=kdcProxyEnabled 가 디렉터리에 존재하는 경우 Apache 웹 서버가 시작될 때마다 Kerberos Key Distribution Center Proxy(KKDCP)가 자동으로 활성화됩니다. 이 경우 심볼릭 링크 /etc/httpd/conf.d/ipa-kdc-proxy.conf 가 생성됩니다.

권한이 없는 사용자로도 IdM 서버에서 KKDCP가 활성화되어 있는지 확인할 수 있습니다.

절차

  • 심볼릭 링크가 있는지 확인합니다.
$ ls -l /etc/httpd/conf.d/ipa-kdc-proxy.conf
lrwxrwxrwx. 1 root root 36 Jun 21  2020 /etc/httpd/conf.d/ipa-kdc-proxy.conf -> /etc/ipa/kdcproxy/ipa-kdc-proxy.conf

출력에서 KKDCP가 활성화되어 있는지 확인합니다.

15.3. IdM 서버에서 KKDCP 비활성화

IdM(Identity Management) 시스템 관리자는 IdM 서버에서 Kerberos KKDCP(Key Distribution Center Proxy)를 비활성화할 수 있습니다.

사전 요구 사항

  • IdM 서버에 대한 루트 액세스 권한이 있습니다.

절차

  1. 디렉터리에서 ipaConfigString=kdcProxyEnabled 속성 및 값 쌍을 제거합니다.

    # ipa-ldap-updater /usr/share/ipa/kdcproxy-disable.uldif
    Update complete
    The ipa-ldap-updater command was successful
  2. httpd 서비스를 다시 시작합니다.

    # systemctl restart httpd.service

현재 IdM 서버에서 KKDCP가 비활성화되어 있습니다.

검증 단계

  • 심볼릭 링크가 없는지 확인합니다.

    $ ls -l /etc/httpd/conf.d/ipa-kdc-proxy.conf
    ls: cannot access '/etc/httpd/conf.d/ipa-kdc-proxy.conf': No such file or directory

15.4. IdM 서버에서 KKDCP 다시 활성화

IdM 서버에서 KKDCP(Kerberos Key Distribution Center Proxy)는 기본적으로 활성화되어 있으며 https://server.idm.example.com/KdcProxy 에서 사용할 수 있습니다.

서버에서 KKDCP를 사용하지 않도록 설정한 경우 다시 활성화할 수 있습니다.

사전 요구 사항

  • IdM 서버에 대한 루트 액세스 권한이 있습니다.

절차

  1. 디렉터리에 ipaConfigString=kdcProxyEnabled 속성 및 값 쌍을 추가합니다.

    # ipa-ldap-updater /usr/share/ipa/kdcproxy-enable.uldif
    Update complete
    The ipa-ldap-updater command was successful
  2. httpd 서비스를 다시 시작합니다.

    # systemctl restart httpd.service

현재 IdM 서버에서 KKDCP가 활성화되어 있습니다.

검증 단계

  • 심볼릭 링크가 있는지 확인합니다.

    $ ls -l /etc/httpd/conf.d/ipa-kdc-proxy.conf
    lrwxrwxrwx. 1 root root 36 Jun 21  2020 /etc/httpd/conf.d/ipa-kdc-proxy.conf -> /etc/ipa/kdcproxy/ipa-kdc-proxy.conf

15.5. KKDCP 서버 I 구성

다음 구성을 사용하면 TCP를 IdM KKDCP와 AD(Active Directory) 영역 간의 전송 프로토콜로 사용할 수 있습니다. 여기서 여러 Kerberos 서버가 사용됩니다.

사전 요구 사항

  • 루트 액세스 권한이 있습니다.

절차

  1. /etc/ipa/kdcproxy/kdcproxy.conf 파일의 [global] 섹션에서 use_dns 매개변수를 false 로 설정합니다.

    [global]
    use_dns = false
  2. 프록시된 영역 정보를 /etc/ipa/kdcproxy/kdcproxy.conf 파일에 넣습니다. 예를 들어 프록시를 사용하는 [AD.EXAMPLE.COM] 영역의 경우 다음과 같이 영역 구성 매개 변수가 나열됩니다.

    [AD.EXAMPLE.COM]
    kerberos = kerberos+tcp://1.2.3.4:88 kerberos+tcp://5.6.7.8:88
    kpasswd = kpasswd+tcp://1.2.3.4:464 kpasswd+tcp://5.6.7.8:464
    중요

    영역 구성 매개 변수는 /etc/krb5.confkdc.conf 와 달리 공백으로 구분된 여러 서버를 나열해야 합니다. 이 경우 특정 옵션을 여러 번 지정할 수 있습니다.

  3. IdM(Identity Management) 서비스 재시작:

    # ipactl restart

추가 리소스

15.6. KKDCP 서버 II 구성

다음 서버 구성은 DNS 서비스 레코드를 사용하여 AD(Active Directory) 서버를 찾아와 통신합니다.

사전 요구 사항

  • 루트 액세스 권한이 있습니다.

절차

  1. /etc/ipa/kdcproxy/kdcproxy.conf 파일에서 [global] 섹션에서 use_dns 매개 변수를 true 로 설정합니다.

    [global]
    configs = mit
    use_dns = true

    configs 매개변수를 사용하면 다른 구성 모듈을 로드할 수 있습니다. 이 경우 구성은 MIT libkrb5 라이브러리에서 읽습니다.

  2. 선택 사항: DNS 서비스 레코드를 사용하지 않으려면 /etc/krb5.conf 파일의 [realms] 섹션에 명시적인 AD 서버를 추가합니다. 프록시가 있는 영역(예: AD.EXAMPLE.COM )이 있는 경우 다음을 추가합니다.

    [realms]
    AD.EXAMPLE.COM = {
        kdc = ad-server.ad.example.com
        kpasswd_server = ad-server.ad.example.com
    }
  3. IdM(Identity Management) 서비스 재시작:

    # ipactl restart

추가 리소스

16장. CLI를 사용하여 IdM에서 셀프 서비스 규칙 관리

IdM(Identity Management)의 셀프 서비스 규칙과 CLI(명령줄 인터페이스)에서 셀프 서비스 액세스 규칙을 생성하고 편집하는 방법에 대해 알아봅니다.

16.1. IdM의 셀프 서비스 액세스 제어

셀프 서비스 액세스 제어 규칙은 IdM(Identity Management) 엔터티가 IdM Directory Server 항목에서 수행할 수 있는 작업을 정의합니다. 예를 들어 IdM 사용자는 자신의 암호를 업데이트할 수 있습니다.

이 제어 방법을 사용하면 인증된 IdM 엔터티에서 LDAP 항목 내에서 특정 속성을 편집할 수 있지만 전체 항목에서 작업을 추가하거나 삭제할 수는 없습니다.

주의

셀프 서비스 액세스 제어 규칙으로 작업할 때 주의하십시오. 액세스 제어 규칙을 부적절하게 구성하면 엔터티의 권한을 의도치 않게 높일 수 있습니다.

16.2. CLI를 사용하여 셀프 서비스 규칙 생성

CLI(명령줄 인터페이스)를 사용하여 IdM에서 셀프 서비스 액세스 규칙을 생성하려면 다음 절차를 따르십시오.

사전 요구 사항

절차

  • 셀프 서비스 규칙을 추가하려면 ipa selfservice-add 명령을 사용하고 다음 두 가지 옵션을 지정합니다.

    --permissions
    읽기쓰기 권한을 설정합니다. ACI(액세스 제어 명령)가 부여됩니다.
    --attrs
    이 ACI에서 권한을 부여하는 전체 속성 목록을 설정합니다.

예를 들어 사용자가 자신의 이름 세부 정보를 수정할 수 있는 셀프 서비스 규칙을 생성하려면 다음을 수행합니다.

$ ipa selfservice-add "Users can manage their own name details" --permissions=write --attrs=givenname --attrs=displayname --attrs=title --attrs=initials
-----------------------------------------------------------
Added selfservice "Users can manage their own name details"
-----------------------------------------------------------
    Self-service name: Users can manage their own name details
    Permissions: write
    Attributes: givenname, displayname, title, initials

16.3. CLI를 사용하여 셀프 서비스 규칙 편집

CLI(명령줄 인터페이스)를 사용하여 IdM에서 셀프 서비스 액세스 규칙을 편집하려면 다음 절차를 따르십시오.

사전 요구 사항

절차

  1. 선택 사항: ipa selfservice-find 명령을 사용하여 기존 셀프 서비스 규칙을 표시합니다.
  2. 선택 사항: ipa selfservice-show 명령을 사용하여 수정할 셀프 서비스 규칙에 대한 세부 정보를 표시합니다.
  3. ipa selfservice-mod 명령을 사용하여 셀프 서비스 규칙을 편집합니다.

예를 들면 다음과 같습니다.

$ ipa selfservice-mod "Users can manage their own name details" --attrs=givenname --attrs=displayname --attrs=title --attrs=initials --attrs=surname
--------------------------------------------------------------
Modified selfservice "Users can manage their own name details"
--------------------------------------------------------------
Self-service name: Users can manage their own name details
Permissions: write
Attributes: givenname, displayname, title, initials
중요

ipa selfservice-mod 명령을 사용하면 이전에 정의한 권한 및 속성을 덮어쓰므로 항상 기존 권한 및 속성의 전체 목록과 정의하고자 하는 새 권한 목록을 포함합니다.

검증 단계

  • ipa selfservice-show 명령을 사용하여 편집한 셀프 서비스 규칙을 표시합니다.
$ ipa selfservice-show "Users can manage their own name details"
--------------------------------------------------------------
Self-service name: Users can manage their own name details
Permissions: write
Attributes: givenname, displayname, title, initials

16.4. CLI를 사용하여 셀프 서비스 규칙 삭제

CLI(명령줄 인터페이스)를 사용하여 IdM에서 셀프 서비스 액세스 규칙을 삭제하려면 다음 절차를 따르십시오.

사전 요구 사항

절차

  • ipa selfservice-del 명령을 사용하여 셀프 서비스 규칙을 삭제합니다.

예를 들면 다음과 같습니다.

$ ipa selfservice-del "Users can manage their own name details"
-----------------------------------------------------------
Deleted selfservice "Users can manage their own name details"
-----------------------------------------------------------

검증 단계

  • ipa selfservice-find 명령을 사용하여 모든 셀프 서비스 규칙을 표시합니다. 방금 삭제한 규칙이 누락되어야 합니다.

17장. IdM 웹 UI를 사용하여 셀프 서비스 규칙 관리

IdM(Identity Management)의 셀프 서비스 규칙과 IdM(IdM 웹 UI)에서 셀프 서비스 액세스 규칙을 생성하고 편집하는 방법에 대해 알아봅니다.

17.1. IdM의 셀프 서비스 액세스 제어

셀프 서비스 액세스 제어 규칙은 IdM(Identity Management) 엔터티가 IdM Directory Server 항목에서 수행할 수 있는 작업을 정의합니다. 예를 들어 IdM 사용자는 자신의 암호를 업데이트할 수 있습니다.

이 제어 방법을 사용하면 인증된 IdM 엔터티에서 LDAP 항목 내에서 특정 속성을 편집할 수 있지만 전체 항목에서 작업을 추가하거나 삭제할 수는 없습니다.

주의

셀프 서비스 액세스 제어 규칙으로 작업할 때 주의하십시오. 액세스 제어 규칙을 부적절하게 구성하면 엔터티의 권한을 의도치 않게 높일 수 있습니다.

17.2. IdM 웹 UI를 사용하여 셀프 서비스 규칙 생성

IdM(웹 인터페이스)을 사용하여 IdM에서 셀프 서비스 액세스 규칙을 생성하려면 다음 절차를 따르십시오.

사전 요구 사항

  • IdM 또는 사용자 관리자 역할을 관리하기 위한 관리자 권한.
  • IdM 웹 UI에 로그인되어 있습니다. 자세한 내용은 웹 브라우저에서 IdM 웹 UI 액세스를 참조하십시오.

절차

  1. IPA 서버 탭에서 역할 기반 액세스 제어 하위 메뉴를 열고 셀프 서비스 권한 을 선택합니다.
  2. 셀프 서비스 액세스 규칙 목록의 오른쪽 상단에 있는 추가 를 클릭합니다.

    Adding a self-service rule

  3. Add self Service Permission(셀프 서비스 권한 추가) 창이 열립니다. 셀프 서비스 이름 필드에 새 셀프 서비스 규칙의 이름을 입력합니다. 공백을 사용할 수 있습니다.

    Form for adding a self-service rule

  4. 사용자가 편집할 속성 옆에 있는 확인란을 선택합니다.
  5. 선택 사항: 액세스 권한을 제공하려는 특성이 나열되어 있지 않은 경우 목록을 추가할 수 있습니다.

    1. Add(추가) 버튼을 클릭합니다.
    2. 다음 Add Custom Attribute(사용자 지정 속성 추가) 창의 Attribute (특성) 텍스트 필드에 특성 이름을 입력합니다.
    3. OK(확인 ) 버튼을 클릭하여 속성을 추가합니다.
    4. 새 속성이 선택되었는지 확인합니다.
  6. 양식 하단에서 Add(추가 ) 버튼을 클릭하여 새 셀프 서비스 규칙을 저장합니다.
    또는 Add and Edit (추가 및 편집) 버튼을 클릭하여 셀프 서비스 규칙을 저장하고 계속 편집하거나 추가 및 추가 버튼을 클릭하여 추가 규칙을 저장하고 추가할 수 있습니다.

17.3. IdM 웹 UI를 사용하여 셀프 서비스 규칙 편집

IdM(웹 인터페이스)을 사용하여 IdM에서 셀프 서비스 액세스 규칙을 편집하려면 다음 절차를 따르십시오.

사전 요구 사항

  • IdM 또는 사용자 관리자 역할을 관리하기 위한 관리자 권한.
  • IdM 웹 UI에 로그인되어 있습니다. 자세한 내용은 웹 브라우저에서 IdM 웹 UI 액세스를 참조하십시오.

절차

  1. IPA 서버 탭에서 역할 기반 액세스 제어 하위 메뉴를 열고 셀프 서비스 권한 을 선택합니다.
  2. 수정할 셀프 서비스 규칙의 이름을 클릭합니다.

    Editing an existing self-service rule

  3. 편집 페이지에서만 셀프 서비스 규칙에 추가하거나 제거할 속성 목록을 편집할 수 있습니다. 적절한 확인란을 선택하거나 선택 취소합니다.
  4. Save(저장 ) 버튼을 클릭하여 셀프 서비스 규칙에 변경 사항을 저장합니다.

17.4. IdM 웹 UI를 사용하여 셀프 서비스 규칙 삭제

IdM(웹 인터페이스)을 사용하여 IdM에서 셀프 서비스 액세스 규칙을 삭제하려면 다음 절차를 따르십시오.

사전 요구 사항

  • IdM 또는 사용자 관리자 역할을 관리하기 위한 관리자 권한.
  • IdM 웹 UI에 로그인되어 있습니다. 자세한 내용은 웹 브라우저에서 IdM 웹 UI 액세스를 참조하십시오.

절차

  1. IPA 서버 탭에서 역할 기반 액세스 제어 하위 메뉴를 열고 셀프 서비스 권한 을 선택합니다.
  2. 삭제할 규칙 옆에 있는 확인란을 선택한 다음 목록 오른쪽에 있는 Delete (삭제) 버튼을 클릭합니다.

    Deleting a self-service rule

  3. 대화 상자가 열리고 Delete(삭제)를 클릭하여 확인합니다.

18장. Ansible 플레이북을 사용하여 IdM에서 셀프 서비스 규칙 관리

이 섹션에서는 IdM(Identity Management)의 셀프 서비스 규칙을 소개하고 Ansible 플레이북을 사용하여 셀프 서비스 액세스 규칙을 생성하고 편집하는 방법을 설명합니다. 셀프 서비스 액세스 제어 규칙을 사용하면 IdM 엔터티에서 IdM 디렉터리 서버 항목에서 지정된 작업을 수행할 수 있습니다.

18.1. IdM의 셀프 서비스 액세스 제어

셀프 서비스 액세스 제어 규칙은 IdM(Identity Management) 엔터티가 IdM Directory Server 항목에서 수행할 수 있는 작업을 정의합니다. 예를 들어 IdM 사용자는 자신의 암호를 업데이트할 수 있습니다.

이 제어 방법을 사용하면 인증된 IdM 엔터티에서 LDAP 항목 내에서 특정 속성을 편집할 수 있지만 전체 항목에서 작업을 추가하거나 삭제할 수는 없습니다.

주의

셀프 서비스 액세스 제어 규칙으로 작업할 때 주의하십시오. 액세스 제어 규칙을 부적절하게 구성하면 엔터티의 권한을 의도치 않게 높일 수 있습니다.

18.2. Ansible을 사용하여 셀프 서비스 규칙이 있는지 확인합니다.

다음 절차에서는 Ansible 플레이북을 사용하여 셀프 서비스 규칙을 정의하고 IdM(Identity Management) 서버에 있는지 확인하는 방법을 설명합니다. 이 예에서 새 사용자는 자신의 이름 세부 정보 규칙을 관리할 수 있으며 사용자에게 자신의 지정된 이름,디스플레이 이름, 제목초기 속성을 변경할 수 있습니다. 이를 통해 원하는 경우 표시 이름 또는 초기값을 변경할 수 있습니다.

사전 요구 사항

  • IdM 관리자 암호를 알고 있습니다.
  • 다음 요구 사항을 충족하도록 Ansible 제어 노드를 구성했습니다.

    • Ansible 버전 2.14 이상을 사용하고 있습니다.
    • Ansible 컨트롤러에 ansible-freeipa 패키지가 설치되어 있습니다.
    • 이 예제에서는 ~/MyPlaybook/ 디렉터리에서 IdM 서버의 FQDN(정규화된 도메인 이름)을 사용하여 Ansible 인벤토리 파일을 생성했다고 가정합니다.
    • 이 예제에서는 secret.yml Ansible 자격 증명 모음이 ipaadmin_password 를 저장하는 것으로 가정합니다.

절차

  1. ~/MyPlaybooks/ 디렉터리로 이동합니다.

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible -freeipa/playbooks/selfservice/ 디렉터리에 있는 selfservice- present.yml 파일의 복사본을 만듭니다.

    $ cp /usr/share/doc/ansible-freeipa/playbooks/selfservice/selfservice-present.yml selfservice-present-copy.yml
  3. 편집할 selfservice-present-copy.yml Ansible 플레이북 파일을 엽니다.
  4. ipaselfservice 작업 섹션에서 다음 변수를 설정하여 파일을 조정합니다.

    • ipaadmin_password 변수를 IdM 관리자의 암호로 설정합니다.
    • name 변수를 새 셀프 서비스 규칙의 이름으로 설정합니다.
    • 권한 변수를 쉼표로 구분된 권한 목록( 읽기쓰기 )으로 설정합니다.
    • attribute 변수를 givenname,displayname ,title, initials 등 사용자가 자체적으로 관리할 수 있는 속성 목록으로 설정합니다.

    이는 현재 예제에 대한 수정된 Ansible 플레이북 파일입니다.

    ---
    - name: Self-service present
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Ensure self-service rule "Users can manage their own name details" is present
        ipaselfservice:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: "Users can manage their own name details"
          permission: read, write
          attribute:
          - givenname
          - displayname
          - title
          - initials
  5. 파일을 저장합니다.
  6. Ansible 플레이북을 실행합니다. Playbook 파일, secret.yml 파일을 보호하는 암호를 저장하는 파일, 인벤토리 파일을 지정합니다.

    $ ansible-playbook --vault-password-file=password_file -v -i inventory selfservice-present-copy.yml

추가 리소스

  • IdM의 셀프 서비스 액세스 제어를 참조하십시오.
  • /usr/share/doc/ansible-freeipa/ 디렉터리에서 README-selfservice.md 파일을 참조하십시오.
  • /usr/share/doc/ansible-freeipa/playbooks/selfservice 디렉토리를 참조하십시오.

18.3. Ansible을 사용하여 셀프 서비스 규칙이 없는지 확인합니다.

다음 절차에서는 Ansible 플레이북을 사용하여 IdM 구성에 지정된 셀프 서비스 규칙이 없는지 확인하는 방법을 설명합니다. 아래 예제에서는 IdM에 사용자가 자체 이름 세부 정보 셀프 서비스 규칙이 없는지 확인하는 방법을 설명합니다. 이렇게 하면 사용자가 예를 들어 자체 표시 이름 또는 초기값을 변경할 수 없습니다.

사전 요구 사항

  • IdM 관리자 암호를 알고 있습니다.
  • 다음 요구 사항을 충족하도록 Ansible 제어 노드를 구성했습니다.

    • Ansible 버전 2.14 이상을 사용하고 있습니다.
    • Ansible 컨트롤러에 ansible-freeipa 패키지가 설치되어 있습니다.
    • 이 예제에서는 ~/MyPlaybook/ 디렉터리에서 IdM 서버의 FQDN(정규화된 도메인 이름)을 사용하여 Ansible 인벤토리 파일을 생성했다고 가정합니다.
    • 이 예제에서는 secret.yml Ansible 자격 증명 모음이 ipaadmin_password 를 저장하는 것으로 가정합니다.

절차

  1. ~/MyPlaybooks/ 디렉터리로 이동합니다.

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible -freeipa/playbooks/selfservice/ 디렉터리에 있는 selfservice- absent.yml 파일의 복사본을 만듭니다.

    $ cp /usr/share/doc/ansible-freeipa/playbooks/selfservice/selfservice-absent.yml selfservice-absent-copy.yml
  3. selfservice-absent-copy.yml Ansible 플레이북 파일을 편집하여 편집합니다.
  4. ipaselfservice 작업 섹션에서 다음 변수를 설정하여 파일을 조정합니다.

    • ipaadmin_password 변수를 IdM 관리자의 암호로 설정합니다.
    • name 변수를 셀프 서비스 규칙의 이름으로 설정합니다.
    • state 변수를 absent 로 설정합니다.

    이는 현재 예제에 대한 수정된 Ansible 플레이북 파일입니다.

    ---
    - name: Self-service absent
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Ensure self-service rule "Users can manage their own name details" is absent
        ipaselfservice:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: "Users can manage their own name details"
          state: absent
  5. 파일을 저장합니다.
  6. Ansible 플레이북을 실행합니다. Playbook 파일, secret.yml 파일을 보호하는 암호를 저장하는 파일, 인벤토리 파일을 지정합니다.

    $ ansible-playbook --vault-password-file=password_file -v -i inventory selfservice-absent-copy.yml

추가 리소스

  • IdM의 셀프 서비스 액세스 제어를 참조하십시오.
  • /usr/share/doc/ansible-freeipa/ 디렉터리에서 README-selfservice.md 파일을 참조하십시오.
  • /usr/share/doc/ansible-freeipa/playbooks/selfservice 디렉터리에서 샘플 플레이북을 참조하십시오.

18.4. Ansible을 사용하여 셀프 서비스 규칙에 특정 특성이 있는지 확인합니다.

다음 절차에서는 Ansible 플레이북을 사용하여 기존 셀프 서비스 규칙에 특정 설정이 있는지 확인하는 방법을 설명합니다. 이 예제에서는 사용자가 자신의 이름 세부 정보 셀프 서비스 규칙에 멤버 속성도 관리할 수 있는지 확인합니다.

사전 요구 사항

  • IdM 관리자 암호를 알고 있습니다.
  • 다음 요구 사항을 충족하도록 Ansible 제어 노드를 구성했습니다.

    • Ansible 버전 2.14 이상을 사용하고 있습니다.
    • Ansible 컨트롤러에 ansible-freeipa 패키지가 설치되어 있습니다.
    • 이 예제에서는 ~/MyPlaybook/ 디렉터리에서 IdM 서버의 FQDN(정규화된 도메인 이름)을 사용하여 Ansible 인벤토리 파일을 생성했다고 가정합니다.
    • 이 예제에서는 secret.yml Ansible 자격 증명 모음이 ipaadmin_password 를 저장하는 것으로 가정합니다.
  • 사용자는 IdM에 있는 고유한 이름 세부 정보 셀프 서비스 규칙을 관리할 수 있습니다.

절차

  1. ~/MyPlaybooks/ 디렉터리로 이동합니다.

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible -freeipa/playbooks/selfservice/ 디렉터리에 있는 selfservice- member-present.yml 파일의 복사본을 만듭니다.

    $ cp /usr/share/doc/ansible-freeipa/playbooks/selfservice/selfservice-member-present.yml selfservice-member-present-copy.yml
  3. selfservice-member-present-copy.yml Ansible 플레이북 파일을 편집하여 편집합니다.
  4. ipaselfservice 작업 섹션에서 다음 변수를 설정하여 파일을 조정합니다.

    • ipaadmin_password 변수를 IdM 관리자의 암호로 설정합니다.
    • name 변수를 수정할 셀프 서비스 규칙의 이름으로 설정합니다.
    • 특성 변수를 성으로 설정합니다.
    • action 변수를 member 로 설정합니다.

    이는 현재 예제에 대한 수정된 Ansible 플레이북 파일입니다.

    ---
    - name: Self-service member present
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Ensure selfservice "Users can manage their own name details" member attribute surname is present
        ipaselfservice:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: "Users can manage their own name details"
          attribute:
          - surname
          action: member
  5. 파일을 저장합니다.
  6. Ansible 플레이북을 실행합니다. Playbook 파일, secret.yml 파일을 보호하는 암호를 저장하는 파일, 인벤토리 파일을 지정합니다.

    $ ansible-playbook --vault-password-file=password_file -v -i inventory selfservice-member-present-copy.yml

추가 리소스

  • IdM의 셀프 서비스 액세스 제어를 참조하십시오.
  • /usr/share/doc/ansible-freeipa/ 디렉토리에서 사용 가능한 README-selfservice.md 파일을 참조하십시오.
  • /usr/share/doc/ansible-freeipa/playbooks/selfservice 디렉터리에서 샘플 플레이북을 참조하십시오.

18.5. Ansible을 사용하여 셀프 서비스 규칙에 특정 속성이 없는지 확인합니다.

다음 절차에서는 Ansible 플레이북을 사용하여 셀프 서비스 규칙에 특정 설정이 없는지 확인하는 방법을 설명합니다. 이 플레이북을 사용하여 셀프 서비스 규칙이 바람직하지 않은 액세스 권한을 부여하지 않도록 할 수 있습니다. 이 예에서 사용자는 이름 세부 정보 셀프 서비스 규칙에 지정된 이름과 멤버 속성이 없는지 확인합니다.

사전 요구 사항

  • IdM 관리자 암호를 알고 있습니다.
  • 다음 요구 사항을 충족하도록 Ansible 제어 노드를 구성했습니다.

    • Ansible 버전 2.14 이상을 사용하고 있습니다.
    • Ansible 컨트롤러에 ansible-freeipa 패키지가 설치되어 있습니다.
    • 이 예제에서는 ~/MyPlaybook/ 디렉터리에서 IdM 서버의 FQDN(정규화된 도메인 이름)을 사용하여 Ansible 인벤토리 파일을 생성했다고 가정합니다.
    • 이 예제에서는 secret.yml Ansible 자격 증명 모음이 ipaadmin_password 를 저장하는 것으로 가정합니다.
  • 사용자는 IdM에 있는 고유한 이름 세부 정보 셀프 서비스 규칙을 관리할 수 있습니다.

절차

  1. ~/MyPlaybooks/ 디렉터리로 이동합니다.

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible -freeipa/playbooks/selfservice/ 디렉터리에 있는 selfservice-member- absent.yml 파일의 복사본을 만듭니다.

    $ cp /usr/share/doc/ansible-freeipa/playbooks/selfservice/selfservice-member-absent.yml selfservice-member-absent-copy.yml
  3. selfservice-member-absent-copy.yml Ansible 플레이북 파일을 편집하여 편집합니다.
  4. ipaselfservice 작업 섹션에서 다음 변수를 설정하여 파일을 조정합니다.

    • ipaadmin_password 변수를 IdM 관리자의 암호로 설정합니다.
    • name 변수를 수정할 셀프 서비스 규칙의 이름으로 설정합니다.
    • 특성 변수를 주어진 이름 및 성으로 설정합니다.
    • action 변수를 member 로 설정합니다.
    • state 변수를 absent 로 설정합니다.

    이는 현재 예제에 대한 수정된 Ansible 플레이북 파일입니다.

    ---
    - name: Self-service member absent
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Ensure selfservice "Users can manage their own name details" member attributes givenname and surname are absent
        ipaselfservice:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: "Users can manage their own name details"
          attribute:
          - givenname
          - surname
          action: member
          state: absent
  5. 파일을 저장합니다.
  6. Ansible 플레이북을 실행합니다. Playbook 파일, secret.yml 파일을 보호하는 암호를 저장하는 파일, 인벤토리 파일을 지정합니다.

    $ ansible-playbook --vault-password-file=password_file -v -i inventory selfservice-member-absent-copy.yml

추가 리소스

  • IdM의 셀프 서비스 액세스 제어를 참조하십시오.
  • /usr/share/doc/ansible-freeipa/ 디렉터리에서 README-selfservice.md 파일을 참조하십시오.
  • /usr/share/doc/ansible-freeipa/playbooks/selfservice 디렉터리에서 샘플 플레이북을 참조하십시오.

19장. IdM CLI에서 사용자 그룹 관리

이 장에서는 IdM CLI를 사용한 사용자 그룹 관리 방법을 소개합니다.

사용자 그룹은 공통 권한, 암호 정책 및 기타 특성을 가진 사용자 집합입니다.

IdM(Identity Management)의 사용자 그룹은 다음을 포함할 수 있습니다.

  • IdM 사용자
  • 기타 IdM 사용자 그룹
  • 외부 사용자 - IdM 외부에 존재하는 사용자

19.1. IdM의 다양한 그룹 유형

IdM은 다음과 같은 유형의 그룹을 지원합니다.

POSIX 그룹(기본값)

POSIX 그룹은 구성원에 대해 Linux POSIX 특성을 지원합니다. Active Directory와 상호 작용하는 그룹은 POSIX 특성을 사용할 수 없습니다.

POSIX 속성은 사용자를 별도의 엔터티로 식별합니다. 사용자와 관련된 POSIX 속성의 예로는 사용자 번호(UID)인 uidNumber 와 그룹 번호(GID)인 gidNumber 가 있습니다.

postIX 이외의 그룹

POST 이외의 그룹은 POSIX 특성을 지원하지 않습니다. 예를 들어, 이러한 그룹에는 GID가 정의되어 있지 않습니다.

이 유형의 그룹의 모든 멤버는 IdM 도메인에 속해야 합니다.

외부 그룹

외부 그룹을 사용하여 IdM 도메인 외부의 ID 저장소에 있는 그룹 구성원을 추가합니다(예:).

  • 로컬 시스템
  • Active Directory 도메인
  • 디렉터리 서비스

외부 그룹은 POSIX 특성을 지원하지 않습니다. 예를 들어, 이러한 그룹에는 GID가 정의되어 있지 않습니다.

표 19.1. 기본적으로 생성된 사용자 그룹

그룹 이름기본 그룹 멤버

ipausers

모든 IdM 사용자

admins

기본 admin 사용자를 포함하여 관리 권한이 있는 사용자

편집기

이는 더 이상 특수 권한이 없는 레거시 그룹입니다.

신뢰 관리자

Active Directory 신뢰 관리를 위한 권한이 있는 사용자

사용자를 사용자 그룹에 추가하면 사용자에게 그룹과 관련된 권한 및 정책이 부여됩니다. 예를 들어 사용자에게 관리 권한을 부여하려면 사용자를 admins 그룹에 추가합니다.

주의

admins 그룹을 삭제하지 마십시오. admins 는 IdM에 필요한 사전 정의된 그룹이므로 이 작업으로 인해 특정 명령에 문제가 발생합니다.

또한 IdM에서 새 사용자가 생성될 때마다 IdM은 기본적으로 사용자 개인 그룹을 생성합니다. 개인 그룹에 대한 자세한 내용은 개인 그룹이 없는 사용자 추가를 참조하십시오.

19.2. 직접 및 간접 그룹 구성원

IdM의 사용자 그룹 속성은 직접 및 간접 구성원 모두에 적용됩니다. B 그룹이 A 그룹의 구성원이면 B 그룹의 모든 사용자는 A 그룹의 간접 구성원으로 간주됩니다.

예를 들어 다음 다이어그램에서 다음을 수행합니다.

  • User 1 및 User 2는 A 그룹의 직접 구성원입니다.
  • User 3, User 4 및 User 5는 A 그룹의 간접 구성원입니다.

그림 19.1. 직접 및 간접 그룹 멤버십

그룹 A(사용자 2명) 및 그룹 B(사용자 3명 포함)가 포함된 차트. B 그룹은 A 그룹에 중첩되어 있으므로 A 그룹에는 총 5명의 사용자가 포함됩니다.

사용자 그룹 A에 대한 암호 정책을 설정하면 이 정책은 사용자 그룹 B의 모든 사용자에게도 적용됩니다.

19.3. IdM CLI를 사용하여 사용자 그룹 추가

IdM CLI를 사용하여 사용자 그룹을 추가하려면 다음 절차를 따르십시오.

사전 요구 사항

절차

  • ipa group-add group _name 명령을 사용하여 사용자 그룹을 추가합니다. 예를 들어 group_a를 생성하려면 다음을 수행합니다.

    $ ipa group-add group_a
    ---------------------
    Added group "group_a"
    ---------------------
      Group name: group_a
      GID: 1133400009

    기본적으로 ipa group-add 는 POSIX 사용자 그룹을 추가합니다. 다른 그룹 유형을 지정하려면 ipa group-add 에 옵션을 추가합니다.

    • --POSIX 이외의 그룹을 만드는 nonposix
    • 외부 그룹을 만드는 --external

      그룹 유형에 대한 자세한 내용은 IdM의 다양한 그룹 유형을 참조하십시오.

    --gid= custom_GID 옵션을 사용하여 사용자 그룹을 추가할 때 사용자 지정 GID를 지정할 수 있습니다. 이 작업을 수행하는 경우 ID 충돌을 피하십시오. 사용자 지정 GID를 지정하지 않으면 IdM에서 사용 가능한 ID 범위에서 GID를 자동으로 할당합니다.

주의

IdM에 로컬 그룹을 추가하지 마십시오. NSS(Name Service Switch)는 로컬 사용자 및 그룹을 확인하기 전에 항상 IdM 사용자 및 그룹을 확인합니다. 즉, IdM 그룹 멤버십은 로컬 사용자에게 작동하지 않습니다.

19.4. IdM CLI를 사용하여 사용자 그룹 검색

IdM CLI를 사용하여 기존 사용자 그룹을 검색하려면 다음 절차를 따르십시오.

절차

  • ipa group-find 명령을 사용하여 모든 사용자 그룹을 표시합니다. 그룹 유형을 지정하려면 ipa group-find 에 옵션을 추가합니다.

    • ipa group-find --posix 명령을 사용하여 모든 POSIX 그룹을 표시합니다.
    • ipa group-find --nonposix 명령을 사용하여 모든 비POSIX 그룹을 표시합니다.
    • ipa group-find --external 명령을 사용하여 모든 외부 그룹을 표시합니다.

      다양한 그룹 유형에 대한 자세한 내용은 IdM의 다양한 그룹 유형을 참조하십시오.

19.5. IdM CLI를 사용하여 사용자 그룹 삭제

IdM CLI를 사용하여 사용자 그룹을 삭제하려면 다음 절차를 따르십시오. 그룹을 삭제해도 IdM에서 그룹 구성원이 삭제되지 않습니다.

사전 요구 사항

절차

  • ipa group-del group _name 명령을 사용하여 사용자 그룹을 삭제합니다. 예를 들어 group_a를 삭제하려면 다음을 수행합니다.

    $ ipa group-del group_a
    --------------------------
    Deleted group "group_a"
    --------------------------

19.6. IdM CLI를 사용하여 사용자 그룹에 멤버 추가

사용자 및 사용자 그룹을 사용자 그룹의 멤버로 추가할 수 있습니다. 자세한 내용은 IdM 및 직접 및 간접 그룹 구성원의 다양한 그룹 유형을 참조하십시오. IdM CLI를 사용하여 사용자 그룹에 멤버를 추가하려면 다음 절차를 따르십시오.

사전 요구 사항

절차

  • ipa group-add-member 명령을 사용하여 사용자 그룹에 멤버를 추가합니다.

    다음 옵션을 사용하여 멤버 유형을 지정합니다.

    • --users 는 IdM 사용자 추가
    • --external 은 IdM 도메인 외부에 있는 사용자 추가: sudoAIN \user_name 또는 user_name@domain형식으로
    • --groups 는 IdM 사용자 그룹 추가

    예를 들어 group_b를 group_a의 멤버로 추가하려면 다음을 수행합니다.

    $ ipa group-add-member group_a --groups=group_b
    Group name: group_a
    GID: 1133400009
    Member users: user_a
    Member groups: group_b
    Indirect Member users: user_b
    -------------------------
    Number of members added 1
    -------------------------

    group_b의 멤버는 이제 group_a의 간접 멤버입니다.

중요

그룹을 다른 그룹의 구성원으로 추가할 때 재귀 그룹을 만들지 마십시오. 예를 들어 그룹 A가 그룹 B의 구성원인 경우 그룹 A의 구성원으로 그룹 B를 추가하지 마십시오. 반복적인 그룹은 예측할 수 없는 동작이 발생할 수 있습니다.

참고

사용자 그룹에 멤버를 추가하고 나면 업데이트에 Identity Management 환경의 모든 클라이언트에 분배하는 데 다소 시간이 걸릴 수 있습니다. 이는 지정된 호스트에서 사용자, 그룹 및 넷 그룹을 확인할 때 먼저 SSSD(System Security Services Daemon )에서 캐시를 살펴보고 서버 조회를 누락되거나 만료된 레코드에 대해서만 수행하기 때문입니다.

19.7. 사용자 개인 그룹없이 사용자 추가

기본적으로 IdM은 새 사용자가 IdM에 생성될 때마다 사용자 개인 그룹(UPG)을 생성합니다. UPG는 특정 그룹 유형입니다.

  • UPG의 이름은 새로 생성된 사용자와 동일합니다.
  • 사용자는 UPG의 유일한 멤버입니다. UPG는 다른 멤버를 포함할 수 없습니다.
  • 개인 그룹의 GID는 사용자의 UID와 일치합니다.

그러나 UPG를 생성하지 않고 사용자를 추가할 수 있습니다.

19.7.1. 사용자 개인 그룹이 없는 사용자

NIS 그룹 또는 다른 시스템 그룹이 사용자 개인 그룹에 할당되는 GID를 이미 사용하는 경우 UPG를 생성하지 않아야 합니다.

다음 두 가지 방법으로 이 작업을 수행할 수 있습니다.

두 경우 모두 IdM은 새 사용자를 추가할 때 GID를 지정해야 합니다. 그렇지 않으면 작업이 실패합니다. IdM에는 새 사용자에 대한 GID가 필요하지만 기본 사용자 그룹 ipausers 는 POSTIX 그룹이 아니므로 GID가 연결되어 있지 않기 때문입니다. 지정한 GID는 기존 그룹에 해당하지 않아도 됩니다.

참고

GID를 지정해도 새 그룹이 생성되지 않습니다. IdM에서 속성이 필요하므로 새 사용자의 GID 속성만 설정합니다.

19.7.2. 개인 그룹이 전역적으로 활성화된 경우 사용자 개인 그룹이 없는 사용자 추가

UPG(사용자 개인 그룹)를 시스템에서 활성화된 경우에도 사용자를 만들 수 있습니다. 이를 위해서는 새 사용자에 대한 GID를 수동으로 설정해야 합니다. 필요한 이유에 대한 자세한 내용은 사용자 개인 그룹이 없는 사용자를 참조하십시오.

절차

  • IdM이 UPG를 생성하지 못하도록 하려면 ipa user-add 명령에 --noprivate 옵션을 추가합니다.

    명령이 성공하려면 사용자 지정 GID를 지정해야 합니다. 예를 들어 GID가 10000인 새 사용자를 추가하려면 다음을 수행합니다.

    $ ipa user-add jsmith --first=John --last=Smith --noprivate --gid 10000

19.7.3. 모든 사용자에 대해 사용자 개인 그룹 전역 비활성화

사용자 개인 그룹(UPG)을 전역적으로 비활성화할 수 있습니다. 이로 인해 모든 새 사용자에 대한 UPG가 생성되지 않습니다. 기존 사용자는 이 변경의 영향을 받지 않습니다.

절차

  1. 관리자 권한을 얻습니다.

    $ kinit admin
  2. IdM은 Directory Server Managed Entries 플러그인을 사용하여 UPG를 관리합니다. 플러그인 인스턴스를 나열합니다.

    $ ipa-managed-entries --list
  3. IdM이 UPG를 생성하지 않도록 하려면 사용자 개인 그룹 관리를 담당하는 플러그인 인스턴스를 비활성화합니다.

    $ ipa-managed-entries -e "UPG Definition" disable
    Disabling Plugin
    참고

    나중에 UPG 정의 인스턴스를 다시 활성화하려면 ipa-managed-entries -e "UPG Definition" enable 명령을 사용합니다.

  4. Directory Server를 다시 시작하여 새 구성을 로드합니다.

    $ sudo systemctl restart dirsrv.target

    UPG를 비활성화한 다음 사용자를 추가하려면 GID를 지정해야 합니다. 자세한 내용은 사용자 개인 그룹이 전역적으로 비활성화된 경우 사용자 추가를 참조하십시오.

검증 단계

  • UPG가 전역적으로 비활성화되어 있는지 확인하려면 disable 명령을 다시 사용합니다.

    $ ipa-managed-entries -e "UPG Definition" disable
    Plugin already disabled

19.7.4. 사용자 개인 그룹이 전역적으로 비활성화된 경우 사용자 추가

사용자 개인 그룹(UPG)이 전역적으로 비활성화되면 IdM에서 새 사용자에게 GID를 자동으로 할당하지 않습니다. 사용자를 성공적으로 추가하려면 수동으로 또는 automember 규칙을 사용하여 GID를 할당해야 합니다. 필요한 이유에 대한 자세한 내용은 사용자 개인 그룹이 없는 사용자를 참조하십시오.

전제 조건

절차

  • UPG를 생성할 때 새 사용자를 추가하는 것이 성공했는지 확인하려면 다음 중 하나를 선택하십시오.

    • 새 사용자를 추가할 때 사용자 지정 GID를 지정합니다. GID는 기존 사용자 그룹에 해당하지 않아도 됩니다.

      예를 들어 명령줄에서 사용자를 추가하는 경우 ipa user-add 명령에 --gid 옵션을 추가합니다.

    • automember 규칙을 사용하여 GID가 있는 기존 그룹에 사용자를 추가합니다.

19.8. IdM CLI를 사용하여 IdM 사용자 그룹에 멤버 관리자로 사용자 또는 그룹 추가

IdM CLI를 사용하여 IdM 사용자 그룹에 사용자 또는 그룹을 멤버 관리자로 추가하려면 다음 절차를 따르십시오. 멤버 관리자는 IdM 사용자 그룹에 사용자 또는 그룹을 추가할 수 있지만 그룹의 특성을 변경할 수는 없습니다.

사전 요구 사항

절차

  • ipa group-add-member-manager 명령을 사용하여 사용자를 IdM 사용자 그룹에 멤버 관리자로 추가합니다.

    예를 들어 사용자 testgroup_a 의 멤버 관리자로 추가하려면 다음을 수행합니다.

    $ ipa group-add-member-manager group_a --users=test
    Group name: group_a
    GID: 1133400009
    Membership managed by users: test
    -------------------------
    Number of members added 1
    -------------------------

    사용자 테스트는 이제 group_a 의 멤버를 관리할 수 있습니다.

  • ipa group-add-member-manager 명령을 사용하여 그룹을 IdM 사용자 그룹에 멤버 관리자로 추가합니다.

    예를 들어 group _admins 그룹을 group_ a 의 멤버 관리자로 추가하려면 :

    $ ipa group-add-member-manager group_a --groups=group_admins
    Group name: group_a
    GID: 1133400009
    Membership managed by groups: group_admins
    Membership managed by users: test
    -------------------------
    Number of members added 1
    -------------------------

    group_admins 그룹이 이제 group_a 의 멤버를 관리할 수 있습니다.

참고

사용자 그룹에 멤버 관리자를 추가한 후 업데이트에 Identity Management 환경의 모든 클라이언트에 분배하는 데 다소 시간이 걸릴 수 있습니다.

검증 단계

  • ipa group-show 명령을 사용하여 사용자와 그룹이 멤버 관리자로 추가되었는지 확인합니다.

    $ ipa group-show group_a
    Group name: group_a
    GID: 1133400009
    Membership managed by groups: group_admins
    Membership managed by users: test

추가 리소스

  • 자세한 내용은 ipa group-add-member-manager --help 를 참조하십시오.

19.9. IdM CLI를 사용하여 그룹 멤버 보기

IdM CLI를 사용하여 그룹의 멤버를 보려면 다음 절차를 따르십시오. 직접 및 간접 그룹 구성원을 모두 볼 수 있습니다. 자세한 내용은 직접 및 간접 그룹 구성원을 참조하십시오.

절차:

  • 그룹의 구성원을 나열하려면 ipa group-show group_name 명령을 사용합니다. 예를 들면 다음과 같습니다.

    $ ipa group-show group_a
      ...
      Member users: user_a
      Member groups: group_b
      Indirect Member users: user_b
    참고

    간접 구성원 목록에는 신뢰할 수 있는 Active Directory 도메인의 외부 사용자가 포함되지 않습니다. Active Directory 신뢰 사용자 오브젝트는 Identity Management 내에 LDAP 오브젝트로 존재하지 않기 때문에 ID 관리 인터페이스에 표시되지 않습니다.

19.10. IdM CLI를 사용하여 사용자 그룹에서 멤버 제거

IdM CLI를 사용하여 사용자 그룹에서 멤버를 제거하려면 다음 절차를 따르십시오.

사전 요구 사항

절차

  1. 선택 사항: ipa group-show 명령을 사용하여 그룹에 제거할 멤버가 포함되어 있는지 확인합니다.
  2. ipa group-remove-member 명령을 사용하여 사용자 그룹에서 멤버를 제거합니다.

    다음 옵션을 사용하여 제거할 멤버를 지정합니다.

    • --users 는 IdM 사용자를 제거합니다
    • --external 은 pamAIN \user_name 또는 user_name@domain 형식으로 IdM 도메인 외부에 있는 사용자를 제거합니다.
    • --groups 는 IdM 사용자 그룹을 제거합니다

    예를 들어 group _name 이라는 그룹에서 user1, user2group1 을 제거하려면 다음을 수행합니다.

    $ ipa group-remove-member group_name --users=user1 --users=user2 --groups=group1

19.11. IdM CLI를 사용하여 IdM 사용자 그룹에서 사용자 또는 그룹을 구성원 관리자로 제거

IdM CLI를 사용하여 IdM 사용자 그룹에서 멤버 관리자로 사용자 또는 그룹을 제거하려면 다음 절차를 따르십시오. 멤버 관리자는 IdM 사용자 그룹에서 사용자 또는 그룹을 제거할 수 있지만 그룹의 특성을 변경할 수는 없습니다.

사전 요구 사항

절차

  • ipa group-remove-member-manager 명령을 사용하여 IdM 사용자 그룹의 멤버 관리자로 사용자를 제거합니다.

    예를 들어 user testgroup_a 의 멤버 관리자로 제거하려면 다음을 수행합니다.

    $ ipa group-remove-member-manager group_a --users=test
    Group name: group_a
    GID: 1133400009
    Membership managed by groups: group_admins
    ---------------------------
    Number of members removed 1
    ---------------------------

    사용자 테스트는 더 이상 group_a 의 구성원을 관리할 수 없습니다.

  • ipa group-remove-member-manager 명령을 사용하여 IdM 사용자 그룹의 멤버 관리자로 그룹을 제거합니다.

    예를 들어 group _admins 그룹을 group_ a 의 멤버 관리자로 제거하려면 다음을 수행합니다.

    $ ipa group-remove-member-manager group_a --groups=group_admins
    Group name: group_a
    GID: 1133400009
    ---------------------------
    Number of members removed 1
    ---------------------------

    그룹 group_admins는 더 이상 group_a 의 구성원을 관리할 수 없습니다.

참고

사용자 그룹에서 멤버 관리자를 제거한 후 업데이트에 Identity Management 환경의 모든 클라이언트에 분배하는 데 다소 시간이 걸릴 수 있습니다.

검증 단계

  • ipa group-show 명령을 사용하여 사용자와 그룹이 멤버 관리자로 제거되었는지 확인합니다.

    $ ipa group-show group_a
    Group name: group_a
    GID: 1133400009

추가 리소스

  • 자세한 내용은 ipa group-remove-member-manager --help 를 참조하십시오.

20장. IdM 웹 UI에서 사용자 그룹 관리

이 장에서는 IdM 웹 UI를 사용한 사용자 그룹 관리에 대해 소개합니다.

사용자 그룹은 공통 권한, 암호 정책 및 기타 특성을 가진 사용자 집합입니다.

IdM(Identity Management)의 사용자 그룹은 다음을 포함할 수 있습니다.

  • IdM 사용자
  • 기타 IdM 사용자 그룹
  • 외부 사용자 - IdM 외부에 존재하는 사용자

20.1. IdM의 다양한 그룹 유형

IdM은 다음과 같은 유형의 그룹을 지원합니다.

POSIX 그룹(기본값)

POSIX 그룹은 구성원에 대해 Linux POSIX 특성을 지원합니다. Active Directory와 상호 작용하는 그룹은 POSIX 특성을 사용할 수 없습니다.

POSIX 속성은 사용자를 별도의 엔터티로 식별합니다. 사용자와 관련된 POSIX 속성의 예로는 사용자 번호(UID)인 uidNumber 와 그룹 번호(GID)인 gidNumber 가 있습니다.

postIX 이외의 그룹

POST 이외의 그룹은 POSIX 특성을 지원하지 않습니다. 예를 들어, 이러한 그룹에는 GID가 정의되어 있지 않습니다.

이 유형의 그룹의 모든 멤버는 IdM 도메인에 속해야 합니다.

외부 그룹

외부 그룹을 사용하여 IdM 도메인 외부의 ID 저장소에 있는 그룹 구성원을 추가합니다(예:).

  • 로컬 시스템
  • Active Directory 도메인
  • 디렉터리 서비스

외부 그룹은 POSIX 특성을 지원하지 않습니다. 예를 들어, 이러한 그룹에는 GID가 정의되어 있지 않습니다.

표 20.1. 기본적으로 생성된 사용자 그룹

그룹 이름기본 그룹 멤버

ipausers

모든 IdM 사용자

admins

기본 admin 사용자를 포함하여 관리 권한이 있는 사용자

편집기

이는 더 이상 특수 권한이 없는 레거시 그룹입니다.

신뢰 관리자

Active Directory 신뢰 관리를 위한 권한이 있는 사용자

사용자를 사용자 그룹에 추가하면 사용자에게 그룹과 관련된 권한 및 정책이 부여됩니다. 예를 들어 사용자에게 관리 권한을 부여하려면 사용자를 admins 그룹에 추가합니다.

주의

admins 그룹을 삭제하지 마십시오. admins 는 IdM에 필요한 사전 정의된 그룹이므로 이 작업으로 인해 특정 명령에 문제가 발생합니다.

또한 IdM에서 새 사용자가 생성될 때마다 IdM은 기본적으로 사용자 개인 그룹을 생성합니다. 개인 그룹에 대한 자세한 내용은 개인 그룹이 없는 사용자 추가를 참조하십시오.

20.2. 직접 및 간접 그룹 구성원

IdM의 사용자 그룹 속성은 직접 및 간접 구성원 모두에 적용됩니다. B 그룹이 A 그룹의 구성원이면 B 그룹의 모든 사용자는 A 그룹의 간접 구성원으로 간주됩니다.

예를 들어 다음 다이어그램에서 다음을 수행합니다.

  • User 1 및 User 2는 A 그룹의 직접 구성원입니다.
  • User 3, User 4 및 User 5는 A 그룹의 간접 구성원입니다.

그림 20.1. 직접 및 간접 그룹 멤버십

그룹 A(사용자 2명) 및 그룹 B(사용자 3명 포함)가 포함된 차트. B 그룹은 A 그룹에 중첩되어 있으므로 A 그룹에는 총 5명의 사용자가 포함됩니다.

사용자 그룹 A에 대한 암호 정책을 설정하면 이 정책은 사용자 그룹 B의 모든 사용자에게도 적용됩니다.

20.3. IdM 웹 UI를 사용하여 사용자 그룹 추가

IdM 웹 UI를 사용하여 사용자 그룹을 추가하려면 다음 절차를 따르십시오.

사전 요구 사항

  • IdM 웹 UI에 로그인되어 있습니다.

절차

  1. ID → 그룹을 클릭하고 왼쪽 사이드바 에서 사용자 그룹을 선택합니다.
  2. Add(추가) 를 클릭하여 그룹 추가를 시작합니다.
  3. 그룹에 대한 정보를 입력합니다. 사용자 그룹 유형에 대한 자세한 내용은 IdM의 다양한 그룹 유형에서 참조하십시오.

    그룹에 대한 사용자 지정 GID를 지정할 수 있습니다. 이 작업을 수행하는 경우 ID 충돌을 피하십시오. 사용자 지정 GID를 지정하지 않으면 IdM에서 사용 가능한 ID 범위에서 GID를 자동으로 할당합니다.

    다음 필드가 있는 "Add user group" 팝업 창의 스크린샷: 그룹 이름(필수 필드) - Description - Group Type - GID. "추가" 버튼이 맨 아래에 있습니다.
  4. Add(추가) 를 클릭하여 확인합니다.

20.4. IdM 웹 UI를 사용하여 사용자 그룹 삭제

IdM 웹 UI를 사용하여 사용자 그룹을 삭제하려면 다음 절차를 따르십시오. 그룹을 삭제해도 IdM에서 그룹 구성원이 삭제되지 않습니다.

사전 요구 사항

  • IdM 웹 UI에 로그인되어 있습니다.

절차

  1. ID → 그룹을 클릭하고 사용자 그룹을 선택합니다.
  2. 삭제할 그룹을 선택합니다.
  3. 삭제를 클릭합니다.
  4. Delete(삭제) 를 클릭하여 확인합니다.

20.5. IdM 웹 UI를 사용하여 사용자 그룹에 멤버 추가

사용자 및 사용자 그룹을 사용자 그룹의 멤버로 추가할 수 있습니다. 자세한 내용은 IdM 및 직접 및 간접 그룹 구성원의 다양한 그룹 유형을 참조하십시오.

사전 요구 사항

  • IdM 웹 UI에 로그인되어 있습니다.

절차

  1. ID → 그룹을 클릭하고 왼쪽 사이드바 에서 사용자 그룹을 선택합니다.
  2. 그룹의 이름을 클릭합니다.
  3. 추가할 그룹 구성원 유형을 선택합니다. 사용자, 사용자 그룹 또는 외부.

    추가할 수 있는 그룹 구성원의 세 가지 범주에 대한 세 개의 버튼을 강조 표시하는 "User Group" 페이지의 스크린샷입니다. "사용자" - "사용자 그룹" - "외부 사용자".
  4. 추가를 클릭합니다.
  5. 추가할 구성원 하나 이상 옆에 있는 확인란을 선택합니다.
  6. 오른쪽 화살표를 클릭하여 선택한 구성원을 그룹으로 이동합니다.

    확인할 수 있는 "사용 가능한 사용자" 로그인이 왼쪽에 있는 열이 있는 "사용자 그룹 group_a" 팝업 창에 "사용자 추가" 팝업 창의 스크린샷입니다. 오른쪽의 "프로스펙티브(Prospective)" 목록에 사용자를 추가하려면 클릭할 수 있는 오른쪽 화살표가 있습니다.
  7. Add(추가) 를 클릭하여 확인합니다.

20.6. 웹 UI를 사용하여 IdM 사용자 그룹에 멤버 관리자로 사용자 또는 그룹 추가

웹 UI를 사용하여 IdM 사용자 그룹에 사용자 또는 그룹을 멤버 관리자로 추가하려면 다음 절차를 따르십시오. 멤버 관리자는 IdM 사용자 그룹에 사용자 또는 그룹을 추가할 수 있지만 그룹의 특성을 변경할 수는 없습니다.

사전 요구 사항

  • IdM 웹 UI에 로그인되어 있습니다.
  • 멤버 관리자로 추가하려는 사용자 또는 그룹의 이름과 관리하려는 그룹의 이름이 있어야 합니다.

절차

  1. ID → 그룹을 클릭하고 왼쪽 사이드바 에서 사용자 그룹을 선택합니다.
  2. 그룹의 이름을 클릭합니다.
  3. 추가할 그룹 멤버 관리자 유형을 선택합니다. 사용자 또는 사용자 그룹.

    그룹 추가 멤버 관리자
  4. 추가를 클릭합니다.
  5. 추가할 구성원 하나 이상 옆에 있는 확인란을 선택합니다.
  6. 오른쪽 화살표를 클릭하여 선택한 구성원을 그룹으로 이동합니다.

    멤버 관리자 추가 사용자
  7. Add(추가) 를 클릭하여 확인합니다.
참고

사용자 그룹에 멤버 관리자를 추가한 후 업데이트에 Identity Management 환경의 모든 클라이언트에 분배하는 데 다소 시간이 걸릴 수 있습니다.

검증 단계

  • 새로 추가된 사용자 또는 사용자 그룹이 사용자 또는 사용자 그룹의 멤버 관리자 목록에 추가되었는지 확인합니다.

    그룹 멤버 관리자 추가

추가 리소스

  • 자세한 내용은 ipa group-add-member-manager --help 를 참조하십시오.

20.7. IdM 웹 UI를 사용하여 그룹 구성원 보기

IdM 웹 UI를 사용하여 그룹의 멤버를 보려면 다음 절차를 따르십시오. 직접 및 간접 그룹 구성원을 모두 볼 수 있습니다. 자세한 내용은 직접 및 간접 그룹 구성원을 참조하십시오.

사전 요구 사항

  • IdM 웹 UI에 로그인되어 있습니다.

절차

  1. ID → 그룹을 선택합니다.
  2. 왼쪽 사이드바에서 User Groups 를 선택합니다.
  3. 보려는 그룹의 이름을 클릭합니다.
  4. Direct MembershipIndirect Membership 간에 전환합니다.

    "실패 표시" 옆의 "Direct Membership(직접 멤버십)" 및 "Indirect Membership(비디렉션)" 옵션 옆에 있는 RAIDial 버튼을 보여주는 스크린샷입니다.

20.8. IdM 웹 UI를 사용하여 사용자 그룹에서 멤버 제거

IdM Web UI를 사용하여 사용자 그룹에서 멤버를 제거하려면 다음 절차를 따르십시오.

사전 요구 사항

  • IdM 웹 UI에 로그인되어 있습니다.

절차

  1. ID → 그룹을 클릭하고 왼쪽 사이드바 에서 사용자 그룹을 선택합니다.
  2. 그룹의 이름을 클릭합니다.
  3. 삭제할 그룹 구성원 유형을 선택합니다. 사용자, 사용자 그룹 또는 외부.

    추가할 수 있는 그룹 구성원의 세 가지 범주에 대한 세 개의 버튼을 강조 표시하는 "User Group" 페이지의 스크린샷입니다. "사용자" - "사용자 그룹" - "외부 사용자".
  4. 제거할 멤버 옆에 있는 확인란을 선택합니다.
  5. 삭제를 클릭합니다.
  6. Delete(삭제) 를 클릭하여 확인합니다.

20.9. Web UI를 사용하여 IdM 사용자 그룹에서 멤버 관리자로 사용자 또는 그룹 제거

웹 UI를 사용하여 IdM 사용자 그룹에서 멤버 관리자로 사용자 또는 그룹을 제거하려면 다음 절차를 따르십시오. 멤버 관리자는 IdM 사용자 그룹에서 사용자 또는 그룹을 제거할 수 있지만 그룹의 특성을 변경할 수는 없습니다.

사전 요구 사항

  • IdM 웹 UI에 로그인되어 있습니다.
  • 제거 중인 기존 멤버 관리자 사용자 또는 그룹의 이름과 관리 중인 그룹의 이름이 있어야 합니다.

절차

  1. ID → 그룹을 클릭하고 왼쪽 사이드바 에서 사용자 그룹을 선택합니다.
  2. 그룹의 이름을 클릭합니다.
  3. 삭제할 멤버 관리자 유형을 선택합니다. 사용자 또는 사용자 그룹.

    그룹 추가 멤버 관리자
  4. 제거할 멤버 관리자 옆의 확인란을 선택합니다.
  5. 삭제를 클릭합니다.
  6. Delete(삭제) 를 클릭하여 확인합니다.
참고

사용자 그룹에서 멤버 관리자를 제거한 후 업데이트에 Identity Management 환경의 모든 클라이언트에 분배하는 데 다소 시간이 걸릴 수 있습니다.

검증 단계

  • 사용자 또는 사용자 그룹의 멤버 관리자 목록에서 사용자 또는 사용자 그룹이 제거되었는지 확인합니다.

    그룹 멤버 관리자 제거

추가 리소스

  • 자세한 내용은 ipa group-add-member-manager --help 를 참조하십시오.

21장. Ansible 플레이북을 사용하여 사용자 그룹 관리

이 섹션에서는 Ansible 플레이북을 사용한 사용자 그룹 관리에 대해 소개합니다.

사용자 그룹은 공통 권한, 암호 정책 및 기타 특성을 가진 사용자 집합입니다.

IdM(Identity Management)의 사용자 그룹은 다음을 포함할 수 있습니다.

  • IdM 사용자
  • 기타 IdM 사용자 그룹
  • 외부 사용자 - IdM 외부에 존재하는 사용자

섹션에는 다음 주제가 포함됩니다.

21.1. IdM의 다양한 그룹 유형

IdM은 다음과 같은 유형의 그룹을 지원합니다.

POSIX 그룹(기본값)

POSIX 그룹은 구성원에 대해 Linux POSIX 특성을 지원합니다. Active Directory와 상호 작용하는 그룹은 POSIX 특성을 사용할 수 없습니다.

POSIX 속성은 사용자를 별도의 엔터티로 식별합니다. 사용자와 관련된 POSIX 속성의 예로는 사용자 번호(UID)인 uidNumber 와 그룹 번호(GID)인 gidNumber 가 있습니다.

postIX 이외의 그룹

POST 이외의 그룹은 POSIX 특성을 지원하지 않습니다. 예를 들어, 이러한 그룹에는 GID가 정의되어 있지 않습니다.

이 유형의 그룹의 모든 멤버는 IdM 도메인에 속해야 합니다.

외부 그룹

외부 그룹을 사용하여 IdM 도메인 외부의 ID 저장소에 있는 그룹 구성원을 추가합니다(예:).

  • 로컬 시스템
  • Active Directory 도메인
  • 디렉터리 서비스

외부 그룹은 POSIX 특성을 지원하지 않습니다. 예를 들어, 이러한 그룹에는 GID가 정의되어 있지 않습니다.

표 21.1. 기본적으로 생성된 사용자 그룹

그룹 이름기본 그룹 멤버

ipausers

모든 IdM 사용자

admins

기본 admin 사용자를 포함하여 관리 권한이 있는 사용자

편집기

이는 더 이상 특수 권한이 없는 레거시 그룹입니다.

신뢰 관리자

Active Directory 신뢰 관리를 위한 권한이 있는 사용자

사용자를 사용자 그룹에 추가하면 사용자에게 그룹과 관련된 권한 및 정책이 부여됩니다. 예를 들어 사용자에게 관리 권한을 부여하려면 사용자를 admins 그룹에 추가합니다.

주의

admins 그룹을 삭제하지 마십시오. admins 는 IdM에 필요한 사전 정의된 그룹이므로 이 작업으로 인해 특정 명령에 문제가 발생합니다.

또한 IdM에서 새 사용자가 생성될 때마다 IdM은 기본적으로 사용자 개인 그룹을 생성합니다. 개인 그룹에 대한 자세한 내용은 개인 그룹이 없는 사용자 추가를 참조하십시오.

21.2. 직접 및 간접 그룹 구성원

IdM의 사용자 그룹 속성은 직접 및 간접 구성원 모두에 적용됩니다. B 그룹이 A 그룹의 구성원이면 B 그룹의 모든 사용자는 A 그룹의 간접 구성원으로 간주됩니다.

예를 들어 다음 다이어그램에서 다음을 수행합니다.

  • User 1 및 User 2는 A 그룹의 직접 구성원입니다.
  • User 3, User 4 및 User 5는 A 그룹의 간접 구성원입니다.

그림 21.1. 직접 및 간접 그룹 멤버십

그룹 A(사용자 2명) 및 그룹 B(사용자 3명 포함)가 포함된 차트. B 그룹은 A 그룹에 중첩되어 있으므로 A 그룹에는 총 5명의 사용자가 포함됩니다.

사용자 그룹 A에 대한 암호 정책을 설정하면 이 정책은 사용자 그룹 B의 모든 사용자에게도 적용됩니다.

21.3. Ansible Playbook을 사용하여 IdM 그룹 및 그룹 구성원이 있는지 확인

다음 절차에서는 사용자 및 사용자 그룹 모두 Ansible 플레이북을 사용하여 IdM 그룹 및 그룹 구성원이 있는지 확인하는 방법을 설명합니다.

사전 요구 사항

  • IdM 관리자 암호를 알고 있습니다.
  • 다음 요구 사항을 충족하도록 Ansible 제어 노드를 구성했습니다.

    • Ansible 버전 2.14 이상을 사용하고 있습니다.
    • Ansible 컨트롤러에 ansible-freeipa 패키지가 설치되어 있습니다.
    • 이 예제에서는 ~/MyPlaybook/ 디렉터리에서 IdM 서버의 FQDN(정규화된 도메인 이름)을 사용하여 Ansible 인벤토리 파일을 생성했다고 가정합니다.
    • 이 예제에서는 secret.yml Ansible 자격 증명 모음이 ipaadmin_password 를 저장하는 것으로 가정합니다.
  • Ansible 플레이북에서 참조하려는 사용자는 IdM에 있습니다. Ansible을 사용하여 사용자가 있는지 확인하는 방법에 대한 자세한 내용은 Ansible 플레이북을 사용하여 사용자 계정 관리를 참조하십시오.

절차

  1. 인벤토리 파일(예: inventory.file )을 생성하고 여기에 ipaserver 를 정의합니다.

    [ipaserver]
    server.idm.example.com
  2. 필요한 사용자 및 그룹 정보를 사용하여 Ansible 플레이북 파일을 생성합니다.

    ---
    - name: Playbook to handle groups
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Create group ops with gid 1234
        ipagroup:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: ops
          gidnumber: 1234
    
      - name: Create group sysops
        ipagroup:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: sysops
          user:
          - idm_user
    
      - name: Create group appops
        ipagroup:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: appops
    
      - name: Add group members sysops and appops to group ops
        ipagroup:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: ops
          group:
          - sysops
          - appops
  3. 플레이북을 실행합니다.

    $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-group-members.yml

검증 단계

ipa group-show 명령을 사용하여 ops 그룹에 sysopsappops 가 직접 멤버로 포함되고 idm_user 가 간접 구성원으로 포함되어 있는지 확인할 수 있습니다.

  1. 관리자로 ipaserver 에 로그인합니다.

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. ops 에 대한 정보를 표시합니다 :

    ipaserver]$ ipa group-show ops
      Group name: ops
      GID: 1234
      Member groups: sysops, appops
      Indirect Member users: idm_user

    appopssysops 그룹 - idm_user 사용자를 포함하는 후자는 IdM에 있습니다.

추가 리소스

  • /usr/share/doc/ansible-freeipa/README-group.md Markdown 파일을 참조하십시오.

21.4. Ansible을 사용하여 AD 사용자가 IdM 관리 가능

Ansible 플레이북을 사용하여 사용자 ID 덮어쓰기가 IdM(Identity Management) 그룹에 있는지 확인하려면 다음 절차를 따르십시오. AD에 대한 트러스트를 설정한 후 기본 신뢰 보기에서 만든 AD(Active Directory) 사용자를 재정의합니다. 플레이북을 실행하면 AD 사용자와 같은 AD 사용자가 두 개의 다른 계정과 암호 없이 IdM을 완전히 관리할 수 있습니다.

사전 요구 사항

  • IdM 관리자 암호를 알고 있습니다.
  • AD에 대한 트러스트를 설치했습니다.
  • AD 사용자의 사용자 ID 재정의는 IdM에 이미 있습니다. 그렇지 않은 경우 ipa idoverrideuser-add 'default trust view' ad_user@ad.example.com 명령을 사용하여 생성합니다.
  • 사용자 ID 재정의를 추가하는 그룹이 IdM에 이미 있습니다.
  • IdM 이상의 4.8.7 버전을 사용하고 있습니다. 서버에 설치된 IdM 버전을 보려면 ipa --version 을 입력합니다.
  • 다음 요구 사항을 충족하도록 Ansible 제어 노드를 구성했습니다.

    • Ansible 버전 2.14 이상을 사용하고 있습니다.
    • Ansible 컨트롤러에 ansible-freeipa 패키지가 설치되어 있습니다.
    • 이 예제에서는 ~/MyPlaybook/ 디렉터리에서 IdM 서버의 FQDN(정규화된 도메인 이름)을 사용하여 Ansible 인벤토리 파일을 생성했다고 가정합니다.
    • 이 예제에서는 secret.yml Ansible 자격 증명 모음이 ipaadmin_password 를 저장하는 것으로 가정합니다.

절차

  1. ~/MyPlaybooks/ 디렉터리로 이동합니다.

    $ cd ~/MyPlaybooks/
  2. 다음 콘텐츠를 사용하여 add-useridoverride-to-group.yml 플레이북을 생성합니다.

    ---
    - name: Playbook to ensure presence of users in a group
      hosts: ipaserver
    
    
      - name: Ensure the ad_user@ad.example.com user ID override is a member of the admins group:
        ipagroup:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: admins
          idoverrideuser:
          - ad_user@ad.example.com

    예에서는 다음을 수행합니다.

    • Secret123은 IdM 관리자 암호입니다.
    • 관리자는 ad_user@ad.example.com ID 덮어쓰기를 추가하는 IdM POSIX 그룹의 이름입니다. 이 그룹의 멤버는 전체 관리자 권한이 있습니다.
    • ad_user@ad.example.com 은 AD 관리자의 사용자 ID 덮어쓰기입니다. 사용자가 신뢰가 설정된 AD 도메인에 저장됩니다.
  3. 파일을 저장합니다.
  4. Ansible 플레이북을 실행합니다. Playbook 파일, secret.yml 파일을 보호하는 암호를 저장하는 파일, 인벤토리 파일을 지정합니다.

    $ ansible-playbook --vault-password-file=password_file -v -i inventory add-useridoverride-to-group.yml

추가 리소스

21.5. Ansible Playbook을 사용하여 IdM 사용자 그룹에 멤버 관리자가 있는지 확인

다음 절차에서는 Ansible 플레이북을 사용하여 사용자 및 사용자 그룹 모두 IdM 멤버 관리자가 있는지 확인하는 방법을 설명합니다.

사전 요구 사항

  • IdM 관리자 암호를 알고 있습니다.
  • 다음 요구 사항을 충족하도록 Ansible 제어 노드를 구성했습니다.

    • Ansible 버전 2.14 이상을 사용하고 있습니다.
    • Ansible 컨트롤러에 ansible-freeipa 패키지가 설치되어 있습니다.
    • 이 예제에서는 ~/MyPlaybook/ 디렉터리에서 IdM 서버의 FQDN(정규화된 도메인 이름)을 사용하여 Ansible 인벤토리 파일을 생성했다고 가정합니다.
    • 이 예제에서는 secret.yml Ansible 자격 증명 모음이 ipaadmin_password 를 저장하는 것으로 가정합니다.
  • 멤버 관리자로 추가하려는 사용자 또는 그룹의 이름과 관리하려는 그룹의 이름이 있어야 합니다.

절차

  1. 인벤토리 파일(예: inventory.file )을 생성하고 여기에 ipaserver 를 정의합니다.

    [ipaserver]
    server.idm.example.com
  2. 필요한 사용자 및 그룹 구성원 관리 정보를 사용하여 Ansible 플레이북 파일을 생성합니다.

    ---
    - name: Playbook to handle membership management
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Ensure user test is present for group_a
        ipagroup:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: group_a
          membermanager_user: test
    
      - name: Ensure group_admins is present for group_a
        ipagroup:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: group_a
          membermanager_group: group_admins
  3. 플레이북을 실행합니다.

    $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-member-managers-user-groups.yml

검증 단계

ipa group-show 명령을 사용하여 group_a 그룹에 test 가 구성원 관리자로 포함되어 있고 group_adminsgroup_a 의 멤버 관리자인지 확인할 수 있습니다.

  1. 관리자로 ipaserver 에 로그인합니다.

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. managergroup1 에 대한 정보 표시 :

    ipaserver]$ ipa group-show group_a
      Group name: group_a
      GID: 1133400009
      Membership managed by groups: group_admins
      Membership managed by users: test

추가 리소스

  • ipa host-add-member-manager --help를 참조하십시오.
  • ipa 도움말 페이지를 참조하십시오.

21.6. Ansible Playbook을 사용하여 IdM 사용자 그룹에 멤버 관리자가 없는지 확인합니다.

다음 절차에서는 Ansible 플레이북을 사용하여 IdM 멤버 관리자(사용자 및 사용자 그룹 모두)가 없는지 확인하는 방법을 설명합니다.

사전 요구 사항

  • IdM 관리자 암호를 알고 있습니다.
  • 다음 요구 사항을 충족하도록 Ansible 제어 노드를 구성했습니다.

    • Ansible 버전 2.14 이상을 사용하고 있습니다.
    • Ansible 컨트롤러에 ansible-freeipa 패키지가 설치되어 있습니다.
    • 이 예제에서는 ~/MyPlaybook/ 디렉터리에서 IdM 서버의 FQDN(정규화된 도메인 이름)을 사용하여 Ansible 인벤토리 파일을 생성했다고 가정합니다.
    • 이 예제에서는 secret.yml Ansible 자격 증명 모음이 ipaadmin_password 를 저장하는 것으로 가정합니다.
  • 제거 중인 기존 멤버 관리자 사용자 또는 그룹의 이름과 관리 중인 그룹의 이름이 있어야 합니다.

절차

  1. 인벤토리 파일(예: inventory.file )을 생성하고 여기에 ipaserver 를 정의합니다.

    [ipaserver]
    server.idm.example.com
  2. 필요한 사용자 및 그룹 구성원 관리 정보를 사용하여 Ansible 플레이북 파일을 생성합니다.

    ---
    - name: Playbook to handle membership management
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Ensure member manager user and group members are absent for group_a
        ipagroup:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: group_a
          membermanager_user: test
          membermanager_group: group_admins
          action: member
          state: absent
  3. 플레이북을 실행합니다.

    $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-member-managers-are-absent.yml

검증 단계

ipa group-show 명령을 사용하여 group_a 그룹에 test 가 구성원 관리자로 포함되어 있지 않은지, group_adminsgroup_a 의 멤버 관리자로 포함되어 있지 않은지 확인할 수 있습니다.

  1. 관리자로 ipaserver 에 로그인합니다.

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. group_a에 대한 정보를 표시합니다.

    ipaserver]$ ipa group-show group_a
      Group name: group_a
      GID: 1133400009

추가 리소스

  • ipa host-remove-member-manager --help를 참조하십시오.
  • ipa 도움말 페이지를 참조하십시오.

22장. IdM CLI를 사용하여 그룹 멤버십 자동화

자동 그룹 멤버십을 사용하면 속성에 따라 자동으로 사용자와 호스트를 그룹에 할당할 수 있습니다. 예를 들면 다음을 수행할 수 있습니다.

  • 직원 관리자, 위치 또는 기타 특성에 따라 직원의 사용자 항목을 그룹으로 나눕니다.
  • 클래스, 위치 또는 기타 특성을 기반으로 호스트를 나눕니다.
  • 모든 사용자 또는 모든 호스트를 하나의 글로벌 그룹에 추가합니다.

이 장에서는 다음 주제를 다룹니다.

22.1. 자동 그룹 멤버십의 이점

사용자에 대한 자동 멤버십을 사용하면 다음을 수행할 수 있습니다.

  • 그룹 멤버십을 수동으로 관리하는 오버헤드 감소

    더 이상 모든 사용자와 호스트를 수동으로 그룹에 할당할 필요가 없습니다.

  • 사용자 및 호스트 관리의 일관성 개선

    사용자와 호스트는 엄격하게 정의되고 자동으로 평가된 기준에 따라 그룹에 할당됩니다.

  • 그룹 기반 설정 관리 간소화

    그룹에 대해 다양한 설정이 정의되고 개별 그룹 구성원에 적용됩니다(예: sudo 규칙, 자동 마운트 또는 액세스 제어). 사용자와 호스트를 그룹에 추가하면 이러한 설정을 자동으로 관리하기가 쉬워집니다.

22.2. 자동 구성원 규칙

자동 그룹 멤버십을 구성할 때 관리자는 automember 규칙을 정의합니다. automember 규칙은 특정 사용자 또는 호스트 대상 그룹에 적용됩니다. 한 번에 둘 이상의 그룹에 적용할 수 없습니다.

규칙을 생성한 후에는 관리자가 조건을 추가합니다. 대상 그룹에서 포함하거나 제외되는 사용자 또는 호스트를 지정합니다.

  • 포함 조건

    사용자 또는 호스트 항목이 포함 조건을 충족하면 대상 그룹에 포함됩니다.

  • 배타적 조건

    사용자 또는 호스트 항목이 독점 조건을 충족하면 대상 그룹에 포함되지 않습니다.

조건은 Perl 호환 정규 표현식(PCRE) 형식으로 정규 표현식으로 지정됩니다. PCRE에 대한 자세한 내용은 pcresyntax Cryostat 매뉴얼 페이지를 참조하십시오.

참고

IdM은 포함 조건보다 먼저 배타적 조건을 평가합니다. 충돌이 발생하는 경우 독점 조건이 포함된 조건보다 우선합니다.

automember 규칙은 향후 생성된 모든 항목에 적용됩니다. 이러한 항목은 지정된 대상 그룹에 자동으로 추가됩니다. 항목이 여러 automember 규칙에 지정된 조건을 충족하면 모든 해당 그룹에 추가됩니다.

기존 항목은 새 규칙의 영향을 받지 않습니다. 기존 항목을 변경하려면 IdM CLI를 사용하여 기존 항목에 자동 구성원 규칙 적용을 참조하십시오.

22.3. IdM CLI를 사용하여 자동 구성원 규칙 추가

IdM CLI를 사용하여 automember 규칙을 추가하려면 다음 절차를 따르십시오. 자동 구성원 규칙에 대한 자세한 내용은 Automember rules 을 참조하십시오.

automember 규칙을 추가한 후에는 automember 규칙에 조건 추가에 설명된 절차를 사용하여 조건을 추가할 수 있습니다.

참고

기존 항목은 새 규칙의 영향을 받지 않습니다. 기존 항목을 변경하려면 IdM CLI를 사용하여 기존 항목에 자동 구성원 규칙 적용을 참조하십시오.

사전 요구 사항

절차

  1. ipa automember-add 명령을 입력하여 automember 규칙을 추가합니다.
  2. 메시지가 표시되면 다음을 지정합니다.

    • 자동 구성원 규칙. 대상 그룹 이름입니다.
    • 그룹화 유형. 이는 규칙에서 사용자 그룹을 대상으로 하는지 또는 호스트 그룹을 대상으로 하는지 여부를 지정합니다. 사용자 그룹을 대상으로 지정하려면 그룹을 입력합니다. 호스트 그룹을 대상으로 지정하려면 hostgroup 을 입력합니다.

    예를 들어 user_group 이라는 사용자 그룹에 대한 자동 구성원 규칙을 추가하려면 다음을 수행합니다.

    $ ipa automember-add
    Automember Rule: user_group
    Grouping Type: group
    --------------------------------
    Added automember rule "user_group"
    --------------------------------
        Automember Rule: user_group

22.4. IdM CLI를 사용하여 자동 구성원 규칙에 조건 추가

자동 멤버 규칙을 구성한 후 IdM CLI를 사용하여 해당 automember 규칙에 조건을 추가할 수 있습니다. 자동 구성원 규칙에 대한 자세한 내용은 Automember rules 을 참조하십시오.

사전 요구 사항

절차

  1. ipa automember-add-condition 명령을 사용하여 하나 이상의 포함 또는 독점적 조건을 정의합니다.
  2. 메시지가 표시되면 다음을 지정합니다.

    • 자동 구성원 규칙. 대상 규칙 이름입니다. 자세한 내용은 자동 구성원 규칙을 참조하십시오.
    • 특성 키. 이는 필터를 적용할 항목 속성을 지정합니다. 예를 들어 사용자를 위한 uid.
    • 그룹화 유형. 이는 규칙에서 사용자 그룹을 대상으로 하는지 또는 호스트 그룹을 대상으로 하는지 여부를 지정합니다. 사용자 그룹을 대상으로 지정하려면 그룹을 입력합니다. 호스트 그룹을 대상으로 지정하려면 hostgroup 을 입력합니다.
    • 포함 정규식배타적 정규식. 이러한 조건은 하나 이상의 조건을 정규 표현식으로 지정합니다. 하나의 조건만 지정하려면 다른 조건을 입력하라는 메시지가 표시되면 Enter 키를 누릅니다.

    예를 들어 다음 조건은 사용자 로그인 특성(uid)에서 임의의 값(.*)을 가진 모든 사용자를 대상으로합니다.

    $ ipa automember-add-condition
    Automember Rule: user_group
    Attribute Key: uid
    Grouping Type: group
    [Inclusive Regex]: .*
    [Exclusive Regex]:
    ----------------------------------
    Added condition(s) to "user_group"
    ----------------------------------
      Automember Rule: user_group
      Inclusive Regex: uid=.*
    ----------------------------
    Number of conditions added 1
    ----------------------------

    또 다른 예로 automembership 규칙을 사용하여 AD(Active Directory)에서 동기화된 모든 Windows 사용자를 대상으로 할 수 있습니다. 이를 위해 모든 AD 사용자가 공유하는 objects Class 특성 에서 모든 사용자를 대상으로 하는 모든 사용자를 대상으로 하는 조건을 생성합니다.

    $ ipa automember-add-condition
    Automember Rule: ad_users
    Attribute Key: objectclass
    Grouping Type: group
    [Inclusive Regex]: ntUser
    [Exclusive Regex]:
    -------------------------------------
    Added condition(s) to "ad_users"
    -------------------------------------
      Automember Rule: ad_users
      Inclusive Regex: objectclass=ntUser
    ----------------------------
    Number of conditions added 1
    ----------------------------

22.5. IdM CLI를 사용하여 기존 자동 구성원 규칙 보기

IdM CLI를 사용하여 기존 automember 규칙을 보려면 다음 절차를 따르십시오.

사전 요구 사항

절차

  1. ipa automember-find 명령을 입력합니다.
  2. 메시지가 표시되면 그룹 유형을 지정합니다.

    • 사용자 그룹을 대상으로 지정하려면 그룹을 입력합니다.
    • 호스트 그룹을 대상으로 지정하려면 hostgroup 을 입력합니다.

      예를 들면 다음과 같습니다.

    $ ipa automember-find
    Grouping Type: group
    ---------------
    1 rules matched
    ---------------
      Automember Rule: user_group
      Inclusive Regex: uid=.*
    ----------------------------
    Number of entries returned 1
    ----------------------------

22.6. IdM CLI를 사용하여 자동 구성원 규칙 삭제

IdM CLI를 사용하여 automember 규칙을 삭제하려면 다음 절차를 따르십시오.

자동 구성원 규칙을 삭제하면 규칙과 연결된 모든 조건도 삭제됩니다. 규칙에서 특정 조건만 제거하려면 IdM CLI를 사용하여 automember 규칙에서 조건 제거를 참조하십시오.

사전 요구 사항

절차

  1. ipa automember-del 명령을 입력합니다.
  2. 메시지가 표시되면 다음을 지정합니다.

    • 자동 구성원 규칙. 삭제할 규칙입니다.
    • 규칙 그룹화. 이는 삭제할 규칙이 사용자 그룹 또는 호스트 그룹에 대한지 여부를 지정합니다. 그룹 또는 호스트 그룹을 입력합니다.

22.7. IdM CLI를 사용하여 automember 규칙에서 조건 제거

다음 절차에 따라 자동 구성원 규칙에서 특정 조건을 제거합니다.

사전 요구 사항

절차

  1. ipa automember-remove-condition 명령을 입력합니다.
  2. 메시지가 표시되면 다음을 지정합니다.

    • 자동 구성원 규칙. 조건을 제거할 규칙의 이름입니다.
    • 특성 키. 대상 항목 속성입니다. 예를 들어 사용자를 위한 uid.
    • 그룹화 유형. 이는 삭제할 조건이 사용자 그룹 또는 호스트 그룹에 대한지 여부를 지정합니다. 그룹 또는 호스트 그룹을 입력합니다.
    • 포함 정규식배타적 정규식. 이러한 조건은 제거할 조건을 지정합니다. 하나의 조건만 지정하려면 다른 조건을 입력하라는 메시지가 표시되면 Enter 키를 누릅니다.

      예를 들면 다음과 같습니다.

    $ ipa automember-remove-condition
    Automember Rule: user_group
    Attribute Key: uid
    Grouping Type: group
    [Inclusive Regex]: .*
    [Exclusive Regex]:
    -----------------------------------
    Removed condition(s) from "user_group"
    -----------------------------------
      Automember Rule: user_group
    ------------------------------
    Number of conditions removed 1
    ------------------------------

22.8. IdM CLI를 사용하여 기존 항목에 자동 구성원 규칙 적용

automember 규칙은 규칙이 추가된 후 생성된 사용자 및 호스트 항목에 자동으로 적용됩니다. 규칙을 추가하기 전에 존재하는 항목에 소급으로 적용되지 않습니다.

이전에 추가한 항목에 자동 구성원 규칙을 적용하려면 자동 멤버십을 수동으로 다시 빌드해야 합니다. 자동 멤버십을 다시 빌드하면 기존의 모든 자동 구성원 규칙을 다시 평가하여 모든 사용자 또는 호스트 항목 또는 특정 항목에 적용합니다.

참고

자동 멤버십을 다시 빌드 해도 항목이 더 이상 그룹의 포함 조건과 일치하지 않는 경우에도 그룹에서 사용자 또는 호스트 항목이 제거되지 않습니다. 수동으로 제거하려면 IdM CLI를 사용하여 사용자 그룹에서 멤버 제거를 참조하거나 CLI를 사용하여 IdM 호스트 그룹 멤버 제거를 참조하십시오.

사전 요구 사항

절차

  • 자동 멤버십을 다시 빌드하려면 ipa automember-rebuild 명령을 입력합니다. 다음 옵션을 사용하여 대상 항목을 지정합니다.

    • 모든 사용자에 대해 자동 멤버십을 다시 빌드하려면 --type=group 옵션을 사용합니다.

      $ ipa automember-rebuild --type=group
      --------------------------------------------------------
      Automember rebuild task finished. Processed (9) entries.
      --------------------------------------------------------
    • 모든 호스트에 대한 자동 멤버십을 다시 빌드하려면 --type=hostgroup 옵션을 사용합니다.
    • 지정된 사용자 또는 사용자의 자동 멤버십을 다시 빌드하려면 --users=target_user 옵션을 사용합니다.

      $ ipa automember-rebuild --users=target_user1 --users=target_user2
      --------------------------------------------------------
      Automember rebuild task finished. Processed (2) entries.
      --------------------------------------------------------
    • 지정된 호스트 또는 호스트에 대한 자동 멤버십을 다시 빌드하려면 --hosts=client.idm.example.com 옵션을 사용합니다.

22.9. IdM CLI를 사용하여 기본 자동 구성원 그룹 구성

기본 자동 구성원 그룹을 구성하면 automember 규칙과 일치하지 않는 새 사용자 또는 호스트 항목이 이 기본 그룹에 자동으로 추가됩니다.

사전 요구 사항

절차

  1. ipa automember-default-group-set 명령을 입력하여 기본 automember 그룹을 구성합니다.
  2. 메시지가 표시되면 다음을 지정합니다.

    • 대상 그룹 이름을 지정하는 default(fallback) 그룹입니다.
    • 타겟이 사용자 그룹인지 또는 호스트 그룹인지 여부를 지정하는 유형 그룹화입니다. 사용자 그룹을 대상으로 지정하려면 그룹을 입력합니다. 호스트 그룹을 대상으로 지정하려면 hostgroup 을 입력합니다.

      예를 들면 다음과 같습니다.

      $ ipa automember-default-group-set
      Default (fallback) Group: default_user_group
      Grouping Type: group
      ---------------------------------------------------
      Set default (fallback) group for automember "default_user_group"
      ---------------------------------------------------
        Default (fallback) Group: cn=default_user_group,cn=groups,cn=accounts,dc=example,dc=com
    참고

    현재 기본 automember 그룹을 제거하려면 ipa automember-default-group-remove 명령을 입력합니다.

검증 단계

  • 그룹이 올바르게 설정되었는지 확인하려면 ipa automember-default-group-show 명령을 입력합니다. 명령은 현재 기본 automember 그룹을 표시합니다. 예를 들면 다음과 같습니다.

    $ ipa automember-default-group-show
    Grouping Type: group
      Default (fallback) Group: cn=default_user_group,cn=groups,cn=accounts,dc=example,dc=com

23장. IdM 웹 UI를 사용하여 그룹 멤버십 자동화

자동 그룹 멤버십을 사용하면 속성에 따라 자동으로 사용자와 호스트를 그룹에 할당할 수 있습니다. 예를 들면 다음을 수행할 수 있습니다.

  • 직원 관리자, 위치 또는 기타 특성에 따라 직원의 사용자 항목을 그룹으로 나눕니다.
  • 클래스, 위치 또는 기타 특성을 기반으로 호스트를 나눕니다.
  • 모든 사용자 또는 모든 호스트를 하나의 글로벌 그룹에 추가합니다.

이 장에서는 다음 주제를 다룹니다.

23.1. 자동 그룹 멤버십의 이점

사용자에 대한 자동 멤버십을 사용하면 다음을 수행할 수 있습니다.

  • 그룹 멤버십을 수동으로 관리하는 오버헤드 감소

    더 이상 모든 사용자와 호스트를 수동으로 그룹에 할당할 필요가 없습니다.

  • 사용자 및 호스트 관리의 일관성 개선

    사용자와 호스트는 엄격하게 정의되고 자동으로 평가된 기준에 따라 그룹에 할당됩니다.

  • 그룹 기반 설정 관리 간소화

    그룹에 대해 다양한 설정이 정의되고 개별 그룹 구성원에 적용됩니다(예: sudo 규칙, 자동 마운트 또는 액세스 제어). 사용자와 호스트를 그룹에 추가하면 이러한 설정을 자동으로 관리하기가 쉬워집니다.

23.2. 자동 구성원 규칙

자동 그룹 멤버십을 구성할 때 관리자는 automember 규칙을 정의합니다. automember 규칙은 특정 사용자 또는 호스트 대상 그룹에 적용됩니다. 한 번에 둘 이상의 그룹에 적용할 수 없습니다.

규칙을 생성한 후에는 관리자가 조건을 추가합니다. 대상 그룹에서 포함하거나 제외되는 사용자 또는 호스트를 지정합니다.

  • 포함 조건

    사용자 또는 호스트 항목이 포함 조건을 충족하면 대상 그룹에 포함됩니다.

  • 배타적 조건

    사용자 또는 호스트 항목이 독점 조건을 충족하면 대상 그룹에 포함되지 않습니다.

조건은 Perl 호환 정규 표현식(PCRE) 형식으로 정규 표현식으로 지정됩니다. PCRE에 대한 자세한 내용은 pcresyntax Cryostat 매뉴얼 페이지를 참조하십시오.

참고

IdM은 포함 조건보다 먼저 배타적 조건을 평가합니다. 충돌이 발생하는 경우 독점 조건이 포함된 조건보다 우선합니다.

automember 규칙은 향후 생성된 모든 항목에 적용됩니다. 이러한 항목은 지정된 대상 그룹에 자동으로 추가됩니다. 항목이 여러 automember 규칙에 지정된 조건을 충족하면 모든 해당 그룹에 추가됩니다.

기존 항목은 새 규칙의 영향을 받지 않습니다. 기존 항목을 변경하려면 IdM 웹 UI를 사용하여 기존 항목에 자동 구성원 규칙 적용을 참조하십시오.

23.3. IdM 웹 UI를 사용하여 자동 구성원 규칙 추가

IdM 웹 UI를 사용하여 automember 규칙을 추가하려면 다음 절차를 따르십시오. 자동 구성원 규칙에 대한 자세한 내용은 Automember rules 을 참조하십시오.

참고

기존 항목은 새 규칙의 영향을 받지 않습니다. 기존 항목을 변경하려면 IdM 웹 UI를 사용하여 기존 항목에 자동 구성원 규칙 적용을 참조하십시오.

사전 요구 사항

  • IdM 웹 UI에 로그인되어 있습니다.
  • admins 그룹의 멤버여야 합니다.
  • 새 규칙의 대상 그룹은 IdM에 있습니다.

절차

  1. ID → 자동 구성원을 클릭하고 사용자 그룹 규칙 또는 호스트 그룹 규칙을 선택합니다.
  2. 추가를 클릭합니다.
  3. Automember 규칙 필드에서 규칙이 적용할 그룹을 선택합니다. 대상 그룹 이름입니다.

    이전에 정의한 규칙 중에서 선택할 수 있는 Automember Rule(자동 구성원 규칙)의 드롭다운 필드를 표시하는 "Add Rule(규칙 추가)" 창의 스크린샷입니다.
  4. Add(추가) 를 클릭하여 확인합니다.
  5. 선택 사항: IdM 웹 UI를 사용하여 automember 규칙에 조건 추가에 설명된 절차를 사용하여 새 규칙에 조건을 추가할 수 있습니다.

23.4. IdM 웹 UI를 사용하여 자동 구성원 규칙에 조건 추가

자동 멤버 규칙을 구성한 후 IdM 웹 UI를 사용하여 해당 automember 규칙에 조건을 추가할 수 있습니다. 자동 구성원 규칙에 대한 자세한 내용은 Automember rules 을 참조하십시오.

사전 요구 사항

  • IdM 웹 UI에 로그인되어 있습니다.
  • admins 그룹의 멤버여야 합니다.
  • 대상 규칙은 IdM에 있습니다.

절차

  1. ID → 자동 구성원을 클릭하고 사용자 그룹 규칙 또는 호스트 그룹 규칙을 선택합니다.
  2. 조건을 추가할 규칙을 클릭합니다.
  3. Inclusive (포함) 또는 Exclusive (독점) 섹션에서 Add(추가)를 클릭합니다.

    user_group 규칙의 속성을 표시하는 User 그룹 규칙 페이지의 스크린샷입니다. "Inclusive" 섹션에는 "Attribute" 열과 Attribute "uid"에 대한 항목이 있는 "Expression" 열이 있는 테이블이 있으며 해당 표현식은 ".*"입니다. 맨 아래에는 Attribute 열과 Expression 열이 있는 테이블도 있지만 항목이 없는 Exclusive 섹션이 있습니다.
  4. Attribute (특성) 필드에서 required 속성을 선택합니다(예: uid ).
  5. Expression(표현식 ) 필드에 정규 표현식을 정의합니다.
  6. 추가를 클릭합니다.

    예를 들어 다음 조건은 사용자 ID(uid) 속성에서 임의의 값(.*)을 가진 모든 사용자를 대상으로 합니다.

    "Add Condition into automember" 팝업 창에서 Attribute(uid)의 드롭다운 메뉴와 해당 "Expression"(필수 및 .*)의 필드를 표시합니다. "추가" 버튼은 창의 아래쪽에 있습니다.

23.5. IdM 웹 UI를 사용하여 기존 자동 구성원 규칙 및 조건 보기

IdM 웹 UI를 사용하여 기존 automember 규칙 및 조건을 보려면 다음 절차를 따르십시오.

사전 요구 사항

  • IdM 웹 UI에 로그인되어 있습니다.
  • admins 그룹의 멤버여야 합니다.

절차

  1. ID → 자동 구성원을 클릭하고 사용자 그룹 규칙 또는 호스트 그룹 규칙을 선택하여 해당 자동 구성원 규칙을 확인합니다.
  2. 선택 사항: 규칙을 클릭하여 Inclusive 또는 Exclusive 섹션에서 해당 규칙의 조건을 확인합니다.

    사용자 그룹 규칙 "user_group"의 세부 정보 스크린샷입니다. Automember 규칙의 이름과 "설명"을 표시하는 "일반" 섹션이 있습니다. 아래에는 "특성" 및 "표현식"이라는 레이블이 지정된 항목이 표시된 항목을 표시하는 "통합" 섹션이 있습니다. 이 테이블에는 Attribute로 uid, 표현식으로 .* 항목이 있습니다. 맨 아래에는 "Inclusive"(통합) 테이블의 구조와 일치하는 테이블이 있는 "Exclusive"(확장) 섹션이 있지만 항목이 없습니다.

23.6. IdM 웹 UI를 사용하여 자동 구성원 규칙 삭제

IdM 웹 UI를 사용하여 automember 규칙을 삭제하려면 다음 절차를 따르십시오.

자동 구성원 규칙을 삭제하면 규칙과 연결된 모든 조건도 삭제됩니다. 규칙에서 특정 조건만 제거하려면 IdM 웹 UI를 사용하여 automember 규칙에서 조건 제거를 참조하십시오.

사전 요구 사항

  • IdM 웹 UI에 로그인되어 있습니다.
  • admins 그룹의 멤버여야 합니다.

절차

  1. ID → 자동 구성원을 클릭하고 사용자 그룹 규칙 또는 호스트 그룹 규칙을 선택하여 해당 자동 구성원 규칙을 확인합니다.
  2. 제거할 규칙 옆에 있는 확인란을 선택합니다.
  3. 삭제를 클릭합니다.

    automember 규칙 테이블을 표시하는 "사용자 그룹 규칙" 페이지의 스크린샷입니다. "user_group" 항목의 확인란이 선택되었으며 "Delete"(삭제) 버튼이 강조 표시되었습니다.
  4. Delete(삭제) 를 클릭하여 확인합니다.

23.7. IdM 웹 UI를 사용하여 automember 규칙에서 조건 제거

IdM 웹 UI를 사용하여 automember 규칙에서 특정 조건을 제거하려면 다음 절차를 따르십시오.

사전 요구 사항

  • IdM 웹 UI에 로그인되어 있습니다.
  • admins 그룹의 멤버여야 합니다.

절차

  1. ID → 자동 구성원을 클릭하고 사용자 그룹 규칙 또는 호스트 그룹 규칙을 선택하여 해당 자동 구성원 규칙을 확인합니다.
  2. 규칙을 클릭하여 Inclusive 또는 Exclusive 섹션에서 해당 규칙의 조건을 확인합니다.
  3. 제거할 조건 옆에 있는 확인란을 선택합니다.
  4. 삭제를 클릭합니다.

    "User group rule" 페이지의 스크린샷은 "user_group"에 대한 정보를 표시합니다. "Inclusive"(통합) 섹션의 항목이 선택되어 있으며 "Inclusive"(통합) 섹션과 관련된 "Delete"(삭제) 버튼이 강조 표시됩니다.
  5. Delete(삭제) 를 클릭하여 확인합니다.

23.8. IdM 웹 UI를 사용하여 기존 항목에 자동 구성원 규칙 적용

automember 규칙은 규칙이 추가된 후 생성된 사용자 및 호스트 항목에 자동으로 적용됩니다. 규칙을 추가하기 전에 존재하는 항목에 소급으로 적용되지 않습니다.

이전에 추가한 항목에 자동 구성원 규칙을 적용하려면 자동 멤버십을 수동으로 다시 빌드해야 합니다. 자동 멤버십을 다시 빌드하면 기존의 모든 자동 구성원 규칙을 다시 평가하여 모든 사용자 또는 호스트 항목 또는 특정 항목에 적용합니다.

참고

자동 멤버십을 다시 빌드 해도 항목이 더 이상 그룹의 포함 조건과 일치하지 않는 경우에도 그룹에서 사용자 또는 호스트 항목이 제거되지 않습니다. 수동으로 제거하려면 IdM 웹 UI 를 사용하여 사용자 그룹에서 멤버 제거 또는 IdM 웹 UI 의 호스트 그룹 멤버 제거를 참조하십시오.

23.8.1. 모든 사용자 또는 호스트에 대한 자동 멤버십 다시 빌드

모든 사용자 또는 호스트 항목에 대한 자동 멤버십을 다시 빌드하려면 다음 절차를 따르십시오.

사전 요구 사항

  • IdM 웹 UI에 로그인되어 있습니다.
  • admins 그룹의 멤버여야 합니다.

절차

  1. ID사용자 또는 호스트 를 선택합니다.
  2. 작업자동 멤버십 다시 빌드를 클릭합니다.

    "자동 멤버십 재구축"을 강조 표시하는 스크린샷은 "작업" 드롭다운 메뉴의 옵션입니다.

23.8.2. 단일 사용자 또는 호스트에 대한 자동 멤버십 다시 빌드

특정 사용자 또는 호스트 항목에 대한 자동 멤버십을 다시 빌드하려면 다음 절차를 따르십시오.

사전 요구 사항

  • IdM 웹 UI에 로그인되어 있습니다.
  • admins 그룹의 멤버여야 합니다.

절차

  1. ID사용자 또는 호스트 를 선택합니다.
  2. 필요한 사용자 또는 호스트 이름을 클릭합니다.
  3. 작업자동 멤버십 다시 빌드를 클릭합니다.

    "Actions(작업)" 드롭다운 메뉴의 콘텐츠에 있는 "Rebuild auto membership(자동 멤버십 다시 빌드)" 옵션을 강조 표시하는 스크린샷입니다.

23.9. IdM 웹 UI를 사용하여 기본 사용자 그룹 구성

기본 사용자 그룹을 구성하면 automember 규칙과 일치하지 않는 새 사용자 항목이 이 기본 그룹에 자동으로 추가됩니다.

사전 요구 사항

  • IdM 웹 UI에 로그인되어 있습니다.
  • admins 그룹의 멤버여야 합니다.
  • IdM에 기본값으로 설정할 대상 사용자 그룹이 있습니다.

절차

  1. Identity → Automember 를 클릭하고 사용자 그룹 규칙을 선택합니다.
  2. Default 사용자 그룹 필드에서 기본 사용자 그룹으로 설정할 그룹을 선택합니다.

    기본 사용자 그룹 설정

23.10. IdM 웹 UI를 사용하여 기본 호스트 그룹 구성

기본 호스트 그룹을 구성하면 automember 규칙과 일치하지 않는 새 호스트 항목이 이 기본 그룹에 자동으로 추가됩니다.

사전 요구 사항

  • IdM 웹 UI에 로그인되어 있습니다.
  • admins 그룹의 멤버여야 합니다.
  • IdM에 기본값으로 설정할 대상 호스트 그룹이 있습니다.

절차

  1. ID → 자동 구성원을 클릭하고 호스트 그룹 규칙을 선택합니다.
  2. Default 호스트 그룹 필드에서 기본 호스트 그룹으로 설정할 그룹을 선택합니다.

    기본 호스트 그룹 설정

24장. Ansible을 사용하여 IdM의 그룹 멤버십 자동화

자동 그룹 멤버십을 사용하여 속성에 따라 사용자 및 호스트 사용자 그룹 및 호스트 그룹을 자동으로 할당할 수 있습니다. 예를 들면 다음을 수행할 수 있습니다.

  • 직원의 사용자 항목을 직원의 관리자, 위치, 위치 또는 기타 속성에 따라 그룹으로 나눕니다. 명령줄에서 ipa user-add --help 를 입력하여 모든 속성을 나열할 수 있습니다.
  • 클래스, 위치 또는 기타 속성에 따라 호스트를 그룹으로 나눕니다. 명령줄에서 ipa host-add --help 를 입력하여 모든 속성을 나열할 수 있습니다.
  • 모든 사용자 또는 모든 호스트를 하나의 글로벌 그룹에 추가합니다.

Red Hat Ansible Engine을 사용하여 IdM(Identity Management)에서 자동 그룹 멤버십 관리를 자동화할 수 있습니다.

이 섹션에서는 다음 주제를 다룹니다.

24.1. IdM 관리를 위한 Ansible 제어 노드 준비

IdM(Identity Management)을 관리하는 시스템 관리자로서 Red Hat Ansible Engine을 사용하여 작업할 때 다음을 수행하는 것이 좋습니다.

  • 홈 디렉터리에서 Ansible 플레이북 전용 하위 디렉터리(예: ~/MyPlaybooks )를 생성합니다.
  • /usr /share/doc/ansible-freeipa/* 및 /usr/share/doc /rhel-system-roles/* 디렉터리 및 하위 디렉터리에서 ~/MyPlaybooks 디렉터리에 샘플 Ansible 플레이북을 복사 및 조정합니다.
  • 인벤토리 파일을 ~/MyPlaybooks 디렉터리에 포함합니다.

이 방법을 사용하면 모든 플레이북을 한 곳에서 찾을 수 있으며 root 권한을 호출하지 않고도 플레이북을 실행할 수 있습니다.

참고

ipaserver,ipareplica,ipaclient,ipabackup,ipasmartcard_serveripasmartcard_client ansible-freeipa 역할을 실행하려면 관리형 노드에서만 root 권한이 필요합니다. 이러한 역할을 수행하려면 디렉터리 및 dnf 소프트웨어 패키지 관리자에 대한 액세스 권한이 필요합니다.

Ansible 플레이북을 저장하고 실행하는 데 사용할 수 있도록 ~/MyPlaybooks 디렉터리를 생성하고 구성하려면 다음 절차를 따르십시오.

사전 요구 사항

  • 관리형 노드인 server.idm.example .com 및 replica.idm.example.com에 IdM 서버를 설치했습니다.
  • 제어 노드에서 직접 관리형 노드인 server.idm.example.com 및 replica.idm.example.com 에 로그인할 수 있도록 DNS 및 네트워킹을 구성했습니다.
  • IdM 관리자 암호를 알고 있습니다.

절차

  1. 홈 디렉터리에서 Ansible 구성 및 플레이북의 디렉터리를 생성합니다.

    $ mkdir ~/MyPlaybooks/
  2. ~/MyPlaybooks/ 디렉터리로 변경합니다.

    $ cd ~/MyPlaybooks
  3. 다음 콘텐츠를 사용하여 ~/Myplaybooks/ansible.cfg 파일을 만듭니다.

    [defaults]
    inventory = /home/your_username/MyPlaybooks/inventory
    
    [privilege_escalation]
    become=True
  4. 다음 콘텐츠를 사용하여 ~/Myplaybooks/inventory 파일을 만듭니다.

    [ipaserver]
    server.idm.example.com
    
    [ipareplicas]
    replica1.idm.example.com
    replica2.idm.example.com
    
    [ipacluster:children]
    ipaserver
    ipareplicas
    
    [ipacluster:vars]
    ipaadmin_password=SomeADMINpassword
    
    [ipaclients]
    ipaclient1.example.com
    ipaclient2.example.com
    
    [ipaclients:vars]
    ipaadmin_password=SomeADMINpassword

    이 구성은 이러한 위치에 있는 호스트에 대한 두 개의 호스트 그룹인 euus 를 정의합니다. 또한 이 구성은 euus 그룹의 모든 호스트를 포함하는 ipaserver 호스트 그룹을 정의합니다.

  5. [선택 사항] SSH 공개 및 개인 키를 생성합니다. 테스트 환경에서 액세스를 간소화하려면 개인 키에 암호를 설정하지 마십시오.

    $ ssh-keygen
  6. SSH 공개 키를 각 관리 노드의 IdM admin 계정에 복사합니다.

    $ ssh-copy-id admin@server.idm.example.com
    $ ssh-copy-id admin@replica.idm.example.com

    이러한 명령을 입력하면 IdM 관리자 암호를 입력해야 합니다.

24.2. Ansible을 사용하여 IdM 사용자 그룹에 대한 automember 규칙이 있는지 확인합니다.

다음 절차에서는 Ansible 플레이북을 사용하여 IdM(Identity Management) 그룹에 대한 자동 멤버십 규칙이 있는지 확인하는 방법을 설명합니다. 이 예제에서는 testing_group 사용자 그룹에 대해 automember 규칙이 있는지 확인합니다.

사전 요구 사항

  • IdM 관리자 암호를 알고 있습니다.
  • IdM에 testing_group 사용자 그룹이 있습니다.
  • 다음 요구 사항을 충족하도록 Ansible 제어 노드를 구성했습니다.

    • Ansible 버전 2.14 이상을 사용하고 있습니다.
    • Ansible 컨트롤러에 ansible-freeipa 패키지가 설치되어 있습니다.
    • 이 예제에서는 ~/MyPlaybook/ 디렉터리에서 IdM 서버의 FQDN(정규화된 도메인 이름)을 사용하여 Ansible 인벤토리 파일을 생성했다고 가정합니다.
    • 이 예제에서는 secret.yml Ansible 자격 증명 모음이 ipaadmin_password 를 저장하는 것으로 가정합니다.

절차

  1. ~/MyPlaybooks/ 디렉터리로 이동합니다.

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible-freeipa/playbooks/automember/ 디렉터리에 있는 automember-group-present.yml Ansible 플레이북 파일을 복사합니다.

    $ cp /usr/share/doc/ansible-freeipa/playbooks/automember/automember-group-present.yml automember-group-present-copy.yml
  3. 편집할 automember-group-present-copy.yml 파일을 엽니다.
  4. ipaautomember 작업 섹션에서 다음 변수를 설정하여 파일을 조정합니다.

    • ipaadmin_password 변수를 IdM 관리자 암호로 설정합니다.
    • name 변수를 testing_group 으로 설정합니다.
    • automember_type 변수를 그룹으로 설정합니다.
    • state 변수가 present 로 설정되어 있는지 확인합니다.

    이는 현재 예제에 대한 수정된 Ansible 플레이북 파일입니다.

    ---
    - name: Automember group present example
      hosts: ipaserver
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Ensure group automember rule admins is present
        ipaautomember:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: testing_group
          automember_type: group
          state: present
  5. 파일을 저장합니다.
  6. Ansible 플레이북을 실행합니다. Playbook 파일, secret.yml 파일을 보호하는 암호를 저장하는 파일, 인벤토리 파일을 지정합니다.

    $ ansible-playbook --vault-password-file=password_file -v -i inventory automember-group-present-copy.yml

추가 리소스

24.3. Ansible을 사용하여 IdM 사용자 그룹 automember 규칙에 지정된 조건이 있는지 확인

다음 절차에서는 Ansible 플레이북을 사용하여 IdM(Identity Management) 그룹의 automember 규칙에 지정된 조건이 있는지 확인하는 방법을 설명합니다. 이 예제에서는 automember 규칙에 UID 관련 조건이 있는 경우 testing_group 그룹에 대해 확인됩니다. .* 조건을 지정하면 향후 모든 IdM 사용자가 자동으로 testing_group 의 멤버가 되도록 합니다.

사전 요구 사항

  • IdM 관리자 암호를 알고 있습니다.
  • IdM에 testing_group 사용자 그룹 및 automember 사용자 그룹 규칙이 있습니다.
  • 다음 요구 사항을 충족하도록 Ansible 제어 노드를 구성했습니다.

    • Ansible 버전 2.14 이상을 사용하고 있습니다.
    • Ansible 컨트롤러에 ansible-freeipa 패키지가 설치되어 있습니다.
    • 이 예제에서는 ~/MyPlaybook/ 디렉터리에서 IdM 서버의 FQDN(정규화된 도메인 이름)을 사용하여 Ansible 인벤토리 파일을 생성했다고 가정합니다.
    • 이 예제에서는 secret.yml Ansible 자격 증명 모음이 ipaadmin_password 를 저장하는 것으로 가정합니다.

절차

  1. ~/MyPlaybooks/ 디렉터리로 이동합니다.

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible-freeipa/playbooks/automember/ directory(예: automember-usergroup-rule-present.yml )에 있는 automember-hostgroup-rule-present.yml Ansible 플레이북 파일을 복사합니다.

    $ cp /usr/share/doc/ansible-freeipa/playbooks/automember/automember-hostgroup-rule-present.yml automember-usergroup-rule-present.yml
  3. 편집할 automember-usergroup-rule-present.yml 파일을 엽니다.
  4. 다음 매개 변수를 수정하여 파일을 조정합니다.

    • 플레이북 이름을 사용 사례에 해당하도록 변경합니다. 예를 들면 다음과 같습니다. automember 사용자 그룹 규칙 멤버가.
    • 작업의 이름을 사용 사례에 맞게 변경합니다. 예를 들면 다음과 같습니다. 사용자 그룹의 automember 조건이 있는지 확인합니다.
    • ipaautomember 작업 섹션에서 다음 변수를 설정합니다.

      • ipaadmin_password 변수를 IdM 관리자 암호로 설정합니다.
      • name 변수를 testing_group 으로 설정합니다.
      • automember_type 변수를 그룹으로 설정합니다.
      • state 변수가 present 로 설정되어 있는지 확인합니다.
      • action 변수가 member 로 설정되어 있는지 확인합니다.
      • include 변수UID 로 설정합니다.
      • 포함 변수를 . *로 설정합니다 .*

    이는 현재 예제에 대한 수정된 Ansible 플레이북 파일입니다.

    ---
    - name: Automember user group rule member present
      hosts: ipaserver
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Ensure an automember condition for a user group is present
        ipaautomember:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: testing_group
          automember_type: group
          state: present
          action: member
          inclusive:
            - key: UID
              expression: .*
  5. 파일을 저장합니다.
  6. Ansible 플레이북을 실행합니다. Playbook 파일, secret.yml 파일을 보호하는 암호를 저장하는 파일, 인벤토리 파일을 지정합니다.

    $ ansible-playbook --vault-password-file=password_file -v -i inventory automember-usergroup-rule-present.yml

검증 단계

  1. IdM 관리자로 로그인합니다.

    $ kinit admin
  2. 다음과 같은 사용자를 추가합니다.

    $ ipa user-add user101 --first user --last 101
    -----------------------
    Added user "user101"
    -----------------------
      User login: user101
      First name: user
      Last name: 101
      ...
      Member of groups: ipausers, testing_group
      ...

추가 리소스

24.4. Ansible을 사용하여 IdM 사용자 그룹 automember 규칙에 조건이 없는지 확인합니다.

다음 절차에서는 Ansible 플레이북을 사용하여 IdM(Identity Management) 그룹에 대한 자동 멤버 규칙에서 조건이 없는지 확인하는 방법을 설명합니다. 이 예제에서는 자동 멤버 규칙에 조건이 없으면 초기 사용자가 dp 여야 함을 지정하는지 확인합니다. automember 규칙이 testing_group 그룹에 적용됩니다. 조건을 적용하면 초기 단계가 dp 인 향후 IdM 사용자가 testing_group 의 멤버가 되지 않도록 합니다.

사전 요구 사항

  • IdM 관리자 암호를 알고 있습니다.
  • IdM에 testing_group 사용자 그룹 및 automember 사용자 그룹 규칙이 있습니다.
  • 다음 요구 사항을 충족하도록 Ansible 제어 노드를 구성했습니다.

    • Ansible 버전 2.14 이상을 사용하고 있습니다.
    • Ansible 컨트롤러에 ansible-freeipa 패키지가 설치되어 있습니다.
    • 이 예제에서는 ~/MyPlaybook/ 디렉터리에서 IdM 서버의 FQDN(정규화된 도메인 이름)을 사용하여 Ansible 인벤토리 파일을 생성했다고 가정합니다.
    • 이 예제에서는 secret.yml Ansible 자격 증명 모음이 ipaadmin_password 를 저장하는 것으로 가정합니다.

절차

  1. ~/MyPlaybooks/ 디렉터리로 이동합니다.

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible-freeipa/playbooks/automember/ 디렉터리(예: automember-usergroup-rule-absent.yml )에 있는 automember-hostgroup-rule-absent.yml Ansible 플레이북 파일을 복사합니다.

    $ cp /usr/share/doc/ansible-freeipa/playbooks/automember/automember-hostgroup-rule-absent.yml automember-usergroup-rule-absent.yml
  3. 편집할 automember-usergroup-rule-absent.yml 파일을 엽니다.
  4. 다음 매개 변수를 수정하여 파일을 조정합니다.

    • 플레이북 이름을 사용 사례에 해당하도록 변경합니다. 예를 들면 다음과 같습니다. 사용자 그룹 규칙 member absent.
    • 작업의 이름을 사용 사례에 맞게 변경합니다. 예를 들면 다음과 같습니다. 사용자 그룹의 automember 조건이 없는지 확인합니다.
    • ipaautomember 작업 섹션에서 다음 변수를 설정합니다.

      • ipaadmin_password 변수를 IdM 관리자 암호로 설정합니다.
      • name 변수를 testing_group 으로 설정합니다.
      • automember_type 변수를 그룹으로 설정합니다.
      • state 변수가 absent 로 설정되어 있는지 확인합니다.
      • action 변수가 member 로 설정되어 있는지 확인합니다.
      • include 변수initial 로 설정합니다.
      • 포함 변수를 dp 로 설정합니다.

    이는 현재 예제에 대한 수정된 Ansible 플레이북 파일입니다.

    ---
    - name: Automember user group rule member absent
      hosts: ipaserver
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Ensure an automember condition for a user group is absent
        ipaautomember:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: testing_group
          automember_type: group
          state: absent
          action: member
          inclusive:
            - key: initials
              expression: dp
  5. 파일을 저장합니다.
  6. Ansible 플레이북을 실행합니다. Playbook 파일, secret.yml 파일을 보호하는 암호를 저장하는 파일, 인벤토리 파일을 지정합니다.

    $ ansible-playbook --vault-password-file=password_file -v -i inventory automember-usergroup-rule-absent.yml

검증 단계

  1. IdM 관리자로 로그인합니다.

    $ kinit admin
  2. automember 그룹을 확인합니다.

    $ ipa automember-show --type=group testing_group
     Automember Rule: testing_group

출력에 결정된 Regex: initials=dp 항목이 없으면 testing_group automember 규칙에 지정된 조건이 포함되어 있지 않습니다.

추가 리소스

24.5. Ansible을 사용하여 IdM 사용자 그룹의 automember 규칙이 없는지 확인합니다.

다음 절차에서는 Ansible 플레이북을 사용하여 IdM(Identity Management) 그룹에 대한 automember 규칙이 없는지 확인하는 방법을 설명합니다. 이 예제에서는 testing_group 그룹에 대해 automember 규칙이 없는지 확인합니다.

참고

자동 구성원 규칙을 삭제하면 규칙과 연결된 모든 조건도 삭제됩니다. 규칙에서 특정 조건만 제거하려면 Ansible을 사용하여 IdM 사용자 그룹 automember 규칙에 조건이 없는지 확인합니다.

사전 요구 사항

  • IdM 관리자 암호를 알고 있습니다.
  • 다음 요구 사항을 충족하도록 Ansible 제어 노드를 구성했습니다.

    • Ansible 버전 2.14 이상을 사용하고 있습니다.
    • Ansible 컨트롤러에 ansible-freeipa 패키지가 설치되어 있습니다.
    • 이 예제에서는 ~/MyPlaybook/ 디렉터리에서 IdM 서버의 FQDN(정규화된 도메인 이름)을 사용하여 Ansible 인벤토리 파일을 생성했다고 가정합니다.
    • 이 예제에서는 secret.yml Ansible 자격 증명 모음이 ipaadmin_password 를 저장하는 것으로 가정합니다.

절차

  1. ~/MyPlaybooks/ 디렉터리로 이동합니다.

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible-freeipa/playbooks/automember/ 디렉터리에 있는 automember-group-absent.yml Ansible 플레이북 파일을 복사합니다.

    $ cp /usr/share/doc/ansible-freeipa/playbooks/automember/automember-group-absent.yml automember-group-absent-copy.yml
  3. 편집할 automember-group-absent-copy.yml 파일을 엽니다.
  4. ipaautomember 작업 섹션에서 다음 변수를 설정하여 파일을 조정합니다.

    • ipaadmin_password 변수를 IdM 관리자 암호로 설정합니다.
    • name 변수를 testing_group 으로 설정합니다.
    • automember_type 변수를 그룹으로 설정합니다.
    • state 변수가 absent 로 설정되어 있는지 확인합니다.

    이는 현재 예제에 대한 수정된 Ansible 플레이북 파일입니다.

    ---
    - name: Automember group absent example
      hosts: ipaserver
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Ensure group automember rule admins is absent
        ipaautomember:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: testing_group
          automember_type: group
          state: absent
  5. 파일을 저장합니다.
  6. Ansible 플레이북을 실행합니다. Playbook 파일, secret.yml 파일을 보호하는 암호를 저장하는 파일, 인벤토리 파일을 지정합니다.

    $ ansible-playbook --vault-password-file=password_file -v -i inventory automember-group-absent.yml

추가 리소스

24.6. Ansible을 사용하여 IdM 호스트 그룹 automember 규칙에 조건이 있는지 확인합니다.

Ansible을 사용하여 IdM 호스트 그룹 automember 규칙에 조건이 있는지 확인합니다. 이 예제에서는 FQDN.*.idm.example.com 인 호스트가 primary_dns_domain_hosts 호스트 그룹의 멤버이고 FQDN.*.example.orgprimary_dns_domain_hosts 호스트 그룹의 멤버가 아닌지 확인하는 방법을 설명합니다.

사전 요구 사항

  • IdM 관리자 암호를 알고 있습니다.
  • IdM에 primary_dns_domain_hosts 호스트 그룹과 automember 호스트 그룹 규칙이 있습니다.
  • 다음 요구 사항을 충족하도록 Ansible 제어 노드를 구성했습니다.

    • Ansible 버전 2.14 이상을 사용하고 있습니다.
    • Ansible 컨트롤러에 ansible-freeipa 패키지가 설치되어 있습니다.
    • 이 예제에서는 ~/MyPlaybook/ 디렉터리에서 IdM 서버의 FQDN(정규화된 도메인 이름)을 사용하여 Ansible 인벤토리 파일을 생성했다고 가정합니다.
    • 이 예제에서는 secret.yml Ansible 자격 증명 모음이 ipaadmin_password 를 저장하는 것으로 가정합니다.

절차

  1. ~/MyPlaybooks/ 디렉터리로 이동합니다.

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible-freeipa/playbooks/automember/ 디렉터리에 있는 automember-hostgroup-rule-present.yml Ansible 플레이북 파일을 복사합니다.

    $ cp /usr/share/doc/ansible-freeipa/playbooks/automember/automember-hostgroup-rule-present.yml automember-hostgroup-rule-present-copy.yml
  3. 편집할 automember-hostgroup-rule-present-copy.yml 파일을 엽니다.
  4. ipaautomember 작업 섹션에서 다음 변수를 설정하여 파일을 조정합니다.

    • ipaadmin_password 변수를 IdM 관리자 암호로 설정합니다.
    • name 변수를 primary_dns_domain_hosts 로 설정합니다.
    • automember_type 변수를 hostgroup 으로 설정합니다.
    • state 변수가 present 로 설정되어 있는지 확인합니다.
    • action 변수가 member 로 설정되어 있는지 확인합니다.
    • inclusive 변수가 fqdn;으로 설정되어 있는지 확인합니다.
    • 해당하는 include 표현식 변수.*.idm.example.com 으로 설정합니다.
    • 전용 변수를 fqdn;로 설정합니다.
    • 해당 전용 표현식 변수를 .*.example.org 로 설정합니다.

    이는 현재 예제에 대한 수정된 Ansible 플레이북 파일입니다.

    ---
    - name: Automember user group rule member present
      hosts: ipaserver
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Ensure an automember condition for a user group is present
        ipaautomember:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: primary_dns_domain_hosts
          automember_type: hostgroup
          state: present
          action: member
          inclusive:
            - key: fqdn
              expression: .*.idm.example.com
          exclusive:
            - key: fqdn
              expression: .*.example.org
  5. 파일을 저장합니다.
  6. Ansible 플레이북을 실행합니다. Playbook 파일, secret.yml 파일을 보호하는 암호를 저장하는 파일, 인벤토리 파일을 지정합니다.

    $ ansible-playbook --vault-password-file=password_file -v -i inventory automember-hostgroup-rule-present-copy.yml

추가 리소스

24.7. 추가 리소스

25장. IdM CLI를 사용하여 사용자를 관리하기 위해 사용자 그룹에 권한을 위임

위임은 IdM의 액세스 제어 방법 중 하나로 셀프 서비스 규칙 및 역할 기반 액세스 제어(RBAC)와 함께 사용됩니다. 위임을 사용하여 한 사용자 그룹에 권한을 할당하여 다른 사용자 그룹의 항목을 관리할 수 있습니다.

이 섹션에서는 다음 주제를 다룹니다.

25.1. 위임 규칙

위임 규칙을 만들어 사용자 그룹에 권한을 위임하여 사용자를 관리할 수 있습니다.

위임 규칙을 사용하면 특정 사용자 그룹이 다른 사용자 그룹의 특정 속성에 대한 쓰기(편집) 작업을 수행할 수 있습니다. 이 형태의 액세스 제어 규칙은 위임 규칙에서 지정한 속성의 값 편집으로 제한됩니다. 전체 항목을 추가 또는 제거하는 기능을 부여하지 않습니다. 지정되지 않은 속성에 대해 전체 항목을 추가하거나 제어하는 기능을 부여하지 않습니다.

위임 규칙은 IdM의 기존 사용자 그룹에 권한을 부여합니다. 예를 들어 위임을 사용하여 managers 사용자 그룹이 employees 사용자 그룹에서 선택한 사용자 속성을 관리할 수 있습니다.

25.2. IdM CLI를 사용하여 위임 규칙 생성

IdM CLI를 사용하여 위임 규칙을 생성하려면 다음 절차를 따르십시오.

사전 요구 사항

  • admins 그룹의 멤버로 로그인했습니다.

절차

  • ipa delegation-add 명령을 입력합니다. 다음 옵션을 지정합니다.

    • --group: 사용자 그룹의 사용자 항목에 권한을 부여하는 그룹입니다.
    • --membergroup: 위임 그룹의 멤버가 항목을 편집할 수 있는 그룹입니다.
    • --permissions: 사용자가 지정된 속성을 보고(읽기) 지정된 속성을 보고 주어진 속성을 추가하거나 변경할 수 있는지(쓰기). 권한을 지정하지 않으면 쓰기 권한만 추가됩니다.
    • --attrs: 멤버 그룹의 사용자가 보거나 편집할 수 있는 속성입니다.

    예를 들면 다음과 같습니다.

$ ipa delegation-add "basic manager attributes" --permissions=read --permissions=write --attrs=businesscategory --attrs=departmentnumber --attrs=employeetype --attrs=employeenumber --group=managers --membergroup=employees
-------------------------------------------
Added delegation "basic manager attributes"
-------------------------------------------
  Delegation name: basic manager attributes
  Permissions: read, write
  Attributes: businesscategory, departmentnumber, employeetype, employeenumber
  Member user group: employees
  User group: managers

25.3. IdM CLI를 사용하여 기존 위임 규칙 보기

IdM CLI를 사용하여 기존 위임 규칙을 보려면 다음 절차를 따르십시오.

사전 요구 사항

  • admins 그룹의 멤버로 로그인했습니다.

절차

  • ipa delegation-find 명령을 입력합니다.
$ ipa delegation-find
--------------------
1 delegation matched
--------------------
  Delegation name: basic manager attributes
  Permissions: read, write
  Attributes: businesscategory, departmentnumber, employeenumber, employeetype
  Member user group: employees
  User group: managers
----------------------------
Number of entries returned 1
----------------------------

25.4. IdM CLI를 사용하여 위임 규칙 수정

IdM CLI를 사용하여 기존 위임 규칙을 수정하려면 다음 절차를 따르십시오.

중요

--attrs 옵션은 지원되는 속성의 이전 목록을 덮어쓰므로 항상 새 속성과 함께 전체 속성 목록을 포함합니다. 이는 --permissions 옵션에도 적용됩니다.

사전 요구 사항

  • admins 그룹의 멤버로 로그인했습니다.

절차

  • 원하는 변경 사항을 사용하여 ipa delegation-mod 명령을 입력합니다. 예를 들어 기본 관리자 속성 예제 규칙에 displayname 속성을 추가하려면 다음을 수행합니다.

    $ ipa delegation-mod "basic manager attributes" --attrs=businesscategory --attrs=departmentnumber --attrs=employeetype --attrs=employeenumber --attrs=displayname
    ----------------------------------------------
    Modified delegation "basic manager attributes"
    ----------------------------------------------
      Delegation name: basic manager attributes
      Permissions: read, write
      Attributes: businesscategory, departmentnumber, employeetype, employeenumber, displayname
      Member user group: employees
      User group: managers

25.5. IdM CLI를 사용하여 위임 규칙 삭제

IdM CLI를 사용하여 기존 위임 규칙을 삭제하려면 다음 절차를 따르십시오.

사전 요구 사항

  • admins 그룹의 멤버로 로그인했습니다.

절차

  • ipa delegation-del 명령을 입력합니다.
  • 메시지가 표시되면 삭제할 위임 규칙의 이름을 입력합니다.

    $ ipa delegation-del
    Delegation name: basic manager attributes
    ---------------------------------------------
    Deleted delegation "basic manager attributes"
    ---------------------------------------------

26장. IdM WebUI를 사용하여 사용자를 관리하기 위해 사용자 그룹에 권한을 위임

위임은 IdM의 액세스 제어 방법 중 하나로 셀프 서비스 규칙 및 역할 기반 액세스 제어(RBAC)와 함께 사용됩니다. 위임을 사용하여 한 사용자 그룹에 권한을 할당하여 다른 사용자 그룹의 항목을 관리할 수 있습니다.

이 섹션에서는 다음 주제를 다룹니다.

26.1. 위임 규칙

위임 규칙을 만들어 사용자 그룹에 권한을 위임하여 사용자를 관리할 수 있습니다.

위임 규칙을 사용하면 특정 사용자 그룹이 다른 사용자 그룹의 특정 속성에 대한 쓰기(편집) 작업을 수행할 수 있습니다. 이 형태의 액세스 제어 규칙은 위임 규칙에서 지정한 속성의 값 편집으로 제한됩니다. 전체 항목을 추가 또는 제거하는 기능을 부여하지 않습니다. 지정되지 않은 속성에 대해 전체 항목을 추가하거나 제어하는 기능을 부여하지 않습니다.

위임 규칙은 IdM의 기존 사용자 그룹에 권한을 부여합니다. 예를 들어 위임을 사용하여 managers 사용자 그룹이 employees 사용자 그룹에서 선택한 사용자 속성을 관리할 수 있습니다.

26.2. IdM WebUI를 사용하여 위임 규칙 생성

IdM WebUI를 사용하여 위임 규칙을 생성하려면 다음 절차를 따르십시오.

사전 요구 사항

  • IdM 웹 UI에 admins 그룹의 멤버로 로그인했습니다.

절차

  1. IPA 서버 메뉴에서 역할 기반 액세스 제어위임을 클릭합니다.
  2. 추가를 클릭합니다.

    "IPA 서버" 탭의 "Role-Based Access Control" 드롭다운 하위 메뉴의 내용을 표시하는 IdM 웹 UI의 스크린샷입니다. "역할 기반 액세스 제어" 드롭다운 메뉴에는 5가지 옵션이 있습니다. 역할 - 권한 - 권한 - 자체 서비스 권한 - 위임.
  3. Add delegation(디렉토리 추가 ) 창에서 다음을 수행합니다.

    1. 새 위임 규칙의 이름을 지정합니다.
    2. 사용자가 지정된 속성(읽기)을 보고 지정된 속성을 추가하거나 변경할 수 있는지 여부를 나타내는 확인란을 선택하여 권한을 설정합니다.
    3. User group(사용자 그룹) 드롭다운 메뉴에서 권한을 부여 받고 있는 그룹을 선택하여 멤버 그룹에서 사용자 항목을 보거나 편집할 수 있습니다.
    4. Member 사용자 그룹 드롭다운 메뉴에서 위임 그룹의 구성원이 편집할 수 있는 그룹을 선택합니다.
    5. attributes(속성) 상자에서 권한을 부여할 속성별로 확인란을 선택합니다.

      위임에 대한 세부 정보를 입력할 수 있는 "Add delegation"(분리 추가) 팝업 창의 스크린샷입니다. 항목 옵션에는 위임 이름의 텍스트 필드와 "read" 및 "write" 권한의 확인란이 포함되어 있습니다. User 그룹에 대한 드롭다운 메뉴, 즉 Member 사용자 그룹의 드롭다운 메뉴와 Attributes(예: departmentnumber - employeenumber - businesscategory - employeetype)의 많은 확인란도 있습니다.
    6. Add(추가 ) 버튼을 클릭하여 새 위임 규칙을 저장합니다.

26.3. IdM WebUI를 사용하여 기존 위임 규칙 보기

IdM WebUI를 사용하여 기존 위임 규칙을 보려면 다음 절차를 따르십시오.

사전 요구 사항

  • IdM 웹 UI에 admins 그룹의 멤버로 로그인했습니다.

절차

  • IPA 서버 메뉴에서 역할 기반 액세스 제어위임을 클릭합니다.

    "IPA 서버" 탭의 "역할 기반 액세스 제어" 하위 메뉴의 "Delegations" 페이지를 표시하는 IdM 웹 UI의 스크린샷입니다. "강의 이름"으로 구성된 위임을 표시하는 테이블이 있습니다.

26.4. IdM WebUI를 사용하여 위임 규칙 수정

IdM WebUI를 사용하여 기존 위임 규칙을 수정하려면 다음 절차를 따르십시오.

사전 요구 사항

  • IdM 웹 UI에 admins 그룹의 멤버로 로그인했습니다.

절차

  1. IPA 서버 메뉴에서 역할 기반 액세스 제어위임을 클릭합니다.

    IPA 서버 탭에서 역할 기반 액세스 제어 하위 페이지를 표시하는 IdM 웹 UI의 스크린샷입니다. 위임 페이지에는 "basic manager attributes" 위임 이름에 대한 항목이 있는 테이블이 표시됩니다.
  2. 수정할 규칙을 클릭합니다.
  3. 원하는 대로 변경합니다.

    • 규칙의 이름을 변경합니다.
    • 사용자가 지정된 속성(읽기)을 보고 지정된 속성을 추가하거나 변경할 수 있는지 여부를 나타내는 확인란을 선택하여 부여된 권한을 변경합니다.
    • User group(사용자 그룹) 드롭다운 메뉴에서 권한을 부여 받고 있는 그룹을 선택하여 멤버 그룹에서 사용자 항목을 보거나 편집할 수 있습니다.
    • Member 사용자 그룹 드롭다운 메뉴에서 위임 그룹의 구성원이 편집할 수 있는 그룹을 선택합니다.
    • attributes(속성) 상자에서 권한을 부여할 속성별로 확인란을 선택합니다. 속성에 대한 권한을 제거하려면 관련 확인란을 선택 취소합니다.

      위임 페이지에는 위임 이름 - 권한(예: "읽기" 및 "쓰기")과 같은 위임에 대한 세부 정보가 표시됩니다. - 사용자 그룹(예: "관리자"과 같이 필수) - 멤버 사용자 그룹(예: "직원 유형"과 같은 필수) 및 속성(예: employeetype - businesscategory - departmentnumber - displayname - employeenumber - homedirectory)과 같은 속성이 표시됩니다. 왼쪽 상단에 있는 "save" 버튼이 강조 표시됩니다.
    • Save(저장 ) 버튼을 클릭하여 변경 사항을 저장합니다.

26.5. IdM WebUI를 사용하여 위임 규칙 삭제

IdM WebUI를 사용하여 기존 위임 규칙을 삭제하려면 다음 절차를 따르십시오.

사전 요구 사항

  • IdM 웹 UI에 admins 그룹의 멤버로 로그인했습니다.

절차

  1. IPA 서버 메뉴에서 역할 기반 액세스 제어위임을 클릭합니다.
  2. 제거할 규칙 옆에 있는 확인란을 선택합니다.
  3. 삭제를 클릭합니다.

    "IPA 서버" 탭의 "Role-Based Access Control" 하위 메뉴의 스크린샷입니다. "Delegations" 페이지에 위임 이름이 있는 테이블과 "basic manager attributes" 항목의 확인란이 선택되어 있습니다. "Delete"(삭제) 버튼이 강조 표시되었습니다.
  4. Delete(삭제) 를 클릭하여 확인합니다.

27장. Ansible 플레이북을 사용하여 사용자를 관리하기 위해 사용자 그룹에 권한을 위임

위임은 IdM의 액세스 제어 방법 중 하나로 셀프 서비스 규칙 및 역할 기반 액세스 제어(RBAC)와 함께 사용됩니다. 위임을 사용하여 한 사용자 그룹에 권한을 할당하여 다른 사용자 그룹의 항목을 관리할 수 있습니다.

이 섹션에서는 다음 주제를 다룹니다.

27.1. 위임 규칙

위임 규칙을 만들어 사용자 그룹에 권한을 위임하여 사용자를 관리할 수 있습니다.

위임 규칙을 사용하면 특정 사용자 그룹이 다른 사용자 그룹의 특정 속성에 대한 쓰기(편집) 작업을 수행할 수 있습니다. 이 형태의 액세스 제어 규칙은 위임 규칙에서 지정한 속성의 값 편집으로 제한됩니다. 전체 항목을 추가 또는 제거하는 기능을 부여하지 않습니다. 지정되지 않은 속성에 대해 전체 항목을 추가하거나 제어하는 기능을 부여하지 않습니다.

위임 규칙은 IdM의 기존 사용자 그룹에 권한을 부여합니다. 예를 들어 위임을 사용하여 managers 사용자 그룹이 employees 사용자 그룹에서 선택한 사용자 속성을 관리할 수 있습니다.

27.2. IdM용 Ansible 인벤토리 파일 생성

Ansible을 사용하는 경우 홈 디렉터리에서 /usr/share/doc/ ansible-freeipa/* 및 /usr/share/doc -roles/* 하위 디렉터리를 복사하고 적응하는 Ansible 플레이북 전용 하위 디렉터리를 생성하는 것이 좋습니다. 이 연습에는 다음과 같은 이점이 있습니다.

  • 모든 플레이북을 한 곳에서 찾을 수 있습니다.
  • 루트 권한을 호출하지 않고 플레이북을 실행할 수 있습니다.

절차

  1. 홈 디렉터리에서 Ansible 구성 및 플레이북의 디렉터리를 생성합니다.

    $ mkdir ~/MyPlaybooks/
  2. ~/MyPlaybooks/ 디렉터리로 변경합니다.

    $ cd ~/MyPlaybooks
  3. 다음 콘텐츠를 사용하여 ~/Myplaybooks/ansible.cfg 파일을 만듭니다.

    [defaults]
    inventory = /home/<username>/MyPlaybooks/inventory
    
    [privilege_escalation]
    become=True
  4. 다음 콘텐츠를 사용하여 ~/Myplaybooks/inventory 파일을 만듭니다.

    [eu]
    server.idm.example.com
    
    [us]
    replica.idm.example.com
    
    [ipaserver:children]
    eu
    us

    이 구성은 이러한 위치에 있는 호스트에 대한 두 개의 호스트 그룹인 euus 를 정의합니다. 또한 이 구성은 euus 그룹의 모든 호스트를 포함하는 ipaserver 호스트 그룹을 정의합니다.

27.3. Ansible을 사용하여 위임 규칙이 있는지 확인합니다.

다음 절차에서는 Ansible 플레이북을 사용하여 새 IdM 위임 규칙에 대한 권한을 정의하고 해당 규칙이 있는지 확인하는 방법을 설명합니다. 이 예제에서 새 기본 관리자 속성 위임 규칙은 managers 그룹에 employees 그룹 구성원에 대해 다음 속성을 읽고 쓸 수 있는 기능을 부여합니다.

  • businesscategory
  • departmentnumber
  • employeenumber
  • employeetype

사전 요구 사항

  • IdM 관리자 암호를 알고 있습니다.
  • 다음 요구 사항을 충족하도록 Ansible 제어 노드를 구성했습니다.

    • Ansible 버전 2.14 이상을 사용하고 있습니다.
    • Ansible 컨트롤러에 ansible-freeipa 패키지가 설치되어 있습니다.
    • 이 예제에서는 ~/MyPlaybook/ 디렉터리에서 IdM 서버의 FQDN(정규화된 도메인 이름)을 사용하여 Ansible 인벤토리 파일을 생성했다고 가정합니다.
    • 이 예제에서는 secret.yml Ansible 자격 증명 모음이 ipaadmin_password 를 저장하는 것으로 가정합니다.

절차

  1. ~/MyPlaybooks/ 디렉터리로 이동합니다.

    $ cd ~/MyPlaybooks/
  2. /usr/share/doc/ansible -freeipa/playbooks/delegation/ 디렉토리에 있는 delegation- present.yml 파일의 복사본을 만듭니다.

    $ cp /usr/share/doc/ansible-freeipa/playbooks/delegation/delegation-present.yml delegation-present-copy.yml
  3. 편집 할 delegation-present-copy.yml Ansible 플레이북 파일을 엽니다.
  4. ipadelegation 작업 섹션에서 다음 변수를 설정하여 파일을 조정합니다.

    • ipaadmin_password 변수를 IdM 관리자의 암호로 설정합니다.
    • name 변수를 새 위임 규칙의 이름으로 설정합니다.
    • 권한 변수를 쉼표로 구분된 권한 목록( 읽기쓰기 )으로 설정합니다.
    • 속성 변수를 위임된 사용자 그룹이 관리할 수 있는 속성 목록(business category,departmentnumber, employeenumber, employeetype ) 으로 설정합니다.
    • 그룹 변수를 특성 보기 또는 수정에 대한 액세스 권한이 부여되는 그룹의 이름으로 설정합니다.
    • membergroup 변수를 속성을 보거나 수정할 수 있는 그룹의 이름으로 설정합니다.

    이는 현재 예제에 대한 수정된 Ansible 플레이북 파일입니다.

    ---
    - name: Playbook to manage a delegation rule
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Ensure delegation "basic manager attributes" is present
        ipadelegation:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: "basic manager attributes"
          permission: read, write
          attribute:
          - businesscategory
          - departmentnumber
          - employeenumber
          - employeetype
          group: managers
          membergroup: employees
  5. 파일을 저장합니다.