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.

Beachten Sie dazu auch die Seiten SourceAnchor Computer und ADSync mit Devices und Azure AD Join

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 mehrere Voraussetzungen:

  • 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 dieser Seite.

Status: Managed und Compliant

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

Dazu gab es 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.
Quelle: https://docs.microsoft.com/de-de/azure/active-directory/device-management-introduction  (frühere Version)

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 `
   -DeviceId 7182897f-6067-469f-b80b-292751178133 
   -IsCompliant $true `
   -IsManaged:$true `
   -Verbose

Hinweis: in 2018 hat es gereicht die ObjectID anzugeben. Mitterlweile muss man wohl DeviceID und ObjectID mit angeben.

Achtung:
Der Compliant-Status kann für mobile Geräte (IOS/Android) nicht per PowerShell gesetzt werden.
Trotz "GlobalAdmin" bekomme ich den Fehler:

Set-AzureADDevice : Error occurred while executing SetDevice
Code: Authorization_RequestDenied
Message: Insufficient privileges to complete the operation

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

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

Dass der Wert gesetzt werden kann, steht sogar auf der Microsoft Webseite

IsCompliant and IsManaged should only be updated by Intune for any device OS type or by an approved MDM app for Windows OS devices. These are used by conditional access policies. ...
Quelle: Set-AzureADDevice https://docs.microsoft.com/en-us/powershell/module/azuread/set-azureaddevice?view=azureadps-2.0

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

Die Kommunikation der AzureAD-PowerShell hinsichtlich den Geräten erfolgt übrigens per Graph API. Per Fiddler können Sie sehr gut nachschauen, welche URLs aufgerufen werden und wie die Antwort aussieht. Hier ein Beispiel:

# Ich suche nach einem Gerät mit dem Namen
Get-AzureADDevice -SearchString fciphone 

Mit Fiddler sehe ich dann folgende URL als Anfragen. Aus Authentifizierung kommt natürlich "Bearer" zum Einsatz

https://graph.windows.net/<TenantID>/devices?api-version=1.6&%24filter=displayName%20eq%20'fciphone'%20or%20startswith(displayName%2C'fciphone')

Wenn ich dann den Compliant-Status eines Geräts setze, dann sieht das wie folgt aus:

PATCH https://graph.windows.net/<tenantid>/devices/<DeviceID>?api-version=1.6 HTTP/1.1
Accept: application/json
Authorization: Bearer 
cmdlet-name: Set-AzureADDevice
client-request-id: a3d95209-eb5f-4523-8b0f-54f39f559c44
User-Agent: Swagger-Codegen/1.4.0.0/csharp
Content-Type: application/json
Host: graph.windows.net
Content-Length: 21
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
 
{"isCompliant":false}

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 Commandlets 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

Siehe dazu auch die Seite Azure AD Join

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.

Die Registrierung kann schon bei der Installation selbst oder durch den Anwender in Windows erfolgen. Suchen Sie einfach nach "Azure" oder "Arbeit" und die Windows 10 Suche sollte ihnen die Einstellung schon anbieten:

Im Dialog der Einstellung finden Sie vermutlich schon die Verknüpfung mit der Domäne und ihrem Anmeldenamen: Hier gibt es dann die Option auch nachträglich das Gerät einfach zu registrieren.

Nach der Eingabe von Anmeldedaten sollten Sie die Bestätigung erhalten:

Auch in den Einstellungen erscheint die Registrierung:

Ab da ist das Gerät dann per Intune verwaltbar.

Cleanup/Stale Device

Speziell, wenn sich Geräte durch den Benutzer selbst im AzureAD registrieren, wird die Liste immer länger und der Wunsch nach einem "Aufräumen" kommt auf. Zwar kosten AzureAD-Geräte noch kein Geld aber wenn die Liste immer länger wird, dauern Abfragen länger und man muss suchen. Der Zeitpunkt der letzten Aktivität könnte hier herangezogen werden. Allerdings ist der Zeitstempel nicht immer aktuell. Selbst auf meinem täglich aktiven PC war der Zeitstempel auch mehrere Tage in der Vergangenheit.

Ich bin nicht sicher, aber auch das Gerät holt sich einen "DeviceKey", welcher einige Zeit gültig ist. AD-Computer würde ich also eher anhand des Kennwortalters beim Computerkonto identifizieren. Nur CloudOnly-Devices muss ich natürlich im AzureAD ermitteln. Dabei hilft Get-AzureADDevice.

Get-AzureADDevice -SearchString FC-T480S | fl

DeletionTimestamp             :
ObjectId                      : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
ObjectType                    : Device
AccountEnabled                : True
AlternativeSecurityIds        : {class AlternativeSecurityId {
                                  IdentityProvider:
                                  Key: System.Byte[]
                                  Type: 2
                                }
                                }
ApproximateLastLogonTimeStamp : 19.09.2021 10:59:37
ComplianceExpiryTime          :
DeviceId                      : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
DeviceMetadata                :
DeviceObjectVersion           : 2
DeviceOSType                  : Windows
DeviceOSVersion               : 10.0.19043.1237
DevicePhysicalIds             : {[HWID]:h:6896141027100719,
                                [USER-HWID]:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx:6896141027100719,
                                [GID]:g:6896141027100720,
                                [USER-GID]:7xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx:6896141027100720}
DeviceTrustType               : ServerAd
DirSyncEnabled                : True
DisplayName                   : FC-T480S
IsCompliant                   : True
IsManaged                     : True
LastDirSyncTime               : 15.11.2019 02:44:06
ProfileType                   : RegisteredDevice
SystemLabels                  : {}

Die Ausgabe ist vom 28.9.2021 und in der Zwischenzeit ist mein Client natürlich aktiv und hat auch ein paar Reboots (Windows updates) hinter sich.

Eine gefilterte Liste können Sie wie folgt ermitteln. Alle Geräte >90 Tage sollten zumindest einmal hinterfragt werden.

Get-AzureADDevice -All:$true `
| where-object {$_.ApproximateLastLogonTimestamp -gt ((get-date).adddays(-90))} `
| ft Displayname,ApproximateLastLogonTimestamp

Achtung: In der Liste können, wenn Sie dies nicht verboten haben, auch private Geräte oder Geräte anderer Firmen auftauchen, die in ihrem Tenant, Stichwort Gast-Identität, mitarbeiten.

Weitere Links