Jump to content

Wisi

Junior Member
  • Content Count

    123
  • Joined

  • Last visited

Posts posted by Wisi


  1. vor 23 Stunden schrieb Harris:

    Bei uns wird wird der Bitlocker Wiederherstellungsschlüssel sowohl ins AD geschrieben, als auch auf einen Share auf unserem Fileserver. Ins AD werden die Schlüssel immer in den Computerkonten hinterlegt. Auf dem Share konnte ich schon feststellen, dass es nicht immer geklappt hat.

    Nachdem du ja .txt Dateien hast, schau mal bitte rein, wer der Owner von der Datei ist, bzw. wer die erstellt hat. Wird das tatsächlich über den jeweils angemeldeten Benutzer erzeugt?


  2. vor 1 Stunde schrieb EitieOS:

    Betroffen sind nur Win10 Pro 1909 und Office 2010. Mit Office 2013 und auch 365 haben wir keine Probleme.

    Idee wäre ein Downgrade auf 1903 - oder Neuinstallation. Den Aufwand wollen wir uns aber sparen.

    Ich habe auch fast das Gefühl, dass das 1909 hier ein entscheidender Faktor ist. Leider haben wir mit dem Rollout direkt dort begonnen, ich habe also nichts davor zum Vergleich.

    Evtl. kann ich aber mal aus der Automatisierung mir eine entsprechende Kette schnell zusammenbauen.


  3. vor 4 Minuten schrieb NilsK:

    Also: "System" bezeichnet in Berechtigungen immer das lokale System. Bei einem Share wäre das also das Betriebssystem des Dateiservers. Also mit Sicherheit nicht die Instanz, die da zu schreiben versucht - das wäre ja das Betriebssystem des Clients. Diese Berechtigung passt also schon mal nicht.

    Danke, Wald und Bäume, das klingt für mich in der Tat sehr logisch, hätte man selbst drauf kommen können. Aber eine Idee mit welchen Berechtigungen, bzw. welchem User etc. das Ding kommt, hast du auch nicht? Scheinen wohl eher wenige Leute zu verwenden.

     

    vor 5 Minuten schrieb NilsK:

    Dann: Man sollte auf Share- und NTFS-Ebene nicht in dieser Form die Berechtigungen unterschiedlich halten. Da NTFS das leistungsfähigere Berechtigungssystem hat, sollten nur dort die Berechtigungen stehen. Das Share wird dann für "Jeder: Vollzugriff" berechtigt.

    Unser Dozent, als ich mit der Thematik vor zig Jahren angefangen habe, hat immer gepredigt, dass er "Jeder" nicht für so geeignet hält wie "Authentifizierte Benutzer". Das war beim Training für MCP Prüfungen in einem Testcenter, in dem nur geprüfte Trainer anwesend waren. Haben das bisher immer so beibehalten und uns darüber keine weiteren Gedanken beim Thema "Jeder" vs "Authentifizierte Benutzer". Was nicht heißt, dass man mal nach aktuellem Stand neu drüber nachdenken könnte, wenn der MVP schon drauf hinweist ;) Beim Rest keine Frage, so ist das bei uns auch, am Share wird nichts weiter abgefangen, es wird auf der NTFS Ebene berechtigt.

     

    vor 7 Minuten schrieb NilsK:

    Ob der Mechanismus, den du beschreibst, den Sicherheitsanforderungen genügt, die man zur Ablage von Bitlocker-Schlüsseln haben sollte, kann ich nicht einschätzen. Seltsam klingt für mich, dass du die Keys von "Standalone-Clients" in das Share legen willst. Sind die nicht Mitglieder im AD? Dann wirst du dort kaum eine sinnvolle Berechtigung vergeben können.

    Nein, deshalb schrieb ich, das gilt für interne Clients als zweite Option. Bei den externen/Standalone machen wir das mit Mitteln unseres Client Managements, da dort eben keine Bordmittel greifen (können). Ich könnte theoretisch auch drauf verzichten und die internen Clients ebenso mit dem Client Management abfragen (was wir wohl auch umsetzen werden im weiteren Workflow). Man will aber ja trotzdem das Problem erfassen und lösen, bevor man es abhakt.


  4. vor 31 Minuten schrieb MurdocX:

    Das klingt interessant, dennoch sagt es nichts ;-)  Welche Berechtigung hast du denn vergeben (lesen/lesen & schreiben/ändern/vollzugriff)? 

    In der Tat wieder mal zu kurz gesprungen. Das kommt davon, wenn man schon länger damit rum macht und dann denkt jeder weiß wovon man redet...

     

    Share - Authentifizierte Benuzter -> Vollzugriff

    Ordner/NTFS - Administratoren/System -> Vollzugriff

    vor 38 Minuten schrieb MurdocX:

    Was denkst du mit welchem Benutzer das Betriebssystem denn auf das Share schreibt?

    Das wäre meine Frage an euch Experten ;) Ich hätte vermutet "System", aber ich weiß es schlicht nicht, weil ich auch noch nirgends ein System habe, wo das funktioniert, sonst hätte ich mir es dort angeschaut, wer der Besitzer ist. Leider steht es auch in keinem einzigen Tutorial, jeder legt nur die Ordner an und verweist auf die Richtlinie. Was er konkret für Berechtigungen auf Share/Ordner gesetzt hat, verschweigen sie alle.

     

    vor 27 Minuten schrieb NorbertFe:

    Wir lassen das ins AD schreiben. Ohne Verbindung zum AD gibts kein Bitlocker.

    Da lass ich es normal natürlich auch rein schreiben, oder alternativ erfasst unser Client Management die Standalone Clients und beim Job der Aktivierung von BitLocker schreibt er dann direkt den Recovery Key (nach Abruf über Powershell) in die Eigenschaften des Clients und schickt nach Möglichkeit auch von dort aus direkt noch eine Mail mit den Informationen über unser eigenes Gateway.

     

    Insofern wollte ich das Share eigentlich mehr oder weniger als "doppelten" Boden für interne Clients haben.


  5. Hallo in die Runde,

     

    wir führen gerade großflächig BitLocker ein (rein auf TPM Basis, damit die Platte ohne Hardware in Zukunft wertlos ist) und im Prinzip funktioniert auch schon alles. Nur eine Sache kriege ich irgendwie nicht hin und zwar, dass er die Recovery Keys auch als TXT im definierten Share ablegt.

    Ich habe die Richtlinie "Standardordner für Wiederherstellungskennwort auswählen" gesetzt, einen Pfad auf unserem DFS dafür festgelegt und diesen kann ich auch beschreiben. Aus der Logik her habe ich dem Share selbst die Berechtigung "Authentifizierte Benutzer" gegeben und die NTFS Berechtigung im Dateisystem ist "Administratoren und System", da ich davon ausgehe, dass das System die Datei ablegen möchte und auch kein User das lesen braucht. Allerdings hat sich bis jetzt dort nie eine .txt gebildet, wenngleich die Verschlüsselung aktiviert ist und funktioniert.

     

    Wo liegt der Fehler, bzw. wie muss dieses Share gesetzt sein, damit es funktioniert bei euch?


  6. Jetzt hab ich mich heute mal ran gesetzt und das Deployment aktualisiert im Bezug auf das Office und habe die neueste Version mit der Setup.exe geladen. Im Dateipfad ist dann auch die 16.0.10354.20022 vermerkt. Wenn ich jetzt damit installiere, lande ich aber wieder bei der 10352.20042. Unabhängig davon, ob es ein Upgrade, oder eine neue Installation ist. Update Check bringt auch die Meldung, dass das die neueste Version wäre.

     

    Ich bin davon ausgegangen, dass dort dann auch die 10354.20022 stehen müsste, wenn ich dessen Source nutze? Hat wer Office 2019 Pro Plus im Einsatz zum Gegencheck?


  7. Interessanter Ansatz, da hab ich nicht dran gedacht, aber für mich schaut das ausnahmslos ok aus...

    sec2.png

    sec1.png

     

     

    Es gibt auf jeden Fall eine History, ich werde jetzt mal die aktuellste Version laden: https://docs.microsoft.com/en-us/officeupdates/update-history-office-2019

     

    Wir haben installiert mit September 10, 2019 Version 1808 (Build 10350.20019), sind aktuell auf November 12, 2019 Version 1808 (Build 10352.20042) und es gibt January 14, 2020 Version 1808 (Build 10354.20022). Das teste ich jetzt als nächstes.


  8. vor 24 Minuten schrieb zahni:

    Eigentlich wird die geschützte Ansicht mit diesen Einstellungen überall aktiviert, bis auf die  vertrauenswürdigen Speicherorte. Die sind bei uns als UNC-Pfad per GPO hinterlegt. 

    Das war auch unser Plan, nur leider können die Leute dann derzeit keine Excel oder Word Dokumente im Anhang öffnen, weil diese immer beschädigt angezeigt werden. Haken raus und es geht. Aktuell also so nicht umsetzbar.

     

    Gibt es vielleicht irgendwo eine Übersicht welche Office 2019 Versionen released wurden? Evtl. haben wir bei unserer Deployment Vorbereitung eine Version erwischt, die schon ersetzt wurde... Man kann das ja nur noch per Setup zum Download antriggern.


  9. vor 20 Minuten schrieb NorbertFe:

    Kann ich grad mangels Office 2019 nicht testen. Ich meine mich aber zu erinnern, dass man weitere Settings für den protected view zur Verfügung hat. evtl. kollidieren die ja an einer Stelle.

    Da wir aktuell absichtlich keine Abweichungen vom Standard eingestellt haben an der Stelle, abgesehen von den oben beschriebenen Optionen, wäre das zwar schizophren von MS, aber nicht ausgeschlossen ;)


  10. Zitat

    Gabs da überhaupt die von dir geschilderten Optionen? :)

    Gute Frage, hab ich ehrlich gesagt gerade auch nicht gegengeprüft ;-)

     

    Zitat

    Ich überlege grad, was jetzt das eigentliche Problem ist? Können die Dateien nicht geöffnet werden, sind sie defekt, oder stört die NUtzer nur, dass das Handling aufgrund der Sicherheitsoptionen jetzt ein anderes ist als mit Windows 7 und Office 2010?

    Die Dateien lassen sich dann nicht öffnen, es ist also gar nicht erst möglich damit zu arbeiten (Office behauptet Datei ist defekt, dieselbe kann bei deaktivierter Option aber problemlos geöffnet und auch bearbeitet werden). Beim Handling würde ich einfach verlangen, dass die Mitarbeiter da mitdenken zwecks der Warnung oben im Office und dann ist das eben so. Aber dass diese es gar nicht erst öffnen können, ist natürlich ein Problem :)

     

     

    Nachtrag:

    Zitat

    Gabs da überhaupt die von dir geschilderten Optionen? :)

    Jupp, gab es ;-)

    word.png


  11. Hallo in die Runde,

     

    während unseres Windows 10 Rollouts kamen immer mal wieder Klagen auf wegen Anhängen an Emails und dem Öffnen selbiger im Office. Zudem das Problem, dass auch Dateien auf Netzlaufwerken als Defekt gemeldet werden beim Öffnen.

    Nach kurzer Suche war klar, dass es mit der "Geschützten Ansicht" aus Office zusammenhängt (Beispiel Screenshot aus Word). Deaktiviert man diese Option(en), dann funktioniert es alles auf Anhieb und wie gewohnt.

     

    Bei den Netzlaufwerken haben wir das damit gelöst, dass wir den UNC Pfad zu unserem DFS in die "Vertrauenswürdigen Speicherorte" hinzugefügt haben, damit war das Thema dann erst mal erledigt und wir konnten die Haken gesetzt lassen.

    Bei den Anhängen bringt das aber leider keinen Fortschritt, da eine der Optionen ja explizit mit Outlook zusammenhängt. Gemäß BSI Empfehlung (https://www.allianz-fuer-cybersicherheit.de/ACS/DE/_/downloads/BSI-CS/BSI-CS_138.pdf?__blob=publicationFile&v=9) soll man das entsprechend eigentlich auch nicht deaktivieren, wenngleich wir das derzeit machen, um einen Betrieb sicherzustellen.

     

    Wir hatten davor Windows 7 Pro mit Office 2010 Pro Plus und keinerlei Probleme in der Hinsicht. Auch auf den Clients, welche zwischendurch zum Test für den Rollout schon installiert wurden und Office 2013 installiert ist, tritt das Problem nicht auf. Allerdings ist dort auch 1809 verwendet worden und nicht 1909, insofern vermutlich sehr schwierig zu vergleichen, da einfach zu viele Änderungen dahinter sind.

     

    Berichte dazu gibt es bspw. hier, wobei eigentlich alle darin enden, dass man es deaktiviert...:

     

    https://community.spiceworks.com/topic/2219489-having-to-disable-protected-view-in-outlook-attachments-in-excel-word-etc-why

    https://www.msoutlook.info/question/884

    https://www.remosoftware.com/info/outlook-2016-error-opening-word-or-excel-attachment-file

     

    Hat noch jemand von euch das Problem in der Konstellation Windows 10 Pro 1909 und Office 2019 Pro Plus? Natürlich könnten wir das jetzt via GPO einfach deaktivieren, aber wir sind immer noch auf der Suche nach dem auslösenden Problem.

    Vielleicht hat ja noch jemand anders Erfahrungen damit und kann hier berichten.

    word.png


  12. Du hast auch sicherlich in deinem Klientel nicht viele aus den folgenden Personengruppen (und das ohne es böse zu meinen und ohne konkrete Reihenfolge): Lehrer, Pädagogen, Hausmeister, Putzfrauen um mal die härtesten Gruppen zu nennen ;)

    Die machen Ihren Job, aber haben halt von dem Rest wenig Ahnung. Das ist auch in Ordnung, dafür sorge ich dann halt für Laufwerke :)


  13. Das stimmt in der Theorie, dann würde ich aber auch auf den anderen Adressen nach diesem Stil Mails erwarten und diese sind sauber.

    Gegen VMWare und Veeam spricht mittlerweile aber auch, dass dort weitere Emailadressen nach dem Schema vorhanden sind und diese auch sauber sind.

     

    Aber ich habe noch mal nachgeschaut was an Mails aufgelaufen ist, es gibt noch zwei weitere Hersteller (TE-Systems und C4B, falls das jemand prüfen möchte) denen wir diese Emailadresse anvertraut haben und da sind keine von den anderen hinterlegt. Insofern werde ich jetzt beobachten ob es bei der einen Adresse bleibt...

     

    Mir ging es auch erst mal darum zu schauen ob jemand von euch evtl. ähnliches die letzten Tage gesehen hat um eben die beiden ausschließen zu können. Könnte evtl. jemand die beiden Firmen aus dem Topic löschen, da es zu dediziert ist an der Stelle?

     

    Danke!


  14. Hi, leider nicht dieses Problem. Dann würde das Skript ja gar nicht ausgeführt werden (das kannte ich auch schon...). Es wird aber ausgeführt und es funktioniert an sich auch. Nur wird der erhöhte Adminkontext nicht mit dem niedrigeren Userkontext verknüpft. Das ist ja der Sinn von EnableLinkedConnections.

     

    Schau mal vorne in den Screenshots, dann siehst du was gemeint ist. Nach dem normalen Anmelden sind die Laufwerke ja gemappt worden, nur im falschen Kontext.

     

    Wenn du die UAC abschaltest, dann hast die Laufwerke auch wieder (weil es keine verschiedenen Kontexte mehr gibt).


  15. Manuell kannst du alles machen. Nur beim Logon gehts halt nicht. Wenn ich dasselbe Skript noch mal ausführe, ist auch alles gut.

    Schau dir mal meine Screenshots vorne an, dann siehste was passiert. Die Laufwerke werden im erhöhten UAC Kontext gemappt...

     

    Und Systemwiederherstellung bringt ja nichts, weil du das alles problemlos mit den Updates "regulär" reproduzieren kannst. Ganz ohne Wiederherstellung. Patch drauf -> geht nicht. Patch deinstallieren -> geht. Auf demselben System. Mehr brauchts nicht um festzustellen, dass in den Patches ein Problem drin ist.

     

    Naja, trauriges Fazit: nachdem es Microsoft nicht fertig bringt, ist die erste Handlung Anfang nächsten Jahres die Umstellung auf GPP in allen Domänen. Dafür müssen wir das ganze Anmeldethema überarbeiten. Sehen wir es positiv, die vor kurzem durchgeführte Bereinigung macht die Umstellung leichter und transparenter.


  16. Hallo,

     

    ich teste das ja auf meinem Client zuerst. Das Problem tritt übrigens auch auf 10/2012 R2 auf. Da stört es mich aktuell nur nicht, weil keine Arbeitsworkstation bei uns damit vorhanden ist. Insofern also auch keine Lösung.

    Es lässt sich ohne Systemwiederherstellung ganz einfach lösen indem man die Patches deinstalliert, soweit funktioniert der Prozess zumindest sauber.

     

    Problem dabei: da es kumulativ ist, fehlen dir zig Updates in der Zwischenzeit, weil du ja nicht den einen Problempatch rausnehmen kannst wie früher.


  17. Hallo,

     

    hat jemand evtl. in den letzten Tagen auf Lizenz Emailadressen auch direkt adressierten Spam bekommen? Wir haben auf einer Emailadresse, die nur zum Empfang von Lizenzinformationen bei Veeam und VMWare eingerichtet ist und auch nie zum Versand benutzt wird, Spams bekommen. Auf der Standardadresse nicht weiter verwunderlich, aber auf dieser ganz speziellen Adresse, auf einer Domain auf der auch nur genau diese eine Adresse überhaupt angelegt ist (keine Onlinepräsenz, nichts), verwundert mich das sehr...


  18. Puh, ganz toll, das nächste Update, welches den Fehler hervorruft (eigentlich klar, weil kumulativ). Hatte gehofft Microsoft hätte das in der Zwischenzeit geklärt.

     

    Dann mal die Frage: wo genau kann ich das eigentlich melden, bisher sind die Fehler immer von selbst behoben worden oder das Update wurde sowieso zurückgezogen...

     

    Betroffenes Update bei uns: November 2016 – monatliches Sicherheitsqualitätsrollup für Windows 8.1 für x64-basierte Systeme (KB3197874)


  19. So, das erste Update ist schon mal gefunden: KB3192392. Allerdings ist es das wohl nicht alleine. Bei mir ist das Problem vorhanden sobald installiert und weg nachdem deinstalliert. Beim Kollegen ist das Problem aber nach Deinstallation noch vorhanden.

     

    Edit: da gibts mit dem Update derzeit wohl auch noch deutlich mehr Probleme, siehe http://www.borncity.com/blog/tag/kb3192392/

    Edit2: auch das andere Update KB3185331 was dort genannt wird, erzeugt das Problem

     

    Fazit für mich: die beiden Updates sind derzeit nicht zu empfehlen. Jedes von den beiden für sich alleine reicht um das Problem hervorzurufen. Test beim Kollegen ebenso erfolgreich abgeschlossen. Die beiden runter und alles passt.

     

    Edit3: Unter Windows 7 installieren wir das entsprechende KB3192391 aber - ohne Probleme. KB31292393 wiederum unter 2012 genau das gleiche Thema wie unter 8.1 (war aber fast zu erwarten).

     

    Edit4: Nachdem ich schon dabei bin: KB3192403 für Windows 7 geht, KB3192404 und KB3192406 selbes Spiel -> Finger weg

×
×
  • Create New...