Jump to content

cj_berlin

Expert Member
  • Gesamte Inhalte

    2.816
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von cj_berlin

  1. Du meinst sicher "abwegig", denn es kommt nicht von der Abwägung, sondern vom "vom Weg abkommen" ;-) 

     

    Es ist schon besser, aber ein Reverse Proxy, der jeden Request unbesehen weiterreicht ist kein großer Sicherheitsgewinn. Wie @NorbertFe sagt: eine minimale WAF, SQL-Umgebung härten, also zumindest verhindern, dass der Service-Account irgendwelche Rechte im System hat, Anwendung härten (SQL Injection).

  2. Moin,

     

    soweit ich weiß, hat Linux nur einen "quiescing"-Mechanismus für Dateisysteme, womit Puffer auf Platten geschrieben und neue Schreiboperationen zurückgehalten werden. Für mySQL braucht es dafür Skripte (findet man tonnenweise im Netz) zum Einfrieren und Wiederauftauen. Das Problem ist das Triggern dieser Skripte vom Host aus - automatisch durch den Snapshot passiert es nicht.

     

    Hier ist etwas von Veeam zum Ausmaß der Misere: https://www.veeam.com/blog/backing-up-mysql-on-a-linux-vm.html

  3. vor 13 Minuten schrieb daabm:

    Nur mit großem Aufwand, wenn viele Syteme dahinter stecken -> nutze gMSA wo immer möglich. Und sorge von Anfang an dafür, daß nur die nötigen Computer den gMSA nutzen dürfen.

    +1 zu gMSA

     

    und dort, wo es nicht möglich ist, gMSA zu nutzen:

    • ein Account pro Service --> Abhängigkeiten zwischen den Services kennen und Kennwörter konzertiert und skriptgesteuert im Mini-Wartungsfenster durchtauschen. Ich habe bei einem Kunden eine 3-Tier-Anwendung aus >10 Servern, wo der Wechsel sämtlicher Service-Kennwörter unter 20 Sekunden dauert. Das muss einmal in 14 Tagen oder einmal im Monat möglich sein.
    • gleicher Service auf mehreren Computern unter demselben Account NUR DANN, wenn die Computer tatsächlcih geclustert sind und es nicht zu vermeiden ist (pseudo-gMSA)
    • Accounts für Sachen wie LDAP-Lookup, was in Tausenden von Appliances eingetragen wird und nur drei Attribute bei 10% der Objekte lesen soll --> in einer Gruppe, die ein explizites Deny auf privilegierte OUs, Objekte und kritische Attribute hat. Kein Telefonbuch der Welt braucht Leserechte auf userAccountControl, adminCount, servicePrincipalName usw.
  4. (bezieht sich auf die Antwort von @NorbertFe)

     

    Vor 10 Jahren hätte ich das auch gesagt. Aber die meisten Firmen haben eher zu viele Third Party Tools als zu wenige - bis auf die Stellen, wo es *wirklich* darauf ankommt.

     

    Und was das Verhindern angeht - das kann das gleiche IAM für Dich erledigen, indem die User mit dem Merkmal "cannot change password" versehen werden. Die Maske in Windows zu deaktivieren ist EINE GPO Einstellung. Die Maske in OWA deaktivieren ist EIN PowerShell-Befehl. Die Maske in StoreFront deaktivieren ist EIN Häkchen. Klar können das nur die Großen ;-) 

  5. Moin,

     

    vergiss die Bücher, sie werden Dir nur erklären, was geht (und wie), und dafür reichen Docs vollkommen aus. Was dort, und auch in den Büchern, nicht stehen wird, ist, warum das eine schlechte Idee ist, und warum das in einer virtualisierten Umgebung eine geradezu disaströse Idee ist. Das musst Du dir aus Blogs zusammen suchen, und ich werde absichtlich keine Links posten, damit Du siehst, wie mühsam bereits das Auffinden dieser Informationen ist.

     

    Was Du dir auch anschauen solltest, ist https://learn.microsoft.com/de-de/iis/web-hosting/scenario-build-a-web-farm-with-iis-servers/overview-build-a-web-farm-with-iis-servers - vielleicht ist es auch schon das, was der Anforderungs-Manager gemeint hat. Alles besser als WNLB. ARR wäre, auf IIS projiziert, das, was man in der professionellen Webserver-Welt mit NGINX-Loadbalancern macht.

     

    • Like 1
  6. vor 30 Minuten schrieb massaraksch:

    Hi,

     

    nochmal eine Erläuterung:

     

    Wenn man -ErrorAction Stop verwendet (verwenden muss, wegen try-catch), dann fliegt man beim ersten Auftreten eines Fehlers aus der umgebenden foreach-Schleife raus. Ende Gelände.

     

    Das vermeidet man, indem man den catch-Block mit "continue" abschließt. Das führt zur Weiterverarbeitung der Schleife mit dem nächsten Item.

     

    Also ungefähr so:

     

    foreach ($Mailbox in $Mailboxes) {

    try {Set-MailboxFolderPermission ... -ea Stop}

    catch {

    Set-MailboxFolderPermission ...

    continue

    }

    }

    Moin,

     

    Du verwechselst hier was. Das, was Du beschreibst, passiert bei Trap, und "continue" braucht man dort, um die Ausgabe der Fehlermeldung zu unterdrücken. Try/catch behandelt alles lokal, und "continue" führt dazu, dass der restliche Codeblock innerhalb der Schleife für diese Iteration übersprungen wird.

    • Like 1
  7. Genau, "terminierende Fehler" sind hier das Stichwort. Einfach -ErrorAction Stop zu den Cmdlets hinzufügen, und schon sind alle Fehler terminierend.

     

    Aber noch besser ist es, die Fehler gar nicht erst entstehen zu lassen: https://it-pro-berlin.de/2016/05/powershell-hack-namen-von-standardordnern-in-einem-exchange-postfach/ Ich könnte schwören, ich habe es bereits als Antwort auf Deinen anderen Thread gepostet.

×
×
  • Neu erstellen...