Black Box Version 1.0 Manual de usuario descargar pdf (Pagina 10)

Authenticate Response

• Server can decline enrollment

• A blank plist is a valid “ok” response

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC

"-//Apple Computer//DTD PLIST 1.0//EN"

"http://www.apple.com/DTDs/PropertyList-1.0.dtd">

</plist>

Token Update

• Via HTTP PUT to /checkin

• Blank plist also a valid response

<dict>

<key>MessageType</key>

<string>TokenUpdate</string>

<key>PushMagic</key>

<string> [ uuid string ] </string>

<key>Token</key>

<data> [ 32 byte string, base64 encoded ] </data>

<key>Topic</key>

<string>com.example.mdm.pushcert</string>

<string> [ redacted ] </string>

<key>UnlockToken</key>

<data> [ long binary string encoded in base64 ] </data>

</dict>

If the server accepts the enrollment request, it doesn’t need to provide

anything beyond a simple, blank .plist ﬁle.

The next step is for the client device to provide some additional special

data to the server. This is the source of the aforementioned PushMagic

string, as well as the DeviceToken provided by Apple when connecting

to APNS, and the Push Notiﬁcation “Topic” string. These three items

permit the server to send MDM notiﬁcations to the device, and without it,

MDM simply won’t work.

The last, most interesting item here is the UnlockToken. As best as I can

determine, this (about 2kb) binary stream includes an actual key to an

escrow keybag on the device. This token is used to clear the passcode

on a locked device.

Again, this message is sent via HTTP PUT over the “Check In” URL.

And, again, all the server needs to respond with is a blank .plist.

1 2 ... 5 6 7 8 9 10 11 12 13 14 15 ... 30 31

Sin comentarios

Black Box Version 1.0 Manual de usuario Pagina 10