OMA DM 프로토콜 지원
OMA DM 클라이언트는 HTTPS를 통해 서버와 통신하고 DM 동기화(OMA DM v1.2)를 메시지 페이로드로 사용합니다. 이 문서에서는 DM 클라이언트가 일반적으로 지원하는 OMA DM 기능에 대해 설명합니다. OMA DM 프로토콜 v1.2에 대한 전체 설명은 OMA 웹 사이트에서 찾을 수 있습니다.
OMA DM 표준
다음 표에서는 Windows에서 사용하는 OMA DM 표준을 보여 줍니다.
| 일반 영역 | 지원되는 OMA DM 표준 |
|---|---|
| 데이터 전송 및 세션 | |
| 부트스트랩 XML | OMA 클라이언트 프로비저닝 XML. |
| DM 프로토콜 명령 | 다음 목록에서는 디바이스에서 사용하는 명령을 보여 줍니다. OMA DM 명령 요소에 대한 자세한 내용은 OMA 웹 사이트에서 사용할 수 있는 "OMA 웹 사이트"를 참조하세요. 유효한 OMA DM 명령이 아닌 XML 요소가 다음 요소 중 하나에 있는 경우 해당 요소에 대해 상태 코드 400이 반환됩니다. DM 명령에 CmdID가 제공되지 않으면 클라이언트는 상태 요소와 상태 코드 400에서 공백을 반환합니다. Atomic 요소가 중첩되면 다음 상태 코드가 반환됩니다. Atomic 명령에 대한 자세한 내용은 OMA DM 프로토콜 공통 요소를 참조하세요. Atomic 요소 내의 동일한 노드에서 Add 명령 다음에 Replace를 수행하는 것은 지원되지 않습니다. LocURI는 로 /시작할 수 없습니다.SyncHdr의 메타 XML 태그는 디바이스에서 무시됩니다. |
| OMA DM 표준 개체 | DevInfo |
| 보안 | |
| 노드 | OMA DM 트리에서 노드 이름에 다음 규칙이 적용됩니다.*) 문자일 수 없습니다. |
| 파일 프로비전 | 프로비저닝 XML은 올바른 형식이어야 하며 SyncML 표현 프로토콜의 정의를 따라야 합니다. 유효한 OMA DM 명령이 아닌 XML 요소가 SyncBody 아래에 있으면 해당 요소에 대해 상태 코드 400이 반환됩니다.
참고 유니코드 문자열을 URI로 나타내려면 먼저 문자열을 UTF-8로 인코딩합니다. 그런 다음 URI 인코딩을 사용하여 각 UTF-8 바이트를 인코딩합니다. |
| WBXML 지원 | Windows는 XML 형식과 인코딩된 WBXML 형식 모두에서 SyncML을 보내고 받을 수 있습니다. 이 이중 형식 지원은 등록 중에 w7 APPLICATION 특성 아래의 DEFAULTENCODING 노드를 사용하여 구성할 수 있습니다. WBXML 인코딩에 대한 자세한 내용은 SyncML 표현 프로토콜 사양의 섹션 8을 참조하세요. |
| 큰 개체 처리 | Windows 10 대용량 개체를 서버에 업로드하기 위한 클라이언트 지원이 추가되었습니다. |
OMA DM 프로토콜 공통 요소
공통 요소는 다른 OMA DM 요소 형식에서 사용됩니다. 다음 표에서는 디바이스를 구성하는 데 사용되는 OMA DM 공통 요소를 나열합니다. OMA DM 공통 요소에 대한 자세한 내용은 OMA 웹 사이트에서 사용할 수 있는 "SyncML 표현 프로토콜 장치 관리 사용"(OMA-SyncML-DMRepPro-V1_1_2-20030613-A)을 참조하세요.
| 요소 | 설명 |
|---|---|
| Chal | 인증 챌린지를 지정합니다. 원래 요청 메시지에 자격 증명이나 부적절한 자격 증명이 제공되지 않은 경우 서버 또는 클라이언트가 다른 사용자에게 챌린지를 보낼 수 있습니다. |
| Cmd | Status 요소에서 참조되는 OMA DM 명령의 이름을 지정합니다. |
| CmdID | OMA DM 명령에 대한 고유 식별자를 지정합니다. |
| CmdRef | 상태 또는 결과 정보가 반환되는 명령의 ID를 지정합니다. 이 요소는 해당 요청 메시지의 CmdID 요소 값을 사용합니다. |
| Cred | 메시지의 보낸 사람의 인증 자격 증명을 지정합니다. |
| 최종 | 현재 메시지가 패키지의 마지막 메시지임을 나타냅니다. |
| LocName | MD5 인증을 위해 사용자 ID를 보내는 데 사용되는 대상 및 원본 요소의 표시 이름을 지정합니다. |
| LocURI | 대상 또는 원본 위치의 주소를 지정합니다. 주소에 영숫자 이외의 문자가 포함된 경우 URL 인코딩 표준에 따라 올바르게 이스케이프되어야 합니다. |
| MsgID | OMA DM 세션 메시지에 대한 고유 식별자를 지정합니다. |
| MsgRef | 해당 요청 메시지의 ID를 지정합니다. 이 요소는 요청 메시지 MsgID 요소의 값을 사용합니다. |
| RespURI | 이 메시지에 대한 응답을 보낼 때 받는 사람이 사용해야 하는 URI를 지정합니다. |
| Sessionid | 포함된 메시지와 연결된 OMA DM 세션의 식별자를 지정합니다. 서버가 DMClient CSP의 SyncApplicationVersion 노드를 통해 새 버전을 지원한다는 사실을 디바이스에 알리지 않으면 클라이언트는 10진수 형식으로 SessionID를 정수로 반환합니다. 서버가 Windows에서 사용되는 DM 세션 동기화 버전 2.0을 지원하는 경우 디바이스 클라이언트는 2바이트를 반환합니다. |
| 소스 | 메시지 원본 주소를 지정합니다. |
| SourceRef | 해당 요청 메시지의 원본을 지정합니다. 이 요소는 요청 메시지 Source 요소의 값을 사용하고 Status 또는 Results 요소에 반환됩니다. |
| 대상 | OMA DM 명령의 대상인 DM 트리의 노드 주소를 지정합니다. |
| TargetRef | 해당 요청 메시지의 대상 주소를 지정합니다. 이 요소는 요청 메시지 Target 요소의 값을 사용하고 Status 또는 Results 요소에 반환됩니다. |
| VerDTD | 메시지를 나타내는 데 사용되는 OMA DM 표현 프로토콜 사양의 주 버전 및 부 버전 식별자를 지정합니다. |
| VerProto | 메시지와 함께 사용되는 OMA DM 프로토콜 사양의 주 버전 및 부 버전 식별자를 지정합니다. |
디바이스 관리 세션
DM(장치 관리) 세션은 DM 서버와 클라이언트 디바이스 간에 교환되는 일련의 명령으로 구성됩니다. 서버는 클라이언트 디바이스의 관리 트리에서 수행해야 하는 작업을 나타내는 명령을 보냅니다. 클라이언트는 결과 및 요청된 상태 정보를 포함하는 명령을 전송하여 응답합니다.
짧은 DM 세션은 다음과 같이 요약할 수 있습니다.
서버는 클라이언트 디바이스에 Get 명령을 전송하여 관리 트리의 노드 중 하나의 콘텐츠를 검색합니다. 디바이스는 작업을 수행하고 요청된 내용이 포함된 Result 명령으로 응답합니다.
DM 세션은 다음 두 단계로 나눌 수 있습니다.
- 설정 단계: 트리거 이벤트에 대한 응답으로 클라이언트 디바이스는 시작 메시지를 DM 서버로 보냅니다. 디바이스 및 서버 교환에는 인증 및 디바이스 정보가 필요했습니다. 이 단계는 1, 2, 3단계로 표시됩니다.
- 관리 단계: DM 서버가 제어됩니다. 디바이스에 관리 명령을 보내고 디바이스가 응답합니다. 2단계는 DM 서버가 명령 전송을 중지하고 세션을 종료할 때 종료됩니다. 이 단계는 3, 4, 5단계로 표시됩니다.
다음 정보는 일반적인 DM 세션 동안의 이벤트 시퀀스를 보여 줍니다.
관리 서버로 다시 호출하기 위해 DM 클라이언트가 호출됩니다.
엔터프라이즈 시나리오 - 디바이스 작업 일정은 DM 클라이언트를 호출합니다.MO 서버는 DM 클라이언트를 호출하는 서버 트리거 메시지를 보냅니다.
트리거 메시지는 서버 ID를 포함하고 클라이언트 디바이스에 서버와의 세션을 시작하도록 지시합니다. 클라이언트 디바이스는 트리거 메시지를 인증하고 서버와 통신할 권한이 있는지 확인합니다.
엔터프라이즈 시나리오 - 예약된 시간에 DM 클라이언트가 주기적으로 호출되어 HTTPS를 통해 엔터프라이즈 관리 서버로 다시 호출됩니다.디바이스는 IP 연결을 통해 메시지를 전송하여 세션을 시작합니다.
이 메시지에는 디바이스 정보 및 자격 증명이 포함됩니다. 클라이언트와 서버는 TLS/SSL 채널 또는 DM 애플리케이션 수준에서 상호 인증을 수행합니다.
DM 서버는 IP 연결(HTTPS)을 통해 응답합니다. 서버는 초기 디바이스 관리 명령(있는 경우)을 보냅니다.
디바이스가 서버 관리 명령에 응답합니다. 이 메시지에는 지정된 디바이스 관리 작업을 수행한 결과가 포함됩니다.
DM 서버는 세션을 종료하거나 다른 명령을 보냅니다. DM 세션이 종료되거나 4단계가 반복됩니다.
단계 번호는 메시지 ID 번호(MsgID)를 나타내지 않습니다. 서버의 모든 메시지에는 첫 번째 메시지에 대해 1부터 시작하여 각 추가 메시지에 대해 1씩 증가하는 세션 내에서 고유한 MsgID가 있어야 합니다. MsgID 및 OMA SyncML 프로토콜에 대한 자세한 내용은 OMA 장치 관리 표현 프로토콜(DM_RepPro-V1_2-20070209-A)을 참조하세요.
OMA DM 애플리케이션 수준 상호 인증 중에 서버 요청의 Cred 요소에 대한 디바이스 응답 코드가 212이면 DM 세션의 나머지 부분에 대해 추가 인증이 필요하지 않습니다. MD5 인증이 Chal 발생하면 요소를 반환할 수 있습니다. 그런 다음 다음 DM 세션이 시작될 때 의 Chal 다음 nonce를 MD5 다이제스트에 사용해야 합니다.
요청에 자격 증명이 포함되어 있고 요청에 대한 응답 코드가 200인 경우 다음 요청 내에서 동일한 자격 증명을 보내야 합니다.
Chal 요소가 포함되어 있고 MD5 인증이 필요한 경우 다음 요청을 위해 요소를 통해 다음 nonce를 사용하여 새 다이제스트를 Chal 만듭니다.
기본 또는 MD5 클라이언트 인증, MD5 서버 인증에 대한 자세한 내용은 MD5 해시 및 MD5 nonce는 OMA 웹 사이트에서 사용할 수 있는 OMA 장치 관리 보안 사양(OMA-TS-DM_Security-V1_2_1-20080617-A), OMA 장치 관리 프로토콜 사양의 인증 응답 코드 처리 및 단계별 샘플(OMA-TS-DM_Protocol-V1_2_1-20080617-A)을 참조하세요.
사용자 대상 및 디바이스 대상 구성
사용자 구성을 지원하는 CSP 및 정책의 경우 MDM 서버는 MDM에 등록된 사용자가 적극적으로 로그인하는 디바이스에 사용자 대상 설정 값을 보낼 수 있습니다. 디바이스는 DM pkg#1에서 경고 유형 = 인 디바이스 경고(1224)를 통해 로그인 상태 서버에 알림
이 경고의 데이터 부분은 다음 문자열 중 하나일 수 있습니다.
- 사용자: 디바이스를 등록한 사용자가 적극적으로 로그인됩니다. MDM 서버는 사용자별 구성을 지원하는 CSP/정책에 대한 사용자별 구성을 보낼 수 있습니다.
- 기타: 다른 사용자가 로그인하지만 해당 사용자에게 MDM 계정이 없습니다. 서버는 디바이스 전체 구성만 적용할 수 있습니다. 예를 들어 구성은 디바이스의 모든 사용자에게 적용됩니다.
- 없음: 활성 사용자 로그인이 없습니다. 서버는 디바이스 전체 구성만 적용할 수 있으며 사용 가능한 구성은 디바이스 환경으로 제한됩니다(활성 사용자 로그인 없음).
경고 예제는 다음과 같습니다.
<Alert>
<CmdID>1</CmdID>
<Data>1224</Data>
<Item>
<Meta>
<Type xmlns="syncml:metinf">com.microsoft/MDM/LoginStatus</Type>
<Format xmlns="syncml:metinf">chr</Format>
</Meta>
<Data>user</Data>
</Item>
</Alert>
서버는 관리 노드의 LocURL에 접두사를 사용하여 사용자 대상 구성인지 디바이스 대상 구성인지, ./user 사용자 대상 구성인지 또는 디바이스 대상 구성 ./device 인지 디바이스에 알릴 수 있습니다. 기본적으로 또는 ./user가 있는 접두사는 ./device 없는 경우 디바이스 대상 구성입니다.
다음 LocURL은 사용자별 CSP 노드 구성을 보여 줍니다. ./user/vendor/MSFT/EnterpriseModernAppManagement/AppInstallation/<PackageFamilyName>/StoreInstall
다음 LocURL은 디바이스당 CSP 노드 구성을 보여 줍니다. ./device/vendor/MSFT/RemoteWipe/DoWipe
SyncML 응답 상태 코드
OMA DM에서 SyncML을 사용하는 경우 반환되는 표준 응답 상태 코드가 있습니다. 다음 표에는 표시되는 일반적인 SyncML 응답 상태 코드가 나와 있습니다. SyncML 응답 상태 코드에 대한 자세한 내용은 SyncML 표현 프로토콜 사양의 섹션 10을 참조하세요.
| 상태 코드 | 설명 |
|---|---|
| 200 | SyncML 명령이 성공적으로 완료되었습니다. |
| 202 | 처리에 허용됩니다. 이 코드는 애플리케이션의 원격 실행 실행 요청과 같은 비동기 작업을 나타냅니다. |
| 212 | 인증이 수락되었습니다. 일반적으로 SyncHdr 요소에 대한 응답으로 이 코드만 표시됩니다(OMA-DM 표준의 인증에 사용됨). OMA DM 로그를 보면 이 코드가 표시되겠지만 CSP는 일반적으로 이 코드를 생성하지 않습니다. |
| 214 | 작업이 취소되었습니다. SyncML 명령이 성공적으로 완료되었지만 세션 내에서 더 이상 명령이 처리되지 않습니다. |
| 215 | 실행되지 않았습니다. 명령을 취소하기 위한 사용자 상호 작용의 결과로 명령이 실행되지 않았습니다. |
| 216 |
Atomic 확인을 롤백합니다. 명령이 요소 내부에 Atomic 있었고 Atomic 실패했습니다. 이 명령은 성공적으로 롤백되었습니다. |
| 400 | 잘못된 요청입니다. 잘못된 형식의 구문으로 인해 요청된 명령을 수행할 수 없습니다. CSP는 일반적으로 이 오류를 생성하지 않지만 SyncML의 형식이 잘못된 경우 이 오류가 표시될 수 있습니다. |
| 401 | 잘못된 자격 증명입니다. 요청자가 적절한 인증을 제공해야 하므로 요청된 명령이 실패했습니다. CSP는 일반적으로 이 오류를 생성하지 않습니다. |
| 403 | 금지. 요청된 명령이 실패했지만 받는 사람이 요청된 명령을 이해했습니다. |
| 404 | 찾을 수 없습니다. 요청된 대상을 찾을 수 없습니다. 이 코드는 존재하지 않는 노드를 쿼리하는 경우 생성됩니다. |
| 405 | 명령이 허용되지 않습니다. 이 응답 코드는 읽기 전용 노드에 쓰려고 하면 생성됩니다. |
| 406 | 선택적 기능은 지원되지 않습니다. 이 응답 코드는 CSP에서 지원하지 않는 속성에 액세스하려고 하면 생성됩니다. |
| 415 | 지원되지 않는 형식 또는 형식입니다. 이 응답 코드는 XML 구문 분석 또는 서식 오류로 인해 발생할 수 있습니다. |
| 418 | 이미. 이 응답 코드는 이미 있는 노드를 추가하려고 하면 발생합니다. |
| 425 | 사용 권한이 거부되었습니다. 보낸 사람에게 수신자에 대한 적절한 ACL(액세스 제어 권한)이 없기 때문에 요청된 명령이 실패했습니다. "액세스 거부됨" 오류는 일반적으로 이 응답 코드로 변환됩니다. |
| 500 | 명령이 실패했습니다. 일반 오류입니다. 수신자가 예기치 않은 조건을 발견하여 요청을 이행하지 못했습니다. 이 응답 코드는 SyncML DPU가 원래 오류 코드를 매핑할 수 없는 경우에 발생합니다. |
| 507 |
Atomic 실패. 블록의 작업 Atomic 중 하나가 실패했습니다. |
| 516 |
Atomic 롤백에 실패했습니다.
Atomic 작업이 실패했고 명령이 성공적으로 롤백되지 않았습니다. |