Latest / M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어) / Microsoft Entra Cloud Sync 쉽게 이해하기: Active Directory를 Entra ID와 가볍게 동기화하는 방법 (AI 더빙)

Transcript

Microsoft Entra Cloud Sync 쉽게 이해하기: Active Directory를 Entra ID와 가볍게 동기화하는 방법 (AI 더빙) · M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어)

0:00
마이크로소프트 365, 코파일럿, AI, 에이저, 그리고 업무의 미래를 만들어가는 사람들과 함께하는 10일간의 여정을 준비되셨나요?
0:08
이번 1월, M365 컨퍼런스가 더 커진 규모로 돌아옵니다.
0:12
전세계 MVP와 업계 전문가들이 선보이는 라이브 세션, 실무 데모, 실용적인 지식을 직접 경험해보세요.
0:18
뻔한 슬라이드나 끝없는 유행원은 없습니다.
0:21
코파일럿 스튜디오, AI 에이전트, 패브릭, 보안, 거버넌스, 자동화 등 실제적인 과제들을 다룹니다.
0:29
IT 전문가든, 개발자든, 비즈니스 리더든 여러분을 위한 세션이 준비되어 있습니다.
0:35
10일 동안 다양한 기술을 탐구하고 글로벌 커뮤니티와 소통할 수 있습니다.
0:40
라이브로 시청하고 실용적인 통찰력을 여러분의 조직에 적용해보세요.
0:44
2027년 1월, 10일간 하나의 마이크로소프트 커뮤니티가 펼쳐집니다.
0:49
지금 등록이 시작되었습니다.
0:52
지금 바로 자리를 확보하세요.
0:56
웹사이트는 m365con.net입니다.
1:00
m365con.net에 대해서 지금 등록하시고 1월에 라이브로 뵙겠습니다.
1:04
안녕하세요.
1:05
m365에서 전해드리는 마이크로소프트 지식 한 조각, 날리지 너겟츠,
1:08
위 새로운 에피소드에 오신 것을 환영합니다.
1:10
FM, EOW, TMNM, 밀코 피터스입니다.
1:12
마이크로소프트 엔트라 클라우드 싱크란 정확히 무엇일까요?
1:15
엔트라 커넥트 위 또 다른 이름일까요?
1:17
아니면 다른 문제를 해결하는 도구일까요?
1:19
많은 기업이 여전히 사내 네트워크의 액티브 디렉토리에 직원 계정을 관리하고 있습니다.
1:23
하지만 직원들은 마이크로소프트 365에서 업무를 수행합니다.
1:26
이들은 팀즈, 익스체인지, 온라인 이메일, 온드라이브 파일, 그리고 클라우드 앱이 필요합니다.
1:30
이로 인해 아이디가 중요한 두 개의 장소가 생겨납니다.
1:32
연결고리가 없으면 액티브 디렉토리에는 존재하지만,
1:35
마이크로소프트 365의 클라우드 안내 데스크인 엔트라 아이디에는 존재하지 않을 수 있습니다.
1:39
비밀번호가 일치하지 않게 됩니다.
1:41
액세스 권한 부여가 늦어집니다.
1:43
IT 부서는 동일한 작업을 두 번씩 반복하게 됩니다.
1:46
엔트라 커넥트는 이 두 곳을 연결하는 익숙한 로컬 도구가 되었습니다.
1:49
클라우드 싱크는 동기화 작업의 상당 부분을 마이크로소프트 엔트라에서 처리하는 색다른 방식을 취합니다.
1:54
영상을 다 보고 나면 이것이 무엇을 하는지, 왜 존재하는지, 그리고 2026년에 무엇이 바뀌었는지 알게 될 것입니다.
1:58
하지만 여러분의 회사에 적합한지 결정지는 한 가지 경계선이 남아있습니다.
2:01
왜 아이디 동기화에는 더 단순한 모델이 필요한지 알아보겠습니다.
2:05
신입서원부터 시작해보죠.
2:06
인사팀은 IT 부서에 마야가 월요일부터 출근한다고 알립니다.
2:09
누군가 마야의 아이디 계정을 액티브 디렉토리에 생성합니다.
2:11
이곳은 많은 기업이 여전히 직원들의 정보를 보관하는 로컬 캐비닛으로 사용합니다.
2:15
이름, 업무용 이메일, 부서, 관리자, 그룹 멤버십, 비밀번호 세부 정보가 모두 여기서 시작됩니다.
2:21
하지만 마야는 회사 네트워크 안에서만 일하지 않습니다.
2:24
집에서 팀즈에 로그인해야 합니다.
2:26
익스체인지 온라인 사소함도 필요합니다.
2:28
팀은 시어포인트에 파일을 저장하며,
2:30
마야는 첫날이 끝나기 전에 급여관리, CRM, 교육 또는 기타 클라우드 앱에 접근해야 할 수도 있습니다.
2:34
한 사람에게는 하나의 작동하는 아이디가 필요합니다.
2:37
그 신원은 두 곳 모두에서 동일한 마야를 가리키면서 나타나야 합니다.
2:41
그녀의 로그인 이름은 일치해야 합니다.
2:42
그녀의 그룹 정보는 클라우드로 전달되어야 합니다.
2:45
액티브 디렉토리에서 비밀번호가 변경되면,
2:47
마이크로소프트 365도 그 비밀번호를 안전하게 확인할 방법이 필요합니다.
2:51
그것이 바로 아이디 동기화의 역할입니다.
2:53
액티브 디렉토리를 사무실 건물 지하에 있는 서류보관함이라고 생각해보세요.
2:57
그곳에는 회사가 이미 신뢰하는 직원 기록이 보관되어 있습니다.
3:00
엔트라 아이디는 위층 안내데스크에 앉아 누가 마이크로소프트 365에 들어올 수 있는지, 어떤 방을 사용할 수 있는지 결정합니다.
3:06
서류보관함과 안내데스크가 정보를 공유하지 않으면,
3:09
마야는 문 앞에서 가로막히게 됩니다.
3:11
20년 전에는 그 간극 때문에 수작업이 많이 필요했습니다.
3:14
IT팀은 로컬의 계정을 하나 만들고, 클라우드 서비스의 계정을 또 하나 만들어야 했습니다.
3:18
마야가 이름을 바꾸거나, 팀을 옮기거나,
3:21
퇴사할 때 누군가는 그녀의 정보가 있는 모든 곳을 기억해야 했습니다.
3:25
사람은 만각하기 마련입니다.
3:26
아이디 동기화를 통한 새로운 팀 방식은 일상적인 IT 업무를 변화시켰습니다.
3:30
액티브 디렉토리에서의 변경사항이 엔트라 아이디로 흐를 수 있게 되어,
3:33
클라우드 계정이 별도의 기록이 아닌 로컬 계정을 따르게 되었습니다.
3:36
오랫동안 엔트라 커넥트가 그 작업을 처리해왔습니다.
3:39
엔트라 커넥트는 회사 네트워크 내부의 서버에서 실행됩니다.
3:42
액티브 디렉토리를 읽고, 로컬 동기화 규칙을 적용하며,
3:45
자체 로컬 데이터 저장소를 유지하고, 승인된 변경사항을 엔트라 아이디로 보냅니다.
3:49
특히 기업이 데이터 이동 방식을 깊이 있게 제어해야 할 때 많은 일을 할 수 있습니다.
3:52
그러한 유연성에는 책임이 따릅니다.
3:55
누군가는 서버를 관리해야 합니다.
3:57
누군가는 패치를 적용해야 합니다.
3:58
사용자의 동기화 인증이 예상대로 되지 않을 경우,
4:01
누군가는 로컬 규칙을 이해해야 합니다.
4:02
또한 메인 동기화 서버가 작동을 멈추면,
4:04
IT가 문제를 해결하거나 복구 계획을 따를 때까지,
4:06
변경사항이 마이크로소프트 365에 도달하지 못할 수 있습니다.
4:09
마야에게는 개정되기를 의미할 수 있습니다.
4:11
수백, 수천명이 직원이 있는 회사라면 신규 입사자가 클라우드 앱에 나타나지 않거나,
4:16
비활성화된 개정의 액세스 권한이 늦게 해제되고,
4:19
지원 요청이 쌓이기 시작할 수 있습니다.
4:21
문제는 엔트라 커넥트라는 제품 자체의 실패가 아닙니다.
4:24
모든 로컬 엔진에는 그에 따른 로컬 작업이 수반된다는 점입니다.
4:27
많은 기업이 자체 서버에서 관리해야 할 요소를 줄이길 원합니다.
4:30
클라우드 싱크는 바로 그 아이디어를 따릅니다.
4:32
거대한 동기화 엔진, 상세한 처리 과정,
4:34
대부분의 규칙을 네트워크 내부에 두는 대신,
4:36
마이크로소프트 엔트라가 클라우드에서 그 작업의 상당 부분을 처리합니다.
4:39
비하의 로컬 네트워크는 액티브 디렉토리를 읽고,
4:41
외부와 안전하게 통신할 수 있는 더 작은 연결 지점만 유지합니다.
4:44
서류 보관함은 그대로 그 자리에 있습니다.
4:46
처리 과정이 안내데스크 쪽으로 더 가까이 이동하는 것입니다.
4:49
이를 통해 팀이 관리해야 할 로컬 소프트웨어의 양을 줄이면서도,
4:52
액티브 디렉토리를 직원 정보의 원천으로 유지할 수 있습니다.
4:54
또한 복구에 대한 관점도 변화시킵니다.
4:56
특히 여러 사무실, 여러 디렉토리를 운영하거나 최근 합병을 겪은 기업의 경우 더욱 그렇습니다.
5:01
그렇다면 주요 동기화 작업이 클라우드에서 실행될 때,
5:04
정확히 무엇이 회사 네트워크 내부에 남게 될까요?
5:07
그것이 바로 마이크로소프트 엔트라 클라우드 동기화의 본질입니다.
5:10
마이크로소프트 엔트라 클라우드 동기화는 선택한 사용자, 그룹,
5:13
연락처를 액티브 디렉토리에서 엔트라 아이디로 복사하는 클라우드 관리 방식입니다.
5:17
안전한 택배 서비스라고 생각하면 됩니다.
5:19
기아의 액티브 디렉토리는 네트워크 내부에서 직원 기록을 보관합니다.
5:23
엔트라 아이디는 사용자가 마이크로소프트 365에 로그인할 수 있도록 해당 기록 중 승인된 부분이 필요합니다.
5:28
클라우드 동기화는 프로비저닝 에이전트라는 작은 택배원을 네트워크 내부에 배치하여 정보를 안전하게 전달합니다.
5:34
이 택배원은 별도의 보관 시스템을 가지고 있지 않습니다.
5:37
승인된 디렉토리 정보를 읽어 암호화한 뒤,
5:39
아웃바운드 연결을 통해 마이크로소프트 엔트라로 전송합니다.
5:42
아웃바운드 연결은 에이전트가 클라우드와 통신을 시작한다는 것을 의미합니다.
5:47
네트워크를 개방하여 알 수 없는 연결을 기다릴 필요가 없습니다.
5:50
이는 유용한 보안 세부사항입니다.
5:52
에이전트는 네트워크 내부에 위치함으로 액티브 디렉토리에 접근할 수 있습니다.
5:56
에이전트가 데이터를 클라우드로 안전하게 전송함으로 마이크로소프트 엔트라가 이를 처리할 수 있습니다.
6:00
양측은 전체 동기화 엔진을 자체 서버에 설치하지 않고도 함께 작동할 수 있습니다.
6:04
백그라운드에서 엔트라가 작업의 대부분을 처리합니다.
6:07
사용자가 엔트라 아이디에 이미 존재하는지 확인합니다.
6:10
사용자가 선택한 범위를 적용합니다.
6:12
설정한 필드 맵핑을 따릅니다.
6:14
그런 다음 정보가 규칙과 일치하면 클라우드 개체를 생성하거나 업데이트합니다.
6:18
이러한 선택사항은 엔트라 포털에서 관리합니다.
6:21
엔트라 커넥트에 익숙하다면 이는 큰 변화입니다.
6:23
엔트라 커넥트에서는 대부분의 논리 및 문제 해결 작업이 동기화 도구가 실행되는 서버에서 수행됩니다.
6:28
클라우드 동기화를 사용하면 포털에서 구성을 생성하고 동기화 항목을 선택하고 필드를 맵핑하고 결과를 한 곳에서 확인할 수 있습니다.
6:35
로컬 에이전트는 가볍게 유지됩니다.
6:37
클라우드 동기화를 위해 로컬 SQL 데이터베이스를 갖춘 대규모 로컬 동기화 엔진은 없습니다.
6:42
이제 기본 맵핑을 확인할 때마다 로컬 규칙 편집기를 열 필요가 없습니다.
6:47
마이크로소프트가 에이전트 업데이트를 처리하는 동안 귀하의 팀은 비즈니스의 중요한 아이디 규칙에 집중할 수 있습니다.
6:53
그렇다고 해서 통제력을 잃는 것은 아닙니다.
6:55
여전히 엔트라 아이디에 진입할 사용자와 그룹을 직접 선택합니다.
6:59
표시 이름, 부서, 전화번호, 관리자와 같은 필드를 선택할 수 있습니다.
7:03
맵핑은 액티브 디렉토리 레코드에 어떤 네이블이 엔트라 아이디 위 어떤 네이브를 채워야 하는지에 대한 간단한 질문에 답하는 것입니다.
7:09
많은 기업의 경우 기본 맵핑으로 일반 직원 계정을 처리할 수 있습니다.
7:13
액티브 디렉토리 위 표시 이름이 마야파텔이라면 엔트라 아이디도 마야파텔을 받을 수 있습니다.
7:17
부서가 영업팀에서 고객 성공팀으로 변경되면 해당 업데이트가 클라우드 계정에 반영될 수 있습니다.
7:21
그룹 멤버십을 통해 마이크로소프트 360 오리소스에 액세스할 수 있는 경우 그룹 정보도 동기화될 수 있습니다.
7:26
일부 설정에는 작은 변경이 필요합니다.
7:29
클라우드 동기화에는 값이 이동할 때 값을 조정해야 하는 경우를 위한 간단한 표현식이 포함되어 있습니다.
7:33
회사에서 특정 계정 세트의 표시 이름에 전미사를 추가하려 할 수 있습니다.
7:37
복잡한 로컬 동기화 규칙을 구축하는 대신 클라우드 구성에서 이를 설정할 수 있습니다.
7:42
이 차이점을 염두에 두십시오.
7:43
클라우드 동기화는 일반적인 아이디 작업에 대해 합리적인 제어 기능을 제공합니다.
7:47
오랫동안 사용해온 엔트라 커넥트 설정에 포함된 모든 고급 사용자 지정을 자동으로 복사하도록 설계된 것은 아닙니다.
7:52
단지 최신 도구라는 이유만으로 도구를 선택하는 실수를 방지할 수 있으므로 이 결정에 대해서는 나중에 다시 다루겠습니다.
7:58
암호와 관련하여 가장 많은 질문이 발생합니다.
8:01
클라우드 동기화는 암호해시 동기화를 사용할 수 있습니다.
8:03
이 문구는 실제보다 더 심각하게 들릴 수 있습니다.
8:06
읽기 가능한 암호는 마이크로소프트 엔트라로 전송되지 않습니다.
8:10
대신 액티브 디렉토리가 보호된 암호 확인 정보를 생성하고
8:13
엔트라 아이디는 이 정보를 사용하여 사용자의 로그인을 안전하게 확인합니다.
8:17
따라서 마야는 회사 암호를 사용하여 마이크로소프트 365에 로그인할 수 있습니다.
8:21
그녀의 암호는 여전히 액티브 디렉토리에서 시작됩니다.
8:24
그녀가 거기서 암호를 변경하면 업데이트된 확인 정보가 엔트라 아이디로 동기화됩니다.
8:28
그러면 마이크로소프트 365는 읽기 가능한 암호 복사본을 저장하지 않고도 그녀의 로그인을 확인할 수 있습니다.
8:33
한 가지 소유권 규칙으로 모든 것을 명확하게 유지할 수 있습니다.
8:36
사용자가 액티브 디렉토리에서 동기화될 때 동기화 세부 정보를 편집하는 곳은 여전히 액티브 디렉토리입니다.
8:41
마야나팀 위부서 또는 직함이 변경되어야 하는 경우 액티브 디렉토리에서 변경하면
8:44
클라우드 동기화가 해당 변경사항을 엔트라 아이디로 전달합니다.
8:47
해당 클라우드 필드가 편집할 수 없도록 잠겨있는 것을 자주 보게 될 것입니다.
8:51
이는 문제가 아닙니다.
8:52
이는 계정이 어디서 오는지 알려주는 것입니다.
8:54
나중에 계획된 권한 원본 변경을 통해 소유권을 변경할 수 있지만
8:57
클라우드 동기화가 로컬 계정을 클라우드 관리 계정으로 자동 전환하지는 않습니다.
9:01
에이전트를 통해 클라우드 동기화가 더 가볍게 느껴지는 이유를 알 수 있으며
9:04
다음 부분에서는 서버 하나가 오프라인 상태가 되어도 작동이 계속되는 이유를 설명합니다.
9:08
서버 장애 시 클라우드 동기화가 계속 작동하는 방법
9:11
동기화 도구는 액티브 디렉토리에 연결할 수 있을 때만 도움이 됩니다.
9:14
월요일 아침 서버를 급히 재시작해야 하거나 예고 없이 디스크가 고장나는 상황을 떠올려 보세요.
9:19
관리자가 액티브 디렉토리에 신규 입사자를 추가했는데
9:21
마이크로소프트 365에는 그 사람이 나타나지 않습니다.
9:24
회사 한 직원의 계정을 비활성화했는데
9:26
클라우드 계정에는 변경사항이 즉시 반영되지 않습니다.
9:29
이러한 지연은 IT 부서에 실질적인 업무 부담을 줍니다.
9:31
기존의 엔트라 커넥트 설정에서는 기업들이 보통 하나의 활성 동기화 서버를 운영하고
9:35
다른 서버는 백업용으로 스테이징 모드에 둡니다.
9:38
급백업 서버는 활성 서버 장애 시인계를 위한 계획과 테스트, 명확한 절차가 필요합니다.
9:43
클라우드 싱크는 다른 방식을 취합니다.
9:45
동일한 액티브 디렉토리 도메인 내에 프로비저닝 에이전트를 하나 이상 설치할 수 있습니다.
9:49
각 에이전트는 마이크로소프트 엔트라 위 동일한 클라우드 싱크 구성에 연결되며
9:52
모두 동일한 디렉토리 정보를 읽을 수 있습니다.
9:54
특정 에이전트를 연구적인 관리자로 설정할 필요가 없습니다.
9:58
마이크로소프트 엔트라가 사용 가능한 에이전트를 감시합니다.
10:01
하나의 에이전트가 오프라인 상태가 되면
10:02
클라우드 서비스는 정상 작동 중인 다른 에이전트를 사용하여 작업을 계속합니다.
10:06
이것이 내장된 고가용성으로
10:08
한 대의 서버가 단일 장애 지점이 되는 것을 방지한다는 의미입니다.
10:12
동일한 직원 디렉터리를 사용하는 두 개의 헬프 데스크를 생각해보세요.
10:15
한 데스크가 운영을 마쳐도
10:16
다른 데스크가 전화를 받고 업무를 처리할 수 있습니다.
10:19
회사 직원들은 어느 데스크가 자신의 요청을 처리했는지 알 필요가 없습니다.
10:24
그것이 바로 실질적인 이점입니다.
10:27
대규모 로컬 동기화 엔진을 중심으로
10:28
수동 장애 조치 계획을 세우는 대신
10:30
가벼운 에이전트를 여러 개 설치하고
10:32
엔트라가 온라인 상태의 에이전트를 사용하게 하세요.
10:35
여전히 에이전트 상태를 모니터링하고
10:36
서버를 최신 상태로 유지하며 복구 계획을 테스트해야 합니다.
10:39
내장된 장애 조치 기능이 있다고 해서
10:41
책임 있는 IT 관리의 필요성이 사라지는 것은 아닙니다.
10:43
다만 한 대의 장비에 집중된 부담을 덜어줄 뿐입니다.
10:45
클라우드 싱크는 기업이 별도의 액티브 디렉토리 포리스트를 가지고 있을 때도 유용합니다.
10:49
포리스트는 독립적인 액티브 디렉토리 환경입니다.
10:52
회사가 다른 기업을 인수했을 때 이런 환경이 생길 수 있습니다.
10:55
두 회사는 서로 직접 통신할 수 없는 서로 다른 도메인, 네트워크, 개별 로컬 디렉터리를 사용할 수 있습니다.
11:02
합병 후에는 흔히 있는 일입니다.
11:04
클라우드 싱크를 사용하면 각 포리스트 근처에 에이전트를 설치할 수 있습니다.
11:08
각 에이전트는 자체 로컬 액티브 디렉토리를 읽고
11:10
동일한 마이크로소프트 엔트라 테넌트에 연결합니다.
11:13
로컬 디렉토리는 분리되어 있더라도 클라우드가 공유 목적지가 됩니다.
11:17
이 설정을 위해 포리스트 간의 직접적인 네트워크 경로는 필요하지 않습니다.
11:21
런던의 회사가 토론토의 기업을 인수했다고 가정해보세요.
11:24
양 팀 모두 동일한 마이크로소프트 365 테넌트를 사용해야 하지만
11:26
기존 디렉토리 네트워크를 연결하려면 수개월이 걸리고 보안 문제도 제기될 수 있습니다.
11:30
런던의 에이전트는 런던 계정을, 토론토의 에이전트는 토론토 계정을 동기화할 수 있습니다.
11:34
두 그룹의 사용자 모두 동일한 엔트라 아이디로 들어올 수 있습니다.
11:38
이는 팀즈, 이메일, 클라우드 앱에 대한 사용자 액세스를 차단하지 않으면
11:40
서더 큰 규모의 디렉토리 작업을 계획할 시간을 벌어줍니다.
11:43
여전히 실질적인 요구사항들이 존재합니다.
11:45
각 에이전트는 로컬 액티브 디렉토리와 안정적인 연결이 필요합니다.
11:48
또한 방화벽이나 프록시를 통해 마이크로소프트 UTMS 클라우드 서비스로 향하는 아웃바운드 액세스가 필요합니다.
11:53
이미 컴퓨터에 에이전트를 설치하고 잘 작동하기를 바랄 수는 없습니다.
11:57
지원되는 서버에 배치하고 올바른 로컬 액세스 권한을 부여하며
12:00
프로덕션 환경에서는 에이전트를 하나 이상 설치하세요.
12:02
가용성이 연결을 안정적으로 유지합니다.
12:05
하지만 어떤 계정을 연결을 통해 전송할지 결정하는 것은
12:07
무엇이 동기화되고 어떻게 제어권을 유지할지를 결정하는 것만큼 중요합니다.
12:12
클라우드 싱크가 엔트라 아이디로 계정을 이동하기 전에
12:14
동기화 범위에 포함될 대상을 정확히 결정하십시오.
12:17
범위란 클라우드 싱크가 읽고 복사할 수 있는 액티브 디렉토리 위 일부를 의미합니다.
12:21
도메인 내에 모든 지원되는 개체를 선택할 수 있는데
12:23
이는 하나의 깔끔한 디렉토리와 명확한 직원 계정 세트를 가진 소규모 기업에 적합할 수 있습니다.
12:28
대기업은 더 세심한 주의가 필요한데
12:30
액티브 디렉토리에 오래된 테스트 사용자, 서비스 계정, 교육용 계정,
12:34
마이크로소프트 365에서 보고 싶지 않은 그룹 등이 포함될 수 있기 때문입니다.
12:38
범위를 좁게 시작하면 예상치 못한 문제를 피할 수 있습니다.
12:41
클라우드 싱크를 사용하면 조직 구성 단위, OU, 나 보안 그룹별로 범위를 제한할 수 있습니다.
12:46
OU는 액티브 디렉토리 내에 레이블이 지정된 폴더와 같습니다.
12:50
예를 들어 직원, 계약직, IT 테스트 계정과 같은 OU가 있을 수 있습니다.
12:57
직원 OU만 마이크로소프트 365에 연결해야 한다면 해당 OU만 선택하면 됩니다.
13:03
그룹 기반 범위 설정은 또 다른 옵션을 제공합니다.
13:05
전체 폴더를 선택하는 대신 보안 그룹을 선택하고 테스트하려는 사용자만 추가하면 됩니다.
13:09
이 방식은 디렉토리 구조를 변경하지 않고 소규모 파일럿 테스트를 진행할 때 매우 효과적입니다.
13:13
테스트 그룹으로 시작하세요. 엔트라 아이디에 안전하게 표시될 수 있는 몇 명이 알려진 사용자를 선택하십시오.
13:18
해당 사용자의 로그인 이름, 부서 정보, 그룹 멤버십을 확인하세요.
13:21
올바른 계정이 표시되는지 확인한 다음 결과에 확신이 들면 범위를 확장하십시오.
13:24
이 작은 확인 과정이 나중에 발생할 긴 정리 작업을 방지해줍니다.
13:27
누가 동기화될지 결정한 후에는 어떤 세부 정보가 함께 전송될지 결정해야 합니다.
13:31
이를 속성 맵핑이라고 하지만 의미는 간단합니다.
13:33
액티브 디렉토리 계정에 어떤 필드가 엔트라 아이디 계정에 어떤 필드를 채울 것인가 하는 문제입니다.
13:38
사용자 레코드에는 이름, 성, 표시 이름, 전화번호, 사무실, 관리자, 부서 등이 포함될 수 있습니다.
13:44
클라우드 싱크에는 일반적인 설정을 위한 기본 맵핑이 포함되어 있습니다.
13:47
많은 경우 처음에는 이러한 기본 설정을 그대로 두는 것이 좋습니다.
13:50
이 설정들은 대부분의 기업이 필요로 하는 일반적인 필드를 다루며
13:52
결과가 잘못되었을 때 무엇이 변경되었는지 쉽게 파악할 수 있게 해줍니다.
13:55
명확한 비즈니스 이유가 있는 경우 애는 맵핑을 조정할 수 있습니다.
13:59
예를 들어 기업이 채우려는 엔트라 필드와 일치하지 않는 로컬 필드에 전화번호를 저장하는 경우가 있을 수 있습니다.
14:04
클라우드 싱크는 해당 필드를 맵핑할 수 있습니다.
14:07
또한 방대한 로컬 규칙을 만들지 않고도 값의 작은 변경을 위한 단단한 식을 지원합니다.
14:11
하지만 깔끔한 설정을 불필요하게 복잡하게 만들지는 마십시오.
14:14
아이디 프로세스가 복잡하고 독특한 논리에 의존한다면 맵핑을 변경하기 전에 해당 요구사항을 문서화하십시오.
14:20
일반적인 계정의 경우 6개월 뒤에는 아무도 이해하지 못할 복잡한 규칙보다 명확한 기본 설정이 훨씬 낫습니다.
14:24
클라우드 싱크는 광범위한 동기화를 활성화하기 전에 안전하게 테스트할 수 있는 방법을 제공합니다.
14:27
이는 주문형 프로비저닝, 프로비전 온 디맨드 이라는 기능을 자동화합니다.
14:30
사용자 한 명을 선택하고 클라우드 싱크에게 이 계정을 어떻게 처리할 것인가? 라고 물어볼 수 있습니다.
14:34
결과를 통해 에이전트가 사용자를 찾았는지, 사용자가 범위 내에 있는지, 엔트라 아이디가 일치하는 계정을 찾았는지, 그리고 클라우드 싱크가 이를 생성하거나 업데이트할지 여부를 확인할 수 있습니다.
14:43
다른 모든 사람에게 영향을 주기 전에 해당 결정을 미리 볼 수 있는 것입니다.
14:46
IT팀이 클라우드 싱크 테스트라는 파일럿 그룹을 만든다고 가정해보겠습니다.
14:49
누군가 실수로 그 안에 더 큰 그룹을 추가했고, 그 더 큰 그룹에는 수백 명의 직원이 포함되어 있습니다.
14:55
주문형 프로비저닝은 수백 개의 계정이 테넌트에 나타난 이후가 아니라, 팀이 한 명을 테스트하는 동안 범위 문제를 노출시켜줍니다.
15:01
제게 있어 그것은 초기에 발견해야 할 종류의 실수입니다.
15:04
클라우드 싱크에는 실수로 인한 삭제 방지 기능도 포함되어 있습니다.
15:08
구성 설정이 갑자기 많은 수의 사용자나 그룹을 제거하려고 하면, 서비스가 실행을 중단하고, 해당 손상이 엔트라 아이디에 바로 복사되지 않도록 구성을 격리 상태로 전환할 수 있습니다.
15:16
관리자는 경고를 받고 상황을 조사할 수 있습니다.
15:19
엔트라 포털은 프로비저닝 로그도 제공합니다.
15:21
사용자를 검색하면 무슨 일이 일어났는지, 개체가 일치했는지, 특정 필드에서 오류가 발생했는지, 에이전트가 연결되었는지, 그리고 구성이 정상 상태를 유지하는지 확인할 수 있습니다.
15:30
아이디 동기화가 잘 작동할 때는 아주 조용하게 진행됩니다.
15:33
문제가 발생하면 그 로그들이 무엇을 확인해야 할지 알려줌으로 추측할 필요가 없습니다.
15:37
클라우드 싱크는 이제 더 광범위한 요구사항을 지원하지만, 모든 엔트라 커넥트 설정을 대체해야 한다는 의미는 아닙니다.
15:42
클라우드 싱크와 엔트라 커넥트, 그리고 2026년의 변화에 대해 생각해보아야 합니다.
15:47
그렇다면 모든 기업이 엔트라 커넥트에서 클라우드 싱크로 전환해야 할까요?
15:50
아니요. 클라우드 싱크가 더 최신 기술이지만, 최신이라고 해서 반드시 귀하의 환경에 적합한 것은 아닙니다.
15:54
올바른 선택은 어떤 제품이 더 현대적으로 보이는가가 아니라, 현재 귀하의 아이디 시스템이 무엇을 수행해야 하는지에 달려있습니다.
16:00
클라우드 싱크는 더 간단한 로컬 설정과 클라우드 관리형 동기화 설정을 원하는 기업에 적합합니다.
16:04
액티브 디렉토리 위 사용자, 그룹, 연락처를 주로 엔트라 아이디에 표시해야 할 때 효과적입니다.
16:09
또한 각 지점을 로컬 네트워크로 통합하지 않고도, 동일한 엔트라 테넌트에 연결할 수 있는 별도의 포리스트를 가진 기업에도 적합합니다.
16:16
그룹 기반 범위 지정 기능도 제공합니다.
16:18
특정 사업부, 신규 사무소 또는 소규모 사용자 집합을 먼저 도입하려 할 때 유용할 수 있습니다.
16:24
엔트라 포털에서 동기화 설정을 유지하고, 에이전트를 모니터링할 수 있으며, 중앙 서버에서 대규모 동기화 엔진을 실행할 필요가 없습니다.
16:30
엔트라 커넥트도 여전히 필요한 영역이 있습니다. 일부 기업은 통과 인증이나 패더레이션과 같이 클라우드 싱크가 동일한 방식으로 지원하지 않는 로그인 방식에 의존합니다.
16:39
통과 인증은 사용자가 로그인하는 순간 액티브 디렉토리에서 비밀번호를 확인합니다.
16:43
패더레이션은 로그인 요청을 기업이 이미 사용 중인 다른 아이디 시스템으로 전송합니다.
16:48
이러한 설정에는 신중한 계획이 필요합니다.
16:50
엔트라 커넥트는 고급 로컬 동기화 규칙이 필요한 기업에도 적합합니다.
16:54
특이한 필드에 데이터를 결합하거나, 상세한 필터링 논리를 적용하거나, 수년간 구축해온 기존의 사용자 지정 규칙에 의존하는 경우입니다.
17:01
모든 규칙을 확인하지 않고 더 간단한 도구로 교체하면 문제가 발생할 수 있습니다.
17:05
익스체인지 하이브리드 구성도 선택에 영향을 줄 수 있습니다.
17:07
기업은 익스체인지 온라인을 사용하면서도 익스체인지 위 일부를 로컬에서 운영할 수 있습니다.
17:11
일부 익스체인지 작업은 세부 정보를 액티브 디렉토리에 다시 기록해야 합니다.
17:15
그래야 마이크로소프트 365와 익스체인지 설정 간에 메일 관련 정보가 일치하게 유지됩니다.
17:19
기하의 정확한 익스체인지 설정에 따라 클라우드 싱크가 필요한 기능을 지원하는지 여부가 결정됩니다.
17:23
그 결정은 2026년에 바뀌었습니다.
17:26
이제 클라우드 싱크에 하이브리드 엔트라 아이디 조인을 위한 장치 동기화가 포함됩니다.
17:29
이는 회사 윈도우즈 장치가 로컬 액티브 디렉토리에 속해 있으면서도,
17:32
클라우드 액세스 및 관리를 위해 엔트라 아이디 위 아이디가 필요한 경우에 중요합니다.
17:35
많은 기업에서 장치 동기화 때문에 엔트라 커넥트를 계속 사용해왔습니다.
17:39
이제 클라우드 싱크 도의 요구사항을 처리할 수 있게 되어,
17:41
일부 팀이 고려조차 할 수 없었던 이유 하나가 사라졌습니다.
17:44
여전히 장치 설정, 윈도우즈 계획, 인튠 사용 방식을 확인해야 하지만,
17:48
이제 선택 기준이 사용자 및 그룹에만 국한되지 않습니다.
17:50
마이크로소프트는 또한 공개 미리 보기로 익스체인지 하이브리드 특성 쓰기 기능을 추가했습니다.
17:54
쉽게 말해, 클라우드 싱크가 이제 특정 익스체인지 관련 세부 정보를 클라우드에서 액티브 디렉토리로 다시 보낼 수 있게 되었습니다.
18:00
공개 미리 보기는 마이크로소프트가 해당 기능을 정식 출시하기 전에 실제 사용 사례와 피드백을 수집하는 단계이므로,
18:05
오랫동안 사용된 기능보다 더 신중하게 다뤄야 합니다.
18:08
제품 업데이트의 한 문장만 보고 익스체인지 설정을 자동으로 이전하지 마십시오.
18:12
최신 마이크로소프트 설명서를 읽고, 비프로덕션 계정으로 테스트하며,
18:16
회사에 필요한 정확한 속성을 확인하십시오.
18:18
익스체인지에는 아이디 세부 정보가 일치하지 않을 때 매우 영격하게 반응할 수 있습니다.
18:22
클라우드 동기화는 익숙한 안전 제어 기능을 포털로 가져옵니다.
18:25
암호 회시 동기화를 사용할 수 있습니다.
18:27
문제가 발생했을 때 담당자에게 전달되도록 알림을 설정할 수 있습니다.
18:30
실수로 삭제되는 것을 방지하는 보호 기능을 설정할 수 있습니다.
18:33
로컬 동기화 서버를 모든 것의 중심으로 다루는 대신 엔트라에서 구성을 관리할 수 있습니다.
18:38
두 도구의 지원 범위가 점점 비슷해지고 있습니다.
18:40
그렇더라도 클라우드 동기화가 모든 회사의 엔트라 커넥트를 즉시 대체할 수 있는 것은 아닙니다.
18:44
이 선택을 차량 선택에 비유해 생각해보십시오.
18:47
소형 밴은 운전과 주차가 쉬워 지역 배달 경로에 적합할 수 있습니다.
18:51
대형 트럭은 밴이 실을 수 없는 짐을 운반할 수 있어 다른 업무에 적합합니다.
18:55
어느 쪽도 틀린 선택은 아닙니다.
18:56
결정을 내리기 전에 몇 가지 직접적인 질문을 던져보십시오.
18:59
액티브 디렉토리 포리스트가 하나입니까? 아니면 연결되지 않은 여러 포리스트입니까?
19:02
하이브리드 장치 동기화가 필요합니까? 고급 사용자 지정 규칙에 의존하고 있습니까?
19:06
어떤 로그인 방법을 사용합니까?
19:07
익스체인지 S기 저장, 나이트백이 필요합니까?
19:10
현재 동기화 서비스가 실패하면 얼마나 빨리 복구할 수 있습니까?
19:13
답변을 기록해두십시오.
19:14
최종 결정은 한꺼번에 마이그레이션 하는 방식으로 시작해서는 안됩니다.
19:17
클라우드 동기화가 실제 계정과 실제 요구사항을 처리할 수 있음을 증명하는 작고 통제된 테스트부터 시작해야 합니다.
19:23
회사를 위한 안전한 첫걸음입니다.
19:26
간단한 아이디 맵을 그리는 것부터 시작하십시오.
19:28
모든 액티브 디렉토리 포리스트와 도메인을 나열하십시오.
19:31
이미 엔트라 커넥트를 실행 중인지, 현재 어떤 사용자가 동기화되는지, 어떤 장치의 하이브리드 아이디가 필요한지,
19:35
그리고 메일 시스템이 로컬 액티브 디렉토리에 의존하는 부분이 어디인지 기록하십시오.
19:38
단순하게 유지하십시오.
19:39
그런 다음 비하의 요구사항을 현재 클라우드 동기화 지원 범위와 비교하십시오.
19:42
가장 먼저 로그인 방법을 확인하십시오.
19:44
익스체인지 요구사항을 확인하십시오.
19:45
장치, 쓰기, 저장, 그리고 누군가 수년 전에 설정해두고 아무도 확인하지 않은 모든 사용자 지적 맵핑을 확인하십시오.
19:50
이 목록은 숨겨진 중속성을 드러낼 수 있습니다.
19:52
클라우드 동기화가 적합하다면 프로덕션 환경에 최소 2개의 프로비저닝 에이전트를 설치하십시오.
19:56
랩 환경에서는 에이전트 하나로 충분할지 모르지만,
19:59
피할 수 있다면 프로덕션 아이디 동기화를 서버 한 대에만 이종해서는 안 됩니다.
20:02
그 다음에는 좁은 범위의 구성을 구축하십시오.
20:04
테스트용 조직 구성단이나 소규모 보안 그룹을 선택하십시오.
20:07
변경해야 할 명확한 이유가 없다면 기본 맵핑을 사용하십시오.
20:10
그런 다음 알려진 사용자를 선택하고 일반 동기화를 활성화하기 전에 주문형 프로비저닝을 실행하십시오.
20:14
결과를 주의 깊게 읽어보십시오.
20:16
엔트라가 올바른 사용자를 찾고 예상한 계정을 생성하며 필요한 필드를 전송하는지 확인하십시오.
20:21
포털로그도 함께 확인하십시오.
20:22
상태가 녹색이라고 해서 비즈니스 규칙이 정상 작동한다는 것을 보장하지는 않기 때문입니다.
20:26
이동 중에 발생하는 한 가지 경고는 중요합니다.
20:29
다음과 같이 가정하지 마십시오.