NilsK

Moin, Angaben wie "die Performance ist schlecht" und "es wirkt, als wäre die I/O-Performance nicht gut" sind fürs Troubleshooting wenig hilfreich. Bist du dem schon strukturierter nachgegangen? Sind andere Faktoren wie die Konfiguration der VM und der Anwendungen schon betrachtet worden? Gruß, Nils

Moin, naja, ganz so einfach ist es nicht. Vielleicht kann man andersrum sagen: "Dropbox ist nicht per se sicher". Da das Unternehmen aber gerade mit einigem Erfolg ins Enterprise-Geschäft einsteigt, ist es ganz sicher kein einfacher "Krauter". @schumi99: Meist gibt es "wahrscheinlichere" Erklärungen als einen Angriff von außen. Jedenfalls solltest du offenkundig jetzt wachsam sein. Dass du sofort dein Dropbox-Kennwort geändert hast, ist eine gute Sache ... ;) Gruß, Nils

Moin, nur zu. ja, sicher. Man kann auch sagen, wenn jemand in den Urlaub fährt und seine Terrassentür offen lässt: Er hat doch alles richtig gemacht, das einzige was man kritisieren kann, ist die Terrassentür. Also, ich weiß nicht, welche Unternehmen du so kennst. Von den Unternehmen, die ich in den letzten 20 Jahren in der IT betreut habe, würde ich es keinen fünf Prozent zutrauen, die LAPS-Prozesse umfassend und dauerhaft umzusetzen. Gruß, Nils

Moin, nachvollziehbar - aber man muss aufpassen, dass man da nicht den Teufel mit dem Beelzebub austreibt. Ein System, das überall Änderungen vornehmen kann, braucht sehr hohe Berechtigungen und ist damit ein 1a-Angriffskandidat. Gruß, Nils

Moin, meines Wissens gibt es dafür keinen lizenzrechtlich sauberen Weg. Daher wäre die korrekteste Variante, wenn ihr eine Art Installationsanleitung oder automatische Installation erzeugt, mit der eure Partner sich mit eigenen Lizenzen oder Eval-Lizenzen die Umgebung selbst bauen. Sogar Microsoft selbst hatte vor einigen Jahren erhebliche Probleme, seine Contoso-VMs für Partner intern richtig lizenziert zu bekommen - und dabei sind die ja der Lizenzgeber ... Gruß, Nils

Moin, brauch ich nicht, gibt's schon, wenn auch nicht von mir: [LAPS – lokales Admin-Passwort endlich sicher | faq-o-matic.net] http://www.faq-o-matic.net/2015/07/01/laps-lokales-admin-passwort-endlich-sicher/ Gruß, Nils

Moin, das ist genau das, was ich mit einem organisatorischen Problem meine. Das kann man vielleicht technisch ein wenig eingrenzen, aber nicht lösen. Wenn der genannte Admin die Kennwörter mitnehmen will, kann er das tun, sobald er einmal Kenntnis von ihnen erhält. Egal, welche technischen Finessen die Datenbank als ganze schützen. Gruß, Nils

Moin, nslookup ist nicht geeignet, die Namensauflösung durch den Client zu überprüfen. Es arbeitet anders als der normale Resolver. [Wenn (und warum) nslookup unerwartete Ergebnisse zeigt | faq-o-matic.net] http://www.faq-o-matic.net/2014/02/12/wenn-und-warum-nslookup-unerwartete-ergebnisse-zeigt/ Dass der Abbruch der Anmeldung mit DNS zusammenhängt, ist ausgesprochen unwahrscheinlich. In dem Moment, wo die Anmeldung beginnt, ist die Namensauflösung ja schon abgeschlossen. Gruß, Nils

Moin, ich verstehe die Frage nicht. Entweder gibt es keine technische Lösung, weil man organisatorische Probleme nur organisatorisch lösen kann. Oder die Antwort lautet "Zugriffsberechtigungen auf die Datei". Oder meinst du was anderes? Gruß, Nils

Moin, das hängt vom Einsatzgebiet und den Anforderungen ab. In dem hier diskutierten Szenario könnte es ausreichen, eine Vorgabe zum manuellen Setzen eines komplexen Kennworts zu machen. LAPS kann durchaus eine Lösung sein, aber sie passt nur, wenn es sehr strikte Prozesse gibt. Aufgrund der Architektur ist LAPS für typische mittelständische Unternehmen i.d.R. nicht geeignet. Man könnte auch etwas LAPS-Ähnliches selbst bauen, z.B. einen Task, der lokal ein Kennwort generiert, es setzt und an einen geschützten Ort schreibt. Eine einzelne Datei auf einem Server oder eine einzelne Datenbank kann man meist leichter absichern als Attribute in einem AD. Gruß, Nils

Moin, das ist ja schon beantwortet worden: Ja, sie kann Probleme bereiten. Das ist im Grundsatz zwar richtig, aber genauso bekannt ist der SID der Gruppe Administratoren. Ein engagierter Angreifer wird von dort aus weiterkommen. Abgesehen davon, wird der SID (genauer: der RID) nicht zufällig generiert, sondern einfach weitergezählt. Da es auf den meisten Servern nur sehr wenige lokale Accounts gibt, ist der neu definierte Admin also schnell gefunden. Hier und da wirst du den Account also vermutlich abschalten können (ist ja bei Clients auch so), an anderen Stellen wirst du es wegen des Funktionsrisikos aber nicht tun wollen. Und gewonnen ist damit wenig. Komplexe Kennwörter sind ziemlich eindeutig besser. LAPS halte ich allerdings nicht für eine schöne Lösung. Man muss dabei sehr viel zusätzlich gewährleisten, damit es funktioniert. Kleine Sorgfaltslücken können dann ein großes Sicherheitsproblem erzeugen. Gruß, Nils

Moin, wenn du das professionell machen willst, solltest du dir 8MAN anschauen. Der kann Mehrfachberechtigungen pro Ressource direkt anzeigen, auch Verschachtelungen werden dabei berücksichtigt. Wenn es "zu Fuß" sein soll, wirst du selbst eine Logik zum Vergleichen finden müssen. Wenn die Gruppennamen einheitlich auf -R oder -RW lauten, könntest du beim Auftreten von "-R" prüfen, ob derselbe String mit "-RW" auch in der Menge der Gruppenmitgliedschaften auftritt. Das hängt dann vor allem von der Namenslogik ab und wird immer auf der Ebene der Gruppen bleiben - die tatsächlichen Berechtigungen berührst du damit nicht. Das wäre dann eben was für 8MAN ... Gruß, Nils

Moin, ein gespiegeltes Storage bedeutet noch lange kein unterbrechungsfreies Umschalten. Das erwarten zwar viele Kunden, aber nur wenige Storage-Systeme können das wirklich leisten. Der Nutzen der Spiegelung besteht zunächst meist darin, dass keine Daten verloren gehen. Beim Ausfall des Primärsystems fällt dann aber das Gesamtsystem aus. Man kann es dann manuell auf das Sekundärsystem umstellen und neu starten. Die Daten sind alle da, aber eben nicht unterbrechungsfrei. Selbst bei höherwertigen Mimiken, die ein "transparentes Failover" unterstützen, kann es zu längeren Umschaltzeiten kommen, die die Applikationen zunächst zum Absturz bringen. Und auch bei solchen Speichersystemen gibt es Situationen, in denen das Failover gar nicht funktioniert - das ist sogar nicht einmal unwahrscheinlich. Das Stichwort ist hier "Split Brain", was i.d.R. eine dritte Instanz erfordert. Ist diese nicht vorhanden oder nicht erreichbar, dann gibt es kein Failover. Gruß, Nils

Moin, ich spüre eine gewisse Einigkeit. :D Gruß, Nils

Moin, doch, hattest du. Jetzt wird hier aber iSCSI diskutiert, das ist ja kein NAS. iSCSI halte ich in dem Szenario auch für eine schlechte Idee. Blockstorage wird das nicht mögen. Ein dateibasiertes Protokoll ist da sinnvoller. Gruß, Nils

Moin, das hat auch alles hier und da seine Berechtigung. Aber da es nun mal auf das Recovery ankommt, muss man schon genau hinsehen - 15 TB sind ja kein Pappenstiel. Und wer holt die Daten dann im Notfall mit einem Satz USB-Platten beim Dienstleister wieder ab? Wie lang dauert das? Wie lang dauert es dann, bis man die wieder eingespielt hat? Daher bin ich bei sowas immer sehr skeptisch. Gruß, Nils

Moin, das meine ich nicht mit "aus einer Hand" - das Betriebssystem und die Storage-Funktionen supportet dir ein Server-Hersteller nicht. Ein (ernst zu nehmender) NAS-Hersteller sehr wohl. 15 TB übers WAN? Na, herzlichen Glückwunsch. Gruß, Nils

Moin, naja, 15 TB netto sind ja auch groß. Der Vorteil einer (professionellen) Appliance: Support aus einer Hand. Bei einem BTO-Server ist man für das Gesamtkonstrukt selbst verantwortlich. Gruß, Nils

Moin, beim Ablauf werden die Konten auch nicht deaktiviert. Sie können sich nur nicht mehr anmelden. Hat der Rechner, von dem aus du die Anmeldung versuchst, Kontakt zum DC? Bei Cached Credentials würde der Ablauf, glaube ich, nicht greifen. Gruß, Nils

Moin, technisch betrachtet, kannst du auch ein Domänenkonto mit deinem Microsoft-Konto verbinden. Das muss natürlich im Unternehmen zulässig sein, also bitte nicht einfach so. Wenn du zwei getrennte Konten dafür willst, ist die Reihenfolge der Einrichtung egal. Bedenke aber, dass der Rechner auch bei Anmeldung mit einem lokalen Konto selbst Domänenmitglied ist und durch GPOs gesteuert wird. Und bedenke, dass eine solche Parallelnutzung von dienstlicher und privater Sphäre meist nicht erwünscht oder sogar untersagt ist. Gruß, Nils

Moin, hart Ausschalten als Standardmethode ist keine gute Idee, besonders wenn es um servergespeicherte Profile geht. Leider sind Probleme dieser Art immer schwer zu lokalisieren, weil es tausende mögliche Ursachen gibt. Wenn es aber so dramatisch ist, wie du beschreibst, sollte man da noch weitere Ressourcen investieren. Das Risiko, kritische Daten durch beschädigte Profile zu verlieren, ist in den meisten Unternehmen durchaus hoch. Aber: Braucht ihr denn servergespeicherte Profile tatsächlich? Die Technik ist derart fehlerhaft, dass ich sie vermeiden würde, wo es nur geht. Und: Tritt das Phänomen auch bei rein lokalen Profilen auf? Gruß, Nils

Moin, klingt nach einem Timeout. Nur wo der herkommt - keine Idee. Sind andere Netzwerkzugriffe ebenfalls verzögert, wenn das Phänomen auftritt? Gruß, Nils

Moin, ich werfe mal kurz in die Runde, dass im Active Directory erheblich weniger schiefgehen kann als bei Exchange. Daher reicht für einen Health Check in aller Regel turnusmäßig dcdiag aus; häufiger als wöchentlich ist es selten nötig. Daneben kann man die Dienste auf den DCs überwachen, aber auch da läuft selten etwas schief. Interessant könnte vielleicht noch die Überwachung der Eventlogs sein. In der Praxis erweist sich das AD als ausgesprochen robust. Wo es Fehler gibt, sind diese meist auf das Design zurückzuführen, dann ist ein laufender Health Check allerdings auch nicht besonders aussagekräftig. Gruß, Nils

Moin, was genau tust du, was genau passiert, was genau wird gemeldet? Abgesehen davon, musst du die Kontorichtlinien in der Default Domain Policy bearbeiten. Gruß, Nils

Moin, schön, dass es geklärt ist. Trotzdem aber bitte beim nächsten Mal einen neuen Thread aufmachen. Das hebt die Übersichtlichkeit - zumal es immer so ist, dass die scheinbare Fortsetzung des alten Threads sich in Wirklichkeit doch um neue Details dreht. Gruß, Nils