wznutzer

evtl. Denkfehler meinerseits? Ich dachte so an: "Hilfe, ich komme nicht mehr an meine Daten!" Und dann gibt es Support um wieder an die Daten zu kommen. Aber Du hast Recht. Dell würde ja auch nur dafür sorgen, dass die Kiste bei einem Hardwaredefekt wieder läuft und den Rest muss ich selber machen. Muss ich mir nochmals überlegen.

Guten Tag, ich hoffe ich habe das richtige Forum erwischt. Man sagt ja, dass die Frage nicht "ob" sondern "wann" lautet, bis es einem mit Ransomware erwischt. Diese Sache mit einem Immutable Storage würde mir sehr gut gefallen. Mit Veeam ist das auch schick nutzbar. Es gibt von Veeam auch prima Anleitungen wie das ohne viel Geld mit einem Linux-Blech umgesetzt werden kann. Die haben das sogar in einem Installationsscript zusammengefasst. Funktioniert prima, alles gut. Da es mich aber vor dem schlimmsten aller Unfälle bewahren soll, wäre eine Lösung mit Support schön. Qnap mit Veeam soll lt. den Veeam-Foren eher schlecht als recht funktionieren. Ich finde leider keinen Anbieter (On-prem) bei dem es nicht schnell sechsstellig (Dell ECS) wird. Scheint eine Enterprise-Sache zu sein. Mein derzeitiges Immutable-Backup ist old school mit LTO7 und wechselnden HDDs im Tresor. Ist auch OK, aber halt nicht automatisch. Hat jemand zufällig eine Lösung in Betrieb die so 50 TB umfasst und < 20.000€ kostet? Grüße und noch einen schönen Tag.

Guten Morgen, herzlichen Dank für den regen Austausch. Die kaufmännische Seite hat da Verträge, aber ein Vertrag ist für meine Bedenken nur dazu da um einen Schuldigen zu finden. Er verhindert ja nichts. Nein. Das wäre mein Traum . Nochmals Danke für die ausführliche Antwort. Vom Rest habe ich tatsächlich schon einiges umgesetzt (Tier-Konzept, MFA, Clients teilweise separiert usw.). Um zwei Dinge werde ich mich unabhängig davon kümmern. Evtl. mag mich jemand noch in die richtige Richtung schubsen. AD-Objekte per LDAP auslesen verhindern: Hätte mir da jemand einen Link über weitere Informationen? Druckspooler: Ist das (Printnightmare mal außen vor) ein generelles Sicherheitsproblem? Meine Eingangs erwähnte Variante, ein komplettes AD neu aufzubauen habe ich nach dieser Diskussion verworfen. Das halte ich dann doch für übertrieben. Ich werde wohl einen separaten RDS in einem eigenen VLAN dafür richten und den möglichst so zunageln, dass dieser zwar alles nötige nutzen kann, aber auch nicht mehr. Weiterer Aufwand ist dann wohl besser in Dinge investiert, die generell nicht nur für den Fall "extern" was bringen. Kennt hier jemand das Tool Purple Knight oder Forest Druid? Empfehlenswert für die AD-Sicherheit? Es wird in einem Blog erwähnt: https://www.semperis.com/de/category/ad-security-101/ Die Lizenzen sind safe. Die Leute machen unsere Arbeit. Das wollte ich jetzt nicht hören . Vielen Dank nochmals an alle.

Vielen dank für den regen Austausch. Ich glaube, ich habe einen etwas anderen Bedarf. Bei mir geht es um Vertrieb und Marketing. Die arbeiten dauerhaft, geben Leads ein, erstellen Angebote, Aufträge, aber sind halt externe Agenturen / Fachhändler. Wenn ich das richtig verstehe, gibt es bei den vorgeschlagenen Vorgehensweisen keinen Schutz vor Böswilligkeit, es gibt einen Vertrauensvorschuss. Bisher lassen wir grundsätzlich keine Dritten ins Netz. Klappt ganz gut, außer Veeam besteht bei manchen Case auf eine Webex-Sitzung. Selbst das machen wir dann nur im Ansichtsmodus und hinterher wird die VM zurückgesetzt. Die Idee war möglichst eine Konfiguration zu haben, die im schlimmsten Fall kompromittiert ist und sich nicht auf den Rest auswirkt. Also es soll selbst dann sicher sein, wenn jemand absichtlich versucht etwas anzustellen. Das scheint eher unüblich zu sein. Auch die Dienstleister sagen, bei allen anderen gibt es einen Zugang wie für jeden regulären Mitarbeiter (VPN, RDP auf RDS fertig). Darf ich die Diskussion nochmals in eine Richtung lenken. Ich tendiere noch immer dazu den RDS in einem VLAN zu separieren. Um den SQL-Port mache ich mir weniger sorgen, aber ich brauche halt auch Ports zum AD: TCP 135 Microsoft RPC TCP/UDP 49152 – 65535 RPC Dynamic Ports TCP 88 Kerberos TCP 389 LDAP UDP 53 DNS TCP 445 SMB Gibt es da etwas besonderes zu beachten (aktuelle Systeme, komplexe und lange Passwörter)? Danke und ein schönes Restwochenende

Es benötigt einen Client, eine ganz normale Windows-Forms Anwendung. Deswegen der RDS. Für das was getan werden muss, ist jedoch ein Browser ausreichend. Ich dachte, ich mache das über den HTML5-Client, gebe aber nicht den kompletten Desktop frei, sondern nur die Anwendung (Remote-App). Im Prinzip will ich mich vor dem Szenario schützen, dass im schlimmsten Fall der Anwender böswillig handelt oder seine Zugangsdaten unvorsichtig weitergibt. Auch dann soll möglichst nichts passieren können. Aber vielleicht übertreibe ich auch.

Tatsächlich nur ERP (Vertrieb, Marketing) keine Dienstleister die irgendwas an der Infrastruktur mitarbeiten müssen.

D. h. die Überlegung, dass ein evtl. kompromittierter RDS "nur" mit einem RODC und nicht mit den anderen RWDC kommunizieren darf ist praktisch wertlos? Würde der RODC kompromittiert, ist es dann nicht egal ob dieser physikalisch oder virtuell an einem "unsicheren Ort" steht?

Eine weitere Erkenntnis: Es betrifft tatsächlich nur HDDs, also Magnetfestplatten. Wir machen das jetzt organisatorisch. Die User behalten das jetzt einfach im Blick und entsperren die HDD erneut.

Habe ich irgendwie einen Knoten im Kopf, ob das reicht. Applocker, hoffentlich korrekt konfiguriert keine Ordner auf C:\ anlegen keine cmd.exe kein Internet eigenes VLAN und nur zulassen was für das AD, Virenscanner, den Remote-Zugriff und die ERP-Software nötig ist. Zugriff nur auf die ERP-Anwendung (Remote-App) Ich überlege, ob ich in das VLAN einen schreibgeschützten DC packen kann. Dann darf der RDS nur mit dem RODC kommunizieren. Bringt ein schreibgeschützter DC im separaten "extern VLAN" in solch einem Szenario einen Sicherheitsvorteil?

Wenn man der VM kurz das Netz nimmt, dann kann die Aufgabe gespeichert werden und funktioniert dann auch, seltsam.

Ich muss mir das nochmals überlegen, ob ich da nicht ein wenig übertreibe. Die vorgeschlagenen Lösungen basieren ja darauf, dass die externen User im Prinzip wie interne behandelt werden. Evtl. mit zeitlicher Beschränkung oder auch nicht. Aber sie sind im Netz und können dann das tun was eben User tun können die im internen Netz sind. Ich unterstelle den externen weniger Achtsamkeit als den direkt angestellten Kollegen und will die gar nicht im Netz haben. Vielleicht liege ich da aber falsch. Sinn war war zu erfahren, wie das sonst so gehandhabt wird. Vielen Dank dafür.

Hallo zusammen, schon ein paar mal ist mir aufgefallen, dass beim Anlegen eines Tasks sich das MMC der Aufgabenplanung komplett aufhängt, wenn ich den Task ohne Anmeldung (unabhängig von der Benutzeranmeldung ausführen) ausführen will. Die Aufgabe kann dann nicht gespeichert werden, es hängt direkt nach der Eingabe des Passwortes. Ich hatte das hin und wieder schon unter 2012R2 und jetzt auch wieder unter W2K22. Bisher hat geholfen den Dienst der Aufgabenplanung neu zu starten (psexec -i -s) oder auch manchmal den ganzen Server. Nun aber hilft das alles nichts. Nach Eingabe des Passwortes hängt sich alles auf. Im Eventlog ist nichts zu erkennen. Tritt bei lokalen und/oder Domänenaccounts auf Kennt jemand von euch dieses Problem? Danke und Grüße

Das ist dann eher das Szenario, dass ein Dienstleister bei einem ganz bestimmten Problem (z. B. Hersteller von ERP-Software usw.) hilft, richtig? Bei mir sind es eher Vertriebler, Marketing, die im ERP-System dauerhaft mitarbeiten sollen. Aber danke für den Tipp, ich habe schon davon gehört, aber nicht gedacht, dass das breit verwendet wird.

Hallo und guten Tag, mich würde interessieren wie die Zugriffe von externen Dienstleister / Freelancer bei euch geregelt sind. Ich hatte das bisher nicht. Aber nun sollen auch externe Dienstleister Zugriff auf unsere ERP-Lösung erhalten. Die Leute sind nicht am Standort. Möglicheit 1 So handhaben wie alle anderen Kollegen im Außendienst auch, also VPN oder RDS-Gateway mit MFA und Zugriff auf einen RD-Sessionhost. ==> Gefällt mir irgendwie gar nicht, weil es halt "externe" sind und die Kollegen das z. B. nur mit per Azure verwalteten Geräten machen. Die "externen" wollen aber ihre eigenen Geräte nutzen. Möglichkeit 2 Ich bastel mir ein separates VLAN in das sich die Externen einwählen können, die haben dann ein eigenes AD, einen eigenen RD-Sessionhost und es gibt "nur" die Tür SQL-Server für das ERP in das Produktivnetz. ==> Gefällt mir von der Trennung her gut, aber es ist halt auch Aufwand. Möglichkeit 3 Eine andere Lösung die ich derzeit noch nicht kenne? Es geht um 4 Leute. Der RD-Sessionhost wäre in allen Fällen "nur" per HTML5-Client für den RD-Gateway erreichbar. Applocker usw. ist sowieso auf den RD-Sessionhost aktiv. Grüße und noch einen schönen Tag.

Hallo, das ist schon etwas länger her. Die Einstellungen des Energieplans haben leider nichts verändert. Ganz konkret konnte ich die Ursache noch nicht finden, aber es könnte mit der USB-HDD selbst zusammenhängen. Während es an manchen USB-HDDs nie passiert, lässt es sich bei einiges USB-HDDs nachvollziehen. Evtl. haben manche USB-HDDs einen eigenen Energiesparmodus, der dann Bitlocker durcheinander bringt. Grüße und ein schönes Wochenende

Ich glaube das ist etwas anderes. Dieser Wert beschreibt, so verstehe ich das, eine Schwelle in der ein Zähler für Autorisierungsfehler im TPM hochgezählt wird. So soll dann ein Standardnutzer daran gehindert werden Passwörter durchzuprobieren. Alle Fehler die dieses Zeitfenster überschreiten werden ignoriert. Bei mir müsste es Bitlocker to go sein (Wechseldatenträger), auch wenn es in der UI einfach nur "Bitlocker aktivieren" heißt. Das TPM dürfte hier (???) nicht mit im Spiel sein.

Hallo, wir verwenden für den Datenaustausch mit HDDs (die das Haus verlassen) Bitlocker. Funktioniert prima, aber seit ein paar Monaten fällt auf, dass die entsperrten HDDs (USB) sich wieder sperren, wenn das Laufwerk einige Zeit nicht genutzt wird und sich abschaltet. Ich finde allerdings keine solch eine Einstellung, also eine Art Timeout. Weiß hier jemand Rat? Grüße und Danke

Haben wir die User umbenannt. Es war auch tatsächlich nie ein Problem, bis jetzt. Evtl. kommt es ja auch auf die Größe an. Ich habe jeden Kollegen/Kollegin mindestens 1x mit Handschlag begrüßt und kann mit dem Namen sofort die Abteilung nennen. Deswegen ist irgendwas, dass ich mit dem Namen in Verbindung bringen kann, ein Vorteil. Aber zurück zum Problem. Da das Zurücksetzen einer W11-Installation das Anmeldeproblem behebt, gehe ich vom einem Fehler im OS aus. Insofern ist ein Anmeldename ohne Umlaute ein guter Weg, ohne sich Sorgen machen zu müssen, dass sonst noch etwas nicht in Ordnung ist. Vielen Dank für die guten Kommentare

Den Kollegen und Kolleginnen gefällt das . Wie man heißt vergisst man meist nicht. Aber ich gebe zu, bei drei Vornamen und einem Doppelnachnamen wird es dann schon etwas arg.

Die User verwenden das SQL-Management Studio, aber auch eigen entwickelte Software die per ODBC (SQL Native Client) zugreift hat das Problem. Selbst ein kleines Testprogramm mit der MFC (CDatabase) oder C# funktioniert nicht. Es ist kein Kerberos-Problem. Wenn der SPN da ist, funktioniert es. Es ist aber auch kein spezielles SQL Problem, weil der Zugriff auf \\domain.local auch zu einer Meldung mit falschen Anmeldedaten führt. Es ist evtl. mein Problem, dass ich mich noch nicht getraut habe NTLM komplett abzuschalten . Nur User mit Umlaut im Anmeldenamen sind betroffen. Windows 10 nicht, Windows 11 22H2 mit allen Updates auch nicht. Sobald dann der gleiche PC auf W11 23H2 angehoben wird, tritt der Fehler auf. Windows 11 23H2 mit dem März 2024 ISO installiert hat den Fehler auch nicht. Windows 11 23H2 mit dem November 2023 ISO installiert und dann bis zum Patchday 03/2024 aktualisiert führt zum gleichen Problem. Das Problem kann in einer Testumgebung (hat noch nie das Produktivnetz gesehen) nachvollzogen werden. kleine Bitte Falls jemand einen W11 23H2 PC (oder VM) hat, der vor März 2024 installiert wurde und vielleicht auch von 22H2 angehoben wurde, wäre prima da einfach mal \\[FQDN der lokalen Domäne] im Explorer eingeben (User mit Umlaut). Normalerweise sollte da ja dann Netlogon und SysVol (und evtl. ein Freigabeordner vom dc auf dem man gerade gelandet ist) angezeigt werden. Vielen Dank für die Kommentare, ich werde berichten...

Ja, ich dachte mich betrifft das nicht und ich konnte auch keinen übermäßigen Speicherverbrauch feststellen. Der OOB-Patch sollte doch im aktuellen April-Patch mit drin sein oder? Den installiere ich sowieso heute Nacht, ich werde dann berichten. Ich kapiere nicht warum. Der User meldet sich lokal an, nutzt Netzwerkfreigaben, RDP, Fileserver und der SQL-Server meint dann, dass das Passwort falsch ist? *weitergrübelnd*

Vielen Dank für eure Mühe. Der SQL-Server hat noch kein MSA und läuft tatsächlich noch mit einen "normalen" Domänenaccount. Der fehlende SPN ist nicht aufgefallen, weil einfach NTLM gemacht wurde. Aber nun schlägt NTLM fehl, weil lt. Log der Benutzername oder das Kennwort falsch ist. Mit W11 23H2 scheint es nichts zu tun zu haben, eher Zufall. Der gleiche Account kann sich an verschiedenen PCs mit W11 23H2 problemlos mit dem SQL auch per NTLM verbinden. nltest /sc_query:domäne ==> alles in Ordnung \\domäne.local ==> Sysvol usw. wird nicht angezeigt, Anmeldedialog erscheint \\irgendeinDC ==> Sysvol wird angezeigt, alles prima Ich forsche mal weiter...

Seltsamerweise wird beim Zugriff per NTLM folgendes am SQL-Server protokolliert: Gleicher Account an verschiedenen anderen Rechnern funktioniert?

Guten Tag, irgendeine Info scheint an mir vorbeigegangen zu sein. W2K22 mit 2 SQL-Server Instanzen Nur eine Domäne, Windows-Authentifizierung Windows 10 und Windows 11 vor 23H2 können sich problemlos mit beiden Instanzen verbinden. Windows 11 23H2 meldet: Es liegt am fehlenden SPN und für das gibt es ja auch auch den "Microsoft® Kerberos Configuration Manager for SQL Server®". Ich kapiere aber nicht warum? Hat sich mit Windows 11 23H2 irgendwas verändert das Kerberos erzwingt? Ahnungslose Grüße

Aber ich gehe schwer davon aus, dass der Hinweis in der nachfolgenden Umfrage 10 Punkte zu vergeben nie gefehlt hat.