blub

Welches OS haben die Clients der Kollegen?

Ich habe zugegebenermaßen keine Ahung von dieser Materie. Was mir allerdings auf der Website auffällt, dass keine konkrete Angaben über SMB-Version bzw. die verwendete Verschlüsselung gemacht wird. Vielleicht habe ich die Angaben aber auch nur überlesen. SMB 1.0 ist jedenfalls alt und unsicher, SMB 2(3) kann dagegen sicher konfiguriert werden. Welche Verschlüsselung: AES 256 oder RC4 ? Wie werden die Schlüssel ausgetauscht? HMAC-SHA2? HMAC-MD5 Bei Firmendaten wäre ich pingelig, diese Daten genau zu bekommen.

Nur als Kommentar: Nur als Kommentar: Wir haben relativ viele DCs über die Welt verteilt stehen. In einigen Ländern wurden viele DCs nach Feierabend oder übers Wochenende teilweise auch hart heruntergefahren, um Energie zu sparen. Damit bringt man diesen Mechanismus durchaus ins Straucheln (Lingering Objects, KCC- oder Topologie-Probleme etc.). Muss man auch erstmal draufkommen Ebenso, wenn die Anbindung zum DC generell schlecht bzw. wacklig ist.

1987 Bundeswehr (Luftwaffe): hatten wir noch Lochstreifen zur Daten- und "Geheim-"codeübertragung. Die waren damals schon 20 bis 25 Jahre dem Stand der Technik hinterher.

Oben schreibst du, dass du durch einen Scan Malware gefunden hast. Später wieder nicht, trotz Programmen verschiedener Hersteller incl. RescueDisk. Entweder nimmst du uns immer noch auf den Arm, oder euer Kunde hat ein Traumlos mit euch erwischt.

1. Sowohl User, wie auch Computer benötigen für eine funktionierende Domänenmitgliedschaft jeweils ein TGT Kerberosticket. Fehlt eines der Tickets, brauchst du mit GPOs etc. gar nicht anfangen. 2. Was heißt, "hab den Server in einer anderen Einrichtung laufen?" Ein Computer kann nur in einer einzigen Domäne hängen! Wenn du mit Domänen arbeiten willst, dann benötigst du elementare Grundlagen ("mit DC meinst du Domaincontroller?"), sonst macht das weder dir noch uns Spaß.

Ich bin im Moment nur mit einem Smartphone bewaffnet. :-) und bald längere Zeit offline. Check mal, ob das Computerkonto auf allen DCs repliziert ist. Dann setz das Computer Passwort zurück. Blub

Ah, Ok! Danke für die Erläuterung.

Hallo Nils, Früher hieß es in den MS-Empfehlungen mal, dass Userobjekte nicht direkt in lokale Ressourcegruppen gesteckt werden sollen, sondern erst logisch in globalen Gruppen zusammengefasst werden sollten. Du hast im AD-Design sicher weit weit mehr Expertise als ich! Daher aus Interesse die Rückfrage: Sind die MS Designprincipals bzgl. Gruppen heute nicht mehr so streng gezogen, wie etwa zu 2003er-Zeiten? Danke Blub

Das habe ich schon auch so gesehen (nachdem der erste Schreck vorüber war) :-)

Hängt der Client sauber in der Domäne? Mach mal "klist tgt" mit und ohne Adminrechten. Die Ausgabe brauch ich nicht, nur ob korrekt das TGT Ticket angezeigt wird. Vergleichs mal mit funktionierenden Rechnern. Sonst nimm den Rechner nochmal neu in die Domäne auf. DNS ist auch immer sehr beliebt, wenn DCs nicht erreichbar sind. Blub

Boah, das ist aber deine eigene, ganz private Definition!

- komplett gebootet ist der Win7 worden? - gibt es nur 2 Clients in der Domäne? Der 1058-er hat nichts direkt mit der Default Policy zu tun. Diese GPO wird nur als erste verarbeitet und wenn die GPO-Verarbeitung, warum auch immer, hängt, zeigt er diese GPO bzw. deren GUID eben an.

Wäre es nicht flexibler und auch MS-konformer, wenn du z.B. eine "standardgroup_01" mit den Usern erstellst und diese in die 10 Anwendungsgruppen einfügst? Dann hast du eine logische (ggf.globale) Gruppe, die du zu resource (ggf. local) Gruppen hinzufügst. Funktionieren werden beide Wege. Aber spiel mal zukünftige Szenarien gedanklich durch: Was kann sich ändern und wie flexibel ist dein Prozess bei Änderungen? blub

Dann hat dein "Problem" aber nichts mit der UAC zu tun. Neben NTFS-ACL Rechten und UAC (= eigentlich das sog. MIC Level) hat Windows 2012 noch einige weitere Security- bzw. Berechtigungssysteme eingebaut, z.B. - privileges - userrights - dynamic access control (DAC) - share rights Ich vermute, dass deine Anwendung ein Privilege (z.B. "act as the operating system", "chnage the system time", "backup files" etc.) verlangt, das der kopierte Obermuckl nicht besitzt. Privileges und Userrights werden über die Securityeinstellungen in den Policies gesetzt (Locale GPO oder Domain GPO -> Windows Settings -> Security Settings -> User Rights Assignement). Schau da rein und du wirst einige Einstellungen finden, die nur der ursprüngliche Administrator bzw. die lokalen Administratoren der Maschine haben, aber nicht dein Obermuckl. Den Obermuckl kannst du ergänzen, bzw. den lokalen Administratoren hinzufügen. Welches Privilege genau fehlt, musst du wohl ausprobieren. Priviliges werden nicht automatisch angepasst, wenn du den AdminAccount kopierst. Soweit die technische Antwort (hoffentlich). Securitytechnisch sollte man mit keinem Account arbeiten, der unnötigerweise erhöhte, kritische Privileges besitzt. bzw. für Anwendungen, die nicht genau erklären können, warum sie mit erhöhten Privileges gestartet werden müssen, sollte man eine Alternative suchen. Aber wen interessiert schon Security, sobald's was kostet? Sei es nur Hirnschmalz. blub

Wenn du den Prompt bestätigst, kannst du dann die Anwendung öffnen?

@Little John, ich bin nicht sicher, ob dein Eingangspost wirklich ernst gemeint war! Falls doch, dann bedenke, dass Malware sich gerne (unabhängig von Land und Datum) weiterverbreitet, auch im Netzwerk deines Arbeitgebers. Den Malware Scan hast du daher hoffentlich mit der notwendigen Vorsicht und Expertise durchgeführt. blub

Süddeutschland kann ich mir als Infektionsort nicht vorstellen. Da (Bayern, BW) kommt so gut wie keine Malware über die Landesgrenzen rein. War der Rechner ggf in Österreich? Wien, Salzburg? Dort ist auf jeder IT-Landkarte für jeden PC dunkelrotes Gefahrengebiet! Schutz ist fast unmöglich!

Die genaue Region wäre wichtig

Aktuell, zumindest monatlich, gepachte Umgebungen sind genauso essentiell, wie beispielsweise sichere Passwörter. Wenn 2 Monate+x normal sein sollten, dann ist das ein Prozessproblem in dieser IT, kein technisches oder Kapazitätsproblem mehr. Irgendwann kann man sich Security auch komplett sparen, wovon ich niemanden abhalten kann oder will. Aber auf Gefahren aufmerksam machen, das will ich schon, Blub

Hallo Markus,Der Patch erschien vor über 2 Monaten und offenbar wurden jetzt erst deine Systeme gepatcht. Wenn ihr nur wertlose, uninteressante Daten in der Domäne hostet, dann ist diese Verzögerung nicht OK, aber noch tolerierbar. Falls es aber bedeutende Werte gibt, sind mindestens 2 Monate Patch-Verzögerung gegenüber diesen Werten verantwortungslos. Blub

Mach doch einfach einen Registryvergleich zwischen vor und nach der Änderung. Blub

Die "reine Lehre" bzw. Die"perfekte Welt" zumindest zu kennen, schadet aber auch nicht

Ich werfe noch ein, dass man securityrelevante Systeme wie DCs oder CA-Server der reinen Lehre nach eigentlich immer physikalisch laufen lassen sollte. - Jeder VM Admin kann sich Zugriff zum virtuellen DC verschaffen - Wird der VM-Host gehackt, fallen auch die VMs - Attacker suchen daher gerne gezielt nach VM-Hosts im Netzwerk, da hier bei Erfolg die größte Beute liegt. - Es ist Malware bekannt, die die Grenzen zwischen VMs überspringen kann. Blub

Und möglichst keine Maschine, bzw. einen DC zweimal nicht, im Produktivnetz installieren, konfigurieren und erst irgendwann später patchen. Produktiv darf es keine, auch nicht kurzfristig, ungepatchten Maschinen geben. Nur als Hinweis. Blub