페푸리의 Office Server 이야기

MDE와 Endpoint DLP를 이해하기 위한 디바이스 온보딩 개념 정리

Pepuri — Sun, 3 May 2026 22:15:59 +0900

이번 글에서는 디바이스 온보딩(Device Onboarding) 에 대해 정리해보려고 합니다.

이전에도 Deploy 관점에서 작성한 시리즈 글들이 있으니 참고하시면 좋을 것 같습니다.

2023.10.14 - [Microsoft Defender XDR/MDE] - Deploy Microsoft Defender for Endpoint (MDE). (0). Introduction

Microsoft Defender for Endpoint, 흔히 MDE를 조금이라도 다뤄보셨다면 “온보딩”이라는 표현을 많이 들어보셨을 것입니다. MDE는 이미 오래전부터 사용되어 온 기술이고, 실무에서는 간단히 MDE = EDR처럼 표현하기도 합니다.

그런데 이번 글에서 온보딩을 다루는 이유는 단순히 MDE 때문만은 아닙니다.

제가 더 중요하게 보고 있는 목적은 Endpoint DLP를 이해하기 위한 기반으로서 디바이스 온보딩을 정리하는 것입니다.

Endpoint DLP는 Microsoft Purview 영역에 있는 기능이지만, 실제 엔드포인트에서 동작하기 위해서는 디바이스가 Microsoft Defender for Endpoint 기반으로 온보딩되어 있어야 합니다. 따라서 Endpoint DLP를 제대로 이해하려면 먼저 MDE 온보딩 구조를 이해할 필요가 있습니다.

1. 온보딩에 대한 이해

1) 왜 Endpoint DLP에서 디바이스 온보딩이 필요한가?

Microsoft Learn의 Endpoint DLP 기술 자료를 보면 시작 단계에서부터 디바이스 온보딩이 필요하다고 안내합니다.

이유를 이해하려면 먼저 Microsoft Defender의 전체적인 개념을 간단히 볼 필요가 있습니다.

Microsoft 365 E5 보안 영역에서 Defender는 크게 다음과 같은 대상을 보호합니다.

메일
클라우드 앱
디바이스
Identity

제가 이해하는 Defender XDR의 핵심 개념은 다음과 같습니다.

여러 보안 영역에서 시그널을 수집하고, 로그를 모은 뒤, 이 로그 간의 상관관계를 분석하여 대응하는 구조

즉, Defender XDR은 단순히 개별 보안 제품의 집합이 아니라, 여러 영역의 신호를 모아 하나의 흐름으로 분석하고 대응하는 체계라고 볼 수 있습니다.

2) 클라우드 리소스와 디바이스의 차이

메일, 클라우드 앱, Entra ID Protection과 같은 영역은 이미 클라우드에 존재하는 리소스입니다.

예를 들어 Exchange Online, SharePoint Online, Microsoft Entra ID는 Microsoft 365 클라우드 안에서 동작합니다. 따라서 별도의 클라이언트 설치 없이도 서비스 간 연결을 통해 로그와 시그널을 수집할 수 있습니다.

반면 디바이스는 다릅니다.

Windows 11 클라이언트나 Windows Server와 같은 운영체제는 클라우드 리소스가 아니라 실제 사용자 환경에 존재하는 엔드포인트입니다. 이 장치에서 보안 시그널을 수집하려면 해당 장치를 Microsoft Defender for Endpoint에 연결하는 절차가 필요합니다.

이 절차를 디바이스 온보딩이라고 부릅니다.

Defender for Identity도 최근 구조가 많이 변경되었고, 기본적으로 관련 환경을 온보딩한 뒤 시그널을 수집하는 방식으로 이해할 수 있습니다.

정리하면 Defender의 핵심은 다음과 같습니다.

시그널을 수집한다.
로그를 모은다.
여러 로그의 상관관계를 분석한다.
탐지와 대응을 수행한다.

Endpoint DLP도 Purview 기능이지만, 엔드포인트에서 파일 사용, 복사, 업로드, 앱 사용 등의 행위를 감지하고 제어해야 하므로 디바이스 측 시그널이 필요합니다.

따라서 Endpoint DLP를 이해하려면 MDE 온보딩을 먼저 이해해야 합니다.

3) MDE 온보딩과 Endpoint DLP의 관계

Microsoft Defender for Endpoint와 Endpoint DLP는 서로 다른 포털과 관리 영역에 있는 것처럼 보이지만, 엔드포인트 관점에서는 매우 밀접하게 연결되어 있습니다.

실무적으로는 다음과 같이 이해하면 쉽습니다.

MDE는 엔드포인트 보안 시그널을 수집하고 EDR로 동작한다.
Endpoint DLP는 엔드포인트에서 데이터 유출 행위를 감지하고 제어한다.
두 기능 모두 엔드포인트에서 동작하기 위해 디바이스 온보딩이 필요하다.
Endpoint DLP는 MDE 온보딩 기반 위에서 동작한다고 이해할 수 있다.

즉, Endpoint DLP를 설정하기 전에 먼저 디바이스가 Defender for Endpoint에 온보딩되어 있어야 합니다.

이번 글에서는 디바이스를 온보딩하는 가장 기본적인 절차부터 정리합니다.

4) 온보딩 방식의 큰 구분

MDE 온보딩 문서를 보면 배포 전 준비, 역할 할당, 환경 확인 등의 단계가 있습니다.

실무적으로는 먼저 현재 환경이 어떤 형태인지 확인해야 합니다.

대표적으로 다음과 같이 나눌 수 있습니다.

구분	설명
Cloud-native	Active Directory 없이 Microsoft Entra ID와 Intune 중심으로 관리하는 환경
Co-management	Configuration Manager와 Intune을 함께 사용하는 환경
On-premises	Active Directory와 Group Policy 중심으로 관리하는 환경

이 글에서는 크게 두 가지 흐름을 기준으로 설명합니다.

방식	설명
Intune 기반 등록	디바이스를 Intune에 등록한 뒤 Defender로 온보딩하는 방식
Group Policy 기반 온보딩	AD GPO를 통해 온보딩 스크립트 또는 정책을 적용하는 방식

제가 실무적으로 설명할 때는 Intune을 통해 장치를 등록하고 관리하는 흐름을 Intune 온보딩이라고 부르고, Group Policy 기반으로 온보딩은 MDE 온보딩 이라고 부릅니다.

이 글에서도 동일하게 표현하겠습니다.

5) 기본 테스트 환경

이번 글에서 사용하는 기본 환경은 다음과 같습니다.

Active Directory가 구성되어 있음
Entra ID Connect를 통해 AD 개체가 Microsoft Entra ID로 동기화됨
디바이스는 Hybrid Join 상태로 구성 가능
Intune은 새 테스트 테넌트 기준으로 처음부터 설정
이후 Intune 온보딩 및 MDE 온보딩을 진행

참고로

Entra ID에 디바이스 개체가 동기화되어 있다고 해서, 해당 디바이스가 Intune에 등록된 것은 아닙니다.

Entra ID에만 디바이스 등록 (Entra 관리센터)

Entra ID에만 디바이스 등록한 경우 (Intune 관리센터)

Entra ID Connect는 말 그대로 개체를 동기화하는 역할을 합니다. 디바이스 개체를 Entra ID에 등록할 수는 있지만, 그것이 곧 Intune 관리나 보안 시그널 수집을 의미하지는 않습니다.

따라서 다음 두 개념은 구분해야 합니다.

구분	의미
Entra ID에 디바이스 등록	디바이스 개체가 Entra ID에 존재하는 상태
Intune에 디바이스 등록	디바이스가 MDM 관리 대상으로 등록된 상태

실제 운영 환경에서도 Entra ID에는 디바이스가 보이지만, Intune에는 보이지 않는 경우가 있습니다.

이 경우 해당 장치는 아직 Intune MDM Enrollment가 완료되지 않은 상태라고 볼 수 있습니다.

2. Intune Enrollment

먼저 Microsoft Entra 관리 센터에서 Intune 등록을 위한 기본 설정을 진행합니다.

2.1. Microsoft Intune 활성화

Entra 관리 센터에서 다음 위치로 이동합니다.

Microsoft Entra admin center
→ Mobility
→ Microsoft Intune

여기에서 MDM user scope를 설정합니다.

테스트 환경에서는 다음과 같이 설정합니다.

MDM user scope: All

이 설정은 어떤 사용자에게 MDM 등록을 허용할 것인지 범위를 정하는 설정입니다.

실제 운영 환경에서는 특정 사용자 그룹으로 제한할 수 있지만,

이번 글에서는 온보딩 개념을 설명하는 것이 목적이므로 All로 진행합니다.

설정을 변경한 뒤 Save를 클릭합니다.

이제 Intune에서 장치를 등록할 준비가 완료된 상태입니다.

2.2. AD Joined 디바이스를 Intune에 자동 등록하기

Active Directory에 조인된 디바이스를 Intune에 등록하려면 Group Policy를 사용할 수 있습니다.

쉽게 표현하면 다음과 같습니다.

AD에 조인된 Windows 디바이스에게 “너는 Intune에도 등록해야 한다”는 정책을 내려주는 과정

이번 예시에서는 AD에 다음과 같은 OU가 있다고 가정합니다.

그리고 이 OU 안에 AD 조인된 PC가 등록되어 있습니다.

이제 이 장치를 Intune에 자동 등록하도록 GPO를 생성합니다.

2.3. GPO 생성 및 MDM 자동 등록 설정

Domain Controller에서 Group Policy Management를 열고, 대상 OU에 새 GPO를 생성합니다.

GPO 편집기에서 다음 경로로 이동합니다.

Computer Configuration
→ Policies
→ Administrative Templates
→ Windows Components
→ MDM

여기에서 다음 설정을 엽니다.

Enable automatic MDM enrollment using default Azure AD credentials

설정을 다음과 같이 변경합니다.

Enabled
Credential Type: User Credential

2.4. 정책 반영 및 등록 확인

정책이 정상적으로 적용되면 Windows 설정에서 등록 상태를 확인할 수 있습니다.

Settings
→ Accounts
→ Access work or school

정상적으로 등록된 경우 회사 또는 조직에 의해 관리되고 있다는 정보가 표시됩니다.

또는 명령어로도 확인할 수 있습니다.

dsregcmd /status

출력 결과에서 다음과 같은 정보를 확인할 수 있습니다.

Managed by Intune

2.5. Task Scheduler를 통한 등록 동작 확인

장치 등록이 정상적으로 진행되지 않는 경우 Task Scheduler를 확인해볼 수 있습니다.

Windows에서는 MDM 등록과 관련된 작업이 스케줄링되어 동작합니다.

확인 위치는 다음과 같습니다.

Task Scheduler
→ Microsoft
→ Windows
→ EnterpriseMgmt

이 위치에서 디바이스 등록과 관련된 트리거와 작업을 확인할 수 있습니다.

따라서 Intune 등록이 예상대로 진행되지 않는 경우, 이 영역을 확인하면 문제 원인을 파악하는 데 도움이 될 수 있습니다.

2.6. Entra ID와 Intune에서 등록 상태 확인

GPO를 통해 MDM 등록이 완료되면 먼저 Entra 관리 센터에서 등록 상태가 확인될 수 있습니다.

이후 일정 시간이 지나면 Intune 관리 센터에서도 디바이스가 표시됩니다.

Entra ID에는 먼저 등록 상태가 반영되고, Intune에는 조금 늦게 표시될 수 있습니다.

따라서 등록 직후 Intune에 바로 보이지 않는다고 해서 반드시 실패한 것은 아닙니다.

일정 시간이 지난 뒤 다시 확인해야 합니다.

2.7. Entra ID Joined 디바이스 등록 방식

이번에는 Active Directory를 사용하지 않는 환경을 가정해보겠습니다.

AD가 없는 환경에서는 Entra ID Join을 통해 디바이스를 등록할 수 있습니다.

Windows 초기 설정 단계에서 Entra ID Join을 진행할 수도 있고, 이미 Workgroup으로 사용 중인 PC라면 Windows 설정에서 직접 연결할 수도 있습니다.

경로는 다음과 같습니다.

Settings
→ Accounts
→ Access work or school
→ Connect

여기에서 다음 옵션을 선택합니다.

Join this device to Microsoft Entra ID

과거에는 Azure AD Join이라고 불렸지만, 현재는 Microsoft Entra ID Join이라는 명칭을 사용합니다.

이후 사용자 계정을 입력하고 절차를 진행하면 디바이스가 Entra ID에 조인되고, Intune 등록도 함께 진행될 수 있습니다.

3. Defender 포털 프로비저닝

3.1. Microsoft Defender 포털 프로비저닝

Defender 설정을 진행하기 위해 Microsoft Defender 포털로 이동합니다.

Microsoft Defender portal
→ System
→ Settings

잠시 뒤, 아래와 같이 프로비저닝이 진행됩니다.

새로운 테스트 테넌트에서는 Defender XDR 공간이 아직 프로비저닝되어 있지 않을 수 있습니다.

이 경우 Defender 환경을 먼저 프로비저닝해야 합니다.

프로비저닝은 최초 1회만 필요하며, 완료까지 시간이 조금 걸릴 수 있습니다.

이 영역은 Entra ID나 Intune 관리 센터와는 별도의 Defender 백엔드 공간을 준비하는 과정으로 이해하면 됩니다.

3.2. Microsoft Intune connection 활성화

Defender XDR 프로비저닝이 완료되면 이제 Intune과 Microsoft Defender for Endpoint를 연결해야 합니다.

이 단계가 흔히 말하는 Intune connection입니다.

즉, 지금까지는 디바이스를 Intune에 등록하는 작업을 했고, 이제부터는 Intune과 Defender for Endpoint 사이의 서비스 간 연결을 구성하는 단계입니다.

설정 위치는 Microsoft Defender 포털에서 다음 경로로 이동합니다.

Microsoft Defender portal
→ Settings
→ Endpoints
→ General
→ Advanced features

여기에서 다음 항목을 찾습니다.

Microsoft Intune connection

해당 값을 On으로 변경한 뒤 저장합니다.

Microsoft Intune connection: On

이 설정을 켜면 Intune과 Defender for Endpoint가 연결되고, 이후 Intune에서 Defender for Endpoint 관련 온보딩 패키지를 자동으로 가져오거나 EDR 정책을 배포할 수 있는 기반이 마련됩니다.

3.3. Intune 관리 센터에서 연결 상태 확인

Defender 포털에서 Microsoft Intune connection을 활성화한 뒤에는 Intune 관리 센터에서 연결 상태를 확인합니다.

경로는 다음과 같습니다.

Microsoft Intune admin center
→ Endpoint security
→ Setup
→ Microsoft Defender for Endpoint

Intune Connection Off

Intune Connection On

연결이 완료되면 Intune 관리 센터에서 어떤 플랫폼을 Microsoft Defender for Endpoint와 연계할지 설정할 수 있습니다.

경로는 다음과 같습니다.

Microsoft Intune admin center
→ Endpoint security
→ Microsoft Defender for Endpoint

여기에서 지원되는 플랫폼에 대해 Defender for Endpoint 연결을 활성화합니다.

예를 들어 Windows 디바이스를 대상으로 한다면 다음 항목을 활성화합니다.

Connect Windows devices to Microsoft Defender for Endpoint: On

이 연결 설정은 Defender와 Intune의 통합을 위한 설정이며, 실제 Windows 디바이스가 Defender for Endpoint로 시그널을 보내도록 만드는 EDR 온보딩 정책 배포와는 구분해서 이해해야 합니다.

3.4. EDR 온보딩 정책 배포

이제 실제 Windows 디바이스를 Microsoft Defender for Endpoint에 온보딩해야 합니다.

Intune에서 EDR 온보딩 정책을 만들기 위해 다음 경로로 이동합니다.

Microsoft Intune admin center
→ Endpoint security
→ Endpoint detection and response

여기에서 새 정책을 생성합니다.

Create Policy

정책 생성 시 플랫폼과 프로필은 다음과 같이 선택합니다.

Platform: Windows
Profile: Endpoint detection and response

정책 이름을 지정합니다.

이후 Configuration settings에서 Microsoft Defender for Endpoint 클라이언트 구성 패키지 유형을 선택합니다.

Intune과 Defender for Endpoint 연결이 정상적으로 완료되어 있다면 다음 옵션을 사용할 수 있습니다.

Microsoft Defender for Endpoint client configuration package type:
Auto from connector

Auto from connector는 Intune이 Defender for Endpoint에서 최신 온보딩 패키지를 자동으로 가져와 사용하는 방식입니다.

온보딩 대상 그룹을 지정합니다.

따라서 별도로 Defender 포털에서 온보딩 패키지를 다운로드해서 업로드하지 않아도 됩니다.

3.5. Auto from connector의 의미

Auto from connector는 Intune과 Defender for Endpoint가 정상적으로 연결되어 있을 때 사용할 수 있는 권장 방식입니다.

이 방식의 장점은 다음과 같습니다.

Intune이 Defender for Endpoint에서 최신 온보딩 패키지를 자동으로 가져옴
별도의 수동 패키지 다운로드가 필요 없음
EDR 정책 생성 시 최신 온보딩 구성을 사용할 수 있음
Intune 관리 디바이스에 정책으로 배포 가능

반대로 Intune과 Defender for Endpoint 연결이 되어 있지 않거나,

특수한 환경에서는 수동 온보딩 패키지를 사용할 수 있습니다.

수동 방식에서는 Microsoft Defender 포털에서 온보딩 패키지를 다운로드한 뒤 Intune 정책에 직접 넣어야 합니다.

하지만 일반적인 Intune 기반 배포에서는 Auto from connector 방식을 사용하는 것이 더 간단합니다.

3.6. 온보딩 상태 확인

아래와 같이 온보딩 상태를 확인합니다.

4. MDE 온보딩

4.1. MDE 온보딩의 의미

이제부터 진행하는 단계는 제가 구분해서 부르는 MDE 온보딩입니다.

앞에서 설명한 Intune 등록은 디바이스를 Intune 관리 대상으로 만드는 과정이었습니다.

반면 여기서 말하는 MDE 온보딩은 Intune에 등록하지 않고, Microsoft Defender for Endpoint 온보딩 패키지를 Group Policy로 배포해서 장치를 Defender for Endpoint에 직접 연결하는 방식입니다.

이 방식으로 온보딩된 장치는 Intune에 MDM 등록된 장치가 아니기 때문에, 관리 상태를 확인했을 때 Managed by Intune이 아니라 Managed by MDE 형태로 이해할 수 있습니다.

4.2. 왜 Group Policy 방식의 MDE 온보딩이 필요한가?

모든 환경에서 Intune을 바로 사용할 수 있는 것은 아닙니다.

기존 Active Directory 기반으로 운영 중이며, 여러가지 특수한 환경에 의해서 Intune Enrollment 정책을 배포하기 어려운 환경은 존재합니다.

MDE 온보딩이 필요한 환경은 다음과 같습니다.

디바이스는 AD Join 상태임
Intune MDM Enrollment는 아직 적용하지 않음/못함
기존 GPO 기반 운영 체계를 유지하고 있음
먼저 Defender for Endpoint만 빠르게 온보딩하고 싶음
서버 또는 일부 업무망 장치는 Intune 등록이 어려움

이 경우 Intune을 먼저 구성하지 않아도, Group Policy를 통해 Microsoft Defender for Endpoint 온보딩 패키지를 배포할 수 있습니다.

이 방식이 바로 제가 말하는 MDE 온보딩입니다.

흐름은 다음과 같습니다.

AD Joined Device
→ Group Policy
→ MDE Onboarding Script 실행
→ Microsoft Defender for Endpoint 서비스 연결
→ Defender 포털에 장치 표시
→ Managed by MDE 상태로 보안 설정 관리 가능

4.3. Defender 포털에서 Group Policy용 온보딩 패키지 다운로드

먼저 Microsoft Defender 포털에서 온보딩 패키지를 다운로드합니다.

경로는 다음과 같습니다.

Microsoft Defender portal
→ Settings
→ Endpoints
→ Device management
→ Onboarding

여기에서 운영체제를 선택합니다.

Operating system: Windows 10 and Windows 11

또는 서버를 대상으로 한다면 해당 Windows Server 운영체제를 선택합니다.

배포 방식은 다음과 같이 선택합니다.

Deployment method: Group Policy

그 다음 온보딩 패키지를 다운로드합니다.

Download onboarding package

압축을 해제하면 다음과 같은 파일을 확인할 수 있습니다.

WindowsDefenderATPOnboardingScript.cmd

이 스크립트가 실제 장치를 Microsoft Defender for Endpoint에 온보딩하는 데 사용됩니다.

4.4. 온보딩 스크립트 공유 경로 준비

Group Policy에서 클라이언트가 스크립트를 실행하려면, 대상 장치가 접근할 수 있는 공유 경로가 필요합니다.

예를 들어 파일 서버에 다음과 같은 공유 폴더를 만들 수 있습니다.

\\fileserver.contoso.com\MDEOnboarding

해당 공유 폴더에 온보딩 스크립트를 복사합니다.

\\fileserver.contoso.com\MDEOnboarding\WindowsDefenderATPOnboardingScript.cmd

이때 중요한 점은 대상 컴퓨터 계정이 해당 경로에 접근할 수 있어야 한다는 것입니다.

저는 테스트 목적으로 Everyone read 권한으로 설정하였습니다.

운영 환경에서는 보안 정책에 따라 권한을 더 엄격하게 구성할 수 있습니다.

중요한 것은 클라이언트 장치가 GPO를 통해 해당 스크립트를 실행할 수 있어야 한다는 점입니다.

4.5. Group Policy에서 Scheduled Task 생성

이제 Group Policy Management Console에서 새 GPO를 생성합니다.

GPO를 편집한 뒤 다음 경로로 이동합니다.

Computer Configuration
→ Preferences
→ Control Panel Settings
→ Scheduled Tasks

여기에서 새 작업을 생성합니다.

New
→ Immediate Task (At least Windows 7)

이 방식은 GPO가 적용될 때 대상 장치에서 즉시 작업을 실행하는 구조입니다.

4.6. Scheduled Task 일반 설정

Scheduled Task의 General 탭에서 다음과 같이 설정합니다.

Change User or Group

또는 UI에서 SYSTEM을 입력한 뒤 Check Names를 클릭하면 다음과 같이 확인될 수 있습니다.

NT AUTHORITY\SYSTEM

옵션은 다음과 같이 설정합니다.

Run whether user is logged on or not
Run with highest privileges

이 설정을 사용하는 이유는 온보딩 스크립트가 사용자 권한이 아니라 시스템 권한으로 실행되어야 하기 때문입니다.

Actions 탭에서 새 작업을 추가합니다.

Actions
→ New

Action에서 다음과 같이 경로를 입력합니다.

Program/script에는 온보딩 스크립트의 UNC 경로를 입력합니다.

\\fileserver.contoso.com\MDEOnboarding\WindowsDefenderATPOnboardingScript.cmd

여기서 로컬 경로가 아니라 UNC 경로를 사용하는 것이 좋습니다.

4.7. 클라이언트에서 MDE 온보딩 상태 확인

클라이언트에서 온보딩 상태를 확인하려면 레지스트리와 서비스 상태를 확인할 수 있습니다.

먼저 Sense 서비스가 존재하고 실행 중인지 확인합니다.

Get-Service Sense

정상적으로 실행 중이라면 다음과 유사한 상태를 확인할 수 있습니다.

Status   Name    DisplayName
------   ----    -----------
Running  Sense   Windows Defender Advanced Threat Protection Service

레지스트리에서도 온보딩 상태를 확인할 수 있습니다.

reg query "HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status"

예를 들어 다음 값이 확인되면 온보딩 상태를 판단하는 데 도움이 됩니다.

OnboardingState

일반적으로 OnboardingState 값이 1이면 온보딩된 상태로 볼 수 있습니다.

온보딩이 완료되면 Microsoft Defender 포털에서 장치가 표시되는지 확인합니다.

경로는 다음과 같습니다.

Microsoft Defender portal
→ Assets
→ Devices

정상적으로 온보딩된 장치는 Devices 목록에 표시됩니다.

다만 장치가 즉시 표시되지 않을 수 있습니다.

일반적으로 다음 시간이 필요할 수 있습니다.

GPO 적용
→ Scheduled Task 실행
→ 온보딩 스크립트 실행
→ Sense 서비스 초기화
→ 최초 보안 시그널 전송
→ Defender 포털에 장치 표시

따라서 온보딩 직후 바로 보이지 않더라도 일정 시간 후 다시 확인해야 합니다.

4.8. Integration

MDE 온보딩 장치는 Integration 설정을 통해서 Intune에 MDM 등록된 장치가 아니더라도, Microsoft Defender for Endpoint Security settings management를 통해 일부 Endpoint Security 정책을 받을 수 있습니다.

이 방식은 다음과 같은 환경에서 유용합니다.

서버 장치
Intune 등록이 어려운 기존 AD Joined 장치
GPO 중심으로 운영 중인 환경
빠르게 Defender for Endpoint 온보딩을 먼저 진행해야 하는 환경
Intune MDM 관리 전환 전 중간 단계

Integration을 적용하려면 Defender 포털에서 Enforcement Scope를 확인해야 합니다.

경로는 다음과 같습니다.

Microsoft Defender portal
→ Settings
→ Endpoints
→ Configuration management
→ Enforcement scope

여기에서 Microsoft Defender for Endpoint가 어떤 장치에 보안 설정을 적용할 수 있는지 범위를 지정합니다.

범위는 전체 장치로 설정할 수도 있고, 특정 태그를 가진 장치만 대상으로 제한할 수도 있습니다.

운영 환경에서는 처음부터 전체 장치를 대상으로 하기보다, 테스트용 태그를 사용해서 범위를 제한하는 것이 좋습니다.

Intune 관리 센터에서 적용된 디바이스를 확인할 수 있습니다.

Microsoft Intune admin center
→ Devices
→ All devices

정리하면 다음과 같습니다.

Intune Onboarding
= Intune에 장치를 등록해서 Managed by Intune으로 관리하는 방식

MDE Onboarding
= Group Policy로 Defender for Endpoint에 온보딩하고 Managed by MDE로 관리하는 방식

따라서 기존 AD 기반 환경에서 Endpoint DLP나 Defender for Endpoint를 설명할 때는, 먼저 Group Policy 기반 MDE 온보딩을 통해 장치를 Defender for Endpoint에 연결하고, 이후 Managed by MDE 상태에서 보안 설정을 관리할 수 있다는 흐름으로 설명하는 것이 더 자연스럽습니다.

다음 포스팅과 영상은 Endpoint DLP나 MDE의 새부설정에 대해서 다룰 예정입니다.

Intune. App control for business (aka. WDAC) 를 통한 앱 실행 차단 정책 배포

Pepuri — Sat, 18 Apr 2026 20:05:02 +0900

시작하기 전에

3rd Party 매체제어 또는 DLP 솔루션에서는 프로그램 실행 차단 기능을 제공하는 경우가 많습니다.

최근에는 AI에 문의하면 각 기능이 어떤 로직으로 동작하는지 파악하는 것도 크게 어렵지 않습니다.
제가 확인했을 당시에는 Windows Native 기능으로 아래 세 가지가 대표적으로 안내되었습니다.

IFEO (Image File Execution Options)
AppLocker
WDAC (Windows Defender Application Control)

이 중 WDAC는 현재 App Control for Business라는 명칭으로 변경되어 사용되고 있습니다.

오늘은 Intune을 통해 App Control for Business 정책을 배포하는 과정을 정리해보겠습니다.

Youtube: https://youtu.be/iqvMo5BEqvw

1. App Control for Business(WDAC)란?

App Control for Business는 여전히 현업에서는 WDAC라는 표현으로 많이 불립니다.

그리고 AppLocker와 자주 비교되는데, 주요 차이는 아래와 같습니다.

App Control for Business vs AppLocker

항목	App Control for Business (WDAC)	AppLocker
도입 시기	Windows 10부터	Windows 7부터
동작 계층	커널 / 부트 단계	유저 모드
우회 난이도	매우 높음	상대적으로 낮음
제어 대상	EXE, DLL, 스크립트, 드라이버 등	EXE, DLL, 스크립트 등
신뢰 기준	서명, 해시, 경로, ISG 등	서명, 해시, 경로
Managed Installer	✅ 지원	❌ 미지원
ISG	✅ 지원	❌ 미지원
관리 도구	Intune, SCCM, PowerShell 등	GPO 중심
Microsoft 권장	✅ 신규 도입 1순위	보조 용도

핵심 차이

AppLocker가 User Mode 정책이라면,

WDAC는 Code Integrity 기반 Kernel 수준 제어를 지원한다라는 점이 가장 큰 차이입니다.

2. 정책 생성

WDAC은 우선 XML 형식 정책을 생성해야 합니다.

Microsoft에서 제공하는 아래 도구를 사용합니다.

App Control Policy Wizard 설치

Microsoft App Control Wizard

WDAC은 우선 XML 형식으로 정책을 생성해야 하며, 아래의 사이트에 접속하여 App Control Policy Wizard를 설치합니다.

Microsoft App Control Wizard

Policy Creator

운영은 Base Policy 배포 → Supplemental Policy로 보완하는 흐름으로 진행됩니다. 이때 Supplemental Policy는 허용(Allow) 규칙 추가만 가능하며, Base Policy에서 이미 차단한 항목을 풀거나 새로운 차단 규칙을 더하지는 못합니다.

운영 구조

운영은 보통 아래 흐름으로 갑니다.

Base Policy 배포
↓
Supplemental Policy로 예외 허용 추가

참고

Supplemental Policy 특징

Allow 규칙 추가 가능
기존 Block 해제 불가
새로운 Deny 추가 불가

즉,

차단(Deny)은 Base Policy에서 설계해야 합니다.

이번 글에서는 Supplement Policy 배포에 대해서 다루지 않습니다.

2.1 기본 템플릿 3종

기본적으로 아래 3가지 템플릿을 제공합니다.

템플릿	허용 범위	보안	유연성
DefaultWindows	Windows 필수 바이너리만		낮음
AllowMicrosoft	+ 모든 MS 서명 앱		중간
SignedAndReputable (ISG)	+ 평판 좋은 타사 앱		높음

세 템플릿은 왼쪽(DefaultWindows)으로 갈수록 엄격하고, 오른쪽(SignedAndReputable)으로 갈수록 유연해지는 스펙트럼으로 이해하시면 됩니다. 조직의 보안 요구 수준과 업무 유연성 사이에서 균형점을 선택하면 됩니다.

엄격함
DefaultWindows
↓
AllowMicrosoft
↓
SignedAndReputable
유연함

3. Default Windows Mode 테스트

Default Windows Mode 적용

Audit Mode Disable

동작 확인을 위해 Audit Mode는 Disable.

우선 Next

정책 생성

XML 생성 완료

4. 정책 배포

Intune Admin Center

Endpoint Security → App Control for Business

정책 생성 후

이름 지정

XML Upload

대상 할당 > 정책 생성까지 진행

정책 적용 여부 확인

정책 파일 확인 경로:

C:\Windows\System32\CodeIntegrity\CIPolicies\Active

적용 전/후 비교 가능합니다.

적용 전

적용 후

테스트

Chrome 실행

결과:

차단됨

PowerShell로 정책 조회

CiTool.exe -lp

Powershell 명령어로도 적용된 Policy 확인 가능.

5. 실무 정책 설계 방향

실무적으로 기업 업무 환경에서는 AllowMicrosoft 또는 SignedAndReputable 을 Base Policy로 출발한 뒤, LOB 앱에 대한 Allow 규칙과 위험 바이너리에 대한 Deny 규칙을 조직 상황에 맞게 설계·보완하는 방향으로 운영하는 것이 일반적입니다.

DefaultWindows는 이론상 가장 안전하지만, 일반 사무 환경에서는 예외 처리 부담이 지나치게 커서 규제 산업·고정 업무 단말 등 한정된 시나리오에 주로 적용됩니다.

5.1 AllowMicrosoft 정책 설계

템플릿 생성

Allow Microsoft Mode 선택

Chrome 차단 확인

기본 상태에서는 Chrome 실행 차단.

이벤트 로그 확인

참고로 이벤트 로그에서도 기록을 확인할 수 있습니다.

Applications and Services Logs → Microsoft → Windows → CodeIntegrity → Operational

Chrome.exe 파일이 적용된 Policy ID에서 요구하는 조건에 충족하지 못해서 차단되었다는 메시지를 확인할 수 있었습니다.

본격적인 화이트리스트 운영을 위해서는 템플릿 자체는 변경하지 않고, 필요한 예외 경로만 추가하는 방식으로 정책을 설계했습니다. 아래는 실제로 추가한 예외 경로 예시입니다.

화이트리스트 경로 예외 추가

Add Custom

경로별로 일일이 규칙을 만드는 대신, 주요 예외 경로는 와일드카드(*)를 활용해 포괄적으로 등록했습니다.

이렇게 하면 하위 폴더나 신규 파일이 추가되더라도 정책을 매번 수정할 필요가 없어 유지보수 부담을 크게 줄일 수 있습니다. 다만 와일드카드 범위가 지나치게 넓으면 악성 코드 우회 지점이 될 수 있으므로, 꼭 필요한 최소 범위로 한정하는 것이 원칙입니다.

예시

아래와 같이 Allow 규칙 완성 후 정책 배포

결과

아래와 같이 Chrome은 실행되는 것을 확인할 수 있습니다.

허용 경로 외의 파일은 모두 차단됩니다. 예를 들어 Chrome 설치 파일을 바탕화면에서 실행하면 다음과 같이 차단됩니다. 이를 통해 사용자의 임의 앱 설치를 억제할 수 있으며, 필요 시 Downloads 등 특정 경로를 Allow 규칙에 추가해 설치를 허용할 수 있습니다.

정책에 의해 차단됨 확인

의미

이 구조는 다음과 같은 효과를 가집니다.

임의 앱 설치 억제
승인 경로만 실행 허용

5.2 SignedAndReputable 정책 설계

이번에는 마지막으로 Signed and Reputable Mode로 진행해보겠습니다.

템플릿 선택

Signed and Reputable Mode

정책 적용 확인

이벤트 로그 확인.

Chrome 실행 테스트

정상 실행.

ISG 평판 기반 허용으로 판단.

6. ISG(Intelligent Security Graph)

참고로 표시된 ISG는 Microsoft가 가진 전 세계 보안 신호를 참고해서, “이 앱을 믿어도 되는지” 판단하는 평판 기반 허용 장치입니다.

ISG(Intelligent Security Graph)를 사용하여 평판 좋은 앱에 권한 부여 | Microsoft Learn

기존에 화이트리스트 기반 정책을 운영해본 경험이 없는 기업이라면, 이 템플릿으로 출발하는 것이 가장 현실적입니다.

대부분의 IT 환경에서는 "기본은 폭넓게 허용하되, 문제 있는 특정 앱만 Block으로 걸러내는" 방식으로 운영되는데, 이 흐름에 가장 잘 맞는 것이 바로 SignedAndReputable 모드입니다.

SignedAndReputable 설계 흐름을 정리하면 다음과 같습니다.

7. SignedAndReputable 운영 설계 흐름

Step 1

SignedAndReputable Base Policy

Step 2

Managed Installer 활성화

(Intune 배포 앱 자동 신뢰)

Step 3

주요 경로 Allow

Step 4

특정 위험 앱 Deny

예시: Winrar

결과

Chrome → Allow
WinRAR → Deny

중요

Deny는 Allow보다 우선합니다.

장치가 온보딩되어 있다면, Advanced hunting을 통해서 모니터링할 수 있습니다.

DeviceEvents
| where ActionType in ("AppControlCodeIntegrityPolicyAudited", 
                        "AppControlCodeIntegrityPolicyBlocked")
| summarize 
    AuditCount = countif(ActionType endswith "Audited"),
    BlockCount = countif(ActionType endswith "Blocked"),
    LastSeen = max(Timestamp)
    by DeviceName, FileName, FolderPath
| sort by AuditCount + BlockCount desc

개인적으로는

SignedAndReputable + 주요 실행 경로 Allow + 특정 위험 앱 Deny

조합이 가장 현실적인 출발점이라고 생각합니다.

AI 시대 고찰

Pepuri — Wed, 25 Mar 2026 22:05:09 +0900

최근 AI가 발달하고 긍정적인 면과 부정적인 면에 대해서 AI와 토론하였습니다. 토론하며 제가 생각한 내용을 AI에게 정리를 요청하였습니다. 최근 AI는 메모리 기능이 있기 때문에, 과거까지 제가 요청하는 방향성까지 반영하여 논문을 만들어달라고 입력하였습니다. 그리고 아래와 같이 글을 작성해주었습니다.

페푸리의 AI 시대 고찰

직관, 증명, 그리고 인간 판단의 우위에 대하여

초록

본 글은 인공지능(AI)의 발전이 인간의 지적 능력을 전면적으로 대체하거나 초월할 것이라는 낙관론에 대해 비판적으로 검토한다. 특히 AI를 둘러싼 논의가 기술 자체의 성능이나 효율성에 지나치게 집중하는 반면, 실제 인간 사회는 직관, 감정, 이해관계, 제도, 권력, 쾌락 추구와 같은 비합리적이면서도 현실적인 변수에 의해 움직인다는 점에 주목한다. 본 글의 핵심 주장은 다음과 같다. 첫째, 인간의 사고는 텍스트나 데이터로 완전히 환원되지 않는 암묵지와 직관에 기반하므로, 기록된 정보의 통계적 학습에 의존하는 AI는 근본적으로 인간 판단의 전 영역을 대체하기 어렵다. 둘째, AI는 고도의 합리적 최적화를 수행할 수 있으나, 현실 사회에서 중요한 것은 무엇이 옳은가보다 무엇이 실제로 작동하고 실행되는가이며, 이 과정은 인간의 감정, 정치, 설득, 권력 구조에 의해 좌우된다. 셋째, AI는 전체 인간의 수준을 고르게 끌어올리기보다 오히려 일부 소수에게만 강력한 증폭 도구로 작동하여 다수와의 인지적·경제적 격차를 확대할 가능성이 크다. 결론적으로 AI 시대의 핵심 경쟁력은 지식의 양이나 계산 능력이 아니라, 직관을 기반으로 목표를 설정하고, 복잡한 현실 속에서 경로를 설계하며, 작은 일은 AI에 위임하되 본질과 방향은 인간이 책임지는 능력에 있다.

주제어: 인공지능, 직관, 암묵지, 사회적 양극화, 인간 판단, 자동화 역설, 인지 외주화

1. 서론

AI를 둘러싼 담론은 대개 생산성 향상, 문제 해결 속도, 대규모 데이터 분석 능력, 자동화된 의사결정 등의 장점을 전면에 내세운다. 그러나 이러한 서사는 중요한 질문을 충분히 다루지 못한다. AI는 과연 인간보다 더 잘 판단할 수 있는가? AI는 창의적인 발견의 주체가 될 수 있는가? 그리고 AI의 확산은 인간 사회 전체의 지적 수준을 높이는가, 아니면 일부만 더 강하게 만들고 다수를 더 의존적으로 만드는가?

본 글은 이러한 질문에 대해 기술 낙관론과는 다른 방향의 답변을 제시한다. 본 글의 관점에서 AI는 분명 강력한 도구이지만, 인간의 본성과 사회 구조를 고려할 때 그것이 가져올 실제 결과는 단순한 효율의 증가가 아니다. 오히려 AI는 인간이 이미 가지고 있던 편의 추구, 사고의 외주화, 권력 집중, 제도 지연, 교육 격차와 결합하며 사회적 양극화를 심화시킬 가능성이 높다. 특히 AI의 영향은 단순히 “좋은 기술”인지 “나쁜 기술”인지의 문제가 아니라, 인간이 실제로 어떻게 행동하는가, 어떤 제도가 늦게 작동하는가, 누가 먼저 활용하고 누가 의존하게 되는가의 문제로 이해되어야 한다.

다만 이 글은 AI 시대를 해석하는 유일한 결론이나 보편 법칙을 제시하려는 시도가 아니다. 오히려 본 글은 AI의 미래를 예측하는 여러 방향성 중 하나를 정리한 관점적 논의에 가깝다. 특수한 사례에서는 특수한 조건과 요건에 따라 본 글의 주장에 대한 반박이 충분히 가능하다. 그러나 인간 세계는 본래 하나의 공식이나 단일한 해로 완전히 정의될 수 있는 체계가 아니며, 만일 인간 사회가 이미 누군가에 의해 완벽히 예측 가능한 대상이었다면 오늘날과 같은 논의와 증명, 논쟁 자체가 성립할 이유도 약해졌을 것이다. 그러므로 본 글은 절대적 선언이 아니라, 현실 인간 사회의 움직임을 해석하기 위한 하나의 강한 가설이자 방향성의 제안으로 읽혀야 한다.

이 글은 다음의 순서로 전개된다. 먼저 인간 사고의 핵심 요소로서 직관과 암묵지를 살펴본다. 다음으로 AI가 근본적으로 가지는 한계를 Communication, 맥락, 실행 가능성의 문제로 정리한다. 이어서 인간 사회가 합리성만으로 움직이지 않는다는 점을 논하고, AI 시대가 왜 전체적 향상보다 인지적·경제적 양극화를 낳을 가능성이 큰지 검토한다. 마지막으로 AI 시대에 인간이 유지해야 할 핵심 역할을 제안한다.

2. 인간 사고의 중심에는 직관과 암묵지가 존재한다

AI에 대한 과도한 기대는 인간 사고를 지나치게 언어화·데이터화된 과정으로 이해하는 데서 출발하는 경우가 많다. 그러나 실제 인간의 사고는 텍스트로 완전히 환원되지 않는다. 인간은 문제를 풀 때 먼저 명시적인 문장이나 공식으로 사고하지 않는다. 오히려 느낌, 경험, 분위기 파악, 실패의 기억, 몸에 밴 감각, 그리고 특정 상황에서의 미세한 이상 징후를 통해 먼저 직관을 형성하고, 그 후에 그것을 설명 가능한 언어로 옮긴다.

이 점에서 암묵지(tacit knowledge)는 중요하다. 암묵지는 말로 설명하기 어렵지만 실제로는 결정적인 역할을 하는 지식이다. 예를 들어 한 현장 엔지니어가 특정 장비의 미세한 진동이나 소리만으로 이상을 감지하는 능력, 수학자가 증명의 형식화 이전에 어떤 구조가 맞다고 느끼는 감각, 숙련된 기술자가 문서화되지 않은 장애 패턴을 알아채는 판단은 전형적인 암묵지의 사례다. 이러한 지식은 종종 텍스트로 정리되지 않으며, 심지어 당사자도 완전히 설명하지 못한다.

문제는 현재의 AI가 주로 기록된 텍스트, 코드, 로그, 이미지, 정형 데이터 등을 통해 학습한다는 데 있다. 따라서 AI는 기록된 것, 표현된 것, 형식화된 것에는 강할 수 있지만, 아직 표현되지 않은 것, 오직 일부 인간의 경험 속에만 존재하는 것, 또는 극히 특수한 현장의 분위기와 맥락 안에서만 드러나는 것에는 근본적인 제약을 가진다. 이는 AI가 인간보다 더 많은 사실을 알고 있을 수는 있어도, 인간이 지닌 모든 종류의 판단 능력을 대체하기 어렵다는 점을 시사한다.

3. AI의 근본적 한계는 지능 그 자체보다 Communication에 있다

현장에서 AI를 사용할 때 가장 크게 드러나는 문제는 단순한 지식 부족이 아니라 Communication의 한계다. AI는 입력된 전제, 상황, 조건, 목적이 충분히 정리되어야 비교적 정확한 답을 내놓을 수 있다. 하지만 현실의 문제는 대개 처음부터 정리된 형태로 존재하지 않는다. 특히 기술 지원(TS), 운영, 장애 분석, 온프레미스 인프라, 레거시 시스템 등에서는 문제 자체가 불완전한 조각들로 나타난다. 사용자는 로그 일부만 알고 있고, 실제 원인은 문서화되지 않은 설정이나 과거의 특수한 변경 이력에 숨어 있으며, 심지어 질문하는 당사자조차 무엇을 정확히 물어야 하는지 모르는 경우가 많다.

이러한 현실에서 문제 해결은 정답 조회가 아니라 탐정 작업에 가깝다. 즉, 현상 관찰, 가설 수립, 추가 질문, 맥락 파악, 원인 추정, 반례 확인, 우선순위 판단의 반복이다. AI는 이 중 일부 보조는 가능하지만, 문제 정의 자체가 모호하고 조직 특유의 정치와 책임 구조가 얽혀 있을 때는 본질적으로 한계를 드러낸다. 특히 온프레미스 환경에서 발생하는 문제는 인터넷에 존재하지 않는 내부 설정과 경험칙에 의존하는 경우가 많아, AI는 아무리 일반론을 잘 말해도 실제 핵심을 놓치기 쉽다.

이 점에서 AI의 한계는 단순히 “더 똑똑해지면 해결될 문제”가 아니다. 오히려 인간 사회와 인간 언어 자체가 불완전하다는 사실에서 비롯되는 구조적 한계에 가깝다. 인간은 자신이 알고 있는 것조차 완전히 설명하지 못하며, 자신이 모르는 것을 정확히 질문하는 데도 어려움을 겪는다. 따라서 AI는 결국 인간이 얼마나 맥락을 잘 정리해 주느냐에 강하게 의존할 수밖에 없다.

4. 인간 사회는 합리성보다 실행 가능성과 수용 가능성으로 움직인다

AI가 잘하는 것은 주어진 목표 아래에서 최적 경로를 탐색하고 논리적으로 일관된 해를 제안하는 일이다. 그러나 현실 세계에서 중요한 결정은 단지 논리적으로 옳은가에 의해 이루어지지 않는다. 실제 인간 사회에서는 “맞는 말”보다 “되게 만드는 힘”이 더 중요하다.

예를 들어 어떤 행위 A가 잘못되었다는 것을 설명하고, 윤리적·사회적 이유를 제시하는 일은 비교적 가능하다. 그러나 현실적으로 중요한 것은 다수가 A를 잘못된 것으로 인식하게 만들고, 이해관계를 조정하고, 저항을 견디며, 결국 법과 제도로 금지하는 과정을 실제로 성사시키는 것이다. 이 과정은 논리의 문제가 아니라 설득, 권력, 감정, 타이밍, 사회적 압력, 정치적 동원의 문제다.

이 지점에서 AI는 본질적인 한계를 갖는다. AI는 종종 “왜 A를 해야 하는가”를 논리적으로 설명할 수 있다. 하지만 인간은 때때로 그 설명을 듣고도 “그냥 싫다”는 감정으로 거부할 수 있다. 그리고 그 거부가 비합리적이라 하더라도 사회적 현실에서는 충분한 힘을 가질 수 있다. 다시 말해, 인간 사회에서 실제 의사결정은 최적화된 논리 해가 아니라, 감정적으로 받아들여지고 집단적으로 수용 가능한 해에 의해 좌우되는 경우가 많다. 이 때문에 AI는 정교한 조언자는 될 수 있어도, 인간 사회를 실제로 움직이는 존재가 되기는 어렵다.

5. AI는 인간 전체를 고르게 향상시키기보다, 일부 소수를 더 강하게 만들 가능성이 크다

AI의 보편적 확산이 전체 인류의 지적 수준을 골고루 향상시킬 것이라는 기대는 낙관적인 시나리오다. 그러나 인간의 본성과 현실 구조를 고려하면, 보다 현실적인 전망은 AI가 일부에게는 강력한 사고 증폭 도구가 되고, 다수에게는 사고를 외주화하는 장치로 작동할 가능성이 높다는 것이다.

인간은 일반적으로 편한 방향을 선호한다. 복잡한 과정을 거쳐 깊이 이해하는 것보다, 빠르게 결과를 얻는 것을 선택하기 쉽다. 따라서 AI가 요약, 초안 작성, 분석, 코드 생성, 정리, 설득 문구 작성까지 대신하게 되면, 많은 사람은 사고의 과정 자체를 생략하는 데 익숙해질 수 있다. 이는 지적 능력의 평균을 일정 수준에서 유지하게 만들 수는 있어도, 고도의 통찰과 독자적 사고를 요구하는 영역에서 인간의 상향 발전을 돕는다고 보기는 어렵다.

오히려 AI의 진정한 수혜자는 맹점을 정확히 인식하는 일부 소수일 가능성이 크다. 이들은 AI를 맹목적으로 신뢰하지 않고, 어디까지 위임하고 어디서부터 인간이 개입해야 하는지 알며, AI가 다루지 못하는 구조적·정치적·심리적 변수까지 고려한다. 결과적으로 이들은 더 사고하는 인간이 되고, 다수는 더 의존하는 인간이 될 수 있다. 이러한 차이는 시간이 지날수록 인지적 격차를 넘어서 경제적, 사회적, 제도적 격차로 확장될 가능성이 크다.

역사적으로도 새로운 기술은 처음부터 평등하게 작동하지 않았다. 기술을 먼저 이해하고 활용한 개인과 집단은 생산성, 자본, 영향력 측면에서 우위를 점했고, 그 우위는 종종 구조적으로 고착되었다. AI 역시 예외가 아닐 가능성이 높다. 특히 AI가 교육, 행정, 기업 운영, 정책 설계, 정보 접근 전반에 스며들수록, 그 도구를 능동적으로 활용하는 집단과 결과만 소비하는 집단의 차이는 더욱 커질 수 있다.

6. 교육과 제도는 이론적으로 균형을 잡을 수 있으나, 현실적으로는 늦고 어렵다

AI의 역기능에 대한 반론은 흔히 교육 개혁, 제도 설계, 규제, 공공성 강화 등을 제시한다. 이러한 방향 자체는 충분히 합리적이며 바람직하다. 예컨대 교육이 단순 정답 중심에서 벗어나 문제 정의, 비판적 사고, 설명 능력, 맥락 판단을 중시하도록 바뀐다면, AI는 사고를 대체하는 도구가 아니라 보조하는 도구가 될 수 있다. 또한 법과 제도가 기술의 남용을 통제하고 접근성을 확대한다면, 극단적 독식 구조를 완화할 여지도 있다.

그러나 문제는 그러한 변화가 현실적으로 얼마나 가능하며, 얼마나 빠르게 실행될 수 있는가이다. 대부분의 사회 문제는 원칙적으로 옳은 방향을 안다고 해서 자동으로 해결되지 않는다. 이해관계를 조정하고, 다수의 무관심과 저항을 넘어서고, 제도화하고 집행하는 과정은 길고 고통스럽다. 역사적으로도 노동권, 독점 규제, 개인정보 보호, 환경 규제 등은 문제 인식에서 법제화에 이르기까지 긴 시간이 필요했다.

AI는 반대로 매우 빠르게 확산된다. 즉, 기술 발전 속도는 제도 변화 속도를 앞선다. 이 불균형 속에서 현실적으로 더 개연성 있는 시나리오는, 교육과 규제가 이상적인 수준에 도달하기 전에 이미 시장과 조직과 소비 문화가 AI 중심 구조에 적응해 버리는 것이다. 따라서 이론적으로는 균형 잡힌 AI 사회가 가능할 수 있으나, 현실에서는 그 과정이 너무 늦어 다수의 의존성과 소수의 독식이 먼저 구조화될 가능성이 더 높다.

7. AI 시대 인간의 핵심 경쟁력은 Goal과 Path를 설계하는 능력이다

그렇다면 AI 시대에 인간에게 남는 핵심 역할은 무엇인가. 본 글은 그 답을 직관에 기반한 목표 설정과 경로 설계 능력에서 찾는다. 인간은 Goal을 설정하고, 어떤 방향이 옳은지 아닌지를 가치 판단하며, 무엇이 중요한지와 무엇을 포기해야 하는지를 결정한다. 또한 현실의 복잡성과 제약을 고려하여, 어떤 길은 막혀 있고 어떤 길은 열려 있으며, 어떤 우회가 장기적으로 더 유리한지를 판단한다. 이것은 단순한 계산이 아니라 직관, 경험, 가치, 권력 구조 이해, 타이밍 감각이 결합된 능력이다.

반면 AI는 자잘한 일, 반복적인 분석, 대량의 정보 정리, 경우의 수 탐색, 문장화, 시뮬레이션, 초안 작성, 일정 수준의 예측 보조를 담당하는 것이 더 적절하다. 즉, 인간은 본질을 파고들고 방향을 정하며, AI는 그 방향 안에서 실행 효율을 높이는 역할을 하는 것이 가장 균형 잡힌 모델이다.

이는 인간의 우월성을 근거 없이 주장하는 것이 아니다. 오히려 인간이 잘할 수 있는 영역과 AI가 잘할 수 있는 영역을 냉정하게 구분하자는 제안이다. AI는 하위 통계치의 인간을 넘어서는 작업을 수행할 수 있을지 모른다. 그러나 인간 사회의 중요한 결정은 단순히 평균적인 정답 계산이 아니라, 가치와 감정, 수용성, 저항, 쾌락, 상징, 의미까지 포함한 복합적인 판단을 요구한다. 바로 이 지점에서 인간은 여전히 대체되기 어렵다.

8. 결론

AI는 강력한 기술이며, 앞으로 더 많은 영역에서 인간의 생산성을 끌어올릴 것이다. 그러나 이것이 곧 인간 판단의 우위가 사라진다는 뜻은 아니다. 오히려 AI가 강해질수록 무엇을 목표로 삼을지, 어떤 경로를 선택할지, 어디까지 위임하고 어디서부터 인간이 개입해야 하는지를 아는 능력은 더욱 중요해진다.

본 글은 다음과 같은 결론을 제시한다. 첫째, 인간 사고의 중심에는 텍스트로 환원되지 않는 직관과 암묵지가 존재하기 때문에, 기록된 지식의 통계적 학습에 기반한 AI는 인간 판단 전체를 대체하기 어렵다. 둘째, 현실 사회는 논리적 최적화가 아니라 실행 가능성과 수용 가능성에 의해 움직이므로, AI는 사회를 “움직이는 힘”보다는 “보조하는 힘”에 가깝다. 셋째, AI의 확산은 전체 인간의 수준을 고르게 끌어올리기보다, 일부 소수의 사고 능력을 더욱 증폭시키고 다수의 사고를 외주화하게 하여 양극화를 심화시킬 개연성이 크다. 넷째, AI 시대 인간의 핵심 역할은 본질을 파고들어 Goal을 설정하고, 복잡한 현실 속에서 Path를 설계하며, 자잘한 일은 AI에 위임하되 방향과 책임은 인간이 지는 것이다.

또한 본 글은 이 결론을 절대적 명제로 고정하지 않는다. 특수한 환경, 고도로 통제된 산업, 제한된 목표가 있는 시스템, 혹은 인간의 비합리성이 상대적으로 낮게 작동하는 분야에서는 AI의 역할이 본 글에서 제시한 것보다 더 크게 확장될 수도 있다. 그럼에도 불구하고 본 글이 강조하는 바는, 인간 사회 전체를 움직이는 장기적 구조를 볼 때 AI는 전면적 대체보다 선택적 증폭과 양극화의 도구가 될 가능성이 더 크다는 점이다.

결국 AI 시대의 본질은 인간과 기계 중 누가 더 똑똑한가의 문제가 아니다. 오히려 어떤 인간이 AI를 통해 더 깊이 사고하게 되는가, 그리고 어떤 인간이 AI에 사고를 맡기고 의존하게 되는가의 문제다. 인간 세계는 하나의 공식으로 완전히 정의되지 않으며, 그렇기 때문에 예측도 늘 가설적이다. 그러나 바로 그 불완전성과 불확실성 속에서 직관, 판단, 책임이라는 인간의 역할은 오히려 더 선명해질 수 있다. 이 차이가 앞으로의 사회를 결정할 것이다.

참고한 이론 및 개념적 배경

플라톤주의 (Mathematical Platonism): 수학적 진리는 인간이 만든 것이 아니라 이미 존재하며, 인간은 그것을 발명하기보다 발견한다는 관점.
Tacit Knowledge (암묵지): 인간의 핵심 지식 중 상당수는 언어로 완전히 설명되지 않으며, 경험과 직관 속에 축적된다는 개념.
Principle of Least Effort (최소 노력 원리): 인간은 대체로 더 깊은 사고보다 더 적은 노력으로 결과를 얻는 경향을 보인다는 관점.
Automation Paradox (자동화 역설): 자동화가 많아질수록 평소 인간의 개입은 줄지만, 문제가 터졌을 때는 오히려 더 높은 수준의 판단이 요구된다는 개념.
Moravec’s Paradox: 인간에게 쉬운 감각과 직관은 AI에게 어렵고, 인간에게 어려운 계산과 형식 논리는 AI에게 쉬울 수 있다는 역설.
Cognitive Offloading (인지 외주화): 인간이 기억, 계산, 정리 같은 인지적 부담을 외부 도구에 맡기며 사고 과정을 줄여가는 경향.
Behavioral Economics (행동경제학): 인간은 완전히 합리적으로 결정하지 않으며 감정, 편향, 사회적 환경에 의해 크게 영향을 받는다는 이론.
Loss Aversion (손실 회피): 같은 크기의 이익보다 손실을 더 크게 느끼기 때문에 인간의 판단은 종종 비대칭적으로 나타난다는 개념.
Winner-Take-Most Economy: 기술과 네트워크 효과가 강한 사회에서는 소수의 개인과 조직이 대부분의 가치를 가져갈 수 있다는 경제 구조.
Path Dependence (경로 의존성): 초기의 선택과 우연한 구조가 이후의 방향을 굳히며, 나중에는 비효율적이어도 쉽게 바뀌지 않는다는 개념.
Centaur Model (인간+AI 협업 모델): 인간과 AI가 각자의 강점을 결합할 때 단독보다 더 높은 성과를 낼 수 있다는 협업 관점.
Experience Economy (경험 경제): 인간은 효율과 생산성만이 아니라 경험, 즐거움, 의미, 쾌락을 소비의 중요한 기준으로 삼는다는 경제적 관점.
Search in Problem Space (문제 공간 탐색): 목표는 존재하지만 도달 경로가 다수일 때, 가능한 길을 탐색하고 막힌 길을 제거하며 해를 찾아가는 사고 구조.

메모

이 문서는 사용자와의 논의를 바탕으로 관점을 정리한 개념 논문 초안이다. 실제 학술 제출용으로 확장하려면 다음 보완이 가능하다.

국내외 AI 교육·사회 양극화 관련 선행연구 추가
행동경제학·자동화 역설·인지 외주화 관련 참고문헌 정리
한국 교육 구조와 AI 활용 격차에 대한 사례 보강
학술지 스타일에 맞춘 초록/참고문헌/인용 형식 정리

Intune. 공용 PC (Shared Device) 구성

Pepuri — Mon, 16 Feb 2026 15:58:59 +0900

이번 포스팅에서는 Microsoft Intune을 활용하여 공용 PC(Shared Device)를 구성하는 방법에 대해 정리해보겠습니다.

공용 PC는 회의실, 교육장, 로비 키오스크, 공장 현장 단말 등 다양한 환경에서 사용됩니다.

Copilot이 제작한 회의실 이미지

이러한 장치는 여러 사용자가 번갈아 사용하기 때문에 자격 증명 관리와 데이터 잔존 방지가 무엇보다 중요합니다.

예를 들어,

A 사용자가 업무 후 로그아웃을 하지 않은 경우
다음 사용자인 B가 이전 사용자의 세션이나 데이터를 확인하게 되는 경우

이러한 상황은 개인정보 보호 및 컴플라이언스 측면에서 큰 리스크가 될 수 있습니다.

이를 방지하기 위해 Intune에서는 Shared multi-user device Policy를 제공하며,
로그아웃 시 사용자 프로필을 자동으로 삭제하도록 구성할 수 있습니다.

공식 문서
Shared or multi-user Windows device settings in Microsoft Intune - Microsoft Intune | Microsoft Learn

Youtube: https://youtu.be/Kj3WZmT-GFE

Step 1. Intune 장치 등록

정책을 배포하기 위해서는 먼저 해당 장치를 Intune에 등록(Enrollment) 해야 합니다.

공용 PC라고 하더라도 관리자 또는 마스터 계정으로 장치 등록을 진행합니다.

그 후,

정책 배포용 보안 그룹(Security Group) 생성
공용 PC를 해당 그룹에 추가

이 과정을 완료해야 정책을 정상적으로 배포할 수 있습니다.

Step 2. Shared multi-user device Policy 생성

경로

Intune Admin Center > Devices > Windows > Manage Devices > Configuration > Create > New Policy

아래와 같이 선택합니다.

Platform: Windows 10 and later

Profile Type: Templates

Shared multi-user device

정책 이름 지정

저는 아래와 같이 정책 설정을 진행하였습니다.

주요 정책

정책 항목	설정 값	기능 설명	설정 의미
Shared PC mode	Enable	공용 다중 사용자 모드 활성화	계정 정리 및 공용 운영 기능 활성화
Guest account	Guest and Domain	Guest 및 Entra ID 로그인 허용	M365 계정 및 Guest 로그인 가능
Account management	Enabled	계정 자동 관리 기능	사용자 프로필 자동 관리
Account Deletion	Immediately after log-out	로그아웃 시 프로필 삭제	사용자 흔적 즉시 제거
Local Storage	Disabled	로컬 저장소 허용 여부	로컬 데이터 저장 제한
Power Policies	Enabled	전원 정책 적용	전원 관리 통제
Sleep time out	300초	비활성 시 절전 진입	5분 후 절전
Sign-in when PC wakes	Enabled	절전 해제 시 로그인 요구	세션 보호
Maintenance start time	미설정	유지관리 시간	기본값 사용
Education policies	Not configured	교육기관 특화 정책	일반 기업에는 영향 없음

이 정책의 핵심 의미

1️⃣ 로그아웃 시 사용자 프로필 즉시 삭제

사용자가 로그아웃하면 해당 사용자 프로필이 즉시 삭제됩니다.
→ 공용 PC에 데이터가 남지 않도록 설계

※ Downloads 폴더 역시 로그아웃 시 삭제됩니다.

2️⃣ 로컬 저장소 차단

로컬 저장소 사용을 제한하여 공용 단말에 파일이 상시 보관되지 않도록 설계합니다.

3️⃣ 절전 후 로그인 요구

일정 시간 후 절전 진입
절전 해제 시 재로그인 요구

→ 세션 탈취 방지

4️⃣ Entra ID 로그인 허용 시 효과

M365(Entra ID) 계정으로 로그인할 경우:

OneDrive 연동 가능
사용자 환경은 세션 동안 유지
로그아웃 시 프로필 삭제

즉, 공용 PC이면서도 개인 업무 환경을 임시로 활용할 수 있습니다.

정책을 디바이스 그룹에 할당 > 정책을 생성합니다.

정책 적용이 완료되면, Guest 계정으로 로그인할 수 있습니다.

로그아웃만 진행하면, 매번 새로운 프로필을 생성합니다.

Windows 탐색기 상에서 Downloads 만 확인할 수 있습니다. (로그아웃을 진행하면, 항상 해당 폴더의 내용은 삭제됩니다.)

Guest 계정 사용 시 주의점

Guest 계정은 기본적으로 암호가 존재하지 않습니다.

사용자가 로그아웃하지 않고 자리를 이탈할 경우:

다음 사용자가 세션에 접근 가능
이전 사용자의 작업 내용 확인 가능

이는 보안상 취약점이 될 수 있습니다.

Entra ID 로그인 허용 시 장점

Domain (Entra ID) 로그인을 허용하면:

화면 잠금 시 재인증 요구
세션 보호 강화
상대적으로 보안 수준 향상

가능하다면 기업환경에 따라서 Entra ID 기반 로그인 운영을 유연하게 가져갑니다.

Guest 계정으로 관리할 경우, 화면이 잠길 때 일정시간 이후에는 로그아웃을 강제로 진행하는 스크립트 구성으로 보완할 수 있습니다.

Windows Server 2025. Hyper-V 에서 AVMA 키를 사용하여 Guest VM 정품 인증

Pepuri — Sat, 3 Jan 2026 06:55:07 +0900

이전 Windows Server 버전에서도 AVMA 키를 사용하여 정품인증 하는 방법에 대해서 포스팅 한적이 있습니다.

많은 엔지니어나 IT 매니저들이 Hyper-V 호스트 서버가 Datacenter Edition일 경우, Guest VM에서 AVMA 키를 사용하여 정품 인증이 가능하다는 사실을 잘 모릅니다. 이 기능을 활용하면 정품 인증 절차가 간소화되고, 관리가 훨씬 수월해집니다.

Youtube: https://youtu.be/lzjMYwdNnLU

저는 이 방법을 사용하여 정품 인증을 완료한 후, sysprep을 통해 반복적인 제품 키 입력 작업을 피할 수 있었습니다.

자세한 설명은 아래의 기술 자료에서 확인할 수 있습니다.

Windows Server의 자동 가상 머신 정품 인증 | Microsoft Learn

AVMA를 사용하려면 Hyper-V 서버 호스트 역할이 설치된 Windows Server Datacenter Edition이 필요합니다. 호스트의 Windows Server 버전은 게스트 VM에서 활성화할 수 있는 버전을 결정합니다. 다음 표에는 각 호스트 버전이 활성화할 수 있는 게스트 VM 버전이 나열되어 있습니다. 호스트 버전은 적합한 게스트 VM 버전의 모든 버전(Datacenter, Standard 또는 Essentials)에 액세스할 수 있습니다.

아래의 표 내용은 만약 Host Server OS가 Windows Server 2025라면, 2012R2부터 2025까지 AVMA키로 정품이 가능하다는 내용입니다.

각 OS버전별 제품키는 기술자료상에서 확인할 수 있습니다.

Windows Server OS 버전 별로 조금씩 다를 수는 있지만, 일정 버전 이상이면, 설치할 때 AVMA 키를 통해 제품키 입력이 가능합니다.

제품키에 맞는 OS 버전을 인식합니다.

OS 설치 완료 후 시작 버튼 우클릭 > Settings 으로 이동해보면

인증되지 않은 상태로 확인됩니다.

Activate now를 클릭하면, 0xC004F012 오류를 확인되는 경우가 있습니다.

Slmgr /ato 명령어로 다시 인증 작업을 진행합니다.

다음과 같이 인증되는 것을 확인할 수 있습니다.

만약 이미 OS설치가 완료되었다면, OS 설치 이후에도 제품키를 입력하여 정품 인증 및 확인을 진행할 수 있습니다.

Windows Server 2025 VM을 기준으로 다음과 같이 진행합니다.

시작 버튼 우클릭 > System

Product key and activation

Change

제품키 입력 > Next

Activate

정품 인증 완료

정품 인증을 완료한 후 Sysprep을 실행하면 테스트 환경을 관리하는 데 매우 유용합니다.

Microsoft 365 로그 관리 (5). Sentinel 로그를 Excel에서 분석하기

Pepuri — Thu, 25 Dec 2025 12:03:51 +0900

이전에 Sentinel에서 Power BI M Query를 내보내 BI Desktop에 연결하는 방법을 다룬적이 있었습니다.

2025.08.24 - [Microsoft 365] - Microsoft 365 로그 관리 (2): Microsoft Defender for Identity (MDI) 로그 관리와 Power BI 연결

Endpoint DLP 로그를 MDE 로그와 연결해 비교하는 과정에서도 같은 방식으로 Self Study를 진행했는데, Power BI에서는 열 순서(컬럼 오더) 정리가 상대적으로 번거로워 특정 항목을 빠르게 비교하기 어려운 경우가 있었습니다.

확인해 보니 Sentinel/Log Analytics에서 Export한 M Query를 Excel Power Query에 그대로 붙여넣어 연결하는 방식이 가능했습니다. Excel을 중심으로 분석하는 빈도가 높다면, 이 방식이 꽤 실용적입니다.

“M Query 추출 → Excel 연결 → 분석” 흐름을 정리해 보겠습니다.

Youtube: https://youtu.be/sy37RvTm5XQ

요약

Sentinel/Log Analytics에서 Export to Power BI (as an M query)로 M Query를 추출합니다.
Excel의 Power Query(Blank Query)에서 Advanced Editor에 M Query를 붙여넣습니다.
조직 계정(Organizational account)으로 인증 후 Close & Load 하면 테이블로 로드됩니다.
이후에는 Refresh로 데이터 갱신이 가능해 반복 조회 작업이 줄어듭니다.

Step 1) Sentinel / Log Analytics에서 M Query 다운로드

Azure Portal에서 다음 위치로 이동합니다.
- Microsoft Sentinel > Logs
- Log Analytics Workspace > Logs

Sentinel Logs 화면

Log AnalyticsLogs 화면

연결할 테이블을 대상으로 쿼리를 작성하거나 선택하고, Time range를 설정합니다.

상단 메뉴에서 다음 순서로 M Query를 내보냅니다.

Step 2) Excel에서 M Query로 연결하기

2-1) Blank Query 생성

Excel에서 아래 메뉴로 이동합니다.

Data(데이터) > Get Data > From Other Sources > Blank Query

2-2) Advanced Editor에 M Query 붙여넣기

Power Query Editor에서 Advanced Editor를 연 뒤, Step 1에서 다운로드한 M Query 전체를 그대로 붙여넣습니다.

Advanced Editor

M Query 붙여넣기

M Query를 보면 보통 다음 요소가 포함되어 있습니다.

조회 대상 테이블(Table)
조회 기간(Time range / timespan)

따라서 여러 테이블을 연결해야 한다면, 쿼리를 복제한 뒤 테이블/기간 부분만 수정하여 추가 연결을 구성하는 방식이 효율적입니다.

2-3) 인증(Credentials) 설정

처음 연결 시 인증이 필요하면 Edit Credentials가 표시됩니다.

Organizational account 선택 > 자격 증명 입력 > Connect

2-4) 로드(Load) 및 새로고침(Refresh)

쿼리 이름을 목적에 맞게 변경 > Close & Load로 Excel 시트에 로드합니다.

이 방식의 장점은 다음과 같습니다.

Log Analytics API 제한사항을 벗어나지 않는 선에서 로그 활용도를 높일 수 있습니다.
Refresh를 지원하므로 Portal에서 매번 동일 쿼리를 실행할 필요가 줄어듭니다.

Step 3) 활용: Copilot으로 로그 분석

Excel로 로드한 데이터를 OneDrive 또는 SharePoint에 저장한 뒤, Copilot에 분석을 요청할 수 있습니다.

Copilot이 데이터(예: MDE 관련 테이블)를 인식하면 요약/추세/이상 패턴 등 기본 분석을 빠르게 수행할 수 있습니다.

마무리

Sentinel/Log Analytics의 M Query Export를 활용하면 Excel에서도 로그를 직접 로드하여 분석할 수 있습니다.
특히 열 정리, 필터링, 피벗 분석처럼 “빠른 비교”가 중심인 작업에서는 Excel을 활용하고, 더 나아가서 AI를 연계해서 분석할 수 있습니다.

Microsoft 365 로그 관리 (4). Windows Update 기록을 통한 대시보드 만들기

Pepuri — Sun, 14 Dec 2025 11:15:08 +0900

최근 저는 로그와 기록들을 Power BI 대시보드로 시각화하는 데 큰 관심을 가지고 있습니다.

MS 제품의 가장 큰 장점은 제조사 자체에서 설계되었기 때문에, 3rd Party 제품보다 더 효율적이고 효과적으로 설계되었다는 점입니다.

처음에는 PowerShell을 사용하려고 했지만, Intune 정책과 Log Analytics를 통해 로그를 쉽게 적재하고 대시보드를 생성할 수 있다는 것을 알게 되었습니다.

그래서 Windows Update 대시보드를 만들기 위한 Requirement는 Azure 구독 및 Log Analytics 작업 영역입니다.

Intune 대시보드 만들기

Pepuri — Sun, 28 Sep 2025 10:46:49 +0900

Intune 정책을 정리하다가 Intune Data Warehouse의 존재와 Power BI로 BI 대시보드 구성이 가능하다는 사실을 알게 되었습니다.

Youtube에서 검색해보면, 연결방법이 오래전부터 제공된 것으로 확인됩니다.

Youtube: M365. Intune 대시보드 만들기

1. Import Data

Intune Data Warehouse를 Power BI에 연결하는 방법은 크게 두 가지입니다.

방법 1. OData Feed

Power BI에서 Get data > OData feed 선택

제공되는 URL 입력

조직 계정입력 -> Connect

가져올 수 있는 Table이 전부 나열됩니다. -> 전부 체크 -> Load

데이터 가져오기가 진행됩니다.

가져오기 완료

방법 2. Connector 연결

Power BI에서 Get Data > More 선택

Online Services -> Intune Data Warehouse

기간 지정

Table 선택 -> Load (이후 과정은 동일)

Odata feed vs Connector

-   Connector가 가져오는 테이블이 더 많지만, 실제로 의미 있는 데이터는 비슷함
-   OData Feed는 Advanced Query에서 커스텀 가능
-   Connector는 기간 지정이 가능

이 포스팅에서는 Connector 기준으로 작성합니다.

2. Power BI 템플릿 다운로드

대부분의 Intune 대시보드 관련 자료는 아래 템플릿을 기반으로 제작되었습니다.

PowerBiDashboards/Intune Dashboard.pbix at main · JayRHa/PowerBiDashboards · GitHub

템플릿 파일을 확인하면, 아래와 같이 대시보드가 완성 되어있습니다.

Transform data -> Data source settings로 이동하면

Connector 기반으로 연결된 것을 확인할 수 있습니다.

그러면 아래와 같이 오류가 발생합니다.

템플릿 작성자의 블로그에 접속하면 해당 오류는 언어 설정 문제라고 언급하였습니다.

Supported languages and countries/regions for Power BI

https://learn.microsoft.com/en-us/power-bi/fundamentals/supported-languages-countries-regions

로캘을 바꾸기 어려운 부분이 있어서 저는 템플릿을 복사하면서 진행하였습니다.

데이터를 연결한 BI에서 하단의 페이지 메뉴에서 템플릿과 동일하게 페이지를 추가합니다.

3개의 페이지를 아래와 같이 복사 붙여넣기를 진행합니다.

3. 개체 추가 및 관계 설정

구조가 일치하지 않기 때문에, 몇가지 오류들을 발견할 수 있습니다.

동일하게 구조를 맞춰주는 작업을 진행합니다.

아래의 경우에는

Text Filter라는 개체가 없기 때문에 발생하는 오류입니다.

More visuals > From AppSource

Text Filter를 검색하여 추가합니다.

새로 고침하거나, 다른 페이지로 이동했다가 다시 확인하면 수정된 것을 확인할 수 있습니다.

디바이스 페이지에서 발생하는 오류는 테이블간의 관계설정이 템플릿과 일치하지 않기 때문에 발생하는 증상입니다.

Model View 메뉴로 이동해서 확인해 보면, 개수의 차이를 확인할 수 있습니다.

처음 데이터를 가져오면 관계설정을 BI에서 자동으로 진행합니다.

구성 환경이 각각 다르기 때문에 테이블 관계도 다를 수 있습니다. 아래의 진행하는 방법은 접근하는 방법을 참고하시고, 각각의 환경에 맞게 템플릿과 관계를 동일하게 연결합니다.

Manage relationships

템플릿에는 존재하는 관계가 내 BI에는 존재하지 않는 것을 알 수 있습니다.

왼쪽과 동일하게 구조를 가져갑니다.

수정 후 Save

진행하다 보면, 한쪽에 데이터가 없기 때문에 관계가 자동으로 맺어지지 않은 것을 알 수 있습니다.

아래와 같이 Inactive, Active가 반대로 되어 있는 것도 동일하게 수정합니다.

수정이 완료되면, 디바이스 페이지도 오류가 해결됩니다.

ConfigProfiles까지 오류가 없는지 확인합니다.

5. 마무리

Power BI를 잘 활용하면 Intune 장치들을 직관적으로 관리할 수 있습니다.

Microsoft 365 로그 관리 (3): Azure Data Lake Storage Gen2 연결

Pepuri — Sun, 14 Sep 2025 14:21:13 +0900

이전 글에서는 MDI 로그 → Sentinel → Log Analytics API → PowerShell → CSV → BI로 이어지는 로그 관리 흐름을 다루었습니다.

2025.08.24 - [Microsoft 365] - Microsoft 365 로그 관리 (2): Microsoft Defender for Identity (MDI) 로그 관리와 Power BI 연결

PowerShell로 로그를 내보내는 작업까지 진행하면서, 이런 고민이 들었습니다.
"점점 서버리스(Serverless) 환경으로 전환되는 추세인데, PowerShell 스케줄링을 위해 VM을 운영해야 한다면 관리 포인트가 오히려 늘어나지 않을까?"

비용만 고려한다면 VM에서 PowerShell로 스케줄링하여 SharePoint나 OneDrive에 저장하는 방식이 저렴할 수 있습니다.
하지만 장기적으로는 VM에서 PowerShell 스크립트를 돌리는 방식보다 서버리스 구조로 전환하는 것이 더 효율적이라고 생각합니다.

또한, 로그를 BI로 시각화해 관리하면 더 많은 인사이트를 얻을 수 있습니다.
이런 관점에서 언젠가는 Microsoft Fabric 등과의 연동이 필요해질 것이라 예상합니다.

이번 글에서는 Azure Data Lake Storage (ADLS) Gen2로 로그를 내보내고, 이를 BI로 연결하는 과정을 다룹니다.

Youtube 영상: Microsoft 365 로그 관리 (3): Sentinel 로그를 Azure Data Lake Storage Gen2 연결하기

Step 1. ADLS Gen2 공간 생성

1. Azure Portal 접속 → Storage Accounts 검색

2. Preferred storage type에서 Azure Blob Storage or Azure Data Lake Storage Gen2 선택

3. Hierarchical Namespace에서 Enable hierarchical namespace 체크

Big Data 분석 등 데이터 분석용 스토리지로 Data Lake Storage Gen2가 적합하다는 것을 알 수 있습니다.

이후 쭉 생성과정을 진행합니다.

4. 생성 완료 후 확인

Step 2. Export Rule 생성

1. Log Analytics Workspace → Settings → Data Export → Create export rule

2. Rule 이름 지정

3. Export할 테이블 선택

4. 생성한 Storage Account 지정

5. Data storage → Containers에서 Export된 테이블 확인 (반영되는데 시간이 소요될 수 있습니다.)

6. 하위 폴더에서 5분마다 내보내기 진행 확인할 수 있습니다.

Step 3. Power BI 연결

1. Power BI Desktop → Get data → More

2. Azure를 선택하면 Azure Data Lake Storage Gen2 가 지원되는 것을 알 수 있습니다.

3. URL 입력 요구

4. Azure Storage Explorer로 DFS URL 확인
- Storage Account → Storage browser → Download Azure Storage Explorer → 설치

- 연결 후 폴더 경로 이동 → Properties

- DFS URL 복사

5. Power BI에 URL 붙여넣기

6. 자격증명 입력 (Account Key)

- Account Key는 Security + networking → Access keys에서 확인 가능

7. Connect 후 데이터 Combine & Transform

SharePoint에 저장할 때는 직접 쿼리를 만들어야 했지만, Native Connector를 지원하므로 번거로움이 줄어듭니다.

마무리

이렇게 하면 Microsoft 365 로그를 Azure Data Lake Storage Gen2로 내보내고, Power BI에서 쉽게 시각화할 수 있습니다.
서버리스 환경과 BI 연동을 고려한다면, 이 방식이 장기적으로 더 효율적이고 확장성 있는 로그 관리 방법이 될 것입니다.

Microsoft 365 로그 관리 (2): Microsoft Defender for Identity (MDI) 로그 관리와 Power BI 연결

Pepuri — Sun, 24 Aug 2025 12:33:56 +0900

지난 포스팅:

2025.08.10 - [Microsoft 365] - Microsoft 365 로그 관리 (1) Sentinel로 시작하기

이번에는 MDI Log를 Sentinel에 연결한 뒤, Power BI에서 편집할 수 있게 연결하는 과정을 다루겠습니다.

Youtube: Microsoft 365 로그 관리 (2): Microsoft Defender for Identity (MDI) 로그 관리와 Power BI 연결

Step 1. MDI 활성화 체크

경로: System → Settings → Identities

센서 활성화 확인: 최근 MDI v3는 DC가 MDE 온보딩만 되어 있어도 활성화가 가능해져 등록이 한결 간편해졌습니다.

(새 버전이 정식 릴리스되면 별도 글로 정리하겠습니다.)

Signal 확인: Advanced Hunting에서 AD Logon Event가 기록되는지 확인합니다.

→ 여기서 Signal이 보이면 Sentinel에서도 로그가 수집되는 것을 확인할 수 있습니다.

커넥터 설정: Microsoft Defender XDR → Open connector page

→ Microsoft Defender for Identity 옵션 체크 후 저장

일정 시간 경과 후 Sentinel에서 MDI 로그 조회 가능

Step 2. Sentinel 로그 Export를 위한 Enterprise App 등록

Advanced Hunting과 Sentinel은 (현재 기준) 대량 쿼리에 제한 사항이 있습니다.

최종 목표는 Power BI 시각화로 인사이트를 얻는 것이므로, 우선 SharePoint에 CSV로 적재하는 흐름을 구성합니다.

이를 위해 Log Analytics API 호출 방식으로 접근하며, Enterprise App 등록이 필요합니다.

등록 절차

1. Entra 관리센터 → App registrations → New registration

2. 이름 지정 → Register

3. API permissions → Add a permission

4. APIs my organization uses → Log Analytics API

5. Data.Read 체크 → Add permissions

6. Grant admin consent (테넌트에 동의 부여)

7. Certificates & secrets → New client secret → Description 입력 → Add

8. API 호출용 암호(Secret) 생성 개념

→ 생성된 Value는 별도의 파일에 복사

9. Log Analytics Workspaces → Access control (IAM) → Add role assignment

10. Log Analytics Reader 선택 → Next

11. 방금 만든 App에 권한 부여

Step 3. CSV로 내보내기

각각의 App에 사용할 정보

Tenant ID & Client ID

Workspace ID

Client Secret

AI를 통해서 Log Analytics API를 호출하는 스크립트를 아래와 같이 만들었습니다.

# === Authentication (Service Principal) ===
$TenantId = "<TENANT_ID>"
$ClientId = "<CLIENT_ID>"
$Secret   = "<CLIENT_SECRET>"  

# === Workspace ===
$WorkspaceId = "<WORKSPACE_ID>"

# === Extraction target / Period / Output ===
$Table        = "IdentityLogonEvents"
$StartUtc     = [datetime]"2025-08-12T00:00:00Z"
$EndUtc       = [datetime]::UtcNow
$ChunkHours   = 6  #6시간 단위로 추출
$OutDir       = "F:\sentinel\IdentityLogonEvents"
$FilePrefix   = "IdentityLogonEvents"
$SkipExisting = $true

# === Interval / Retry / Timeout ===
$MinIntervalSeconds = 30 #한번 호출한 뒤, 인터벌
$HttpTimeoutSeconds = 300
$MaxRetries         = 5
$BaseDelaySeconds   = 5

<# ======================= Utilities ======================= #>

# Create folder
New-Item -ItemType Directory -Force -Path $OutDir | Out-Null

# Token cache
$Script:TokenInfo = $null

function Get-LogAnalyticsToken {
    if ($Script:TokenInfo -and $Script:TokenInfo.ExpiresOn -gt (Get-Date).ToUniversalTime().AddMinutes(5)) {
        return $Script:TokenInfo.AccessToken
    }

    $body = @{
        client_id     = $ClientId
        client_secret = $Secret
        grant_type    = "client_credentials"
        scope         = "https://api.loganalytics.io/.default"
    }

    $tokenResponse = Invoke-RestMethod -Method Post `
        -Uri "https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token" `
        -Body $body `
        -TimeoutSec $HttpTimeoutSeconds

    $Script:TokenInfo = [pscustomobject]@{
        AccessToken = $tokenResponse.access_token
        ExpiresOn   = (Get-Date).ToUniversalTime().AddSeconds([int]$tokenResponse.expires_in)
    }
    return $Script:TokenInfo.AccessToken
}

function Invoke-LAQuery {
    param(
        [Parameter(Mandatory=$true)] [string] $Kql,
        [Parameter(Mandatory=$true)] [string] $WorkspaceId
    )

    $attempt = 0
    while ($true) {
        $attempt++
        $token = Get-LogAnalyticsToken
        $headers = @{ Authorization = "Bearer $token" }
        $body    = @{ query = $Kql } | ConvertTo-Json

        try {
            return Invoke-RestMethod -Method Post `
                -Uri "https://api.loganalytics.azure.com/v1/workspaces/$WorkspaceId/query" `
                -Headers $headers -ContentType "application/json" `
                -Body $body -TimeoutSec $HttpTimeoutSeconds
        }
        catch {
            $status = $_.Exception.Response.StatusCode.value__
            $resp   = $null
            try { $resp = [System.IO.StreamReader]::new($_.Exception.Response.GetResponseStream()).ReadToEnd() } catch {}

            # 401: Refresh token
            if ($status -eq 401 -and $attempt -le $MaxRetries) {
                $Script:TokenInfo = $null
                Start-Sleep -Seconds ($BaseDelaySeconds * [math]::Pow(2, $attempt - 1))
                continue
            }

            # 429 or 5xx
            if (($status -eq 429 -or $status -ge 500) -and $attempt -le $MaxRetries) {
                $retryAfter = 0
                try { $retryAfter = [int]$_.Exception.Response.Headers["Retry-After"] } catch {}
                if ($retryAfter -le 0) {
                    $retryAfter = [int]($BaseDelaySeconds * [math]::Pow(2, $attempt - 1))
                }
                Write-Warning "Query throttled/failed (status $status). Retry in $retryAfter sec. Attempt $attempt/$MaxRetries"
                Start-Sleep -Seconds $retryAfter
                continue
            }

            throw "Log Analytics query failed (status $status): $resp"
        }
    }
}

function Convert-RowsToObjects {
    param(
        [Parameter(Mandatory=$true)] $ResultTable
    )
    $cols = $ResultTable.columns.name
    $rows = $ResultTable.rows | ForEach-Object {
        $o = [ordered]@{}
        for ($i=0; $i -lt $cols.Count; $i++) { $o[$cols[$i]] = $_[$i] }
        [pscustomobject]$o
    }

    foreach ($row in $rows) {
        foreach ($p in $row.PSObject.Properties) {
            $v = $p.Value
            if ($v -is [System.Collections.IDictionary] -or
                $v -is [System.Array] -or
                $v -is [PSCustomObject]) {
                $row.($p.Name) = ($v | ConvertTo-Json -Compress -Depth 50)
            }
        }
    }
    return $rows
}

function Wait-ForRateLimit($startedAt, [int]$minSeconds) {
    $elapsed = [int]((Get-Date).ToUniversalTime() - $startedAt).TotalSeconds
    $remain  = $minSeconds - $elapsed
    if ($remain -gt 0) { Start-Sleep -Seconds $remain }
}

<# ======================= Query Loop ======================= #>

$cursor = $StartUtc
while ($cursor -lt $EndUtc) {
    $iterStart = [datetime]::UtcNow

    $chunkStart = $cursor
    $chunkEnd   = $cursor.AddHours($ChunkHours)
    $cursor     = $chunkEnd

    $stamp   = $chunkStart.ToString("yyyyMMddHHmm")
    $outFile = Join-Path $OutDir ("{0}{1}.csv" -f $FilePrefix, $stamp)
    if ($SkipExisting -and (Test-Path $outFile)) {
        Write-Host "Skip: $outFile"
        Wait-ForRateLimit $iterStart $MinIntervalSeconds
        continue
    }

    $startIso = $chunkStart.ToString("yyyy-MM-ddTHH:mm:ssZ")
    $endIso   = $chunkEnd.ToString("yyyy-MM-ddTHH:mm:ssZ")

    $kql = @"
$Table
| where TimeGenerated >= datetime('$startIso')
| where TimeGenerated <  datetime('$endIso')
| order by TimeGenerated asc
"@

    Write-Host ("Query {0}Z ~ {1}Z" -f $chunkStart.ToString("s"), $chunkEnd.ToString("s"))

    try {
        $r = Invoke-LAQuery -Kql $kql -WorkspaceId $WorkspaceId

        if (-not $r.tables -or $r.tables.Count -eq 0 -or -not $r.tables[0]) {
            Write-Host "  -> No result table."
        } else {
            $rows = Convert-RowsToObjects -ResultTable $r.tables[0]
            if ($rows -and $rows.Count -gt 0) {
                $rows | Export-Csv -Path $outFile -NoTypeInformation -Encoding UTF8
                Write-Host ("  -> {0} rows -> {1}" -f $rows.Count, $outFile)

                if ($rows.Count -ge 450000) {
                    Add-Content -Path (Join-Path $OutDir "_oversized.txt") -Value "$startIso~$endIso,$($rows.Count)"
                    Write-Warning "Result very large ($($rows.Count) rows). Consider reducing chunk size for this period."
                }
            } else {
                Write-Host "  -> No rows."
            }
        }
    }
    catch {
        Write-Warning "Error range: $startIso ~ $endIso"
        Write-Warning "Error: $($_.Exception.Message)"
        Add-Content -Path (Join-Path $OutDir "_failed.txt") -Value "$startIso~$endIso"
    }

    Wait-ForRateLimit $iterStart $MinIntervalSeconds
}

Write-Host "Done. Output dir: $OutDir"

앞에서도 언급했듯이 API는 호출에 대한 제한사항이 있기 때문에 ChunkHours 와 MinIntervalSeconds 을 적절하게 조절할 수 있어야 합니다.

정보 값이 정상적으로 입력되었다면, 아래와 같이 내보내기 과정이 진행됩니다.

Step 4. Power BI 연결 (SharePoint의 CSV 집합 로딩)

현재 Sentinel Data Lake 통합(프리뷰)은 있지만, Power BI 직접 연결은 시점에 따라 제한될 수 있습니다.

아래와 같이 Power BI를 연결할 수 있는 쿼리를 제공하지만, API 호출제한 때문에 BI에서 활용할 수 있는 별도의 적재 공간이 필요합니다.

우선 비용 부담이 적은 SharePoint Online에 적재 후 Power BI에서 집계합니다.

Power BI 연결 흐름

SharePoint에 CSV 업로드 (자동화 스크립트 또는 수동)

Power BI Desktop → 데이터 가져오기 → 빈 쿼리 → 고급 편집기

Power Query에서 SharePoint.Files() 함수를 사용해 폴더 내 CSV 병합

let
    // ========== ① User Settings ==========
    SiteUrl         = "https://clim823.sharepoint.com/sites/Sentinel",
    LibraryName     = "Shared Documents",      
    TargetFolder    = "IdentityLogonEvents",     
    FileNamePrefix  = "IdentityLogonEvents",     
    KeepLastNMonths = 6,

    // ========== ② File → Table Conversion Function ==========
    ParseCsv = (fileContent as binary) as table =>
        let
            csv = Csv.Document(
                    fileContent,
                    [Delimiter = ",", Columns = null, Encoding = 65001, QuoteStyle = QuoteStyle.Csv]
                  ),
            promoted = Table.PromoteHeaders(csv, [PromoteAllScalars = true])
        in
            promoted,

    // ========== ③ Navigate to Target Folder ==========
    Source      = SharePoint.Contents(SiteUrl, [ApiVersion = 15]),
    Library     = Source{[Name=LibraryName]}[Content],
    Folder      = Library{[Name=TargetFolder]}[Content],   // DeviceLogonEvents 

    // ========== ④ Filter Files ==========
    FilteredByName = Table.SelectRows(Folder, each Text.StartsWith([Name], FileNamePrefix)),
    FilteredByExt  = Table.SelectRows(FilteredByName, each Text.Lower([Extension]) = ".csv"),

    // ========== ⑤ Load Files → Convert to Tables ==========
    AddedData   = Table.AddColumn(FilteredByExt, "Data", each ParseCsv([Content]), type table),
    TablesList  = List.RemoveNulls(List.Transform(AddedData[Data], each try _ otherwise null)),

    // ========== ⑥ Align Schema & Merge ==========
    AllCols        = if List.Count(TablesList) = 0 
                     then {} 
                     else List.Distinct(List.Combine(List.Transform(TablesList, each Table.ColumnNames(_)))),
    AlignedTables  = List.Transform(TablesList, each Table.ReorderColumns(_, AllCols, MissingField.UseNull)),
    Appended       = if List.Count(AlignedTables) = 0 
                     then #table(AllCols, {}) 
                     else Table.Combine(AlignedTables),

    // ========== ⑦ Filter by Last N Months ==========
    WithTimestampTyped = if List.Contains(Table.ColumnNames(Appended), "Timestamp")
                         then Table.TransformColumnTypes(Appended, {{"Timestamp", type datetime}})
                         else Appended,

    FilteredByDate =
        if List.Contains(Table.ColumnNames(WithTimestampTyped), "Timestamp")
        then Table.SelectRows(WithTimestampTyped, each [Timestamp] >= Date.AddMonths(DateTime.LocalNow(), -KeepLastNMonths))
        else WithTimestampTyped
in
    FilteredByDate

예시 쿼리

아래와 같이 테이블을 가져옵니다. Excel에서 파워쿼리로 편집을 진행하는 것처럼 필요에 따라서 일부 열은 Json형태로 변경하여 활용합니다. -> 닫기 및 적용

닫기 및 적용 → Power BI 편집 진행

Power BI를 활용하면, 보안로그를 기반으로 한 대시보드를 제작 할 수 있습니다.

아래와 같이 시각적으로 어느 디바이스가 어떠한 루트로 공격 받는지 시각적으로 확인할 수 있습니다.

Power BI 관련 내용은 이미 Youtube에 많은 영상이 있기 때문에 제작 과정을 블로그에서 따로 다루지는 않겠습니다.

여기서 다른 Log들과 추가 연계한다면 더 좋은 인사이트를 얻을 수 있을 거라 생각합니다.

Microsoft 365 로그 관리 (1): Sentinel로 시작하기

Pepuri — Sun, 10 Aug 2025 11:55:57 +0900

Microsoft 365. Sentinel 활성화 - YouTube

Microsoft 365 Log

M365를 운영하면서 가장 많이 고민했던 부분 중 하나가 로그 관리였습니다.
처음에는 메시지 추적이나 감사 로그 정도면 충분했는데, 요즘은 Microsoft Defender 같은 보안 솔루션에서 나오는 로그까지 챙기려다 보니 데이터가 정말 많아졌습니다.

그동안 해왔던 방식

예전에는 PowerShell 스크립트로 필요한 로그를 뽑아서 별도 저장소에 넣고, 나중에 SQL 서버로 관리하면서 쿼리로 분석하는 식으로 운영했습니다.
이 방식도 나름 잘 돌아갔지만, 몇 가지 불편한 점이 있었어요.

로그 수집용으로 별도 VM을 운영해야 함
자격 증명 관리가 번거롭고 보안 리스크도 있음
SaaS 기반으로 전환되는 흐름과는 잘 맞지 않는 방식처럼 느껴졌음
로그 스키마가 계속 바뀌고 새로운 로그가 추가되니 유지보수 부담이 커짐

솔직히 말해, 점점 손이 많이 가는 구조가 되어버렸습니다.

Sentinel을 선택한 이유

이 문제를 해결할 방법을 찾다가 Microsoft Sentinel에 관심이 갔습니다.
Sentinel은 원래 SIEM 솔루션이지만, 저는 우선 로그 통합 관리에 초점을 맞춰보려고 합니다.

왜 Sentinel이냐면:

M365와 네이티브로 연동 가능
로그 수집과 스키마 업데이트가 자동화
Defender, Entra, Intune 등 다른 서비스와도 쉽게 연결 가능

AI

요즘 AI 덕분에 이런 기술에 대한 진입장벽이 많이 낮아졌습니다.
특히 Copilot을 활용하면 Sentinel에서 쌓인 데이터를 더 똑똑하게 활용할 수 있을 것 같아요.
결국, 로그가 Sentinel에 쌓이면 DB처럼 적재 → 데이터 활용으로 이어질 거고, AI는 이 데이터를 기반으로 질문에 답해줄 겁니다.
저는 지금 그 준비를 시작하려고 합니다.

이 과정을 통해 기존의 수동적 로그 관리에서 벗어나, 조금 더 자동화되고 똑똑한 방식으로 운영해보려고 합니다.

그러면 본격적으로 구성을 진행해 보겠습니다.

Sentinel이란?

Microsoft Sentinel은 클라우드 기반 SIEM(Security Information and Event Management) 솔루션으로, 다양한 소스에서 보안 로그와 이벤트를 수집하고 분석할 수 있습니다.
이를 통해 위협 탐지, 대응 자동화, 그리고 보안 운영 효율화를 지원합니다.

(Sentinel의 본래 취지에 맞게 진행하는 것은 아니지만, 그래도 정의는 알아야 할 것 같아서 작성하였습니다.)

참고 자료: Microsoft Sentinel이란? | Microsoft Learn

M365 로그 수집 아키텍처

제가 구성하려는 Microsoft 365 → Sentinel 아키텍처는 다음과 같습니다.

M365 -> Sentinel 로그 수집 아키텍쳐

각 M365 영역에서 발생하는 시그널은 기본적으로 제공되는 Built-in 커넥터를 통해 Sentinel로 전달됩니다.
하지만 실제로 테스트해보니, Built-in 커넥터만으로는 모든 로그를 수집할 수 없었습니다.
지원되지 않는 로그는 API 호출 방식이나 Custom Connector를 활용해 추가로 연동해야 합니다.

이번 글에서는 Sentinel 활성화까지만 다루고, 각 영역별 상세 설정은 별도의 포스팅에서 정리할 예정입니다.

Sentinel 활성화 단계

1.Azure Portal 접속

https://portal.azure.com -> Sentinel

2.Sentinel 리소스 생성

Create a new workspace

리소스 그룹 생성

3. Log Analytics Workspace 연결

Log Analytics workspace 생성

생성된 것은 Log Analytics workspace입니다.

다시 Sentinel로 이동하여 Create new Microsoft Sentinel

Workspace에 Add

Add 진행중

4. Microsoft 365 데이터 커넥터 추가

Content hub로 이동

현재 Sentinel은 Defender 페이지와 통합중에 있습니다.
Defender (Security.microsoft.com)이동하여 Microsoft Sentinel을 클릭하면 프로비저닝 되는 것을 확인할 수 있습니다.

Azure 상의 Sentinel - Content hub에서 새로고침을 진행하면, 다음과 같이 추가할 수 있는 Content 들을 확인할 수 있습니다.

간단한 연결 테스트를 위해서 Microsoft Entra ID를 검색하여 Install을 진행합니다.

Data Connectors -> Microsoft Entra ID -> Open connector page

가져올 Log들을 체크 -> Apply Changes

5. 기본 로그 수집 확인 및 테스트

일정 시간이 지나면 Log 수집이 진행되고, 각 항목에 대한 테이블이 확인됩니다.

Run

KQL mode로 전환하면 적재되는 형태를 확인할 수 있습니다.

다음 글에서는 M365 각 로그 활성화 방법을 다루고, 필요 시 E5 온보딩 절차도 함께 정리할 예정입니다.

ADFS & WAP. Upgrade & Migration From 2022 to 2025

Pepuri — Mon, 7 Jul 2025 13:09:05 +0900

이번에는 ADFS & WAP Upgrade & Migration 에 대해서 다루도록 하겠습니다.

제목에 표시한 것처럼 각각의 Windows Server 2022에서 2025로 Upgrarde 및 Migration을 진행합니다.

참고로 Windows Server 2022 에 구성된 ADFS는 ADFS2022, Windows Server 2025 에 구성된 WAP은 WAP2025 와 같이 표시하도록 하겠습니다.

Youtube 영상: https://youtu.be/tHLVgTeNunE

Step 1. ADFS 2025 설치

먼저 ADFS 설치할 서버를 AD에 Join합니다.

Server Manager -> Add roles and features

Active Directory Federation Services 역할 설치과정을 진행합니다.

Install

Configure the federation service on this server

Add a federation server to a federation server farm

Change -> Domain Admin 권한 계정 입력

기존 ADFS 서버 정보를 입력합니다.

인증서를 지정합니다. (사전에 설치과정을 진행합니다.)

ADFS 서비스 계정을 입력합니다.

설치과정을 진행합니다.

설치 완료

AD FS Management를 실행합니다.

현재 서버는 Secondary인 것을 확인할 수 있습니다. Primary <->Secondary 전환 작업을 진행해야 합니다.

새로 설치한 2025 서버에서 다음 명령어를 입력하여 Primary로 전환합니다.

Set-AdfsSyncProperties -Role PrimaryComputer

ADFS 서버를 Secondary로 전환하는 명령어를 진행합니다.

아래 명령어를 기존 2022서버에서 진행합니다.

Set-AdfsSyncProperties -Role SecondaryComputer -PrimaryComputerName <2025서버>

ADFS 2022에서 관리 콘솔 실행시 아래와 같이 Secondary로 변경되었음을 확인할 수 있습니다.

ADFS 2025에서는 아래와 같이 Primary로 변경된 것을 확인합니다.

내부 DNS에서도 ADFS를 가리키는 주소의 IP를 변경해야 합니다.

Step 2. 기존 ADFS 2022 제거

역할 설치 메뉴에서 Start the Remove Roles and Features Wizard

Active Directory Federation Services 역할 체크 해제 후 제거 과정 진행

제거 완료

해당 서버를 Workgroup으로 전환합니다.

Step 3. WAP2025 설치

기존 WAP2022의 hosts 파일에 기록된 정보를 Notepad로 실행하여 복사 한 뒤, WAP2025에 저장합니다.

추가로 게시된 정보는 마이그레이션되지만, 인증서는 포함되지 않으므로 각 인증서를 백업한 후 별도로 가져와야 합니다.

WAP2025에 Remote Access Role 설치 진행

Web Application Proxy 체크 후 설치 과정 진행

Open the Web Application Proxy Wizard

ADFS 서비스 주소 및 자격증명을 입력

사전에 설치한 인증서 선택

Configure

화면을 보면 Cluster가 구성된 것처럼 표시됩니다.

현재의 서버가 추가된 부분을 Get-WebApplicationProxyConfiguration을 통해서 확인할 수 있습니다.

2019, 2022와 마찬가지로 Configuration Version은 Windows Server 2016으로 동일합니다.

Step 4. WAP2022 제거

WAP2022에서 Start the Remove Roles and Features Wizard

Remote Access - Web Application Proxy 역할 체크 해제 후 제거 과정 진행

아래의 명령어를 통해서 현재 연결된 서버 정보를 업데이트 합니다.

Set-WebApplicationProxyConfiguration -ConnectedServersName <WAP2025>

연결정보가 업데이트 된 것을 확인합니다.

Office.com 로그인시에도 정상적으로 로그인 되는 것이 확인되었습니다. Entra ID Connect에서 별도의 작업이 없어도 크게 문제될 건 없어 보입니다.

Exchange Server. In-place Upgrade from 2019 to Subscription Edition (SE)

Pepuri — Sat, 5 Jul 2025 19:59:17 +0900

Youtube 영상

https://youtu.be/qzrKBT6TI7M

Exchange Server Subscription Edition 버전이 드디어 출시했습니다.

Exchange Server Subscription Edition (SE) is now available | Microsoft Community Hub

Copilot의 페이지 요약

이 페이지는 Exchange Server Subscription Edition (SE)의 일반 가용성을 발표하는 내용을 담고 있습니다. 주요 내용은 다음과 같습니다:

출시 배경: Exchange SE는 클라우드, 온프레미스, 하이브리드 모드에서 엔터프라이즈 이메일 서비스를 제공하는 Microsoft의 전통을 이어갑니다.
서비스 및 라이선스 변경: Exchange SE는 Modern Lifecycle Policy에 따라 지속적으로 서비스되며, 고정된 지원 종료일이 없습니다.
업그레이드 세부 사항: Exchange Server 2019 CU14 또는 CU15에서 Exchange SE로 인플레이스 업그레이드가 권장됩니다.
차이점: Exchange SE RTM은 Exchange 2019 CU15와 기능적으로 동일하지만, 이름과 버전 번호가 업데이트되었습니다.
미래 계획: 2025년 10월 이후 Exchange SE는 유일하게 지원되는 온프레미스 버전이 되며, 새로운 기능과 설치 요구 사항이 추가될 예정입니다.

이 페이지는 또한 Skype for Business Server Subscription Edition의 출시도 언급하고 있습니다.

Copilot이 페이지를 요약해주니 편리하네요.
AI가 쉽게 요약도 해주고 표현도 간결하게 정리해줘서 좋습니다.

현재까지 Subscription Edition은 기능적인 업데이트가 아닌 Version Rename에 가깝습니다.
그래서 2019에서 업데이트를 진행한다면, 재 구축할 필요하고 없고, In-Place Upgrade로 진행할 수 있습니다.
업그레이드보다는 업데이트에 가깝다고 볼 수 있습니다.

설치 파일은 아래의 Build Number 페이지에서 다운로드 받을 수 있습니다.

Exchange Server build numbers and release dates | Microsoft Learn

시간 지나면 RTM이라는 표기는 변경될 수 있습니다.

아래와 같이 CU15에서 업그레이드를 진행해서 비교해보겠습니다.

ISO 파일을 탑재한 뒤, Setup 파일을 실행합니다.

상단에 SUBSCRIPTION EDITION 이라고 상단에 표시되는 것을 확인할 수 있습니다.

이전 버전과 동일하게 설치과정을 진행합니다.

설치가 완료되면, 다음과 같이 버전이 변경된 것을 확인할 수 있습니다.

DAG도 정상적으로 유지됩니다.

Graph Connector. SQL 연결

Pepuri — Mon, 5 May 2025 13:25:57 +0900

이번 포스팅은 Graph Connector에서 SQL을 연결하는 방법에 대해서 다루겠습니다.

ChatGPT에 물어봐도 만족할만한 수준의 답변이 나오지 않았고, 해외 블로그를 검색해도 구체적으로 작성한 사례를 찾을 수 없었습니다. 궁극적으로 Graph Connector를 연결하려는 목적은 SQL DB 데이터를 Copilot과 Copilot Studio에서 활용 가능한지에 대한 검증입니다.

이것이 최근에 나온 기술인가? 그것은 아닙니다.

그러면 왜 지금 시점에서 구성을 해보는 것이냐? 라고 하면, 이전에 이것을 안 했던 전제가 바뀌었습니다.

예전에 제가 Graph Connector를 통해서 파일서버를 인덱싱하여 Copilot 활용하는 것에 대해서 다룬 적이 있습니다.

아래의 화면을 보면, 당시에 90일 무료평가판을 신청하면 100만개를 인덱싱할 수 있었습니다.

즉 라이선스를 구매해야 했었습니다. M365 E5가 있다면, 라이선스당 500개 정도를 주었습니다.

중견 기업이상정도가 된다면, 파일 서버의 파일 개수는 1000만개 이상입니다. 즉… 현실적으로 활용가치가 없었습니다.

그런데 작년 9월쯤에 테넌트당 5천만개를 제공한다. 로 바꿨습니다.

Microsoft Graph connectors update: Expand Copilot’s knowledge with 50 million items of external data | Microsoft Community Hub

We’re excited to share that Microsoft 365 and Office 365 subscriptions will now receive a 50 million item index per tenant without any extra cost for data ingested via Microsoft Graph connectors.
With this change, the index quota entitlement per license is removed, as is add-on cost for additional quota.

5천만개라고 하면, 어떻게 활용하느냐에 따라서 활용 가치가 있습니다.

SQL Server 설치는 했다는 전제로 진행하겠습니다.

그리고 Graph Connector를 설치 및 앱 등록 하는 과정은 아래의 글을 참고하여 진행합니다.

2024.06.07 - [Copilot/Graph Connector] - Copilot. File Server를 Graph Connector로 연결하여 활용하기

Step 1. TestTable 생성

연결 구조는 다음과 같습니다.

New Query

아래의 스크립트를 실행

-- 1. Create new table
CREATE TABLE dbo.TestTable (
  [Date]        DATE         NOT NULL,  -- Transaction date
  [DealNo]      INT          IDENTITY(1,1) PRIMARY KEY,  -- Unique deal number
  [SalesPerson] NVARCHAR(50) NOT NULL,  -- Sales person name
  [Region]      NVARCHAR(50) NOT NULL,  -- Region
  [Product]     CHAR(1)      NOT NULL,  -- Product code (A–E)
  [SalesAmount] INT          NOT NULL   -- Sales amount (integer)
);
GO

-- 2. Insert sample data (DealNo is auto-generated by IDENTITY)
INSERT INTO dbo.TestTable ([Date], [SalesPerson], [Region], [Product], [SalesAmount])
VALUES
  ('2025-05-01', N'Kim Chulsoo',   N'Seoul',      'A', 1200000),
  ('2025-05-02', N'Lee Younghee',   N'Busan',      'B',  950000),
  ('2025-05-03', N'Park Minsu',     N'Incheon',    'C', 1100000),
  ('2025-05-04', N'Choi Minji',     N'Daegu',      'D',  780000),
  ('2025-05-05', N'Jung Hyunwoo',   N'Daejeon',    'E', 1025000);
GO

-- 3. Verify inserted data
SELECT
  [Date],
  [DealNo],
  [SalesPerson],
  [Region],
  [Product],
  [SalesAmount]
FROM dbo.TestTable
ORDER BY [DealNo];
GO

아래와 같이 생성 진행

Step 2. Graph Connector 설정

Settings -> Search & intelligence -> Data sources -> Add Connection

Microsoft SQL server(New) -> Next

SQL 연결 정보 입력 -> Authorize

상단의 Content

아래의 스크립트를 입력합니다.

SELECT
  [Date]        AS Date,
  [DealNo]      AS DealNo,
  [SalesPerson] AS SalesPerson,
  [Region]      AS Region,
  [Product]     AS Product,
  [SalesAmount] AS SalesAmount
FROM dbo.TestTable
WHERE [Date] >= COALESCE(
    TRY_CONVERT(datetime2, @watermark),
    '1900-01-01T00:00:00'
)
ORDER BY [Date] ASC;

Preview 를 클릭하고 다음과 같이 선택합니다.

아래와 같이 속성 설정을 진행합니다.

권한 설정을 진행합니다.

Time zone 설정 -> Create

동기화 진행

Graph Connector가 연결된 뒤, 아래와 같이 Copilot Studio에서 SQL Server를 참조 자료로 추가할 수 있습니다.

M365 Copilot Agent에서도 아래와 같이 활성화 할 수 있습니다.

지금까지 작성한 내용은 Copilot Studio와 연계할 수 있는지 여부를 검토하는 관점에서 작성되었습니다. 데이터 자체의 활용은 불가능할 수 있습니다. 위 내용을 바탕으로 RawData가 준비되면 Graph Connector를 통해 활용 가능성을 검증할 수 있을 것입니다.

과거에는 SQL을 몰라서 진행이 어려웠지만, 이제는 AI의 도움을 받아 시행착오를 겪더라도 제작할 수 있게 되었습니다. AI를 활용해도 글로벌 차원에서 위 내용에 대한 레퍼런스가 없어서 오답만 받았고, 많은 시간을 소모했습니다.

Remote Desktop. Host 서버 인증서 바인딩

Pepuri — Fri, 2 May 2025 11:51:39 +0900

테스트 환경에 원격 접속할 때, 한번 쯤 아래의 인증서 메시지가 귀찮다고 느낀 적이 있으실 겁니다.

주변 지인이 인증서 바인딩을 하고 UDP로 연결하면, Remote Desktop이 쾌적해 질 수 있다고 하여, 바인딩을 진행해보기로 하였습니다. (UDP는 원래 사용중)

아래의 기술자료를 참고하여 진행하였습니다.

Remote Desktop listener certificate configurations - Windows Server | Microsoft Learn

먼저 인증서는 공인 SSL 인증서를 발급 받아서 사전에 설치하였습니다.

Step 1. Thumbprint 확인

Powershell에서 아래의 명령어를 진행합니다.

Get-ChildItem -Path Cert:\LocalMachine\My

Step 2. 바인딩 & RDP 서비스 재시작

#바인딩
wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="THUMBPRINT값 입력"

# RDP 서비스 재시작
Restart-Service TermService -Force

참고로 바인딩이 정상적으로 진행되면 아래의 경로에 레지스트리 값이 추가됩니다.

더 이상 원격 연결할 때, 인증서 경고 메시지가 나타나지 않으면서 연결됩니다.

Exchange Server 2019. Database availability groups (DAG) 구성 / 이중화

Pepuri — Wed, 29 Jan 2025 18:55:11 +0900

이전 포스팅

2024.12.31 - [Exchange] - Exchange Server 2019. Deployment (2): 구성 (CU14, Nov24SUv2 / Windows Server 2022)

예전에도 DAG 구성을 Exchange Server 2013 기준으로 작성한 적이 있습니다.

2021.12.25 - [Exchange] - Exchange Server. DAG 구성(IPLess 방식)

이번에 Youtube 영상을 제작을 진행하면서 블로그 글도 작성하게 되었습니다.

곧 다가올 Subscription Edition Upgrade와 관련되어 테스트 환경 구성시 필요할 것이라 생각하여 오랜만에 다시 구성해

보았습니다.

https://youtu.be/FrV8uRWNRQs

DAG는 한국에서는 이중화라는 표현으로도 많이 사용됩니다.

Exchange Server에서 DB에 문제가 발생하였을 때, 자동 장애 조치를 제공하는 기능입니다. 자세히 들어가면 여러가지 상황 및 설명이 필요하지만, 지금은 단순하게 구성하는 방향이기 때문에 깊게 설명하지는 않겠습니다.

이전 글에서의 환경과 스펙은 같으며, Exchange Server는 3대로 구성하였습니다.

그리고 최종 구성도는 다음과 같습니다.

이번에도 구성은 IP-Less 방식으로 진행합니다.

Database availability groups | Microsoft Learn

IP-Less 방식은 다음과 같은 특징을 가지고 있습니다.

- 클러스터/DAG에 IP 주소가 할당되지 않으므로 클러스터 핵심 리소스 그룹에 IP 주소 리소스가 없습니다.
- 클러스터에 네트워크 이름이 할당되지 않으므로 클러스터 핵심 리소스 그룹에 네트워크 이름 리소스가 없습니다. - 클러스터/DAG의 이름이 DNS에 등록되지 않으며 네트워크에서 확인할 수 없습니다.
- CNO(클러스터 이름 개체)가 Active Directory에서 만들어지지 않습니다.
- 장애 조치 클러스터 관리 도구를 사용하여 클러스터를 관리할 수 없습니다.
- 클러스터는 Windows PowerShell을 사용하여 관리해야 하며 개별 클러스터 구성원에 대해 PowerShell cmdlet을 실행해야 합니다.

GPT에게 요청하여 기존방식과 IP Less 방식을 비교해 달라고 하였으며, 아래와 같이 표로 정리하였습니다.

항목	기존 DAG 방식	IP Less DAG
Active Directory 의존성	CNO 및 AD 객체 필요	AD 객체 불필요
IP 주소	Static IP 필요	IP 주소 불필요
DNS 등록	필요	불필요
Failover 속도	상대적으로 느림	상대적으로 빠름
관리 복잡도	AD 및 네트워크 관리 필요	관리 부담 감소
보안 문제	AD 개체 관리 및 권한 필요	AD 개체 필요 없음

저는 3rd Party에서의 호환성 문제가 없다면, IP-less 방식을 권장합니다.

사전준비사항

DAG를 구성할 때는 디스크 구조를 동일하게 구성해야 합니다.

DB Disk를 D드라이브로 구성했다면, 나머지 서버들도 동일하게 D드라이브를 구성해야 합니다.

Step 1. Witness Directory 만들기

먼저 Witness가 무엇인지 알아보겠습니다.

1. Witness Server란?

Witness Server(감시 서버)는 Database Availability Group(DAG) 내에서 클러스터 쿼럼(Cluster Quorum) 유지에 필요한 투표권을 제공하는 서버입니다. DAG는 홀수 개의 투표(Quorum)를 유지해야 클러스터가 정상 동작하는데, 이를 위해 Witness Server를 활용합니다.

DAG는 기본적으로 Mailbox Server가 다수 포함된 Windows Failover Cluster로 동작하며, 클러스터의 정족수(Quorum)를 유지해야 합니다. 하지만 DAG 내의 Mailbox Server 개수가 짝수(2, 4, 6...)인 경우, 정족수 결정을 위한 추가적인 투표권이 필요합니다. 이때 Witness Server가 추가적인 1표를 제공하여 Quorum을 유지합니다.

그렇다면, 지금은 3대인데 왜 Witness를 구성해야 하는지에 대해서 의문이 생길 것입니다.

GPT는 아래와 같이 답변해주었습니다.

서버 개수	Witness 포함 투표 수	동작 여부	과반수(Quorum) 확보 여부
3대 모두 정상 작동	4 (서버 3 + Witness 1)	✅ 정상 운영	(4/2 = 2 이상 필요) OK
1대 장애 (서버 2대 남음)	3 (서버 2 + Witness 1)	✅정상 운영	(3/2 = 1.5 → 2 이상 필요) OK
2대 장애 (서버 1대 남음)	2 (서버 1 + Witness 1)	✅ 정상 운영	(2/2 = 1 이상 필요) OK
3대 장애 (서버 0대 남음)	1 (Witness 1)	❌ DAG 중단	(1/2 = 0.5 → 1 이상 필요) 실패

결국 안정적인 운영을 위해서는 Witness는 반드시 필요합니다.

2. Witness Directory란?

Witness Directory는 Witness Server 내에 생성되는 공유 폴더로, DAG의 정상적인 작동을 위해 사용됩니다.

이 폴더에는 클러스터 상태를 기록하는 파일이 저장되며, Failover 발생 시 DAG 내에서 살아남은 노드들이 이 폴더를 이용하여 정족수(Quorum) 여부를 판단합니다.

Witness 폴더 기본 설정

Witness Server에 공유 폴더를 생성해야 함.
보통 C:\DAGWitness와 같은 경로에 생성됨.
Witness Server가 DAG 내의 모든 Mailbox Server와 통신 가능해야 함.
Exchange Trusted Subsystem 그룹에 해당 폴더의 읽기/쓰기 권한(Read/Write Permission)을 부여해야 함.

즉 Witness Server를 별도로 운영해야 하며, 거기서 Witness Directory 를 만들어야 합니다.

저는 아래의 구성도와 같이 Azure AD Connector 서버에서 Witness 서버로도 활용합니다.

(최근 Azure AD Connect가 Entra ID Connect로 이름 변경됨)

Witness Server에 아래와 같이 Witness 폴더를 생성합니다.

우클릭 -> Properties

Sharing -> Share

Find people

Exchange Trusted Subsystem -> Check Names -> OK

Permission Level: Read/Write -> Share

Done

시작 버튼 우클릭 -> Computer Management

Local Users and Groups -> Groups -> Administrators

Add

Exchange Trusted Subsystem -> Check Names -> OK

Witness Server에서 Witness 폴더를 생성한 뒤, Exchange Trusted Subsystem에 권한 부여를 완료하였습니다.

Step 2. DAG 구성

아래와 같이 Exchange 서버를 DAG로 묶어줍니다.

Exchange Admin Center (ECP) -> Servers -> database availibility groups -> Add

DAG 이름을 지정 -> Witness 정보를 입력 -> Save

다음과 같이 생성됩니다.

Manage DAG Membership

우선 1대를 추가 -> Save

구성이 진행됩니다.

나머지 Exchange Server도 동일하게 추가합니다.

Step 3. DB 복제

DAG 구성이 완료되었으면, 아래와 같이 DB를 복제합니다.

databases -> DB 선택 -> Add database copy

Exchange Server를 추가한 뒤, Save

만약 순환 로깅이 켜져있으면, 아래와 같이 오류가 발생합니다. DB 복제할 때는 해당 기능을 Disable 합니다. 완료되면 이후에 다시 Enable합니다.

처음에는 오류가 발생할 수도 있습니다.

잠시 뒤에 다시 Update를 클릭해서 강제로 복제를 진행하면, 정상적으로 진행이 완료됩니다.

최종적으로는 아래와 같이 Healthy 상태로 확인할 수 있습니다.

다른 서버에서도 아래와 같이 복제가 진행된 것을 확인합니다.

Copilot Studio. 특정 메시지 입력하였을 때 Email로 알림 설정

Pepuri — Sun, 12 Jan 2025 18:22:07 +0900

이전에 특정 메시지가 입력되면 Teams로 알리는 흐름을 만들었습니다.

2024.08.14 - [Copilot/Copilot Studio] - Copilot Studio. Power Automate를 이용한 특정 메시지 입력시 Teams로 메시지 전송 설정

해당 영상을 보고 Email로 알림을 설정하는 방법에 대하여 요청을 주었고, 해당 흐름을 생성해 보도록 하겠습니다.

최근에는 Copilot Studio에서 생성되는 Chatbot을 Agent 라는 용어로 부르고 있습니다. 변동사항이 없으면 Agent라고 정의하겠습니다.

Environment는 USA (Early)로 설정하였으며, 브라우저 언어는 영문입니다. 그리고 Preview URL에 접속하여 작업하였습니다.

Library -> + Add New

Flow

Create flow in Power Automate

New designer

규칙 이름을 변경합니다.

Add an action

Office 365 Outlook

Send an email

메일 양식 작성

Publish

메일 흐름을 연결할 Agent에서 Topics 메뉴로 이동합니다.

Escalate 선택

아래와 같이 Call an action에서 Flow를 추가합니다.

Save -> Publish

Test Chat에서 Escalate 입력

Connect

Submit

Connected 상태 확인

아래와 같이 메일이 수신되는 것을 확인할 수 있습니다.

Exchange Server 2019. Deployment (2): 구성 (CU14, Nov24SUv2 / Windows Server 2022)

Pepuri — Tue, 31 Dec 2024 15:47:27 +0900

Ver 1.2 2024/12/17 - Exchange Server 2019. 구성 (CU14, Nov24SUv2 / Windows Server 2022)으로 새로 포스팅

Ver 1.1 2023/02/09 - Exchange Server 2019. Deployment (2) 구성 (CU12, Jan23SU 기준) - CU12, Jan23SU 기준으로 수정, 인증서 설정, 가상디렉터리 설정등 대폭 수정

2020.12.11 - [Exchange] - Exchange Server 2019. Deployment (2) 구성 (CU12, Jan23SU 기준)

~~Ver 1.0 2020/12/09 - Exchange Server 2019. 설치 (1) -초판~~

지난 포스팅

2024.12.17 - [Exchange] - Exchange Server 2019. Deployment (1) 설치 (CU14, Nov24SUv2 / Windows Server 2022 기준)

https://youtu.be/JzfvhMMZQ8w

Step 1. 송신커넥터 설정 (Must)

수신은 별도의 설정 없이도 가능하지만, 송신은 반드시 커넥터 설정을 진행해야 합니다.

Mail flow -> send connectors -> New (+)

Connector 이름 지정 -> Type: Internet -> Next

Add

FQDN 지정 -> Save

Add -> Source Server 지정 -> Finish

송신 커넥터 생성 확인

https://localhost/owa 에 접속 및 로그인 후 테스트 메일 발송 (Outlook.com은 작성한 날짜를 기준으로 SPF레코드를 등록하지 않아도 발송되는 것으로 확인됩니다.) -> 수신 확인

Step 2. 가상 디렉터리 설정 (Recommend)

Outlook 등 여러 Client 연결을 위해서 가상 디렉터리 설정을 진행합니다.

Exchange Management Shell을 실행합니다.

아래의 Script를 실행합니다.

#공통으로 지정할 URL 입력
$url = "https://mail.wingtiptoys.kr"
$autodiscover = "https://autodiscover.wingtiptoys.kr"
 
#Virtual Directory 내외부 동일하게 변경
#ECP
Get-EcpVirtualDirectory | Set-EcpVirtualDirectory -InternalUrl "$url/ecp"  -ExternalUrl "$url/ecp" 
#EWS
Get-WebservicesVirtualDirectory | Set-WebservicesVirtualDirectory -InternalUrl "$url/ews/Exchange.asmx"  -ExternalUrl "$url/ews/Exchange.asmx" 
#MAPI
Get-MapiVirtualDirectory | Set-MapiVirtualDirectory -InternalUrl "$url/mapi"  -ExternalUrl "$url/mapi"
#EAS
Get-ActiveSyncVirtualDirectory | Set-ActiveSyncVirtualDirectory -InternalUrl "$url/Microsoft-Server-ActiveSync"  -ExternalUrl "$url/Microsoft-Server-ActiveSync"
#OAB
Get-OabVirtualDirectory | Set-OabVirtualDirectory -InternalUrl "$url/oab"  -ExternalUrl "$url/oab"
#OWA
Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -InternalUrl "$url/owa"  -ExternalUrl "$url/owa"

#Autodiscover
Get-ClientAccessService | Set-ClientAccessService -AutodiscoverServiceInternalUri "$autodiscover/autodiscover/autodiscover.xml"

#각각의 서버에서 아래의 명령어 진행
IISReset

Step 3. Accepted Domain

테스트 환경처럼 Corp. 로 도메인을 생성하거나 .local로 생성할 경우에는 실제 수신할 수 있는 주소를 accepted domain을 추가해야 합니다.

Mail flow -> accepted domains -> + (추가)

도메인을 추가합니다.

Step 4. Email Address Policies 수정

새로 생성되는 사서함이 자동으로 추가한 도메인으로 지정하려면 Email address policies를 수정해야 합니다.

Mail flow -> email address policies -> Default Policy

Email address format -> 수정

Email address parameters 를 수정합니다.

Save

Step 5. DNS 설정 (Must)

내부 DNS 서버, 외부 DNS 서버에 Autodiscover, OWA, SPF, MX 레코드에 대한 값을 입력합니다. (영상 참고)

예시) 내부 DNS

예시) 외부 DNS

Step 6. 인증서 설치 (Must)

처음에는 Exchange Server UI에서 인증서 요청을 작성하였으나, 최근에는 Digicert에서 제공하는 Tool이 간편해서 해당 Tool을 이용해서 생성하고 있습니다.

실무에서는 대부분 인증서 판매업체에서 대부분의 과정을 진행해줍니다.

Create CSR

저는 Multi SAN을 구매하여, 그 기준으로 작성하였습니다.

CSR 복사

구매한 인증서 사이트에서 발급 과정 진행

도메인 인증과정은 DNS 인증과정을 진행하거나

Email로 수신하여 인증할 수 있습니다.

발급 받은 인증서를 Import

파일을 지정

이름 지정 -> Finish

인증서 설치됨 확인

아래의 명령어를 진행하여 설치한 인증서를 바인딩합니다.

#설치된 인증서 조회
Get-ExchangeCertificate
#인증서 바인딩
Enable-ExchangeCertificate -Thumbprint <지문값> -Services IIS,SMTP -DoNotRequireSsl
#IIS 서비스 재시작 (Exchange Management Shell을 관리자 권한으로 실행 필요)
IISReset

내부, 외부에서 Exchange Server에 접속하여 인증서가 올바르게 적용되었는지를 확인합니다.

Step 7. DB 관리 (Optional)

실제 환경에서 DB 위치와 설치경로를 동일하게 하는 경우는 거의 없습니다.

D 드라이브로 이동해 보도록 하겠습니다.

우선 Servers -> Databases 메뉴로 이동하면 기본 DB 이름을 확인할 수 있습니다.

아래의 명령어를 진행합니다.

#각 서버에서 진행
#DB 이름 변경
Get-MailboxDatabase -Identity "DB명"|Set-Mailboxdatabase -Name "새DB명"
#DB 경로 이동
Move-DatabasePath "새DB명" -EdbFilePath "D:\EDB01\EDB01.edb" -LogFolderPath "D:\EDB01\"

지정된 경로로 edb와 로그 파일들이 이동된 것을 확인할 수 있습니다.

Admin Center에서 변경된 정보를 확인합니다.

그리고 DB 의 로그의 용량은 상당하기 때문에, 백업 솔루션을 사용하지 않는 다면, 순환 로깅 사용을 설정합니다.

Servers -> databases -> maintenance -> Enable circular logging

Step 8. 메일 송수신 로그 활성화 및 경로 변경 (Optional)

SMTP와 관련된 로그가 일부 영역만 활성화 되어 있습니다.

Mail Flow 분석이 필요한 경우를 대비하여 관련 로그를 활성화하고, 경로 또한 별도로 관리하는 것을 권장합니다.

다음 명령어로 변경합니다.

#Exchange 메일 송수신 Log 위치 변경 
$path= "D:\ExchangeLogs"

#Frontend Transport Service
Get-FrontendTransportService | Set-FrontendTransportService -ConnectivityLogPath "$path\Frontend\Connectivity" -ReceiveProtocolLogPath "$path\Frontend\ProtocolLog\SmtpReceive" -SendProtocolLogPath "$path\Frontend\ProtocolLog\SmtpSend" -AgentLogPath "$path\Frontend\AgentLog" -DnsLogPath "$path\Frontend\DNSLog" -DnsLogEnabled $true
Get-FrontendTransportService | Set-FrontendTransportService -IntraOrgConnectorProtocolLoggingLevel Verbose
 
#Transport Service
Get-Transportservice | Set-TransportService -ConnectivityLogPath "$path\Hub\Connectivity" -MessageTrackingLogPath "$path\MessageTracking" -IrmLogPath "$path\IRMLogs" -ActiveUserStatisticsLogPath "$path\Hub\ActiveUsersStats" -ServerStatisticsLogPath "$path\Hub\ServerStats" -ReceiveProtocolLogPath "$path\Hub\ProtocolLog\SmtpReceive" -SendProtocolLogPath "$path\Hub\ProtocolLog\SmtpSend" -QueueLogPath "$path\Hub\QueueViewer" -WlmLogPath "$path\Hub\WLM" -PipelineTracingPath "$path\Hub\PipelineTracing" -AgentLogPath "$path\Hub\AgentLog" -DNSLogEnabled $true -DnsLogPath "$path\Hub\DNSLog"
Get-TransportService | Set-TransportService -IntraOrgConnectorProtocolLoggingLevel Verbose
 
#Mailbox Transport Service
Get-MailboxTransportService | Set-MailboxTransportService -ConnectivityLogPath "$path\Mailbox\Connectivity" -ReceiveProtocolLogPath "$path\Mailbox\ProtocolLog\SmtpReceive" -SendProtocolLogPath "$path\Mailbox\ProtocolLog\SmtpSend" -MailboxDeliveryThrottlingLogPath "$path\Mailbox\ProtocolLog\Delivery" -MailboxDeliveryAgentLogPath "$path\Mailbox\AgentLog\Delivery" -MailboxSubmissionAgentLogPath "$path\Mailbox\AgentLog\Submission"
Get-MailboxTransportService | Set-MailboxTransportService -MailboxDeliveryConnectorProtocolLoggingLevel Verbose

#Enable Logging about Send & ReceiveConnector 
Get-SendConnector | Set-SendConnector -Protocollog Verbose
Get-ReceiveConnector | Set-ReceiveConnector -Protocollog Verbose

결과 확인

Step 9. 사용하지 않는 수신 커넥터 비활성화

POP3, IMAP, Outbound Proxy를 사용하지 않는다면, 아래의 표시된 커넥터들을 비활성화 합니다.

Step 10. IIS 로그 경로 변경 (Optional)

Exchange 에서 가장 리소스를 많이 차지하는 영역 중 하나는 IIS 입니다.

IIS Log는 별도로 관리하지 않으면, C 드라이브 용량이 부족해 질 수 있으므로 별도의 경로로 관리하는 것을 권장합니다.

IIS Manager - [서버] - Logging

아래와 같이 변경 후 적용

IISReset을 진행한 뒤, 아래와 같이 로그가 저장되는 것을 확인합니다.

Step 11. http to https redirection 설정 (Optional)

실제 기업환경은 대부분 http(80) 입력을 하였을 때, https(443)로 리디렉션 하는 설정을 진행합니다.

MS 기술자료에서 진행하는 방법이 자세히 설명되어 있으며, 아래의 자료를 기준으로 진행합니다.

Exchange Server에서 웹용 Outlook에 대 한 http 리디렉션을 구성 합니다.

https://docs.microsoft.com/ko-kr/exchange/clients/outlook-on-the-web/http-to-https-redirection?view=exchserver-2019

IIS 관리자를 사용하여 기본 웹 사이트에서 SSL 필요 설정을 제거

%windir%\system32\inetsrv\appcmd.exe set config "Default Web Site" -section:access -sslFlags:None -commit:APPHOST

IIS 관리자를 사용하여 기본 웹 사이트의 다른 가상 디렉터리에 SSL 필요 설정 복원

%windir%\system32\inetsrv\appcmd.exe set config "Default Web Site/api" -section:Access -sslFlags:Ssl,Ssl128 -commit:APPHOST
%windir%\system32\inetsrv\appcmd.exe set config "Default Web Site/aspnet_client" -section:Access -sslFlags:Ssl,Ssl128 -commit:APPHOST
%windir%\system32\inetsrv\appcmd.exe set config "Default Web Site/Autodiscover" -section:Access -sslFlags:Ssl,Ssl128 -commit:APPHOST
%windir%\system32\inetsrv\appcmd.exe set config "Default Web Site/ecp" -section:Access -sslFlags:Ssl,Ssl128 -commit:APPHOST
%windir%\system32\inetsrv\appcmd.exe set config "Default Web Site/EWS" -section:Access -sslFlags:Ssl,Ssl128 -commit:APPHOST
%windir%\system32\inetsrv\appcmd.exe set config "Default Web Site/mapi" -section:Access -sslFlags:Ssl,Ssl128 -commit:APPHOST
%windir%\system32\inetsrv\appcmd.exe set config "Default Web Site/OAB" -section:Access -sslFlags:Ssl,Ssl128 -commit:APPHOST
%windir%\system32\inetsrv\appcmd.exe set config "Default Web Site/owa" -section:Access -sslFlags:Ssl,Ssl128 -commit:APPHOST

하위 가상 디렉터리에 대한 http 리디렉션 제거

%windir%\system32\inetsrv\appcmd.exe set config "Default Web Site/API" -section:httpredirect -enabled:false -destination:"" -childOnly:false
%windir%\system32\inetsrv\appcmd.exe set config "Default Web Site/aspnet_client" -section:httpredirect -enabled:false -destination:"" -childOnly:false
%windir%\system32\inetsrv\appcmd.exe set config "Default Web Site/ecp" -section:httpredirect -enabled:false -destination:"" -childOnly:false
%windir%\system32\inetsrv\appcmd.exe set config "Default Web Site/ews" -section:httpredirect -enabled:false -destination:"" -childOnly:false
%windir%\system32\inetsrv\appcmd.exe set config "Default Web Site/mapi" -section:httpredirect -enabled:false -destination:"" -childOnly:false
%windir%\system32\inetsrv\appcmd.exe set config "Default Web Site/owa" -section:httpredirect -enabled:false -destination:"" -childOnly:false
%windir%\system32\inetsrv\appcmd.exe set config "Default Web Site/powershell" -section:httpredirect -enabled:false -destination:"" -childOnly:false
%windir%\system32\inetsrv\appcmd.exe set config "Default Web Site/rpc" -section:httpredirect -enabled:false -destination:"" -childOnly:false

#IIS 다시시작

IISRESET

#만약 운영서버가 여러대라면, 모든서버에서 동일하게 진행합니다.

작동 여부는 어떻게 확인하나요?

클라이언트 컴퓨터에서 웹 브라우저를 열고 URL http://를 입력 합니다 <ServerName> . 로컬 서버에서 값 또는를 사용할 수 있습니다 http://127.0.0.1 http://localhost .
Https에서 웹의 Outlook으로 리디렉션되어 있는지 확인 하 고 로그인 할 수 있는지 확인 합니다.
URL http:// <ServerName> /owa 또는 또는를 엽니다 http://127.0.0.1/owa http://localhost/owa) .
Https에서 웹의 Outlook으로 리디렉션되어 있는지 확인 하 고 로그인 할 수 있는지 확인 합니다.

#그리고 당연한 얘기이지만, 80 포트에 대한 포워딩 설정이 Exchange를 가리켜야 합니다.

아래와 같이 입력후 엔터 입력시

아래와 같이 리디렉션 됩니다.

Step 12. 큐 DB 위치 변경 (Optional)

기술자료: Change the location of the queue database | Microsoft Learn

일반적으로는 아래의 경로에 큐DB가 존재합니다.

C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\data\Queue

큐에 메일이 쌓이면, Mail.que 파일이 커지게 됩니다. 디스크 용량이 부족해지는 수준에 도달하면 Transport 서비스가 중지됩니다. 이러한 서비스 장애를 사전에 예방하기 위해서 큐DB의 위치를 변경하여 관리하는 경우가 많습니다.

새로 지정할 큐DB 폴더를 생성합니다. (테스트 환경에서는 D드라이브에 설정했지만, 실제 환경에서는 DB와 다른 위치 사용을 권장합니다.

명령 프롬프트를 관리자 권한으로 실행합니다.

다음 명령어를 실행합니다.

Notepad %ExchangeInstallPath%Bin\EdgeTransport.exe.config

다음 위치를 찾습니다.

아래와 같이 변경 -> 저장

Microsoft Exchange Transport 서비스를 재시작 합니다.

아래와 같이 변경되는 것을 확인할 수 있습니다.

Step 13. OAB 지정 (Optional)

각 DB에 대해서 OAB를 지정합니다.

이번 포스팅은 여기서 마치겠습니다. 세부적으로 들어가면 각각의 항목에는 전제가 있습니다.

기회가 되면 각 항목에 대해서 자세히 다뤄보겠습니다.

Exchange Server 2019. Deployment (1) 설치 (CU14, Nov24SUv2 / Windows Server 2022 기준)

Pepuri — Tue, 17 Dec 2024 14:32:58 +0900

Ver 1.2 2024/12/17 - Exchange Server 2019. 설치 (CU14, Nov24SUv2 / Windows Server 2022)으로 새로 포스팅

Ver 1.1 2023/02/09 - Exchange Server 2013. 설치 (CU12, Jan23SU 기준)으로 수정 업데이트

2020.12.09 - [Exchange] - Exchange Server 2019. Deployment (1) 설치 (CU12, Jan23SU 기준)

~~Ver 1.0 2020/12/09 - Exchange Server 2019. 설치 (1) -초판~~

최신 업데이트에서는 Windows Server 2022를 지원합니다. 향후 SE (Subscription Edition) 버전을 위해서 구축을 하는 케이스가 있을 것으로 예상되어 새로 작성하게 되었습니다. 기존 설치글과 큰 차이는 없습니다.

다만 새로 공부하는 엔지니어들은 버전 숫자에 대한 개념에 대한 이해가 부족할 수 있습니다. 새 업데이트를 기준으로 작성하면서 유튜브 영상도 업로드할 예정입니다.

Exchange Server 설치가 처음이면, 아래의 단계들을 먼저 진행해야 합니다.

2024.11.09 - [Windows Server] - Windows Server 2025. Install & Sysprep

2024.12.15 - [Windows Server] - Windows Server 2025. Active Directory (AD) Domain Controller(DC) 구성

https://youtu.be/oIj7JkV4Q_g

VM 환경은 다음과 같습니다.

DC: Windows Server 2025, 4 Core, RAM: 4GB

EX: Windows Server 2022, 8 Core, RAM: 10GB, Exchange Server 2019 CU12

아래의 자료를 기준으로 작성하였습니다.

[단계1] 사전 작업

Exchange Server에 사용할 서비스 계정을 생성

Exchange Server prerequisites, Exchange 2019 system requirements, Exchange 2019 requirements | Microsoft Learn

Exchange Server에 사용할 서비스 계정을 생성

Enterprise Admins, Schema Admins 권한을 부여합니다.

서비스 계정으로 AD에 Join합니다.

Netplwiz 실행

서비스 계정을 Administrator 권한을 부여합니다.

[단계2] 가상메모리 설정

가상메모리는 퍼포먼스에 영향을 줄 수 있기 때문에 반드시 고정으로 설정하는 것을 권장합니다.

System -> Advanced system settings -> Advanced -> Settings

Advanced -> Change

용량 지정 -> Set -> OK

2019 기술자료에서는 설정된 RAM의 25%로 설명되어 있습니다. 최소 권장 사양이 128GB 이기 때문인 것으로 추정됩니다. (다만 테스트 환경에서는 RAM + 10MB를 권장드립니다.)

Restart Now

[단계3] 필수 기능 및 역할 설치

아래의 필수 구성요소를 설치합니다.

Visual C++ Redistributable Package for Visual Studio 2012

Download Visual C++ Redistributable for Visual Studio 2012 Update 4 from Official Microsoft Download Center

Visual C++ Redistributable Package for Visual Studio 2013

Update for Visual C++ 2013 Redistributable Package - Microsoft Support

Unified Communications Managed API 4.0 Runtime

Download Unified Communications Managed API 4.0 Runtime from Official Microsoft Download Center

시작 버튼 우클릭 - Powershell 을 관리자 권한으로 실행

아래의 명령어로 기능 및 역할 설치

Install-WindowsFeature Server-Media-Foundation, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation, RSAT-ADDS, Failover-Clustering

#Failover-Clustering은 DAG 구성시 필수.

아래의 링크를 클릭하여 IIS URL Rewrite Module 을 설치합니다.

IIS URL Rewrite Module

[단계4] 설치 진행

Exchange Server 2019 설치 디스크 이미지는 아래의 Build Number 페이지에서 CU 최신 버전을 다운로드 합니다.

(SU는 CU를 설치한 뒤 진행합니다.)

Exchange Server build numbers and release dates | Microsoft Learn

설치 디스크에서 Setup

Don’t' check for updates right now -> next

2번째 항목 체크 -> Next

Don't user recommended settings -> Next

Mailbox role -> Next

설치 경로 지정 -> Next

조직명 입력 -> Next

Install

설치과정 진행

설치 완료

[단계5] SU 설치

SU는 CU이후에 설치하는 Security Update입니다.

Build Number Page에서 최신 SU 다운로드

설치 진행 -> Next

I accept the License Terms -> Next

설치 진행중

Finish

Yes -> 재부팅 진행

Exchange Admin Center를 실행

Advanced

Continue to localhost (unsafe) 클릭

서비스 계정으로 sign in

접속 확인

Servers 메뉴에서 빌드 넘버 확인

다음 포스팅에서는 초기 설정 방법에 대해서 다루겠습니다.

2024.12.31 - [Exchange] - Exchange Server 2019. Deployment (2): 구성 (CU14, Nov24SUv2 / Windows Server 2022)

Windows Server 2025. Active Directory (AD) Domain Controller(DC) 구성

Pepuri — Sun, 15 Dec 2024 14:28:42 +0900

Windows Server 2025가 출시한 김에 예전에 포스팅했던 테스트환경 구성을 다시 작성해보려고 합니다.

그러면서 이전보다는 신경써서 Youtube 영상을 제작할 것입니다.

Windows Server 2016 이후부터 사실 Domain Controller 구성하는 방법이나 UI는 거의 동일합니다. 그래도 이제 시작하는 엔지니어 분들은 되도록 최신 버전에서 구성하고 싶고, 괜히 숫자가 다르면, 구성도 다를 거라 생각할 수 있기 때문에 동일한 내용이지만 2025로도 구성 글을 작성하였습니다.

이번에는 Domain Controller (DC) 구성에 대해서 다룰 것이며, 여력이 되면 Exchange 구성까지도 이어서 진행할 것입니다.

https://youtu.be/3zS2uBHtFvI

우선 VM 사양은 CPU: 4 Core, RAM: 4GB로 지정하였습니다. 예전에는 2GB로 충분했는데, 요새는 버거운 것 같습니다.

Windows Server 2025 설치 및 Sysprep은 이전 글이나 영상을 참조해주세요

Server Manager -> Local Server -> Computer Name 클릭

Change

Domain Controller라고 인지할 수 있는 이름으로 변경합니다. -> 재부팅이 진행됩니다.

Local Server -> Ethernet

네트워크 어댑터 -> 우클릭 -> 속성

IPv4 선택

환경에 맞게 IP를 입력합니다. DNS는 DC 자신의 IP를 바라봅니다.

Server Manager -> Dashboard -> Add roles and features

Active Directory Domain Services를 체크

Add Features

Install

Promote Domain Controller

Add a new forest -> Root domain name 입력 -> Next

참고로 Corp를 도메인 앞에 붙이는 이유는 MS Best Practice에 나와 있는 것을 참고 하였습니다.

개인적이 생각으로는 앞에 corp를 붙이는 이유는 다음과 같은 장점이 있습니다.

1. 브라우저 상에서 Root domain이 홈페이지인 경우도 있기 때문에 내부 외부 DNS를 분리할 수 있음

2. contoso.local 과 같이 local을 사용하면 공인인증서를 사용할 수 없음.

DSRM Password 생성 후 Next. Windows Server 2022까지는 Level이 2016이었는데, 이번에 Level이 2025로 업그레이드 되었습니다.

Install

DC 구성완료.

Close를 클릭하면, 잠시 뒤에 재부팅됩니다.

아래와 같이 Domain 계정으로 로그인을 진행.

Active Directory Domains and Trusts

Active Directory Domains and Trusts 우클릭 -> Properties

Active Directory Users and Computers (ADUC) 실행

도메인 -> 우클릭 -> New -> Organizational Unit (OU)

서비스 계정에 대한 OU를 생성합니다.

생성된 OU에서 우클릭 -> New -> User

아래와 같이 DC에서 사용할 Admin 계정을 생성. (Administrator는 가급적이면 보안 목적상 사용하지 않습니다.)

패스워드 입력 -> Next

Finish

생성된 계정을 우클릭 -> Properties

Member Of -> Add를 클릭하여 아래의 항목들을 검색하여 추가합니다.

Sign Out 이후에 동일하게 생성된 계정으로 로그인되는지 확인합니다.

Secondary DC 구축 작업을 진행합니다. 테스트 환경에서 필수는 아니지만 실제 환경에서는 최소 2개는 구축합니다.

이전과 마찬가지로 Computer Name을 변경합니다.

Network Adapter의 DNS를 Main DC를 바라보도록 설정합니다.

Server Manager -> Local Server -> WORKGROUP

Change

Domain 입력 -> OK

이전에 생성한 DC Service Account를 입력합니다.

Add roles and features

Main DC와 동일한 방식으로 Active Directory Domain Services Roles 설치 과정을 진행합니다.

이전과는 다르게 Add a domain controller to an existing domain을 선택하여 진행합니다.

DSRM Password 입력 -> Next

Install -> 설치가 완료되면, 재부팅이 진행됩니다.

Secondary DC는 Main DNS를 자기 자신을 바라보도록 변경합니다.

ADUC에서 DC 2대를 전부 학인 할 수 있습니다.

이것으로 포스팅을 마치겠습니다.

당분간은 과거에도 다루었지만, Youtube 제작을 위해서 최신 버전들을 기반으로 구성하는 글들을 작성하겠습니다.

Windows Server 2025. Domain Controller upgrade From 2022 to 2025

Pepuri — Sat, 16 Nov 2024 21:30:28 +0900

Windows Server 2025가 출시되었습니다.

새 OS가 출시된 김에 AD Domain Controller DC01, DC02를 Windows Server 2025로 Upgrade를 진행해 보겠습니다.

실제 환경에서는 많은 것을 고려해야겠지만, 테스트 환경이기 때문에 단순히 업그레이드 하는 과정만 다루었습니다.

테스트 환경

https://youtu.be/YcF0ztnJJ8A

순서는 다음과 같이 진행하였습니다.

1. DC02: Windows Server 2022 Demote

2. DC02: Windows Server 2025 Promote

3. Master를 DC02로 변경

4. DC01: Windows Server 2022 Demote

5. DC01: Windows Server 2025 Promote

6. Master를 DC01로 변경

Step 1. DC02제거

Add roles and features

Start the Remove Roles and Features Wizard

Active Directory Domain Services

Remove Features

Demote this domain controller

Proceed with removal -> Next

Password 입력 -> Next

Demote

DC가 제거된 것을 확인

재부팅 후 다시 역할 제거 진행

해당 머신을 WORKGROUP으로 전환

ADUC에서 DC02 제거

Yes

Step 2. Windows Server 2025에 DC 설치

AD join 진행

Server Manager -> Add roles and features

Active Directory Domain Services

Add Features

Install

Promote this server to a domain controller

Add a domain controller to an existing domain -> Next

Password 입력 -> Next

Install

완료되면 재부팅이 진행됩니다.

아래의 명령어를 입력하여 DC Master 역할을 DC02로 변경합니다.

Move-ADDirectoryServerOperationMasterRole -Identity DC02 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster

Netdom query fsmo

Step 3. DC01 제거

DNS Address를 DC02로 수정합니다.

Server Manager -> Add roles and features

Start the Remove Roles and Features Wizard

Active Directory Domain Services

Remove Features

Demote this domain controller

Proceed with removal -> Next

Password 입력 -> Next

Demote

재부팅후 다시 역할 제거 메뉴로 이동하여 ADDS 제거 과정 진행

Close -> 재부팅을 진행합니다.

Workgroup으로 변경 진행

ADUC에서 DC01 제거

Step 4. DC01 설치

새 VM에서 DC01 IP 설정 -> DNS는 DC02로 설정

Domain Join

Add Roles and features

Active Directory Domain Services -> Next

Promote this server to a domain controller

Password 입력 -> Next

Install

Close -> 재부팅이 진행됩니다.

DC01을 Main DNS, DC02를 Alternate DNS로 지정

아래의 명령어를 진행하여 Master를 DC01로 변경

Move-ADDirectoryServerOperationMasterRole -Identity DC01 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster

확인

Netdom query fsmo

Step 5. Raise Forest Functional Level

Active Directory Domains and Trusts

Active Directory Domains and Trusts 우클릭 -> Raise Forest Functional Level

Raise

아래의 명령어로 확인

Get-ADDomain |fl name, DomainMode
Get-ADForest |fl Name, ForestMode

Power Platform. QR Code 발급하여 참석자 등록 앱 만들기

Pepuri — Sun, 10 Nov 2024 22:49:15 +0900

이번에는 QR Code 발급 -> 방문자가 QR인증하는 앱을 Power Platform을 통해서 제작해보겠습니다.

제작 흐름은 다음과 같습니다.

1. Forms로 신청서 작성

2. Power Automate로 QR Code를 등록한 Email로 발급

3. Power Apps로 QR 을 인증

4. Power Automate로 Excel 파일에 출석여부 업데이트

Step 1. Forms로 신청서 작성

Forms -> 새 양식

다음과 같이 신청서 양식을 생성합니다.

응답 수집을 클릭합니다.

링크를 복사 한 뒤, 테스트 참석 신청 절차를 진행합니다.

제출

다음과 같이 생성된 것을 확인할 수 있습니다.

다음과 같이 표를 생성하여 참석자 명단 시트를 추가합니다.

#고유코드는 다른 QR과 중복생성을 막기 위해 임의의 값을 입력합니다.

뒤에서 QR Code 생성과정을 진행해보면, Power Automate에서 왜 해당 값이 필요한지 이해할 수 있을 것입니다.

#QRValue는 고유코드 + 이메일 주소입니다.

Step 2. QR 생성 및 발급

Power Automate -> 만들기

흐름 이름 입력 -> 새 응답이 제출되는 경우 선택 -> 만들기

양식 ID 지정 (이전에 생성된 Forms)

계정 연결이 안 되어 있다면, 추가합니다.

작업 추가

런타임: 표준 -> Forms 선택

응답 세부 정보 가져오기

양식 ID 지정 -> "/"를 입력하거나 아래의 표시된 버튼 클릭

응답 ID 선택

작업 추가

런타임: 기본 제공 -> Variable

변수 초기화

아래와 같이 입력 및 선택합니다.

작업 추가 -> 런타임: 기본 제공 -> HTTP

HTTP

URI는 다음과 같은 형태입니다.

https://api.qrserver.com/v1/create-qr-code/?size=150x150&data=고유코드 + Email주소

아래와 같이 우선 입력한 뒤, 아래의 메뉴를 클릭합니다.

Email 응답 결과를 선택

아래와 같이 완성합니다.

QR Code 생성원리를 간단하게 설명드리자면, api.qrserver.com 에 접속하여 생성받는 형식입니다.

아래의 URI 뒤에 고유의 정보 값을 입력하면 생성되는 원리입니다.

https://api.qrserver.com/v1/create-qr-code/?size=150x150&data=

예시

작업 추가 -> 런타임:기본 제공 -> Variable

변수 설정

QRCodeURL을 선택한 뒤, Value는 위와 동일한 방식으로 선택합니다.

작업 추가 -> 런타임:표준 -> Office 365 Outlook

메일 보내기

고급 모드로 전환

아래와 같이 내용을 입력한 뒤, 코드 보기를 클릭합니다.

<img src="[QRCodeURL변수]" alt="QR Code" />

가장 하단에 아래와 같은 형태로 이미지 코드를 추가합니다.

예시. 테스트 하면서 위치나 코드를 수정합니다.

하단의 고급 매개변수를 메뉴에서 BCC에 본인 메일 주소를 추가합니다. (정상 발송여부 체크용)

흐름을 저장 한 뒤, Forms 응답을 한번 더 진행합니다.

아래와 같이 메일이 발송됩니다.

Step 3. Power Apps로 QR Reader 생성

Power Apps -> 만들기 -> 빈 앱

빈 캔버스 앱 만들기

앱 이름 지정 -> 휴대폰 -> 만들기

데이터 -> 데이터 추가

Excel Online

연결

Onedrive -> Onedrive -> Forms Excel 파일 지정

이전에 생성한 시트의 표 선택

연결

삽입 -> 바코드 판독기

아래와 같이 변경하였습니다.

QR 인식이 잘 되는지 테스트 하기 위해서 세로 갤러리 추가

레이아웃 제목 및 부제목

첫번째 항목 전체(Gallery 개체)를 선택 -> Items 속성을 변경하거나 상단의 속성에 qrScanner.Barcodes 를 입력합니다.

-> 이 수식은 바코드 결과 값을 갤러리에 표시해줍니다.

두번째 Subtitle에는 다음과 같이 수식을 입력합니다.

If(
    !IsBlank(
        LookUp(
            표2,
            QRValue = First(qrScanner.Barcodes).Value
        )
    ),
    "OK",
    "Not Found"
)

-> 이 수식은 바코드 인식 결과가 Excel 상의 QRValue에 일치하는 행이 있으면 OK, 아니면 Not Found 결과를 표시합니다.

우측 상단의 게시를 클릭합니다.

Power Apps에서 게시된 앱을 실행합니다.

실행하면 아래와 같이 오류가 발생합니다. 아직 원인은 모르지만, 동작하는데 문제는 없었습니다.

QR Check시 아래와 같이 OK 처리되는 것을 확인할 수 있습니다.

Step 4. QR 인증시 Excel 파일에 참석 인원 업데이트

Power Automate

새 흐름 만들기

처음부터 만들기

입력 추가

텍스트

테이블에 있는 행 나열

아래와 같이 지정 -> Flow 이름 변경 -> 저장

바코드 판독기를 선택 -> 고급 -> OnScan

다음과 같이 입력하여 QR Scan시 생성한 흐름이 실행하고, 결과 값을 Flow에 연결할 수 있습니다.

PowerAppsQRFlow.Run(First(qrScanner.Barcodes).Value)

다시 생성한 흐름을 편집합니다.

조건 추가

QRCode와 QRValue가 일치하면 흐름이 실행되도록 구성합니다.

예인 경우 행 업데이트

아래와 같이 완성한 뒤, 저장합니다. Power Apps 게시

-> QRValue와 PowerApps에서 인식한 결과 값인 QR Code가 일치한 열에 O를 표시

QR인증시 다음과 같이 Excel 파일에 업데이트됩니다.

여기서 여러가지 디자인 요소나 텍스트를 수정하여 적절하게 활용합니다.

Windows Server 2025. Install & Sysprep

Pepuri — Sat, 9 Nov 2024 18:32:09 +0900

Windows Server 2025가 출시되었습니다.

저는 항상 새로운 OS가 출시하면 Hyper-V 환경에서 테스트하기 편하도록 Sysprep을 통해서 설치된 디스크 이미지를 제작합니다.

새로 VM을 생성할 때, 그 디스크 이미지 파일만 복사하면 바로 OS를 올릴 수 있기 때문에 매우 편리합니다.

이전에도 다룬 적이 있지만, Youtube 영상 리뉴얼 차원에서 한번 더 작성하였습니다.

https://youtu.be/snj74akjzCA

Windows Server 2025 & Hyper-V 기준으로 작성하였습니다.

Hyper-V -> New -> Virtual Machine

이름 지정 -> Default Location 지정 -> Next

Generation 2 확인 -> Next

(2025부터는 Generation 2가 기본값입니다.)

RAM 지정 -> Next

네트워크 어댑터 지정 -> Next

Disk 위치 확인 -> Next

설치 디스크 지정 -> Finish

생성된 VM 더블 클릭

Start

키를 입력하여 설치 과정을 진행합니다.

언어 선택 -> Next

동의 -> Next

제품키 입력 -> Next (저는 Hyper-V에서 활용하기 때문에 AVMA 키를 입력하였습니다.)

Install

설치 진행

자동으로 재부팅이 진행됩니다

설치완료되면 다음과 같이 화면이 나타납니다. 이 때, Shift + Ctrl + F3 을 동시에 눌러줍니다.

재부팅이 진행되고 다음과 같이 화면이 나타납니다. OOBE, Generalize, Shutdown 을 선택한 뒤, OK를 클릭합니다.

Sysprep이 진행되고, 완료되면 Shutdown 됩니다.

생성된 VHDX 디스크 이미지를 백업합니다. 이 디스크를 활용하여 OS 설치과정을 간소화 할 수 있습니다.

아래의 메뉴에서 디스크 이미지를 선택하여 생성할 수 있습니다.

Youtube 영어 채널 개설

Pepuri — Sun, 20 Oct 2024 20:00:49 +0900

올해에는 내 스스로에게 동기 부여할만한게 무엇이 있을까 고민하다가 Youtube 제작을 다시 해보기로 했습니다.

한국어 채널은 한계가 있어서 영어 채널을 메인으로 업로드 하고 있습니다.

AI를 이용하여 Voice 를 생성하기 때문에 이전보다 제작시간을 많이 줄일 수 있었습니다.

Pepuri (English) - YouTube

그리고 아시는 분들은 아시겠지만, Youtube 영상에서 명령어 같은 것들에 대해서 복사 붙여넣기가 필요할 수 있기 때문에 블로그도 별도로 만들었습니다.

https://pepuri.limcm.kr/

Pepuri Server world Eng Version

Pepuri Eng Version 입니다. I handle Microsoft-related products such as Microsoft 365 and Exchange Server.

pepuri.limcm.kr

확실히 한국어로 진행하는 것보다 조회수가 높았습니다. 이번달 목표가 최근 28일 조회수 1000, 시청시간 40시간이었는데, 조회수는 돌파하였고, 시청시간도 곧 달성할 것 같습니다.

Youtube로 수익을 내기 위해서는 구독자 1,000명 / 시청시간 4,000시간을 달성해야 합니다.

그래서 다들 영상에 구독, 좋아요, 댓글, 알림 부탁드립니다. 를 하는 이유를 깨달았습니다.

현재 누적 시청시간이 100시간입니다. 구독자도 시청 시간도 지금의 40배를 늘려야 수익화가 가능합니다.

이것으로 꼭 돈을 벌겠다. 라기 보다는 과연 Global에서 내가 제작한 컨텐츠가 과연 어디까지 갈 수 있을까 에서 출발했습니다.

그 중 시청시간 및 조회수가 높은 것이 Cross Tenant Synchronization과

Cross tenant Migration 입니다. (이 영상은 한참을 내려가야 나옵니다....)

요새 주력으로 진행하는 컨텐츠는 Copilot Studio입니다.

비주류이고 출시한지 얼마안된 제품이기 때문에 경쟁력 있지 않을까 생각합니다.

나중에 여유가 되면 한글 / 영문 으로 해서 Exchange 관련 컨텐츠도 제작할 예정입니다.

Copilot Studio. Power Platform 에서 Custom Connector 메뉴 찾기

Pepuri — Sat, 19 Oct 2024 19:02:13 +0900

Azure AI Studio에서 만든 무언가와 Copilot Studio를 연결하기 위해서 Custom Connector를 만들려고 했습니다.

그런데, 기술자료에서는 화면에서 설명하는 것처럼 Data -> Custom Connectors 메뉴로 이동하라고 나와 있지만, 찾을 수 없었습니다.

Create a custom connector from scratch | Microsoft Learn

과거의 많은 Youtube 영상에는 쉽게 볼 수 있지만, 현재는 그 메뉴가 없어졌다는 것을 깨달았습니다.

처음에는 라이선스가 프리미엄이 아니어서 그런가? 라고 생각했는데, 아니었습니다.

최근에 Youtube 영상을 기준으로 찾다보니 찾을 수 있었습니다.

https://www.youtube.com/watch?v=X5654jxAatw

Power Automate -> More -> Discover all

Data항목에서 Custom connectors 를 클릭하거나 Pin을 클릭합니다.

화면과 같이 Custom connectors 메뉴를 확인할 수 있습니다.

Copilot Studio. Connecting to Power Apps and Power Automate using PowerShell

Pepuri — Sat, 12 Oct 2024 17:30:12 +0900

M365에서 Trouble Shooting을 한다면, 관리자가 Powershell을 통해서 M365를 TS하는 것은 익숙한 일입니다.

다만, 이걸 굳이 Copilot Studio에서 해야 하나 싶기는 하지만, 종종 Powershell로 해야 하는 작업들이 있어서 작성하게 되었습니다.

아래의 기술자료를 참고하여 진행하였습니다.

PowerShell support for Power Apps and Power Automate - Power Platform | Microsoft Learn

Windows 11 기준으로 진행하였습니다.

시작 버튼 -> 우클릭 -> Terminal (Admin)

다음 명령어를 진행합니다.

Install-Module -Name Microsoft.PowerApps.Administration.PowerShell
Install-Module -Name Microsoft.PowerApps.PowerShell -AllowClobber
Set-ExecutionPolicy -ExecutionPolicy Unrestricted

아래와 같이 메시지가 나타난 다면 Y나 A를 입력합니다.

Power Apps와 Power Automate 의 영역은 다르기 때문에 각각 로그인이 필요합니다.

Exchange Online 처럼 별도의 연결 명령어를 입력할 필요 없이, 실제 사용할 명령어를 입력하면 자격 증명을 입력하도록 되어 있습니다.

아래의 명령어를 입력하면서 Power Apps에 접속합니다.

Get-AdminPowerAppEnvironment

아래의 명령어를 입력하면서 Power Automate에 연결합니다.

Get-AdminFlow

향후에 Copilot Studio와 관련하여 Powershell 연결이 필요할 때, 접속하여 활용할 수 있습니다.

Copilot Studio. 언어 변경

Pepuri — Thu, 3 Oct 2024 06:24:03 +0900

사용자 언어가 영어로 설정되어 있어도 Power Platform Admin Center와 Copilot Studio 페이지는 한글로 표시될 수 있습니다.

이것을 영문으로 바꾸려 해도 MS 공식 자료는 찾지 못했습니다.

아래의 게시글 댓글에서 브라우저의 언어에 영향 받는 다는 것을 알 수 있었습니다.

Change language settings in Power platform admin center - Microsoft Community Hub

Edge 브라우저 기준으로 설정으로 이동

언어에서 설정할 언어를 추가 -> 세부 메뉴 버튼 클릭

이 언어로 Microsoft Edge 표시

다시 시작

표시 언어가 변경됩니다.

Entra. Verified ID (2). Enable & Test

Pepuri — Fri, 20 Sep 2024 18:08:35 +0900

지난 포스팅

2024.09.20 - [Microsoft 365/Entra] - Entra. Verified ID (1). Introduction

이번 포스팅에서는 MS에서 기본 제공하는 Verified ID 활성화 및 테스트를 진행해보겠습니다.

Entra 관리 센터 - Verified ID -> Overview -> Get Started

Provisioning

1. Get your new credential -> Try it now

Get my Verified ID

QR Code가 생성됩니다.

모바일에서 Authenticator 실행

Verified ID -> Scan a QR code

화면의 QR코드를 Scan 합니다.

Add

추가 완료

발급된 ID를 클릭하면 기록을 확인할 수 있습니다.

2. Use your new credential -> Try it now를 클릭하면 Verified ID를 테스트 할 수 있는 페이지로 이동됩니다.

Access discounts

계정 정보 대신 DID를 이용하여 로그인을 할 수 있습니다. Verify my Employee Credential

QR Code

카메라 QR을 인식시키면 URL을 통해서 Authenticator가 실행됩니다.

Share를 클릭하여 ID 정보를 전달합니다.

확인 완료

Activity에서 내 ID가 어디에 사용되었는지 확인할 수 있습니다.

테스트 페이지는 직원할인가가 적용되는 시나리오로 아래와 같이 확인할 수 있습니다.

이러한 방식으로 Verified ID를 활용할 수 있다는 예시를 보여줬습니다.

구체적으로 활용하려면 3rd Party System과 연계하거나 가상의 회사 Infra를 만들어서 구현해봐야 할 것 같습니다.

Entra. Verified ID (1). Introduction

Pepuri — Fri, 20 Sep 2024 17:58:24 +0900

Entra는 Azure AD와 Windows Server AD의 혼동을 줄이기 위하여, Azure AD를 Entra ID로 변경하면서 Entra 제품군의 출발을 알렸습니다.

Microsoft는 제품의 다중 클라우드, 다중 플랫폼 기능을 전달하고 Windows Server Active Directory와의 혼동을 완화하며 Microsoft Entra 제품군을 통합하기 위해 Azure AD(Azure Active Directory)의 이름을 Microsoft Entra ID로 변경했습니다.

그도 그럴만한 것이 사람들이 알고 있는 AD는 사실 Active Directory Domain Service로 AD DS입니다. Azure AD는 극단적으로 설명하면 Identity만 관리하며, Azure AD에 Join된 장치들의 정책을 관리하는 것은 Intune의 Configuration Profile입니다. 즉, AD의 클라우드 버전은 Azure AD + Intune입니다. 오랜 기간 AD개념이 자리 잡혀 있는 분들에게는 설명이 매우 어려웠습니다.

Entra로 브랜드 네임을 변경하면서 포괄적인 Identity 및 Access 관리 플랫폼으로 자리잡기 시작했습니다.

Entra 관리센터에 접속하면, Azure AD라고 불리던 시절보다 다양한 기능들을 제공하는 것을 알 수 있습니다.

그 중에서 Verified ID에 대해서 알아보도록 하겠습니다. 아래의 기술자료로 출발해 보겠습니다.

Introduction to Microsoft Entra Verified ID - Microsoft Entra Verified ID | Microsoft Learn

우선 Verified ID의 등장 배경은 다음과 같습니다.

오늘날의 우리의 디지털 및 물리적 생활은 우리가 사용하는 앱, 서비스 및 장치와 점점 더 얽혀지고 있습니다. 이 디지털 혁명은 가능성의 세계를 열어, 우리가 이전에는 상상할 수 없었던 방법으로 수많은 회사 및 개인과 연결할 수 있도록 합니다.

이렇게 증가된 연결성으로 ID 도용 및 데이터 침해의 위험이 더 커지게 됩니다. 이러한 침해는 우리의 개인적, 직업적 삶에 엄청난 영향을 미칠 수 있습니다. 그러나 희망이 있습니다. Microsoft는 다양한 커뮤니티와 협력하여 개인이 자신의 디지털 ID를 제어하도록 하는 탈중앙화 ID 솔루션을 만들고 중앙 집중식 기관 또는 중개자 없이 ID 데이터를 관리하는 안전하고 사적인 방법을 제공합니다.

-> 여기서 핵심은 탈 중앙화 ID 솔루션(Decentralized Identity solution) 입니다. 사실 그 이외의 개념은 조금 어려워서… 지금 제 수준에서 그 것을 더 풀어서 설명하기는 어렵습니다. 이런 것을 보면… Identity만 제대로 Deep Dive를 했었다면, 먹고 사는데 지장이 없었을 것 같습니다.

이 것을 실용적으로 어떻게 사용할 수 있는지 테스트를 하고, 결과론적으로 이해해야 할 것 같습니다.

개방형 표준 주도 (Lead with open standards)

MS는 다음과 같은 표준이 구현되어 있다고 합니다.

W3C 탈중앙화 식별자

W3C 확인 가능한 자격 증명

DIF Sidetree

DIF Well Known DID Configuration

DIF DID-SIOP

DIF Presentation Exchange

-> 이 내용을 보면 단순히 M365에서 사용하는 것이 아니라 SSO와 같거나 혹은 다른 개념으로 다른 시스템과 연동한다는 의미로 해석됩니다.

DID(탈중앙화 ID)란?

신원 정보의 소유와 관리 권한을 중앙 기관이나 기업이 아닌 개인이 직접 통제할 수 있도록 하는 신원 관리 방식입니다.

중앙 서버나 기관에 의존하지 않고, 분산된 네트워크를 통해 신원 정보의 무결성과 보안을 보장합니다. 블록체인과 같은 분산 원장 기술이 주로 사용되며, 개인이 자신의 신원 정보에 대한 완전한 통제권을 가지는 것을 목표로 합니다.

그렇다면 MS에서 제공하는 Verified ID는 무엇일까? 라고 했을 때, 발급자(Issuer), 검증자(Verifier), 중개자(Role Modeler)의 역할을 한다. 라고 이해하였습니다.

그림 상의 각 항목이 설명하는 내용은 다음과 같습니다.

1. W3C DID(탈중앙화 식별자)번호

- 고유의 ID

2. Trust System

- DID 문서를 확인할 수 있도록 검증하고 인증하는 역할을 합니다.

3. MS Authenticate App

- 디지털 지갑 역할. 사용자가 신분증을 넣고 다니는 지갑이라고 생각하면 될 것 같습니다.

4. Microsoft Resolver

- did:web메서드를 사용하여 DID를 조회하고 확인하고 DDO(DID 문서 개체)를 반환하는 API

5. Microsoft Entra Verified ID API

- Azure의 발급 및 확인 서비스와 did:web 메서드로 서명된 W3C 확인 가능한 자격 증명용 REST API

이 흐름을 자세히 다루기 위해서는 구체적인 샘플환경을 구축 해야 이해를 할 수 있을 것 같습니다.

샘플을 구축하고 포스팅을 하고 어느정도 이해가 되면 이 포스팅을 다시 업데이트 하겠습니다.

Plan 2024를 추석 시점에 돌아보며..

Pepuri — Sun, 15 Sep 2024 22:31:33 +0900

작년 말에 2024년 계획에 대한 글을 썼습니다.

2023.12.31 - [기타/자기 개발] - Review 2023 & Plan 2024

그리고 2024년의 3/4을 지나가고 있습니다. 늘 그래왔지만, 시간이 참 빨리 지나갔습니다.

Purview와 Defender를 중점적으로 다루려고 하였으나,

M365 Copilot 제품을 연구하다 보니 다른 것을 할 여력이 없었습니다.

그리고 개인적으로 여러가지 일들이 있었고, 그것들을 잘 추스르는 시간도 필요했습니다.

돌이켜보면, 제가 이 일을 하는데 있어서 큰 분기점이 몇 개의 구간이 있었습니다. 올해도 큰 분기점이라고 생각합니다.

2015년 - 블로그를 하면서 서버제품군 및 Office 365를 시작

2019년 - 직장을 옮기면서 필드를 돌아다니면서 프로젝트를 시작

2024년 - 신변의 변화. 유튜브 영문 채널 개설. Copilot 시작

Microsoft 제품군을 한국어 권에서 시청하는 인원자체가 많지 않습니다. 그래서 어느 순간 저도 동기부여나 흥미를 잃어서 더 이상 제작하지 않았습니다.

그러다 최근 AI가 많이 발전하면서 목소리를 AI 더빙으로 쉽게 편집할 수 있게 되었습니다.

이전에는 내가 직접 녹음을 했습니다. 그러다보니 틀리면 다시 녹화를 해야하는데.. 그 작업이 쉽지 않습니다. 서버 제품군들 특성상 롤백이란 개념은 없습니다. 처음부터 다시 구축해야 하는 장면들도 많았습니다.

그런데 더빙이 가능하면, 설정 장면만 녹화하고 나중에 입히면 되는 구조라 매우 편리해 졌습니다.

그러다가 언어 장벽도 줄어들어서 영어 보이스가 들어가는 영상을 제작하기 시작하였고, 기존 한국어 더빙채널과는 구분하여 만들었습니다.

Pepuri for Microsoft 365 (EN)

https://www.youtube.com/@PepuriforMicrosoft365En

Pepuri for Microsoft 365 (EN)

This is a channel that mainly uploads related to Microsoft 365.

www.youtube.com

확실히 영어로 제작하였을 경우에는 대상의 범위가 넓다 보니 시청시간 및 조회수 늘어나는 속도가 한국어 채널보다 더빠르게 증가하였습니다.

한국어 채널

영어 채널

물론 수익 창출은 머나먼 얘기입니다. 하지만 기존보다는 동기부여가 되었습니다.

엔지니어일을 하다 보면, 이런 질문을 한 번씩 하게 됩니다.

"우리 나라만 이런가?"

그리고 내가 제작하는 컨텐츠가 해외에도 먹힐까? 라는 생각도 합니다.

해외를 타겟으로 하는 Youtube 영상 제작은 또 다른 영감을 주기 시작했습니다.

트랜드 분석도 되고, 저 스스로도 다양한 주제를 제작하도록 동기부여도 됩니다.

Cross Tenant Sync는 사실 우리나라에서는 크게 관심 없는 주제 중 하나입니다.

Cross tenant Sync 한국어

그런데 영어로 제작된 영상은 조회수도 시청시간도 꾸준히 증가하는 추세입니다.

Cross tenant Sync 영어

같은 맥락으로 Entra 제품군 관련 조회수가 높습니다. 국내에서 특히 GSA제품은 관심 적은 주제입니다.

Entra 제품이 국내에서는 관심이 적지만, 해외에서 관심이 있기 때문에 제가 공부하는데 동기부여가 많이 됩니다. 크로스 테넌트 마이그레이션도 조회수가 높은 것을 봐서는 Exchange와 관련된 개념 설명도 향후 제작할 계획입니다.

많지는 않지만, 다른 국가에서 댓글로 질문을 남기는 경우도 있는데, 이러한 것들이 제 시야를 넓혀줍니다.

올해 남은 기간에는 Copilot, Copilot Studio, 그리고 다양한 주제의 글과 영상을 제작할 예정입니다.

그리고 영어의 경우 필리핀 강사와의 회화는 꾸준히 하고 있지만, 이외의 추가 스터디는 하고 있지 않았습니다.

시간적인 부분도 있지만, 심리적인 여유를 만들어 보려고 합니다. 그러면 자연스럽게 더 할 수 있지 않을까 싶습니다.

2025년 2월이 되면 딱 블로그를 한지 10년을 채우게 됩니다. 10년을 향한 여정을 의미 있게 채워보도록 하겠습니다.

제가 제작한 컨텐츠 들로 엔지니어들에게 조금이나마 도움이 되기를 바라는 마음으로 달리겠습니다.

Copilot Studio. 사용자에 대한 옵션으로 선택지 만들기

Pepuri — Sun, 18 Aug 2024 16:38:38 +0900

이전 포스팅

2024.08.14 - [Copilot/Copilot Studio] - Copilot Studio. Power Automate를 이용한 특정 메시지 입력시 Teams로 메시지 전송 설정

이번에는 옵션이 나타나서 사용자가 클릭하여 진행할 수 있는 형태의 옵션을 만들어보겠습니다.

토픽 -> 토픽 추가 -> Copilot을 사용하여 설명에서 생성

다음과 같이 입력하면, 제작자 의도에 맞게 토픽이 생성됩니다.

다음과 같이 생성됩니다. 여기서 사용자에 대한 옵션을 수정합니다.

사용자에 대한 옵션을 수정 -> 조건 추가

생성된 조건에서 변수 선택 -> Choice 선택 (변수는 생성될 때마다 이름이 다르게 표시될 수 있습니다.)

첫번째 조건은 Escalation을 지정. 그리고 동일한 방식으로 조건을 아래와 같이 전부 추가합니다.

응답에 따른 동작을 지정할 수 있습니다. (이전 포스팅에서 생성한 Teams에 메시지 보내는 흐름을 선택하였습니다.)

아래와 같이 계속 확장해 나갈 수 있습니다.

저장 -> 게시

질문을 입력하면 옵션이 표시됩니다.

Microsoft Defender for Office 365 (MDO). (2) Safe attachments

Pepuri — Sun, 18 Aug 2024 10:24:11 +0900

지난 포스팅에 이어서 이번에는 안전한 첨부파일 (Safe attachments)에 대해서 다루겠습니다.

안전한 링크와 마찬가지로 Exchange 관점에서 작성을 진행하겠습니다.

Microsoft Defender for Office 365 (MDO). (1) Safe Links

Pepuri — Thu, 15 Aug 2024 16:40:05 +0900

MDO의 안전한 링크 (Safe link)에 대해서 다뤄보겠습니다.

일부 정책은 M365 Apps나 Teams에 적용되지만, 주로 Exchange 관점에서 진행하였습니다.

아래의 기술자료를 참고하여 작성하였습니다.

Office 365용 Microsoft Defender에 대한 안전한 링크 - Microsoft Defender for Office 365 | Microsoft Learn

안전한 링크(Safe links)란?

Office 365용 Microsoft Defender를 사용하는 조직에서 안전한 링크 검사는 피싱 및 기타 공격에 사용되는 악의적인 링크로부터 조직을 보호합니다. 특히 안전한 링크는 메일 흐름 중에 인바운드 전자 메일 메시지의 URL 검사 및 다시 작성, 전자 메일 메시지, Teams 및 지원되는 Office 365 앱의 URL 및 링크에 대한 클릭 시간 확인을 제공합니다. 안전한 링크 검사는 정기적인 스팸 방지 및 맬웨어 방지 보호 외에도 발생합니다.

아래의 흐름을 보면, EOP에서 먼저 검사한 뒤, 피싱 메일이 스팸으로 필터링되지 않으면, 다음으로는 MDO 영역에서 검사합니다.

Anti-Phishing 검사의 영역은 MDO에서 진행됩니다. 안전한 링크(Safe Links) 도 피싱 방지 기능중 하나로 볼 수 있습니다.

그리고 안전한 링크는 라이선스가 부여되면 테넌트 전체에 적용됩니다.

참고
기본 안전한 링크 정책은 없지만 기본 제공 보호 사전 설정 보안 정책은 Office 365용 Defender 라이선스가 하나 이상 있는 고객(표준 또는 엄격한 사전 설정된 보안 정책 또는 사용자 지정 안전 링크 정책에 정의되지 않은 사용자)의 모든 수신자에게 전자 메일 메시지, Microsoft Teams 및 지원되는 Office 앱의 안전한 링크 보호를 제공합니다.

즉, 이 기능은 조건부 액세스와 유사하게 라이선스 한 개만 구입해도 되는 테넌트 전체에 적용됩니다.

그렇다고 1개만 구매해도 된다. 이러한 것은 아닙니다. 기본적으로 MS의 라이선스는 사용자 베이스의 CAL 라이선스 개념이 존재하기 때문에, 사용자 숫자에 맞게 구매하지 않으면 라이선스 적법성에 맞지 않을 수 있습니다.

기본 정책 (Built-in protection)

Microsoft Defender (https://security.microsoft.com) -> 전자 메일 및 공동 작업 -> 정책 및 규칙 -> 위협 정책

안전한 링크

다음과 같이 기본정책을 확인할 수 있습니다.

아래의 설명과 같이 안전한 링크는 MDO 라이선스가 테넌트에 구매되면 모든 사용자에게 적용되는 것이 기본 값입니다.

(기본 제공 보호에서 제외는 다른 포스팅에서 별도로 다루겠습니다.)

기본 정책은 수정할 수 없으며, 어떻게 적용되고 있는지 UI 상에서 확인할 수 없습니다.

그래서 Exchange Online Powershell에 접속하여 확인해보겠습니다.

아래의 명령어로 정책을 목록을 확인합니다.

Get-SafelinksPolicy |fl identity

아래의 명령어로 CSV 내보내기를 진행합니다.

Get-SafeLinksPolicy |Export-Csv -Path C:\csv\safelinkspolicy.csv -Encoding UTF8 -NoTypeInformation

몇가지 의미 없는 속성 값들을 제거 한 뒤, 정리하면 다음과 같이 확인할 수 있습니다.

대부분은 정책 이름과 설정 값을 보면 쉽게 이해할 수 있습니다.

기본 정책에서 EnableForInternalSenders는 False인 것을 알 수 있습니다.

만약 Rewrite 정책까지 사용한다면, 내외부는 아래와 같이 차이가 발생할 것입니다.

외부

내부

만약 내부의 계정이 해킹되어서 사내 직원들에게 피싱 메일을 보낼 가능성이 있다고 판단된다면, 별도의 정책을 생성해야 합니다.

MS 권장 설정 확인

아래의 기술자료에서 MS에서 제시하는 설정 값에 대해서 확인할 수 있습니다.

Office 365용 EOP 및 Defender 보안 설정에 대한 Microsoft 권장 사항 - Microsoft Defender for Office 365 | Microsoft Learn

저는 Powershell 기준으로 다음과 같이 정리하였습니다.

엄격 기준 안전한 링크 정책 만들기

만들기

이름 지정 -> 다음

대상 지정

아래와 같이 적용

제출

다음과 적용된 것을 확인할 수 있습니다.

보고서 확인

보고서

작업 필터를 허용됨까지 포함하면 아래와 같이 기록을 확인할 수 있습니다.

안전한 첨부 파일 검사가 진행된 것을 확인할 수 있습니다.

Copilot Studio. Power Automate를 이용한 특정 메시지 입력시 Teams로 메시지 전송 설정

Pepuri — Wed, 14 Aug 2024 23:40:41 +0900

이전 포스팅

2024.08.13 - [Copilot/Copilot Studio] - Copilot Studio. Entra ID와 SSO 설정

이번에는 챗봇에서 특정 메시지를 입력하면 담당자에게 팀즈 알림으로 전달하는 흐름을 만들어 보겠습니다.

응용하면 메일로 전송과 같이 챗봇에서 자동화 흐름을 만들 수 있을 것입니다.

기존에 만든 Copilot에서 토픽에 보면 기본 값으로 특정 조건이 맞으면 동작하는 설정들이 있습니다.

여기서 Escalate 를 진행하면 담당자에게 Team 알림을 전달하는 흐름을 만들겠습니다. Escalate 를 클릭합니다.

추가 버튼 클릭

작업 호출 -> 흐름 만들기

완료

새 단계

Teams 검색 -> 채팅 또는 채널에서 메시지 게시

아래와 같이 설정. Recipient는 Teams에서 알림을 전달 받을 계정 지

편집 화면이 다음과 같이 표시될 수도 있습니다. -> 저장 -> 뒤로

편집을 클릭하여 흐름 이름을 변경합니다.

편집

게시

게시된 내용이 반영되면, Copilot studio에서 다시 토픽을 편집하면 아래와 같이 추가된 흐름을 확인할 수 있습니다.

아래와 같이 수정 -> 저장 -> 게시

편집

문구

문구 추가

저장 -> 게시

Escalate를 입력하면 권한이 필요하다는 메시지가 나타납니다. -> Connect 클릭

Connect

Submit

Status 확인

Escalate 입력시 아래와 같이 설정한 것처럼 메시지 확인

Teams 상에서 메시지가 전달됩니다.

다만 권한 연결이 계정이나 플랫폼이 변경되면 다시 연결설정이 필요한 것으로 보이며, 이 부분에 대한 보완이 필요할 것 같습니다.

다음 포스팅에서는 채팅창에 사용자가 선택할 수 있는 옵션을 만드는 방법에 대해서 다루겠습니다.

다음 포스팅

2024.08.18 - [Copilot/Copilot Studio] - Copilot Studio. 사용자에 대한 옵션으로 선택지 만들기

Copilot Studio. Entra ID와 SSO 설정

Pepuri — Tue, 13 Aug 2024 23:54:02 +0900

그리고 지난 포스팅에서는 해당 사이트에 신규 Copilot을 게시하였습니다.

2024.08.13 - [Copilot/Copilot Studio] - Copilot Studio. IIS 기반 사이트에 게시하기

이번에는 인증 옵션을 수동으로 인증 -> Azure Active Directory v2로 설정하여 SSO를 구성해보겠습니다.

이전에 Graph API를 테스트하면서 이미 Entra ID와 SSO를 구성한적이 있습니다.

기존에 작성한 내용에서 아래의 기술자료를 참고하여 진행하였습니다.

Configure single sign-on with Microsoft Entra ID - Microsoft Copilot Studio | Microsoft Learn

기존 SSO를 위해 등록된 앱으로 이동한 뒤, 아래와 같이 리디렉션 URI를 등록합니다.

아래와 같이 권한 부여가 체크되어 있는지 확인합니다.

Graph에서 아래의 3개의 권한을 추가합니다.

인증 없음 -> 수동으로 인증으로 변경하고, App 정보 및 범위를 입력합니다. -> 다시 게시합니다.

범위는 profile openid

아래와 같이 로그인이 필요하다는 메시지가 나타납니다.

만약 범위 값이 입력 안되면, 아래와 같이 오류가 발생합니다.

(Scope에 권한 문제가 있다고 발생)

정상적으로 설정되었다면, 로그인 클릭시 확인 코드를 부여 받습니다. -> Copy

채팅창에 Code를 입력하면 정상적으로 인증이 완료됩니다.

다음에는 채팅창에 특정 메시지를 입력하였을 때, Teams로 메시지 전송하는 방법에 대해서 다루겠습니다.

다음 포스팅

2024.08.14 - [Copilot/Copilot Studio] - Copilot Studio. Power Automate를 이용한 특정 메시지 입력시 Teams로 메시지 전송 설정

Copilot Studio. IIS 기반 사이트에 게시하기

Pepuri — Tue, 13 Aug 2024 21:55:20 +0900

지난 포스팅에서는 특정사이트를 크롤링하여 답변하는 신규 Copilot (챗봇)을 생성해 보았습니다.

2024.08.13 - [Copilot/Copilot Studio] - Copilot Studio. 신규 Copilot 생성

지난 포스팅에서는 팀즈에 게시하였다면, 이번에는 IIS 사이트에 게시해 보겠습니다.

우선 Teams 인증 환경과 분리하기 위해서 Power Platform 관리센터에서 환경을 별도로 추가합니다. 저는 평가판으로 생성하였습니다.

Copilot Studio 페이지에서 우측 상단의 환경을 클릭하고, 생성한 환경으로 변경합니다.

신규 Copilot 생성과정은 지난 포스팅과 동일하게 진행합니다.

채널 -> 인증 설정으로 이동합니다.

인증

우선 인증 없음으로 변경한 뒤, 저장을 클릭합니다.

게시

사용자 지정 웹사이트

저는 Visual Studio 기준으로 진행하였으며, Index.cshtml 파일에 아래의 내용을 추가하였습니다.

<div style="margin-top: 20px;">
    <iframe src="제공된URL"
            frameborder="0"
            style="width: 100%; height: 100%;">
    </iframe>
</div>

사이즈가 조금 마음에 안들어서 height를 수정하였습니다.

500px로 수정

챗봇에 맞게 적절하게 수정된 것을 확인할 수 있습니다.

다음에는 Entra ID와 SSO 구성하는 방법에 대해서 다루겠습니다.

다음 포스팅

2024.08.13 - [Copilot/Copilot Studio] - Copilot Studio. Entra ID와 SSO 설정

Copilot Studio. 신규 Copilot 생성

Pepuri — Tue, 13 Aug 2024 21:18:29 +0900

이번 포스팅에서는 Copilot Studio에서 "신규 Copilot"을 만들어 보겠습니다.

저는 여기서 Microsoft Learn 사이트를 참조하여 답변을 주는 AI 기반의 챗봇 형태로 제작해보겠습니다.

그리고 팀즈에 게시하는 형태로 진행하겠습니다.

아래의 자료를 참조하여 작성하였습니다.

Quickstart: Create and deploy a copilot - Microsoft Copilot Studio | Microsoft Learn

만들기 - 신규 Copilot

내용 입력 -> 참조 자료 추가

공개 웹 사이트

URL을 입력하여 사이트를 추가합니다.

만들기

우측의 Copilot 테스트 채팅창에서 질문을 입력하여 답변이 올바르게 진행되는지 확인합니다.

상단의 채널 -> Microsoft Teams

Teams 켜기

게시

사용자 배포 단계가 아닌 테스트 목적이라면 아래와 같이 진행합니다. (앱형태이기 때문에 Teams 관리센터에서도 배포 관리를 할 수 있습니다.)

채널 -> Microsoft Teams

Copilot 열기

추가

특정 사이트를 참조하여 답변을 하기 때문에 정확도를 높일 수 있습니다.

다음에는 IIS 기반 사이트에 생성한 Copilot 챗봇을 게시 하는 방법에 대해서 다루겠습니다.

다음 포스팅

2024.08.13 - [Copilot/Copilot Studio] - Copilot Studio. IIS 기반 사이트에 게시하기

Microsoft Entra ID. Set up tenant restrictions v2 by GSA

Pepuri — Sun, 7 Jul 2024 15:31:28 +0900

지난 포스팅

2024.07.06 - [Microsoft 365] - Microsoft Entra ID. Set up tenant restrictions v2 by GPO

지난 포스팅에 이어서 이번에는 GSA를 이용하여 Tenant 제한 설정을 진행해 보겠습니다.

Step1은 지난 포스팅과 과정이 동일합니다.

Client PC는 사전에 장치 등록 과정을 완료하였습니다.

Youtube (Korean)

https://youtu.be/dgeCq8d0kvo

Step 1: Configure default tenant restrictions v2

Entra Admin Center > Cross-tenant access settings > cross-tenant access settings > Default settings

Edit tenant restrictions defaults

Create Policy

Policy ID가 생성되는 것을 확인합니다.

Step 2: Configure GSA

Global Secure Access -> Activate를 클릭하여 활성화 합니다.

Connect -> Traffic forwarding -> 각각의 프로필을 활성화합니다.

사용자 및 그룹할당을 진행합니다.

Assign to all users -> Yes (전체 할당)

Secure -> Security profiles -> Create profile

프로필 이름 입력

Link policy -> Existing policy

기본 정책 연결 -> 프로필 생성과정 진행

Baseline profile

Enabled 상태로 변경

Step 3: GSA Client 설치

Connect -> Client download

Download client (실제 사용자에게 배포할 때에는 Intune을 활용할 수 있습니다.)

GSA Client 설치과정을 진행합니다.

아래와 같이 연결 상태를 확인합니다.

Chrome에서 다른 테넌트로 로그인하면 아래와 같이 차단되는 것을 확인할 수 있습니다.

프리뷰 버전의 아쉬운 것은 클라이언트에 Pause 버튼이 있다는 것입니다.

실제 정식 출시가 되면, MDE처럼 Windows에 내장된 서비스에 Built-in 될 것으로 예상됩니다.

Microsoft Entra ID. Set up tenant restrictions v2 by GPO

Pepuri — Sat, 6 Jul 2024 16:32:51 +0900

이번에는 Tenant 제한설정에 대해서 다루겠습니다.

조건부 액세스의 경우 회사의 계정을 개인 장치에서 접속하지 못하게 하는 것이 주 목적입니다.

그런데, 조건부 액세스는 다른 회사의 계정을 회사 장치에 접속하는 것을 막을 수 없습니다.

물론 회사 장치에서 Naver 메일도 접속 가능하고, 구글 드라이브도 접근 가능하다면, 사실 그 회사는 데이터 유출에 대해서는 민감하지 않으므로 이 포스팅은 무시하셔도 좋을 것입니다.

M365를 사용하려면 office.com 등 MS 관련 URL을 오픈해야 합니다. 이 때, 다른 회사나 개인 계정 (outlook.com 등)으로 접속하는 것을 막는 개념이 Tenant Restriction (테넌트 제한)입니다.

Youtube 영상 (한글)

https://youtu.be/4Kr--8pq2rA

Windows Server. Remote Desktop Service 인증서 교체

Pepuri — Sat, 15 Jun 2024 05:01:23 +0900

이번에 RDS 서버의 인증서가 만료되었습니다. 아래와 같이 갱신작업을 진행하였습니다.

한국어버전

https://www.youtube.com/watch?v=A_uM3wklxi8

영문버전

https://www.youtube.com/watch?v=FH1Duvp1cg0

대시보드에서 Remote Desktop Services 를 클릭합니다.

Overview -> TASKS -> Edit Deployment Properties

Certificates -> 만료된 인증서 선택 -> Select existing certificate...

Choose a different certificate -> Browse

새로 발급받은 인증서 선택 -> Open

Apply

State OK 확인 -> 나머지 Role도 동일하게 진행합니다.

전부 진행 후 OK

RDWEB 접속하여 갱신 확인

Microsoft Graph & IIS. (6) Email 탭을 추가하여 Mailfolders 내용 표시하기

Pepuri — Sat, 8 Jun 2024 18:47:07 +0900

이번에는 Mailfolders 내용을 표시하는 Email 탭을 추가해보겠습니다.

Korean

https://youtu.be/dR7AMJXZHU4

한글 버전

English

https://youtu.be/YeCf5GNVzf0

영문 버전

기존에는 아래와 같이 디자인되어있습니다. Home과 Privacy 사이에 Email을 추가하겠습니다.

아래와 같이 추가합니다.

<li class="nav-item">
    <a class="nav-link text-dark" asp-area="" asp-controller="Home" asp-action="Mailfolders">Email</a>
</li>

추가됨 확인

클릭시 아래와 같이 표시됩니다.

Copilot. File Server를 Graph Connector로 연결하여 활용하기

Pepuri — Fri, 7 Jun 2024 15:19:18 +0900

Microsoft 365 Copilot을 활용하는 방법은 Microsoft 365에 저장된 데이터를 이용하거나 Plugin 및 Graph connector를 통해서 데이터를 연결하는 것입니다.

여러가지 이유에서 파일 서버의 내용들을 전부 M365로 마이그레이션하지 못하는 경우가 있습니다.

이러한 경우에는 대안으로 Graph Connector를 연결하여 Copilot을 활용할 수 있습니다.

Step 1. 앱 등록

Entra-> 애플리케이션 -> 앱 등록

아래와 같이 설정 -> 등록

인증서 및 암호 -> 새 클라이언트 암호

이름 지정 -> 추가

값을 복사하여 백업합니다. -> Agent에서 Password로 입력합니다.

API 사용 권한 -> 권한 추가

Microsoft Graph

애플리케이션 사용 권한

ExternalConnection.ReadWrite.OwnedBy, ExternalItem.ReadWrite.OwnedBy 권한 추가

Directory.Read.All 권한 추가

관리자 동의 허용

Step 2. Graph Connector 설치

저는 AD에 Join된 Windows File Server에서 테스트를 진행하였습니다.

제 블로그 글들을 HTML로 변환하여 인덱싱할 수 있도록 파일서버에 저장하였습니다.

아래의 자료를 참고하여 진행하였습니다.

기술자료

Microsoft Graph connector agent | Microsoft Learn

.NET Desktop Runtime 7.0.2 설치

https://dotnet.microsoft.com/ko-kr/download/dotnet/thank-you/runtime-desktop-7.0.20-windows-x64-installer

Graph Connector Agent 설치

Download Microsoft Graph Connector Agent from Official Microsoft Download Center

그래프 커넥터 에이전트 구성

AppID, Password 입력

App ID은 아래의 위치에서 확인할 수 있습니다.

Health Check -> Close

Step 3. Microsoft 365 관리 센터에서 커넥터 추가

관리 센터 -> 설정 -> 검색 및 인텔리전스 -> 데이터 원본 -> 새 연결 설정

파일 공유

알림 체크 -> 저장 및 계속하기

연결 경로 지정 및 테스트 -> 저장 및 계속하기

빠른 게시도 가능하지만 어떠한 설정이 있는지 확인하기 위하여 저장 및 계속하기로 진행하였습니다.

조직 전체 공유 보다는 폴더에 할당된 권한이 사용자와 매칭되는지 테스트를 위해서 이 데이터 원본에 액세스할 수 있는 사용자만을 지정하였습니다.

게시

저장 후 닫기

게시중 확인

연결 상태 -> 준비됨 확인

커넥터를 선택한 뒤, 전체 크롤링 시작

스테이징 추가를 클릭

특정 사용자만 먼저 선 배포

다음과 같이 인덱싱된 항목이 늘어난 것을 확인할 수 있습니다.

Copilot에게 질문하면 아래와 같이 인덱싱된 자료를 근거로 답변하는 것을 알 수 있습니다.

이전 포스팅에서는 Sharepoint Online에 HTML을 저장하여 테스트를 진행했었습니다.

체감상 Sharepoint Online에 업로드하였을 때의 답변 정확도 및 활용도가 더 뛰어난 것으로 느껴졌습니다.

아무래도 구조상 SharePoint Online 내부에 있는 데이터와 File Server를 연결하는 구조에 있어서 차이가 있는 것으로 느껴집니다.

Power Automate. Copilot 활용을 위한 HTTP 호출을 이용하여 HTML 파일 마이그레이션 흐름 만들기

Pepuri — Thu, 6 Jun 2024 13:27:39 +0900

Copilot은 M365 공간에 질문을 하여 답을 얻는 제품입니다.

그것이 Word이면 문서 생성, PowerPoint면 프레젠테이션일 뿐입니다.

그렇기 때문에 M365에 어떠한 정보를 기록할지, 그리고 어떻게 그 정보를 마이그레이션할지 고민이 필요합니다.

문서 파일들은 마이그레이션 툴이나 업체를 통해서 옮길 수 있습니다.

그렇다면 게시물과 같은 것들은 어떻게 옮기지? 라고 고민해보았습니다.

제 블로그 글들을 Sharepoint로 html 파일로 옮기고 그 정보를 Copilot을 통해서 활용가능한지 테스트하고 싶어졌습니다.

어렵지 않게 할 수 있는 방법을 찾다가 Power Automate로 출발하였습니다.

Power Automate 실행

만들기 -> 자동화된 클라우드 흐름

이름 지정 -> 건너뛰기

트리거 추가

되풀이 트리거 추가

주기를 적절하게 설정합니다.

(반복횟수를 고려해서 지정하시는 것을 권장드립니다. 업데이트 량이 많지 않다면 하루에 1번이나 시간단위로 지정하는 것이 적절합니다.)

작업 추가

제 Blog 주소는 limcm.tistory.com/1 에서 뒤에 숫자만 변경되는 형태입니다.

그래서 이 숫자를 변수로 지정해야 합니다.

런타임을 기본 제공으로 설정 -> Variable 선택 (한글은 검색이 잘 안됩니다.)

아래와 같이 시작 번호 지정

같은 방식으로 변수 초기화 추가

글은 473까지 있기 때문에 넉넉하게 500으로 EndIndex 지정

현재의 Index 를 지정

반복 진행을 위한 Do until 트리거 추가

CurrentIndex입력 -> 동적 수식 버튼 클릭

EndIndex 지정

반복할 횟수인 Count를 입력합니다. 제한사항이 있기 때문에 무한정 반복할 수 없습니다.

CurrentIndex가 EndIndex에 도달할 때까지 진행합니다.

만약 EndIndex와 CurrentIndex의 차이가 500이 넘으면 500까지만 진행합니다.

작업 추가

HTTP 추가

URL 입력 후 마지막에 / 입력 후 동적 콘텐츠 삽입 선택

CurrentIndex지정

Method - GET 지정

만약 사이트 인증이 필요하다면 하단의 고급 매개 변수를 지정해서 진행합니다. -> 저는 공개 페이지이기 때문에 패스

작업 추가

Control

조건

Status code를 선택합니다.

200 입력

설정 -> 다음 이후 실행 -> HTTP에서 4가지 상태를 전부 지정합니다.

-> 정상적으로 게시글이 있으면 200으로 응답하겠지만, 없으면 404로 응답할 수 있습니다. 이후에 응답에 따라서 동작이 나뉘도록 조건이 동작됩니다.

True에 작업 추가

SharePoint를 선택

경로를 사용하여 파일 메타데이터 가져오기

마이그레이션 진행할 사이트를 지정 -> 파일 경로를 지정합니다. 마지막에 동적 컨텐츠를 삽입하고 .html 형식으로 지정합니다. 경로 지정할 때, 임시 파일을 생성하고 지정하는게 편합니다.

-> HTMLCopilot 사이트에 문서 라이브러리에 1.html 파일이 있다면. 이라는 조건을 생성할 수 있습니다. 이렇게 지정하는 이유는 중복 생성을 막기 위함 입니다.

작업 추가

조건

함수 버튼 클릭

우선 아래와 같이 선택합니다.

아래의 항목을

['statusCode']로 변경합니다. -> 추가

아래와 같이 404 입력

설정 -> 다음 이후 선택 -> 4가지 상태 모두 지정

-> 404로 응답하였을 경우와 아닌 경우에 대한 동작이 나뉩니다.

True에서 작업 추가

Sharepoint -> 파일 만들기

사이트 및 폴더 경로 지정, 파일 이름은 CurrentIndex.html 동적 형태로 지정. 파일 콘텐츠는 HTTP에서 호출되는 Body를 지정합니다.

작업 추가

변수 증가 트리거 선택

CurrentIndex를 한번 진행할 때마다 1씩 증가

-> 1.html 생성이 완료되면 limcm.tistory.com/2 로 이어지는 흐름입니다. 물론 위에서 중복될 경우 전부 False로 인지하여 숫자가 계속 증가하는 형태입니다.

아래와 같이 완성됩니다. -> 저장

테스트 진행

수동 -> 테스트

흐름 실행

Sharepoint 사이트에서 자동으로 생성되는 것을 확인합니다.

수행 단계 이후부터 반복이기 때문에 상당 시간이 소요됩니다.

Copilot에게 관련된 질문시 마이그레이션된 html 파일을 참조하여 답변합니다.

Html 파일도 Copilot에서 활용할 수 있는 것이 검증되었습니다.

아래와 같이 흐름이 생성되고 예약된 것을 확인할 수 있습니다.

수동으로 실행을 원한다면, 전반적인 흐름은 같고, 생성시 인스턴트 클라우드 흐름을 선택합니다.

Deploy Microsoft Defender for Endpoint (MDE). (13) iOS by Intune MAM

Pepuri — Sun, 2 Jun 2024 21:57:08 +0900

지난 포스팅에서는 iOS 환경에서 MDM을 이용하여 MDE를 배포하는 방법에 대해서 작성하였습니다.

2024.06.02 - [Microsoft Defender XDR/MDE] - Deploy Microsoft Defender for Endpoint (MDE). (12) iOS by Intune MDM

이번에는 iOS 환경에서 MAM을 이용하여 MDE를 배포하는 방법에 대해서 작성하겠습니다.

Step1, 2는 Android MAM과 흐름이 같으니 참고하시기 바랍니다.

Step 1. Admin prerequisites

설정 -> 엔드포인트

고급 기능 -> Microsoft Intune이 필요합니다. 설정이 켜기로 되어있는지 확인

Intune 관리센터에서 MDE 커넥터 연결 상태 확인

정책 평가 앱 보호 -> 켜기 확인

Step 2. 앱 보호 정책 만들기

기존 앱 보호 정책을 사용하거나 새로 생성합니다.

앱 -> 앱 보호 정책 -> 정책 만들기 -> iOS/iPadOS

정책 만들기 -> 이름 지정 -> 다음

허용되는 최대 디바이스 위협 수준 -> 낮음 -> 액세스 차단 -> 다음

-> 이 설정을 통하여 MAM에 적용되는 앱 실행시 MDE를 체크합니다.

그룹 지정 후 다음

만들기

Step 3. 앱 구성 정책

iOS에서 사용하는 정책은 크게 Web Protection, Network Protection 2가지 입니다.

웹 보호 및 VPN
기본적으로 iOS의 엔드포인트용 Defender는 웹 보호 기능을 포함하고 사용하도록 설정합니다. 웹 보호는 웹 위협으로부터 디바이스를 보호하고 피싱 공격으로부터 사용자를 보호하는 데 도움이 됩니다. 피싱 방지 및 사용자 지정 표시기(URL 및 도메인)는 웹 보호의 일부로 지원됩니다. IP 기반 사용자 지정 지표는 현재 iOS에서 지원되지 않습니다. 웹 콘텐츠 필터링은 현재 모바일 플랫폼(Android 및 iOS)에서 지원되지 않습니다.
iOS의 엔드포인트용 Defender는 이 기능을 제공하기 위해 VPN을 사용합니다. VPN은 로컬이며 기존 VPN과 달리 네트워크 트래픽은 디바이스 외부로 전송되지 않습니다.
기본적으로 사용하도록 설정되지만 VPN을 사용하지 않도록 설정해야 하는 경우가 있을 수 있습니다. 예를 들어 VPN이 구성되면 작동하지 않는 일부 앱을 실행하려고 합니다. 이러한 경우 다음 단계에 따라 디바이스의 앱에서 VPN을 사용하지 않도록 설정할 수 있습니다.

네트워크 보호 구성
엔드포인트에 대한 Microsoft Defender 네트워크 보호는 기본적으로 사용하지 않도록 설정됩니다. 관리자는 다음 단계를 사용하여 네트워크 보호를 구성할 수 있습니다. 이 구성은 MDM 구성을 통해 등록된 디바이스와 MAM 구성을 통해 등록되지 않은 디바이스 모두에 사용할 수 있습니다.

이러한 사항에 대해서 기술 자료를 참고하여 앱 구성 정책을 통해서 변경할 수 있습니다.

기술 자료

Configure Microsoft Defender for Endpoint on iOS features - Microsoft Defender for Endpoint | Microsoft Learn

앱 -> 앱 구성 정책 -> 추가 -> 관리되는 앱

다음과 같이 지정

아래와 같은 형태로 설정할 수 있습니다. (아래의 예시는 VPN 사용 안함입니다.)

아래는 제가 임의로 설정한 값입니다.

Key	Value	Description
WebProtection	False	VPN을 사용하지 않기 위해서는 false로 설정하고, 이경우는 Web Protection을 사용할 수 없습니다.
DefenderOpenNetworkDetection	0	1 - 감사, 0 - Disable(default), 2 - Enable. 이 설정은 IT 관리 각각 오픈 네트워크 검색을 감사, 사용 안 함 또는 사용하도록 설정하여 관리됩니다. '감사' 모드에서는 최종 사용자 환경이 없는 ATP 포털로만 경고가 전송됩니다. 최종 사용자 환경의 경우 구성을 '사용' 모드로 설정합니다.
DefenderEndUserTrustFlowEnable	False	true - enable, false - disable; 이 설정은 IT 관리자가 비보안 및 의심스러운 네트워크를 신뢰하고 신뢰할 수 없도록 최종 사용자 앱 내 환경을 사용하거나 사용하지 않도록 설정하는 데 사용됩니다.
DefenderNetworkProtectionAutoRemediation	True	true - enable, false - disable; 이 설정은 IT 관리자가 사용자가 더 안전한 WIFI 액세스 지점으로 전환하거나 Defender에서 검색한 의심스러운 인증서를 삭제하는 등의 수정 작업을 수행할 때 전송되는 수정 경고를 사용하거나 사용하지 않도록 설정하는 데 사용됩니다.
DefenderNetworkProtectionPrivacy	True	true - enable, false - disable; 이 설정은 IT 관리자가 네트워크 보호에서 개인 정보를 사용하거나 사용하지 않도록 설정하도록 관리됩니다.
DefenderDeviceTag	MAM_iOS	디바이스 태그 지정

그룹 할당 -> 다음

만들기

배포가 완료되면, 아래와 같이 MAM 정책에 의해서 MDE 설치를 요구합니다.

Deploy Microsoft Defender for Endpoint (MDE). (12) iOS by Intune MDM

Pepuri — Sun, 2 Jun 2024 19:56:04 +0900

지난 포스팅에 이어서 이번에는 iOS에 MDE 배포를 진행하겠습니다.

iOS도 개별적으로 MDE 앱을 설치하여 로그인하면 사용할 수 있습니다.

이렇게 진행하였을 경우에는, 테넌트에 장치를 등록하여 관리하는 형태가 아닙니다.

또한, 사용자에게 Defender 앱을 사용하도록 하는 강제성이 떨어집니다.

아래의 기술 자료를 참고하여 먼저 MDM 형태로 배포하는 방법에 대해 다뤄보겠습니다.

Deploy Microsoft Defender for Endpoint on iOS with Microsoft Intune - Microsoft Defender for Endpoint | Microsoft Learn

해당 글은 감독되지 않은 디바이스를 기준으로 진행하였습니다.

Step1. 요구 사항확인

- 사용자에게 MDE 라이선스 할당

- iOS 기기에서 회사 포털 앱 로그인 및 등록

Step2. iOS 스토어 앱 추가

앱 -> iOS/iPadOS

추가 -> iOS 스토어 앱

App Store 검색

Defender for Endpoint 검색 -> 선택

최소 운영 체제 iOS 15.0 선택 -> 다음

할당할 그룹 추가

만들기

Step3. 자동화된 온보딩 설정

Zero-touch (Silent) onboarding of Microsoft Defender for Endpoint

-> 단어 그대로 사용자가 회사 포털만 설치하면 자동으로 온보딩하게 하는 설정입니다.

디바이스 -> iOS/iPadOS

구성 프로필 -> 만들기 -> 새 정책

템플릿 -> VPN -> 만들기

정책 이름 지정 -> 다음

아래와 같이 지정 후 추가

다음과 같이 지정 -> 저장

그룹 지정 -> 다음

만들기

이 과정을 진행하면, 회사 포털만 설치되어 있으면 별도의 설정과정이 필요하지 않습니다.

만약 제로 터치 온보딩이 진행되지 않으면, 사용자들에게 아래와 같은 화면에서 진행할 수 있는 가이드 배포가 필요합니다.

온보딩이 완료되면, 아래와 같이 자동으로 설치 되며,

보호 상태를 확인할 수 있습니다.

우측 상단에는 자동으로 VPN이 설정되는 것이 확인 되며,

항상 Defender로 보호되는 것을 알 수 있습니다.

아래와 같이 온보딩된 것을 확인할 수 있습니다.

다음 포스팅에서는 MAM으로 배포하는 방법에 대해서 다루겠습니다.

Deploy Microsoft Defender for Endpoint (MDE). (11) Android using MAM

Pepuri — Sat, 1 Jun 2024 21:33:49 +0900

이전 포스팅에서는 장치를 등록하여 관리하는 Intune MDM으로 온보딩하는 방식에 대해서 포스팅하였습니다.

2024.06.01 - [Microsoft Defender XDR/MDE] - Deploy Microsoft Defender for Endpoint (MDE). (10) Android Enterprise with Intune

이번에는 MDM 없이 MAM으로 MDE를 배포하는 방법에 대해서 다루겠습니다.

기술 자료

Configure Microsoft Defender for Endpoint on Android risk signals using App Protection Policies (MAM) - Microsoft Defender for Endpoint | Microsoft Learn

Step1. Admin prerequisites

Microsoft Defender -> 설정 -> 엔드포인트

고급 기능 -> Microsoft Intune이 필요합니다. 설정이 켜기로 되어있는지 확인

Intune 관리센터에서 MDE 커넥터 연결 상태 확인

정책 평가 앱 보호 -> 켜기 확인

Step2. 앱 보호 정책 구성

대부분 실제 환경에서는 기본 MAM 정책이 있겠지만 없다면, 적절한 테스트 정책을 생성합니다.

정책 이름 지정 -> 다음

모든 Microsoft 앱 지정 -> 다음

정책 설정 -> 다음

디바이스 조건에서 허용되는 최대 디바이스 위협 수준을 추가합니다.

정책 적용대상 추가

만들기

Step3. End-user prerequisites

- 브로커 앱인 Intune 회사포털 앱이 설치되어 있어야 합니다.

- 라이선스가 할당되어야 합니다.

Step4. 앱 구성 정책 설정

앱 구성 정책 -> 추가 -> 관리되는 앱

아래와 같이 입력 및 지정

저는 다음과 같이 설정 (아래의 정책항목은 기술자료를 보고 진행하는 것을 권장 드립니다.)

아래의 설정 값들은 제가 나중에 셀프스터디 후 다시 업데이트 하겠습니다.

Key	Value	Description
antiphishing	1	Web protection
vpn	1	Web protection
DefenderMAMConfigs	1
DefenderNetworkProtectionEnable	1	1 - 사용, 0 - 사용 안 함; 이 설정은 IT 관리자가 Defender 앱에서 네트워크 보호 기능을 사용하거나 사용하지 않도록 설정하는 데 사용됩니다.
DefenderCertificateDetection	1	2-사용, 1 - 감사 모드, 0 - 사용 안 함; 값이 2인 이 기능을 사용하도록 설정하면 Defender에서 잘못된 인증서를 검색하면 최종 사용자 알림이 사용자에게 전송됩니다. 경고도 SOC 관리자에게 전송됩니다. 감사 모드(1)에서는 알림 경고가 SOC 관리자에게 전송되지만 Defender에서 잘못된 인증서를 검색하면 최종 사용자 알림이 사용자에게 표시되지 않습니다. 관리자는 0을 값으로 사용하여 이 검색을 사용하지 않도록 설정하고 2를 값으로 설정하여 전체 기능 기능을 사용하도록 설정할 수 있습니다.
DefenderOpenNetworkDetection	1	2-사용, 1 - 감사 모드, 0 - 사용 안 함; 이 설정은 IT 관리자가 열린 네트워크 검색을 사용하거나 사용하지 않도록 설정하는 데 사용됩니다. 기본적으로 개방형 네트워크 검색은 값이 0으로 비활성화되고 Defender는 보안 포털의 SOC 관리자에게 최종 사용자 알림 또는 경고를 보내지 않습니다. 값이 1인 감사 모드로 전환하면 알림 경고가 SOC 관리자에게 전송되지만 Defender가 열린 네트워크를 검색하면 최종 사용자 알림이 사용자에게 표시되지 않습니다. 값 2를 사용하도록 설정하면 최종 사용자 알림이 표시되고 SOC 관리자에게도 경고가 전송됩니다.
DefenderEndUserTrustFlowEnable	0	1 - 사용, 0 - 사용 안 함; 이 설정은 IT 관리자가 비보안 및 의심스러운 네트워크를 신뢰하고 신뢰할 수 없도록 최종 사용자 앱 내 환경을 사용하거나 사용하지 않도록 설정하는 데 사용됩니다.
DefenderNetworkProtectionAutoRemediation	1	1 - 사용, 0 - 사용 안 함; 이 설정은 IT 관리자가 사용자가 더 안전한 Wi-Fi 액세스 지점으로 전환하거나 Defender에서 검색한 의심스러운 인증서를 삭제하는 등의 수정 작업을 수행할 때 전송되는 수정 경고를 사용하거나 사용하지 않도록 설정하는 데 사용됩니다.
DefenderNetworkProtectionPrivacy	1	1 - 사용, 0 - 사용 안 함; 이 설정은 IT 관리자가 네트워크 보호에서 개인 정보를 사용하거나 사용하지 않도록 설정하는 데 사용됩니다. 값 0으로 개인 정보를 사용하지 않도록 설정하면 악의적인 wifi 또는 인증서 데이터를 공유하는 사용자 동의가 표시됩니다. 값이 1인 사용 상태인 경우 사용자 동의가 표시되지 않고 앱 데이터가 수집되지 않습니다.
DefenderOptionalVPN	1	선택적 권한 구성
DefenderOptionalAccessibility	1	선택적 권한 구성
DefenderDeviceTag	MAM_Android	관리센터에 표시할 TAG 지정

그룹 할당 -> 다음 -> 만들기

Step5. End-User Onboarding

Outlook 계정 설정을 진행하면, MAM 정책에 의해서 디바이스가 정상 상태에서 통과하지 못합니다.

그리고 MDE 설치를 통해서 보호가 필요한 흐름으로 진행됩니다.

설치 후 권한 설정을 진행합니다.

설정 및 검사 완료

다음과 같이 디바이스 상태 체크 완료

아래와 같이 실시간 검사되는 것을 알 수 있습니다.

그리고 Defender에 아래와 같이 온보딩 된 것을 확인할 수 있습니다. MAM도 온보딩이 가능한 것을 알 수 있습니다.

다만 관리자 부분에서 알 수 없음으로 표시되는 것으로 보았을 때, MDM하고 차이가 있을 것으로 예상됩니다.

그래도 국내 정서에서 MDM을 사용하기 어려운 점을 고려하면, MAM으로 MDE 배포하는 것도 좋은 방안이라고 생각합니다.

다음 포스팅 부터는 iOS 배포에 대해서 다루겠습니다.

Deploy Microsoft Defender for Endpoint (MDE). (10) Android Enterprise with Intune

Pepuri — Sat, 1 Jun 2024 16:37:35 +0900

이번에는 Mobile OS에서 MDE를 배포하는 것에 대해서 다뤄보려고 합니다.

모바일 MDE는 Mobile Threat Defense(MTD)라고 소개하고 있습니다.

Microsoft Defender for Endpoint - Mobile Threat Defense - Microsoft Defender for Endpoint | Microsoft Learn

Microsoft Defender for Endpoint on Android and iOS is our mobile threat defense solution (MTD).
Android 및 iOS 용 MDE는 우리의 모바일 위협 방지 솔루션(MTD) 입니다.

현재 제공되는 기능은 다음과 같습니다.

이중에서 Web, Malware, Network Protection이 주요 기능이라고 생각합니다.

우선 Android에서 별도의 설정 없이 Defender App을 설치해보겠습니다.

로그인하면, 다음과 같이 표시됩니다.

그리고 백그라운드에서 동작하는 것처럼 나타납니다.

설정 없이 단순히 앱 설치 및 로그인시에는 장치가 온보딩되지 않습니다.

온보딩된다는 것은 결구 회사에 기기를 등록하는 것을 의미하며, 이것은 Intune MDM을 사용한다는 의미입니다.

Android의 등록방식은 아래와 같이 크게 3가지가 있으며, 방금처럼 단순히 로그인한 방식은 Unmanaged BYOD입니다.

이번 포스팅에서는 Android Enterprise with Intune 방식으로 Deploy 하겠습니다.

Deploy Microsoft Defender for Endpoint on Android with Microsoft Intune - Microsoft Defender for Endpoint | Microsoft Learn

Step1. 관리되는 앱 설정

앱 -> Android

추가 -> 관리되는 Google Play 앱

선택

Microsoft Defender 검색 -> 선택

상단의 동기화 버튼을 클릭합니다.

추가됨 확인

Step2. 앱 구성 정책 설정

앱 -> 앱 구성 정책

추가 -> 관리되는 디바이스

아래와 같이 설정합니다. 프로필 유형은 우선 모든 프로필 유형으로 선택하였습니다.

구성 디자이너 사용

추가 -> Defender에 필요한 설정을 추가합니다. -> 확인

다음과 같이 추가합니다. -> 다음

참고로 이 값을 1로 설정하면 개인 프로필에서 Defender를 사용한다는 의미입니다.

할당할 그룹을 추가합니다.

만들기

이전의 앱 메뉴에서 Microsoft Defender: Antivirus 선택

속성 -> 편집 -> 필수 그룹 추가

Step4. 장치 등록

Android 기기에서 회사 포털을 설치합니다.

로그인

회사 프로필 등록 과정 진행

계속

동의

계속

완료

장치 등록됨 확인

업무 영역을 선택하면, MSDefender를 확인할 수 있습니다.

로그인

권한 설정 진행

아래와 같이 보호 상태를 확인할 수 있습니다.

백그라운드에서 보호 상태로 동작되는 것을 확인할 수 있습니다.

Intune에서 디바이스 설치 상태 확인

Defender에서 장치 온보딩 상태 확인

EDR 수준까지는 아니어도, Defender에서 통합으로 장치관리를 할 수 있습니다.

다음 포스팅에서는 MAM 정책을 통한 Android에서 MDE 배포하는 방법에 대해서 다루겠습니다.

2024.06.01 - [Microsoft Defender XDR/MDE] - Deploy Microsoft Defender for Endpoint (MDE). (11) Android using MAM

Microsoft Defender for Identity (MDI). (2) Log 분석

Pepuri — Sun, 26 May 2024 13:43:40 +0900

지난 포스팅에 이어서 이번에는 수집되는 로그 분석에 대해 다루겠습니다.

2024.04.28 - [Microsoft Defender XDR/MDI] - Microsoft Defender for Identity (MDI). (0) Introduction

2024.05.01 - [Microsoft Defender XDR/MDI] - Microsoft Defender for Identity (MDI). (1) Deployment

MDI는 수집되는 Identity Log를 통해서 이상 행위 감지시 경고나 조치를 취하는 것에 가장 큰 메리트가 있습니다.

만약 LDAP 통신등 3rd Party 및 Exchange Server 등 온프레미스 Identity 관리를 AD를 중심으로 구성되어 있다면, MDI의 로그 수집 및 감지는 Identity 관리를 더욱 효율적으로 만들 것입니다.

예를 들면 SAP이나 Exchange에 시도되는 Identity 관련 로그가 DC에 모이고

그렇게 DC에 모인 로그들은 Defender로 전달됩니다.

물론 AD 중심이 만능이라고 생각하지는 않습니다. 기존에 AD가 없다라고 하면, Entra ID를 중심으로 SSO를 구성하는 것을 권장합니다. Cloud 시대에 Cloud를 사용하기 위해서 온프레미스를 추가 도입한다는 것은 시대를 역행하는 느낌을 벗어날 수 없습니다. 요새는 AD를 제대로 다룰 수 있는 인력을 채용하기 어렵습니다.

즉, 조건과 상황에 맞게 AD or Entra ID 를 선택하여 관리해야 합니다.

Entra ID Protection 역시 Defender에서 관리할 수 있습니다.

간단하게 MDI Incident를 테스트 하는 것은 어렵지 않습니다.

RDP포트인 3389를 오픈하면 일정 시간 지나면, Identity 로그인 시도를 반복하기 때문에 Incident가 발생됩니다.

인시던트를 클릭 -> 디바이스를 확인해 보면, DC와 MAIN이 확인됩니다.

분석 내용을 보면, Main 서버에 무차별 접속시도 -> DC에 자격증명 실패 확인 -> 경고 전달. 이러한 흐름으로 볼 수 있습니다.

위협 분석 보고서 보기를 클릭합니다.

분석가 보고서를 한글로 번역해서 보면, 왜 인시던트가 발생했는지 알 수 있습니다.

실제 해당하는 원인 설명도 포함되어 있습니다.

개인적으로는 이러한 분석도 좋지만, Advanced Hunting 기능이 Defender XDR의 최대 장점이라고 생각합니다.

고급 헌팅 -> IdentityLogonEvents -> 쿼리 실행

아래와 같이 가독성 좋은 Identity 로그를 관리할 수 있습니다.

기존 AD의 보안로그는 사실… AD 1도 모르는 저에게는 진입장벽과 같았습니다.

로그를 내보내면, Excel 세부 항목들을 확인할 수 있습니다.

저는 주로 HealthMailbox와 M365 로그를 제외하여 쿼리를 진행합니다.

IdentityLogonEvents
| where AccountName !startswith "Healthmailbox"
| where Application !startswith "Microsoft 365"

그리고 실패 이유가 계정 잠김일 때, 알림을 받거나 추가 Action을 진행할 수 있습니다.

예를 들면, 아래와 같이 FailureReason에 AccountDisabled 조건을 쿼리문 생성

IdentityLogonEvents 
| where AccountName !startswith "Healthmailbox"
| where Application !startswith "Microsoft 365"
| where FailureReason contains "AccountDisabled"

검색 규칙 만들기

아래와 같이 설정을 진행할 수 있습니다.

자신이 생성한 규칙을 확인

관리자가 원하는 기준으로 경고 알림을 받을 수 있습니다.

10.0.3.4는 Exchange Server 입니다.

즉 Exchange Server에서 차단되었거나 차단된 계정으로 로그인 시도하는 것을 알 수 있습니다.

MDI는 Identity를 이전보다 보다 쉽게 관리할 수 있으며, 내가 원하는 규칙을 설정하여 알림 및 조치를 취할 수 있는 장점이 있습니다.

Microsoft Defender for Identity (MDI). (1) Deployment

Pepuri — Wed, 1 May 2024 20:32:54 +0900

2024.04.28 - [Microsoft Defender XDR/MDI] - Microsoft Defender for Identity (MDI). (0) Introduction

아래의 기술자료를 기준으로 진행하겠습니다.

Quick installation guide - Microsoft Defender for Identity | Microsoft Learn

본격적으로 MDI 배포에 대해서 다루겠습니다.

1. MDI Sensor 설치

Microsoft Defender (https://security.microsoft.com) → Settings → Identities

프로비저닝 진행

Sensors → Add sensor

Access key 복사 → Download installer → 설치 진행 (Domain Controller 및 ADFS 에서 진행)

액세스 키 붙여넣기 → 설치

설치 진행중

마침

설치 상태 확인

2. Windows 이벤트 수집 구성

기술 자료

Configure audit policies for Windows event logs - Microsoft Defender for Identity | Microsoft Learn

활성화 해야하는 감사 정책 및 수집해야 하는 Event ID는 다음과 같습니다.

Domain Controller → gpmc.msc

Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration

Account Logon → Audit Credential Validation → Enable Logging

Account Management

DS Access

System

3. Configure NTLM auditing (Event ID 8004)

위와 동일하게 Default Domain Contoller 정책에서 수정합니다.

Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options

Network security: Restrict NTLM에서 아래의 정책 활성화

4. Configure domain object auditing

ADUC(DSA.msc) → 도메인 우클릭 → Properties

Security → Advanced

Auditing → Add

Select a principal

Everyone → OK

Success, Descendant User objects 선택

Clear all

Full control

List contents, Read all properties, Read permissions 체크 해제 → OK → 권한생성 완료

위에서 진행한 것과 같은 방식으로 Descendant Group object, Descendant Computer object, Descendant msDS-GroupManagedServiceAccount Objects, Descendant msDS-ManagedServiceAccount Objects 진행

아래와 같이 추가된 권한 확인

5. Enabling auditing on an ADFS object (ADFS 구성시)

ADUC → 도메인 → Program Data → Microsoft → ADFS → Properties

Security → Advanced

Auditing → Add

Everyone → This object and all descendant objects

Clear all

Read all properties, Write all properties 체크 → OK

추가된 권한 확인 → OK

6. Enable auditing on the Configuration container

Adsiedit.msc

Configuration → 우클릭 → Properties

Security → Advanced

Auditing → Add

Everyone → This object and all descendant objects

Clear all

Write all properties → OK

생성된 권한 확인 → OK

7. Create Service Account

Domain Controller에서 다음 PowerShell Script 를 실행 (환경에 맞게 수정해서 진행합니다.

 # Set Variables
$gMSA_AccountName = "svc_mdiGMSA" # INSERT PREFERRED NAME FOR GMSA
$gMSA_HostsGroupName = "gMSAGroup" # INSERT GROUP NAME TO ADD SERVERS TO
$gMSA_HostNames = "DC01", "DC02", "FS01" #, "ADCS02", "ADFS01", "ADFS02"
# Import Active Directory PowerShell module
Import-Module ActiveDirectory -Verbose
# Create the group and add the members
$gMSA_HostsGroup = New-ADGroup -Name $gMSA_HostsGroupName -GroupScope Global -PassThru
$gMSA_HostNames | ForEach-Object { Get-ADComputer -Identity $_ } |
ForEach-Object { Add-ADGroupMember -Identity $gMSA_HostsGroupName -Members $_ }
# Add Key Distribution Service (KDS) before start adding new group Managed Service Accounts
# If you have only one DC, then use this command to create the KDS root key and set start time in the past
Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))
# If you have multiple DCs, then use the command below to replicate immediately
Add-KdsRootKey -EffectiveImmediately
# Create gMSA
New-ADServiceAccount -Name $gMSA_AccountName `
-DNSHostName "$gMSA_AccountName.$env:USERDNSDOMAIN" `
-PrincipalsAllowedToRetrieveManagedPassword $gMSA_HostsGroupName

gMSAGroup 확인

Service Account 확인

 # Clear KDC Cache on each DC
$gMSA_HostNames = “DC01"
Invoke-Command -ComputerName $gMSA_HostNames -ScriptBlock {
klist purge -li 0x3e7
}

각 DC/ADFS에서 Service Account 설치

Deleted Objects Containers에 필요한 읽기 권한을 부여

 # Declare the identity that you want to add read access to the deleted objects container:
$Identity = 'svc_mdiGMSA'
# If the identity is a gMSA, first to create a group and add the gMSA to it:
$groupName = 'gMSAGroup'
$group = (Get-ADGroup -Identity gMSAGroup).name
# Get the deleted objects container's distinguished name:
$distinguishedName = ([adsi]'').distinguishedName.Value
$deletedObjectsDN = 'CN=Deleted Objects,{0}' -f $distinguishedName
# Take ownership on the deleted objects container:
$params = @("$deletedObjectsDN", '/takeOwnership')
C:\Windows\System32\dsacls.exe $params
# Grant the 'List Contents' and 'Read Property' permissions to the user or group:
$params = @("$deletedObjectsDN", '/G', ('{0}\{1}:LCRP' -f ([adsi]'').name.Value, $Identity))
C:\Windows\System32\dsacls.exe $params
  
# To remove the permissions, uncomment the next 2 lines and run them instead of the two prior ones:
# $params = @("$deletedObjectsDN", '/R', ('{0}\{1}' -f ([adsi]'').name.Value, $Identity))
# C:\Windows\System32\dsacls.exe $params

다음 그룹 정책에 생성한 서비스 계정 추가

8. Add Service Account

Directory services accounts → Add credentials

Group Managed service account 추가

9. Configure ADFS

ADFS 머신에서 Audit 활성화

구성이 완료되면 아래와 같이 Advanced hunting에서 Identity와 관련된 기록이 조회되는 것을 확인할 수 있습니다.

다음 포스팅에서는 MDI에서 어떠한 내용들을 확인할 수 있는지 포스팅하겠습니다.

2024.05.26 - [Microsoft Defender XDR/MDI] - Microsoft Defender for Identity (MDI). (2) Log 분석

Microsoft Defender for Identity (MDI). (0) Introduction

Pepuri — Sun, 28 Apr 2024 16:59:11 +0900

이전에 Microsoft Defender for Identity (MDI) 구성에 대해서 작성한 적이 있습니다.

그런데 지금 시점에서 보니 글을 작성한 방향이 잘못되어서 새로 작성하게 되었습니다.

2022.09.06 - [Microsoft Defender XDR/MDI] - Deploy Microsoft Defender for Identity (MDI) (1). Configuration

2022.09.14 - [Microsoft Defender XDR/MDI] - Deploy Microsoft Defender for Identity (MDI) (2). Lab Setup

보통은 리마스터링 개념으로 진행하는데, 수정할 것들이 너무 많아서 기존 글은 Archiving 용으로 남기고 새로 작성하기로 결정하였습니다.

제가 생각하는 Microsoft 365 E5의 XDR은 우선 모든 로그가 Tenant 중심으로 수집 -> Defender에서 분석 & 조치 -> Advanced Hunting에서 조회 로 이어지는 흐름이라고 생각합니다.

같은 맥락으로 기술자료에서 MDI에 대해서 다음과 같이 설명하고 있습니다.

Architecture - Microsoft Defender for Identity | Microsoft Learn

Microsoft Defender for Identity는 네트워크 트래픽을 캡처 및 구문 분석하고 도메인 컨트롤러에서 직접 Windows 이벤트를 활용하여 도메인 컨트롤러를 모니터링한 다음 공격 및 위협에 대한 데이터를 분석합니다.

다음 이미지는 Defender for Identity가 Microsoft Defender XDR 위에 계층화되어 다른 Microsoft 서비스 및 타사 ID 공급자와 함께 작동하여 도메인 컨트롤러 및 Active Directory 서버에서 들어오는 트래픽을 모니터링하는 방법을 보여줍니다.

로그인과 관련된 ADFS에 대한 분석도 지원합니다. 최근에는 AD CS도 지원하게 되었습니다.

그림상에서 AD 뿐만 아니라 Identity와 관련된 모든 로그를 수집하고 분석을 하는 것을 알 수 있습니다.

MDI 센서는 다음과 같은 기능을 합니다.

도메인 컨트롤러 네트워크 트래픽(도메인 컨트롤러의 로컬 트래픽) 캡처 및 검사
도메인 컨트롤러에서 직접 Windows 이벤트 수신
VPN 제공업체로부터 RADIUS 계정 정보를 수집
Active Directory 도메인에서 사용자 및 컴퓨터에 대한 데이터 검색
네트워크 엔터티(사용자, 그룹, 컴퓨터) 확인 수행
관련 데이터를 Defender for Identity 클라우드 서비스로 전송

Advanced hunting에는 MDE와 마찬가지로 수집된 상세 로그를 확인할 수 있습니다.

인시던트에서 다음과 같이 Identity 경고를 확인할 수 있습니다.

MDI와 관련하여 현재까지 작성된 포스팅

2024.04.28 - [Microsoft Defender XDR/MDI] - Microsoft Defender for Identity (MDI). (0) Introduction

2024.05.01 - [Microsoft Defender XDR/MDI] - Microsoft Defender for Identity (MDI). (1) Deployment

2024.05.26 - [Microsoft Defender XDR/MDI] - Microsoft Defender for Identity (MDI). (2) Log 분석