Kaffeeundcode

Sektion 03: DNS & MDM Discovery: Wie Geräte Intune finden

29. Juni 2026 Bruno 0 Kommentare
MODUL: Intune A-Z Mastercourse
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.

TECHNICAL LOGIC FLOW:
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.

# DNS Konfiguration für Apple Discovery
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.
# PowerShell Check: Ist der Enrollment-Server erreichbar?
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:

STEP 1: DNS VERIFICATION
Prüfen Sie, ob enrollment.manage.microsoft.com aufgelöst wird.
nslookup enrollment.manage.microsoft.com
Wenn hier ein Fehler auftritt: DNS-Forwarder oder lokale Firewall prüfen.
STEP 2: SSL/TLS INSPECTION CHECK
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).
STEP 3: SCOPE CHECK (Windows)
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

ADMIN CHECKLIST: MDM DISCOVERY
[ ] 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
Expert-Tipp: Nutzen Sie bei Problemen mit Apple-Geräten das Tool curl -v https://deviceenrollment.ihredomain.de/company. Wenn Sie keinen 302 Redirect zu Microsoft sehen, ist Ihre DNS-Konfiguration oder Ihr Redirect-Service defekt.

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.