mwiederkehr

Bei Verteilergruppen bleibt soweit ich weiss der ursprüngliche Empfänger erhalten. Du könntest also statt den Aliases Verteilergruppen erstellen, in welchen der Benutzer Mitglied ist.

HPE hat Microcode-Updates für diverse Server zurückgezogen: https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-a00039784en_us&hprpt_id=HPGL_ALERTS_1997685&jumpid=em_alerts_us-us_Jan18_xbu_all_all_1422961_1997685_SynergyServersMoonshotSystems_critical__&DIMID=EMID_72E7628E3A0715627796F604F977455F/ Laut Artikel hat Intel Probleme gemeldet und arbeitet an einem neuen Update. Geht wohl um die unerklärlichen Abstürze, von denen im Heise-Artikel die Rede war.

Eigentlich sollte es schon gehen, Client Zertifikate sind ja in etwa ein umgekehrter Handshake und dann eine neue TLS-Verbindung. Wireshark muss natürlich den private Key des Client Zertifikats ebenfalls haben. Aber verwendet die Verbindung evtl. PFS? Dann ist eine nachträgliche Entschlüsselung nicht möglich, selbst wenn man die Private Keys hat. Ein Proxy wie Fiddler ist deshalb wohl die bessere Lösung.

Soweit ich weiss sind Dokumente im Office Open XML-Format (docx, xlsx), die mit einem Passwort zum Öffnen versehen sind, richtig verschlüsselt. Man kann das Passwort nicht wie bei .doc und .xls mit dem Hex-Editor rausoperieren. Der Blattschutz ist aber nach wie vor kein richtiger Schutz, den kann man mit einem Texteditor entfernen.

Im Gegensatz zu produktiven Servern haben Testserver im Homelab meist viel weniger zu tun. Deshalb sollten Consumer SSD recht lange halten. Habe gerade auf meinem Server mit einer Samsung SSD EVO nachgeschaut, in Betrieb seit Herbst 2015. Auf dem Server laufen um die fünf VMs, Windows und Linux, einmal SQL, einmal Exchange. Total geschrieben wurden bisher 23 TB. Samsung nennt keine Disk Writes per Day, aber gibt eine Garantie bis 75 TB. Demnach sollte die SSD noch 5 Jahre halten. In einem MSA P2000 G3 haben wir mal drei Samsung SSD installiert und darauf eine Kopie der produktiven Umgebung für Testzwecke laufen lassen. Die hatte mehr Last und nach knapp drei Jahren sind zwei der drei SSD fast gleichzeitig ausgefallen. Im Gegensatz zu den teuren SSD von HP natürlich ohne Vorwarnung.

Mit "untrusted code" meinen sie wohl Code, welcher ungeprüft von aussen kommt und ausgeführt wird. Also zum Beispiel Terminalserver (Benutzer lädt Programm herunter) oder Webserver (Hostingkunde lädt PHP-Anwendung hoch). Ein Fileserver fällt nicht darunter und dort muss die Mitigation nicht aktiviert werden, wenn ich die Doku richtig verstanden habe. Wohl deshalb ist die Mitigation auf Servern nach der Installation des Updates nicht automatisch aktiviert, sondern muss per Registry aktiviert werden. Microsoft nennt unter https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution drei Fälle, in welchen die Mitigation aktiviert werden sollte: - Hyper-V Hosts: damit nicht von einer VM auf den Speicher einer anderen VM zugegriffen werden kann - Terminalserver: da läuft fast immer "untrusted code", und sei es nur JavaScript im Browser - Server, auf denen "untrusted code" läuft wie Webserver Ganz allgemein halte ich die Aufregung für etwas übertrieben. Einerseits soll sich die Lücke nicht so gut ausnutzen lassen wie zuerst befürchtet (Meltdown soll nur auslesen können, was im L1-Cache ist) und andererseits sehe ich (noch) kein Szenario für flächendeckende Angriffe. Zielgerichtete Angriffe auf lohnenswerte Ziele auf jeden Fall, aber was bringt es einem Angreifer, wenn er mit viel Aufwand ein Zertifikat für kleinfirma.de aus dem Speicher extrahieren kann? Vielleicht bin ich zu ängstlich, aber ich halte die Installation von frisch dem Compiler entschlüpften Microcode-Updates auf allen Hosts für das grössere Risiko für den stabilen Betrieb als die offenen Lücken. Habe deshalb nur die Hosts gepatcht, auf denen VMs mit "untrusted code" laufen und noch nicht ganze Cluster.

Mit dem Sejda SDK (http://sejda.org/) sollte es gehen von der Kommandozeile aus. Nachteil: benötigt Java. Falls PowerShell eine Option ist: damit kann man direkt .NET-Libraries ansteuern und für .NET gibt es gute PDF-Tools. Ein Beispiel für die Nutzung von PDFSharp: http://support.coolorange.com/support/solutions/articles/22000211000-how-to-merge-multiple-pdf-with-pdfsharp-and-powershell Mit der DLL und dem PowerShell-Modul kannst Du aus Deinem Script einen Aufruf starten, der alle Dateien in einem Verzeichnis zusammenfügt, unabhängig deren Namen: $files = Get-ChildItem "C:\temp\PDF\Source" -Filter "*.pdf" MergePdf -Files $files -DestinationFile "C:\TEMP\PDF\Destination\test.pdf" -PdfSharpPath 'C:\pfad\zur\PdfSharp-gdi.dll'

Der Unterschied von SSD zu HDD ist eigentlich sofort spürbar: beim Booten, beim Öffnen des Servermanagers etc. Habe den direkten Vergleich: einmal HP ProLiant ML30 mit 3x SATA HDD im RAID 5, einmal Intel NUC mit i7 und Samsung SSD. Das war mein letzter Server, auf dem ich SATA-Disks für VMs einsetze... Ich denke mit einer SSD wirst Du die Performance massiv verbessern können.

Du könntest das Makro die Datei nach den Anpassungen passwortgeschützt speichern lassen: https://exceloffthegrid.com/vba-code-password-protect-excel-file/

Das ist wohl kein Problem: Anleitung https://www.cisco.com/c/dam/en/us/td/docs/wireless/access_point/csbap/wap371/quick_guide/guide/QSG_ENGLISH.pdf, Seite 7: Power Solid (Amber): The Cisco WAP371 is powered on, booting, or in normal operation with External Power Adapter Grün ist die LED nur bei PoE.

Wenn Rechner A ein Paket zu Rechner B schickt, welcher sich im gleichen Netz befindet, macht er einen ARP-Lookup und adressiert das Paket an die MAC-Adresse von Rechner B. Schickt er ein Paket an Rechner C, der sich in einem anderen Netz befindet, adressiert er das Paket an das Gateway, also schlussendlich an die MAC-Adresse des Gateways. Er kommt nicht auf die Idee, dass sich beide Netze am gleichen Switch befinden und versucht nicht, an die MAC-Adresse von Rechner C zu kommen. Was Du vielleicht meinst mit MAC-Adressen auf dem Switch: der Switch lernt, über welche Ports welche MAC-Adressen erreichbar sind, so dass er Pakete (im Gegensatz zum Hub) nicht über alle Ports schicken muss. Eine schnelle Lösung für Dein Problem könnte sein, einen routingfähigen Switch zu beschaffen. Die kosten nicht mehr so viel wie früher. Die Überarbeitung des Netzwerkkonzepts sollte aber trotzdem auf der Pendenzenliste bleiben.

Die Windows Server Sicherung ist nicht ideal für die Sicherung übers Netzwerk. Zumindest früher wurde übers Netzwerk jedes Mal eine Vollsicherung erstellt. Veeam bietet eine kostenlose Software zur Sicherung von physischen Servern an: https://www.veeam.com/de/windows-endpoint-server-backup-free.html Arbeite schon einige Jahre damit und bin sehr zufrieden, sichere auch meine privaten Rechner so. Man kann auf ein NAS oder in ein Veeam Repository sichern. Besonders wenn ihr zur Sicherung der VMs schon Veeam einsetzt bietet sich diese Lösung an.

Ich würde auf dem Notebook Windows 10 installieren, da gibt es sicher die richtigen Treiber dafür. Dann entweder mit dem Hyper-V von Windows 10 arbeiten, falls der reicht, oder sonst Nested Virtualization aktivieren (https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/nested-virtualization) und den Server 2012 R2 als virtuelle Maschine installieren. So kannst Du auch mehrere 2012 R2 parallel installieren, falls Du Cluster testen willst etc.

Wenn Du das Backup auf den gleichen Server zurückspielst, sollte das funktionieren. Was die anderen Mitglieder gemeint haben mit "Host nicht sichern" war, dass man auf dem Host keine Daten hat. Muss man für die Wiederherstellung die Hardware wechseln, ist Windows schneller neu installiert als das Backup zurückgespielt, Treiber ausgetauscht etc. Sogar auf der gleichen Hardware ist man unter Umständen mit einer Neuinstallation schneller. Nämlich dann, wenn man Scripts hat, welche die Netzwerkeinstellungen etc. konfigurieren.

Es gibt schon noch Anwendungsgebiete, aber die sind nicht mehr so zahlreich, wie man am Anfang vielleicht gemeint hat. Beispiel aus der Praxis: eine Firma, mehrere Standorte. Einige Mitarbeiter arbeiten an verschiedenen Standorten (aber immer nur an einem gleichzeitig). Profile replizieren und der Mitarbeiter kann sich schneller anmelden. Oder Luftbilder: riesige Bilddateien, die man nur einmal jährlich bekommt und die dann read-only sind und auf Plänen als Hintergrundbild eingebunden werden. So können alle Standorte mit den Dateien arbeiten, ohne sie über WAN übertragen zu müssen und ohne händische Kopieraktionen. Für diese Fälle war DFS-R in Zeiten teurer Bandbreite ein grosser Vorteil. Mittlerweile läuft aber alles zentral und die Leitung wurde auf Gbit-Glasfaser umgestellt.

Nein, bis jetzt noch nicht. Es hat immer alles funktioniert und die Doku ist auch umfangreich. Support scheint in erster Linie über das Forum zu laufen, dort schreiben auch Mitarbeiter von Ubiquiti. Muss aber dazu sagen, dass wir nur immer "einfache" Sachen wie mehrere SSID und Vouchers benötigt haben. Traffic Shaping etc. machen wir auf der Firewall.

Beim grössten Kunden sind es ca. 75 Mitarbeiter, verteilt auf drei Stockwerke. Die haben jeweils ein Smartphone und etwa ein Drittel davon hat noch ein Notebook. Dazu kommen bei Sitzungen noch diverse Gäste. Das geht gut mit drei Access Points. (Die Anzahl Clients pro AP war bei meinen Installationen noch nie ein Problem, die Reichweite hat immer die Anzahl benötigter Access Points bestimmt.) Die Daten gehen direkt vom AP aufs LAN. Der Controller wird nur für die Konfiguration benötigt oder eben für die Voucher. Setze UniFi auch bei kleinen Kunden ohne Server ein, dort installiere ich den Controller einfach auf einem Rechner, richte ihn aber nicht als Dienst ein. Gefallen hat mir, dass die Access Points den Controller bei korrekter Konfiguration von DHCP oder DNS automatisch finden, auch über Netzwerkgrenzen hinweg. Braucht ein Aussenstandort einen zusätzlichen AP, kann man den direkt dort hin schicken. (Wobei das wahrscheinlich die anderen Anbieter auch können.)

Ich setzte meist UniFi ein und da meist die Long Range Access Points. Da reicht je nach Gebäude einer pro Etage. Mehrere SSID in verschiedenen VLANs sind kein Problem. Vouchers funktionieren auch, aber dafür muss entweder der Controller als Dienst auf einem Server laufen oder man braucht noch das Security Gateway. Mir wurde schon von guten Erfahrungen mit den Lösungen von Fortinet und WatchGuard berichtet. Die sind aber in einer anderen Preisklasse und machen nur Sinn, wenn man die Firewalls des Herstellers nutzt.

Mit dem "Media Creation Tool" (https://www.microsoft.com/de-de/software-download/windows10) kann man eine aktuelle ISO von Windows 10 herunterladen. Die monatlichen Updates sind soweit ich weiss nicht integriert, aber man erhält immer den aktuellen Build, aktuell also das Fall Creators Update. Da der Key bei OEM-Lizenzen im BIOS integriert ist, braucht man kein spezielles Installationsmedium vom Hersteller mehr, wie das noch bei Windows 7 der Fall war.

Nextcloud lässt sich in einem Webhosting oder auf einem kleinen vServer installieren und bietet serverseitige Verschlüsselung. Dazu ein kostenloses SSL-Zertifikat von Let's Encrypt (bei vielen Webhostern mittlerweile standardmässig aktiviert) und die Daten sind auch bei der Übertragung geschützt.

Wir machen das ebenfalls mit einem Script. Es liest den Clientnamen aus und schaut im AD nach, welcher Standort für den Rechner hinterlegt ist. "5. OG, Sekretariat" zum Beispiel. Aufgrund des Standorts verbindet es die Drucker und setzt den Standarddrucker. Zusätzlich legt es den letzten Standort und eine Versionsnummer in einer Textdatei im Benutzerprofil ab, so dass die Drucker nur neu verbunden werden, wenn sich der Benutzer von einem anderen Client aus anmeldet oder das Script bzw. die Drucker aktualisiert wurden. Das Script stammt aus der Zeit um 2008. Bin mir ziemlich sicher, dass es mittlerweile schönere Lösungen gibt.

Habe mal so ein Tool geschrieben, Sourcen und EXE (im ZIP unter \bin) hier: http://cloud.zeugs.info/index.php/s/NGsx46FIQtWlVB2 Anleitung: - auf ein Netzlaufwerk kopieren - vom Anmeldescript aus starten mit Parameter "/logon" (DB wird automatisch erstellt falls noch nicht vorhanden) - falls gewünscht, aus dem Abmeldescript starten mit Parameter "/logoff" (aktuell werden die Datensätze des Benutzers gelöscht, man könnte aber auch die Abmeldezeit protokollieren) - schauen, an welchem Rechner User hmuster angemeldet ist mit "/getUser hmuster" - Datenbank ausgeben mit "/dump" (oder für eine Auswertung die Datenbank öffnen mit einem Viewer/Editor für SQLite) Es ging darum, mittels Script festzustellen, wo Benutzer XY gerade arbeitet. Für die Suche alter Benutzerkonten macht der Parameter "/logoff" deshalb aktuell keinen Sinn.

Soweit ich weiss geht das nicht, ohne das Ereignisprotokoll der Rechner auszulesen. Zu Zeiten von Windows 2003 habe ich dafür mal ein VBS gebastelt, welches als Anmeldescript lief und Zeit, Benutzername und Datum in eine Access-DB eingetragen hat. Dieses habe ich vor einiger Zeit nach .NET mit SQLite als Datenbank umgeschrieben. Kann die Sourcen und die EXE gerne zur Verfügung stellen.

Also Du lässt Blat Mails verschicken, von denen Du dann eine Lesebestätigung erhalten möchtest? Anforderungen für Lesebestätigungen sind ein Header in der Mail. Laut https://en.wikipedia.org/wiki/Email_tracking#Read-receipts ist es "X-Confirm-Reading-To:", "Disposition-Notification-To:" oder "Return-Receipt-To:". Würde mal im Outlook eine Mail mit Lesebestätigungsanforderung verschicken und schauen, welchen Header Outlook setzt. Mit "-a1" lässt sich bei Blat ein benutzerdefinierter Header anfügen.

Mittlerweile habe ich SolidCP getestet: es ist leider nicht geeignet für diesen Zweck, da es zu sehr auf normales Hosting ausgerichtet ist. Es werden nur Gruppen angezeigt, die über SolidCP erstellt wurden (und somit in der SQL-Datenbank vorhanden sind), Gruppen haben ein Suffix etc. Es ist zwar Open Source, aber da wäre ich ein paar Tage dahinter um das umzuschreiben. Deshalb haben wir es jetzt direkt im AD mit den gewöhnlichen Verwaltungstools gelöst. Die Benutzer starten über RDP die AD-Verwaltungskonsole. Die Rechte im AD anzupassen war etwas mühsam, wobei ich sagen muss dass die neuen Menüs seit Server 2012 ein echter Fortschritt sind. Es liess sich alles über Vererbung lösen, ohne Scripts, die jedes Objekt angefasst haben. Die Struktur im AD sieht so aus: Domain - OU=WebUsers, dann pro Gemeinde eine OU. Folgende Berechtigungen mussten angepasst werden: - Ebene Domäne: "Authentifizierte Benutzer", "nur dieses Objekt", "Inhalt auflisten" entfernen - Ebene OU=WebUsers: "Authentifizierte Benutzer", "nur dieses Objekt", "Inhalt auflisten" entfernen - Ebene OU=WebUsers: "Authentifizierte Benutzer", "dieses und alle untergeordneten Objekte", "Inhalt auflisten" und "Objekt auflisten" entfernen - Ebene OU=WebUsers: "Application Pool-Benutzer, "untergeordnete Benutzer-Objekte", "Gruppenmitgliedschaft lesen" erlauben => wichtig, sonst sieht die Anwendung nicht mehr, wer in welcher Gruppe ist! - Ebene Gemeinde-OU: "Gemeinde-Admins", "nur dieses Objekt", "Lesen" erlauben - Ebene Gemeinde-OU: "Gemeinde-Admins", "dieses und alle untergeordneten Objekte", "Benutzer-Objekte erstellen" und "Benutzer-Objekte löschen" erlauben - Ebene Gemeinde-OU: "Gemeinde-Admins", "Untergeordnete Benutzer-Objekte", "Vollzugriff" erlauben Funktioniert ganz gut, die Gemeinde-Admins können nur in ihre OU navigieren, alles andere ist ausgeblendet. Dort können sie dann nur Benutzer erstellen. "Neue Gruppe" etc. erscheint nicht mal im Kontextmenü, gibt also nicht erst beim Klick einen Fehler. Sie können die Kennwörter setzen, Anzeigenamen anpassen und eben die Gruppenmitgliedschaft verwalten. Dort sehen sie nur ihre Gruppen, können also nicht einen Benutzer zum Domänen-Admin machen. Ist natürlich unschön, eine Webanwendung über RDP zu verwalten, aber funktionieren tut es.