SEKTION: 03 / DNS & MDM Discovery
STATUS: Masterclass Deep-Dive
Bevor ein Gerät eine einzige Policy von Microsoft Intune empfangen kann, muss es eine fundamentale Hürde überwinden: Es muss wissen, wo es nach Hause telefonieren soll. In der Welt des Mobile Device Managements (MDM) nennt man diesen Prozess Discovery. Ohne eine funktionierende Discovery bleibt ein Gerät „blind“ – es ist zwar im Netzwerk, weiß aber nicht, welcher Server seine Konfigurationsprofile und App-Zuweisungen verwaltet.
1. Die Architektur der Discovery
MDM-Discovery ist kein proprietärer Microsoft-Standard, sondern ein Zusammenspiel aus industriellen Protokollen (HTTP, DNS) und plattformspezifischen Implementierungen von Apple, Google und Microsoft. Das Ziel ist immer dasselbe: Den Client von einer generischen Start-URL oder einem System-Trigger zum spezifischen Tenant-Endpunkt von Intune zu führen.
1. Trigger (z.B. Boot-Vorgang oder Account-Login) $\rightarrow$
2. DNS-Lookup (Plattformspezifisch) $\rightarrow$
3. HTTP/S Request an Discovery-URL $\rightarrow$
4. Redirect (302) zum Tenant-spezifischen Endpunkt $\rightarrow$
5. MDM-Handshake (Zertifikatsprüfung & Enrollment)
2. Apple MDM Discovery: Der Goldstandard der Strenge
Apple hat den Discovery-Prozess extrem formalisiert. Für iOS, iPadOS und macOS gibt es zwei Hauptwege: Das Device Enrollment Program (DEP) via Apple Business Manager (ABM) und das manuelle Enrollment.
2.1 DEP / ABM Discovery (Automated)
Bei DEP-Geräten ist die Discovery bereits auf Hardware-Ebene vorbereitet. Apple speichert die Seriennummer des Geräts in seinen eigenen Datenbanken und verknüpft sie mit einem MDM-Server. Wenn das Gerät startet, fragt es die Apple-Server: „Ich bin Gerät XY, wer ist mein Chef?“ Apple antwortet mit der URL des Intune-Enrollment-Servers.
2.2 Manuelle Discovery & DNS CNAMEs
Wenn ein Administrator eine eigene Domain für das MDM-Management verwenden möchte (White-Labeling), kommen DNS-CNAMEs ins Spiel. Apple-Geräte suchen nach spezifischen Hostnamen.
TYPE HOST VALUE
CNAME deviceenrollment.ihredomain.de enrollment.manage.microsoft.com
Der Client sendet einen Request an deviceenrollment.ihredomain.de. Der DNS-Server leitet ihn zu Microsoft weiter, wo Intune anhand des Zertifikats oder des Tokens entscheidet, in welchen Tenant das Gerät gehört.
3. Windows 10/11: Entra ID als Wegweiser
Windows nutzt einen anderen Ansatz. Da Windows-Geräte meist tief in das Microsoft-Ökosystem integriert sind, erfolgt die Discovery primär über Microsoft Entra ID (Azure AD). Es gibt keinen klassischen DNS-Lookup für die Discovery-URL, sondern einen tokenbasierten Abruf.
Der Prozess im Detail:
- User-Authentifizierung: Der Nutzer meldet sich mit seinem Firmenkonto am Gerät an.
- Discovery Request: Windows fragt Entra ID nach dem
MDM-Enrollment-Endpunkt. - Scope-Prüfung: Intune prüft im Backend: Ist der User im MDM-Scope (All, Some oder None)?
- URL-Delivery: Wenn der User im Scope ist, erhält Windows die URL
https://enrollment.manage.microsoft.com/enrollmentsbytoken.
Test-NetConnection -ComputerName enrollment.manage.microsoft.com -Port 443
4. Android Enterprise: Google & Zero Touch
Android nutzt zwei parallele Discovery-Mechanismen, je nachdem, ob das Gerät als Corporate-Owned oder Bring-Your-Own-Device (BYOD) genutzt wird.
4.1 Android Zero Touch (Corporate)
Ähnlich wie Apples DEP nutzt Android Zero Touch. Die Hardware-ID (IMEI/Seriennummer) ist bei Google hinterlegt. Beim ersten Start prüft das Gerät die Google-Cloud: „Gehöre ich zu einem Unternehmen?“ Falls ja, wird die Intune-Enrollment-URL direkt in den Setup-Assistenten injiziert.
4.2 Managed Google Play (BYOD)
Bei BYOD-Szenarien erfolgt die Discovery über das Google-Konto. Der Nutzer installiert die Intune-App, meldet sich an, und die App nutzt die API-Schnittstellen von Google, um den Device-Admin-Status zu aktivieren und die Verbindung zum Intune-Tenant herzustellen.
5. Netzwerk-Prärequisiten & Firewall-Hürden
Die Discovery scheitert in 90% der Fälle nicht an der Konfiguration in Intune, sondern an der Netzwerk-Infrastruktur. Wenn die Discovery-URL nicht aufgelöst oder erreicht werden kann, schlägt das gesamte Enrollment fehl.
| Komponente | Port | Zweck | Kritikalität |
|---|---|---|---|
| DNS | 53 | Auflösung der Enrollment-URLs | Essenziell |
| HTTP | 80 | Initialer Redirect-Check (Apple) | Mittel |
| HTTPS | 443 | Secure Communication / API | Kritisch |
6. Troubleshooting Masterclass
Wenn ein Gerät meldet: „Der Server ist nicht erreichbar“ oder „Die Verbindung konnte nicht hergestellt werden“, gehen Sie nach diesem Schema vor:
Prüfen Sie, ob
enrollment.manage.microsoft.com aufgelöst wird. nslookup enrollment.manage.microsoft.comWenn hier ein Fehler auftritt: DNS-Forwarder oder lokale Firewall prüfen.
Viele Firmen-Firewalls nutzen SSL-Inspection (Deep Packet Inspection). Da MDM-Discovery-Prozesse (besonders bei Apple) extrem empfindlich auf Zertifikatsänderungen reagieren, führt dies oft zum Abbruch.
Lösung: Die Domänen
*.manage.microsoft.com und *.apple.com müssen von der SSL-Inspection ausgenommen werden (Bypass).
Prüfen Sie im Intune Admin Center: Devices $\rightarrow$ Enrollment $\rightarrow$ Windows Enrollment $\rightarrow$ Automatic Enrollment. Steht der MDM-User-Scope auf None, wird die Discovery zwar erfolgreich sein, aber Entra ID wird dem Client keine URL liefern.
7. Zusammenfassung & Admin-Checkliste
[ ] Alle Endgeräte haben Zugriff auf Port 443 nach *.manage.microsoft.com
[ ] SSL-Inspection ist für MDM-Endpunkte deaktiviert
[ ] Apple CNAMEs sind korrekt gesetzt (falls Custom Domain genutzt wird)
[ ] MDM-User-Scope in Entra ID ist auf ‚All‘ oder ‚Some‘ gesetzt
[ ] ABM/DEP Token ist aktuell und nicht abgelaufen
[ ] Android Zero Touch IDs sind korrekt mit dem Tenant verknüpft
Academy
Weiterlernen in der Kaffeeundcode Academy
Wenn du diese Themen systematisch vertiefen willst, schau dir den ersten Academy-Kurs zur PSADT-Softwarepaketierung an. Im Fokus stehen .msi, .exe, Silent Switches, Detection, Logs und ein belastbarer Troubleshooting-Workflow.