Generelle Voraussetzungen:

• Eine existierende AD-Umgebung welche korrekt mittels Azure-AD-Sync nach Azure AD synchronisiert
• Mindestens einen der Domäne beigetretenen Computer
• Regionale Verfügbarkeit des Dienstes
• Sicherheit darüber, dass Azure Files prinzipiell funktioniert. Als Test kann eine Dateifreigabe mittels Speicherkontenschlüssel erstellt und getestet werden. Diese muss funktionieren!

Der Beitrag ist extra so kurz wie möglich gehalten und beschreibt nur die wichtigsten Schritte. Weitere, sowie tiefgründigere Informationen, sind der Microsoft Dokumentation zu entnehmen.

Lösung

Vorhandenes Speicherkonto auswählen oder ein neues erstellen.

Das Archiv „AzureFilesHybrid“ von GitHub herunterladen und entpacken.

Hinweis: Dies und das Nachfolgende auf einem Computer durchführen, welcher der lokalen Domäne beigetreten ist. Außerdem sicherstellen, dass ein AD-Konto verwendet wird, welches mindestens das Recht besitzt einen Dienstbenutzer (service log on account) zu erstellen.

PowerShell-Terminal öffnen und folgende Befehle ausführen und bestätigen:

Install-Module -Name az -AllowClobber -Scope CurrentUser
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser

In der PowerShell-Sitzung in den Ordner des entpackten „AzureFilesHybrid“ Archives wechseln und folgende Befehle ausführen und bestätigen:

.\CopyToPSPath.ps1
Import-Module -Name AzFilesHybrid -Verbose

Eine Verbindung mit dem Azure-Online-Dienst aufbauen. Dazu mit dem gewünschten Azure-Konto anmelden und sicherstellen, dass das korrekte Abo ausgewählt wurde. Sollte das falsche Abo vorausgewählt sein, kann es mit einem optionalen Befehl gewechselt werden.

Connect-azaccount

Optional bei falschem Abo:
Select-AzSubscription -SubscriptionId "ID"

Erstellung und Zuweisung eines Service-Benutzers zur Authentifizierung des Azure Speicherkontos. Dabei eine OU angeben unter welcher der Benutzer erstellt werden soll.

Hinweis: Darauf achten, dass das Passwort des Dienstbenutzers nicht abläuft! (Sollte „Kennwort läuft nie ab“ nicht verwendet werden)

Join-AzStorageAccountForAuth -ResourceGroupName "Ressourcengruppenname" -Name "Speicherkontoname" -Domain "lokale Domäne" -DomainAccountType ServiceLogonAccount -OrganizationalUnitDistinguishedName "Gewünschte OU"

Anschließend kann der erstellte Benutzer in der angegebenen OU des ADs gefunden werden.

Als nächstes sollte die Konfiguration überprüft werden. Dazu ggf. ein zweites PowerShell-Fenster öffnen und folgende Informationen auslesen lassen und temporär merken.

$domainInformation = Get-ADDomain
$domainGuid = $domainInformation.ObjectGUID.ToString()
$domainName = $domainInformation.DnsRoot
$domainGuid
$domainName

Die nachfolgenden Befehle in das erste PowerShell-Fenster eingeben und prüfen, ob die angezeigten Informationen passen.

$storageacccount = Get-AzStorageAccount -ResourceGroupName "Ressourcengruppenname" -Name "Speicherkontoname"
$storageacccount | Get-AzStorageAccountKey -ListKerbKey | Format-Table Keyname
# Es sollten Schlüsselnamen angezeigt werden
$storageacccount.AzureFilesIdentityBasedAuth.DirectoryServiceOptions
# Ergebnis sollte "AD" sein
$storageacccount.AzureFilesIdentityBasedAuth.ActiveDirectoryProperties
# Die informationen sollten mit denen aus dem zweiten PowerShell-Fenster übereinstimmen(DomainName und DomainGUID)

Über das Azure-Portal können, in der Konfiguration des Speicherkontos, die Freigabeberechtigungen (via IAM) vorgenommen werden. Folgende Rollen sind hierfür relevant:

Hinweis: Alternativ können Berechtigungen auch direkt über die Freigabe im Windows-Explorer (ACL) vorgenommen werden.

Zuletzt den Azure Fileshare via CMD mounten damit er über den Explorer verwendet werden kann.

net use LAUFWERKBUCHSTABE: \\SPEICHERKONTONAME.file.core.windows.net\FREIGABENAME

Hinweis: Die Eingabeaufforderung muss als „normaler“ Benutzer ausgeführt werden und nicht als Administrator!

Der Beitrag Azure Files – Hybrid AD-Authentifizierung für Azure File Shares erschien zuerst auf Daniel Gutermuth.

Ich konnte des Öfteren beobachten, dass lokal angelegte Verteiler ihre Senden Als Attribute nicht korrekt in Exchange Online replizieren, was dazu führt, dass es entsprechenden Benutzer nicht möglich ist, E-Mails mit der Absendeadresse des Verteilers zu versenden. Auch eine explizite Konfiguration im Azure AD Connect brachte keine Besserung.

Die wohl einfachste Lösung wäre es den Verteiler lokale zu löschen und „cloud-only“ in Exchange Online anzulegen. Damit würde sich der Extraschritt der lokalen Konfiguration und der dazugehörigen Synchronisierung in das Azure AD und Exchange Online erübrigen.

Leider ist das nicht immer möglich und so muss eine andere Lösung gefunden werden.

Zusammengefasst besteht die Lösung daraus, dass via PowerShell eine Verbindung mit Exchange Online hergestellt und die Senden Als Berechtigung manuell hinzugefügt wird.

Vorbereitungen

• Das Senden Als Attribut wurde im lokalen Active Directory für den/die Benutzer gesetzt

• Die Objekte werden korrekt in das Azure AD synchronisiert

Lösung

Eine PowerShell-Sitzung als Administrator öffnen und das ExchangeOnlineManagement Modul installieren/laden.

Import-Module ExchangeOnlineManagement

Aufkommende Meldungen mit Ja bestätigen.

Anschließend mit dem Exchange Online Dienst verbinden.

Connect-ExchangeOnline 

Die Anmeldung muss mit einem Benutzer stattfinden, welcher entsprechende Berechtigungen für die Administration von Exchange Online besitzt.

Sobald die Verbindung erfolgreich hergestellt wurde, können Befehle abgesetzt werden.

Mit dem unten stehenden Befehl wird einem Benutzer das Senden-Als Recht auf einer Zielentität (z.B. Verteiler) gewährt. Dazu einfach die Variablen ziel@domain und SendenAlsBenutzer@domain mit den richtigen, eigenen Entitäten austauschen und abschließend mit Enter bestätigen.

Add-RecipientPermission -Identity ziel@domain -Trustee SendenAlsBenutzer@domain  -AccessRights SendAs 

Die aufkommende Meldung bestätigen.

Die Ausgabe bestätigt das erfolgreiche Hinzufügen des Attributes.

Zum Schluss die offene Verbindung zu Exchange Online wieder schließen.

Disconnect-ExchangeOnline

Auch diesen Befehl bestätigen.

Der Beitrag Exchange Online – Senden Als Berechtigung in Exchange / Azure AD Hybrid-Umgebungen erschien zuerst auf Daniel Gutermuth.

Damit solche Maschinen ihre Wiederherstellungskennwörter an das Azure AD übertragen, kann mit PowerShell nachgeholfen werden.

Lösung

Im ersten Script wird das Wiederherstellungskennwort des Systemlaufwerkes in das Azure AD gesichert. Der Mount Point bzw. der Laufwerksbuchstabe wird mit der Umgebungsvariablen $env:SystemDrive ermittelt.

Die Ausführung des Skriptes muss nicht mit den Anmeldedaten des aktuellen Benutzers erfolgen.

try{
$BLV = Get-BitLockerVolume -MountPoint $env:SystemDrive
        $KeyProtectorID=""
        foreach($keyProtector in $BLV.KeyProtector){
            if($keyProtector.KeyProtectorType -eq "RecoveryPassword"){
                $KeyProtectorID=$keyProtector.KeyProtectorId
                break;
            }
        }

       $result = BackupToAAD-BitLockerKeyProtector -MountPoint "$($env:SystemDrive)" -KeyProtectorId $KeyProtectorID
return $true
}
catch{
     return $false
}

Natürlich kann dieses Script auch in Intune eingebunden werden. Für bereits vorhandene BitLocker Bestandsmaschinen, kann damit unkompliziert der Wiederherstellungsschlüssel in das Azure AD gesichert werden.

Generell empfiehlt sich aber die Verwendung der entsprechenden BitLocker Richtlinie in Intune.

Dies wären die Einstellungen.

Eine Abwandlung des ersten Scripts ist in Script zwei zu finden. Hier wird das Wiederherstellungskennwort eines bestimmten Laufwerkes in das Azure AD gesichert.

Definiert wird das Laufwerk durch die Variable $MP (In diesem Beispiel D:)

try{
$MP = "D:"
$BLV = Get-BitLockerVolume -MountPoint $MP
        $KeyProtectorID=""
        foreach($keyProtector in $BLV.KeyProtector){
            if($keyProtector.KeyProtectorType -eq "RecoveryPassword"){
                $KeyProtectorID=$keyProtector.KeyProtectorId
                break;
            }
        }

       $result = BackupToAAD-BitLockerKeyProtector -MountPoint "$($MP)" -KeyProtectorId $KeyProtectorID
return $true
}
catch{
     return $false
}

In Intune stellt sich die Frage, warum es 41 Errors bei der Ausführung gab.

Das liegt daran, dass diese 41 Geräte kein Laufwerk D besitzen und das Script so nicht „erfolgreich“ abschließen konnte. Die Errors können daher, nach einer Verifizierung, ignoriert werden.

Auch hier die Einstellungen.

Es gibt sicherlich elegantere Methoden. Diese hier ist, wenn es um BitLocker Bestandsmaschinen geht, die ansonsten nicht Reporten wollen, bisher immer zuverlässig.

Der Beitrag BitLocker Wiederherstellungskennwort mit PowerShell in das Azure AD sichern erschien zuerst auf Daniel Gutermuth.

Dies muss gemacht werden, da Azure AD nicht mit privaten TLDs (domain.local, domain.intra) arbeiten kann.

Domäne:

• danielgutermuth.local = privat
• danielgutermuth.de = öffentlich

Benutzer:

• Benutzer@danielgutermuth.local = privat
• Benutzer@danielgutermuth.de = öffentlich

Hinweis: Es muss der Suffix verwendet werden, welcher auch in Microsoft 365 / Office 365 registriert ist und verwendet wird. Ist bei Microsoft 365 / Office 365 die Domain danielgutermuth.de registriert, dann muss der Suffix danielgutermuth.de auch lokal verwendet werden.

Lösung

Für die Umstellung des UPN-Suffixes auf dem Domänencontroller Active Directory-Domänen und -Vertrauensstellungen öffnen. Anschließend einen Rechtsklick auf Active Directory-Domänen und -Vertrauensstellungen machen und in die Eigenschaften gehen.

Im öffnenden Fenster den entsprechenden UPN-Suffix eintragen, hinzufügen und mit OK bestätigen.

Nun müssen die AD-Benutzer aktualisiert werden. Da eine manuelle Umstellung jedes einzelnen Benutzer eine sehr langwierige Aufgabe wäre, löst man es am besten mit PowerShell.

Im unteren Beispiel werden die UPN-Suffixe aller Benutzer mit dagu.local mit danielgutermuth.de ersetzt

$LocalUsers = Get-ADUser -Filter {UserPrincipalName -like '*dagu.local'} -Properties UserPrincipalName -ResultSetSize $null
$LocalUsers | foreach {$newUpn = $_.UserPrincipalName.Replace("dagu.local","danielgutermuth.de"); $_ | Set-ADUser -UserPrincipalName $newUpn}

Um sicher zu gehen, dass kein Benutzer mehr den alten Suffix enthält, muss der Output des nachfolgenden Scripts leer sein.

Get-ADUser -Filter {UserPrincipalName -like '*local'} | Sort-Object Name | Format-Table Name, UserPrincipalName

Der Beitrag Azure AD – UPN Suffix ändern erschien zuerst auf Daniel Gutermuth.