Device Registration

Für die Steuerung des Zugriffs auf Office 365 Dienste können Sie mit Conditional Access steuern, wer mit welchem Gerät und welcher Authentifizierung welche Dienste nutzen darf. Gerade für die Steuerung über das Gerät muss Office 365 natürlich das Gerät kennen. Computer, die Domainmitglied in einem lokale Active Directory sind, können über AADConnect einfach in die Cloud synchronisiert werden.

Diese Seite beschreibt am Beispiel eines Android Device die Registrierung eines Mobilgeräts an AzureAD und die spätere Verwendung in Conditional Access Rules. Conditional Access ist aus meiner Sicht das Schlüsselelemente Dienste und Daten in der Cloud nur für Geräte bereit zu stellen, die auch vom Unternehmen zugelassen wurden.

Früher war das Leben einfacher, weil PCs im internen LAN und Mitglied der Domäne waren und von Draußen per VPN sich verbunden haben. Die Office 365 Dienste sind erst mal für jeden mit Benutzername und Kennwort von jedem Client erreichbar.

Besser ist es aber, wenn auf dem Client eine Applikation installiert wird, die das Gerät selbst als Ganzes an einem Management-Dienst registriert, ggfls. Richtlinien und Einstellungen übernimmt und die "Konformität" zurück meldet. Auf dieser Basis können dann die Dienste entscheiden, welchen Zugriff sie erlauben. Diese Lösung ist nicht nur für mobile Geräte wie Smartphones oder Tablets sondern auch für vollwertige Windows 10 PCs verfügbar.

Diese Seite beschreibt die Registrierung am AzureAD. Es gibt auch den Weg, das sich ein Gerät über einen lokalen ADFS-Server am lokalen Active Directory registriert und dort geführt und durch AADConnect dann ins AzureAD synchronisiert wird. Das ist ein anderer Fall

Vorarbeiten

Damit das alles so funktioniert, benötige ich natürlich...

  • Office 365 Tenant
    Ohne den geht das schon mal nicht
  • Office 365 Identität
    Ich muss mich als Anwender natürlich gegen die Cloud authentifizieren. Daher brauche ich auch einen Benutzer, mit dem ich mich anmelden kann
  • DNS-Eintrag
    Sie müssen natürlich noch zwei DNS-Einträge (enterpriseregistration.<upndomain> und enterpriseenrollment.<upndomain>) in der DNS-Domäne im Internet setzen, die sie als UPN bei den Benutzern verwenden:
  • Berechtigung für den Anwender
    In der Standardeinstellung darf jeder Anwender bis zu 20 Geräte in das AzureAD aufnehmen. Diese Einstellung können Sie aber über die Azure Verwaltungsoberfläche anpassen.

Aber dann kann es schon losgehen.

Registrierung mit dem Unternehmensportal

Exemplarisch habe ich dazu ein Android-Telefon (Honor 9lite) wie folgt mit dem AzureAD verbunden. Über den normalen Google Play Store suche ich nach dem Microsoft Unternehmensportal und installiere die so erst mal kostenfreie Software:

Der nächste Schritt ist natürlich die Anmeldung mit meinem AzureAD-Konto. Nach der Authentifizierung kommen eine ganze Menge von Fenstern, die die Arbeit und die Auswirkungen der App beschreiben.

Interessant finde ich, dass die App dem Anwender einmalig die Wahl lässt, das Gerät selbst zu klassifizieren. Das könnte die App doch auch selbst schon vorgeben und ist etwas unverständlich für mich:

Die App bleibt nun auf dem Smartphone und kann auch genutzt werden, um z.B. Unternehmens-Apps zu verteilen oder neue Richtlinien umzusetzen. Für einige Funktionen ist dazu allerdings Intune zu lizenziere.

Sichtbarkeit in AzureAD

Die Einrichtung auf dem Client führt natürlich zu einem Eintrag in der Cloud. Im Office 365 Portal sehen sie die Geräte noch nicht aber im Azure Portal können Sie über die Benutzer im AzureAD die Geräte des Benutzers anzeigen lassen.

Das untere Gerät ist in AzureAD registriert und da ich auch eine Intune-Lizenz habe, könne ich nun das Gerät auch damit weiter verwalten.

Ich habe aber keinen Weg gefunden, das Gerät auch in Gruppen aufzunehmen und damit zu steuern

Das geht wohl nur mit Intune.

Alle Änderungen sind im Überwachungsprotokoll sichtbar:

So kann pro Device auch nachvollzogen werden, welche Änderungen daran erfolgt sind.

Sichtbarkeit On-Premises

Größere Firmen verwalten natürlich ihre Clients nicht alleine im AzureAD sondern haben ein lokales Active Directory. Mit der Komponente AzureADConnect (AADConnect) gibt es die Funktion "Device Writeback", mit der Sie dann die in der Cloud angelegten Geräte auch in das lokale AD zurückschreiben können.

Für das Geräterückschreiben ist ein Azure AD Premium-Abonnement erforderlich.
Quelle: https://docs.microsoft.com/de-de/azure/active-directory/connect/active-directory-aadconnect-feature-device-writeback

Diese Funktion brauchen Sie natürlich nur, wenn Sie die Informationen über die Geräte auch im lokalen AD für bestimmte Aufgaben verwenden müssen. Wenn Sie nur Dienste in der Cloud absichern, dann können ihnen die fehlenden lokalen AD-Objekte erst mal egal sein.

Verwechseln Sie diese Funktion nicht mit der Möglichkeit, dass Geräte sich direkt über einen lokalen ADFS-Service im lokalen AD registrieren können. Dann m��ssen die DNS-Einträge nicht in die Cloud sondern auf die lokalen Services verweisen. Denkbar ist auch, dass eine andere MDM-Lösung die Objekte im lokalen AD entsprechend anlegt und ihre Applikationen und Clients dann arbeiten. Das ist aber nicht im Scope deser Seite.

Status: Managed und Compliant

Das Mobilgerät ist nun natürlich erst mal im AzureAD aber weder "managed" noch "compliant.

Dazu finde ich bei Microsoft dann den Satz:

In Kombination mit einer Lösung für die Verwaltung mobiler Geräte, wie z.B. Microsoft Intune, werden die Geräteattribute in Azure AD mit zusätzlichen Informationen über das Gerät aktualisiert. S
Quelle: https://docs.microsoft.com/de-de/azure/active-directory/device-management-introduction

Das Wörtchen "z.B." hat mich neugierig gemacht und im englischen Original heißt es "Such as". Also kein Übersetzungsfehler und ein Hinweis, dass es auch anders gehen kann. In der GUI ist nichts zu finden. Aber die PowerShell zeigt mehr:

Install-Module AzureAD
Connect-AzureAD

Get-AzureADDevice | where {$_.iscompliant -ne $false}

ObjectId                             DeviceId                             DisplayName
--------                             --------                             -----------
4cbdbd39-8fe6-443f-9a9c-3b9bca2a3913 80302af3-d1ec-41f0-94a5-5e04be5352c2 DCUser
677f5b4b-df90-4225-b4be-cb35ebd76a48 99bde2e5-9649-4e86-a1b4-94c3e148a242 frank_Android_6/10/2018_10:59 PM
9e9a0c7b-35f5-4d20-a03b-185ff467e933 e728a968-1fc8-46d2-b88b-691b45675447 WIN10-A

get-AzureADDevice  -ObjectId 677f5b4b-df90-4225-b4be-cb35ebd76a48  | fl

DeletionTimestamp             :
ObjectId                      : 677f5b4b-df90-4225-b4be-cb35ebd76a48
ObjectType                    : Device
AccountEnabled                : True
AlternativeSecurityIds        : {class AlternativeSecurityId {
                                  IdentityProvider:
                                  Key: System.Byte[]
                                  Type: 2
                                }
                                }
ApproximateLastLogonTimeStamp : 10.06.2018 22:59:25
ComplianceExpiryTime          :
DeviceId                      : 99bde2e5-9649-4e86-a1b4-94c3e148a242
DeviceMetadata                :
DeviceObjectVersion           : 2
DeviceOSType                  : Android
DeviceOSVersion               : 8.0.0
DevicePhysicalIds             : {}
DeviceTrustType               : Workplace
DirSyncEnabled                :
DisplayName                   : frank_Android_6/10/2018_10:59 PM
IsCompliant                   : False
IsManaged                     : False
LastDirSyncTime               :

Interessanterweise gibt es auch einen Set-AzureADDevice

Da lag es nahe mal die Parameter zu probieren:

Set-AzureADDevice `
   -ObjectId 677f5b4b-df90-4225-b4be-cb35ebd76a48 `
   -IsCompliant $false `
   -IsManaged:$true `
   -Verbose

Es hat ein paar Sekunden gedauert aber dann dann war das Gerät auch ohne MDM/Intune auf "Kompliant"

Das ist natürlich interessant, da dieser Status in den Conditional Access Policies verwendet werden kann:

Da fehlt dann nur noch die Lösung, um auch 3rd Party MDM-Lösungen in AzureAD einzubinden-

Device addieren?

Bei der Kontrolle von Commandlets mit "*-AzureADDevice" sind mir natürlich noch andere Commandlets aufgefallen.

Get-Command *-azureaddevice

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Cmdlet          Get-AzureADDevice                                  2.0.1.10   AzureAD
Cmdlet          New-AzureADDevice                                  2.0.1.10   AzureAD
Cmdlet          Remove-AzureADDevice                               2.0.1.10   AzureAD
Cmdlet          Set-AzureADDevice                                  2.0.1.10   AzureAD

Set-, Get und Remove- sind ja schnell erklärt, aber was hat es mit "New" auf sich? Sollte ich damit ein eigenes neues Gerät einfach vorab schon addieren können? Für Mobilgeräte hatte ich eigentlich immer erwartet, dass das nur über die Unternehmensapp geht und die Anwender natürlich die Rechte dazu haben müssen. Ich habe daher einfach mal das Commandlete gestartet und gewartet, welche Parameter verpflichtend abgefragt werden.

New-AzureADDevice

Cmdlet New-AzureADDevice an der Befehlspipelineposition 1
Geben Sie Werte für die folgenden Parameter an:
AccountEnabled: $true
AlternativeSecurityIds[0]:
DeviceId: 1234
DeviceOSType: Type
DeviceOSVersion: 1.0
DisplayName: Test123
New-AzureADDevice : Der Parameter "AlternativeSecurityIds" kann nicht gebunden werden. Der Wert "$null" vom Typ
"System.String" kann nicht in den Typ "Microsoft.Open.AzureAD.Model.AlternativeSecurityId" konvertiert werden.
In Zeile:1 Zeichen:1
+ New-AzureADDevice
+ ~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [New-AzureADDevice], ParameterBindingException
    + FullyQualifiedErrorId : CannotConvertArgumentNoMessage,Microsoft.Open.AzureAD16.PowerShell.NewDevice

Von allen Feldern stört sich das Commandlet anscheinend nur an der fehlenden SID, die ein Mobiltelefon nicht hat. Aber ein Administrator könnte damit wohl schon Computerkonten anlegen, die später von einem Client genutzt werden.

Ich habe auch hinweise gefunden, dass z.B. andere MDM-Lösungen sich in AzureAD integrieren können. Eventuell nutzen diese Lösungen ja den Weg von ihnen eingerichtete und verwaltete Geräte im AzureAD anzulegen.

AADConnect Device WriteBack

Die meisten Administratoren mit Office 365 Erfahrung werden schon einen AzureADConnect installiert haben und sind dabei über die Funktion "Device Writeback" gestoßen.

Für die Aktivierung dieser Funktion ist natürlich wieder eine AzureAD Premium 1 (P1) oder P2 erforderlich. Dann sorgt aber AADConnect dafür, dass in der Cloud verwaltete Geräte auch in das lokale Active Directory übertragen werden. Im ersten Moment erscheint es fraglich, was hier damit passieren soll. Wer aber eine AzureAD P1 Lizenz hat, kann MFA auch für On Premises Systeme nutzen und auch den lokalen ADFS-Server mit MFA und erweiterten Regeln einsetzen. Es wird damit also möglich sein, das ein Office 365 Kunden als Device Management zwar Intune in der Cloud nutzt und die Information über den Gerätestatus auch im lokalen Umfeld einsetzen kann.

Lokale Verwaltung
Ich habe aktuell keinen Tenant mit Device Writeback und nutzt nur die Conditional Access-Funktion mit Office 365. Insofern kann ich nicht testen, welche AD-Properties die Geräte im lokalen AD haben und ob über diese lokalen Objekte und AADConnect die Objekte im AzureAD mit verwaltet werden können. Interessant wäre hier die Einstellung bezüglich "IsManaged" und "IsCompliant"

Windows 10 als Device

Natürlich kann auch Windows 10 und sogar Windows Server 2016 als AzureAD-Gerät addiert werden. Es muss also nicht das Smartphone sein. Das "kann" ein Szenario in Firmen sein, wenn private Geräte, also BYOD, auf Unternehmensdaten zugreifen dürfen aber nicht Mitglied im lokalen Active Directory sind. Allerdings habe ich damit selbst noch keine praktischen Erfahrungen gesammelt. Daher belasse ih es bei einem Link.

Weitere Links