Alle Aktivitäten

Hi, unter diesen Umständen würde ich mir derzeit die Frage gar nicht stellen. Der Exchange hängt ja scheinbar (direkt) am Internet und Mitte Oktober ist es mit dem Support vorbei. Evtl. sollte man hier über eine Migration zu Exchange Server SE (oder in Exchange online) nachdenken und in diesem Step direkt nach Best Practices vorgehen, die sich im Falle von ExO von alleine erledigen: Split DNS öffentliches Zertifikat Falls es nichts "kosten" darf -> Let's Encrypt oder ähnlich Generell würde ich beim Vorfinden eines solchen Exchanges einen Fahrplan in Richtung Split DNS + öffentliches Zertifikat aufstellen bzw. dankend ablehnen. (Zusätzlich wäre zu beleuchten, ob der Exchange wirklich direkt und ohne Web Application Firewall im Internet hängen muss, sofern er dies denn derzeit tut.) Gruß Jan

Hi, der Windows Server Essentials ist Domain Controller und gleichzeitig Hyper-V? Oder ist die Hyper-V Rolle "auf der Hardware" installiert und der Essentials läuft bereits als VM unter Hyper-V? Losgelöst davon ist das meiner Meinung nach eine echt bescheidene Idee, den Essentials als Hyper-V Host zu nutzen und den Essentials dann als VM zu betreiben. Für die zweite RDS VM wirst du am Ende so oder so eine Windows Server Standard (samt CALs) benötigen und kannst daher auch gleich auf den Essentials verzichten. Gruß Jan

Dann prüf mal die DNS Auflösung.

ja - ECP ja funktioniert. Ich weiß nicht 100% welcher Dienst für Exchange Powershell zuständig. Ich weiß nur das IIS/WWW und FMS Microsoft-Filterverwaltungsdienst aktuell gestartet sind.

Hallo, oftmals hört man ja aktuelle Smartphones und Selfsign Zertifikate funktionieren mittlerweile nicht mehr. Ist das auf jeden Fall richtig? (kann ja sein, das Parameter wie Laufzeit/SHA256 nur ausschlaggebend sind) Gekaufte SSL Zertifikate sind günstig und sollten sofort besorgt werden, weil man sich damit die Probleme mit Selfsign vom Hals hällt. Selfsign Zertifikat haben meiner Vermutung nach kein Vorteil in ganz kleinen KMU´s. Habe ein Exchange 2016 vorgefunden mit Selfsign Zertifikat. Hab Vorort geprüft, bei den zwei Power Usern am iPhone unter "iOS / Allgemein / info / Zertifikatsvertrauenseinstellungen" habe ich kein installierte CA Root Zertifikat gesehen. Trotzdem funktioniert der Emailsync. Relativ sicher hatten die beiden iPhones hatten aktuelles iOS. Kann man so leicht erklären wieso das funktioniert? Ich weiß, am besten man testet das nochmal mit einem frischen iPhone nach Reset. +++ Dann kam noch ein Nachzügler mit Android an den Tresen. Habe das o.g. Selfsign Exchange CA Certifikat meiner Vermutung nach erfolgreich im Android installiert. Konnte dann allerdings das Exchangekonto nicht hinzufügen. Ob die Android Fehlermeldung: "Bestätigen des Konto nicht möglich, Sicherheitsfehler, Serverzertifikat nicht vertrauenswürdig" das Hauptproblem war weiß ich nicht mehr genau. Muss man im Android Selfsign Zertifikat nochmal explizit erlauben? (wie beim iPhone) Selfsign CA Zertifikate im Android fügt man scheinbar an dieser Stelle hinzu: Android / Einstellungen / weitere Sicherheitseinstellungen Sicherheitszertifikate anzeigen Benutzerzertifikate vom Gerätespeicher installieren

Moin. Funktioniert denn ECP noch? Hast Du die Zertifikate überprüft? Sind alle Dienste gestartet?

Funktioniert nicht mehr ist keine hilfreiche Fehlerbeschreibung. Das Ereignisprotokoll auf beiden Seiten, gibt sicherlich mehr Aufschluß als funktioniert nicht. Probier mal mstsc /admin oder mstsc /console aus, wird dabei die Verbindung zum DC hergestellt?

Hallo, wollte die Exchange Powershell starten. (mit Domainadministrator am Exch 2019 eingeloggt, aktuelle Version) (mit Rechtsklick als Administrator starten wurde auch probiert) Es hat schonmal funktioniert. Serverneustart war noch nicht. Würde es mit "set-executionpolicy Unrestricted" funktionieren oder warum startet die Powershell nicht? Es kam rote Meldung á la .\skript.ps1 : Die Datei "C:\work\skript.ps1" kann nicht geladen werden, da die Ausführung von Skripts auf diesem System deaktiviert ist. Weitere Informationen finden Sie unter "about_Execution_Policies" (https:/go.microsoft.com/fwlink/?LinkID=135170). Habe dies eingeben: set-executionpolicy remotesigned Nun kommt diese Meldung: AUSFÜHRLICH: Verbindung mit firma-EXC03.firmahh.local wird hergestellt. New-PSSession : [firma-exc03.firmahh.local] Beim Verbinden mit dem Remoteserver "firma-exc03.firmahh.local" ist folgender Fehler aufgetreten: WinRM kann den Vorgang nicht abschließen. Überprüfen Sie, ob der angegebene Computername gültig, der Computer über das Netzwerk erreichbar und eine Firewallausnahme für den WinRM-Dienst aktiviert ist und den Zugriff von diesem Computer zulässt. Standardmäßig wird der Zugriff auf Remotecomputer innerhalb desselben lokalen Subnetzes von der WinRM-Firewallausnahme für öffentliche Profile eingeschränkt. Weitere Informationen finden Sie im Hilfethema "about_Remote_Troubleshooting". In Zeile:1 Zeichen:1 + New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName Micr ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin gTransportException + FullyQualifiedErrorId : WinRMOperationTimeout,PSSessionOpenFailed

Ist das bereits eine Produktive Umgebung oder eine Testumgebung zum „Spielen“? Ich würde alles frisch aufsetzen, so wird das nichts - meine Meinung

Hallo zusammen, ich habe hier einen Windows Server 2022 Standard 21H2 (Essentials). Dies ist der Domänencontroller. Hyper-V ist installiert mit einer VM. Die VM ist ein Terminalserver. In der Vergangenheit habe ich versucht, den Terminalserver auf dem Hyper-V-Server zu installieren. Dazu habe ich alle möglichen Remotedesktop-Rollen auf dem DC installiert. Das war b***d von mir. Vor allem funktioniert das nicht auf einem DC. Ich möchte mich als Administrator per RDP (mstsc) mit dem Server verbinden, aber es funktioniert nicht mehr, seitdem ich all diese Rollen und Features installiert habe. Keine anderen Benutzer sind verbunden. Ich kann mich jedoch weiterhin mit der VM verbinden. In einer Situation konnte ich mich mit dem Server verbinden, aber nach der Passworteingabe erhielt ich den Fehler 0x808 (0x101), dass kein Lizenzserver für Remotedesktop verfügbar ist. Ich habe inzwischen alle Rollen im Zusammenhang mit dem Terminalserver und RDP, die ich installiert hatte, wieder entfernt. Aber ich kann RDS-Virtualisierung nicht deinstallieren. Nach der Deinstallation ist sie nach einem Neustart wieder da. Ich habe bereits Uninstall-WindowsFeature -Name RDS-Virtualization -Remove ausprobiert. Im Server-Manager erscheint ein Menüpunkt zu Remotedesktopdiensten. Dort steht jedoch, dass kein Connection-Broker-Server im Pool ist. Im Untermenü „Server“ wird mein DC aufgelistet. Im Ereignismanager habe ich einen Fehler im Zusammenhang mit dem Deinstallationsprozess gefunden: 0x80070057 falscher Parameter. Mehr Informationen habe ich aber nicht. DISM /RestoreHealth und sfc /scannow haben keine Probleme gefunden. Ich verwende kein VDI, aber könnte Hyper-V vielleicht die Rolle nach dem Neustart wieder installieren? Muss ich die Rolle deinstallieren, damit RDP wieder funktioniert, oder könnte es auch andere Gründe geben? Wo könnte ich ein detailliertes Protokoll zu den Problemen bei der Deinstallation und eventuell auch zur Installation finden? Wie könnte ich mehr über das Problem herausfinden ? Vielen Dank!

Schönes Beispiel. So könnte man jetzt viele weitere Kombinationen erstellen nach der Art: Wenn --> Dann = Schuld VG Damian

Studien zur Schädlichkeit des Kaffeekonsums sind kritisch zu bewerten. Oft wurde übersehen, dass der Kaffeetrinker auch Raucher ist und die scheinbaren Folgen des Kaffeekonsums diesem keineswegs anzulasten sind. Koinzidenz begründet keine Kausalität

Naja, "Deaktivieren" ist sicher kontraproduktiv Und "ein paar lokale GPOs gesetzt" ist auch relativ undefiniert.

Ja, sorry. Hat sich erledigt: Zum Testen die falsche Datei genommen. Im Powershell-Test waren es Ordner. Den Gedanken hatte ich, nachdem ich Thema erstellen geklickt hatte

Startet die Powershell überhaupt? Siehst du im Task Manager. Was sagen die Taskplaner Logs?

Moin. Ich sehe gerade den Wald vor lauter Bäumen nicht: Via Taskplaner sollen Dateien von einem NAS auf eine Windows-Freigabe verschoben werden. Den Task habe ich erstellt mit "Programm ausführen": Powershell und die Argumente -ExecutionPolicy Bypass -File "C:\Batches\SD-RSH.ps1" verwendet. Der Task wird ausgeführt und beendet, aber es passiert genau nichts. Per Powershell direkt ausgeführt, funktioniert das Skript. Was habe ich vergesssen/übersehen? Host ist überigens Windows Server 2016 oder auch 2019 (beide probiert)

Moin Koffeinentzug. Empfohlen vom Gesundbeter unseres Beinahevertrauens um Mitternacht an der Wegegabelung im Breitscheider Kreuz. Gibt es Verluste? VG Damian

Moin an Board, auf geht es in den Tag - ich koche Kaffee TGIF! Allen einen stressfreien Freitag, bleibt gesund! Hier trübe bei 10°C, es bleibt den ganzen Tag so ggf. Schauer bis etwa 17°C Gestern konnte ich nicht und scheinbar war ja keiner hier...

Ich hab den Server heute Nacht neugestartet - leider bleibt das Phänomen bestehen. Interessanterweise tritt es über die Nacht quasi nicht auf. Gefühlt scheint es also mit den Zugriffen auf den Server (die Nachts definitiv deutlich geringer sind) zusammenzuhängen. Wie bekomme ich den NTLM denn gesprächiger? Ich hab mal ein paar lokale GPOs gesetzt, aber das Ereignislog des NTLM ist komplett leer.

Ich find den Substatus 0x0 eigenartig, hab ich so noch nie gesehen. Aber "alles mal booten" ist auf jeden Fall der erste Ansatz

Seit ~Oktober 2022 gibt es da keien Einschränkung mehr: Requirements to use AppLocker | Microsoft Learn

Neben dem Virenschutz solltest Ihr mindestens eine geeignete Applocker-Policy ausrollen. Die ist u.U. wirkungsvoller als ein Virenscanner. Nur ganz kurz: finales Ziel muss sein, dass ein User nur von dort Programme starten darf, wo keine Schreibberechtigung hat. Viren speichern sich meist erst in irgendeinem Ordner des Users und werden dann gestartet. Das Speichern kannst Du mit dem Applocker nicht verhindern, aber die Ausführung. Euer Virenscanner wird dann ein paar Tage später den Virus hoffentlich kennen und entsorgen. Zur Abwehr aktueller Bedrohungen sind Virenscanner meist nutzlos ("Schlangenöl"), da kein verantwortungsvoller Hacker Dir einen Virus sendet, der von einem Virenscanner erkannt wird. Falls Deine Windows-Edition keinen Applocker hat: Mit den SRP erreicht man das Gleiche. -Zahni

Hi, hat zufällig jemand Erfahrung damit? Problem: Unser neue DL nutzt Credential Guard und wir ein paar Java-Anwendungen, die Kerberos-SSO geben einen Tomcat/Websphere machen sollen. Das SSO ist mittels JAAS/krb5loginmodule implementiert. Wie ich leider erst jetzt herausgefunden habe (Google ist nicht immer hilfreich), unterstützt krb5loginmodule die native Windows SSPI-API nicht. Da ist geht nur, wenn man auf die vergleichsweise neue Java-GSS-Implementierung schwenkt. Hier braucht man dann auch kein "AllowTGTSessionKey". Credential Guard verhindert aber die Nutzung von des TGT Session Keys. Nun entwickeln wir nicht alle Anwendungen selber... Kennt sich jemand mit Credential Guard aus? Kann man da irgendwelche Ausnahmen definieren? Wen es interessiert: Die Java-Doku. Dort sind beide Variantenbeschrieben: https://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/single-signon.html Hier ein relevanter Bug: https://bugs.openjdk.org/browse/JDK-8054026 und die finale Lösung: https://bugs.openjdk.org/browse/JDK-8214079 Die native SSPI-Bridge gibt es im Java also seit 2019. Dank an Euch im Voraus. -Zahni

Moin, das Wochenende naht - vielleicht kannst Du den Server mal booten und schauen, ob der Fehler verschwindet - vielleicht hat er sein Kennwort gerollt und irgendein Subsystem hat es nicht sauber mitbekommen. Oder schau erst mal, ob die letzte Kennwortänderung nach dem letzten Boot liegt oder davor. Ansonsten, da die Anmeldung offenbar über NTLM versucht wird, kannst Du mal lokal das NTLM Logging hochdrehen und schauen, welcher Prozess gegenüber welcher Ressource das versucht... Gibt's eventuell eine vergessene RDP-Session auf der Maschine? Vielleicht von einem Admin, der Mitglied in "Protected Users" ist?

Hallo zusammen, in den Sicherheits-Meldungen eines Fileservers habe ich schon länger mehrmals pro Minute einen gescheiterten Überwachungseintrag - Ereignis ID 4625. Auf dem DC gibt es keine Fehlermeldung und das last login in den Attributen ist auch erst heute gewesen. Technisch scheint alles reibungsfrei zu funktionieren. Hat jemand einen Tipp wo ich überhaupt nach der Ursache des Phänomens schauen kann? Woher kommen überhaupt diese häufigen Authentifizierungsversuche des Computerkontos gegenüber der Domäne? Auf dem Server laufen nur Windows-Freigaben und sonst kein zusätzlicher Dienst. Fehler beim Anmelden eines Kontos. Antragsteller: Sicherheits-ID: NULL SID Kontoname: - Kontodomäne: - Anmelde-ID: 0x0 Anmeldetyp: 3 Konto, für das die Anmeldung fehlgeschlagen ist: Sicherheits-ID: NULL SID Kontoname: FILESRV-IS$ Kontodomäne: COMPA Fehlerinformationen: Fehlerursache: Bei der Anmeldung ist ein Fehler aufgetreten. Status: 0xC000006D Unterstatus:: 0x0 Prozessinformationen: Aufrufprozess-ID: 0x0 Aufrufprozessname: - Netzwerkinformationen: Arbeitsstationsname: FILESRV-IS Quellnetzwerkadresse: 192.168.11.175 Quellport: 59553 Detaillierte Authentifizierungsinformationen: Anmeldeprozess: Authentifizierungspaket: NTLM Übertragene Dienste: - Paketname (nur NTLM): - Schlüssellänge: 0 Dieses Ereignis wird beim Erstellen einer Anmeldesitzung generiert. Es wird auf dem Computer generiert, auf den zugegriffen wurde. Die Antragstellerfelder geben das Konto auf dem lokalen System an, von dem die Anmeldung angefordert wurde. Dies ist meistens ein Dienst wie der Serverdienst oder ein lokaler Prozess wie "Winlogon.exe" oder "Services.exe". Das Anmeldetypfeld gibt den jeweiligen Anmeldetyp an. Die häufigsten Typen sind 2 (interaktiv) und 3 (Netzwerk). Die Felder für die Prozessinformationen geben den Prozess und das Konto an, für die die Anmeldung angefordert wurde. Die Netzwerkfelder geben die Quelle einer Remoteanmeldeanforderung an. Der Arbeitsstationsname ist nicht immer verfügbar und kann in manchen Fällen leer bleiben. Die Felder für die Authentifizierungsinformationen enthalten detaillierte Informationen zu dieser speziellen Anmeldeanforderung. - Die übertragenen Dienste geben an, welche Zwischendienste an der Anmeldeanforderung beteiligt waren. - Der Paketname gibt das in den NTLM-Protokollen verwendete Unterprotokoll an. - Die Schlüssellänge gibt die Länge des generierten Sitzungsschlüssels an. Wenn kein Sitzungsschlüssel angefordert wurde, ist dieser Wert 0.