기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# WorkSpaces 애플리케이션에서 Active Directory 사용
Amazon WorkSpaces 애플리케이션 올웨이즈 온 및 온디맨드 Windows 플릿과 이미지 빌더를 Microsoft Active Directory의 도메인에 조인하고 클라우드 기반 또는 온프레미스의 기존 Active Directory 도메인을 사용하여 도메인 조인 스트리밍 인스턴스를 시작할 수 있습니다. AWS 관리형 Microsoft AD라고 AWS Directory Service for Microsoft Active Directory도 하는를 사용하여 Active Directory 도메인을 생성하고 이를 사용하여 WorkSpaces 애플리케이션 리소스를 지원할 수도 있습니다. AWS Managed Microsoft AD 사용에 대한 자세한 내용은 **AWS Directory Service 관리 안내서의 [Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html)를 참조하세요.
**참고**
Amazon Linux 2 플릿, 이미지 빌더, Elastic 플릿, 앱 블록 빌더는 현재 도메인 조인을 지원하지 않습니다.
WorkSpaces 애플리케이션을 Active Directory 도메인에 조인하여 다음을 수행할 수 있습니다.
+ 사용자와 애플리케이션이 스트리밍 세션에서 프린터나 파일 공유 같은 Active Directory 리소스에 액세스할 수 있습니다.
+ 그룹 정책 관리 콘솔(GPMC)에서 사용할 수 있는 그룹 정책 설정을 사용하여 최종 사용자 환경을 정의합니다.
+ 사용자가 Active Directory 로그인 자격 증명을 사용하여 인증해야 하는 애플리케이션을 스트리밍합니다.
+ WorkSpaces 애플리케이션 스트리밍 인스턴스에 엔터프라이즈 규정 준수 및 보안 정책을 적용합니다.
**Topics**
+ [Active Directory 도메인 개요](active-directory-overview.md)
+ [Amazon WorkSpaces 애플리케이션에서 Active Directory 사용을 시작하기 전에](active-directory-prerequisites.md)
+ [자습서: Active Directory 설정](active-directory-directory-setup.md)
+ [인증서 기반 인증](certificate-based-authentication.md)
+ [WorkSpaces 애플리케이션 Active Directory 관리](active-directory-admin.md)
+ [추가 정보](active-directory-more-info.md)
# Active Directory 도메인 개요
WorkSpaces 애플리케이션에서 Active Directory 도메인을 사용하려면 함께 작동하는 방식과 완료해야 하는 구성 작업을 이해해야 합니다. 다음 작업을 완료해야 합니다.
1. 필요 시 그룹 정책 설정을 구성하여 애플리케이션에 대한 최종 사용자 환경 및 보안 요구 사항을 정의합니다.
1. WorkSpaces 애플리케이션에서 도메인에 조인된 애플리케이션 스택을 생성합니다.
1. SAML 2.0 자격 증명 공급자에서 WorkSpaces 애플리케이션 애플리케이션을 생성하고 이를 직접 또는 Active Directory 그룹을 통해 최종 사용자에게 할당합니다.
사용자가 도메인에 인증되려면 사용자가 WorkSpaces 애플리케이션 스트리밍 세션을 시작할 때 여러 단계를 수행해야 합니다. 다음 다이어그램은 초기 브라우저 요청부터 SAML 및 Active Directory 인증에 이르기까지 종합적인 사용자 인증 흐름을 보여줍니다.
![\[Authentication flow diagram showing steps from user login to AWSWorkSpaces Applications session start.\]](http://docs.aws.amazon.com/ko_kr/appstream2/latest/developerguide/images/domain-join-UPDATED.png)
**사용자 인증 흐름**
1. 사용자가 `https://applications.exampleco.com`으로 이동합니다. 로그온 페이지에서 사용자에 대한 인증을 요청합니다.
1. 연동 서비스가 조직의 자격 증명 스토어에서 인증을 요청합니다.
1. 자격 증명 스토어가 사용자를 인증하고 인증 응답을 연동 서비스에 반환합니다.
1. 인증에 성공하면 연동 서비스가 SAML 어설션을 사용자의 브라우저에 게시합니다.
1. 사용자의 브라우저는 SAML 어설션을 AWS 로그인 SAML 엔드포인트()에 게시합니다`https://signin.aws.amazon.com/saml`. AWS 로그인은 SAML 요청을 수신하고 요청을 처리하며 사용자를 인증하고 인증 토큰을 WorkSpaces 애플리케이션 서비스에 전달합니다.
1. AWS WorkSpaces 애플리케이션은의 인증 토큰을 사용하여 사용자에게 권한을 부여하고 애플리케이션을 브라우저에 제공합니다.
1. 사용자는 애플리케이션을 선택하고 WorkSpaces 애플리케이션 스택에서 활성화된 Windows 로그인 인증 방법에 따라 Active Directory 도메인 암호를 입력하거나 스마트 카드를 선택하라는 메시지가 표시됩니다. 두 인증 방법이 모두 활성화된 경우 사용자는 도메인 암호를 입력할지 아니면 스마트 카드를 사용할지 선택할 수 있습니다. 프롬프트를 제거하고 인증서 기반 인증을 사용해서도 사용자를 인증할 수 있습니다.
1. 사용자 인증을 위해 도메인 컨트롤러에 연결됩니다.
1. 도메인 인증을 마치면 도메인 연결과 함께 사용자 세션이 시작됩니다.
사용자의 관점에서 이 프로세스는 투명합니다. 사용자는 먼저 조직의 내부 포털로 이동하여 자격 AWS 증명을 입력할 필요 없이 WorkSpaces 애플리케이션 애플리케이션 포털로 리디렉션됩니다. Active Directory 도메인 암호 또는 스마트 카드 보안 인증 정보만 있으면 됩니다.
사용자가 이 프로세스를 시작하기 전에 먼저 필요한 권한 및 그룹 정책 설정을 사용하여 Active Directory를 구성하고 도메인에 조인된 애플리케이션 스택을 생성해야 합니다.
# Amazon WorkSpaces 애플리케이션에서 Active Directory 사용을 시작하기 전에
WorkSpaces 애플리케이션에서 Microsoft Active Directory 도메인을 사용하기 전에 다음 요구 사항 및 고려 사항에 유의하세요.
**Topics**
+ [Active Directory 도메인 환경](active-directory-prerequisites-domain-environment.md)
+ [도메인에 조인된 WorkSpaces 애플리케이션 스트리밍 인스턴스](active-directory-prerequisites-streaming-instances.md)
+ [그룹 정책 설정](active-directory-prerequisites-group-policy-settings.md)
+ [스마트 카드 인증](active-directory-prerequisites-smart-card-authentication.md)
# Active Directory 도메인 환경
Active Directory 도메인 환경은 다음 요구 사항을 충족해야 합니다.
+ 스트리밍 인스턴스를 조인할 Microsoft Active Directory 도메인이 필요합니다. Active Directory 도메인이 없거나 온프레미스 Active Directory 환경을 사용하려는 경우 [AWS 파트너 솔루션 배포 가이드의 Active Directory 도메인 서비스를](https://aws-solutions-library-samples.github.io/cfn-ps-microsoft-activedirectory/) 참조하세요.
+ WorkSpaces 애플리케이션에서 사용하려는 도메인에서 컴퓨터 객체를 생성하고 관리할 수 있는 권한이 있는 도메인 서비스 계정이 있어야 합니다. 자세한 내용은 Microsoft 설명서의 [How to Create a Domain Account in Active Directory](https://msdn.microsoft.com/en-us/library/aa545262(v=cs.70).aspx)를 참조하세요.
이 Active Directory 도메인을 WorkSpaces 애플리케이션과 연결할 때 서비스 계정 이름과 암호를 제공합니다. WorkSpaces 애플리케이션은이 계정을 사용하여 디렉터리에서 컴퓨터 객체를 생성하고 관리합니다. 자세한 내용은 [Active Directory 컴퓨터 객체를 생성 및 관리할 수 있는 권한 부여](active-directory-permissions.md) 단원을 참조하십시오.
+ WorkSpaces 애플리케이션에 Active Directory 도메인을 등록할 때 조직 단위(OU) 고유 이름을 제공해야 합니다. 이를 위해 OU를 생성합니다. 기본 컴퓨터 컨테이너는 OU가 아니며 WorkSpaces 애플리케이션에서 사용할 수 없습니다. 자세한 내용은 [조직 단위의 고유 이름 찾기](active-directory-oudn.md) 단원을 참조하십시오.
+ WorkSpaces 애플리케이션에서 사용하려는 디렉터리는 스트리밍 인스턴스가 시작되는 Virtual Private Cloud(VPC)를 통해 정규화된 도메인 이름(FQDNs)을 통해 액세스할 수 있어야 합니다. 자세한 내용은 Microsoft 설명서의 [Active Directory 및 Active Directory 도메인 서비스 포트 요구 사항](https://technet.microsoft.com/en-us/library/dd772723.aspx)을 참조하세요.
+ 도메인 컨트롤러 액세스는 IPv6를 통해 지원될 수 있으며 [DHCP 옵션 세트 업데이트](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html)가 필요합니다.
# 도메인에 조인된 WorkSpaces 애플리케이션 스트리밍 인스턴스
도메인에 조인된 올웨이즈 온 및 온디맨드 플릿에서 애플리케이션 스트리밍을 수행하려면 SAML 2.0 기반 사용자 페더레이션이 필요합니다. [CreateStreamingURL](https://docs.aws.amazon.com/appstream2/latest/APIReference/API_CreateStreamingURL.html) 또는 WorkSpaces 애플리케이션 사용자 풀을 사용하여 도메인에 조인된 인스턴스에 대한 세션을 시작할 수 없습니다.
또한 이미지 빌더 및 플릿을 Active Directory 도메인에 조인하도록 지원하는 이미지를 사용해야 합니다. 2017년 7월 24일 이후로 게시되는 퍼블릭 이미지는 모두 Active Directory 도메인 병합을 지원합니다. 자세한 내용은 [WorkSpaces 애플리케이션 기본 이미지 및 관리형 이미지 업데이트 릴리스 정보](base-image-version-history.md) 및 [자습서: Active Directory 설정](active-directory-directory-setup.md) 섹션을 참조하세요.
**참고**
Always-On 및 온디맨드 플릿 스트리밍 인스턴스를 Active Directory 도메인에 조인할 수 있습니다. 지원되는 운영 체제에는 Windows, Red Hat Enterprise Linux 및 Rocky Linux가 포함됩니다.
# 그룹 정책 설정
다음 그룹 정책 설정에 대한 구성을 확인합니다. 필요한 경우 WorkSpaces 애플리케이션이 도메인 사용자를 인증하고 로그인하는 것을 차단하지 않도록이 섹션에 설명된 대로 설정을 업데이트합니다. 그렇지 않으면 사용자가 WorkSpaces 애플리케이션에 로그인하려고 하면 로그인에 실패할 수 있습니다. 대신 사용자에게 “알 수 없는 오류가 발생했습니다.“라는 메시지가 표시됩니다.
+ **컴퓨터 구성 > 관리 템플릿 > Windows 구성 요소 > Windows 로그온 옵션 > 소프트웨어 보안 주의 시퀀스 비활성화 또는 활성화** - **서비스**에 대해 이 설정을 **활성화됨**으로 설정합니다.
+ **컴퓨터 구성 > 관리 템플릿 > 시스템 > 로그온 > 자격 증명 제공업체 제외** - 다음 CLSID가 나열되지 *않게* 하세요. `e7c1bab5-4b49-4e64-a966-8d99686f8c7c` 및 `f148bAed-5f7f-40c9-8D48-51e24e571825`
+ **컴퓨터 구성 > 정책 > Windows 설정 > 보안 설정 > 로컬 정책 > 보안 옵션 > 대화형 로그온 > 대화형 로그온: 로그온을 시도하는 사용자에 대한 메시지 텍스트** - 이 값을 **정의되지 않음**으로 설정합니다.
+ **컴퓨터 구성 > 정책 > Windows 설정 > 보안 설정 > 로컬 정책 > 보안 옵션 > 대화형 로그온 > 대화형 로그온: 로그온을 시도하는 사용자에 대한 메시지 제목** - 이 값을 **정의되지 않음**으로 설정합니다.
+ **컴퓨터 구성 > 정책 > Windows 설정 > 보안 설정 > 로컬 정책 > 사용자 권한 할당 > 로컬에서 로그온 허용** - 이를 **정의되지 않음**으로 설정하거나 도메인 사용자/그룹을 이 목록에 추가합니다.
+ **컴퓨터 구성 > 정책 > Windows 설정 > 보안 설정 > 로컬 정책 > 사용자 권한 할당 > 로컬에서 로그온 거부** - 이를 **정의되지 않음**으로 설정하거나 도메인 사용자/그룹이 목록에 포함되지 않도록 합니다.
멀티 세션 플릿을 사용하는 경우 위에 지정된 설정 외에도 다음 그룹 정책 설정도 필요합니다.
+ **컴퓨터 구성 > 정책 > Windows 설정 > 보안 설정 > 로컬 정책 > 사용자 권한 할당 > 원격 데스크톱 서비스를 통한 로그인 허용** - 이를 **정의되지 않음**으로 설정하거나 도메인 사용자/그룹을 이 목록에 추가합니다.
+ **컴퓨터 구성 > 정책 > Windows 설정 > 보안 설정 > 로컬 정책 > 사용자 권한 할당 > 원격 데스크톱 서비스를 통한 로그온 거부** - 이를 **정의되지 않음**으로 설정하거나 도메인 사용자/그룹이 목록에 포함되지 않도록 합니다.
# 스마트 카드 인증
WorkSpaces 애플리케이션은 Windows용 [CAC(Common Access Card)](https://www.cac.mil/Common-Access-Card) 및 [PIV(Personal Identity Verification)](https://piv.idmanagement.gov/) 스마트 카드와 같은 Active Directory 도메인 암호 또는 스마트 카드를 WorkSpaces 애플리케이션 스트리밍 인스턴스에 로그인할 수 있도록 지원합니다. 서드 파티 인증 기관(CA)을 사용하여 스마트 카드 로그인을 활성화하도록 Active Directory 환경을 구성하는 방법에 대한 자세한 내용은 Microsoft 설명서에서 [Guidelines for enabling smart card logon with third-party certification authorities](https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/enabling-smart-card-logon-third-party-certification-authorities)를 참조하세요.
**참고**
WorkSpaces 애플리케이션은 사용자가 스트리밍 인스턴스에 로그인한 후 세션 내 인증을 위한 스마트 카드 사용도 지원합니다. 이 기능은 Windows 버전 1.1.257 이상용 WorkSpaces 애플리케이션 클라이언트가 설치된 사용자에게만 지원됩니다. 추가 요구 사항에 관한 자세한 내용은 [스마트 카드](feature-support-USB-devices-qualified.md#feature-support-USB-devices-qualified-smart-cards) 섹션을 참조하세요.
# 자습서: Active Directory 설정
Active Directory를 WorkSpaces 애플리케이션에서 사용하려면 먼저 WorkSpaces 애플리케이션에서 Directory Config 객체를 생성하여 디렉터리 구성을 등록해야 합니다. 이 객체에는 Active Directory 도메인에 스트리밍 인스턴스를 조인하는 데 필요한 정보가 포함되어 있습니다. WorkSpaces 애플리케이션 관리 콘솔, AWS SDK 또는를 사용하여 Directory Config 객체를 생성합니다 AWS CLI. 그러고 나면 디렉터리 구성을 사용하여 도메인에 조인된 올웨이즈 온 및 온디맨드 플릿 및 이미지 빌더를 시작할 수 있습니다.
**참고**
올웨이즈 온 및 온디맨드 플릿 스트리밍 인스턴스만 Active Directory 도메인에 조인할 수 있습니다.
**Topics**
+ [1단계: 디렉터리 구성 객체 생성](#active-directory-setup-config)
+ [2단계: 도메인에 조인된 이미지 빌더를 사용하여 이미지 생성](#active-directory-setup-image-builder)
+ [3단계: 도메인 병합 플릿 생성](#active-directory-setup-fleet)
+ [4단계: SAML 2.0 구성](#active-directory-setup-saml)
## 1단계: 디렉터리 구성 객체 생성
WorkSpaces 애플리케이션에서 생성하는 Directory Config 객체는 이후 단계에서 사용됩니다.
AWS SDK를 사용하는 경우 [CreateDirectoryConfig](https://docs.aws.amazon.com/appstream2/latest/APIReference/API_CreateDirectoryConfig.html) 작업을 사용할 수 있습니다. 를 사용하는 경우 [create-directory-config](https://docs.aws.amazon.com/cli/latest/reference/appstream/create-directory-config.html) 명령을 사용할 AWS CLI수 있습니다.
**WorkSpaces 애플리케이션 콘솔을 사용하여 Directory Config 객체를 생성하려면**
1. [https://console.aws.amazon.com/appstream2](https://console.aws.amazon.com/appstream2) WorkSpaces 애플리케이션 콘솔을 엽니다.
1. 탐색 창에서 **Directory Configs**(디렉터리 구성)를 선택하고 **Create Directory Config**(디렉터리 구성 생성)를 선택합니다.
1. **디렉터리 이름**에는 Active Directory의 정규화된 도메인 이름(FQDN)(예: `corp.example.com`)을 입력합니다. 각 리전마다 [**Directory Config**] 값 하나만 특정 도메인 이름을 가질 수 있습니다.
1. **서비스 계정 이름**에는 컴퓨터 객체를 생성할 수 있고 도메인 조인 권한이 있는 계정의 이름을 입력합니다. 자세한 내용은 [Active Directory 컴퓨터 객체를 생성 및 관리할 수 있는 권한 부여](active-directory-permissions.md) 단원을 참조하십시오. 계정 이름은 `DOMAIN\username` 형식이어야 합니다.
1. **암호** 및 **암호 확인**에는 지정된 계정의 디렉터리 암호를 입력합니다.
1. [**Organizational Unit (OU)**]에 스트리밍 인스턴스 컴퓨터 객체에 대한 하나 이상의 OU의 고유 이름을 입력합니다.
**참고**
OU 이름에는 공백이 있어서는 안 됩니다. 공백이 포함된 OU 이름을 지정하는 경우 플릿 또는 이미지 빌더가 Active Directory 도메인에 다시 조인하려고 하면 WorkSpaces 애플리케이션은 컴퓨터 객체를 올바르게 순환할 수 없으며 도메인 재조인이 성공하지 못합니다. 이 문제를 해결하는 방법에 대한 자세한 내용은 [Active Directory 도메인 병합](troubleshooting-notification-codes.md#troubleshooting-notification-codes-ad)에서 '계정이 이미 있습니다.' 메시지에 대한 *DOMAIN\$1JOIN\$1INTERNAL\$1SERVICE\$1ERROR* 항목을 참조하세요.
또한 기본 컴퓨터 컨테이너는 OU가 아니며 WorkSpaces 애플리케이션에서 사용할 수 없습니다. 자세한 내용은 [조직 단위의 고유 이름 찾기](active-directory-oudn.md) 단원을 참조하십시오.
1. OU를 두 개 이상 추가하려면 **조직 단위(OU)** 옆의 더하기 기호(**\$1**)를 선택합니다. OU를 제거하려면 **x** 아이콘을 선택합니다.
1. **다음**을 선택합니다.
1. 구성 정보를 살펴본 후 [**Create**]를 선택합니다.
## 2단계: 도메인에 조인된 이미지 빌더를 사용하여 이미지 생성
그런 다음 WorkSpaces 애플리케이션 이미지 빌더를 사용하여 Active Directory 도메인 조인 기능을 사용하여 새 이미지를 생성합니다. 단, 플릿과 이미지가 서로 다른 도메인의 구성원일 수도 있습니다. 이미지 빌더를 도메인에 조인하여 도메인 조인을 활성화하고 애플리케이션을 설치하면 됩니다. 플릿 도메인 병합은 다음 단원에서 설명합니다.
**도메인 병합 플릿을 시작하기 위해 이미지를 생성하려면**
1. [자습서: WorkSpaces 애플리케이션 콘솔을 사용하여 사용자 지정 WorkSpaces 애플리케이션 이미지 생성](tutorial-image-builder.md)의 절차를 따르십시오.
1. 기본 이미지 선택 단계에서는 2017년 7월 24일 이후에 릴리스된 AWS 기본 이미지를 사용합니다. 현재 릴리스된 AWS 이미지 목록은 섹션을 참조하세요[WorkSpaces 애플리케이션 기본 이미지 및 관리형 이미지 업데이트 릴리스 정보](base-image-version-history.md).
1. [**Step 3: Configure Network**]에서 Active Directory 환경에 대한 네트워크 연결을 통해 VPC와 서브넷을 선택합니다. VPC 서브넷을 통해 디렉터리에 액세스할 수 있도록 설정된 보안 그룹을 선택합니다.
1. 또한 **3단계: 네트워크 구성**에서 **Active Directory 도메인(선택 사항)** 섹션을 확장한 후 이미지 빌더가 조인되어야 할 **도메인 이름** 값과 **디렉터리 OU** 값을 선택합니다.
1. 이미지 빌더 구성을 살펴본 후 [**Create**]를 선택합니다.
1. 새로운 이미지 빌더가 **Running** 상태로 바뀔 때까지 기다렸다가 [**Connect**]를 선택합니다.
1. 이미지 빌더에 관리자 모드, 또는 로컬 관리자 권한을 가진 디렉터리 사용자로 로그인합니다. 자세한 내용은 [이미지 빌더에 대한 로컬 관리자 권한 부여](active-directory-image-builder-local-admin.md) 단원을 참조하십시오.
1. [자습서: WorkSpaces 애플리케이션 콘솔을 사용하여 사용자 지정 WorkSpaces 애플리케이션 이미지 생성](tutorial-image-builder.md)에서 설명한 단계에 따라 애플리케이션을 설치하고 새 이미지를 생성합니다.
## 3단계: 도메인 병합 플릿 생성
이전 단계에서 생성한 프라이빗 이미지를 사용하여 애플리케이션을 스트리밍할 수 있는 Active Directory 도메인에 조인된 올웨이즈 온 또는 온디맨드 플릿을 생성합니다. 단, 도메인은 이미지 빌더에서 이미지를 생성할 때 사용한 도메인과 다를 수 있습니다.
**도메인에 조인된 올웨이즈 온 또는 온디맨드 플릿을 만드는 방법**
1. [Amazon WorkSpaces 애플리케이션에서 플릿 생성](set-up-stacks-fleets-create.md)의 절차를 따르십시오.
1. 이미지 선택 단계에서는 이전 단계인 [2단계: 도메인에 조인된 이미지 빌더를 사용하여 이미지 생성](#active-directory-setup-image-builder)에서 생성한 이미지를 사용합니다.
1. [**Step 4: Configure Network**]에서 Active Directory 환경에 대한 네트워크 연결을 통해 VPC와 서브넷을 선택합니다. 도메인과 통신할 수 있도록 설정된 보안 그룹을 선택합니다.
1. 또한 **4단계: 네트워크 구성**에서 **Active Directory 도메인(선택 사항)** 섹션을 확장한 후 플릿이 조인되어야 할 **디렉터리 이름** 값과 **디렉터리 OU** 값을 선택합니다.
1. 플릿 구성을 살펴본 후 [**Create**]를 선택합니다.
1. 플릿이 스택과 연결되어 실행되도록 [Amazon WorkSpaces 애플리케이션 플릿 및 스택 생성](set-up-stacks-fleets.md)에 설명된 나머지 단계를 완료합니다.
## 4단계: SAML 2.0 구성
사용자는 SAML 2.0 기반 자격 증명 연동 환경을 사용하여 도메인에 조인된 플릿에서 스트리밍 세션을 시작해야 합니다.
**SSO(Single Sign-On) 액세스가 가능하도록 SAML 2.0을 구성하려면**
1. [SAML 설정](external-identity-providers-setting-up-saml.md)의 절차를 따르십시오.
1. WorkSpaces 애플리케이션에서는 로그인하는 사용자의 SAML\$1Subject `NameID` 값을 다음 형식 중 하나로 제공해야 합니다.
+ sAMAccountName을 사용하는 `domain\username`
+ userPrincipalName을 사용하는 `username@domain.com`
sAMAccountName 형식을 사용하는 경우에는 NetBIOS 이름 또는 전체 도메인 이름(FQDN)을 사용하여 `domain`을 지정할 수 있습니다.
1. Active Directory 사용자 또는 그룹에 액세스 권한을 제공하여 ID 제공업체 애플리케이션 포털에서 WorkSpaces 애플리케이션 스택에 액세스할 수 있도록 합니다.
1. [SAML 설정](external-identity-providers-setting-up-saml.md)에 설명된 나머지 단계를 완료합니다.
**SAML 2.0을 사용하여 로그인하려면**
1. SAML 2.0 공급자의 애플리케이션 카탈로그에 로그인하고 이전 절차에서 생성한 WorkSpaces 애플리케이션 SAML 애플리케이션을 엽니다.
1. WorkSpaces 애플리케이션 카탈로그가 표시되면 시작할 애플리케이션을 선택합니다.
1. 로딩 아이콘이 표시되면 암호를 입력하라는 메시지가 나타납니다. SAML 2.0 자격 증명 공급자가 제공하는 도메인 사용자 이름이 암호 필드 위에 표시됩니다. 암호를 입력하고 **로그인**을 선택합니다.
스트리밍 인스턴스가 Windows 로그인 절차를 진행하고, 이후 선택한 애플리케이션이 열립니다.
# 인증서 기반 인증
Microsoft Active Directory에 조인된 WorkSpaces 애플리케이션 플릿에서 인증서 기반 인증을 사용할 수 있습니다. 이렇게 하면 사용자가 로그인할 때 Active Directory 도메인 암호를 입력하라는 메시지가 표시되지 않습니다. Active Directory 도메인에서 인증서 기반 인증을 사용하면 다음과 같은 작업을 수행할 수 있습니다.
+ SAML 2.0 ID 제공업체를 통해 사용자를 인증하고 Active Directory의 사용자와 매칭하도록 SAML 어설션을 제공할 수 있습니다.
+ 사용자 프롬프트 수를 줄여 Single Sign-On 로그온 경험을 생성할 수 있습니다.
+ SAML 2.0 ID 제공업체를 사용하여 암호 없는 인증 흐름을 활성화할 수 있습니다.
인증서 기반 인증은에서 AWS 프라이빗 인증 기관(AWS 프라이빗 CA) 리소스를 사용합니다 AWS 계정. AWS Private CA를 사용하면 루트 및 하위 CA를 포함한 사설 인증 기관(CA) 계층 구조를 생성할 수 CAs. 또한 자체 CA 계층 구조를 만들고 이 계층 구조를 사용하여 내부 사용자를 인증하는 데 사용할 인증서를 발급할 수 있습니다. 자세한 내용은 [란 무엇입니까? AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html)를 참조하십시오.
인증서 기반 인증에 AWS Private CA를 사용하는 경우 WorkSpaces 애플리케이션은 각 WorkSpaces 애플리케이션 플릿 인스턴스의 세션 예약 시 사용자를 위해 인증서를 자동으로 요청합니다. 사용자는 인증서로 프로비저닝된 가상 스마트 카드를 사용하여 Active Directory에 인증됩니다.
인증서 기반 인증(CBA)은 Windows 인스턴스를 실행하는 WorkSpaces Applications 도메인에 조인된 플릿(단일 세션 및 다중 세션 플릿 모두)에서 지원됩니다. 다중 세션 플릿에서 CBA를 활성화하려면 02-07-2025 또는 그 이후에 릴리스된 WorkSpaces 애플리케이션 에이전트를 사용하는 WorkSpaces 애플리케이션 이미지를 사용해야 합니다. 또는 이미지는 02-11-2025 또는 그 이후에 릴리스된 관리형 WorkSpaces 애플리케이션 이미지 업데이트를 사용해야 합니다.
**Topics**
+ [사전 조건](certificate-based-authentication-prereq.md)
+ [인증서 기반 인증 활성화](certificate-based-authentication-enable.md)
+ [인증서 기반 인증 관리](certificate-based-authentication-manage.md)
+ [교차 계정 PCA 공유 활성화](pca-sharing.md)
# 사전 조건
인증서 기반 인증을 사용하기 전에 다음 단계를 완료하세요.
1. 도메인에 조인된 플릿을 설정하고 SAML 2.0을 구성합니다. SAML\$1Subject `NameID`에 `username@domain.com` `userPrincipalName` 형식을 사용해야 합니다. 자세한 내용은 [5단계: SAML 인증 응답을 위한 어설션 생성](external-identity-providers-setting-up-saml.md#external-identity-providers-create-assertions) 단원을 참조하십시오.
**참고**
인증서 기반 인증을 사용하려는 경우 스택에서 **Active Directory에 대한 스마트 카드 로그인**을 활성화하지 마세요. 자세한 내용은 [스마트 카드](feature-support-USB-devices-qualified.md#feature-support-USB-devices-qualified-smart-cards) 단원을 참조하십시오.
1. 이미지와 함께 WorkSpaces Applications 에이전트 버전 10-13-2022 이상을 사용합니다. 자세한 내용은 [Amazon WorkSpaces 애플리케이션 이미지를 Up-to-Date 유지](keep-image-updated.md) 단원을 참조하십시오.
1. SAML 어설션에서 `ObjectSid` 속성을 구성합니다. 이 속성을 사용하여 Active Directory 사용자와 강력한 매핑을 수행할 수 있습니다. `ObjectSid` 속성이 SAML\$1Subject `NameID`에 지정된 사용자의 Active Directory 보안 식별자(SID)와 매칭되지 않으면 인증서 기반 인증이 실패합니다. 자세한 내용은 [5단계: SAML 인증 응답을 위한 어설션 생성](external-identity-providers-setting-up-saml.md#external-identity-providers-create-assertions) 단원을 참조하십시오. `ObjectSid`는 2025년 9월 10일 이후 인증서 기반 인증에 필수입니다. 자세한 내용은 Microsoft 지원 설명서에서 [KB5014754: Windows 도메인 컨트롤러의 인증서 기반 인증 변경](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16)을 참조하세요.
1. SAML 2.0 구성에서 사용하는 IAM 역할 신뢰 정책에 `sts:TagSession` 권한을 추가합니다. 자세한 내용은 [AWS STS에서 세션 태그 전달](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html.html)을 참조하세요. 인증서 기반 인증을 사용하려면 이 권한이 필요합니다. 자세한 내용은 [2단계: SAML 2.0 페더레이션 IAM 역할 생성](external-identity-providers-setting-up-saml.md#external-identity-providers-grantperms) 단원을 참조하십시오.
1. Active Directory로 구성되지 않은 경우 Private CA를 사용하여 AWS 프라이빗 인증 기관(CA)을 생성합니다. 인증서 기반 인증을 사용하려면 AWS 프라이빗 CA가 필요합니다. 자세한 내용은 [AWS Private CA 배포 계획](https://docs.aws.amazon.com/privateca/latest/userguide/PcaPlanning.html)을 참조하세요. 다음과 같은 AWS 사설 CA 설정은 많은 인증서 기반 인증 사용 사례에 공통됩니다.
+ **CA 유형 옵션**
+ **수명이 짧은 인증서 CA 사용 모드** - 인증서 기반 인증을 위한 최종 사용자 인증서를 발급하는 데만 CA를 사용하는 경우 권장됩니다.
+ **루트 CA를 사용한 단일 수준 계층 구조** - 기존 CA 계층 구조와 통합하려는 경우 하위 CA를 선택합니다.
+ **키 알고리즘 옵션** - RSA 2048
+ **주체 고유 이름 옵션** - Active Directory Trusted Root Certification Authorities 저장소에서 가장 적합한 옵션을 사용하여 이 CA를 식별합니다.
+ **인증서 취소 옵션** - CRL 배포
**참고**
인증서 기반 인증에는 WorkSpaces Applications 플릿 인스턴스와 도메인 컨트롤러 모두에서 액세스할 수 있는 온라인 CRL 배포 지점이 필요합니다. 이를 위해서는 AWS Private CA CRL 항목용으로 구성된 Amazon S3 버킷에 대한 인증되지 않은 액세스 또는 퍼블릭 액세스를 차단하는 경우 Amazon S3 버킷에 액세스할 수 있는 CloudFront 배포가 필요합니다. 옵션에 대한 자세한 내용은 [인증서 취소 목록(CRL) 계획](https://docs.aws.amazon.com/privateca/latest/userguide/crl-planning.html)을 참조하세요.
1. WorkSpaces Applications 인증서 기반 인증에 사용할 CA를 지정할 `euc-private-ca` 권한이 있는 키로 프라이빗 CA에 태그를 지정합니다. 이 키는 값이 필요하지 않습니다. 자세한 내용은 [프라이빗 CA의 태그 관리](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCaTagging.html)를 참조하세요. WorkSpaces 애플리케이션과 함께 사용하여의 리소스에 권한을 부여하는 AWS 관리형 정책에 대한 자세한 내용은 섹션을 AWS 계정참조하세요[AWS WorkSpaces 애플리케이션 리소스에 액세스하는 데 필요한 관리형 정책](managed-policies-required-to-access-appstream-resources.md).
1. 인증서 기반 인증은 로그온에 가상 스마트 카드를 사용합니다. 자세한 내용은 [타사 인증 기관과 함께 스마트 카드 로그온을 활성화하기 위한 지침](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/enabling-smart-card-logon-third-party-certification-authorities)을 참조하세요. 다음 단계를 따릅니다.
1. 도메인 컨트롤러 인증서를 사용하여 도메인 컨트롤러를 구성하여 스마트 카드 사용자를 인증합니다. Active Directory에 Active Directory Certificate Services 엔터프라이즈 CA가 구성되어 있는 경우 스마트 카드 로그온을 활성화하는 인증서가 포함된 도메인 컨트롤러가 자동으로 등록됩니다. Active Directory 인증서 서비스가 없는 경우 [타사 CA의 도메인 컨트롤러 인증서 요구 사항을](https://learn.microsoft.com/en-US/troubleshoot/windows-server/windows-security/requirements-domain-controller) 참조하세요. Active Directory 엔터프라이즈 인증 기관에서 도메인 컨트롤러 인증서 등록을 자동으로 관리할 것을 AWS 권장합니다.
**참고**
AWS 관리형 Microsoft AD를 사용하는 경우 도메인 컨트롤러 인증서에 대한 요구 사항을 충족하는 Amazon EC2 인스턴스에서 Certificate Services를 구성할 수 있습니다. [Active Directory 인증서 서비스로 구성된 관리형 Microsoft AD의 배포 예제는 새 Amazon Virtual Private Cloud](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-ad-deploying-new-vpc.html)에 Active Directory 배포를 참조하세요. AWS
AWS 관리형 Microsoft AD 및 Active Directory 인증서 서비스를 사용하면 컨트롤러의 VPC 보안 그룹에서 인증서 서비스를 실행하는 Amazon EC2 인스턴스로 아웃바운드 규칙도 생성해야 합니다. 인증서 자동 등록을 활성화하려면 TCP 포트 135와 포트 49152\$165535에 대한 보안 그룹 액세스 권한을 제공해야 합니다. 또한 Amazon EC2 인스턴스는 도메인 컨트롤러를 포함한 도메인 인스턴스로부터 동일한 포트에 대한 인바운드 액세스를 허용해야 합니다. AWS 관리형 Microsoft AD의 보안 그룹을 찾는 방법에 대한 자세한 내용은 [VPC 서브넷 및 보안 그룹 구성을 참조하세요](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_setup_trust_prepare_mad.html#tutorial_setup_trust_open_vpc).
1. AWS 프라이빗 CA 콘솔 또는 SDK 또는 CLI를 사용하여 프라이빗 CA 인증서를 내보냅니다. 자세한 내용은 [프라이빗 인증서 내보내기](https://docs.aws.amazon.com/acm/latest/userguide/export-private.html)를 참조하세요.
1. 프라이빗 CA를 Active Directory에 게시합니다. 도메인 컨트롤러 또는 도메인에 조인된 시스템에 로그온합니다. 프라이빗 CA 인증서를 원하는 `\`에 복사하고 도메인 관리자로 다음 명령을 실행합니다. 또한 그룹 정책 및 Microsoft PKI Health Tool(PKIView)을 사용하여 CA를 게시할 수도 있습니다. 자세한 내용은 [구성 지침](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/enabling-smart-card-logon-third-party-certification-authorities#configuration-instructions)을 참조하세요.
```
certutil -dspublish -f \ RootCA
```
```
certutil -dspublish -f \ NTAuthCA
```
명령이 성공적으로 완료되었는지 확인한 다음 프라이빗 CA 인증서 파일을 제거하세요. Active Directory 복제 설정에 따라 CA가 도메인 컨트롤러 및 WorkSpaces 애플리케이션 플릿 인스턴스에 게시하는 데 몇 분 정도 걸릴 수 있습니다.
**참고**
Active Directory는 도메인에 가입할 때 WorkSpaces 애플리케이션 플릿 인스턴스에 대해 신뢰할 수 있는 루트 인증 기관 및 엔터프라이즈 NTAuth 스토어에 CA를 자동으로 배포해야 합니다.
Windows 운영 체제의 경우 CA(인증 기관) 배포가 자동으로 수행됩니다. 그러나 Rocky Linux 및 Red Hat Enterprise Linux의 경우 WorkSpaces Applications Directory Config에서 사용하는 CA에서 루트 CA 인증서(들)를 다운로드해야 합니다. KDC 루트 CA 인증서가 다른 경우 해당 인증서도 다운로드해야 합니다. 인증서 기반 인증을 사용하기 전에 이러한 인증서를 이미지 또는 스냅샷으로 가져와야 합니다.
이미지에 /`etc/sssd/pki/sssd_auth_ca_db.pem`이라는 파일이 있어야 합니다. 이 템플릿은 다음과 같습니다.
```
-----BEGIN CERTIFICATE-----
Base64-encoded certificate chain from ACM Private CA
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64-encoded certificate body from ACM private CA
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64-encoded root CA KDC certificate chain
-----END CERTIFICATE-----
```
**참고**
리전 또는 계정 간에 이미지를 복사하거나 이미지를 새 Active Directory에 다시 연결할 경우, 이 파일을 사용하기 전에 이미지 빌더에서 관련 인증서를 사용하여 다시 구성하고 스냅샷을 다시 생성해야 합니다.
다음은 루트 CA 인증서 다운로드 지침입니다.
1. 이미지 빌더에서 `/etc/sssd/pki/sssd_auth_ca_db.pem`이라는 파일을 생성합니다.
1. [AWS Private CA 콘솔](https://console.aws.amazon.com/acm-pca/)을 엽니다.
1. WorkSpaces 애플리케이션 디렉터리 구성에 사용되는 프라이빗 인증서를 선택합니다.
1. **CA 인증서** 탭을 선택합니다.
1. 인증서 체인과 인증서 본문을 이미지 빌더의 `/etc/sssd/pki/sssd_auth_ca_db.pem`에 복사합니다.
KDCs에서 사용하는 루트 CA 인증서가 WorkSpaces Applications Directory Config에서 사용하는 루트 CA 인증서와 다른 경우 다음 예제 단계에 따라 다운로드합니다.
1. 이미지 빌더와 동일한 도메인에 조인된 Windows 인스턴스에 연결합니다.
1. `certlm.msc`를 엽니다.
1. 왼쪽 창에서 **신뢰할 수 있는 루트 인증 기관**을 선택한 다음 **인증서**를 선택합니다.
1. 각 루트 CA 인증서에 대해 컨텍스트(마우스 오른쪽 버튼 클릭) 메뉴를 엽니다.
1. **모든 작업**을 선택하고 **내보내기**를 선택하여 인증서 내보내기 마법사를 연 후 **다음**을 선택합니다.
1. **Base64 인코딩 X.509(.CER)**를 선택하고 **다음**을 선택합니다.
1. **찾아보기**를 선택하고 파일 이름을 입력한 후 **다음**을 선택합니다.
1. **마침**을 클릭합니다.
1. 내보낸 인증서를 텍스트 편집기에서 엽니다.
1. 파일 내용을 이미지 빌더의 `/etc/sssd/pki/sssd_auth_ca_db.pem`으로 복사합니다.
# 인증서 기반 인증 활성화
인증서 기반 인증을 활성화하려면 다음 단계를 완료하세요.
**인증서 기반 인증을 활성화하는 방법**
1. [https://console.aws.amazon.com/appstream2](https://console.aws.amazon.com/appstream2) WorkSpaces 애플리케이션 콘솔을 엽니다.
1. 탐색 창에서 **Directory Configs**를 선택합니다. 구성하려는 디렉터리 구성을 선택하고 **편집**을 선택합니다.
1. **인증서 기반 인증 활성화**를 선택합니다.
1. 프라이빗 CA ARN이 목록에 연결되어 있는지 확인합니다. 목록에 표시하려면 프라이빗 CA를 동일한 AWS 계정 및에 저장해야 합니다 AWS 리전. 또한 프라이빗 CA에 이름이 `euc-private-ca`인 키를 태그해야 합니다.
1. 폴백에서 디렉터리 로그를 구성합니다. 폴백을 사용하면 인증서 기반 인증에 실패한 경우 사용자가 AD 도메인 암호를 사용하여 로그인할 수 있습니다. 사용자가 도메인 비밀번호를 알고 있는 경우에만 권장되는 방법입니다. 폴백을 해제하면 잠금 화면이나 Windows 로그오프가 발생할 경우 세션에서 사용자 연결을 끊을 수 있습니다. 폴백이 켜져 있는 경우 세션은 사용자에게 AD 도메인 암호를 입력하라는 메시지를 표시합니다.
1. **변경 사항 저장(Save Changes)**을 선택합니다.
1. 인증서 기반 인증이 이제 활성화되었습니다. 사용자가 WorkSpaces 애플리케이션 웹 클라이언트 또는 Windows용 클라이언트(버전 1.1.1099 이상)의 도메인 조인 플릿을 사용하여 WorkSpaces 애플리케이션 스택에 SAML 2.0으로 인증하면 더 이상 도메인 암호에 대한 프롬프트가 표시되지 않습니다. 사용자가 인증서 기반 인증이 활성화된 세션에 연결할 때 '인증서 기반 인증으로 연결 중...'이라는 메시지가 표시됩니다.
# 인증서 기반 인증 관리
인증서 기반 인증을 활성화한 후 다음 작업을 검토하세요.
**Topics**
+ [프라이빗 CA 인증서](certificate-based-authentication-manage-CA.md)
+ [최종 사용자 인증서](certificate-based-authentication-manage-certs.md)
+ [감사 보고서](certificate-based-authentication-manage-audit.md)
+ [로깅 및 모니터링](certificate-based-authentication-manage-logging.md)
# 프라이빗 CA 인증서
일반적인 구성에서 프라이빗 CA 인증서의 유효 기간은 10년입니다. 프라이빗 CA를 만료된 인증서로 교체하거나 프라이빗 CA를 새 유효 기간으로 재발급하는 방법에 대한 자세한 내용은 [프라이빗 CA 수명 주기 관리](https://docs.aws.amazon.com/privateca/latest/userguide/ca-lifecycle.html)를 참조하세요.
# 최종 사용자 인증서
WorkSpaces 애플리케이션용 AWS Private CA에서 발급한 최종 사용자 인증서 인증서 기반 인증에는 갱신 또는 취소가 필요하지 않습니다. 이러한 인증서는 수명이 짧습니다. WorkSpaces 애플리케이션은 각 새 세션에 대해 새 인증서를 자동으로 발급하거나 기간이 긴 세션의 경우 24시간마다 새 인증서를 발급합니다. WorkSpaces 애플리케이션 세션은 이러한 최종 사용자 인증서의 사용을 관리합니다. 세션을 종료하면 WorkSpaces 애플리케이션은 해당 인증서 사용을 중지합니다. 이러한 최종 사용자 인증서의 유효 기간은 일반적인 AWS 사설 CA CRL 배포보다 짧습니다. 따라서 최종 사용자 인증서를 취소할 필요가 없으며 CRL에 표시되지 않습니다.
# 감사 보고서
프라이빗 CA가 발급 또는 취소한 모든 인증서를 나열하는 감사 보고서를 만들 수 있습니다. 자세한 내용은 [프라이빗 CA에서 감사 보고서 사용](https://docs.aws.amazon.com/privateca/latest/userguide/PcaAuditReport.html)을 참조하세요.
# 로깅 및 모니터링
CloudTrail을 사용하여 WorkSpaces 애플리케이션을 통해 프라이빗 CA에 대한 API 호출을 기록할 수 있습니다. 자세한 내용은 [AWS CloudTrail이란 무엇입니까?](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) 및 [CloudTrail 사용](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCtIntro.html)을 참조하세요. CloudTrail 이벤트 기록에서 WorkSpaces Applications**EcmAssumeRoleSession** 사용자 이름으로 만든 **acm-pca.amazonaws.com** 이벤트 소스의 **GetCertificate** 및 **IssueCertificate** 이벤트 이름을 볼 수 있습니다. 이러한 이벤트는 모든 WorkSpaces 애플리케이션 인증서 기반 인증 요청에 대해 기록됩니다. 자세한 내용은 [CloudTrail 이벤트 기록을 사용하여 이벤트 보기](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html)를 참조하세요.
# 교차 계정 PCA 공유 활성화
프라이빗 CA(PCA) 교차 계정 공유는 중앙 집중식 CA를 사용할 수 있는 권한을 다른 계정에 부여하는 기능을 제공합니다. CA는 [AWS Resource Access Manager](https://aws.amazon.com/ram/)(RAM)를 통해 권한을 관리하여 인증서를 생성하고 발급할 수 있습니다. 이렇게 하면 모든 계정에서 프라이빗 CA를 사용할 필요가 없습니다. 프라이빗 CA 교차 계정 공유는 동일한 내에서 WorkSpaces 애플리케이션 인증서 기반 인증(CBA)과 함께 사용할 수 있습니다 AWS 리전.
WorkSpaces Applications CBA에서 공유 Private CA 리소스를 사용하려면 다음 단계를 완료하세요.
1. 중앙 집중식에서 CBA용 프라이빗 CA를 구성합니다 AWS 계정. 자세한 내용은 [인증서 기반 인증](certificate-based-authentication.md) 단원을 참조하십시오.
1. WorkSpaces 애플리케이션 리소스 AWS 계정 가 CBA를 사용하는 리소스와 프라이빗 CA를 공유합니다. 이렇게 하려면 [AWS RAM을 사용하여 ACM Private CA 교차 계정을 공유하는 방법](https://aws.amazon.com/blogs/security/how-to-use-aws-ram-to-share-your-acm-private-ca-cross-account/)의 단계를 따릅니다. 인증서를 생성하기 위해 3단계를 완료할 필요는 없습니다. 프라이빗 CA를 개인과 공유 AWS 계정하거나를 통해 공유할 수 있습니다 AWS Organizations. 개별 계정과 공유하는 경우 AWS Resource Access Manager 콘솔 또는 APIs.
공유를 구성할 때 AWS Resource Access Manager 리소스 계정의 프라이빗 CA에 대한 리소스 공유가 `AWSRAMBlankEndEntityCertificateAPICSRPassthroughIssuanceCertificateAuthority` 관리형 권한 템플릿을 사용하고 있는지 확인합니다. 이 템플릿은 CBA 인증서를 발급할 때 WorkSpaces 애플리케이션 서비스 역할에서 사용하는 PCA 템플릿과 일치합니다.
1. 공유가 성공하면 리소스 계정의 프라이빗 CA 콘솔을 사용하여 공유 프라이빗 CA를 봅니다.
1. API 또는 CLI를 사용하여 WorkSpaces Applications Directory Config에서 프라이빗 CA ARN을 CBA와 연결합니다. 현재 WorkSpaces 애플리케이션 콘솔은 공유 프라이빗 CA ARNs 선택을 지원하지 않습니다. 다음은 CLI 명령 예시입니다.
`aws appstream update-directory-config --directory-name --certificate-based-auth-properties Status=,CertificateAuthorityArn=`
# WorkSpaces 애플리케이션 Active Directory 관리
WorkSpaces 애플리케이션에서 Active Directory를 설정하고 사용하려면 다음과 같은 관리 작업이 필요합니다.
**Topics**
+ [Active Directory 컴퓨터 객체를 생성 및 관리할 수 있는 권한 부여](active-directory-permissions.md)
+ [조직 단위의 고유 이름 찾기](active-directory-oudn.md)
+ [이미지 빌더에 대한 로컬 관리자 권한 부여](active-directory-image-builder-local-admin.md)
+ [도메인 병합에 사용되는 서비스 계정 업데이트](active-directory-service-acct.md)
+ [사용자 유휴 시 스트리밍 세션 잠금](active-directory-session-lock.md)
+ [디렉터리 구성 편집](active-directory-config-edit.md)
+ [디렉터리 구성 삭제](active-directory-config-delete.md)
+ [도메인 트러스트를 사용하도록 WorkSpaces 애플리케이션 구성](active-directory-domain-trusts.md)
+ [Active Directory에서 WorkSpaces 애플리케이션 컴퓨터 객체 관리](active-directory-identify-objects.md)
# Active Directory 컴퓨터 객체를 생성 및 관리할 수 있는 권한 부여
WorkSpaces 애플리케이션이 Active Directory 컴퓨터 객체 작업을 수행하도록 허용하려면 충분한 권한이 있는 계정이 필요합니다. 가장 좋은 방법은 필요한 최소 권한만을 가진 계정을 사용하는 것입니다. Active Directory 조직 단위(OU)의 최소 권한은 다음과 같습니다.
+ 컴퓨터 객체 생성
+ 암호 변경
+ 암호 재설정
+ 설명 쓰기
권한을 설정하려면 먼저 다음 작업을 수행해야 합니다.
+ 도메인에 조인되는 컴퓨터 또는 EC2 인스턴스에 대한 액세스 권한을 확보합니다.
+ Active Directory User and Computers MMC 스냅인을 설치합니다. 자세한 내용은 Microsoft 설명서의 [Windows 7용 원격 서버 관리 도구의 설치 또는 제거](https://technet.microsoft.com/en-us/library/ee449483.aspx)를 참조하세요.
+ OU 보안 설정을 수정할 수 있는 권한이 부여된 도메인 사용자로 로그인합니다.
+ 권한을 위임할 사용자, 서비스 계정 또는 그룹을 생성하거나 식별합니다.
**최소 권한을 설정하려면**
1. 도메인에서 또는 도메인 컨트롤러에서 **Active Directory 사용자 및 컴퓨터**를 엽니다.
1. 왼쪽 탐색 창에서 도메인 조인 권한을 부여할 첫 번째 OU를 선택하고 컨텍스트(마우스 오른쪽 버튼 클릭) 메뉴를 연 다음 **제어 위임**을 선택합니다.
1. **제어 위임 마법사** 페이지에서 **다음**과 **추가**를 차례대로 선택합니다.
1. **사용자, 컴퓨터 또는 그룹 선택**에서 사전 생성된 사용자, 서비스 계정 또는 그룹을 선택한 다음 **확인**을 선택합니다.
1. **위임할 작업** 페이지에서 **위임할 사용자 지정 작업 만들기**를 선택하고 **다음**을 선택합니다.
1. **폴더의 다음 객체만**과 **컴퓨터 객체**를 차례대로 선택합니다.
1. **이 폴더에서 선택한 객체 생성**과 **다음**을 차례대로 선택합니다.
1. **권한**에서 **읽기**, **쓰기**, **비밀번호 변경**, **비밀번호 초기화**, **다음**을 차례대로 선택합니다.
1. **제어 위임 마법사 완료** 페이지에서 정보를 확인하고 **완료**를 선택합니다.
1. 이러한 권한이 필요한 OU가 더 있는 경우에는 2\$19단계를 반복합니다.
그룹에 권한을 위임한 경우에는 강력한 암호로 사용자 또는 서비스 계정을 생성한 다음 이 계정을 그룹에 추가합니다. 그러면 이 계정은 스트리밍 인스턴스를 디렉터리에 연결할 수 있는 충분한 권한을 갖게 됩니다. WorkSpaces Applications 디렉터리 구성을 생성할 때이 계정을 사용합니다.
# 조직 단위의 고유 이름 찾기
WorkSpaces 애플리케이션에 Active Directory 도메인을 등록할 때 조직 단위(OU) 고유 이름을 제공해야 합니다. 이를 위해 OU를 생성합니다. 기본 컴퓨터 컨테이너는 OU가 아니며 WorkSpaces 애플리케이션에서 사용할 수 없습니다. 다음은 고유 이름을 가져오는 방법을 나타낸 절차입니다.
**참고**
고유 이름은 **OU=**로 시작해야 하며 그렇지 않은 경우 컴퓨터 객체에 사용할 수 없습니다.
이 절차를 완료하기 전에 먼저 다음을 수행해야 합니다.
+ 도메인에 조인되는 컴퓨터 또는 EC2 인스턴스에 대한 액세스 권한을 확보합니다.
+ Active Directory User and Computers MMC 스냅인을 설치합니다. 자세한 내용은 Microsoft 설명서의 [Windows 7용 원격 서버 관리 도구의 설치 또는 제거](https://technet.microsoft.com/en-us/library/ee449483.aspx)를 참조하세요.
+ OU 보안 속성을 읽을 수 있는 권한이 부여된 도메인 사용자로 로그인합니다.
**OU의 고유 이름을 찾으려면**
1. 도메인에서 또는 도메인 컨트롤러에서 **Active Directory 사용자 및 컴퓨터**를 엽니다.
1. **보기** 아래에서 **고급 기능**이 활성화되어 있는지 확인합니다.
1. 왼쪽 탐색 창에서 WorkSpaces Applications 스트리밍 인스턴스 컴퓨터 객체에 사용할 첫 번째 OU를 선택하고 컨텍스트(마우스 오른쪽 버튼 클릭) 메뉴를 연 다음 **속성을** 선택합니다.
1. **속성 편집기**를 선택합니다.
1. **속성** 아래 있는 **distinguishedName**에서 **보기**를 선택합니다.
1. **값**에서 고유 이름을 선택하고 컨텍스트 메뉴를 연 다음 **복사**를 선택합니다.
# 이미지 빌더에 대한 로컬 관리자 권한 부여
기본적으로 Active Directory 도메인 사용자는 이미지 빌더 인스턴스에 대한 로컬 관리자 권한이 없습니다. 하지만 이러한 권한은 디렉터리에서 그룹 정책 기본 설정을 사용하여 부여하거나, 또는 이미지 빌더의 로컬 관리자 계정에서 수동으로 부여할 수 있습니다. 도메인 사용자에게 로컬 관리자 권한을 부여하면 해당 사용자가에 애플리케이션을 설치하고 WorkSpaces 애플리케이션 이미지 빌더에서 이미지를 생성할 수 있습니다.
**Topics**
+ [그룹 정책 기본 설정 사용](group-policy.md)
+ [이미지 빌더에 로컬 관리자 그룹 사용](manual-procedure.md)
# 그룹 정책 기본 설정 사용
그룹 정책 기본 설정을 사용하여 Active Directory 사용자 또는 그룹과 지정된 OU의 모든 컴퓨터 객체에 로컬 관리자 권한을 부여할 수 있습니다. 로컬 관리자 권한을 부여할 Active Directory 사용자나 그룹이 이미 존재해야 합니다. 그룹 정책 기본 설정을 사용하려면 먼저 다음을 수행해야 합니다.
+ 도메인에 조인되는 컴퓨터 또는 EC2 인스턴스에 대한 액세스 권한을 확보합니다.
+ 그룹 정책 관리 콘솔(GPMC) MMC 스냅인을 설치합니다. 자세한 내용은 Microsoft 설명서의 [Windows 7용 원격 서버 관리 도구의 설치 또는 제거](https://technet.microsoft.com/en-us/library/ee449483.aspx)를 참조하세요.
+ 권한을 가진 도메인 사용자로 로그인하여 그룹 정책 객체(GPO)를 생성합니다. GPO를 해당 OU에 연결합니다.
**그룹 정책 기본 설정을 사용하여 로컬 관리자 권한을 부여하려면**
1. 디렉터리 또는 도메인 컨트롤러에서 명령 프롬프트를 관리자로 열고 `gpmc.msc`를 입력한 다음 ENTER를 누릅니다.
1. 왼쪽 콘솔 트리에서 새 GPO를 생성할 OU를 선택하거나 기존 GPO를 사용하고 나서, 다음 중 하나를 수행합니다.
+ 컨텍스트(마우스 오른쪽 버튼 클릭) 메뉴를 열어서 **Create a GPO in this domain, Link it here**(이 도메인에서 GPO 생성, 여기에 연결)를 선택하여 새 GPO를 생성합니다. **이름**에 이 GPO를 설명하는 이름을 입력합니다.
+ 기존 GPO를 선택합니다.
1. GPO의 컨텍스트 메뉴를 열고 **편집**을 선택합니다.
1. 콘솔 트리에서 **컴퓨터 구성**, **기본 설정**, **Windows 설정**, **제어판 설정** 및 **로컬 사용자 및 그룹**을 선택합니다.
1. **로컬 사용자 및 그룹**을 선택하고 컨텍스트 메뉴를 연 다음, **새로 만들기**, **로컬 그룹**을 차례로 선택합니다.
1. **작업**에서 **업데이트**를 선택합니다.
1. **그룹 이름**에서 **관리자(내장형)**를 선택합니다.
1. **멤버**에서 **추가...**를 선택하고 스트리밍 인스턴스에 대한 로컬 관리자 권한을 할당할 Active Directory 사용자 계정 또는 그룹을 지정합니다. **작업**에서 **이 그룹에 추가**와 **확인**을 차례대로 선택합니다.
1. 이 GPO를 다른 OU에 적용하려면 다른 OU를 선택하고 컨텍스트 메뉴를 연 다음 **기존 GPO 연결**을 선택합니다.
1. 2단계에서 지정한 새 GPO 또는 기존 GPO 이름을 사용하여 스크롤해서 해당 GPO 위치로 이동하고 나서 **확인**을 선택합니다.
1. 이 기본 설정을 지정해야 하는 추가 OU에 대해 9단계와 10단계를 반복합니다.
1. **확인**을 선택하여 **새 로컬 그룹 속성** 대화 상자를 닫습니다.
1. **확인**을 다시 선택하여 GPMC를 닫습니다.
새 기본 설정을 GPO에 적용하려면 실행 중인 모든 이미지 빌더나 플릿을 중지했다가 다시 시작해야 합니다. 8단계에서 지정한 Active Directory 사용자 및 그룹에 GPO가 연결된 OU의 이미지 빌더 및 플릿에 대한 로컬 관리자 권한이 자동으로 부여됩니다.
# 이미지 빌더에 로컬 관리자 그룹 사용
이미지 빌더에 대한 Active Directory 사용자 또는 그룹 로컬 관리자 권한을 부여하려면 이미지 빌더의 로컬 관리자 그룹에 이러한 사용자나 그룹을 수동으로 추가합니다. 이러한 권한을 가진 이미지에서 생성되는 이미지 빌더는 동일한 권한을 유지합니다.
단, 로컬 관리자 권한을 부여할 Active Directory 사용자 또는 그룹이 사전에 존재해야 합니다.
**Active Directory 사용자나 그룹을 이미지 빌더의 로컬 관리자 그룹에 추가하려면**
1. [https://console.aws.amazon.com/appstream2](https://console.aws.amazon.com/appstream2) WorkSpaces 애플리케이션 콘솔을 엽니다.
1. 이미지 빌더에 관리자 모드로 연결합니다. 이때 이미지 빌더는 실행 중이고 도메인에 병합되어야 합니다. 자세한 내용은 [자습서: Active Directory 설정](active-directory-directory-setup.md) 단원을 참조하십시오.
1. **시작**, **관리 도구**를 차례로 선택하고 나서 **컴퓨터 관리**를 두 번 클릭합니다.
1. 왼쪽 탐색 창에서 **로컬 사용자 및 그룹**을 선택하고 **그룹** 폴더를 엽니다.
1. **관리자** 그룹을 열고 **추가...**를 선택합니다.
1. 로컬 관리자 권한을 할당할 Active Directory 사용자 또는 그룹을 모두 선택한 다음 **확인**을 선택합니다. **확인**을 다시 선택하여 **관리자 속성** 대화 상자를 닫습니다.
1. 컴퓨터 관리를 닫습니다.
1. Active Directory 사용자로 로그인하고 사용자가 이미지 빌더에 대한 로컬 관리자 권한이 있는지 여부를 테스트하려면 **Admin Commands**(관리자 명령)를 선택하고 **사용자 전환**을 선택한 다음 관련 사용자의 자격 증명을 입력합니다.
# 도메인 병합에 사용되는 서비스 계정 업데이트
WorkSpaces 애플리케이션이 도메인 가입에 사용하는 서비스 계정을 업데이트하려면 이미지 빌더와 플릿을 Active Directory 도메인에 조인하기 위해 별도의 서비스 계정 두 개를 사용하는 것이 좋습니다. 별도의 서비스 계정 두 개를 사용하면 암호 만료 등으로 서비스 계정을 업데이트해야 할 때 서비스를 중단할 필요가 없습니다.
**서비스 계정을 업데이트하려면**
1. Active Directory 그룹을 생성한 후 이 그룹에게 올바른 권한을 위임합니다.
1. 서비스 계정을 새로운 Active Directory 그룹에 추가합니다.
1. 필요한 경우 새 서비스 계정의 로그인 자격 증명을 입력하여 WorkSpaces Applications Directory Config 객체를 편집합니다.
새로운 서비스 계정을 사용하여 Active Directory 그룹 설정을 마친 후부터는 새로운 스트리밍 인스턴스 작업을 실행할 때마다 새로운 서비스 계정을 사용하는 반면 실행 중인 스트리밍 인스턴스 작업은 중단 없이 이전 계정을 계속해서 사용합니다.
실행 중인 스트리밍 인스턴스 작업을 마칠 때 서비스 계정이 중복되는 시간은 매우 짧아서 하루를 넘기지 않습니다. 중복 기간에 이전 서비스 계정의 암호를 삭제하거나 변경해서는 안 되기 때문에 중복 시간이 필요합니다. 그렇지 않으면 작업이 중단될 수 있습니다.
# 사용자 유휴 시 스트리밍 세션 잠금
WorkSpaces 애플리케이션은 사용자가 지정된 시간 동안 유휴 상태인 후 스트리밍 세션을 잠그기 위해 GPMC에서 구성하는 설정에 의존합니다. GPMC를 사용하려면 먼저 다음을 수행해야 합니다.
+ 도메인에 조인되는 컴퓨터 또는 EC2 인스턴스에 대한 액세스 권한을 확보합니다.
+ GPMC를 설치합니다. 자세한 내용은 Microsoft 설명서의 [Windows 7용 원격 서버 관리 도구의 설치 또는 제거](https://technet.microsoft.com/en-us/library/ee449483.aspx)를 참조하세요.
+ GPO 생성 권한이 있는 도메인 사용자로 로그인합니다. GPO를 해당 OU에 연결합니다.
**사용자 유휴 시 스트리밍 인스턴스를 자동으로 잠그려면**
1. 디렉터리 또는 도메인 컨트롤러에서 명령 프롬프트를 관리자로 열고 `gpmc.msc`를 입력한 다음 ENTER를 누릅니다.
1. 왼쪽 콘솔 트리에서 새 GPO를 생성할 OU를 선택하거나 기존 GPO를 사용하고 나서, 다음 중 하나를 수행합니다.
+ 컨텍스트(마우스 오른쪽 버튼 클릭) 메뉴를 열어서 **Create a GPO in this domain, Link it here**(이 도메인에서 GPO 생성, 여기에 연결)를 선택하여 새 GPO를 생성합니다. **이름**에 이 GPO를 설명하는 이름을 입력합니다.
+ 기존 GPO를 선택합니다.
1. GPO의 컨텍스트 메뉴를 열고 **편집**을 선택합니다.
1. **사용자 구성**에서 **정책**, **관리 템플릿**, **제어판**을 차례로 확장하고 나서 **개인 설정**을 선택합니다.
1. **화면 보호기 사용**을 두 번 클릭합니다.
1. **화면 보호기 사용** 정책 설정에서 **사용**을 선택합니다.
1. **적용**을 선택하고 **확인**을 선택합니다.
1. **특정 화면 보호기 강제 적용**을 두 번 클릭합니다.
1. **특정 화면 보호기 강제 적용** 정책 설정에서 **사용**을 선택합니다.
1. **화면 보호기 실행 파일**에 **scrnsave.scr**을 입력합니다. 이 설정이 활성화되면 사용자의 바탕 화면에 검은색 화면 보호기가 표시됩니다.
1. **적용**을 선택하고 **확인**을 선택합니다.
1. **Password protect the screen saver**(화면 보호기 암호로 보호)를 두 번 클릭합니다.
1. **Password protect the screen saver**(화면 보호기 암호로 보호) 정책 설정에서 **사용**을 선택합니다.
1. **적용**을 선택하고 **확인**을 선택합니다.
1. **화면 보호기 시간 제한**을 두 번 클릭합니다.
1. **화면 보호기 시간 제한** 정책 설정에서 **사용**을 선택합니다.
1. **초**에 화면 보호기가 적용되기 전 사용자가 유휴 상태로 있어야 하는 기간을 지정합니다. 유휴 시간을 10분으로 설정하려면 600초를 지정합니다.
1. **적용**을 선택하고 **확인**을 선택합니다.
1. 콘솔 트리의 **사용자 구성**에서 **정책**, **관리 템플릿**, **시스템**을 차례로 확장한 다음 **Ctrl\$1Alt\$1Del 옵션**을 선택합니다.
1. **컴퓨터 잠금 사용 안 함**을 두 번 클릭합니다.
1. **컴퓨터 잠금 사용 안 함** 정책 설정에서 **사용 안 함**을 선택합니다.
1. **적용**을 선택하고 **확인**을 선택합니다.
# 디렉터리 구성 편집
WorkSpaces Applications 디렉터리 구성을 생성한 후 이를 편집하여 조직 단위를 추가, 제거 또는 수정하거나, 서비스 계정 사용자 이름을 업데이트하거나, 서비스 계정 암호를 업데이트할 수 있습니다.
**디렉터리 구성을 업데이트하려면**
1. [https://console.aws.amazon.com/appstream2](https://console.aws.amazon.com/appstream2) WorkSpaces 애플리케이션 콘솔을 엽니다.
1. 왼쪽 탐색 창에서 [**Directory Configs**]를 선택한 다음 편집할 디렉터리 구성을 선택합니다.
1. **작업(Actions)**, **편집(Edit)**을 선택합니다.
1. 변경할 필드를 업데이트합니다. OU를 추가하려면 최상단 OU 필드 옆에 있는 더하기 기호([**\$1**])를 선택합니다. OU 필드를 제거하려면 해당 필드 오른쪽에 있는 [**x**]를 선택합니다.
**참고**
OU는 최소 1개 이상 필요합니다. 현재 사용 중인 OU는 제거할 수 없습니다.
1. 변경 내용을 저장하려면 [**Update Directory Config**]를 선택합니다.
1. 이제 [**Details**] 탭의 정보가 변경 내용을 반영하여 업데이트됩니다.
서비스 계정 로그인 보안 인증 정보를 변경하더라도 실행 중인 스트리밍 인스턴스 작업에는 아무런 영향도 미치지 않습니다. 업데이트된 자격 증명은 새로운 스트리밍 인스턴스 작업에서 사용됩니다. 자세한 내용은 [도메인 병합에 사용되는 서비스 계정 업데이트](active-directory-service-acct.md) 단원을 참조하십시오.
# 디렉터리 구성 삭제
더 이상 필요하지 않은 WorkSpaces Applications 디렉터리 구성을 삭제할 수 있습니다. 단, 이미지 빌더나 플릿에 연결되어 있는 디렉터리 구성은 삭제하지 못합니다.
**디렉터리 구성을 삭제하려면**
1. [https://console.aws.amazon.com/appstream2](https://console.aws.amazon.com/appstream2) WorkSpaces 애플리케이션 콘솔을 엽니다.
1. 왼쪽 탐색 창에서 [**Directory Configs**]를 선택한 다음 삭제할 디렉터리 구성을 선택합니다.
1. **작업**, **삭제**를 선택합니다.
1. 팝업 메시지에서 이름을 확인한 후 [**Delete**]를 선택합니다.
1. [**Update Directory Config**]를 선택합니다.
# 도메인 트러스트를 사용하도록 WorkSpaces 애플리케이션 구성
WorkSpaces 애플리케이션은 파일 서버, 애플리케이션 및 컴퓨터 객체와 같은 네트워크 리소스가 한 도메인에 있고 사용자 객체가 다른 도메인에 있는 Active Directory 도메인 환경을 지원합니다. 컴퓨터 객체 작업에 사용되는 도메인 서비스 계정은 WorkSpaces Applications 컴퓨터 객체와 동일한 도메인에 있을 필요가 없습니다.
디렉터리 구성을 생성할 때는 파일 서버, 애플리케이션, 컴퓨터 객체 및 기타 네트워크 리소스가 상주하는 Active Directory 도메인의 컴퓨터 객체를 관리할 수 있는 권한을 가진 서비스 계정을 지정합니다.
최종 사용자의 Active Directory 계정은 다음과 같은 경우에 "인증 허용(Allowed to Authenticate)" 권한이 필요합니다.
+ WorkSpaces 애플리케이션 컴퓨터 객체
+ 도메인에 대한 도메인 컨트롤러
자세한 내용은 [Active Directory 컴퓨터 객체를 생성 및 관리할 수 있는 권한 부여](active-directory-permissions.md) 단원을 참조하십시오.
# Active Directory에서 WorkSpaces 애플리케이션 컴퓨터 객체 관리
WorkSpaces 애플리케이션은 Active Directory에서 컴퓨터 객체를 삭제하지 않습니다. 이 컴퓨터 객체는 디렉터리에서 쉽게 식별할 수 있습니다. 디렉터리의 컴퓨터 객체는 각각 플릿 또는 이미지 빌더 인스턴스와 이름을 지정하는 `Description` 속성으로 생성됩니다.
**컴퓨터 객체 설명 예**
| Type | 이름 | Description 속성 |
| --- | --- | --- |
| 플릿 | ExampleFleet | `WorkSpaces Applications - fleet:ExampleFleet` |
| 이미지 빌더 | ExampleImageBuilder | `WorkSpaces Applications - image-builder:ExampleImageBuilder` |
다음 `dsquery computer` 및 `dsrm` 명령을 사용하여 WorkSpaces 애플리케이션에서 생성한 비활성 컴퓨터 객체를 식별하고 삭제할 수 있습니다. 자세한 내용은 Microsoft 설명서의 [Dsquery computer](https://technet.microsoft.com/en-us/library/cc730720.aspx) 및 [Dsrm](https://technet.microsoft.com/en-us/library/cc731865.aspx)을 참조하십시오.
`dsquery` 명령은 일정 기간 비활성 상태인 컴퓨터 객체를 식별하며 다음 형식을 따릅니다. 또한 파라미터를 사용하여 `dsquery` 명령을 실행`-desc "WorkSpaces Applications*"`하여 WorkSpaces 애플리케이션 객체만 표시해야 합니다.
```
dsquery computer "OU-distinguished-name" -desc "WorkSpaces Applications*" -inactive number-of-weeks-since-last-login
```
+ `OU-distinguished-name`은 조직 단위의 고유 이름입니다. 자세한 내용은 [조직 단위의 고유 이름 찾기](active-directory-oudn.md) 단원을 참조하십시오. 명령에 *OU-distinguished-name* 파라미터를 입력하지 않으면 전체 디렉터리를 검색합니다.
+ `number-of-weeks-since-last-log-in`은 비활성 정의 방식을 정의하는 데 기준으로 사용할 값입니다.
예를 들어 다음 명령은 `OU=ExampleOU,DC=EXAMPLECO,DC=COM` 조직 단위에서 지난 2주간 로그인하지 않은 모든 컴퓨터 객체를 표시합니다.
```
dsquery computer OU=ExampleOU,DC=EXAMPLECO,DC=COM -desc "WorkSpaces Applications*" -inactive 2
```
일치하는 결과가 발견되면 객체 이름이 1개 이상 있습니다. `dsrm` 명령은 지정한 객체를 삭제하며, 다음 형식을 따릅니다.
```
dsrm objectname
```
여기에서 `objectname`은 `dsquery` 명령으로 출력되는 전체 객체 이름입니다. 예를 들어 위의 `dsquery` 명령에서 반환되는 컴퓨터 객체 이름이 "ExampleComputer"라면 삭제하기 위한 `dsrm` 명령은 다음과 같습니다.
```
dsrm "CN=ExampleComputer,OU=ExampleOU,DC=EXAMPLECO,DC=COM"
```
이 두 가지 명령은 파이프(`|`) 연산자를 사용하여 함께 묶을 수 있습니다. 예를 들어, 모든 WorkSpaces Applications 컴퓨터 객체를 삭제하고 각각에 대한 확인 메시지를 표시하려면 다음 형식을 사용합니다. `-noprompt` 파라미터를 `dsrm`에 추가하면 확인 메시지가 표시되지 않습니다.
```
dsquery computer OU-distinguished-name -desc "WorkSpaces Applications*" –inactive number-of-weeks-since-last-log-in | dsrm
```
# 추가 정보
이 주제에 대한 자세한 내용은 다음 리소스를 참조하세요.
+ [알림 코드 문제 해결](troubleshooting-notification-codes.md) - 알림 코드 오류 해결 방법
+ [Active Directory 문제 해결](troubleshooting-active-directory.md) - 일반적인 문제 지원
+ [Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) - 사용에 대한 정보입니다 Directory Service.