Jump to content

Assassin

Members
  • Gesamte Inhalte

    368
  • Registriert seit

  • Letzter Besuch

Profile Fields

  • Member Title
    Newbie

Letzte Besucher des Profils

Der "Letzte Profil-Besucher"-Block ist deaktiviert und wird anderen Benutzern nicht angezeit.

Fortschritt von Assassin

Experienced

Experienced (11/14)

  • Erste Antwort
  • Engagiert
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei

Neueste Abzeichen

13

Reputation in der Community

2

Beste Lösungen

  1. Das ist ein Testsystem wo ich das hier mache. Da ist natürlich bei weitem nicht der Umfang wie im Produktivsystem. Aber daher frage ich vorsichtshalber bevor ich das eben auch im Produktivsystem so anwende
  2. Ok, habe jetzt beim AdminSDHolder die Benutzergruppe Exchange Servers einfach mal entfernt - jetzt geht es, wird nicht mehr als gefährlich erkannt. Admin Accounts sollen auch keine E-Mail adressen bekommen. Aber steht nur deswegen die Exchange Server gruppe da mit drin wegen möglicher E-Mail-Adressen? Oder hat das vieleicht doch noch weitreichendere Folgen wenn man die gruppe entfernt?
  3. OK, aber auch in der Sicherheitsberechtigung des AdminSDHolders gibt es keinen eintrag zum msDS-KEyCredentialLink, also wenn ich da bei den Effektiven Zugriffen schaue. Da wird allerdings der Eintrag msDS-KEyCredentialLink garnicht mit aufgeführt. Ich finde auch nirgendwo infos im Netz, wie ich das schreibrecht entziehen kann. Habe im AdminSDHolder objekt unter den Sicherheitsberechtigungen auch jeden Exchange Servers eintrag durchgeklappert und geschaut ob es da irgendwo den eintrag msDS-KEyCredentialLink gibt wo ein häkchen davor ist - gibt es aber nicht
  4. Zugriff auf den wert msDS-KEyCredentialLink vom Administrator wird für Exchange Servers verweigert, oder hab ich da was falsch gemacht?
  5. Servus miteinander, Ich habe gerade in einer Testumgebung wo es nur einen neuinstallierten und unkonfigurierten DC und einen Exchange 2019 gibt, mal PurpleKnight angeworfen. Da kommen natürlich einige Meldungen zusammen, aber eine ist recht hartnäckig wo ich nicht wirklich weiter weiß, was ich da noch einstellen kann um das Testsystem zu härten (und später natürlich auch das Produktivsystem) PurpleKnight meldet, dass die Gruppe Exchange Servers im Domänen-Administrator Konto den msDS-KEyCredentialLink wert schreiben kann. Nur habe ich ich dies bereits über eine Sicherheits-Verweigerungsregel im Administrator-Konto angepasst, dass die ExchangeServers Gruppe nicht schreiben darf auf den Eintrag. Dennoch meckert PurpleKnight diesen wert an. Was müsste ich den jetzt wie ändern, damit das sauber ist?
  6. muss das Thema nochmal hoch holen...man könnte also jetzt ein Zertifikat kaufen für 99€ im Jahr in etwa (mehrere Subdomains, darum direkt Wildcard-Zertifikat, ReverseProxy unterstützt nur ein Zertifikat) und tauscht das Zertifikat 1x im Jahr aus, oder man bleibt beim LetsEncrypt Zertifikat aber muss es dann halt aller 3 Monate tauschen - ist dafür Kostenlos. Eine sache die ic mich noch etwas frage - wenn der Exchange dann ein öffentliches Zertifikat auf seinem IIS liegen hat, dann müssten die internen Client Computer aber die RootCA des Zertifikat-anbieters über das Internet erreichen müssen, damit Outlook nicht rummeckert, oder? Gibt ein paar Clients die haben zwar Outlook drauf - aber keine Internetverbindung (Webproxy mit authentifizierung only, und einige User dürfen halt nichts)
  7. Jagut, Security kostet, klar...aber manchmal beschleicht einem das gefühl, dass da einige andere ganz gerne mit verdienen wollen wohne effektiven Mehrwert... UTM = Securepoint
  8. jep, habe ich gelesen, dachte nur dass es auch ein SSL Offloading ist weil die anfragen ja erstmal auf dem Reverseproxy "landen" Gekaufte Zertifikate hatten wir früher mal, aber wenns das auch kostenlos mit LetsEncrypt gibt und die Firewall das automatisch aktualisiert kann mans ja auch so machen nur unschön das MS das jetzt unnötig kompliziert macht wenn man ein erhöhtes maß an Sicherheit haben möchte...
  9. Guten Morgen, Kurze frage zum Verständnis zwecks dem Extended Protection https://microsoft.github.io/CSS-Exchange/Security/Extended-Protection/ Gegeben ist: - ca. 50 User Umgebung - ca. 10 Außendienstler die sich ebenfalls via Handys und Outlook mit dem Exchange verbinden - einen Exchange 2019 Server, on Premise - eigene interne PKI um Selbstsignierte Zertifikate Netz-intern zu verwalten und zu nutzen - für die UTM/Firewall wird ein LetsEncrypt Zertifikat genutzt - UTM/Firewall mit aktivem ReverseProxy wo nur bestimmte Exchange Dienste durchkommen, ECP wird NICHT durchgelassen (von extern eingehend, URLpath_regex: ^/EWS ^/ews ^/mapi ^/Mapi ^/Microsoft-Server-ActiveSync ^/OAB ^/oab ^/owa ^/Autodiscover ^/autodiscover ^/eas ^/EAS ^/rpc ^/RPC ^/AUTODISCOVER ^/MAPI ^/exchange ^/Rpc ) dieser nutzt auch das LetsEncrypt Zertifikat für zugriffe von extern, intern leitet er die anfragen an den Exchange weiter mit dem selbstsigniertem Zertifikat Nach meinem Verständnis her würde es genau hier beim ReverseProxy knallen wenn ich Extended Protection aktivieren würde, da SSL Offloading nicht unterstützt wird. Ich müsste also das Letsencrypt Zertifikat auch dem IIS vom Exchange zuordnen, aber das wird ja aller 3 Monate getauscht - unschön also jedes mal das IIS Zertifikat zu tauschen, und das Selbstsignierte Zertifikate dem ReverseProxy mitgeben ist auch nicht schön. Wie macht man dann sowas? Oder habe ich da was falsch verstanden?
  10. natürlich nicht so häufig Aber ich finde es halt schade dass man was Konstruiert hat aber nicht voll ausgereizt wird...gut klar, redundanz war da eigentlich eher das Ziel Aber wenns schon mal da ist, will man das doch gern mit nutzen finde ich. 1-2x im Monat schubse ich die VMs umher zwecks Windows-Updates auf den Hosts. Und das dauert dann natürlich ein paar Minuten bei 25 VMs mit insgesamt 320GB Ram verbrauch. Und wenn ich sehe dass Windows - warum auch immer - alles nur über eine 10G Leitung schiebt statt die zweite mit zu nutzen, bringt das immer leichte selbstzweifel auf warum es das so macht. Aber um nochmal auf das eigentliche Thema zurück zu kommen - es ist egal ob ich jetzt noch zusätzlich die Regel 2 und 4 deaktiviere oder aktiviert lasse, da regel 1&3 aktiv ist und damit über den anderen (default) Einstellungen steht?
  11. Serverseitig haben wir natürlich überall SMB1 deaktiviert gelassen, es gibt aber einen Windows 10 Client, welcher leider SMB1 aktiviert haben muss (da aber auch nur SMB1 Client - NICHT Server) weil dieser PC mit ein paar Spezial-Druckern kommunizieren muss. die Drucker sind zwar als Drucker unter Windows10 installiert, allerdings als File-Pipe, das Druckobjekt wird als zip vom Treiber verpackt und per SMB1 an die Drucker geschickt...Fragt nicht - es gibt vom Hersteller leider nix "moderneres" Mir ist halt nur aufgefallen, dass gerade bei den Clients standardmäßig eine der "wenn gegenseite zustimmt" Option aktiv ist - ich hab aber nur die GPO ausgerollt das Client und Server immer signieren sollen und alles andere auf unkonfiguriert gelassen in der GPO. die HyperV knoten haben keine RDMA NICs drin, daher arbeite ich da mit SMB Komprimieren für die Livemigration. Schade nur, dass immer nur eine der zwei möglichen 10G Netzwerkkarten genutzt wird obwohl ich 4 VMs gleichzeitig migrieren lasse -.-
  12. Servus, wie sollte man optimalerweise in einem Domänen-Netzwerk die SMB Signierung einstellen? Es gibt ja insgesamt 4 Regeln: 1. Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer) 2. Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt) 3. Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer) 4. Microsoft-Netzwerk (Server): Kommunikation digital signieren (wenn Client zustimmt) sollte man Regel 1 und 3 auf aktiviert setzen und Regel 2 und 4 auf deaktiviert setzen, oder wird Regel 2 und 4 durch Regel 1 und 3 ohnehin ausgehebelt? So richtig schlau werde ich aus der MS Beschreibung nicht: https://go.microsoft.com/fwlink/?LinkID=787136 für SMB1 und SMB2 gilt wenn SMB Signierung erforderlich ist, ist die Regel 1 und 3 zu aktivieren. Regel 2 und 4 würde nur für SMB1 greifen, aber wenn bereits Regel 1 und 3 aktiviert ist - gilt das dann auch zwingend für SMB1? Ist es dann egal ob Regel 2 und 4 zusätzlich aktiv ist? Oder wäre eine unsignierte Kommunikation über SMB1 dann dennoch möglich (auch wenn Regel 1 und 3 aktiv sind) und: Es soll ja einen Leistungseinbruch geben bei aktivierter Signierung, was beim 10G Netzwerk wohl noch höher ausfallen soll. Was mach ich aber bei einem HyperV Failover-Cluster der die VMs per Livemigration via SMB auf ein anderen Knoten schiebt - das würde ja dann auch langsamer gehen, oder?
  13. Fehler war, das es anscheinend die Papierkörbe zwar mit kopiert hat, aber da nicht die Berechtigung des Users gesetzt hat. Ich habe also in jedem umgeleitetem Ordner den $Recycle.bin gelöscht - sodass der Client einen neuen Ordner mit korrekten rechten angelegt hatte. Das ganze natürlich per Skript gemacht (suche Papierkorb in umgeleitete Elemente, rekursiv, und lösche das.
  14. Hallo allerseits, vor ein paar Tagen haben wir unseren Fileserver migriert auf Server 2019 (vorher 2012R2), alle Daten mit dem Windows eigenen Fileserver Migration Toolkit incl. freigaben. Hat auch alles fast wunderbar funktioniert, den bei ein paar wenigen Benutzern lassen sich Dateien die unter Dokumente liegen (also eigen Dateien) nicht löschen. Es gibt für alle User eine Ordnerumleitung GPO, welche auch angepasst wurde für den neuen Servernamen (Häkchen für Dateiumzug in der GPO ist raus). Selbst wenn der User eine neue Datei anlegt - kann er diese nicht löschen, es erscheint dann immer die Meldung, das er selbst rechte für die Datei braucht zum löschen. Wenn man allerdings in die Eigenschaften des Papierkorbs geht und für Dokumente die Option setzt das er sofort löschen soll und nicht in den Papierkorb schieben soll - dann geht auch das Löschen... Es gibt also Probleme mit dem Verschieben aus dem Umgeleiteten Dokumente (was auf dem Server liegt) in den Papierkorb - aber eben nur bei ganz wenigen Leuten...aber warum? Wonach könnte ich da suchen?
  15. bei so einem USN Rollback - da funktioniert die ganze Domäne nicht mehr, oder? Also keiner kann sich mehr anmelden, oder wie macht sich das bemerkbar? und wie verhält es sich wenn man 3 DCs hat, und man einen der untergeordneten DCs aus einem backup wiederherstellen würde (also einen der KEINE FSMO Rollen trägt). würde dann nur dieser eine wiederhergestellte server "sgeperrt" werden, oder auch die anderen beiden die sich eigentlich bestens miteinander "verstanden" haben ?
×
×
  • Neu erstellen...