Die meisten Lehrpersonen wissen, dass sie mit Google sehr einfach überprüfen können, ob die Schülerarbeit einfach aus einer Internetseite kopiert worden ist. Dazu muss man in Google nach ganzen Sätzen (oder Satzteilen) suchen, die so nicht in vielen Dokumenten stehen und diesen Text in Anführungs- und Schlusszeichen setzen.
Nach der Installation von Update Rollup 3 für DPM 2012 R2 gibt es eine Meldung im Server Manager, dass der Dienst “VSSNullProvider” beendet sei, obwohl der Starttyp auf automatisch gesetzt ist.
Gemäss dem “System Center: Data Protection Manager” Blog wird der VSSNullProvider Dienst nur für das Backup gestartet und danach wieder beendet. Man kann also die Meldung ignorieren, oder besser den Starttyp auf manuell setzen, damit die Meldung nicht mehr angezeigt wird.
Wie im 1. Teil beschrieben, favorisiere ich das Modell, bei dem die Passwörter von Office 365 mit den Passwörtern im lokalen Active Directory synchronisiert werden.
Um die Synchronisierung einzurichten, kann man “Benutzer und Gruppen” und dann “Aktive Benutzer” auswählen. Rechts wird nun “Active Directory Synchronisierung” angezeigt. Hier wählt man “Einrichten”.
Nun kann man unter Punkt 3 die Active Directory Synchronisierung aktivieren.
Unter Punkt 4 lässt sich nun das DirSync Tool herunterladen.
Um DirSync zu installieren, muss das .Net Framework 3.5 SP1 und 4.0 installiert sein.
Das .Net Framework 3.5 kann man über den Servermanager als Feature installieren. Unter Windows 2012 R2 ist das .Net Framework 4.5 bereits installiert. Die Version 4.0 muss also nicht installiert werden, da 4.5 die Version 4.0 bereits enthält.
Vor der Installation wird noch bemängelt, dass Powershell 2.0 benötig werde (obwohl $PSVersionTable ausgibt, dass Version 4 installiert sei).
Dies ist aber ein Fehler bei der Abfrage von Powershell. Man kann dies umgehen, indem man die Einstellungen fürs Zahlenformat auf Englisch stellt und sich ab- und wieder anmeldet. Dieses Verhalten wird bei der nächsten Version von DirSync behoben sein.
Danach funktioniert die Installation.
Wenn man das Häklein stehen lässt, startet direkt der Konfigurations-Assistent.
Auf der nächsten Seite kann man die Benutzerdaten für die Verbindung mit Office 365 eingeben.
Auf dieser Seite muss man die Anmeldeinformationen eines Kontos angeben, das Admin-Berechtigungen auf das lokale Active Directory hat.
Hier könnte man die “Hybride Bereitstellung aktivieren”. Da ich aber plane, den Exchangeserver bei uns ganz mit Office 365 zu ersetzen, lasse ich das Häklein weg. Ausserdem bin ich nicht sicher, ob das überhaupt gehen würde. Wir haben noch einen Exchange 2007 Server im Einsatz, ich meine aber gelesen zu haben, dass Exchange 2010 Mindestvoraussetzung sei.
Im nächsten Fenster sollte man “Kennwortsynchronisierung aktivieren” auswählen. Ziel ist es ja, dass für Office 365 das gleiche Kennwort wie für die Computeranmeldung im lokalen Netzwerk verwendet werden kann.
Nun kann man die Verzeichnisse synchronisieren.
Vor dem Abschluss des Konfigurations-Assistenten wird noch ein Link angezeigt, mit dem man überprüfen kann, ob die Verzeichnissynchronisierung korrekt durchgeführt wird.
Nach der Synchronisation findet man die Accounts im Portal.
Um die Synchronisierung zu überprüfen, kann man den “Synchronization Service Manager” verwenden. Dieser befindet sich unter C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell als Programm miisclient. Ich habe gleich eine Verknüpfung auf dem Desktop angelegt.
Hier lassen sich dann die Änderungen verfolgen. Durch einen Klick auf Updates, kann man einzelne Updates überprüfen.
Grundlage für diesen Beitrag war dieser Blog. Vielen Dank dafür.
Um einen manuellen Sync durchzuführen (z.B. weil man nicht so lange warten möchte), kann man das DirSync Modul in Powershell importieren und dann das Start-OnlineCoexistenceSync Cmdlet ausführen.
Import-Module DirSync
Start-OnlineCoexistenceSync
Wir filtern Spam unter anderem, indem wir eine Reverse DNS Abfrage machen. Bei Reverse DNS wird überprüft, ob die IP Adresse, von der die Mail verschickt wird, auch wirklich zu dem Namen gehört, der hinter dem @ Zeichen steht (also z.B. schalt.ch).
Nun hat sich jemand mit einer Hotmail Adresse beschwert, dass ein Mail nicht bei uns ankommt, andere aber schon. Im Log der Firewall, die die Spamfilterung bei uns übernimmt, sieht man, dass die Mails der betroffenen Hotmail Adresse über verschiedene Mailserver resp. IP’s verschickt wurde.
So gehören 157.55.2.76, 157.55.2.97, 157.55.2.92 zu Hotmail und sind auch korrekt im DNS registriert.
Dies kann man z.B. unter http://network-tools.com/ oder unter http://www.heise.de/netze/tools/dns/ überprüfen.
Aber die Adresse 157.55.0.209 ist nicht korrekt im DNS registriert und wird daher von unserem Spamfilter abgelehnt.
Ich habe nun mal ein Mail an die Adresse custserv@microsoft.com, die ich im Impressum der Hotmail Seite gefunden habe, geschickt. Mal schauen, ob sie die Adresse nun registrieren. Schliesslich sind ja nicht nur wir davon betroffen, sondern alle Mails die von Hotmail über diesen Server an Mailserver mit aktivierter Reverse DNS Abfrage verschickt werden.
Obwohl ich nur so eine doofe Standardantwort erhalten habe, die aufzeigte, dass niemand mein Mail gelesen hat, funktioniert nun die DNS Auflösung von 157.55.0.209. Scheinbar hat es auch noch jemand gemeldet, dessen Mails wirklich gelesen werden…
Auf http://www.sophos.com/de-de/support/knowledgebase/118843.aspx wird ein Tool angeboten, um einen defekten Accesspoint neu zu flashen.
Wir verwalten unsere Accesspoints von Sophos mit der Sophos UTM. Sobald ein Sophos Accesspoint am Netzwerk angeschlossen wird, versucht er Kontakt mit der Sophos UTM aufzunehmen. Dazu schickt er eine Anfrage an die Adresse 1.2.3.4 über den TCP Port 2712. Da die Adresse 1.2.3.4 im internen Netzwerk nicht existiert, wird sie durch die VLAN’s weiter nach “draussen” geroutet, bis beim Übergang zum Internet die Sophos UTM als Firewall und Gateway die Abfrage selber bearbeitet, statt weiter ins Internet zu leiten.
Quelle: http://www.sophos.com/de-de/support/knowledgebase/119131.aspx
Es gibt verschiedene Möglichkeiten, wie sich ein Client an einem WLAN Accesspoint authentifizieren kann. Wir haben es so umgesetzt, dass die Laptops ein Zertifikat erhalten, mit dem sie sich an einem Radiusserver ausweisen müssen, damit sie Zugang ins Netzwerk erhalten.
Diese Lösung hat diverse Vorteile. Zum einen lässt sie sich zentral verwalten. Ein weiterer Vorteil ist, dass niemand ein Passwort eingeben muss, dass vergessen oder weitergegeben werden kann. Ausserdem gilt diese Lösung als sehr sicher.
Wie man eine bestehende CA (Certificate Authority) migriert, wird auf dieser Technet Seite beschrieben. Auf dem Blog von Rachfahl findet man eine bebilderte Schritt-für-Schritt Anleitung. Dabei sollte der neue Server den gleichen Namen wie der alte haben. Ausserdem sollte der alte Server entfernt werden, bevor der neue eingesetzt wird. Wenn sich ein Problem ergeben sollte, ist der Rückweg versperrt. Auf dem Blog von Rachfahl wird die alte Zertifizierungsstelle zwar erst entfernt, nachdem die neue aufgesetzt wird, aber dies entspricht nicht dem empfohlenen Vorgehen gemäss der Technet Seite. Wenn man nach der Installation der neuen Zertifizierungsstelle die alte entfernt, könnte dies zu Problemen im Active Directory führen. Wie man die Einträge der CA im Active Directory findet, ist hier beschrieben. So habe ich mich aus diversen Überlegungen dazu entschieden, einen neuen Zertifikatserver aufzusetzen und den alten gar nicht zu migrieren.
Gemäss diesem Technet-Blog-Beitrag spricht nichts dagegen, zwei PKI’s parallel zu betreiben. Aus den oben angetönten Gründen habe ich mich für diesen Weg entschieden. So habe ich also einen weiteren Server in der Domäne erstellt (diesmal kein Domänencontroller).
Dazu muss man eine neue Rolle hinzufügen.
Hier kann man die Zertifikatsdienste auswählen und muss diese dann auch noch bestätigen.
Nach diversen Klicks auf “Weiter” habe ich als Rollen “Zertifizierungsstelle” und “Zertifizierungsstellen-Webregistrierung” ausgewählt.
Nach erfolgter Installation wird im Servermanager angezeigt, dass man die Zertifikatsdienste noch konfigurieren muss.
Als Installationstyp wählt man Unternehmenszertifizierungsstelle und danach Stammzertifizierungsstelle. Dies genügt für unsere Zwecke. Wer sich dafür interessiert, wie man eine deutlich komplexere Struktur (multi-tier hierarchy) einsetzt findet in diesem Technetblog einen guten Einstieg.
Beim Namen für die Zertifizierungsstelle wird ein Name vorgeschlagen. Diesen kann man ändern, was ich aber nicht gemacht habe.
Bei der Gültigkeitsdauer habe ich grosszügig 10 Jahre genommen. So bekommen wir sicher keine Probleme bis zum nächsten Serverwechsel.
Nach ein paar “Weiter” Klicks ist die Konfiguration beendet.
Die Zertifikate lassen sich automatisch über eine Gruppenrichtlinie verteilen.
Computerkonfiguration –> Richtlinien –> Windows-Einstellungen –> Sicherheitseinstellungen –> Richtlinien für öffentliche Schlüssel –> Zertifikatdienstclient – Automatische Registrierung
Computerkonfiguration –> Richtlinien –> Windows-Einstellungen –> Sicherheitseinstellungen –> Richtlinien für öffentliche Schlüssel –> Zertifikatdienstclient – Zertifikatregistrierungsrichtlinie
Computerkonfiguration –> Richtlinien –> Windows-Einstellungen –> Sicherheitseinstellungen –> Richtlinien für öffentliche Schlüssel –> Einstellungen der automatischen Zertifikatanforderung
Hier ein Zertifikat auswählen, das automatisch verteilt werden soll.
Tipp: Wenn man eine eigens erstellte Vorlage verwenden möchte (statt der Standardvorlage Computer), muss man die Schemaversion der Vorlage von 2 auf 1 ändern. Dazu kann man ADSI-Edit verwenden.
Da wir keine Passwörter eingeben, sondern uns mit einem Computerzertifikat authentifizieren wollen, verwenden wir ein PEAP-TLS Verbindungsprofil, das wir über eine Gruppenrichtlinie verteilen.
Computerkonfiguration –> Richtlinien –> Windows-Einstellungen –> Sicherheitseinstellungen –> Drahtlosnetzwerkrichtlinien (IEEE 802.11)
Durch einen Rechtsklick kann man eine neue Richtlinie hinzufügen.
Nun kann man der Richtlinie einen Namen geben und ein Infrastrukturprofil hinzufügen.
Hier kann man für ein Profil die entsprechenden SSID Namen hinzufügen.
Als Sicherheitsmethoden wird bereits WPA2-Enterprise mit AES Verschlüsselung vorgeschlagen, was im Moment die beste Sicherheit bietet.
Bei “Authentifizierungsmodus” wählt man “Computerauthentifizierung”. Ansonsten verliert der Computer die Verbindung, sobald sich jemand anmeldet. Dies könnte man umgehen, indem man auch Zertifikate für die Benutzer verteilen würde, was aber für unseren Einsatz nicht wirklich etwas bringt.
Bei “Netzwerkauthentifizierungsmethode” wählt man “Microsoft: Smartcard- oder anderes Zertifikat”. Durch einen Klick auf “Eigenschaften” kann man das Zertifikat angeben. Hier kann man einfach den Vorschlag “Zertifikat auf diesem Computer verwenden” akzeptieren. Unten muss man noch die Stammzertifizierungsstelle auswählen.
Die Clients bekommen nun also automatisch über eine Gruppenrichtlinie ein Zertifikat von der Zertifizierungsstelle (CA) und die passenden WLAN Einstellungen. Nun muss noch der Radiusserver (bei Microsoft Netzwerkrichtlinienserver NPS) konfiguriert werden. Dieser meldet den Accesspoints ob der Client eine Verbindung herstellen darf oder nicht (vgl. Grafik ganz oben).
Um NPS zu installieren, muss man über den Servermanager eine neue Rolle Netzwerkrichtlinien- und Zugriffsdienste hinzufügen.
Auf dem Radiusserver muss man nun die Clients (Accesspoints oder die Managementstation für die AP’s) hinzufügen und eine Richtlinie erstellen.
Um einen Client hinzuzufügen, macht man einen Rechtsklick auf “RADIUS-Clients” und wählt “Neu”.
Nun kann man Anzeigename, IP-Adresse und den gemeinsamen geheimen Schlüssel eintragen. Selbstverständlich muss man auf der Accesspoint-Seite die IP dieses Servers eingeben (resp. in meinem Fall anpassen) und den gleichen Schlüssel eintragen.
Mit einer Richtlinie kann man angeben, welche Voraussetzungen erfüllt sein müssen, damit der Radiusserver das OK für die Verbindung gibt. Man kann die Richtlinien manuell erstellen oder über den Szenario Assistenten erstellen lassen. Dazu wählt man bei “Erste Schritte” bei Standardkonfiguration “Radius-Server für drahtlose oder verkabelte 802.1X-Verbindungen” aus und klickt auf “802.1X konfigurieren”.
Im ersten Fenster wählt man “Sichere Drahtlosverbindungen” und gibt einen Namen für die Richtlinien.
Im nächsten Fenster könnten man die Radius-Clients hinzufügen. Einen habe ich schon vorher manuell hinzugefügt (vgl. oben).
Bei der Authentifizierungsmethode wählt man “Microsoft: Smartcard- oder anderes Zertifikat”
Nun kann man noch Benutzergruppen angeben. Dies habe ich nicht gemacht. Alle Computer mit gültigem Zertifikat dürfen sich bei uns über WLAN am Netzwerk anmelden, unabhängig vom angemeldeten Benutzer.
Auch Datenverkehrssteuerelemente werden in unserem Fall nicht benötigt.
Und so werden nun eine Verbindungsanforderungsrichtlinie und eine Netzwerkrichtlinie erstellt, die man manuell überprüfen kann.
Wichtig ist nun noch, dass man die Radius-Clients auch so umstellt, dass sie sich mit dem neuen Radiusserver verbinden.
So wie das oben beschrieben ist, kann man WLAN mit Zertifikaten neu aufsetzen. Wenn man aber wie ich einen alten Server ohne Unterbruch der WLAN Verbindungen ablösen möchte, gibt es noch ein paar Dinge, die man beachten sollte.
Wir haben bei der Verteilung der WLAN-Profile über Gruppenrichtlinien angegeben, dass die Identität des Servers über dessen Zertifikat überprüft werden soll. Wenn wir nun den Radiusserver wechseln, weist sich der neue mit dem neuen Zertifikat aus, was vom Client nicht automatisch akzeptiert wird. Daher muss man beim WLAN Profil beide Server als vertrauenswürdige Stammzertifizierungsstellen angeben.
Damit der Client diese Änderung bei den Gruppenrichtlinien erfährt, muss er einmal am Netzwerk gestartet werden. Dies bedeutet, dass man einen Zeitpunkt festlegen und dies den Mitarbeitern mitteilen muss, bis zu dem alle Laptops einmal gestartet werden müssen. Falls ein Laptop in dieser Zeit nicht gestartet wurde, kann er danach nicht mehr automatisch eine Verbindung mit dem Netzwerk herstellen. Am einfachsten startet man ihn dann einmal mit eingestecktem Netzwerkkabel, damit er die Einstellung erhält und danach auch wieder automatisch eine Verbindung über WLAN herstellt.
Da die beiden Zertifizierungsstellen (CA’s) im Active Directory eingetragen sind, vertrauen sie einander und auch den Zertifikaten voneinander. So spielt es also keine Rolle, von welcher Zertifizierungsstelle das Zertifikat des Clients ausgestellt wurde.
Solange die alte CA auch noch vorhanden ist, können beide Zertifikate ausliefern. Es kann aber nur eine CA Zertifikate ausliefern, die auch die entsprechende Zertifikatvorlage besitzt. Um die alte CA davon abzuhalten, neue Zertifikate auszuliefern, kann man also einfach die entsprechende Vorlage auf der alten CA löschen (in meinem Fall war das die Vorlage “Computer”).
Besser wäre eine duplizierte Vorlage, wie ich sie neu verwende. Dazu dupliziert man bei den Zertifikatvorlagen die Vorlage Computer.
Der neuen Vorlage habe ich den Namen “ComputerzertifikatWLAN” gegeben.
Wenn man nun nur bei der lokalen Zertifizierungsstelle des neuen Servers die Vorlage aktiviert, liefert auch nur dieser Zertifikate dieser Vorlage aus.
Sobald also alle Zertifikatvorlagen von der alten Zertifizierungsstelle gelöscht sind werden die Zertifikate von der neuen Zertifizierungsstelle ausgestellt. Wenn auf der neuen Zertifizierungsstelle die neu erstellte Vorlage die einzige für die Clientauthentifizierung ist, bekommen nun alle Clients ein solches Zertifikat, sobald sie ein neues anfordern.
Die alten Zertifikate bleiben aber bestehen, bis sie ablaufen, bei mir wäre das ein Jahr. Sinnvoll wäre es also, wenn die Clients schon vor Ablauf des Zertifikats ein neues beziehen, damit man den alten Server deinstallieren kann.
Die Zertifikate vom Computer kann man in einer Mangement Konsole (MMC) ansehen (mmc –> Datei –> Snap-In hinzufügen/entfernen –> Zertifikate –> Computerkonto) oder unter Windows 8 certlm.msc starten.
Wenn man einen Rechtsklick unter “Zertifikate (Lokaler Computer)” –> “Eigene Zertifikate” –> “Zertifikate” macht, kann man “Alle Aufgaben” –> “Neues Zertifikat anfordern…” auswählen und sich ein neues Zertifikat ausstellen lassen.
Man kann dies automatisieren, indem man bei den Zertifikatvorlagen die gewünschte auswählt und über einen Rechtsklick “Alle Zertifikatinhaber erneut registrieren” lässt.
Dies funktioniert aber leider nur mit duplizierten Vorlagen, die von mir damals verwendete Standard-Vorlage “Computer” lässt dies nicht zu.
Man kann auch mit dem Befehl “certreq” erreichen, dass ein neues Zertifikat von den Clients bezogen wird:
certreq -q -enroll -machine ComputerzertifikatWLAN
Diesen Befehl könnte man z.B. als renewcertificate.bat abspeichern und über SCCM an alle Clients verteilen. Windows 7 bringt aber eine Meldung wegen fehlender Berechtigung (obwohl die Berechtigung über den Weg mit der graphischen MMC ausreicht und der gleiche Befehl unter Windows 8 problemlos funktioniert).
Wenn man eine neue Vorlage erstellt und diese über die automatische Zertifikatanforderung verteilt, wird diese beim nächsten Start bezogen. So bekommen alle Computer schnell ein Zertifikat vom neuen Server. Somit kann demnächst der alte Server deinstalliert werden…
Um Objekte im Active Directory anzuzeigen, verwendet man oft den ADSI-Editor (adsiedet.msc). Standardmässig werden aber nicht alle Objekte angezeigt. So sieht man z.B. die Objekte nicht,, die von einer CA (Zertifizierungsstelle) im Active Directory eingetragen werden, wenn man eine PKI (Public-Key-Infrastruktur) einsetzt.
CN=Public Key Services, CN=Services, CN=Configuration, DC=<forestRootPartition>.
Um diese Einträge anzeigen zu lassen, muss man sich mit der Konfigurations-Partition verbinden. Dazu macht man einen Rechtsklick auf ADSI-Editor und wählt “Verbindung herstellen…”
Nun wählt man unter “Bekannten Namenskontext auswählen:” den Eintrag “Konfiguration” aus.
![image_thumb[1]](https://ictschule.com/wp-content/uploads/2014/08/image_thumb1.png "image_thumb[1]")
Unter Services –> Public Key Services findet man die einzelnen Container, die von Bedeutung für eine PKI sind. Die Bedeutung der einzelnen Container ist in diesem Technet Beitrag beschrieben.
![image_thumb[2]](https://ictschule.com/wp-content/uploads/2014/08/image_thumb2.png "image_thumb[2]")
Ich wurde auf die interessante Dokumentation “Zugriff! Wenn das Netz zum Gegner wird” in der ARD Mediathek aufmerksam gemacht. Eine Reporterin versucht herauszufinden, wie weit man mit professioneller Hilfe kommt und hackt die Daten ihres Arbeitskollegen.
Dabei wird auch immer wieder erwähnt, dass die Daten von amerikanischen Cloud-Anbietern durch die NSA abgegriffen werden können.
Umgekehrt wehrt sich Microsoft gerade gegen die Herausgabe von Daten aus einem europäischen Rechenzentrum an US-Behörden, obwohl es da scheinbar um Ermittlungen im Zusammenhang mit Drogenschmuggel geht (und damit wohl auch ein Rechtshilfegesuch genügen müsste). Daraus lässt sich immerhin ablesen, dass die US-Behörden scheinbar noch nicht automatisch Zugriff auf Rechenzentren in Europa haben.
Nach einem Update unserer Sophos UTM auf die Version 9.204-20 funktionierten alle von uns veröffentlichten Webseiten nicht mehr. Auch konnten die Mails nicht mehr über ActiveSync synchronisiert werden. Eine Recherche brachte mich dann auf diesen Beitrag im Sophos Forum, der mich dann zu diesem Knowledgebase Beitrag führte.
Man muss also bei “Web Application Firewall” bei der Registerkarte “Firewall Profiles” das Häklein bei “Common Threats Filter” entfernen und dies für alle Firewallprofile wiederholen, bei denen das Häklein gesetzt ist.
Danach müssen alle virtuellen Webserver deaktiviert und wieder aktiviert werden.
Am Schluss kann man die Häklein bei “Common Threats Filter” wieder setzen.
ictschule 