mirror of
https://github.com/empayre/fleet.git
synced 2024-11-06 08:55:24 +00:00
add document with MDM glossary and protocols summary (#8765)
This commit is contained in:
Roberto Dip
GitHub
parent
c2647c3111
commit
ac5d04cde7
224
tools/mdm/apple/glossary-and-protocols.md
Normal file
224
tools/mdm/apple/glossary-and-protocols.md
Normal file
@ -0,0 +1,224 @@
|
||||
## Glossary
|
||||
|
||||
### SCEP: Simple Certificate Enrollment Protocol
|
||||
|
||||
SCEP is a protocol that allows devices to get a certificate from a CA (in our
|
||||
case, the Fleet server). This certificate is used later on to authenticate to
|
||||
the MDM server.
|
||||
|
||||
Resources:
|
||||
|
||||
- [SCEP summary](#scep-summary) below
|
||||
- [RFC 8894](https://datatracker.ietf.org/doc/html/rfc8894)
|
||||
|
||||
### DEP: Device Enrollment Program
|
||||
|
||||
A device enrolled via DEP prompts the user to enroll in MDM during the initial
|
||||
device setup process (right after macOS is installed.)
|
||||
|
||||
DEP is also called "automatic" enrollment because it doesn't require user
|
||||
action to download and activate a profile like [manual
|
||||
enrollment](#manual-enrollment) does.
|
||||
|
||||
Resources:
|
||||
|
||||
- [DEP Workflow Summary](#dep-workflow-summary)
|
||||
- [MDM protocol specification](https://developer.apple.com/business/documentation/MDM-Protocol-Reference.pdf)
|
||||
|
||||
### Manual enrollment
|
||||
|
||||
A method to enroll a device to an MDM server by manually getting and
|
||||
installing (generally by downloading from a URL) an [enrollment
|
||||
profile](#enrollment-profile).
|
||||
|
||||
### ABM: Apple Business Manager
|
||||
|
||||
Interface to administer Devices and MDM servers, mainly used for [DEP
|
||||
enrollment](#dep-enrollment).
|
||||
|
||||
Can be accessed at https://business.apple.com/ .
|
||||
|
||||
### APNs: Apple Push Notification Service
|
||||
|
||||
MDM uses the Apple Push Notification Service (APNs) to deliver a "wake up"
|
||||
message to managed devices. The device then connects to the MDM server to
|
||||
retrieve [commands](#commands) and return results.
|
||||
|
||||
APNs are servers managed by Apple, the MDM server needs a certificate signed by
|
||||
Apple to authenticate with them.
|
||||
|
||||
Resources:
|
||||
|
||||
- [MDM Protocol summary](#mdm-protocol-summary)
|
||||
- [MDM protocol specification](https://developer.apple.com/business/documentation/MDM-Protocol-Reference.pdf)
|
||||
|
||||
### Profile
|
||||
|
||||
A configuration profile is an XML file that allows to distribute configuration
|
||||
information, for example: restrictions on device features, VPN settings, etc.
|
||||
|
||||
Profiles have the `.mobileconfig` extension and can be administered in a device
|
||||
from "Settings > Profiles."
|
||||
|
||||
Resources:
|
||||
|
||||
- [Configuration Profile Reference](https://developer.apple.com/business/documentation/Configuration-Profile-Reference.pdf).
|
||||
|
||||
### Enrollment profile
|
||||
|
||||
An enrollment profile is a [profile](#profile) that contains special directives
|
||||
to enroll a device to an MDM server.
|
||||
|
||||
For [DEP enrollment](#dep-device-enrollment-program) this profile is
|
||||
automatically sent an installed into the device.
|
||||
|
||||
For [manual enrollment](#manual-enrollment) the profile needs to be downloaded
|
||||
and installed by the user.
|
||||
|
||||
### Commands
|
||||
|
||||
After a device is enrolled, an MDM server can send commands to be executed in
|
||||
the device (e.g: install an application, shut down the device, etc.)
|
||||
|
||||
The server first sends a [push
|
||||
notification](#apons-apple-push-notification-service), then the device polls
|
||||
the server for the command, processes the command, and reports the command
|
||||
results to the server.
|
||||
|
||||
### CSR: Certificate Signing Request
|
||||
|
||||
Issued by the server that needs validation from a signing authority, the
|
||||
request has the public key in the pair and information about the server
|
||||
(organization name, etc)
|
||||
|
||||
The CSR itself is usually created in a Base-64 based PEM format
|
||||
|
||||
### PKI: Public Key Infrastructure
|
||||
|
||||
Allows authenticating users and devices. The basic idea is to have one or more
|
||||
trusted parties digitally sign documents certifying that a particular
|
||||
cryptographic key belongs to a particular user or device. The key can then be
|
||||
used as an identity for the user.
|
||||
|
||||
Resources:
|
||||
|
||||
- https://www.ssh.com/academy/pki
|
||||
- https://en.wikipedia.org/wiki/Public_key_infrastructure
|
||||
|
||||
### CA: Certificate Authority
|
||||
|
||||
The primary role of the CA is to digitally sign and publish a public key
|
||||
bound to a given user.
|
||||
|
||||
This is done using the CA's own private key, so that
|
||||
trust in the user key relies on one's trust in the validity of the CA's key.
|
||||
|
||||
Resources:
|
||||
|
||||
- https://en.wikipedia.org/wiki/Public_key_infrastructure#Certificate_authorities
|
||||
|
||||
## SCEP summary
|
||||
|
||||
SCEP is a [PKI](#pki-public-key-infrastructure) protocol that allows devices to
|
||||
request certificates from a [CA](#ca-certificate-authoriy) (in our context, the
|
||||
Fleet server acts as a CA) that will be later used to authenticate with the MDM
|
||||
server (in our context, the Fleet server also acts as the MDM server.)
|
||||
|
||||
To enroll, a client provides a distinguished name and a public key, and the
|
||||
server responds with a X.509 certificate.
|
||||
|
||||
The CA server might also request a `challengePassword`, which is a shared
|
||||
secret that the server uses gate access to certificates, its omission allows
|
||||
for unauthenticated authorisation of enrolment requests.
|
||||
|
||||
More generally, the protocol is specified in [RFC
|
||||
8894](https://datatracker.ietf.org/doc/html/rfc8894) and allows:
|
||||
|
||||
- [CA](#ca-certificate-authority) public key distribution
|
||||
- Certificate enrolment and issue
|
||||
- Certificate renewal
|
||||
- Certificate query
|
||||
- Query (not perform) certificate revocation
|
||||
|
||||
## MDM Protocol summary
|
||||
|
||||
This is a rough summary of the [MDM Protocol
|
||||
Reference](https://developer.apple.com/business/documentation/MDM-Protocol-Reference.pdf).
|
||||
|
||||
The protocol is composed by the MDM Check-in protocol and the main MDM protocol.
|
||||
|
||||
### MDM Check-in Protocol
|
||||
|
||||
Used during initialization, validates if the device can be enrolled and
|
||||
notifies the server.
|
||||
|
||||
It's composed by three different messages sent by the device to the server.
|
||||
|
||||
**Authenticate**
|
||||
|
||||
When the MDM payload is being installed, the device tries to stablish a
|
||||
connection with the server. This is when the
|
||||
[SCEP](#scep-simple-certificate-enrollment-protocol) exchange takes place.
|
||||
|
||||
The device sends its UDID and the [topic](#push-notification-topic) that should
|
||||
be used for push notifications.
|
||||
|
||||
The server shouldn't assume that the device has installed the MDM payload, as
|
||||
other payloads in the profile may still fail to install. When the device has
|
||||
successfully installed the MDM payload, it sends a `TokenUpdate` message.
|
||||
|
||||
**TokenUpdate**
|
||||
|
||||
A device sends a token update message to the server when it has installed the
|
||||
MDM payload or whenever its device push token, push magic, or unlock token
|
||||
change. These fields are needed by the server to send the device push
|
||||
notifications or passcode resets.
|
||||
|
||||
The server should send push messages to the device only after receiving the
|
||||
first token update message.
|
||||
|
||||
**CheckOut**
|
||||
|
||||
The device attempts to notify the server when the MDM profile is removed.
|
||||
|
||||
- In macOS v10.9, this only happens if the `CheckOutWhenRemoved` key in the
|
||||
[MDM payload](#enrollment-profile) is set to true.
|
||||
- In macOS v10.8, this always happens.
|
||||
|
||||
If network conditions don't allow the message to be delivered successfully,
|
||||
the device makes no further attempts to send the message.
|
||||
|
||||
### Main MDM Protocol
|
||||
|
||||
After the device is enrolled, the server (at some point in the future) sends
|
||||
out a push notification to the device, then:
|
||||
|
||||
- The device polls the server for a [command](#commands) in response to the
|
||||
push notification.
|
||||
- The device performs the command.
|
||||
- The device contacts the server to report the result of the last command and
|
||||
to request the next command.
|
||||
|
||||
To see all available commands, look under "Support for macOS Requests" in the
|
||||
MDM Protocol Reference.
|
||||
|
||||
## DEP Workflow Summary
|
||||
|
||||
In order to get information about devices enrolled through DEP, the MDM server
|
||||
needs to communicate with Apple servers periodically.
|
||||
|
||||
The workflow looks like:
|
||||
|
||||
1. The MDM server gets a token that will use to authenticate to Apple servers.
|
||||
This process is described in detail in the MDM protocol reference. Some parts
|
||||
of it can be automated by MDM solutions.
|
||||
2. The MDM server periodically pings
|
||||
`GET https://mdmenrollment.apple.com/server/devices` and
|
||||
`GET https://mdmenrollment.apple.com/devices/sync` to get
|
||||
information about newly enrolled devices and changes on devices already
|
||||
enrolled.
|
||||
3. The MDM server defines and assigns profiles to devices using `POST
|
||||
https://mdmenrollment.apple.com/profile` and `PUT
|
||||
https://mdmenrollment.apple.com/profile/devices`
|
||||
4. The MDM server removes profiles from a device using `DELETE
|
||||
https://mdmenrollment.apple.com/profile/devices`
|
||||
Loading…
Reference in New Issue
Block a user