| 탐색 링크 건너뛰기 | |
| 인쇄 보기 종료 | |
|
Oracle Solaris 11.1 관리: 보안 서비스 Oracle Solaris 11.1 Information Library (한국어) |
| 탐색 링크 건너뛰기 | |
| 인쇄 보기 종료 | |
|
|
Oracle Solaris 11.1 관리: 보안 서비스 Oracle Solaris 11.1 Information Library (한국어) |
LDAP 데이터 서버를 사용하도록 KDC를 구성하는 방법
마스터 서버에서 TGS(티켓 부여 서비스) 키를 새로 고치는 방법
FTP 실행 시 Kerberos를 통한 일반 보안 서비스 사용 방법
Kerberos 보안 모드가 여러 개인 보안 NFS 환경 설정 방법
Kerberos 클라이언트 설치 프로파일을 만드는 방법
Active Directory 서버에 대한 Kerberos 클라이언트 구성 방법
TGT(티켓 부여 티켓) 확인을 사용 안함으로 설정하는 방법
Kerberos로 보호된 NFS 파일 시스템에 root 사용자로 액세스하는 방법
Kerberos 영역에서 사용자의 자동 마이그레이션을 구성하는 방법
모든 TGT(티켓 부여 티켓)를 자동으로 갱신하는 방법
서버 업그레이드 후 Kerberos 데이터베이스 변환 방법
증분 전파를 사용하도록 마스터 KDC를 재구성하는 방법
증분 전파를 사용하도록 슬레이브 KDC를 재구성하는 방법
전체 전파를 사용하도록 슬레이브 KDC를 구성하는 방법
비Kerberos 객체 클래스 유형에서 Kerberos 주체 속성을 함께 사용하는 방법
Kerberos 데이터베이스는 Kerberos의 중심이므로 올바르게 유지 관리되어야 합니다. 이 절에서는 Kerberos 데이터베이스 관리(예: 데이터베이스 백업 및 복원, 증분 또는 병렬 전파 설정, stash 파일 관리) 방법에 대한 몇 가지 절차를 제공합니다. 데이터베이스 초기 설정 단계는 수동으로 마스터 KDC를 구성하는 방법에서 설명됩니다.
마스터 KDC에서 슬레이브 KDC로 Kerberos 데이터베이스를 전파하는 작업은 가장 중요한 구성 작업 중 하나입니다. 전파가 충분히 자주 실행되지 않으면 마스터 KDC와 슬레이브 KDC의 동기화가 끊깁니다. 따라서 마스터 KDC의 작동이 중지될 경우 슬레이브 KDC가 최신 데이터베이스 정보를 가지지 못합니다. 또한 로드 균형 조정 용도로 슬레이브 KDC가 마스터 KDC로 구성된 경우 슬레이브 KDC를 마스터 KDC로 사용하는 클라이언트가 최신 정보를 가지지 못합니다. 따라서 전파가 충분히 자주 실행되도록 하거나 Kerberos 데이터베이스 변경 빈도에 따라 서버에서 증분 전파를 구성해야 합니다. 수동으로 데이터베이스를 전파하면 관리 오버헤드가 늘어나므로 수동 전파보다 증분 전파가 선호됩니다. 또한 데이터베이스 전체 전파를 실행하는 경우 비효율성이 발생할 수 있습니다.
마스터 KDC를 구성할 때 자동으로 Kerberos 데이터베이스를 /var/krb5/slave_datatrans 덤프 파일에 백업하여 슬레이브 KDC에 전파하도록 cron 작업의 kprop_script 명령을 설정합니다. 하지만 다른 파일과 마찬가지로 Kerberos 데이터베이스도 손상될 수 있습니다. 슬레이브 KDC에서 데이터가 손상된 경우 다음 번 데이터베이스 자동 전파 시 복사본이 다시 설치되므로 특별한 통지가 없을 수 있습니다. 하지만 마스터 KDC에서 데이터가 손상된 경우 다음 번 전파 중 손상된 데이터베이스가 모든 슬레이브 KDC에 전파됩니다. 또한 손상된 백업이 손상되지 않은 마스터 KDC의 이전 백업 파일을 겹쳐 씁니다.
이 시나리오에는 "안전한" 백업 복사본이 없으므로 주기적으로 slave_datatrans 덤프 파일이 다른 위치에 복사되거나 kdb5_util의 dump 명령을 사용하여 별도의 다른 백업 복사본이 만들어지도록 cron 작업도 설정해야 합니다. 그런 다음 데이터베이스가 손상되면 kdb5_util의 load 명령을 사용하여 마스터 KDC에서 최신 백업을 복원할 수 있습니다.
데이터베이스 덤프 파일에는 주체 키가 포함되어 있으므로 권한이 없는 사용자가 액세스하지 못하도록 파일을 보호해야 합니다. 기본적으로 데이터베이스 덤프 파일은 root로만 읽기 및 쓰기 권한을 가집니다. 허용되지 않은 액세스를 방지하려면 kprop 명령을 통해서만 데이터베이스 덤프 파일을 전파하십시오. 그러면 전달하려는 데이터가 암호화됩니다. 또한 kprop는 슬레이브 KDC로만 데이터를 전파하므로 허용되지 않은 호스트로 데이터베이스 덤프 파일이 잘못 전송될 가능성이 최소화됩니다.
 | 주의 - Kerberos 데이터베이스가 전파된 후 업데이트되는 경우 및 나중에 데이터베이스가 다음 번 전파 전에 손상되는 경우 KDC 슬레이브에 업데이트가 포함되지 않습니다. 업데이트는 손실됩니다. 따라서 정기적으로 예약된 전파 전에 Kerberos 데이터베이스에 중요한 업데이트를 추가할 경우 데이터가 손실되지 않도록 수동으로 데이터베이스를 전파해야 합니다. |
슬레이브 KDC의 kpropd.acl 파일은 host 주체 이름 목록(한 행당 하나의 이름)을 제공합니다. 이 목록에는 KDC가 전파를 통해 업데이트된 데이터베이스를 수신할 수 있는 시스템이 지정됩니다. 마스터 KDC를 사용하여 모든 슬레이브 KDC를 전파할 경우 각 슬레이브의 kpropd.acl 파일에는 마스터 KDC의 host 주체 이름만 포함되어야 합니다.
단, 본 설명서의 Kerberos 설치 및 후속 구성 단계에서는 마스터 KDC와 슬레이브 KDC에 동일한 kpropd.acl 파일을 추가하도록 안내합니다. 이 파일에는 모든 KDC host 주체 이름이 포함되어 있습니다. 전파하는 KDC를 일시적으로 사용할 수 없을 경우 이 구성을 통해 KDC에서의 전파를 실행할 수 있습니다. 또한 모든 KDC의 복사본이 동일하게 유지되도록 유지 관리가 간편한 구성을 설정합니다.
kprop_script 명령은 kprop 명령을 사용하여 Kerberos 데이터베이스를 다른 KDC에 전파합니다. kprop_script 명령이 슬레이브 KDC에서 실행되면 Kerberos 데이터베이스의 슬레이브 KDC 복사본을 다른 KDC에 전파합니다. kprop_script는 전파할 KDC를 표시하는 인수에 대해 공백으로 구분된 호스트 이름 목록을 승인합니다.
kprop_script가 실행되면 /var/krb5/slave_datatrans 파일에 Kerberos 데이터베이스 백업을 만들고 지정된 KDC에 해당 파일을 복사합니다. Kerberos 데이터베이스는 전파가 완료될 때까지 잠깁니다.
시작하기 전에
root 역할을 맡아야 합니다. 자세한 내용은 지정된 관리 권한을 사용하는 방법을 참조하십시오.
# /usr/sbin/kdb5_util dump [-verbose] [-d dbname] [filename [principals...]]
백업하려는 각 주체 및 정책의 이름을 인쇄합니다.
백업할 데이터베이스의 이름을 정의합니다. 파일에 대한 절대 경로를 지정할 수 있습니다. -d 옵션을 지정하지 않을 경우 기본 데이터베이스 이름은 /var/krb5/principal입니다.
데이터베이스 백업에 사용되는 파일을 정의합니다. 파일에 대한 절대 경로를 지정할 수 있습니다. 파일을 지정하지 않을 경우 표준 출력에 데이터베이스가 덤프됩니다.
백업할 하나 이상의 주체 목록(공백으로 구분됨)을 정의합니다. 정규화된 주체 이름을 사용해야 합니다. 주체를 지정하지 않을 경우 전체 데이터베이스가 백업됩니다.
예 21-19 Kerberos 데이터베이스 백업
다음 예에서는 이름이 dumpfile인 파일에 Kerberos 데이터베이스가 백업됩니다. -상세 정보 표시 옵션이 지정되었으므로 각 주체가 백업된 대로 인쇄됩니다.
# kdb5_util dump -verbose dumpfile kadmin/kdc1.eng.example.com@ENG.EXAMPLE.COM krbtgt/ENG.EXAMPLE.COM@ENG.EXAMPLE.COM kadmin/history@ENG.EXAMPLE.COM pak/admin@ENG.EXAMPLE.COM pak@ENG.EXAMPLE.COM changepw/kdc1.eng.example.com@ENG.EXAMPLE.COM
다음 예에서는 Kerberos 데이터베이스의 pak 및 pak/admin 주체가 백업됩니다.
# kdb5_util dump -verbose dumpfile pak/admin@ENG.EXAMPLE.COM pak@ENG.EXAMPLE.COM pak/admin@ENG.EXAMPLE.COM pak@ENG.EXAMPLE.COM
시작하기 전에
KDC 마스터에서 root 역할을 맡아야 합니다. 자세한 내용은 지정된 관리 권한을 사용하는 방법을 참조하십시오.
kdc1 # svcadm disable network/security/krb5kdc kdc1 # svcadm disable network/security/kadmin
# /usr/sbin/kdb5_util load [-verbose] [-d dbname] [-update] [filename]
복원하려는 각 주체 및 정책의 이름을 인쇄합니다.
복원할 데이터베이스의 이름을 정의합니다. 파일에 대한 절대 경로를 지정할 수 있습니다. -d 옵션을 지정하지 않을 경우 기본 데이터베이스 이름은 /var/krb5/principal입니다.
기존 데이터베이스를 업데이트합니다. 그렇지 않으면 새 데이터베이스가 만들어지거나 기존 데이터베이스를 겹쳐 씁니다.
데이터베이스를 복원할 파일을 정의합니다. 파일에 대한 절대 경로를 지정할 수 있습니다.
kdc1 # svcadm enable -r network/security/krb5kdc kdc1 # svcadm enable -r network/security/kadmin
예 21-20 Kerberos 데이터베이스 복원
다음 예에서는 이름이 database1인 데이터베이스가 dumpfile 파일의 현재 디렉토리에 복원됩니다. -update 옵션이 지정되지 않았으므로 복원을 통해 새 데이터베이스가 만들어집니다.
# kdb5_util load -d database1 dumpfile
KDC 데이터베이스가 Solaris 8 또는 Solaris 9 릴리스를 실행하는 서버에 만들어진 경우 데이터베이스를 변환하면 향상된 데이터베이스 형식을 사용할 수 있습니다.
시작하기 전에
데이터베이스가 오래된 형식을 사용하고 있는지 확인합니다.
KDC 마스터에서 root 역할을 맡아야 합니다. 자세한 내용은 지정된 관리 권한을 사용하는 방법을 참조하십시오.
kdc1 # svcadm disable network/security/krb5kdc kdc1 # svcadm disable network/security/kadmin
kdc1 # mkdir /var/krb5/tmp kdc1 # chmod 700 /var/krb5/tmp
kdc1 # kdb5_util dump /var/krb5/tmp/prdb.txt
kdc1 # cd /var/krb5 kdc1 # mv princ* tmp/
kdc1 # kdb5_util load /var/krb5/tmp/prdb.txt
kdc1 # svcadm enable -r network/security/krb5kdc kdc1 # svcadm enable -r network/security/kadmin
이 절차의 단계를 통해 증분 전파를 사용하도록 기존 마스터 KDC를 재구성할 수 있습니다. 이 절차에서는 다음 구성 매개변수가 사용됩니다.
영역 이름 = EXAMPLE.COM
DNS 도메인 이름 = example.com
마스터 KDC = kdc1.example.com
슬레이브 KDC = kdc2.example.com
admin 주체 = kws/admin
시작하기 전에
root 역할을 맡아야 합니다. 자세한 내용은 지정된 관리 권한을 사용하는 방법을 참조하십시오.
증분 전파를 사용으로 설정하고 KDC 마스터가 로그에 유지할 수 있는 업데이트 수를 선택해야 합니다. 자세한 내용은 kdc.conf(4) 매뉴얼 페이지를 참조하십시오.
kdc1 # cat /etc/krb5/kdc.conf
[kdcdefaults]
kdc_ports = 88,750
[realms]
EXAMPLE.COM= {
profile = /etc/krb5/krb5.conf
database_name = /var/krb5/principal
acl_file = /etc/krb5/kadm5.acl
kadmind_port = 749
max_life = 8h 0m 0s
max_renewable_life = 7d 0h 0m 0s
sunw_dbprop_enable = true
sunw_dbprop_master_ulogsize = 1000
}kiprop 주체는 마스터 KDC 서버를 인증하고 마스터 KDC로부터의 업데이트를 허가하는 데 사용됩니다.
kdc1 # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin: addprinc -randkey kiprop/kdc1.example.com Principal "kiprop/kdc1.example.com@EXAMPLE.COM" created. kadmin: addprinc -randkey kiprop/kdc2.example.com Principal "kiprop/kdc2.example.com@EXAMPLE.COM" created. kadmin:
이 항목은 마스터 KDC가 kdc2 서버의 증분 전파 요청을 수신할 수 있도록 합니다.
kdc1 # cat /etc/krb5/kadm5.acl */admin@EXAMPLE.COM * kiprop/kdc2.example.com@EXAMPLE.COM p
이 단계는 마스터 KDC가 KDC 데이터베이스 복사본을 전파하지 않도록 합니다.
kdc1 # crontab -e #ident "@(#)root 1.20 01/11/06 SMI" # # The root crontab should be used to perform accounting data collection. # # The rtc command is run to adjust the real time clock if and when # daylight savings time changes. # 10 3 * * * /usr/sbin/logadm 15 3 * * 0 /usr/lib/fs/nfs/nfsfind 1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1 30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean #10 3 * * * /usr/lib/krb5kprop_script kdc2.example.sun.com #SUNWkr5ma
kdc1 # svcadm restart network/security/kadmin
전체 지침은 증분 전파를 사용하도록 슬레이브 KDC를 재구성하는 방법을 참조하십시오.
시작하기 전에
root 역할을 맡아야 합니다. 자세한 내용은 지정된 관리 권한을 사용하는 방법을 참조하십시오.
첫번째 새 항목은 증분 전파를 사용으로 설정합니다. 두번째 새 항목은 폴링 시간을 2분으로 설정합니다.
kdc2 # cat /etc/krb5/kdc.conf
[kdcdefaults]
kdc_ports = 88,750
[realms]
EXAMPLE.COM= {
profile = /etc/krb5/krb5.conf
database_name = /var/krb5/principal
acl_file = /etc/krb5/kadm5.acl
kadmind_port = 749
max_life = 8h 0m 0s
max_renewable_life = 7d 0h 0m 0s
sunw_dbprop_enable = true
sunw_dbprop_slave_poll = 2m
}kdc2 # /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
kadmin: ktadd kiprop/kdc2.example.com
Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type AES-256 CTS mode
with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type AES-128 CTS mode
with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type Triple DES cbc
mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type ArcFour
with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type DES cbc mode
with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin: quitkdc2 # svcadm restart network/security/krb5_prop
이 절차에서는 Solaris 10 릴리스를 실행 중인 슬레이브 KDC 서버가 전체 전파를 사용하도록 재구성하는 방법을 보여 줍니다. 일반적으로 마스터 KDC 서버가 Solaris 9 릴리스 또는 이전 릴리스를 실행 중인 경우에만 이 절차를 사용합니다. 이 경우 마스터 KDC 서버는 증분 전파를 지원할 수 없으므로 전파가 작동하려면 슬레이브를 구성해야 합니다.
이 절차에서는 이름이 kdc3인 슬레이브 KDC가 구성됩니다. 이 절차에서는 다음 구성 매개변수를 사용합니다.
영역 이름 = EXAMPLE.COM
DNS 도메인 이름 = example.com
마스터 KDC = kdc1.example.com
슬레이브 KDC = kdc2.example.com 및 kdc3.example.com
admin 주체 = kws/admin
온라인 도움말 URL = http://docs.oracle.com/cd/E23824_01/html/821-1456/aadmin-23.html
시작하기 전에
마스터 KDC를 구성해야 합니다. 이 슬레이브를 교체 가능한 것으로 설정하려는 경우 구체적인 지침은 마스터 KDC와 슬레이브 KDC 교체를 참조하십시오.
마스터 KDC에서 root 역할을 맡아야 합니다. 자세한 내용은 지정된 관리 권한을 사용하는 방법을 참조하십시오.
마스터 KDC를 구성할 때 만든 admin 주체 이름 중 하나로 로그인해야 합니다.
kdc1 # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin:
슬레이브마다 항목을 하나씩 추가해야 합니다. 이 파일에 대한 자세한 설명은 krb5.conf(4) 매뉴얼 페이지를 참조하십시오.
kdc1 # cat /etc/krb5/krb5.conf
.
.
[realms]
EXAMPLE.COM = {
kdc = kdc1.example.com
kdc = kdc2.example.com
kdc = kdc3.example.com
admin_server = kdc1.example.com
}이 파일에 대한 자세한 설명은 kprop(1M) 매뉴얼 페이지를 참조하십시오.
kdc1 # cat /etc/krb5/kpropd.acl host/kdc1.example.com@EXAMPLE.COM host/kdc2.example.com@EXAMPLE.COM host/kdc3.example.com@EXAMPLE.COM
마스터 KDC 서버가 각 KDC 서버에 필요한 정보를 업데이트했으므로 모든 슬레이브 KDC에서 이 단계를 수행해야 합니다. ftp 또는 유사한 전송 방식을 사용하여 마스터 KDC의 다음 파일을 복사할 수 있습니다.
/etc/krb5/krb5.conf
/etc/krb5/kdc.conf
/etc/krb5/kpropd.acl
수정되지 않은 kadm5.acl 파일은 다음과 같이 표시됩니다.
kdc2 # cat /etc/krb5/kadm5.acl */admin@___default_realm___ *
파일에 kiprop 항목이 있을 경우 제거합니다.
마스터 KDC를 구성할 때 만든 admin 주체 이름 중 하나로 로그인해야 합니다.
kdc2 # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin:
이 항목은 kprop 및 기타 Kerberos화된 응용 프로그램이 작동할 수 있도록 합니다. 주체 인스턴스가 호스트 이름인 경우 FQDN은 이름 서비스의 도메인 이름 대소문자에 관계없이 소문자로 지정되어야 합니다.
kadmin: ktadd host/kdc3.example.com
Entry for principal host/kdc3.example.com with kvno 3, encryption type AES-256 CTS mode
with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc3.example.com with kvno 3, encryption type AES-128 CTS mode
with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc3.example.com with kvno 3, encryption type Triple DES cbc
mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc3.example.com with kvno 3, encryption type ArcFour
with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc3.example.com with kvno 3, encryption type DES cbc mode
with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin: kadmin: quit
kprop_script 행의 끝에 각 슬레이브 KDC 서버의 이름을 추가합니다.
10 3 * * * /usr/lib/krb5/kprop_script kdc2.example.com kdc3.example.com
백업 시간을 변경할 수도 있습니다. 이 항목은 매일 오전 3시 10분에 백업 프로세스를 시작합니다.
kdc3 # svcadm enable network/security/krb5_prop
데이터베이스 백업 복사본을 이미 사용할 수 있을 경우 다른 백업을 완료할 필요가 없습니다. 추가 지침은 수동으로 슬레이브 KDC에 Kerberos 데이터베이스를 전파하는 방법을 참조하십시오.
kdc1 # /usr/lib/krb5/kprop_script kdc3.example.com Database propagation to kdc3.example.com: SUCCEEDED
kdc3 # /usr/sbin/kdb5_util stash kdb5_util: Cannot find/read stored master key while reading master key kdb5_util: Warning: proceeding without master key Enter KDC database master key: <Type the key>
NTP(Network Time Protocol)를 설치하여 사용할 필요가 없습니다. 하지만 인증이 성공하려면 모든 클럭이 krb5.conf 파일의 libdefaults 섹션에 정의된 기본 시간에 속해야 합니다. NTP에 대한 자세한 내용은 KDC와 Kerberos 클라이언트 간의 클럭 동기화를 참조하십시오.
kdc3 # svcadm enable network/security/krb5kdc
증분 전파가 구성된 경우 이 절차는 슬레이브 KDC의 정보가 업데이트되었는지 확인합니다.
시작하기 전에
root 역할을 맡아야 합니다. 자세한 내용은 지정된 관리 권한을 사용하는 방법을 참조하십시오.
kdc1 # /usr/sbin/kproplog -h
kdc2 # /usr/sbin/kproplog -h
예 21-21 KDC 서버 동기화 여부 확인
다음은 마스터 KDC 서버에서 kproplog 명령을 실행한 결과의 샘플입니다.
kdc1 # /usr/sbin/kproplog -h
Kerberos update log (/var/krb5/principal.ulog)
Update log dump:
Log version #: 1
Log state: Stable
Entry block size: 2048
Number of entries: 2500
First serial #: 137966
Last serial #: 140465
First time stamp: Fri Nov 28 00:59:27 2004
Last time stamp: Fri Nov 28 01:06:13 2004
다음은 슬레이브 KDC 서버에서 kproplog 명령을 실행한 결과의 샘플입니다.
kdc2 # /usr/sbin/kproplog -h
Kerberos update log (/var/krb5/principal.ulog)
Update log dump:
Log version #: 1
Log state: Stable
Entry block size: 2048
Number of entries: 0
First serial #: None
Last serial #: 140465
First time stamp: None
Last time stamp: Fri Nov 28 01:06:13 2004
최종 일련 번호와 최종 시간 기록의 값이 같은지 확인합니다. 값이 같을 경우 슬레이브가 마스터 KDC 서버와 동기화된 것입니다.
슬레이브 KDC 서버 출력에서 슬레이브 KDC 서버의 업데이트 로그에 업데이트 항목이 존재하지 않는지 확인합니다. 슬레이브 KDC 서버는 마스터 KDC 서버와 달리 일련의 업데이트를 유지하지 않으므로 항목이 존재하지 않습니다. 또한 KDC 슬레이브 서버는 관련 정보가 아닌 첫번째 일련 번호 또는 첫번째 시간 기록에 대한 정보를 포함하지 않습니다.
이 절차에서는 kprop 명령을 사용하여 Kerberos 데이터베이스를 전파하는 방법을 보여 줍니다. 주기적 cron 작업 이외에 슬레이브 KDC를 마스터 KDC와 동기화해야 할 경우 이 절차를 사용하십시오. kprop_script와 달리 kprop를 사용하면 Kerberos 데이터베이스의 새 백업을 만들지 않고도 현재 데이터베이스 백업을 전파할 수 있습니다.
주 - 증분 전파를 사용 중인 경우 이 절차를 사용하지 마십시오.
시작하기 전에
root 역할을 맡아야 합니다. 자세한 내용은 지정된 관리 권한을 사용하는 방법을 참조하십시오.
# /usr/sbin/kdb5_util dump /var/krb5/slave_datatrans
# /usr/lib/krb5/kprop -f /var/krb5/slave_datatrans slave-KDC
예 21-22 kprop_script를 사용하여 수동으로 슬레이브 KDC에 Kerberos 데이터베이스 전파
주기적 cron 작업 이외에 데이터베이스를 백업하여 슬레이브 KDC에 전파하려는 경우에도 다음과 같이 kprop_script 명령을 사용할 수 있습니다.
# /usr/lib/krb5/kprop_script slave-KDC
대부분의 경우 마스터 KDC는 슬레이브 KDC에 Kerberos 데이터베이스를 전파하는 데만 사용됩니다. 하지만 사이트에 KDC가 여러 개 있을 경우 전파 프로세스를 공유하는 로드(병렬 전파라고 함)를 사용할 수 있습니다.
주 - 증분 전파를 사용 중인 경우 이 절차를 사용하지 마십시오.
병렬 전파를 사용하면 특정 슬레이브 KDC가 마스터 KDC와 전파 역할을 공유할 수 있습니다. 이 역할 공유를 통해 전파를 더 빠르게 완료하고 마스터 KDC에 대한 작업을 줄일 수 있습니다.
예를 들어, 사이트에 마스터 KDC가 한 개 있고 슬레이브 KDC가 여섯 개 있으며(그림 21-2 참조) 여기서 slave-1에서 slave-3까지는 하나의 논리적 그룹화로 구성되고 slave-4에서 slave-6까지는 다른 논리적 그룹화로 구성된다고 가정합니다. 이 경우 병렬 전파를 설정하려면 마스터 KDC가 데이터베이스를 slave-1 및 slave-4에 전파하도록 할 수 있습니다. 이런 방법으로 해당 KDC 슬레이브는 데이터베이스를 그룹 내 KDC 슬레이브에 전파할 수 있습니다.
그림 21-2 병렬 전파 구성 예
다음은 자세한 단계별 절차가 아니지만 병렬 전파를 사용으로 설정할 수 있는 높은 레벨의 구성 단계 목록입니다. 이러한 단계에는 다음이 포함됩니다.
마스터 KDC에서 후속 전파(전파 슬레이브)를 수행할 KDC 슬레이브에 대해서만 인수가 포함되도록 cron 작업의 kprop_script 항목을 변경합니다.
각 전파 슬레이브에서 전파할 슬레이브에 대한 인수가 포함되도록 cron 작업에 kprop_script 항목을 추가합니다. 병렬 전파를 성공적으로 수행하려면 새 Kerberos 데이터베이스와 함께 전파 슬레이브가 자체적으로 전파된 후 cron 작업이 실행되도록 설정해야 합니다.
주 - 전파 슬레이브를 전파하는 데 걸리는 시간은 네트워크 대역폭, Kerberos 데이터베이스 크기 등의 인자에 따라 다릅니다.
각 슬레이브 KDC에서 적절한 전파 권한을 설정합니다. 이 단계를 완료하려면 kpropd.acl 파일에 전파하는 KDC의 host 주체 이름을 추가합니다.
예 21-23 병렬 전파 설정
그림 21-2의 예를 사용하면 마스터 KDC의 kprop_script 항목이 다음과 같이 표시됩니다.
0 3 * * * /usr/lib/krb5/kprop_script slave-1.example.com slave-4.example.com
slave-1의 kprop_script 항목은 다음과 같이 표시됩니다.
0 4 * * * /usr/lib/krb5/kprop_script slave-2.example.com slave-3.example.com
마스터가 전파를 수행하고 1시간 후에 슬레이브에서 전파가 시작됩니다.
전파 슬레이브의 kpropd.acl 파일에는 다음 항목이 포함됩니다.
host/master.example.com@EXAMPLE.COM
slave-1이 전파하려는 KDC 슬레이브의 kpropd.acl 파일에는 다음 항목이 포함됩니다.
host/slave-1.example.com@EXAMPLE.COM
stash 파일에는 Kerberos 데이터베이스를 만들 때 자동으로 만들어지는 Kerberos 데이터베이스용 마스터 키가 포함되어 있습니다. stash 파일이 손상된 경우 kdb5_util 유틸리티의 stash 명령을 사용하여 손상된 파일을 바꿀 수 있습니다. kdb5_util의 destroy 명령을 사용하여 Kerberos 데이터베이스를 제거한 후에만 stash 파일을 제거해야 합니다. stash 파일은 데이터베이스와 함께 자동으로 제거되지 않으므로 정리를 완료하려면 stash 파일을 제거해야 합니다.
시작하기 전에
root 역할을 맡아야 합니다. 자세한 내용은 지정된 관리 권한을 사용하는 방법을 참조하십시오.
# rm stash-file
여기서 stash-file은 stash 파일의 경로입니다. 기본적으로 stash 파일은 /var/krb5/.k5. realm에 있습니다.
주 - stash 파일을 다시 만들어야 할 경우 kdb5_util 명령의 -f 옵션을 사용할 수 있습니다.
시작하기 전에
root 역할을 맡아야 합니다. 자세한 내용은 지정된 관리 권한을 사용하는 방법을 참조하십시오.
이 명령은 임의로 생성된 새 마스터 키를 추가합니다. -s 옵션은 새 마스터 키가 기본 keytab에 저장되도록 요청합니다.
# kdb5_util add_mkey -s Creating new master key for master key principal 'K/M@EXAMPLE.COM' You will be prompted for a new database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: <Type the password> Re-enter KDC database master key to verify: <Type it again>
# kdb5_util list_mkeys Master keys for Principal: K/M@EXAMPLE.COM KNVO: 2, Enctype: AES-128 CTS mode with 96-bit SHA-1 HMAC, No activate time set KNVO: 1, Enctype: DES cbc mode with RSA-MD5, Active on: Wed Dec 31 18:00:00 CST 2001 *
이 출력의 별표는 현재 활성 상태의 마스터 키를 식별합니다.
# date Fri Jul 1 17:57:00 CDT 2011 # kdb5_util use_mkey 2 'now+2days' # kdb5_util list_mkeys Master keys for Principal: K/M@EXAMPLE.COM KNVO: 2, Enctype: AES-128 CTS mode with 96-bit SHA-1 HMAC, Active on: Sun Jul 03 17:57:15 CDT 2011 KNVO: 1, Enctype: DES cbc mode with RSA-MD5, Active on: Wed Dec 31 18:00:00 CST 2001 *
이 예에서는 새 마스터 키가 모든 KDC에 전파되도록 충분한 시간을 확보하기 위해 날짜가 2일로 설정됩니다. 환경에 맞게 날짜를 조정합니다.
# kadmin.local -q 'getprinc jimf' |egrep 'Principal|MKey' Authenticating as principal root/admin@EXAMPLE.COM with password. Principal: jimf@EXAMPLE.COM MKey: vno 2
이 예에서는 MKey: vno 2를 통해 주체의 보안 키가 새로 만들어진 마스터 키 2에 의해 보호되고 있음을 알 수 있습니다.
명령 끝에 패턴 인수를 추가할 경우 패턴과 일치하는 주체가 업데이트됩니다. 이 명령 구문에 -n 옵션을 추가하여 업데이트할 주체를 식별합니다.
# kdb5_util update_princ_encryption -f -v Principals whose keys WOULD BE re-encrypted to master key vno 2: updating: host/kdc1.example.com@EXAMPLE.COM skipping: jimf@EXAMPLE.COM updating: kadmin/changepw@EXAMPLE.COM updating: kadmin/history@EXAMPLE.COM updating: kdc/admin@EXAMPLE.COM updating: host/kdc2.example.com@EXAMPLE.COM 6 principals processed: 5 updated, 1 already current
주체 보안 키를 보호하는 데 더 이상 마스터 키가 사용되지 않을 경우 마스터 키 주체에서 제거할 수 있습니다. 이 명령은 주체가 키를 사용하고 있을 경우 키를 제거하지 않습니다. 이 명령에 -n 옵션을 추가하여 올바른 마스터 키가 제거될지 확인합니다.
# kdb5_util purge_mkeys -f -v Purging the follwing master key(s) from K/M@EXAMPLE.COM: KNVO: 1 1 key(s) purged.
# kdb5_util list_mkeys Master keys for Principal: K/M@EXAMPLE.COM KNVO: 2, Enctype: AES-128 CTS mode with 96-bit SHA-1 HMAC, Active on: Sun Jul 03 17:57:15 CDT 2011 *
# kdb5_util stash Using existing stashed keys to update stash file.
# klist -kt /var/krb5/.k5.EXAMPLE.COM Keytab name: FILE:.k5.EXAMPLE.COM KVNO Timestamp Principal ---- ---------------- --------------------------------------------------------- 2 05/07/2011 15:08 K/M@EXAMPLE.COM
|