cj_berlin

Das habe ich mich schon immer gefragt - wer denn bitte hat gleichzeitig das Know-How, einen C-Code gegenzulesen die Zeit, ein Projekt, das quasi jedes andere Projekt nutzt, nach jedem Release zu analysieren, und die Nerven, einen von anderen verfassten Code zu lesen? Merken wir hier ja auch: *entdeckt* wurde die Lücke mit "normalen" Mitteln - jemandem ist ein anormales Verhalten aufgefallen, er hat den kompilierten Prozess profiliert und seine Findings dokumentiert. Der Umstand, dass es sich hier um Open Source handelt, führte lediglich im letzten Schritt dazu, dass Andres Freund selbst die endgültige Diagnose stellen konnte.

Select-Object -ExpandProperty primaryGroupToken oder (Get-ADGroup $targetGroup -Properties PrimaryGroupToken ).PrimaryGroupToken

Es ist nicht "eine höhere Version", sondern ein anderes Produkt. Windows PowerShell und PowerShell sind zwar verwandt, aber das eine folgt nicht auf das andere oder löst es gar ab

Moin, das entscheidende Stichwort in Deiner Schilderung ist "warum auch immer", und da gabelt sich der Weg. Als ich vor 25 Jahren die ersten AD-Trainings gemacht habe, war das Disaster, das wir betrachtet haben, eine Naturkatastrophe, d.h. die Daten sind an sich gut und vertrauenswürdig, es geht also nur darum, sie technisch konsistent wieder auf die Straße zu bekommen. In diesem Szenario ist Deine Lösung komplett valide, sie kann aber auch durch einen Backup ersetzt werden, da muss man nichts neu erfinden. Heute geht ein AD in der Regel durch einen Cyber-Vorfall hops, und da sind die Daten inklusive Betriebssystem eben NICHT gut und vertrauenswürdig. Mit Komplett-Backups bist Du also schnell bei der Diskussion "welches Backup ist noch nicht infiziert", und diese Frage kann im Breach Response nie schnell genug beantwortet werden. In diesem Szenario sind alle Recovery-Verfahren, die auf Komplettbackups oder -kopien basieren, problematisch. Es gibt Anbieter für Tools, die auch "Cyber-geschädigte" ADs recovern können. Da einer davon mein Arbeitgeber ist, werde ich hier keine Namen nennen.

Moin, die Alternative unter Windows PowerShell ist, ping zu benutzen. Oder halt, wenn es in Deinem Fall möglich ist, PowerShell 7. ODER Du bedienst Dich des .NET Frameworks und machst: $ping = New-Object System.Net.NetworkInformation.Ping $ping.Send('192.168.5.105',10000) # zweiter Parameter ist Timeout in MILLIsekunden, also in diesem Fall 10s

Moin, Du siehst es teilweise richtig. Die VM hat durchaus ein Chipset, eine Grafikkarte und manchmal auch eine Soundkarte. Aber die Treiber und Tools, die von der Physik kommen, müssen natürlich runter. Initialisierungsversuch bei jedem Boot plus halt Dienste, die keine Treiber sind und sich nicht automatisch beenden, wenn das Gerät nicht gefunden wird.

Da Du keinen vCenter hast, wirst Du es über VMM nicht machen können. MVMC wäre eine Alternative, ansonsten Disk2VHD oder Bare Metal-Backup / Restore. Es gibt auch kommerzielle Tools dafür wie z.B. von Paragon.

Moin, das "g" in gMSA steht für "group". Da ist es eine 1:N-Beziehung, und Du kannst es für Service und Backup nutzen, dafür ist es da.

Das *ist* der Ansatz mit <div>s

...und bedenke dabei, dass Du die Häufigkeit des Kennwortwechsels für das gMSA nur einmal festlegen kannst, nämlich bei dessen Erzeugung Alles, was @toao und die Vorredner geschrieben haben, ist richtig und wichtig. Ein technisch deutlich komplexeres Problem als das Aufspüren von hochprivilegierten Service-Accounts ist die Frage, welche von ihnen wie stark überprivilegiert sind, d.h. auf welches Berechtigungsniveau Du das zukünftige Service-Account, ob nun Legacy oder gMSA, heben musst, damit die jeweilige Anwendung funktioniert. Insbesondere dann, wenn ihr die Default-Konstruktion nicht geändert habt, die Domain Admins zu lokalen Admins auf Member-Maschinen macht.

Wie waren denn meine angehängt? Einfach in den Post einfügen. Aber Word-Dateien aus dem Internet aufmachen ist wie in einer Bar aus einem zufälligen Glas trinken - nur einer weiß wirklich, was da drin ist, und das bist nicht Du

OK, aber Du hast ja sicher auch schon bemerkt, dass Deine Maus noch gar nicht als Maus erkannt wird, sondern in der Vorstufe "Human Interface Device" stehen bleibt. Dann ist vermutlich Deine Datei "C:\Windows\INF\input.inf" versaut. Vielleicht hast Du die Möglichkeit, jemanden zu finden, der physisch greifbar ist und sich "mit sowas auskennt". Dein Problem ist lösbar, aber nicht in einem Forum. Der Hinweis von @Nobbyaushb ist übrigens mehr als berechtigt - das Forum hat exzellente Einbindung von Bildern, inklusive Copy/Paste direkt in den Beitrag, poste bitte in Zukunft keine Office-Dateien oder ausführbare Dateien verkürzte Links, wo unklar ist, welche echte URL sich dahinter verbirgt Monster-Dateien wie Logs mit 10.000 Einträgen

Moin, bei Tabellen in e-Mails bin ich immer zwiegespalten, spätestens auf kleinen Bildschirmen werden sie gern gequetscht. Ich würde das "modern", das heißt, mit <div>s machen - dann werden die sich beim Quetschen automatisch umsortieren und untereinander angezeigt werden. Aber auch einige der "Großen" wie PayPal verwenden Tabellen, sogar mehrfach verschachtelte, so dass, wie so oft, YMMV...

Moin, die Linux-Gemeinde empfiehlt für diese Karte die folgende Einstellung: Die wirkt sich natürlich auf alle PCIe-Geräte aus

Moin, Code 39 ist "Dateien fehlen oder sind beschädigt". Die meisten Mäuse heutzutage arbeiten mit dem Microsoft-Treiber, Du kannst es aber verifizieren, wenn Du im Geräte-Manager auf die "Problemmaus" doppelklickst und dann auf den Reiter "Treiber" gehst: Dann klickst Du auf "Treiberdetails" und siehst eine Liste von Dateien: Prüfe mal, ob jede von ihnen am angegebenen Ort vorhanden ist. Ist das der Fall, prüfe, ob die Signatur intakt ist: Sofern die erforderlichen Dateien von Microsoft sind (das sind mouclass.sys und mouhid.sys), kannst Du schauen, ob Du mit sfc /scannow eine intakte Version wiederherstellen kannst. Nächste Stufe wäre dann DISM.exe /Online /Cleanup-Image /Restorehealth

Hallo zusammen, folgende Herausforderung: ich möchte auf einem Windows Server prüfen, ob die Installation eines bestimmten Satzes an Rollen und Features scheitern wird, aber ohne die Installation zu versuchen. wenn ein Feature bereits installiert ist, ist der Fall klar wenn ein Feature ordnungsgemäß mit -Remove entfernt wurde, ist der Fall auch klar leider gibt es immer wieder den Fall, dass die Admins einfach CAB-Dateien aus WinSxS löschen, um "zufällige" Installaiton gewisser Features zu unterbinden. Das Feature wird von WMI dann immer noch als "Available" reportet, die Installation scheitert aber verständlicherweise. Wie kann ich diesen letzten Fall untersuchen? Gibt es eine WMI-Klasse, eine Liste oder eine Datenbank in Windows, welche die benötigten SxS-Dateien für jedes Feature auflistet? Danke vorab an alle und einen schönen Sonntag! EDIT: Ach ja, und so etwas wie DISM /CheckHealth und dann den CBS-Log parsen würde ich gerne vermeiden wollen

Moin, wie die Software ihre Client -Komponente an IP bindet, ist ihr überlassen. Der Clusterdienst sorgt dafür, dass die Rollen-IP am gleichen Host präsent ist wie anderen Teile der Rolle, nicht mehr. Du könntest versuchen, bei den Hostadressen mit dem skipassource Flag zu versehen, aber das wird vermutlich irgendwas anderes stören.

Klar, Microsoft ist schuld. Ich weiß nicht, woher Du Deine Erkenntnisse beziehst, bei mir kann ich auch noch unter Server 2008R2 die Spalte "User Logon Name" einblenden, die den UPN enthält. Das AD macht hier keine Vorgaben, Du kannst per LDAP oder PowerShell den CN auf jeden beliebigen Wert setzen, der die Eindeutigkeit des DN gewährleistet. Dass die MMC-Tools nicht das Gelbe vom Ei sind, war auch schon 1999 klar.

Dein Problem ist. vermute ich jetzt mal, dass die bordeigenen Tools aus Vor- und Nachnamen einen "Full Name" zusammenfügen, diesen dann aber stillschweigend in *zwei* Attribute schreiben: name (CN) und displayName. DisplayName wäre ja völlig OK, das kann mehrfach vergeben sein, auch innerhalb einer OU, aber der CN halt nicht. Lösungsansätze: wenn die Fehlermeldung kommt, ergänze den Full Name um irgendwelche Zeichen, lege damit den Benutzer an und benenne anschließend den Display Name richtig um. lege alle neuen User in einer separaten OU an und verschiebe sie anschließend. Wird das Verschieben verweigert, bennene den CN durch Ergänzung um irgendwelche Zeichen. lege für Namensvetter eine Unter-OU Deiner User-OU an Benutze NICHT die GUI-Tools, sondern PowerShell für die Benutzeranlage, dann kannst Du gleich zuerst abfragen, ob es den User schon gibt und dann entsprechend CN und DisplayName explizit mit unterschiedlichen Werten füllen, und auch den sAMAccountName und den UPN nach einer Vorschrift gestalten. In einer prominenten öffentlichen Behörde hat man vor ca. 11 Jahren einen neuen Pressesprecher eingestellt, der aber so einen Allerweltsnamen hatte. Und man hat seine *angenommene* e-Mail-Adresse bereits im Anzeigeblatt veröffentlicht, *bevor* er durch den Onboarding-Workflow gelaufen ist und festgestellt wurde, dass es einen Beamten mit diesem Namen und dieser Mail-Adresse dort bereits seit Jahren gibt. Den Rest der Geschichte gibt es allerdings nur mündlich

Da stören sich einige "Enterprise-grade" Monitoring-Produkte auch nicht dran, sondern probieren alle hinterlegten Credentials nacheinander durch, man muss halt zusehen, dass man alle erwischt . SCCM bei Agent Push-Deployment auch.

Das ist allerdings nur praktikabel, wenn ausschließlich AD member zu berücksichtigen sind. Dann ist es auch der beste Weg, das mit Bordmitteln zu lösen. Der TO hat es allerdings bereits im OP präzisiert.

Moin, ja, es ist möglich. Du musst nur eruieren, wie Du zu den Geräten verbinden kannst: PowerShell Remoting zwischen Domain-Members - ist die Firewall offen? Ist WinRM überhaupt konfiguriert? PowerShell Remoting zu Workgroup-Windows-Maschinen - ist die Firewall offen? Ist WinRM überhaupt konfiguriert? Ist die lokale Maschine konfiguriert, den Remote-Maschinen für WinRM zu vertrauen? Remote WMI - ist die Firewall offen? Nicht-Windows-Maschinen - ist SSH offen? Gibt es eine andere API, über die man diese Info beschaffen kann?

Moin, nein, es geht mit Sicherheit nicht um die Felder "Vorname" und "Nachname", auch nicht um den Anzeigenamen. Falls es um Domänen-Accounts geht, dürfen zwei Objekte in der gleichen OU nicht den gleichen Common Name haben (meist identisch mit DisplayName, aber es sind zwei unterschiedliche Attribute). Ansonsten, UPN und SamAccountname, ersterer ist per Forest eindeutig, zweiterer per Domain.

Moin, was sagt denn Dein Ausbilder dazu? Ich habe Abschlussprojekte immer mit meinen Azubis zusammen konzipiert...

Moin, der Grund, warum zum Hardware-Tausch geraten wird, ist UEFI-Persistence. Es gibt einige Proof of Content-Darstellungen und einige wenige tatsächlich durchgeführte Angriffe. Verbreitet ist es nicht, aber ausgeschlossen eben auch nicht. Mit dem Dienstleister seiner Wahl sollte man bereits in Friedenszeiten a. einen Vertrag schließen, der seine Verfügbarkeit bei einem Angriff gewährleistet, und b. im Detail besprechen, wie Daten für die Forensik konserviert werden sollen. Ich kann zwei Firmen nennen, die sehr gut sind, gerne per PM.