Hallo Serverfreunde,
heute möchte ich mich mal nicht mit Microsoft Exchange beschäftigen sondern das Feature „Work Folders“ vorstellen. Das Feature ist mit Windows Server 2012 R2 erstmals erschienen und kann sowohl für Windows 7 als auch für Windows 8.1 RT und Windows 8.1 verwendet werden.
Voraussetzungen für Workfolders
- DNS Name workfolders.domäne.dom
- SSL Zertifikate
- AD FS 3.0
- WAP
- Fileserver mit NTFS
Auch hier wird wieder klar das Microsoft die AD FS 3.0 für die Neuerung von Windows Server 2012 R2 verstärkt einsetzt. Workfolders innerhalb des Domänennetzwerkes benötigen keine AD FS!! Sollte aber der Zugriff über das Internet ermöglicht werden so benötige ich diese Dienste für Authentifizierung und natürlich auch für den Web Application Proxy. Ich empfehle den Einsatz auf einem Server der ausschließlich Fileserver ist und auf dem noch keine IIS o.ä. installiert ist. Ausgangsituation meiner Anleitung heute ist meine bereits bekannte Testumgebung die ich um einen Server erweitert habe. (siehe hier).
Diese neue Server bekommt die Workfolder – Rolle installiert. Ich habe bereits einen „öffentlichen“ DNS Eintrag erstellt: workfolders.sichel.com. Der Server hat passend zu dem Domänennamen ein Zertifikat erhalten, dieses habe ich vom ADFS- Server kopiert. Ich nutze weiterhin mein Wildcard Zertifikat mit dem identischen Thumbprint. Das ist zwar nicht wichtig, aber ich muss später mit dem Zertifikat noch arbeiten, daher der Hinweis.
Schritt 1 – Rolle installieren
- Auf dem Fileserver den Server Manager öffnen
- Rollen hinzufügen auswählen
- Datei und Speicherdienste –> Datei und iSCSI Dienste –> Arbeitsordner auswählen –> erforderliche Features hinzufügen –> Weiter (Bild 1)
- Den Assistenten abschließen und Rollendienst installieren lassen
- Über den Server Manager zu Arbeitsordner navigieren (Bild 2)
- Den Einrichtungsassistenten öffnen mit klick auf „Starten Sie zum Erstellen eine neuen….“
- Vorbereitungsfenster –> Weiter (Bild 3)
- Server und Pfad bestimmen –> Weiter (Bild 4)
- Benutzerordnerstruktur konfigurieren –> Weiter (Bild 5)
- Namen der Synchronisierungsfreigabe festlegen –> Weiter (Bild 6)
- Synchronisierungszugriff definieren –> Weiter (Bild 7)
- Geräterichtlinien Konfigurieren –> Weiter(Bild 8)
- Bestätigung und Übersicht –> Weiter (Bild 9)
- Freigabe wurde erstellt –> Fertig (Bild 10)
- Fertig
Ich habe mit Absicht einen Benutzer und keine Gruppe verwendet. Sobald ich eine Gruppe verwendet habe hat der Zugriff auf den Arbeitsordner nicht funktioniert :(
Hinweise zur Benutzerordnerstruktur (Quelle: TechNet):
Benutzeralias erstellt Benutzerordner, die keinen Domänennamen enthalten. Wählen Sie diese Benennungskonvention aus, wenn Sie eine Dateifreigabe verwenden, die bereits mit der Ordnerumleitung oder einer anderen Benutzerdatenlösung genutzt wird. Optional können Sie das Kontrollkästchen Nur den folgenden Unterordner synchronisieren aktivieren, um nur einen bestimmten Unterordner zu synchronisieren, z. B. den Ordner „Dokumente“.
Benutzeralias@Domäne erstellt Benutzerordner, die einen Domänennamen enthalten. Wählen Sie diese Benennungskonvention aus, wenn Sie keine bereits mit der Ordnerumleitung oder einer anderen Benutzerdatenlösung genutzte Dateifreigabe verwenden. Durch diese Einstellung werden Konflikte bei der Ordnerbenennung verhindert, wenn mehrere Benutzer der Freigabe identische Aliase haben (dies kann passieren, wenn die Benutzer unterschiedlichen Domänen angehören).
Schritt 2 – Zertifikatsbindung für Workfolders
Workfolders funktionieren ausschließlich mit SSL Zertifikaten. Ich habe bereits mein Wildcard-Zertifikat aus der vorherigen Konfiguration ( Server 2012 R2: Webanwendungsproxy mit Exchange 2013. Schritt 2 – Wildcard Zertifikat)! Dieses habe ich auf meinem Server mit installierte Workfolder Rolle in Computer\Eigene Zertifikat importiert (Bild 11).
Wichtig ist der „Thumbprint“ da ich das Zertifikat mit netsh an den Port 443 binden muss. Ähnlich wie hier: Exchange 2013 SP1 und ADFS Authentifizierung (Accept ADFS Claims).
- Zertifikat am APP2 auslesen
dir cert:localmachine\my
- Zertifikat auf APP2 an Port 443 binden
Try { $thumbprint = "B2D96D09F600EB701ECC0F9265A33207BD137D4B" $Command = "http add sslcert ipport=0.0.0.0:443 certhash=$thumbprint appid={CE66697B-3AA0-49D1-BDBD-A25C8359FD5D} certstorename=MY" $Command | netsh } Catch { "Fehler bei der Zertifikatsbindung" Exit }
Thumbprint bitte durch eigenen ersetzten. Das Zertifikat kann auch über das IIS SnapIn hinterlegt werden, dieses müsste jedoch zuvor installiert werden, was ich mir gespart habe ;)
Schritt 3 – ADFS Konfiguration
Auch hier werde ich wie in meine letzten Post keine komplexe Anleitung hinterlegen sondern ausschließlich ein PowerShell Script verwenden. Das ist deutlich weniger aufwendig als die 25 Steps in der ADFS Konsole.
ADFS Regel hinzufügen via PowerShell:
$URL = "https://Windows-Server-Work-Folders/V1"; $WorkFolders = "Workfolders"; $AnspruchsRegel = '@RuleTemplate = "LdapClaims" @RuleName = "ActiveDirectory" c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"), query = ";userPrincipalName,displayName,sn,givenName;{0}", param = c.Value);' ; $AusstellerRegel = '@RuleTemplate = "AllowAllAuthzRule" => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit",Value = "true");' ; Add-ADFSRelyingPartyTrust -Identifier $URL -Name $WorkFolders -IssuanceTransformRules $AnspruchsRegel -IssuanceAuthorizationRules $AusstellerRegel -EncryptClaims:$false -EnableJWT:$true -AllowedClientTypes Public;
- Nach anschließender Ausführung des Scripts habe ich eine neue Vertrauensstellung der vertrauenden Seite namens Workfolders (Bild 12)
- Diese beinhaltet die URL als Bezeichner (Bild 13)
- Via rechtsklick lassen sich die Anspruchsregeln einsehen / bearbeiten (Bild 14)
Schritt 4 – WAP Konfiguration
Nachdem also Workfolders und ADFS eingerichtet sind fehlt nur noch der Zugriff von außen via WAP. Auch das habe ich wiederholt mit einem PowerShell Script gelöst da es die Konfiguration vereinfacht:
$WAPCert = "B2D96D09F600EB701ECC0F9265A33207BD137D4B" $URL = "https://workfolders.sichel.com" Add-WebApplicationProxyApplication -BackendServerUrl "$URL/" -ExternalCertificateThumbprint $WAPCert -ExternalUrl "$URL/" -Name 'Workfolders' -ExternalPreAuthentication ADFS -ADFSRelyingPartyName 'Workfolders' Get-WebApplicationProxyApplication -Name "Workfolders" | Set-WebApplicationProxyApplication -UseOAuthAuthentication Write-host "WAP Regeln erfolgreich hinzugefügt"
Anschließend ist in der Remotezugriffs-Verwaltungskonsole folgender neuer Eintrag vorhanden:
- Workfolders (Bild 15)
Die Konfiguration ist damit vollständig abgeschlossen und der Benutzer kann sich mit dem Workfolder verbinden!
Schritt 5 – Internen Client verbinden
Es ist soweit, alle Konfigurationsschritte sind erfolgreich getätigt worden und der Benutzer kann nun mit seinem „Arbeitsordner“ arbeiten. Ich bleibe lieber bei der Englischen Bezeichnung da diese, so denke ich, populärer ist. An einem deutschen Windows System ist es nun mal als Arbeitsordner betitelt.
- Am Windows 8 Client mit einem Benutzer der berechtigt ist Workfolders zu nutzen anmelden
- Systemsteuerung –> „Arbeitsordner“ öffnen und Assistenten „Arbeitsordner einrichten“ starten (Bild 16)
- Im Assistenten die eigene E-Mail-Adresse eingeben und mit „Weiter“ bestätigen (Bild 17)
- Einführung von Workfolders und Speicherort bestimmen –> Weiter (Bild 18)
- Sicherheitsrichtlinien akzeptieren und „Arbeitsordner einrichten“ (Bild 19)
- Synchronisierung wurde gestartet (Bild 20)
- Unterhalb von „Dieser PC“ erscheint nun der Ordner Arbeitsordner (Bild 21)
In der Regel erhält der Benutzer beim Verbinde eine Anmeldeaufforderung zum Verbinden mit dem Arbeitsordner. Da ich allerdings folgenden Domänen in den Internetexplorer Optionen, unterhalb von Lokales Intranet, hinterlegt habe, werde ich automatisch angemeldet (Bild 22).
- https://adfs.sichel.com
- https://workfolders.sichel.com
Schritt 6 – Externen Client verbinden
Der externe Client wird identisch eingerichtet wie der Interne Client. Einziger Unterschied ist die ADFS Authentifizierung nachdem die E-Mail-Adresse eingegeben worden ist (Bild 23)
Weitere Hinweise
- Sollte die Automatische Konfiguration mit der E-Mail-Adresse nicht funktionieren so kann die Workfolders URL auch manuell eingegeben werden. Stimmt E-Mail-Domäne mit Workfolder-URL-Domäne allerdings überein sucht der Assistent anhand der Domäne in der E-Mail-Adresse nach der URL: Workfolders.domain.com.
- Zu Workfolders gibt es im übrigen auch ein Ereignislog in dem sämtliche Ereignisse Protokolliert werden. (Bild 24)
- Workfolders können vom Client auch wieder entfernet werden. Damit wird ausschließlich die Synchronisation beendet. Die Daten bleiben weiterhin auf dem PC, in dem zuvor bei der Einrichtung bestimmten Ordner, vorhanden. (Bild 25)
- Bei der erneuten Synchronisierung vom externen Client, bspw. nach einem Neustart, ist eine erneute ADFS Authentifizierung erforderlich. (Bild 26)
- Intern entfällt die erneute Anmeldung durch die Automtatische Anmeldung in der Zone Intranet. (Bild 27)
- Wie auf dem Arbeitsgruppen PC die Geräterichtlinien entfernt wird steht hier: Windows 8 Sicherheitsrichtlinien mit Exchange ActiveSync (EAS)
Puhhhh, geschafft :) Wie üblich alle Bilder in der Übersicht:
Ich hoffe doch es gefällt, wenn ja bitte teilen und posten :)
Andi
Danke für die unermüdliche Arbeit, die in diesem Blog steckt. Die Informationen sind für mich sehr hilfreich gewesen.
Liebe Grüße Alisa
Wollte mal liebe grüße da lassen.
Moin Moin, wir haben demnächst vor die Work Folder auf dem Server 2019 bereit zu stellen, es gibt aber noch ein paar Fragezeichen.
Wir haben bereits Home Folder und zwar \\domain.xx\u\Home die sollen auch bestehen bleiben.
Hallo,
Bei Workfolder hat ja jeder Benutzer seinen eigenen Ordner.
Kann ich die Daten für mehrere Benutzer sichtbar machen?
Hallo Dani,
nein. Die Workfolders sind Personalisiert und gehören jeweils dem Benutzer. Eine Freigabe wie bei OneDrive existiert nicht.
LG Andi
Ok, danke!
Ich kann jedoch dann einen Benutzer anlegen, der für mehrere Personen freigegeben wird!? Düfte hoffentlich keine Probleme machen!
Eine andere Lösung gibts ja nicht von microsoft… (außer vpn und das ist zu kompliziert für einzelne Personen)
(owncloud hab ich da auch schon versucht, funktioniert zwar, aber im lokalen netzwerk wieder unpraktisch, da die Ordner gesperrt sind und owncloud auch auf die Client-pc im netzwerk installiert werden muss, was sehr zu lasten der Festplatte geht)
lg dan
Hallo Andi,
gehe ich recht in der Annahme das die (lokalen) Adminberechtigungen nur zum tragen kommen wenn der Client die Arbeitsordner selbst einrichten/anschalten will?
Wird die Konfiguration per GPO angestubst sollte das hinfällig sein oder?
Abend,
Korrekt! Bei der Einrichtung der Workfolders durch den Benutzer sind zwingend Administrative Berechtigungen erforderlich, da Richtlinien auf dem PC gesetzt werden.
Wird hingegen die Steuerung über die Gruppenrichtlinien definiert, sind keine Weiteren Schritte durch den Benutzer erforderlich.
Vorteil der Workfolders ist natürlich die Benutzung von Non-Domain-Joined Clients ;)
LG Andi