NilsK

Moin, ja, das wird nicht funktionieren. Zum Umbenennen, wenn kein Exchange genutzt wird, könntest du rendom nutzen. Alternativ müsstest du in eine neue Domäne migrieren. rendom funktioniert bei manchen völlig problemlos, bei anderen nicht. Ein gewisses Risiko besteht. Das würde ich mit jemandem in Ruhe bewerten, der sich mit der Materie gut auskennt. Gruß, Nils

Moin, das ADPrep ist eine der ursprünglichen Vorsichtsmaßnahmen, von denen Microsoft sich verabschiedet hat, weil sie sich als nicht notwendig erwiesen haben. Tatsächlich war der Prozess schon immer so sicher, dass praktisch nie was schiefging, und es hat auch schon immer "remote" funktioniert. Technisch gab es nie eine Notwendigkeit, das ADPrep separat auf dem Schemamaster zu machen. Andere Vorsichtsmaßnahmen dieser Art waren die fünfminütige Replikationsverzögerung intra-site (mit Windows 2003 entfernt), die Empfehlung, die FSMO-Rollen aufzuteilen (schon zu Windows-2000-Zeiten relativiert, später nicht weiter vertreten) oder der 180-Minuten-Standard bei der Inter-Site-Replikation. Gruß, Nils

Moin, Geht es darum, Details auszulesen oder eine Übersicht über alles zu haben? Gruß, Nils

Moin, Deiner Beschreibung nach ist die Umgebung vollständig kompromittiert. Tut mir leid, das so sagen zu müssen, aber für mich klingt das nach Neuinstallation. Die Rechner sind ja offenbar durch die Malware manipuliert. Man kann ihnen also nicht trauen. Die Entfernung der Viren stellt den Zustand dann auch nicht wieder her. Viel Erfolg, Nils

Moin, naja, wie sollen die Erfahrungen schon sein - schlecht halt. Für solche Zwecke gibt es virtuelle Maschinen. Dort entwickeln die Developer. Auf ihrem normalen Rechner haben sie keine Adminrechte. Führt auch zu Kämpfen und bedeutet Aufwand, bis man eine passende Konfig hat, dämmt das Risiko aber wenigstens ein. Gruß, Nils

Moin, also, eins sollten wir noch prüfen. Melde dich mit dem User, zu dem die whoami-Ausgabe oben gehört, an einem anderen Rechner an. Versuche dann von dort aus, auf einen Admin-Share des Rechners zuzugreifen, auf dem du whoami ausgeführt hattest. Kann er dort zugreifen? Wenn das so ist, dann ist an dem System irgendwas verdreht bzw. nicht in Ordnung. Die whoami-Ausgabe (so sie denn vollständig ist) belegt, dass der User nicht lokaler Admin ist. Wenn er von einem anderen Rechner aus einen Admin-Share auf diesem Rechner öffnen kann, dann fehlt dort anscheinend die Zugriffsbeschränkung auf lokale Administratoren. Das ist nicht ohne Weiteres zu erreichen, also muss dort was manipuliert sein. Sofern dies also zutrifft, liegt die Ursache des Phänomens nicht an falschen lokalen Admin-Mitgliedschaften. Es wird dir dann also nichts nützen, an den lokalen Admins etwas zu ändern. Was auch immer da geschehen ist, es liegt auf einer anderen Ebene. Ohne genaue Untersuchung kann man das nicht besser sagen. Und da du selbst angegeben hast, dass in dem Netzwerk schon mehrere Viren unterwegs waren - liegt der Schluss zumindest nahe, dass die Rechner tiefgreifend kompromittiert sind. Ich würde mir jetzt nicht mehr viel Zeit lassen ... Gruß, Nils

Moin, die Gruppen müssen nicht mehr ausgewertet werden, und auch weitere Nachforschungen zu den Gruppen erübrigen sich - sofern das oben stehende Ergebnis von whoami für die anderen User übertragbar ist. Es sind dort die Gruppenmitgliedschaften vermerkt, die im Access Token auftauchen, also auch durch Verschachtelungen. Da ist tatsächlich keine lokale Administratorgruppe dabei. Hier muss also was anderes vorliegen - ich neige nun auch zu Zahnis Verdacht, dass die Systeme bereits durch eine Malware kompromittiert wurden und jetzt als offene Scheunentore dastehen. Was man jetzt noch prüfen könnte: Möglicherweise sind durch Verbiegen der lokalen Sicherheitsrichtlinien anonyme Zugriffe aktiviert worden. Damit wäre jeder Berechtigungsschutz ausgehebelt. Nach derzeitigem Stand der Dinge würde ich jetzt ins Auge fassen, alle Rechner plattzumachen und neu zu installieren. Dann natürlich mit hohem Sicherheitsstandard. Und ich würde mir mit der Entscheidung nicht viel Zeit lassen. Mag sein, dass wir falsch liegen, eine Ferndiagnose ist über ein Forum kaum möglich. Wäre ich aber in der tatsächlichen Situation, dann wären das meine Überlegungen. Viel Erfolg, Nils

Moin, wie ich gerade lese, wird am cim-Samstag eine Anti-Atom-Großdemo durch Lingen laufen. Praktischerweise am Bahnhof vorbei, also quasi als cim-Zaungäste. :D Gruß, Nils

Moin, hm ... dann gehen wir noch mal sicher. Falls du dich mit einem normalen Useraccount (nicht dein eigener Admin-User) anmelden kannst, gib bitte mal in einem CMD-Fenster ein: whoami /groups | clip Welche administrativen Gruppen tauchen in der Ausgabe auf, die sich wieder in der Zwischenablage befindet? Gruß, Nils

Moin, OK, und wer ist in der Gruppe edv2 Mitglied? Wäre nicht das erste Mal, dass man sowas feststellt. Abgesehen davon: Wie stellst du fest, dass alle User auf alle administrativen Freigaben zugreifen können? Was genau tust du, um das zu prüfen? Vielleicht handelt es sich ja auch um ein Missverständnis. Und: Von welchem Betriebssystem reden wir? Gruß, Nils

Moin, was steht denn auf so einem PC in der Mitgliedsliste der Administratoren? net localgroup Administratoren | clip kopiert die Angabe in die Zwischenablage, sodass du sie hier einfügen kannst. Gruß, Nils

Moin, das "Konzept" ist eine Fehlkonzeption, die auch schon vor 20 Jahren falsch war, aus vielen Köpfen aber irgendwie nicht rauszukriegen ist. User haben auf Rechnern keine Adminrechte zu haben, Punkt. Das, was du da vor dir hast, ist mit Sicherheit keine "Servereinstellung", weil lokale Adminrechte nur lokal vergeben werden können. Denkbar wäre: Die "Domänen-Benutzer" sind auf den PCs der lokalen Administratoren-Gruppe hinzugefügt. Irgendeine andere Gruppe ist auf den PCs der lokalen Administratoren-Gruppe hinzugefügt, und diese Gruppe enthält die Benutzerkonten. Die Einzel-Accounts sind auf den PCs der lokalen Administratoren-Gruppe hinzugefügt. Die User sind doch Mitglieder in den "Domänen-Admins". Die ersten drei Punkte könnten manuell bzw. einzeln gesetzt sein oder auch über die von Norbert erwähnte GPO-Einstellung. Natürlich ist all das inakzeptabel. Gruß, Nils

Moin, nein, ist er nicht. Aber auf die Admin-Shares können, wie der Name ja auch sagt, nur Admins zugreifen. Wenn deine User das also flächendeckend können, haben sie administrative Rechte auf den betreffenden PCs. Warum auch immer - das sollte man also zunächst rausfinden. Gruß, Nils PS. Dass ein User auf seinem PC lokaler Admin ist, ist auch keineswegs "natürlich", sondern ein erhebliches Sicherheitsproblem. Über Virenbefall würde ich mich da keine Sekunde wundern.

Moin, wie wir dir in dem anderen Thread schon gesagt haben: Nein, diese Möglichkeit existiert nicht. Das AD speichert die Kennwörter gar nicht, schon daher kann man sie nicht exportieren. Gespeichert werden nur die Hashes, aber auch die kann man nicht ohne weitere Klimmzüge exportieren. Und selbst wenn man es kann, nützen dir die Hashes nichts, weil du sie nicht zur Anmeldung verwenden kannst, ohne das Anmeldesystem von Active Directory zu nutzen. Die einzige Möglichkeit, in mehreren getrennten Systemen dieselben Anmeldedaten für verschiedene Authentifizierungsverfahren zu nutzen, wäre ein getrennter Abgleich, der die "Rohdaten" der Konten aus dem einen System in ein anderes überträgt (das wäre simpel), dann aber die Kennwortvergabe selbst vornimmt und das Kennwort des Anwenders dann in die verschiedenen Benutzerdatenbanken schreibt. Aber bevor du jetzt sowas baust: Das ist eine Infrastruktur, die mit höchstem Sicherheitsniveau gebaut werden muss, weil sie ja nun mal sämtliche Kennwörter steuert. Sowas wie eine Ablage in einer Datenbank ist dann ein No-go, solange man keine wirklich guten Algorithmen für Verschlüsselung und Schutz der Daten implementiert. Und nochmal: Du befindest dich auf einem Holzweg. Die Lösung besteht nicht darin, in deiner Anwendung die AD-Konten zu duplizieren. Sie besteht auch nicht darin, einen direkten Durchgriff von der Internetapplikation auf das interne AD zuzulassen. Wenn überhaupt, käme, wie schon gesagt, so etwas wie SAML oder OAuth in Frage, aber auch das nur mit der passenden Infrastruktur und Programmcode, der nach aktuellem Stand "sicher" entwickelt ist. Um meine bisherigen Hinweise noch mal zu verschärfen: Wir reden hier nicht nur von personenbezogenen Daten, die per se hochgradig schützenswert sind (und für die ein inadäquater Umgang mit empfindlichen Strafen bewehrt ist), sondern sogar von Daten von Schutzbefohlenen. Bitte keine Experimente und kein Gebastel an dieser Stelle, auch wenn es noch so gut gemeint ist. Gruß, Nils

Moin, als Vater schulpflichtiger Kinder sage ich es mal so: Ich erwarte, dass die Schule alles tut, um die persönlichen Daten meiner Kinder (und aller anderen) zu schützen, insbesondere weil ich hier faktisch gezwungen bin, der Speicherung solcher Daten zuzustimmen - der gesamte Schulbetrieb geht anscheinend nicht mehr ohne. Zu diesem Schutz gehört, dass nur Software eingesetzt wird, die nach aktuellem Stand der Entwicklung erarbeitet und professionell gewartet wird. Dass die interne Betreuung eines solchen Systems meist nicht von professionellen Kräften übernommen, sondern von Lehrern "nebenbei" gemacht wird, ist für mich schon sehr schwer zu akzeptieren. Gänzlich inakzeptabel wäre es aber, wenn Amateure Software entwickeln oder manipulieren, die auf solche sensiblen Daten zugreift oder - noch schlimmer - sie von außen zugänglich macht. Das wird auch dadurch nicht besser, dass es - wie ich in deinem Fall unterstelle - in bester Absicht geschieht. Die Alternative wäre also, den Hersteller der Schulsoftware nach einer Funktionserweiterung zu fragen. Damit besteht immer noch keine Gewähr, dass das in ausreichender Qualität geschieht, aber eine Firma hat wenigstens ein wirtschaftliches Interesse daran, keine Datenschutzprobleme zu verursachen. Gruß, Nils

Moin, eine Anwendung, die über das Internet zugänglich gemacht wird, steht augenblicklich unter Beschuss. Es ist sehr wahrscheinlich, dass Hacker (solche von der "automatisierten" Sorte) sie angreifen und damit erfolgreich sind, wenn man nicht umfassende Maßnahmen dagegen ergreift. Zu solchen Maßnahmen gehört eine strikte Netzwerktrennung. Eine vom Internet erreichbare Anwendung darf nicht direkt auf ein internes AD zugreifen, in dem "normale" produktive Anmeldedaten gespeichert sind. Wer den Webserver mit der Anwendung gekapert hat, hat sonst direkten Durchgriff auf das AD - insbesondere wenn der PHP-Code die Anmeldedaten auch noch auf dem Silbertablett serviert. Für Anwendungen, die aus dem Internet erreichbar sein, aber trotzdem eine AD-Anmeldung unterstützen sollen, gibt es andere Techniken wie SAML oder OAuth. Aber auch solche Anwendungen müssen mit modernen Sicherheitstechniken entwickelt und durch eine leistungsfähige Infrastruktur geschützt werden, alles andere wäre grob fahrlässig. Selbst wenn es sich nur um eine interne Anwendung handelt, ist der genannte Beispielcode für die LDAP-Anmeldung eben nur ein Beispiel und entspricht nicht heutigen Sicherheitsanforderungen. Auf keinen Fall verwendet man für sowas administrative Zugänge. Gruß, Nils

Moin, a.) warum habe ich gewusst, dass das kommt? b.) typisch PowerShell - tut so, als wäre es einfacher, dabei ist es umständlich c.) :D Gruß, Nils ... und d.) Autokorrekturen sind doof.

Moin, falls du damit meinst, dass du deine PHP-Anwendung und dein AD über das Internet erreichbar machen willst: Holzweg. Das macht man so nicht. Gruß, Nils

Moin, ich nutze die Hilfe über die PowerShell ISE, da kann ich selbst scrollen. :D Gruß, Nils

Moin, korrekt, wäre aber zu spät, denn er hat ja bereits einen. :D Gruß, Nils

Moin, ja, korrekt, guter Hinweis. Aber: Da sind wir auf einer anderen Ebene, nämlich den Eigenschaften eines Objekts, nicht mehr bei Cmdlets ... ja, die PowerShell wird schnell komplex, wenn man einzusteigen versucht. Gruß, Nils PS. Nur Mut. Abkupfern und Recherchieren hilft, sich zurechtzufinden.

Moin, das hängt vom jeweiligen Cmdlet ab. Wenn es z.B. so implementiert ist, dass es nicht mehr zurückgibt, dann eben nicht. Wenn es stattdessen den Schalter "-verbose" oder "-amfreitagnurfisch" nutzt, dann eben so ... Das ist der Fluch der Erweiterbarkeit. PowerShell ist nur oberflächlich einheitlich. Gruß, Nils

Moin, nebenbei empfehle ich, das AD nicht unnötig lang mit unterschiedlichen Windows-Versionen auf den DCs zu betreiben. Es ist empfehlenswert, zügig auf die aktuellste Version zu vereinheitlichen, die man einsetzt. Technisch geht ein Mischbetrieb auch, aber man verzichtet auf Neuerungen unter oder über der Haube, ohne einen Nutzen davon zu haben. Gruß, Nils

Moin, wie die Kollegen schon richtig sagen - die Idee geht in die falsche Richtung. Man exportiert in so einem Fall keine Daten aus dem AD, sondern man nutzt das AD als Anmeldesystem für die Applikation (dafür ist es ja auch da). Das kann ein direkter LDAP-Zugriff sein, die Nutzung einer Kerberos-Anmeldung oder auch Federation-Techniken wie SAML oder OAuth. Mit diesen Stichwörtern sollte sich recherchieren lassen, ob die Applikationen sowas können. Rein technisch würde so ein Export auch nicht funktionieren. Gruß, Nils

Moin, also, zunächst mal habt ihr keine Class-B- und Class-C-Netze. Das sind Begriffe und Techniken, die seit 20 Jahren oder so nicht mehr verwendet werden. Gewöhnt euch diese Bezeichnungen also ab. Ihr habt IP-Netze mit unterschiedlichen Subnetzgrößen. Dann: Der DHCP-Server verteilt nur Adressen aus dem Segment, dem er selbst angehört. Ihm weitere NICs mit separaten Bindungen zu geben, ist ein Holzweg. In den anderen Netzen braucht ihr DHCP Relay Agents (in Cisco-Sprech: IP Helper), um zwischen Subnetz und DHCP zu vermitteln. Gruß, Nils