Sektion 02: Entra ID (Azure AD) Grundlagen für Intune Admins

Einleitung: Warum Entra ID das Herzstück von Intune ist

Wenn du Intune verwalten willst, musst du zuerst verstehen, was Entra ID ist — und zwar nicht oberflächlich, sondern tiefgreifend. Entra ID (früher Azure Active Directory, seit Juli 2023 umbenannt) ist nicht einfach ein „Verzeichnisdienst im Cloud“ — es ist die Identitätsschicht, auf der Intune vollständig aufbaut. Jede Registrierung, jede Richtlinie, jede App-Zuweisung, jeder bedingter Zugriff — alles beginnt mit einer Identität in Entra ID.

Die häufigste Fehleinschätzung von Intune-Admins, die aus der On-Premises-Welt kommen: Sie denken an Entra ID wie an ein lokales Active Directory. Das ist jedoch ein fundamentaler Irrtum. Entra ID ist kein Domänencontroller in der Cloud. Es ist ein Identity-as-a-Service-Provider mit einer völlig anderen Architektur, anderen Protokollen und einer anderen Philosophie. Wer hier an alten Gewohnheiten festhält, wird bei der Implementierung von Intune immer wieder scheitern.

In dieser Sektion legen wir das Fundament, auf dem die nächsten 88 Sektionen aufbauen. Du wirst verstehen, wie Entra ID strukturiert ist, wie sich Benutzer und Geräte darin verhalten, wie die Synchronisation mit einem lokalen AD funktioniert, und welche Konzepte du als Intune-Admin zwingend beherrschen musst.

Grundkonzepte: Die Architektur von Entra ID

Tenant, Tenant ID und Primäre Domäne

Ein Entra ID Tenant ist eine dedizierte, isolierte Instanz von Entra ID, die einer Organisation gehört. Jeder Tenant hat eine eindeutige Tenant ID (eine GUID) und mindestens eine primäre Domäne, die bei der Registrierung vergeben wird — typischerweise etwas wie contoso.onmicrosoft.com. Diese onmicrosoft.com-Domäne ist die einzige Domäne, die niemals gelöscht werden kann und immer als Fallback dient.

Du kannst eigene benutzerdefinierte Domänen hinzufügen (z.B. contoso.com), indem du einen TXT- oder MX-Eintrag bei deinem DNS-Provider erstellst und Entra ID die Kontrolle darüber verifiziert. Erst dann können Benutzer sich mit max.mustermann@contoso.com anmelden statt mit der onmicrosoft.com-Adresse.

Für Intune-Admins ist wichtig: Intune ist in den Tenant integriert. Es gibt keine separate Intune-Instanz. Wenn du einen Tenant hast, hast du automatisch Intune (sofern die entsprechenden Lizenzen zugewiesen sind). Die Tenant-ID ist die gemeinsame Basis für alle Microsoft Cloud-Dienste.

Benutzer, Gruppen und administrative Einheiten

In Entra ID sind Benutzer (Users) die zentralen Identitäten. Ein Benutzer kann rein in der Cloud existieren (Cloud-only) oder aus einem lokalen Active Directory synchronisiert werden (hybrid). Cloud-only-Benutzer werden direkt in Entra ID erstellt, synchronisierte Benutzer werden über Entra ID Connect (früher Azure AD Connect) vom lokalen AD repliziert und können in der Cloud nicht bearbeitet werden — ihre Attributquelle ist das lokale AD.

Gruppen in Entra ID gibt es in zwei Varianten, und der Unterschied ist für Intune-Admins entscheidend:

Sicherheitsgruppen (Security Groups): Die Standardgruppe für die Zuweisung von Intune-Richtlinien, Apps und Konfigurationsprofilen. Mitglieder können manuell oder dynamisch zugewiesen werden.
Microsoft 365-Gruppen: Diese Gruppen haben ein gemeinsames Postfach, einen SharePoint-Team- und einen Kalender. Für Intune-Zuweisungen sind sie zwar technisch verwendbar, aber nicht empfohlen — sie bringen Overhead, den du für reine Geräteverwaltung nicht brauchst.

Der eigentliche Gamechanger sind dynamische Gruppen. Statt Mitglieder manuell hinzuzufügen, definierst du Regeln basierend auf Benutzer- oder Geräteattributen. Entra ID wertet diese Regeln kontinuierlich aus und fügt oder entfernt Mitglieder automatisch:

// Beispiel: Dynamische Sicherheitsgruppe für alle Windows 11-Geräte
(user.deviceOSType -eq "Windows11") 
AND (user.deviceTrustType -eq "AzureAD")

// Beispiel: Dynamische Gruppe für alle Benutzer in der IT-Abteilung
(user.department -eq "IT") 
AND (user.userType -eq "Member")

Für Intune bedeutet das: Ein Gerät, das sich neu registriert und die Kriterien erfüllt, landet automatisch in der entsprechenden Gruppe — und damit automatisch im Geltungsbereich der zugewiesenen Richtlinien. Keine manuelle Zuweisung mehr. Das ist der Kern moderner, automatisierter Geräteverwaltung.

Administrative Einheiten (Administrative Units) sind ein weiteres Konzept, das du kennen musst. Sie erlauben es dir, administrative Zuständigkeiten auf bestimmte Untergruppen innerhalb des Tenants einzuschränken. Eine AU „Zürich“ könnte alle Benutzer und Geräte im Raum Zürich enthalten, und ein dortiger IT-Admin bekommt nur für diese Objekte administrative Rechte. Das ist für große, dezentrale Organisationen unverzichtbar — in kleinen Umgebungen oft überflüssig.

Geräteidentitäten in Entra ID

Geräte in Entra ID können drei verschiedene Join-Status haben, und jeder davon hat spezifische Auswirkungen auf Intune:

Azure AD registriert (Registered): Das Gerät ist mit Entra ID registriert, hat aber keine echte Identität in einer Domäne. Typisch für BYOD-Geräte (Bring Your Own Device). Benutzer können auf Unternehmensressourcen zugreifen, aber das Gerät unterliegt weniger strengen Kontrollen.
Azure AD verbunden (Joined): Das Gerät ist direkt mit Entra ID verbunden, ohne lokales AD. Dies ist der Standardweg für moderne Windows-Geräte in Cloud-only-Umgebungen. Der Benutzer meldet sich mit seiner Entra-ID-Identität an.
Hybrid Azure AD verbunden (Hybrid Joined): Das Gerät ist Mitglied eines lokalen Active Directory und zusätzlich mit Entra ID verbunden. Diese Variante wird durch Entra ID Connect ermöglicht. Typisch für Umgebungen mit bestehender On-Premises-Infrastruktur.

Der Join-Status bestimmt, wie Intune das Gerät verwaltet. Ein Azure AD Joined Gerät kann vollständig von Intune verwaltet werden. Ein Hybrid Joined Gerät kann ebenfalls von Intune verwaltet werden, erfordert aber Entra ID Connect und eine funktionierende Synchronisation. Ein rein registriertes BYOD-Gerät erhält nur eingeschränkte Verwaltungsfunktionen über MDM-Registrierung.

App-Registrierungen und Enterprise Applications

Entra ID verwaltet nicht nur Menschen und Geräte, sondern auch Anwendungen. App-Registrierungen (App Registrations) und Enterprise Applications sind zwei Seiten derselben Medaille: Die App-Registrierung definiert die Identität einer Anwendung in deinem Tenant, die Enterprise Application repräsentiert die Instanz dieser Anwendung nach dem Consent-Prozess.

Intune selbst ist eine Enterprise Application. Wenn du die Intune-Graph API ansprechen willst (z.B. für automatisiertes Reporting oder PowerShell-Skripte), brauchst du eine App-Registrierung mit den entsprechenden API-Berechtigungen. Das werden wir in späteren Sektionen vertiefen, aber du solltest jetzt schon verstehen, dass jede Automatisierung rund um Intune über Entra ID-App-Registrierungen läuft.

Praxis-Implementierung: Entra ID für Intune aufsetzen

Lizenzierung: Was du brauchst

Bevor du irgendwelche Konfiguration vornimmst, musst du die Lizenzierung verstehen. Intune selbst ist in mehreren Microsoft-Lizenzpaketen enthalten:

Microsoft Intune (eigenständig): Die reine Intune-Lizenz, ohne Entra ID Premium P1 oder P2.
Microsoft 365 E3: Enthält Intune und Entra ID Premium P1.
Microsoft 365 E5: Enthält Intune und Entra ID Premium P2 (mit erweiterten Identity-Protection-Features).
Microsoft 365 Business Premium: Enthält Intune und Entra ID Premium P1 für kleine und mittlere Unternehmen.

Der Unterschied zwischen Entra ID Premium P1 und P2 ist für Intune-Admins nicht akademisch: P2 enthält Entra ID Identity Protection, welches Risiken basierend auf Verhaltensanalyse erkennt und automatische Antworten (z.B. MFA erzwingen, Zugriff blockieren) triggern kann. Conditional Access ist bereits in P1 enthalten, aber die risikobasierten Bedingungen erfordern P2.

Benutzer und Gruppen mit PowerShell erstellen

Die manuelle Erstellung über das Entra Admin Center ist für kleine Umgebungen ausreichend, aber in der Praxis wirst du PowerShell verwenden. Hier die wesentlichen Befehle mit dem Microsoft Graph PowerShell SDK:

# Verbindung zu Entra ID herstellen
Connect-MgGraph -Scopes "User.ReadWrite.All", "Group.ReadWrite.All"

# Einen neuen Benutzer erstellen
$passwordProfile = @{
    Password = "TempPass123!#"
    ForceChangePasswordNextSignIn = $true
}

New-MgUser -DisplayName "Max Mustermann" `
    -UserPrincipalName "max.mustermann@contoso.com" `
    -MailNickname "max.mustermann" `
    -PasswordProfile $passwordProfile `
    -AccountEnabled `
    -UsageLocation "CH"

# Eine statische Sicherheitsgruppe erstellen
$group = New-MgGroup -DisplayName "Intune-Windows11-Devices" `
    -Description "Alle Windows 11-Geräte unter Intune-Verwaltung" `
    -MailEnabled:$false `
    -SecurityEnabled `
    -MailNickname "intune-win11"

# Eine dynamische Sicherheitsgruppe erstellen (Windows 11-Geräte)
$dynamicGroupParams = @{
    DisplayName = "Intune-Dynamic-Win11"
    Description = "Automatisch: Alle Windows 11 Geräte"
    GroupTypes = @("DynamicMembership")
    MailEnabled = $false
    SecurityEnabled = $true
    MailNickname = "dyn-win11"
    MembershipRule = '(device.deviceOSType -eq "Windows") and (device.deviceOSVersion -startsWith "10.0.22")'
    MembershipRuleProcessingState = "On"
}

New-MgGroup @dynamicGroupParams

Das UsageLocation-Attribut ist obligatorisch, bevor du Lizenzen zuweisen kannst — ohne dieses Attribut schlägt die Lizenzzuweisung fehl. Das ist einer der häufigsten Fehler, die Intune-Admins bei der Automatisierung machen.

Lizenzen zuweisen

# Die Intune-Lizenz (SkuId) ermitteln
$licenses = Get-MgSubscribedSku
$intuneSku = $licenses | Where-Object { 
    $_.SkuPartNumber -eq "INTUNE_A" 
}

# Lizenz einem Benutzer zuweisen
Set-MgUserLicense -UserId "max.mustermann@contoso.com" `
    -AddLicenses @(@{SkuId = $intuneSku.SkuId}) `
    -RemoveLicenses @()

Gruppenbasierte Lizenzzuweisung ist die empfohlene Methode: Du weist die Lizenz nicht dem einzelnen Benutzer zu, sondern einer Gruppe. Jeder, der in die Gruppe aufgenommen wird, erhält automatisch die Lizenz. Das lässt sich hervorragend mit dynamischen Gruppen kombinieren — z.B. alle Benutzer in der Abteilung „IT“ erhalten automatisch die Intune-Lizenz.

Entra ID Connect: Die hybride Synchronisation

Wenn du ein bestehendes lokales Active Directory hast, brauchst du Entra ID Connect (oder den Cloud-basierten Entra ID Connect Cloud Sync), um Benutzer, Gruppen und Geräte von On-Premises nach Cloud zu synchronisieren. Die Installation erfolgt auf einem Windows Server im lokalen Netzwerk.

# Entra ID Connect installieren (Silent Mode, grundlegende Konfiguration)
# Download: https://www.microsoft.com/download/details.aspx?id=47594

# Nach der Installation: Synchronisation überprüfen
Get-ADSyncScheduler
# Zeigt: SyncCycleInterval, Current Sync Cycle Status

# Manuelle Synchronisation triggern
Start-ADSyncSyncCycle -PolicyType Delta
# Delta = nur Änderungen, Initial = Vollständige Synchronisation

Für Intune relevant sind vor allem zwei Aspekte der Synchronisation:

Benutzer- und Gruppensynchronisation: Nur synchronisierte Benutzer und Gruppen können in Intune verwendet werden, wenn du eine hybride Umgebung betreibst.
Gerätesynchronisation (Hybrid Join): Damit ein lokales AD-Gerät hybrid mit Entra ID verbunden wird, musst du den Hybrid Join in Entra ID Connect konfigurieren. Das erfordert einen Service Connection Point (SCP) im lokalen AD und zusätzliche Konfigurationsschritte.

Best Practices für Intune-Admins

Naming Conventions durchsetzen

Verwende konstante Naming Conventions für Gruppen, Richtlinien und Profile. Eine bewährte Konvention für Intune-bezogene Entra ID-Gruppen:

INT-DEV-W11-CMP   = Intune, Devices, Windows 11, Compliance
INT-DEV-W11-CFG   = Intune, Devices, Windows 11, Configuration
INT-USR-ALL-LIC   = Intune, Users, All, Licensed
INT-USR-IT-DYN    = Intune, Users, IT, Dynamic

Dieses System ermöglicht es dir, auf einen Blick zu erkennen, was eine Gruppe ist, für wen sie gilt und wofür sie verwendet wird. Bei 50+ Gruppen in einem Intune-Tenant ist das kein Luxus, sondern Überlebenstechnik.

Dynamische Gruppen strategisch einsetzen

Dynamische Gruppen sind mächtig, aber sie haben Grenzen. Die Regelverarbeitung kann bei sehr großen Tenants (über 50.000 Objekte) Verzögerungen aufweisen — Microsoft garantiert keine sofortige Mitgliedschaftsänderung. Für kritische, zeit-sensitive Zuweisungen sind statische Gruppen verlässlicher.

Kombiniere stattdessen beide Ansätze: Verwende dynamische Gruppen für die grundsätzliche Kategorisierung (Betriebssystem, Abteilung, Gerätetyp) und statische Gruppen für spezifische, manuell kontrollierte Zuweisungen (Pilotgruppen, VIP-Geräte, Testgeräte).

Conditional Access von Tag eins an denken

Conditional Access ist die Brücke zwischen Entra ID und Intune. Die typische Implementierung: Intune registriert und verwaltet das Gerät, Conditional Access prüft bei jedem Anmeldeversuch, ob das Gerät compliant ist (Intune-Compliance-Status) und gewährt oder verweigert Zugriff basierend darauf.

Richte die Gruppenstruktur von Anfang an so ein, dass sie Conditional Access-freundlich ist. Das bedeutet: Trenne Compliance-fähige Geräte von nicht-Compliance-fähigen Geräten in der Gruppenstruktur, und plane Exklusionsgruppen für Break-Glass-Accounts und Notfallzugriffe.

Break-Glass-Accounts einrichten

Wenn deine Conditional Access-Politik zu strikt ist, sperrst du dich selbst aus. Jeder Intune-Tenant braucht mindestens zwei Break-Glass-Accounts — Cloud-only, mit komplexen Passwörtern (mindestens 32 Zeichen), MFA-pflichtig (physischer FIDO2-Key), und von allen Conditional Access-Politiken ausgeschlossen. Diese Accounts werden nur in Notfällen verwendet und sollten regelmäßig (aber selten) getestet werden.

Troubleshooting: Die häufigsten Probleme

Problem 1: Benutzer erscheint nicht in Intune

Ursachen können sein: Fehlende Lizenz, fehlendes UsageLocation, Synchronisationsfehler bei hybriden Umgebungen, oder der Benutzer ist in einer administrativen Einheit, die für Intune nicht sichtbar ist.

# Prüfen, ob der Benutzer eine Intune-Lizenz hat
$user = Get-MgUser -UserId "max.mustermann@contoso.com" `
    -Property id, displayName, assignedLicenses

if ($user.AssignedLicenses.Count -eq 0) {
    Write-Warning "Keine Lizenzen zugewiesen!"
}

# Prüfen, ob UsageLocation gesetzt ist
$userDetails = Get-MgUser -UserId "max.mustermann@contoso.com" `
    -Property usageLocation
if (-not $userDetails.UsageLocation) {
    Write-Warning "UsageLocation fehlt - Lizenz kann nicht zugewiesen werden!"
}

Problem 2: Dynamische Gruppe nimmt keine Mitglieder auf

Die häufigste Ursache sind Syntaxfehler in der Membership Rule. Entra ID evaluiert die Syntax, gibt aber nicht immer klare Fehlermeldungen zurück. Prüfe, ob die Attribute, auf die du verweist, überhaupt gepflegt sind. Eine Regel wie (user.department -eq "IT") funktioniert nur, wenn das department-Attribut tatsächlich für den Benutzer gesetzt ist.

# Mitgliedschaftsregel einer Gruppe überprüfen
$group = Get-MgGroup -Filter "displayName eq 'Intune-Dynamic-Win11'" `
    -Property id, displayName, membershipRule, membershipRuleProcessingState

Write-Host "Rule: $($group.MembershipRule)"
Write-Host "Processing: $($group.MembershipRuleProcessingState)"

# Mitgliedschaft prüfen
$members = Get-MgGroupMember -GroupId $group.Id
Write-Host "Mitglieder: $($members.Count)"

Problem 3: Gerät wird nicht Hybrid Joined

Wenn ein lokales AD-Gerät nicht den Hybrid Join-Status erreicht, prüfe folgende Punkte:

Der Service Connection Point (SCP) ist im lokalen AD konfiguriert (über Entra ID Connect)
Der Client kann den SCP erreichen (DNS-Auflösung, Netzwerkverbindung zum Domänencontroller)
Das Gerät hat das entsprechende Attribut userCertificate gesetzt
Entra ID Connect synchronisiert Geräte (nicht nur Benutzer)

# SCP im lokalen AD überprüfen
Get-ADObject -Filter "objectClass -eq 'serviceConnectionPoint'" `
    -Properties serviceBindingInformation, serviceDNSName

# Auf dem Client: Hybrid Join Status prüfen
dsregcmd /status
# Suche nach: "AzureAdJoined : YES" im Device Status-Abschnitt

Problem 4: Entra ID Connect-Synchronisation schlägt fehl

Synchronisationsfehler sind meist in den Metaverse-Regeln oder in Attribut-Konflikten begründet. Die wichtigste Diagnose:

# Synchronisations-Fehler abrufen
Get-ADSyncAADConnectorSyncErrors

# Detaillierte Synchronisation-Logs
# Im Synchronization Service Manager (miisclient.exe):
# C:\Program Files\Microsoft Azure AD Sync\SyncUIService.exe

Die häufigsten Synchronisationsfehler sind:

Duplicate UPN: Zwei Benutzer mit demselben UserPrincipalName. Entra ID erlaubt keine Duplikate.
Duplicate ProxyAddress: Zwei Benutzer mit derselben E-Mail-Adresse (SMTP-Proxy-Adresse).
Fehlendes Source-Anchor: Wenn ms-DS-ConsistencyGuid nicht korrekt konfiguriert ist, können Benutzer nicht eindeutig identifiziert werden.
LargeObject-Fehler: Wenn ein Benutzerattribut (meist userCertificate oder proxyAddresses) die Größenbegrenzung überschreitet.

Problem 5: Conditional Access blockiert legitime Benutzer

Wenn Conditional Access-Regeln zu aggressiv konfiguriert sind, kann das den gesamten Zugriff blockieren. Die Diagnose erfolgt über die Anmeldeprotokolle in Entra ID:

# Anmeldeprotokolle abrufen (Graph API)
Connect-MgGraph -Scopes "AuditLog.Read.All"

$signIns = Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'max.mustermann@contoso.com'" `
    -Top 10

foreach ($log in $signIns) {
    Write-Host "Zeit: $($log.CreatedDateTime)"
    Write-Host "Status: $($log.Status.ErrorCode) - $($log.Status.FailureReason)"
    Write-Host "CA-Policies: $($log.AppliedConditionalAccessPolicies | ConvertTo-Json -Depth 3)"
    Write-Host "---"
}

In den Applied Conditional Access Policies siehst du, welche Politik angewendet wurde und warum der Zugriff verweigert wurde. Die häufigsten Ursachen sind: Gerät nicht compliant (Intune-Compliance fehlt), MFA nicht abgeschlossen, oder die IP-Adresse ist nicht in den vertrauenswürdigen IP-Adressen enthalten.

Die Rolle von Entra ID im Intune-Lebenszyklus

Um zu verstehen, wie tief Entra ID und Intune verwoben sind, betrachte den typischen Lebenszyklus eines Geräts:

Registrierung: Das Gerät verbindet sich mit Entra ID (Join oder Registration). Entra ID erstellt die Geräteridentität.
Intune-Registrierung: Durch den Entra ID-Join wird automatisch die MDM-Registrierung in Intune ausgelöst (sofern konfiguriert). Das Gerät taucht im Intune-Portal auf.
Gruppenzuweisung: Das Gerät landet basierend auf seinen Attributen in dynamischen Entra ID-Gruppen.
Richtlinienanwendung: Intune wertet die Gruppenzugehörigkeit aus und wendet die zugewiesenen Konfigurationsprofile, Compliance-Richtlinien und Apps an.
Compliance-Reporting: Intune meldet den Compliance-Status zurück an Entra ID.
Conditional Access: Bei jeder Anmeldung prüft Entra ID den Compliance-Status (über Intune) und gewährt oder verweigert Zugriff.
Ausmustung: Beim Retire/Wipe in Intune wird auch die Geräteridentität in Entra ID entfernt (sofern konfiguriert).

Jeder Schritt in diesem Zyklus berührt Entra ID. Wenn etwas in diesem Zyklus schiefgeht, liegt die Ursache oft nicht in Intune selbst, sondern in der Entra ID-Konfiguration — fehlende Lizenzen, fehlerhafte Synchronisation, falsche Gruppenzugehörigkeit, unvollständige Geräteridentität. Als Intune-Admin musst du genauso kompetent in Entra ID sein wie in Intune selbst.

Fazit

Entra ID ist nicht „das AD in der Cloud“ — es ist eine komplett andere Identitätsplattform, die nach eigenen Regeln funktioniert. Wer Intune erfolgreich implementieren will, muss diese Regeln verstehen: Tenant-Struktur, Benutzer- und Geräteidentitäten, dynamische Gruppen, App-Registrierungen, Conditional Access und die hybride Synchronisation. Diese Sektion hat dir das Vokabular und die grundlegenden Konzepte gegeben. In den nächsten Sektionen werden wir diese Konzepte anwenden — bei der Geräte-registrierung, der Richtlinienkonfiguration, der App-Verteilung und der Implementierung von Conditional Access. Das Fundament, das du hier gelegt hast, ist die Voraussetzung für alles, was kommt.

Der häufigste Fehler, den ich in der Praxis sehe: Admins überspringen diese Grundlagen, springen direkt zur Richtlinienkonfiguration und wundern sich dann, warum Geräte nicht registriert werden, Richtlinien nicht angewendet werden oder Conditional Access scheinbar willkürlich Zugriffe blockiert. Die Ursache ist fast immer in Entra ID zu finden — nicht in Intune. Nimm dir die Zeit, diese Konzepte zu verinnerlichen. Es wird dir hunderte Stunden Troubleshooting sparen.