Latest / M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어) / Microsoft Entra Domain Services 쉽게 설명: 자체 도메인 컨트롤러 없이 레거시 앱을 Azure로 (AI 더빙)

Transcript

Microsoft Entra Domain Services 쉽게 설명: 자체 도메인 컨트롤러 없이 레거시 앱을 Azure로 (AI 더빙) · M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어)

• 0:00
  마이크로소프트 365, 코파일럿, AI, 에이저, 그리고 이래 미래를 만들어가는 사람들과 함께하는 10일간의 여정을 준비되셨나요?
• 0:08
  오는 1월, M365 컨퍼런스가 더 커진 규모로 돌아옵니다.
• 0:12
  전세계 MVP와 업계 전문가들이 선보이는 라이브 세션, 실무 데모, 그리고 실용적인 지식을 만나보세요.
• 0:18
  헌한 슬라이드는 없습니다. 끝없는 유행어 나열도 없습니다.
• 0:22
  코파일럿 스튜디오, AI 에이전트, 패브릭, 보안, 거버넌스, 자동화 등 실질적인 과제들을 다룹니다.
• 0:29
  IT 전문가, 개발자, 비즈니스 리더 등 누구든 자신에게 맞는 세션을 찾을 수 있습니다.
• 0:35
  10일 동안 다양한 기술을 탐구하고 전세계 커뮤니티와 연결될 수 있습니다.
• 0:40
  라이브로 시청하고 조직에 바로 적용할 수 있는 실무 인사이트를 얻어가세요.
• 0:45
  2027년 1월, 10일간의 여정, 하나의 마이크로소프트 커뮤니티, 지금 등록이 시작되었습니다.
• 0:51
  M365 con.net에 접속하여 오늘 바로 자리를 확보하세요.
• 0:55
  다시 한번 M365 con.net입니다.
• 0:59
  지금 M365 con.net에서 등록하고 1월 라이브 행사에서 뵙겠습니다.
• 1:04
  여러분, 안녕하세요.
• 1:06
  M365 FM 위 또 다른 마이크로소프트 지식 한 조각 에피소드에 오신 것을 환영합니다.
• 1:10
  저는 미르코 피터스입니다.
• 1:11
  사무실 서버에 있던 오래된 비즈니스 앱을 에이저 가상 머신으로 옮겼다고 상상해보세요.
• 1:16
  앱은 이제 클라우드에 있지만 여전히 윈도우즈 도메인을 요구합니다.
• 1:19
  도메인에 가입하고 LDAP을 통해 사람을 찾고 커버로스로 로그인하며 그룹 정책을 적용하려 합니다.
• 1:24
  대부분의 사람들은 엔트라 아이디가 액티브 디렉토리 위 모든 역할을 대체한다고 생각합니다.
• 1:28
  그렇지 않습니다.
• 1:29
  최신 클라우드 앱은 엔트라 아이디를 통해 로그인할 수 있지만,
• 1:32
  구형 윈도우즈 앱은 여전히 서버실에서 사용하던 것과 동일한 도메인을 기대합니다.
• 1:36
  이번 에피소드가 끝날 때 쯤이면 엔트라 아이디, 액티브 디렉토리,
• 1:39
  엔트라 도메인 서비시즈가 각각 어디에 적합한지,
• 1:42
  그리고 관리에 변화를 주는 한 가지 세부사항을 알게 되실 겁니다.
• 1:44
  아이디 정보는 한 방향으로만 이동합니다.
• 1:46
  왜 엔트라 아이디만으로는 모든 레거시 앱을 실행할 수 없는지 알아보겠습니다.
• 1:50
  엔트라 아이디가 잘하는 것부터 시작해보죠.
• 1:52
  엔트라 아이디는 클라우드 서비스의 안내데스크와 같습니다.
• 1:55
  여러분이 누구인지 확인하고 로그인을 검사하며,
• 1:57
  마이크로소프트 365팀즈, 시어포인트 또는 클라우드 비즈니스 앱에 접근할 수 있는지 결정합니다.
• 2:02
  한 번 로그인하면 비밀번호를 계속 입력할 필요 없이 서비스 간을 이동할 수 있습니다.
• 2:06
  그것이 바로 싱글사인온 SSO입니다.
• 2:08
  엔트라 아이디는 다중인증을 통해 2차 로그인 확인을 요청할 수 있으며,
• 2:12
  사용 중인 기기, 접속 위치, 그리고 회사가 설정한 접근 규칙을 검토합니다.
• 2:17
  최신 앱의 경우 이러한 패턴은 매우 효과적입니다.
• 2:20
  브라우저를 열면 앱이 여러분을 엔트라 아이디로 보내고,
• 2:23
  로그인을 완료하고, 휴대폰에 알림을 승인하면,
• 2:25
  엔트라 아이디가 앱에 보안 로그인 메시지를 전송합니다.
• 2:28
  앱은 그 메시지를 읽고 여러분을 들여보내 줍니다.
• 2:30
  이 패턴을 사용하면 도메인 가입이 필요 없고,
• 2:33
  구형 윈도우즈 서버도 필요 없으며,
• 2:35
  앱이 기존 회사 디렉터리를 검색할 필요도 없습니다.
• 2:37
  하지만 더 오래된 앱들은 다른 환경에서 개발되었습니다.
• 2:39
  수년 동안 윈도우즈 서버에서 실행되었고,
• 2:42
  사용자가 도메인에 가입된 PC에서 로그인하는 재무앱을 상상해보세요.
• 2:45
  이 앱은 LDAP을 통해 직원 정보를 조회하는데,
• 2:47
  이는 구형 소프트웨어가 회사 디렉터리를 검색하는 일반적인 방식입니다.
• 2:50
  이 앱은 시스템 간의 신뢰를 가능하게 하는
• 2:52
  오래된 윈도우즈 로그인 방식인 커버로스를 사용할 수도 있습니다.
• 2:55
  또한 윈도우즈 컴퓨터의 설정을 제어할 수 있는
• 2:57
  회사 규칙 세트인 그룹 정책에 위존할 수도 있습니다.
• 3:00
  해당 앱은 최신 클라우드 로그인 메시지를 읽는 방법을 모릅니다.
• 3:03
  앱은 네트워크를 통해 호출을 보내 전통적인 윈도우즈 도메인을 찾으려 합니다.
• 3:07
  만약 찾지 못하면 앱은 사용자 로그인에 실패하거나,
• 3:09
  서비스 계정을 찾지 못하거나, 단순히 실행을 거부할 수 있습니다.
• 3:12
  여러분은 아마도 IT 분야 밖에서도 이런 패턴을 보셨을 겁니다.
• 3:15
  오래된 기기에 플러브가 맞지 않으면 새로운 전원 콘센트는 아무 소용이 없습니다.
• 3:18
  전기는 들어오지만 연결 방식이 잘못된 것이죠.
• 3:21
  이제 회사가 해당 재무 앱과 데이터베이스를
• 3:22
  에이저 가상 머신으로 옮기는 상황을 그려보세요.
• 3:24
  서버는 이동했지만 기존의 요구사항은 그대로입니다.
• 3:27
  액티브 디렉토리를 사무실에 그대로 두고 VPN이라는 전용 네트워크 터널을 통해
• 3:31
  에이저와 다시 연결할 수 있습니다.
• 3:33
  그렇게 하면 에이저 위 앱은 도메인이 필요할 때마다 그 연결을 통해 요청을 보냅니다.
• 3:37
  작동할 수는 있지만, 이제 앱은 네트워크 링크와 온 프레미스 도메인 컨트롤러의 가용성에 의존하게 됩니다.
• 3:42
  만약 그 연결에 문제가 생기면, 클라우드의 매도 문제가 발생할 수 있습니다.
• 3:46
  또 다른 선택은 에이저의 자체 도메인 컨트롤러 가상 머신을 만드는 것입니다.
• 3:49
  도메인 컨트롤러는 전통적인 액티브 디렉토리 도메인을 실행하며 디렉터리, 로그인 및 기타 도메인 작업을 처리하는 서버입니다.
• 3:55
  이 방법도 작동하지만, 이제 여러분의 팀이 관리해야 할 서버가 늘어납니다.
• 3:58
  누군가는 서버에 패치를 적용하고 모니터링해야 합니다.
• 4:01
  백업, 복구 계획, 도메인 컨트롤러 동기화 계획이 필요하며, 도메인을 제어하는 강력한 관리자 계정도 보호해야 합니다.
• 4:07
  일부 기업에게는 이러한 통제권이 합리적일 수 있습니다.
• 4:09
  다른 기업들에게는 단지 오래된 앱을 유지하기 위한 추가적인 작업일 뿐입니다.
• 4:12
  결국 그 격차는 매우 좁지만 분명히 존재합니다.
• 4:15
  앱은 에이저에 있지만, 여전히 오래된 액티브 디렉토리 언어를 사용하고 있습니다.
• 4:19
  마이크로소프트 엔트라 도메인 서비시즈란 무엇인가?
• 4:21
  마이크로소프트 엔트라 도메인 서비시즈는 에이저 네트워크 내부에서 실행되는 관리형 윈도우즈 도메인입니다.
• 4:26
  이것이 쉬운 말로 정의한 내용입니다.
• 4:28
  도메인 컨트롤러는 백그라운드에서 실행되어 마이크로소프트가 완전히 관리하며,
• 4:32
  사용자의 에이저 가상 머신과 기존 앱은 익숙한 도메인 서비스를 그대로 사용합니다.
• 4:36
  클라우드 설정을 사무실 건물이라고 생각해보세요.
• 4:38
  엔트라 아이디는 앞쪽의 안내 데스크입니다.
• 4:41
  사용자가 마이크로소프트 365나 다른 클라우드 앱에 로그인할 때 신원을 확인하고,
• 4:44
  해당 로그인에 대한 회사 규칙을 적용합니다.
• 4:46
  엔트라 도메인 서비시즈는 잠긴 뒤쪽 사무실에 위치합니다.
• 4:49
  기존 시스템은 최신 클라우드 앱처럼 안내 데스크를 방문할 필요가 없습니다.
• 4:53
  이들에게는 언어를 이해하고 요청에 응답할 수 있는 가까운 곳의 구식 디렉터리가 필요합니다.
• 4:57
  그 뒤쪽 사무실이 바로 관리형 도메인입니다.
• 4:59
  핵심은 이렇습니다.
• 5:00
  도메인 컨트롤러를 직접 구축할 필요가 없습니다.
• 5:03
  원격 데스크톱으로 로그인할 필요도 없습니다.
• 5:05
  몇 대를 실행할지 결정하거나, 윈도우즈 패치를 적용하거나, 연결을 관리할 필요가 없습니다.
• 5:08
  마이크로소프트가 모든 것을 처리합니다.
• 5:10
  사용자의 역할은 적절한 에이저 가상 머신과 앱을 관리형 도메인에 연결하는 것뿐입니다.
• 5:14
  연결되면 익숙한 액티브 디렉터리 서비스를 사용할 수 있습니다.
• 5:17
  윈도우즈 VM은 도메인에 가입할 수 있고, 기존 앱은 LDAP를 사용하여 사람, 그룹 및 디렉터리 세부 정보를 조회할 수 있습니다.
• 5:23
  또한 한 서버가 다른 서버를 신뢰해야 할 때, 기존 비즈니스 앱이 자주 요구하는 로그인 방식인 커버로스를 사용할 수 있습니다.
• 5:29
  일부 앱에서 여전히 필요한 또 다른 구형 윈도우즈 로그인 방식인 ntlm도 사용할 수 있습니다.
• 5:33
  관리형 도메인은 dns도 제공함으로, 시스템이 숫자 문자열 대신 이름으로 올바른 서버를 찾을 수 있도록 돕습니다.
• 5:39
  또한 그룹 정책을 지원함으로, 관리형 도메인의 컴퓨터와 사용자에게 특정 윈도우즈 설정을 적용할 수 있습니다.
• 5:44
  기술적인 내용이라 어렵게 들릴 수 있습니다.
• 5:46
  대신 번역 데스크라고 상상해보세요.
• 5:48
  앱이 구형 윈도우즈 언어로 묻습니다.
• 5:50
  이 사용자는 누구인가요?
• 5:52
  이 서버가 저 서버를 신뢰할 수 있나요?
• 5:54
  데이터베이스는 어디에 있나요?
• 5:56
  이 컴퓨터는 어떤 설정을 사용해야 하나요?
• 5:58
  엔트라 도메인 서비시즈는 이러한 질문을 이해하고 앱이 기대하는 유형의 답변을 제공하지만,
• 6:02
  두 번째 직원 목록을 생성하지는 않습니다.
• 6:04
  기본 아이디 레코드는 엔트라 아이디에 유지됩니다.
• 6:07
  엔트라 아이디 위 사용자 및 그룹이 관리형 도메인으로 복사되므로,
• 6:10
  기존 앱은 이해할 수 있는 형식으로 이를 확인하고 사용할 수 있습니다.
• 6:12
  회사에 온 프레미스 액티브 디렉토리 가 있는 경우,
• 6:15
  해당 아이디가 도메인 서비시즈로 복사되기 전에 이미 엔트라 아이디에 도달했을 수 있습니다.
• 6:18
  여기서는 방향이 중요합니다.
• 6:20
  아이디 세부 정보는 엔트라 도메인 서비시즈로 흘러들어갑니다.
• 6:23
  다시 밖으로 흘러나오지는 않습니다.
• 6:25
  따라서 사용자가 엔트라 아이디에서 온 경우,
• 6:26
  해당 사용자는 엔트라 아이디에서 관리합니다.
• 6:28
  사용자가 원래 온 프레미스 액티브 디렉토리에서 온 경우,
• 6:31
  해당 위치에서 사용자를 관리하면 됩니다.
• 6:33
  도메인 서비시즈를 주 직원 기록을 수정하는 곳으로 취급해서는 안 됩니다.
• 6:36
  그래야 관리형 도메인이 동일 인물에 대한 서로 다른 버전이 담긴 또 다른 서류함이 되는 것을 막을 수 있습니다.
• 6:41
  설정 과정에서 많은 사람이 어려움을 겪는 부분이 하나 있는데, 바로 암호입니다.
• 6:45
  최신 클라우드 로그인과 이전 윈도우즈 로그인은 내부적으로 암호를 사용하는 방식이 정확히 같지 않습니다.
• 6:50
  커버로스와 ntlm이 작동하려면 도메인 서비시즈는 해당 구형 방식을 지원하는 보호된 형태의 암호 데이터가 필요합니다.
• 6:55
  마이크로소프트는 사용자의 암호를 일반 텍스트로 절대 보관하지 않습니다.
• 6:58
  대신 사용자가 관리형 도메인을 통해 도메인 가입 VM이나 구형 앱에 로그인하려면 서비스에 올바른 보호된 암호 정보가 있어야 합니다.
• 7:06
  클라우드 전용 사용자의 경우 도메인 서비시즈를 활성화한 후 암호를 변경해야 하는 경우가 많습니다.
• 7:12
  그 암호 변경을 통해 관리형 도메인에 필요한 보호된 형태가 생성됩니다.
• 7:15
  그 전까지는 사용자가 마이크로소프트 365에는 문제없이 로그인하더라도 구형 도메인 방식 사용 시에는 실패할 수 있습니다.
• 7:22
  처음에는 이상하게 느껴질 수 있습니다.
• 7:24
  이미 계정도 있고 암호도 정상적으로 작동하는데 레거시 앱에서는 사용할 수 없기 때문입니다.
• 7:29
  누락된 조각은 사용자 계정이 아닙니다.
• 7:31
  구형 로그인 방식에 필요한 보호된 암호 형태입니다.
• 7:34
  도메인 서비시즈는 또한 작동 범위에 대한 명확한 경계가 있습니다.
• 7:37
  이 서비스는 흔히 vnet이라고 불리는 에이저 가상 네트워크 내에서 실행됩니다.
• 7:41
  에이저 VM은 해당 vnet에 네트워크로 액세스해야 하며 서비스를 찾을 수 있도록 관리형 도메인의 dns 설정을 사용해야 합니다.
• 7:47
  이것은 인터넷 상의 모든 장치가 접근할 수 있는 공개 디렉터리가 아닙니다.
• 7:50
  올바른 에이저 네트워크에 연결된 워크로드를 위한 프라이빗 도메인 서비스입니다.
• 7:54
  따라서 앱이 에이저에서 기존 액티브 디렉터리 동작을 필요로 할 때 도메인 서비시즈는 해당 동작을 찾을 수 있는 관리형 환경을 제공합니다.
• 8:00
  이제 다음 질문으로 넘어가겠습니다.
• 8:02
  이것은 엔트라 아이디 및 기존 액티브 디렉터리 도메인과 어떤 관계가 있을까요?
• 8:06
  이름은 비슷하게 들리지만 수행하는 역할은 매우 다릅니다.
• 8:09
  엔트라 아이디, 액티브 디렉터리, 그리고 도메인 서비시즈 각기 다른 업무를 수행합니다.
• 8:13
  이름이 비슷해서 동일한 제품의 서로 다른 버전으로 생각하기 쉽습니다.
• 8:17
  하지만 그렇지 않습니다.
• 8:19
  각각은 회사의 아이디 환경에서 서로 다른 부분을 담당하며 각자의 역할을 이해하면 선택이 훨씬 명확해집니다.
• 8:24
  엔트라 아이디는 클라우드 아이디를 담당합니다.
• 8:26
  마이크로소프트 365, 팀즈, 셰어포인트 또는 최신 비즈니스 앱을 열 때 엔트라 아이디가 로그인을 확인하고 액세스 권한을 제어합니다.
• 8:33
  또한 다중인증과 액세스 규칙을 지원하여 알 수 없는 장치에서 작업할 때 더 강력한 로그인 확인을 요구하기도 합니다.
• 8:39
  이것은 클라우드 서비스를 위해 구축되었습니다.
• 8:42
  최신 앱은 웹기반 로그인 방식을 사용함으로 엔트라 아이디와 동일한 네트워크에 있을 필요가 없습니다.
• 8:47
  브라우저 나앱을 통해 로그인하면 엔트라 아이디가 사용자 본인임을 확인하고 앱은 액세스 권한이 있다는 증명을 받습니다.
• 8:53
  이것이 새로운 클라우드 앱의 일반적인 패턴입니다.
• 8:55
  흔히 액티브 디렉토리로 줄여 부르는 액티브 디렉토리 도메인 서비시즈는 다른 역할을 수행합니다.
• 9:00
  이는 많은 기업이 사무실, 데이터센터 또는 서버실에서 운영하는 전통적인 윈도우즈 도메인입니다.
• 9:05
  기업이 도메인 컨트롤러를 소유하고 설정 방식을 선택하며 도메인 전체를 처음부터 끝까지 관리합니다.
• 9:10
  윈도우즈 PC를 제어하고 로컬 서버를 지원하며 오랫동안 사용된 비즈니스 앱에 필요한 구형 로그인 방식을 제공할 수 있습니다.
• 9:16
  그러한 수준의 제어에는 책임이 따릅니다.
• 9:18
  IT팀이 도메인을 운영하고 서버를 관리하며 기업을 위해 디렉토리가 어떻게 작동해야 할지 결정합니다.
• 9:24
  엔트라 도메인 서비시즈는 이 두세 개의 중간에 위치합니다.
• 9:27
  기존 액티브 디렉토리 동작이 필요한 에이저 워크로드의 관리형 윈도우즈 도메인을 제공하되 도메인 컨트롤러 측면은 마이크로소프트가 운영합니다.
• 9:34
  전통적인 액티브 디렉토리 도메인을 직접 운영하는 전체적인 업무를 수행하지 않고도 에이저 VM과 구형 앱을 위해 도메인을 사용할 수 있습니다.
• 9:40
  파일 캐비닛 시스템이라고 생각하면 됩니다.
• 9:43
  엔트라 아이디는 클라우드 업무를 위한 주요 직원 기록을 보유합니다.
• 9:46
  그곳은 마이크로소프트 365 및 최신 클라우드 로그인에 사용되는 업무용 기록을 보관하는 장소입니다.
• 9:50
  도메인 서비시즈는 구형 에이저 앱에 필요한 호환 가능한 기록 사본을 제공합니다.
• 9:55
  해당 앱들은 익숙한 유형의 파일 캐비닛을 열어 사용자가 이해하는 이전 형식으로 사용자, 그룹 및 로그인 세부 정보를 찾을 수 있습니다.
• 10:01
  에이저로 이동했다는 이유만으로 앱을 다시 빌드할 필요는 없습니다.
• 10:04
  클라우드 전용 기업도의 설정을 사용할 수 있습니다.
• 10:07
  로컬 도메인 컨트롤러를 한 번도 운영해본 적이 없는 기업을 상상해보십시오.
• 10:10
  모든 직원이 엔트라 아이디를 통해 마이크로소프트 365에 로그인하고, 비즈니스상 구형 윈도우즈 앱을 위해 에이저 VM을 사용하기 시작합니다.
• 10:16
  그 기업은 단순히 해당 앱 하나를 위해 온 프레미스 액티브 디렉토리 도메인을 구축할 필요가 없습니다.
• 10:21
  대신 도메인 동작이 필요한 에이저 VM에는 엔트라 도메인 서비시즈를 사용하고, 나머지 기업 업무는 일반적인 클라우드 업무를 위해 엔트라 아이디를 계속 사용할 수 있습니다.
• 10:28
  하이브리드 기업은 시작 지점이 다릅니다.
• 10:30
  이미 사무실에서 액티브 디렉토리를 운영하며 사용자 및 그룹을 엔트라 아이디로 동기화하고 있을 수 있습니다.
• 10:35
  그러면 해당 사용자들이 에이저에서 실행되는 워크로드를 위해 엔트라 도메인 서비시즈에 나타날 수 있습니다.
• 10:39
  흐름은 다음과 같습니다.
• 10:41
  기업의 기존 액티브 디렉토리가 아이디 세부 정보를 엔트라 아이디로 보내고, 엔트라 아이디는 호환 가능한 사본을 도메인 서비시즈에 제공합니다.
• 10:48
  그렇다고 해서 도메인 서비시즈가 원래 온 프레미스 도메인을 대체한다는 의미는 아닙니다.
• 10:52
  사무실에서는 여전히 로컬 PC, 서버, 공장 시스템 또는 사내에 유지되는 애플리케이션을 위한 자체 액티브 디렉토리 도메인이 필요할 수 있습니다.
• 10:59
  도메인 서비시즈는 관리형 구식 도메인 동작이 워크로드에 적합한 에이저 영역만을 처리합니다.
• 11:04
  또한 엔트라 아이디를 완전한 액티브 디렉토리로 바꿔주지도 않습니다.
• 11:07
  엔트라 아이디는 그대로 클라우드 아이디 서비스로 남습니다.
• 11:10
  도메인 서비시즈는 특정 구식 요구사항을 위해 관리형 도메인을 추가하지만,
• 11:14
  직접 액티브 디렉토리를 운영할 때와 같은 모든 옵션이나 제어 수준을 제공하지는 않습니다.
• 11:18
  그러니 세 가지의 별도 작업을 떠올려 보세요.
• 11:21
  엔트라 아이디는 최신 클라우드 로그인을 처리합니다.
• 11:23
  액티브 디렉토리는 귀사가 직접 운영하는 윈도우즈 도메인을 처리합니다.
• 11:27
  엔트라 도메인 서비시즈는 도메인 컨트롤러를 직접 운영할 필요 없이
• 11:30
  윈도우즈 도메인을 여전히 필요로 하는 기존 에이저 워크로드를 처리합니다.
• 11:33
  훨씬 더 나은 질문을 던질 수 있습니다.
• 11:36
  도메인 서비시즈는 언제 워크로드에 적합하며, 언제 다른 것을 선택해야 할까요?
• 11:40
  도메인 서비시즈가 적합한 때와 그렇지 않은 때입니다.
• 11:43
  제품 이름이 아닌 앱에서부터 시작하세요.
• 11:45
  오래된 앱이 사용자 이름과 암호를 확인하는 구식 언어인 LDAP을 사용하고
• 11:48
  이를 에이저로 옮기려 한다면 도메인 서비시즈가 매우 적합할 수 있습니다.
• 11:52
  앱은 전체를 다시 작성할 필요 없이 이미 이해하고 있는 방식을 그대로 사용할 수 있습니다.
• 11:56
  이는 앱이 여전히 잘 작동하고 비즈니스에 필요하며,
• 11:58
  로그인 코드를 다시 작성하는 데 드는 시간이나 비용이 너무 클 때 중요한 문제입니다.
• 12:01
  또 다른 흔한 시나리오는 에이저 가상 머신 그룹이 일반 도메인 컴퓨터처럼 작동해야 하는 경우입니다.
• 12:06
  직원들이 업무용 계정으로 윈도우즈에 로그인해야 할 수도 있습니다.
• 12:09
  서비스에는 데이터베이스와 같은 다른 시스템에 연결하기 위해
• 12:12
  앱이 사용하는 계정인 서비스 계정이 필요할 수 있습니다.
• 12:14
  해당 가상 머신에 회사 설정을 적용하려면 그룹 정책이 필요할 수도 있습니다.
• 12:18
  이러한 경우 도메인 서비시즈는 에이저 머신에 필요한 도메인 동작을 제공합니다.
• 12:22
  원격 데스크톱 서비스도 여기에 해당합니다.
• 12:25
  직원들이 에이저 위 공유 윈도우즈 데스크톱이나 앱에 연결하는 상황을 생각해보세요.
• 12:29
  이러한 시스템은 종종 사용자 로그인 및 컴퓨터 관리를 위해 윈도우즈 도메인에 위존합니다.
• 12:33
  도메인 서비시즈는 팀이 도메인 컨트롤러 가상 머신을 처음부터 구축하지 않고도 해당 도메인 계층을 제공합니다.
• 12:39
  구형 앱은 종종 하나 이상의 부분으로 구성됩니다.
• 12:41
  앞단에는 웹서버, 중간에는 앱서버, 뒷단에는 데이터베이스가 있을 수 있습니다.
• 12:45
  앱서버는 데이터베이스가 연결을 수락하기 전에 자신의 신원을 증명해야 합니다.
• 12:49
  이러한 신뢰관계가 윈도우즈 서비스 계정에 위존하는 경우
• 12:52
  도메인 서비시즈는 이전 후에도 해당 연결이 계속 작동하도록 유지합니다.
• 12:55
  핵심은 이렇습니다.
• 12:56
  팀은 워크로드에 필요한 구식 도메인 동작을 얻고
• 12:58
  마이크로소프트는 그렇지 않으면
• 13:00
  비하의 서버 목록에 부담이 되었을 도메인 컨트롤러 작업을 처리한다는 것입니다.
• 13:04
  하지만 단순히 에이저를 사용한다는 이유만으로
• 13:05
  도메인 서비시즈를 선택하지는 마십시오.
• 13:07
  새로운 클라우드 앱은 엔트라 아이디를 통해 직접 로그인해야 합니다.
• 13:10
  최신 로그인 방식을 지원하면
• 13:12
  사용자를 엔트라 아이디로 보내고 로그인 증명을 받은 뒤
• 13:15
  클라우드 액세스 규칙과 다중인증의 이점을 누릴 수 있습니다.
• 13:18
  그것이 새로운 소프트웨어를 위한 더 깔끔한 방식입니다.
• 13:21
  도메인 서비스는 구식 언어를 사용하는 앱을 지원합니다.
• 13:24
  새로운 앱에 그 구식 언어를 가르칠 이유는 없습니다.
• 13:26
  먼저 확인해야 할 엄격한 제한 사항들도 있습니다.
• 13:29
  일부 앱은 액티브 디렉토리에서 읽기만 하는 것이 아니라
• 13:32
  다시 쓰기도 합니다.
• 13:33
  예를 들어 어떤 앱은 일반적인 작업의 일부로
• 13:35
  디렉터리 항목을 생성하거나 변경하려 할 수 있습니다.
• 13:38
  앱이 LDAP 쓰기 액세스를 요구할 때는
• 13:40
  도메인 서비스가 적합하지 않습니다.
• 13:42
  디렉터리에 저장할 수 있는 필드 집합인 액티브 디렉토리 스키마를
• 13:45
  앱이 변경해야 하는 경우에도 동일한 경고가 적용됩니다.
• 13:48
  일부 구형 소프트웨어는 실행하기 전에
• 13:50
  자체 필드를 추가하도록 요구합니다.
• 13:52
  관리형 도메인에서는 이러한 기본 설계를 변경할 수 없습니다.
• 13:54
  팀이 도메인 자체에 대한 완전한 제어 권한을 필요로 하는 경우
• 13:57
  에도 잠시 멈춰야 합니다.
• 13:58
  도메인 컨트롤러에 대한 직접적인 액세스가 필요할 수도 있습니다.
• 14:01
  매우 광범위한 제어 권한을 부여하는 도메인 관리자 권한이 필요할 수도 있습니다.
• 14:04
  아니면 직접 설계하고 운영하려는 복잡한 디렉터리 구조가 필요할 수도 있습니다.
• 14:08
  그런 경우 라면 온 프레미스 나에이저 가상 머신에서
• 14:11
  직접 액티브 디렉토리를 실행하는 방향으로 가야 합니다.
• 14:14
  도메인 서비스는 마이크로소프트가 핵심 도메인 서비스를 운영하므로
• 14:16
  위도적으로 더 적은 제어 권한을 제공합니다.
• 14:18
  따라서 경로를 선택하기 전에 명확한 질문을 하나 던져보십시오.
• 14:21
  이 워크로드가 구식 액티브 디렉토리 언어를 필요로 합니까?
• 14:24
  아니면 최신 엔트라 아이디를 사용할 수 있습니까?
• 14:26
  최신 엔트라 아이디를 사용할 수 있다면 거기서부터 시작하십시오.
• 14:28
  구식 도메인 동작이 필요하지만 도메인의 모든 부분을 소유할 필요는 없다면
• 14:32
  도메인 서비스가 매우 잘 맞을 수 있습니다.
• 14:34
  만약 앱이 디렉터리를 다시 쓰고 스키마를 변경하거나
• 14:36
  팀에 완전한 도메인 제어 권한을 주어야 한다면 다른 환경이 필요합니다.
• 14:40
  관리형 도메인을 선택하는 것은 절충안을 받아들이는 것을 의미합니다.
• 14:43
  마이크로소프트가 도메인 컨트롤러를 관리하고
• 14:45
  사용자는 직접 운영할 때 가졌던 제어 권한 중 일부를 포기하는 것입니다.
• 14:48
  알아야 할 관리형 서비스의 절충점들입니다.
• 14:50
  그러한 관리형 방식은 수고를 덜어주지만
• 14:52
  IT팀이 제어할 수 있는 범위도 바꿉니다.
• 14:55
  마이크로소프트는 도메인 컨트롤러를 운영하고
• 14:57
  동기화 상태를 유지하며 해치를 적용하고
• 14:59
  백그라운드에서 가용성을 처리합니다.
• 15:01
  각 도메인 컨트롤러의 위치를 계획하거나
• 15:03
  서버 장애 후 복구할 필요가 없습니다.
• 15:05
  그것이 많은 틈이 서비스를 선택하는 이유이지만
• 15:07
  도메인 컨트롤러의 원격 데스크톱으로 접속할 수는 없으며
• 15:10
  마이크로소프트 가관리하는 부분을 제어하게 되는
• 15:12
  도메인 관리자나 엔터프라이즈 관리자 권한도 얻을 수 없습니다.
• 15:14
  대신 마이크로소프트는 엔트라 도메인 서비시즈 어드미니스트레이터라는 그룹을 제공합니다.
• 15:19
  도메인을 관리해야 하는 사람들을 해당 그룹에 넣은 다음
• 15:22
  관리 대상 도메인에 조인된 관리용 가상 머신을 사용하세요.
• 15:25
  해당 머신에서 익숙한 액티브 디렉토리 도구를 사용하여
• 15:27
  마이크로소프트가 허용하는 범위를 관리할 수 있습니다.
• 15:29
  예를 들어 고유한 조직 구성 단위 OU를 직접 만들 수 있습니다.
• 15:33
  이들을 컴퓨터나 서비스 계정과 같은 도메인 개체를 담는 폴더로 생각하면 됩니다.
• 15:36
  dns 레코드를 관리하고 지원되는 설정에 대한 그룹 정책을 만들고 적용할 수 있습니다.
• 15:41
  또한 도메인에 가입된 컴퓨터를 관리할 수 있는데
• 15:43
  이는 서비스가 존재하는 주된 이유이기도 합니다.
• 15:45
  이러한 제한사항은 위도된 것입니다.
• 15:47
  도메인 컨트롤러를 추가하거나 액티브 디렉토리 스키마를 변경하거나
• 15:50
  관리 대상 도메인을 변경사항이 엔트라 아이디로 다시 전달되는 곳으로 취급할 수 없습니다.
• 15:54
  따라서 사용자 및 그룹 관리는 원본 디렉토리에서 수행하세요.
• 15:57
  클라우드 전용 기업의 경우 해당 원본은 엔트라 아이디입니다.
• 16:00
  하이브리드 기업의 경우 엔트라 아이디로 동기화되는 온 프레미스 액티브 디렉토리가 원본입니다.
• 16:05
  이 규칙은 흔히 발생하는 실수를 방지합니다.
• 16:07
  누군가 관리 대상 도메인에서 사용자를 보고 변경사항이 유지될 것이라 가정하고
• 16:10
  그곳에서 변경하는 경우입니다.
• 16:11
  하지만 그 변경사항은 엔트라 아이디 나온 프레미스 액티브 디렉토리 위 회사 기록이 되지 않습니다.
• 16:16
  관리 대상 도메인은 에이저 네트워킹 내부에서 비공개로 유지하세요.
• 16:19
  일반적인 회사 디렉토리가 아닌 필요한 워크로드만 지원해야 합니다.
• 16:23
  네트워크 액세스를 제한하고 관리 머신을 보호하며 필요한 사람에게만 관리자 액세스 권한을 부여하세요.
• 16:28
  여러분은 안전장치가 있는 서비스를 선택하는 것입니다.
• 16:31
  그 안전장치는 업무 부담을 줄여주는 동시에 마이크로소프트가 소유한 부분을 변경하지 못하도록 합니다.
• 16:36
  간단한 에이저 마이그레이션 사례입니다.
• 16:38
  사무실 내부 서버에서 오래된 앱을 실행 중인 금융회사를 상상해보세요.
• 16:42
  해당 앱은 직원을 찾기 위해 LDAP에 의존합니다.
• 16:44
  사람들이 로그인할 때는 커버로스를 사용합니다.
• 16:46
  그리고 서버는 금융 데이터베이스에 접근하기 위해 서비스 계정으로 인증합니다.
• 16:50
  회사는 앱과 데이터베이스를 모두 에이저 가상 머신으로 옮기려고 합니다.
• 16:54
  한 가지 방법은 VPN을 통해 앱을 사무실 도메인의 연결 상태로 두는 것이지만
• 16:58
  이 경우 에이저 앱은 매일 해당 네트워크 연결과 로컬 도메인 컨트롤러에 위존하게 됩니다.
• 17:02
  다른 방법은 에이저에서 새로운 도메인 컨트롤러 가상 머신을 실행하는 것입니다.
• 17:06
  이렇게 하면 에이저 내부에서 트래픽이 더 많이 유지되지만
• 17:08
  IT팀이 패치, 모니터링, 백업 및 복구해야 하는 윈도우즈 서버가 추가됩니다.
• 17:11
  팀은 다른 방식을 선택합니다.
• 17:13
  그들의 사용자와 그룹은 이미 엔트라 아이디로 동기화되어 있습니다.
• 17:16
  그들은 엔트라 도메인 서비스를 활성화하고
• 17:18
  에이저 가상 네트워크를 연결합니다.