In diesem Video wird erklärt, welche Funktionen der Office 365 Plan für unsere Schule beinhaltet.
Office 365 – Einleitung
Kommentar verfassen
Archiv der Kategorie: ICT
openhpi – Sicherheit im Internet
Schon mein zweiter MOOC (Massive Open Online Course) bei openhpi. Dieses Mal ging es um Sicherheit im Internet. Der Kurs ist zwar nun abgeschlossen, aber man kann ihn immer noch durcharbeiten, einfach ohne Möglichkeit für ein Zertifikat. Um sich theoretisches Grundlagenwissen zu Sicherheit im Internet anzueignen oder zu vertiefen, eignet sich der Kurs bestens. Ich hatte mir noch erhofft, dass ich mehr über die Abwehr von Angriffen auf Netzwerke erfahren könnte, aber es geht beim Kurs eher um die Theorie von Angriffen und Abwehr. Aber auch das bringt ja etwas, also durchaus empfehlenswert.
Office 365 – Kennwort nie ändern
Wir haben ein paar Mailaccounts, deren Passwort nie ablaufen sollte, wie z.b. der Account unter dem die Kopierer ihre Scans per Mail verschicken oder die Telefonanlage ihre Voicemail-Aufzeichnungen. Im Office 365 Portal gibt es nur die Möglichkeit eine Zeit zwischen 14 und 730 Tagen einzustellen, aber keine, damit das Passwort nie geändert werden müsste.
Dies lässt sich aber über die Powershell erledigen. Ich bin diesem Technet-Artikel gefolgt. Als erstes muss man den Microsoft Online Services-Anmelde-Assistenten für IT-Experten RTW und Azure Active Directory-Modul für Windows PowerShell (64-Bit-Version) installieren. Man sollte diese Programme aber nicht auf dem Server installieren, auf dem DirSync ausgeführt wird. Bei mir funktionierte danach DirSync nicht mehr.
Nun kann man das neu installierte “Windows Azure Active Directory-Modul für Windows PowerShell” starten und sich mit Office 365 verbinden.
connect-msolservice
Nun kann man gemäss dieser Seite mit folgendem Befehl festlegen, dass das Passwort des entsprechenden Benutzers nicht mehr abläuft.
Set-MsolUser -UserPrincipalName <user ID> -PasswordNeverExpires $true
Nachtrag:
Neu kann man das gleiche mit MgGraph erreichen:
Connect-MgGraph -Scopes "User.ReadWrite.All","Group.ReadWrite.All"
Update-MgUser -UserId user@contoso.com -PasswordPolicies DisablePasswordExpiration
Um zu überprüfen, ob bei einem Account eingestellt ist, dass das Passwort nie abläuft, kann man diesen Befehl verwenden.
Get-MgUser -UserId user@contoso.com -Property UserPrincipalName, PasswordPolicies |
Select-Object UserPrincipalName,@{N="PasswordNeverExpires";E={$_.PasswordPolicies -contains "DisablePasswordExpiration"}}
Office 365 – nicht alle Benutzer synchronisieren
Standardmässig werden von DirSync alle Benutzer synchronisiert. Diese Benutzer können dann für das Abrufen der Mails von Office 365 das Passwort benutzen, das sie auch für die Anmeldung innerhalb des Netzwerks benutzen. Bevor das Passwort abläuft, werden sie am Computer aufgefordert, dieses zu ändern.
Wir haben aber Mailaccounts für Schulratsmitglieder, Sekretariatsmitarbeiter/-innen und andere, die nie an einem Computer innerhalb des Schulnetzwerks arbeiten. Damit diese eine Mailadresse erhalten, mussten wir einen Benutzeraccount im AD anlegen. Das Passwort konnten sie von extern über Outlook Web Access (OWA) zurücksetzen, auch nachdem dieses abgelaufen war. Für diese Benutzer erstellt man besser nur in Office 365 einen Account und löscht den lokalen nach der Migration des Postfachs.
Um in DirSync die OU’s herauszufiltern, die man nicht synchronisiert haben möchte, kann man im “Synchronization Service Manager” “Management Agents” und dann den “Active Directory Connector” auswählen und dann auf “Properties” klicken. In dem sich öffnenden Fenster wählt man “Configure Directory Partitions” und dann “Containers…”
Man muss sich dann mit Benutzernamen und Passwort mit Administratorberechtigungen für das lokale AD anmelden. Den voreingestellten Benutzernamen kann man einfach überschreiben.
Hier kann man nun alle Häklein ausser bei den gewünschten OU’s entfernen.
Nachdem sollte man einen “Full Import Full Sync” ausführen. Die Accounts in den nicht mehr synchronisierten OU’s werden dabei in Office 365 gelöscht. Diese können nun manuell als nicht synchronisierte “cloud only” Accounts in Office 365 angelegt werden.
Man kann übrigens solche nicht synchronisierte Accounts ganz normal über einen Migration-Batch in die Cloud migrieren. Nur die Mailadresse muss stimmen, die Accounts müssen lokal und in Office365 nicht einmal das gleiche Passwort besitzen.
PHP-Cache
Wir bekommen eine neue Webseite, die auch wieder unter Typo3 entwickelt wurde. Da sie aber diverse dynamische Elemente beinhaltet, dauert das Laden der Seiten deutlich länger, als bei den bisherigen Seiten. Also musste ich mich wieder einmal vertiefter mit Linux und Typo3 auseinandersetzen.
Gemäss Internetrecherche gibt es viele Hebel, an denen man ansetzen kann, aber mit Abstand am meisten bringt es die PHP Dateien zu cachen. Ich habe mich für APC (Alternative PHP Cache) entschieden. Ab PHP 5.5 wird das nicht mehr benötigt, da ein PHP Cache direkt mit PHP kommt. Da wir aber noch weitere Homepages haben, die im Moment einen Wechsel auf die neue Version verhindern, musste ich leider doch APC installieren und konfigurieren.
Um APC zu installieren, bin ich dieser Anleitung gefolgt, ausser dass ich 256 MB Ram zugewiesen habe. Wenn dann z.B. nach einem Update APC nicht mehr benötigt wird, kann man es einfach durch “apt-get remove –purge php-apc” wieder entfernen.
Sophos UTM – Problem mit Mailempfang wegen Poodle
Wegen einer Sicherheitslücke mit dem Namen Poodle gilt SSL in Version 3 als nicht mehr sicher. Eine anschauliche Erklärung zum grundsätzlichen Problem findet sich hier.
Mit dem Update 9.210-20 hat Sophos die Unterstützung für SSLv3 in seinem Firewallprodukt Sophos UTM deaktiviert. Dies ist grundsätzlich ein richtiger Entscheid, da SSLv3 nicht mehr sicher ist.
Nun gibt es aber noch diverse Mailserver, die mit SSLv3 verschlüsseln wollen, statt mit dem neueren TLS 1.2. So wurde uns zurückgemeldet, dass Mails mit der Fehlermeldung “4.7.0 TLS handshake failed” nicht an uns zugestellt werden konnten.
Ein Test unter https://ssl-tools.net lieferte dann das Ergebnis, dass der eingesetzte Mailserver nur SSLv3 und TLSv1.0 unterstützt.
Unsere Firewall unterstützt seit dem Update zur Behebung des Poodle Bugs aber nur noch die sicherste Version TLSv1.2
Die betroffenen IP’s kann man im SMTP Protokoll finden. Vielen Dank für diesen Blogbeitrag, der mir weitergeholfen hat.
In der Version 9.303 sollte das Problem behoben sein (ich gehe davon aus, dass dann zumindest TLSv1.0 und TLSv1.1 auch unterstützt werden, aber nicht SSLv3). Leider kann ich nicht auf Version 9.303 updaten, da es noch keinen Updatepfad für die Version 9.210 gibt. Dieser sollte diese Woche verfügbar sein.
In der Zwischenzeit habe ich für die betroffenen Mailserver (bisher zwei) eine Ausnahme generiert, damit sie wenigstens unverschlüsselt senden können und melde deren Admins, dass sie trotzdem am besten TSLv1.2 unterstützen (und vor allem die Unterstützung von SSLv3 deaktivieren) sollten.
Um die Ausnahme einzutragen, kann man unter “Email Protection” –> “SMTP” –> Registerkarte “Advanced” bei “TLS settings” unter “Skip TLS negotiation hosts/nets” die betroffenen IP’s eintragen.
PDF Formulare mit Scribus erstellen
In unserem Sekretariat kam der Wunsch auf, dass man PDF-Formulare, die wir auf unserer Homepage anbieten, auch am Computer ausfüllen können sollte.
Gemäss c’t Artikel gibt es da verschiedene Möglichkeiten mit verschiedenen Vor- und Nachteilen.
Ich habe mich dann für die Gratislösung Scribus entschieden, mit der sich das Gewünschte gut umsetzen liess.
Beim Öffnen eines Dokuments kann man auswählen, welches Standardmass man verwenden möchte. Ich wähle da Zentimeter, weil ich mir so die Abstände besser vorstellen kann, als z.B. mit Punkten.
Scribus ist ein DTP Programm und anders als in Word muss man zuerst ein Textfeld aufziehen, bevor man Text einfüllt.
Wenn man einen Rechtsklick auf ein Textfeld macht, öffnet sich das Kontextmenü, aus dem man “Eigenschaften” auswählen kann. Alternativ kann man auch die Taste F2 drücken, was hilfreich ist, da man doch sehr oft die Eigenschaften von einem Element benötigt.
Durch die Angabe der gewünschten Zentimeter bei Geometrie kann man ein Element genau ausrichten.
Um ein Formularfeld aufzuziehen kann man in der Menüleiste das richtige Werkzeug auswählen und eine entsprechende Form auswählen.
Dieses Formularfeld soll also von Hand wie auch am Computer ausgefüllt werden können. Um es von Hand auszufüllen, macht eine Höhe von 1 cm wohl Sinn, damit man genügend Platz zum Schreiben hat.
Damit bei einer Höhe von 1 cm die Computerschrift nicht ganz oben am Feld klebt, muss man ein wenig rechnen. Eine 12pt Schrift ist etwa 4,233333mm hoch (vgl. http://de.wikipedia.org/wiki/Schriftgrad#DTP-Punkt). Wenn man also so eine Schrift innerhalb eines 1 cm hohen Feldes vertikal zentrieren möchte, ergibt sich also oben und unten ein Abstand von (10mm – 4,233333…mm)/2 = 2,88333333mm. Auf zwei Nachkommastellen gerundet also etwa 2,89mm. Diesen Wert kann man bei “Spalten & Textabstände” unter “Oben:” eintragen.
Wenn man den gleichen Wert beim Textfeld und beim Formularfeld einträgt, ist die Schrift jeweils in der Mitte von Feld.
Wenn man nun das Dokument über “Exportieren” –> “Als PDF speichern…” exportiert, sollte man unter “Kompatibilität” “PDF 1.3” auswählen. So erhält man ein Dokument, das sowohl von Hand als auch am Computer ausgefüllt werden kann.
Office 365 – Outlook Profil anpassen
Bei der Installation von Office auf Computern kann man die einzelnen Komponenten mit dem “Office Customization Tool” (OCT) anpassen. Damit die Benutzer kein eigenes Profil für Outlook erstellen müssen, habe darüber ein Profil verteilt, das den lokalen Exchangeserver als Server eingetragen hat.
Für Benutzer, die Outlook noch nie geöffnet haben, wird beim ersten Öffnen von Outlook ein Profil erstellt. Wenn nun solche Benutzer nach Office 365 migriert werden, erstellt Outlook automatisch die neuen Einträge wie in diesem Artikel ganz unten beschrieben.
Wenn nun aber ein Benutzer bereits nach Office 365 migriert ist, bevor er das erste Mal Outlook geöffnet hat, wird beim ersten Start versucht, die Verbindung mit dem lokalen Exchangeserver, der über das Office-Anpassungstool (OCT) eingetragen wurde, herzustellen. Das geht aber nicht und Outlook lässt sich dann nicht öffnen.
Um diesen Fall aufzufangen, kann man mit dem OCT eine MSP-Datei erstellen, die sich verteilen lässt. Da bei der Installation von Office damals OCT benutzt wurde, kann man einfach die Installationsdateien z.B. auf eine virtuelle Maschine kopieren und “setup.exe /admin” ausführen.
Wenn man nun unter “Outlook-Profil” –> “Vorhandenes Profil verwenden:” auswählt, wird nichts an bereits eingerichteten Profilen geändert, aber bei der Neuerstellung von einem Profil kommt die Abfrage und es wird nicht mehr versucht, mit dem voreingestellten lokalen Exchangeserver Kontakt aufzunehmen.
Ich ändere gerade auch noch die Einstellung für den Cachemodus (aus anderen Gründen).
Über “Datei” –> “Speichern” kann man die Einstellungen als MSP-Datei speichern und diese z.B. mit SCCM verteilen. Das Programm könnte z.B. lauten:
msiexec /p Office365.msp /qn
Wenn sich nun ein Benutzer zum ersten Mal anmeldet, kommt wie gewünscht der Start-Assistent.
Da kann man sich durchklicken, bis zur Anmeldung. Hier muss man als Benutzernamen die vollständige Mailadresse und das Passwort eingeben.
Wenn das Postfach bereits eingerichtet ist, der Benutzer also Outlook schon einmal geöffnet hat, ändert sich nichts, man muss den Assistenten nicht durchklicken.
Office 365 – Teil 5: Benutzer migrieren
Es gibt verschiedene Wege, die Benutzer auf Office 365 zu migrieren. Mit dem Exchange 2013 Server Deployment Assistant kann man herausfinden, welche Migration für die eigene Umgebung in Frage kommt.
In meinem Fall mit mehr als 1’000 Accounts und einem Exchange 2007 Server wählt man die sogenannte “Staged Exchange Migration”.
Die “Staged Exchange Migration” kann sich über mehrere Wochen oder sogar Monate hinziehen. Wichtig ist, dass bis zum Abschluss der Migration die öffentlichen DNS-Einträge (Autodiscover- und MX-Einträge) auf den lokalen Exchange Server zeigen. Dies bedeutet zwar, dass im Office 365 Admin Center die Domänen ein rotes Kreuz haben, was aber während der Migration richtig ist.
Der lokale Exchangeserver leitet nämlich die an ihn gerichteten Mails der bereits migrierten Benutzer an Office 365 weiter. Erst wenn alle Benutzer migriert sind, kann man die DNS Einträge auf Office 365 umstellen, damit die Mails direkt dorthin geroutet werden.
Wenn alles vorbereitet ist, kann man gemäss diesem Technet Artikel eine CSV-Datei für die Migration bereitstellen. Da das Passwort über DirSync mit dem Active Directory synchronisiert wird, benötigt man nur die Spalte “EmailAddress”. In einer CSV-Datei dürfen maximal 1’000 User vorkommen.
Diese CSV-Datei kann man nun im “Exchange Admin Center” vom Office 365 Portal”“ unter “Empfänger” –> “Migration” hinzufügen.
Beim Migrationstyp wählt man aus den oben erwähnten Gründen “Mehrstufige Migration”, also eine “staged migration”.
Im nächsten Fenster wählt man die vorher erstellte CSV-Datei aus.
Als nächstes muss man die Angaben zum Server angeben.
Nun muss man dem Migrationsbatch noch einen Namen vergeben.
Wenn man möchte, dass man per Mail über die erfolgreiche Abarbeitung des Batches informiert wird, kann man eine Mailadresse eintragen.
Nachdem der Migrationsbatch durchgelaufen ist, haben die migrierten Benutzer zwei Postfächer, eines auf dem lokalen Exchangeserver und eines in Office 365. Mails werden wegen den noch nicht umgestellten DNS Einträgen weiterhin an den lokalen Exchangeserver geliefert, welcher nun die Mails an Office 365 weiterleitet. Dies wird erreicht, indem im Active Directory die Adresse von Office 365 bei targetAddress eingetragen wird. Man kann dies mit dem ADSI-Editor überprüfen.
Ein Problem bleibt nun aber das bestehende Postfach auf dem lokalen Exchangeserver. So verbindet sich z.B. Outlook über den Autodiscover-Eintrag weiterhin mit dem lokalen Exchangeserver. Dieses und weitere Probleme kann man beheben, indem man das Benutzerpostfach auf dem lokalen Exchangeserver zu einem “mail-enabled user” abändert. Microsoft stellt dafür eine Anleitung und Powershellskripts zur Verfügung.
Als erstes lädt man die beiden Powershellskripts in einen Ordner, kopiert die CSV-Datei mit den migrierten Benutzern dazu und ändert den Namen auf migration.csv.
Nun kann man in der Exchange Management Shell das erste Skript .\ExportO365UserInfo.ps1 ausführen lassen.
Für die Verbindung mit Office 365 muss man sich mit Benutzernamen und Passwort für Office 365 anmelden.
Wenn das Skript erfolgreich durchgelaufen ist, wird eine neue Datei cloud.csv erstellt.
Mit .\Exchange2007MBtoMEU.ps1 <FQDN von einem Domänencontroller> kann man nun die Umwandlung auslösen.
Wenn alles erfolgreich gelaufen ist, haben die Accounts kein Postfach mehr in Exchange, sondern sind nur noch als E-Mail-Kontakt mit der externen Mailadresse von Office 365 aufgeführt.
Im Office 365 Portal kann man nun unter “Benutzer” –> “Aktive Benutzer” die migrierten Benutzer auswählen.
Tipp: Ich habe mir eine neue Ansicht erstellt, die die Benutzer mit einem Postfach, aber ohne Lizenz anzeigt. Dies sind dann gerade die noch zu ändernden Benutzer.
Diese kann man nun alle auswählen und bearbeiten. So kann man für alle migrierten Benutzer die Standarddomäne auswählen, den Benutzerstandort auf Schweiz setzen und eine Lizenz zuweisen.
Wenn alles korrekt funktioniert hat, kann man den Batch im Exchange Admin Center unter “Empfänger” –> “Migration” beenden und löschen
Die migrierten Benutzer können sich nun auf verschiedenen Wegen anmelden. An Outlook Web App kann man sich über https://outlook.office365.com und am Portal über https://portal.office365.com anmelden.
Bei der ersten Anmeldung muss man noch Sprache und Zeitzone auswählen.
Über Active Sync kann man wie gewohnt ein neues Exchange Konto hinzufügen und die persönlichen Daten eintragen. Bei mir genügten die Mailadresse und das Passwort nicht. Es wurde auch der Benutzername (gleich wie Mailadresse) und der Server (outlook.office365.com) abgefragt. Ich gehe davon aus, dass dies nicht mehr nötig ist, wenn nach der vollständigen Migration die DNS Einträge angepasst sind.
Bei einem bereits eingerichteten Outlook Profil muss man die neue Verbindung herstellen. Beim Starten von Outlook erscheint ein Anmeldefenster. Beim Benutzernamen wird die intern verwendete Domäne vorgeschlagen, welche auf die korrekte öffentliche Mailadresse geändert werden muss.
Am Schluss kommt eine Meldung, dass Outlook nun neu gestartet werden muss.
Danach startet Outlook korrekt mit der neuen Verbindung zu Office 365.
Über diese Änderungen sollte man die Benutzer mit einer Anleitung informieren.
Alternativ könnte man mit dem “Office Customization Tool” eine angepasste MSP-Datei erstellen, die sich dann verteilen lässt. Wegen einem Problem mit Benutzern, die Outlook noch nie geöffnet haben, musste ich so eine angepasste MSP-Datei verteilen. Weitere Informationen findet man in diesem Beitrag.
Es bleiben ein paar weitere “Real-World” Probleme.
Public Folders
Microsoft bietet zwar Skripts zum Migrieren der öffentlichen Ordner, aber solange diese Skripts nicht ausgeführt wurden, können die migrierten Benutzer nicht auf die öffentlichen Ordner zugreifen und nachdem sie ausgeführt wurden, können die noch nicht migrierten Benutzer nicht mehr auf sie zugreifen…
Passwort ändern
Bisher konnten Benutzer, die nicht an einem Computer in unserem Netzwerk arbeiten (z.b. Schulräte), ihr Passwort von extern über Outlook Web Access (OWA) zurücksetzen, auch nachdem es abgelaufen ist. Da DirSync aber die lokalen Passwörter nach Office 365 synchronisiert, können die Passwörter nur noch von intern geändert werden. Der beste Weg wird wohl sein, nicht das ganze AD zu synchronisieren und für diese Benutzer nicht synchronisierte “cloud-only” Accounts anzulegen.
Informatik-Biber 2014 Resultate
Auch dieses Jahr haben wir wieder am Informatik-Biber teilgenommen. Neben einem ersten Platz in der Einzelwertung der Stufe 3/4 hatten wir wieder sehr viele Teilnehmer in den einzelnen Kategorien, so dass wir wieder einige Preise erhalten haben.
Für die Kategorien haben wir Robokits erhalten.
ictschule 