StephanR

Danke für die Links. Sehe aus folgenden Gründen kein Sicherheitsproblem: Passwörter werden nicht im Klartext durch den Passwort Locker Service abgespeichert Quelle Wenn Malware auf dem Client ist kann diese ggfs. die Credentials auslesen. Ok, dann hat der Angreifer "lesenden" Zugriff auf den von mir erwähnten Share. Ansonsten hat das Konto keine weiteren Rechte. Da geht von der eigentlichen Infektion ein viel höheres Risiko aus, auch wenn der per Autologin angemeldete User nur "Standard"-Berechtigungen hat. Noch jemand Ideen zu meinem ursprünglichen Anliegen?

Weil bisher - ich bin noch kein Jahr im Unternehmen - keiner eine AD-Infrastruktur aufgebaut hat. Die Clients und deren Verwaltung ist grundsätzlich äußerst statisch. Wie ja inzwischen klar sein sollte geht es nicht um Office-Clients, sondern produktionsnahe Systeme, deren Dynamik (User/Applikationen/Netzwerkzugriffe) deutlich geringer ist als bei Office-Clients. Im Prinzip werden die Clients bis auf die Installation von Windows Updates über Ihren Lebenszyklus nicht verändert. Trotzdem mag es durchaus sein, dass eine AD an wenigen Punkten eine bessere Verwaltung zuließe, nur sind die Gegebenheiten nun mal andere. Welche konkreten Sicherheitsbedenken bestehen denn zur Nutzung der Anmeldeinformationsverwaltung? Bitte auch Quellen nennen.

Clients und Server (mit Freigabe) befinden sich im gleichen Netz und sind per FW von der Office-Zone (Konzerndomäne mit den AD-Servern) getrennt. Bitte jetzt keine Diskussion über die Öffnung der notwendigen Kommunikation lostreten... Für mich eine typische Netzwerkzonierung/Trennung. Wenn ihr das anders interpretiert gerne, hilft mir dann aber nicht Was ist denn genau Bastelei? Die Nutzung von lokalen Richtlinien und der Anmeldeinformationsverwaltung? Sind jetzt beides für mich Bestandteile eines marktführenden Produktes....

Die gewünschte und erforderliche Netztrennung erlaubt dies nicht. Darf ich fragen welche Relevanz deine Fragen auf das vorhandene, technische Problem haben?

Die PCs sind keine Domänenmitgleider. Daher die Nutzung der lokalen Policy. Irgendwie muss der lokale Nutzer vom Client ja Zugriffsrechte auf die externe Ressource bekommen. Das geht halt über die Anmeldeinformationsverwaltung und das Hinterlegen eines privilegierten Kontos.

Moin, per lokaler Gruppenrichtlinie habe ich die Ausführung eines Powershell Logonscripts (Benutzerkonfiguration) konfiguriert. In diesem Logonscript ist folgende Funktion enthalten, die ein Netzlaufwerk mappen soll. ##### Netzlaufwerk verbinden ##### function lw_mapping($freigabe){ Start-Process -FilePath cmd -Wait -ArgumentList "/c net use Z: $freigabe" } lw_mapping "\\servera.ad.local.net\p1" Auf dem Client existiert ein lokales Benutzerkonto, welches per Autologin nach Reboot direkt angemeldet wird. In der Anmeldeinformationsverwaltung wurden für die Serveradresse "servera.ad.local.net" Zugangsdaten hinterlegt, die Zugriff auf die genannte Freigabe haben. Das Problem stellt sich jetzt so dar, dass nach einem Reboot das Logonscript ausgeführt wird, aber das Laufwerk nicht gemappt wird. Stattdessen erscheint ein CMD-Fenster mit der Bitte einen Benutzernamen für den Zugriff auf die Freigabe einzugeben. Dieses Verhalten kenne ich grundsätzlich, wenn die hinterlegten Zugangsdaten in der Anmeldeinformationsverwaltung nicht korrekt sind. Daher habe ich diese als erstes Überprüft und konnte auch einen Fehler feststellen. Leider ist das Verhalten nach der Korrektur der Zugangsdaten weiterhin vorhanden. Um wirklich sicherzustellen, dass die Zugangsdaten korrekt sind, bin ich manuell auf die Freigabe gegangen und habe auf dem Server überprüft, dass die Anmeldung auch wirklich mit dem hinterlegten Konto erfolgt ist. Zunächst habe ich ein eventuelles Timingproblem mit der Netzwerkkonnektivität vermutet. Daher habe ich in den lokalen Richtlinien eine Skript-Verzögerung von 120Sek konfiguriert. Leider ohne Erfolg. Dann habe ich das Logonscript aus den lokalen Richtlinien entfernt, einen Reboot durchgeführt und das Logonscript manuell ausgeführt. Dies hatte dann Erfolg. Für einen weiteren Test und als aktuellen Workaround habe ich die Ausführung des Logonscripts per Aufgabenplanung eingerichtet (Ausführung bei Anmeldung). Dies funktioniert ebenfalls! Auf 4 anderen Clients funktioniert das Logonscript per lokalen Richtlinien auch. Nur dieser eine Client - auf dem einmal falsche Zugangsdaten hinterlegt waren - funktioniert so eben nicht. Gibt es irgendwie einen Cache den ich ggfs. löschen sollte? Oder andere Ideen, warum sich dieser eine Client komplett anders verhält? Vielen Dank und viele Grüße Stephan

Hallo, ich möchte noch kurz mitteilen, dass ich keine Lösung zum Thema Nicht-AD-Windows-Clients/sichere DNS-Zone/DHCP dynamische Updates nur nach Aufforderung finden konnte. Ich habe lediglich noch folgende Seite gefunden, die das Verhalten der Nicht-AD-Windows-Clients bestätigt. http://jorgequestforknowledge.wordpress.com/2011/01/01/dhcp-and-name-protection-in-windows-server-2008-r2/ Ansonsten funktioniert in den meisten Subnetzen bei uns die Einstellung, dass der DHCP nur nach Afforderung die dynamischen Updates durchführt und sich die AD-Clients somit selbständig im DNS aktualisieren. In Subnetzen mit außergewöhnlichen Komponenten (Print-Boxen, etc.) führte die Einstellung allerdings zu Problem, so dass diese Zonen so konfiguriert sein müssen, dass der DHCP für alle die dynamischen Updates durchführt.

Moin, Punkt 1 und Punkt 2 wurden mit folgenden Einstellungen getestet: Punkt 3 und 4 wurden dann mit den durch die Aktivierung des Namensschutzes vorgegebenen Einstellung durchgeführt. UPDATE Ändere ich die DNS Einstellungen von "DNS Einträge immer dynamisch aktualisieren" auf "nur nach Aufforderung von Clients dynamisch aktualisieren" ergibt sich folgendes Bild. 1. Der AD-Mitglied DNS Eintrag bekommt als Owner den hostname$ 2. Ein nicht-AD-Windows-Client wird nicht im DNS eingetragen. Hier habe ich inzwischen schon die Vermutung, dass die Umstellung der DNS-Zone auf "nur sichere Updates" auch die initiale Erstellung eines Records unterbindet, sollte keine AD-Authentifizierung vorhanden sein. 3. Der Linux Client wird über den DHCP im DNS registriert Diesen Beitrag möchte ich gerne noch loswerden, bevor ich meine Tests erstmal einstellen möchte. Folgende Option zu dynamischen Updates ist im DHCP gesetzt "nur nach Aufforderung von Clients dynamisch aktualisieren". Ansonsten sind die Einstellungen identisch zum Screenshot im Beitrag zuvor. Der Nicht-AD-Windows Client wird in der DNS Zone nicht eingetragen, weil er nicht autorisiert ist DNS Einträge zu setzen. Folgende Screenshots stützen aus meiner Sicht diese These: 1. Der Client stellt den DHCP Request mit einem korrekten FQDN http://picload.org/image/lwawogc/dhcp_request.jpg 2. Es kommt zu folgendem Deny der Dynamic Updates http://picload.org/image/lwawogw/dns_deny.jpg Für mich ist damit belegt, dass bei einer sicheren DNS-Zone nicht einfach so jeder Client (auch initiale) Objekte erstellen kann. Oder deute ich die Auszüge des Wiresharks falsch? Leider scheine ich mein Upload Limit überschritten zu haben. Daher die Links zum Bildhoster...

Hallo, ich habe mittlerweile folgende Ergebnisse in einer Testumgebung erzielt: unsichere und sichere Updates erlaubt / DHCP Namensschutz deaktiviert / DHCP nicht Mitglied Gruppe DNSUpdateProxy Ergebnis: Win7 nicht AD-Mitglied: Der DHCP erzeugt den A und PTR Eintrag im DNS es ist dabei unerheblich, ob im DHCP Credentials hinterlegt sind oder nicht Im DNS-Objekt sind keine speziellen Berechtigungen ersichtlich. Egal ob Credentials hinterlegt wurden oder nicht Win7 AD-Mitglied: Der DHCP erzeugt den A und PTR Eintrag werden im DNS Der DHCP trägt das AD-Konto (Credentials) als Besitzer des Objektes ein Dadurch ist gewährleistet, dass auch ein zweiter DHCP Server die Einträge löschen/updaten kann Achtung Wird der Client umbenannt, so ist das Ergebnis wie beim Client ohne AD-Mitgliedschaft. Eventuell hat irgendein Cache dazu geführt, dass der alte Name mit dem AD-Konto als Owner angelegt wurd. Linux: Der DHCP erzeugt den A und PTR Eintrag im DNS Im DNS-Objekt sind keine speziellen Berechtigungen ersichtlich. Egal ob Credentials hinterlegt wurden oder nicht nur sichere Updates / DHCP Namensschutz deaktiviert / DHCP nicht Mitglied Gruppe DNSUpdateProxy Ergebnis: Win7 nicht AD-Mitglied: Der DHCP erzeugt den A und PTR Eintrag im DNS Wenn im DHCP keine Credentials hinterlegt sind passiert folgendes: Der DHCP trägt sich mit seinem Hostname$ als Besitzer des Objektes ein Dies dürfte zur Folge haben, dass ein anderer DHCP Server diesen Eintrag nicht ändern kann bzw. nur der Ersteller die Möglichkeit hat Sind im DHCP Credentials hinterlegt: Der DHCP trägt das AD-Konto (Credentials) als Besitzer des Objektes ein Dadurch ist gewährleistet, dass auch ein zweiter DHCP Server die Einträge löschen/updaten kann Win7 AD-Mitglied: Der DHCP erzeugt den A und PTR Eintrag werden im DNS Der DHCP trägt das AD-Konto (Credentials) als Besitzer des Objektes ein Dadurch ist gewährleistet, dass auch ein zweiter DHCP Server die Einträge löschen/updaten kann Linux: Der DHCP erzeugt den A und PTR Eintrag im DNS Einträge von AD-Mitglieder werden einfach überschrieben, wenn das nicht AD-Mitglied den gleichen Namen hat Der DHCP trägt das AD-Konto (Credentials) als Besitzer des Objektes ein Dadurch ist gewährleistet, dass auch ein zweiter DHCP Server die Einträge löschen/updaten kann nur sichere Updates / DHCP Namensschutz aktiviert / DHCP nicht Mitglied Gruppe DNSUpdateProxy Ergebnis: Win7 nicht AD-Mitglied: Es wird kein A Eintrag im DNS erzeugt PTR wird erzeugt. Win7 AD-Mitglied: A und PTR Eintrag werden im DNS erzeugt Der Client trägt selber seinen A-Record ein und gibt sich auf Basis der Hostnamen$ die Owner Rolle Der DHCP hat keinen Zugriff auf den Record Der Eintrag kann nicht manipuliert werden (getestet mit einem Linux Client, der den gleichen Hostnamen bekommen hat) Ereignisprotokoll DHCP-Server: Linux: Der DHCP erzeugt den A, PTR und DHCID Eintrag im DNS Der DHCP trägt das AD-Konto (Credentials) als Besitzer der Objekte ein Dadurch ist gewährleistet, dass auch ein zweiter DHCP Server die Einträge löschen/updaten kann Der Eintrag kann nicht manipuliert werden (getestet mit AD-Mitglied, dass den gleichen Hostnamen bekommen hat) nur sichere Updates / DHCP Namensschutz aktiviert / DHCP Mitglied Gruppe DNSUpdateProxy Ergebnis: Win7 nicht AD-Mitglied: Es wird kein A Eintrag im DNS erzeugt PTR wird erzeugt. Win7 AD-Mitglied: Der DHCP erzeugt den A und PTR Eintrag im DNS Der Client trägt selber seinen A-Record ein und gibt sich auf Basis der Hostnamen$ die Owner Rolle Der DHCP hat keinen Zugriff auf den Record Linux: Der DHCP erzeugt den A, PTR und DHCID Eintrag im DNS Der DHCP trägt das AD-Konto (Credentials) als Besitzer der Objekte ein Dadurch ist gewährleistet, dass auch ein zweiter DHCP Server die Einträge löschen/updaten kann Mein Problem sind somit die nicht AD-Windows-Systeme, da diese in den sicheren Konfigurationen (Punkt 3 & 4) nicht in das DNS eingetragen werden. Aus meiner Sicht gibt es jetzt zwei Lösungswege: 1. Unter Punkt 2 wird erreicht, dass die AD-Windows Systeme nicht durch den DHCP ihren Eintrag im DNS bekommen, sondern dies eigenständig tun und somit selber Owner des Objektes werden. Dadurch hat der DHCP dann keine Möglichkeit mehr den Eintrag auf Aufforderung eines anderen Clients (Linux, Nicht-AD-Windows,...) zu ändern. 2. Nicht-AD-Windows Systeme werden irgendwie in den sicheren Konfigurationen (Punkt 3 & 4) eingetragen. Hier verstehe ich sowieso nicht, warum ein nicht AD-Windows-Client anders behandelt wird als ein Linux System. Also warum der DHCP nicht den Eintrag für nicht-AD-Windows-Clients vornimmt. Wie sich externe Geräte wie Drucker oder Handgeräte im Lager verhalten, werde ich wohl live testen. Ich danke fürs Lesen und hoffe auf ein paar Tipps :)

Ich vermute einfach mal, dass der Artikel seit 09/2013 nicht geändert wurde. Dann geht folgender Link über http://archive.org/web/ http://web.archive.org/web/20130907181009/http://msmvps.com/blogs/acefekay/archive/2009/08/20/dhcp-dynamic-dns-updates-scavenging-static-entries-amp-timestamps-and-the-dnsproxyupdate-group.aspx Das Thema ist wirklich nicht trivial und man findet diverse widersprüchliche Aussagen. Ich zitiere mal die vorgeschlagene Konfiguration der MSMVPS Seite: Hier wird jetzt behauptet, dass sowohl die Credentials eines AD-Kontos als auch die Mitgliedschaft in der Gruppe DNSUpdateProxy notwendig ist. Immerhin gibt es dazu die klare Aussage, dass dann auch Microsoft fremde oder alte Clients ins DNS eingetragen werden. Zudem wird gesagt, dass der DHCP dann bereits existierende Objekte nicht updatet bzw. löscht. Hier habe ich die Hoffnung, dass dies in unserem Fall nicht zutrifft, weil wir ja bereits Credentials nutzen und diese sich nicht ändern. In unserer Umgebung ist mir jetzt noch folgendes aufgefallen. Wie im ersten Post erwähnt, sind im DHCP Credentials eines AD-Kontos hinterlegt. Schaue ich mir aber jetzt einen DNS-Eintrag an, so finde ich dieses Konto dort nicht unter Sicherheit: Müsste nicht das AD-Konto der Besitzer sein und auch unter Gruppen- oder Benutzernamen aufgeführt werden? Vielen Dank!

Danke, ich habe mir die Newsgroup Beiträge durchgelesen und würde meine Erkenntnisse gerne einmal zur Prüfung wiedergeben. 1. Die Nutzung der dnsupdateproxy Gruppen ist obsolet und unsicher. 1.1 Obsolet, weil man inzwischen ein AD-Konto im DHCP-Server definieren kann, welches sich auch mehrere DHCP-Server "teilen" können. 1.2 Unsicher, weil der DHCP Server nicht Owner des Eintrages wird, sondern der erste Client, der auf den Eintrag zugreift. 2. Best practise ist im DHCP-Server ein AD-Konto zu definieren. Dieses AD-Konto wird dann Owner der Objekte, die der DHCP Server anlegt. 1.1 Nutzt man mehrere DHCP Server haben alle Zugriff auf die Objekte, da Sie alle das gleiche AD-Konto verwenden. 3. Die DNS-Zone ist auf nur sichere dynamische Updates zu konfigurieren, damit die unter Punkt 1 & 2 geschilderten Sicherheitsmechanismen greifen. 3.1 Nur wenn die DNS-Zone auf nur sichere dynamische Updates, wird der Owner eines Objektes berücksichtigt. 3.2 Erlaubt die Zone auch unsichere Updates, so kann jeder DNS-Einträge manipulieren. Mein Fazit aus diesen Erkenntnissen wären folgende: 1. Die Umstellung der DNS-Zone auf nur sichere dynamische Updates verhindert, dass ein unautorisierter Client bestehende Änderungen an Einträgen vornehmen kann 1.1 Es ist aber weiterhin so, dass nicht AD-Clients neue Einträge (Ersteinträge) vornehmen können? So wie NilsK im zweiten Post geschrieben hat? Wer ist dann Owner? 2. Der DHCP Server ist mit dem definierten AD-Konto Owner aller über Ihn angelegten Objekte 2.1 Besitzer der Objekte ist also letztendlich das AD-Konto, so dass diese Einträge nicht manipuliert werden können. 3. Aus meiner Sicht gibt es jetzt nur folgendes Problem. Der DHCP hat für einen AD-Client (nennen wir ihn client1.firma.local) einen Eintrag im DNS vorgenommen. Owner dieses Eintrages ist das im DHCP Server definierte AD-Konto. Jetzt kommt ein nicht AD-Client mit dem gleichen Namen client1 und konfiguriertem DNS-Suffix firma.local ins LAN. Würde der DHCP Server jetzt nicht einfach den vorhandenen Eintrag überschreiben. Schließlich ist er ja Owner. Setzt genau an diesem Punkt die Option Namensschutz an? Vielen Dank!

Danke für den Link, leider kann ich diesen nicht aufrufen. Es kommt seit gestern stetig ein Timeout. Zum Thema "Secure Updates". Wenn weiterhin der DCHP die Einträge im DNS pflegt ist dieser ja Owner (außer er ist Mitglied der Gruppen dnsupdateproxy, dann werden soweit ich gelesen habe keine Sicherheitsinformationen gesetzt). Wenn der DHCP aber Owner ist, muss zwingend die Namensschutz Option aktiviert sein, damit der DHCP nicht einfach "seine" Einträge auf Anforderung (oder wenn es keine Anforderung gibt und der DHCP trotzdem die Einträge setzen soll) des Clients ändert? Hab ich das so richtig verstanden?

Hallo, Ziel ist die Absicherung der AD-DNS-Zone. Es soll nicht mehr ohne Authentifizierung möglich sein Records zu setzen und zu ändern. IST-Zustand: Active Directory (3x DC Windows Server 2012 R2) DNS (3x DC Windows Server 2012 R2) DHCP (1x Windows Server 2008 R2) Aktuell übernimmt der DHCP Server die Aktualisierung der PRT und A Records für die Clients. Hier ist die Option wichtig, dass Einträge auch für Clients gesetzt werden, die keine Aktualisierung anfordern. Dies ist denke ich für unsere Druckersysteme und alte Windows embedded Geräte notwendig, da diese die Option 81 nicht liefern. Der DHCP Server hat zudem ein AD-Userkonto zugewiesen, welches Mitglied der Gruppe DNS-Admins ist. Die DNS-Zone erlaubt aktuell nicht sichere Updates. Zielformulierung: 1 .Neue DNS Einträge können nur noch nach Authentifizierung erfolgen 2. Änderungen von bestehenden Einträgen sind nur dann erlaubt, wenn der Anforderer auch der "Besitzer" des Eintrages ist. Verhinderung von Name-Squatting. 3. Der DHCP Server aktualisiert weiterhin für AD und nicht AD-Mitglieder die DNS-Records bzw. erstellt sie. Umsetzung: Zum 1. Ziel: Umstellung der AD-DNS-Zone auf nur sichere Updates. Frage: D. h. nur noch Windows AD-Mitglieder können neue Einträge erstellen? Wäre dies für den DHCP Server gegeben, da er das AD-Konto DNS-Admin nutzt? Zum 2. und 3. Ziel: Im DHCP wird die Option DHCP-Namensschutz aktiviert Frage: Werden weiterhin Einträge für Clients erzeugt, die keine Aktualisierung anfordern? Vielleicht nochmal ausgeschrieben, wie ich das Verhalten nach Umsetzung intepretieren würde. Änderung an der Zone sind durch die Umstellung auf "nur sichere Updates" nur noch die authentifizierte AD-Konten möglich (Beispiel DHCP AD-Konto). Dadurch wird schon mal verhindert, dass einfach Records in der Zone erstellt werden. Jetzt gibt es aus meiner Sicht noch folgendes Problem. Kommt ein Client ins LAN und hat den gleichen Hostname wie eine AD-Maschine, so würde über den DHCP der Eintrag im DNS einfach überschrieben. Das sogenannte Name-Squatting. Um dieses zu verhindern würde ich dann gerne den DHCP Namensschutz aktivieren, der das Überschreiben von AD-Records verhindert. Ganz wichtig wäre bei den Punkten nur, dass Clients die die Option 81 nicht senden weiterhin im DNS eingetragen werden. Ich freue mich auf Feedback zu meinem Vorhaben. Vielen Dank!

Moin, ich habe die Replikation soweit eingerichtet und diese wurde auch erfolgreich abgeschlossen. Mir fällt jetzt nur auf, dass die Zuordnung der Computer zu den Gruppen nicht mitrepliziert wird. Soweit aus meiner Sicht noch ok, da sich bisher kein PC beim neuen WSUS Server angemeldet hat. Meinen Client habe ich jetzt auf den neuen WSUS Server umgestellt. Es wurde auch ein Statusbericht erstellt, allerdings ist mein Client jetzt keiner Gruppe zugeordnet. Wenn ich dieses Verhalten jetzt richtig deute, müsste ich nach der Umstellung der Clients die komplette Gruppenzuordnung erneut vornehmen. Ist dies schlüssig, oder mache ich einen Fehler? Vielen Dank!

Das ist doch aber mit meiner Anforderung nicht praktikabel oder? Erreichen will ich ja, dass der angemeldete AD-User seine Attribute (company, department, etc.) editieren darf und nicht eine Gruppe von Benutzern. Sonst könnte ja User A die Attribute von User B editieren, wenn diese sich in ein und derselben Gruppe befinden sollten. Damit dies eben nicht geht würde ich in der OU eine Berechtigung erstellen, die dem Konto "Selbst" das Recht gewährt. Nach Tests gehe ich davon aus, dass "Selbst" das AD-Objekt meint. D. h. der Mitarbeiter kann dann sein eigenes Konto editieren, aber nicht die der anderen. Liege ich damit falsch? Danke!

Vielen Dank für eure Hilfe. Als Lösung werde ich dem User auf der OU die Rechte zum Schreiben der "Öffentlichen Informationen" geben.

Vielen Dank schon mal! :) In die Berechtigungen der OUs hatte ich bereits reingeschaut, aber bin dort leider an folgendem Punkt hängengeblieben. Und zwar möchte ich ganz konkret die Attribute company, officephone, department und mobile den User pflegen lassen. Die Pflege der Telefonnummern ist im Default gegeben, so dass die Attribute company und department noch für die Anforderung relevant sind. In den Sicherheitseinstellungen der OU finde ich jedoch keine entsprechende Möglichkeit dem User "Selbst" die Berechtigung zum Schreiben auf die Attribute zu geben. Es werden zwar diverse Attribute angezeigt (sehr viele msDS-*) und nur wenig (ich nenn Sie mal kosmetische) wie Name und Straße. Hab ich hier das von Nils benannte Problem, dass eine Berechtigung auf die gewünschten Attribute dort nicht möglich ist? Wäre dann die einzige Alternative Schreiben auf "Alle Eigenschaften schreiben" zuzulassen? Das würde mir ehrlich gesagt nicht so sehr gefallen, oder ist das aus Eurer Sicht ungefährlich? Bezüglich Domino sehe ich ebenfalls keine Probleme, da er vollkommen autonom zum AD läuft.

Hallo, der Benutzer soll auch Attribute pflegen können, zu der er im Standard keine Berechtigung für eine Editierung hat. Per dsacls kann ich wie auf der Seite erwähnt ja die aktuellen Berechtigungen ändern. Mir stellt sich jetzt nur die Frage, wie es bei neu angelegten Benutzern aussieht. Wo muss man Anpassungen vornehmen, damit neue Benutzer automatisch diese Editierungsrechte bekommen? Danke und Grüße

Moin Nils, vielen Dank für den Hinweis! Von einer Migration möchte ich für diese Anforderung doch Abstand nehmen ;) Gruß Stephan

Hallo, ich würde gerne unseren Usern die Möglichkeit geben, bestimmte Attribute ihres AD-Objektes zu pflegen. D. h. der angemeldete User soll die Möglichkeit haben bestimmte Attribute (Telefonnummber, Vertreter, etc.) seines AD-Users zu editieren. Kennt jemand Lösungen, die eine solche Funktionalität bereitstellen? Umgebung: Domäne: Active Directory DC: Windows Server 2008 R2 Groupware: Lotus Domino Danke und Gruß

Nicht was sondern wer. Der geizige CFO ;-) – Soo, die Verteilung auf dem Testclient hat funktioniert! :-) Wird das Ergebnis einer Installation eigentlich serverseitig protokolliert? Wäre ja nett, damit man weiss auf welchen Clients die Installation bereits durchgelaufen ist.

Sicherlich ist eine Verteilung über das AD sehr sauber was .msi Pakete angeht. Leider brauchen wir aber ein Programm zum Verteilen der Software, welches mehr Möglichkeiten bietet (andere Installer, Ausführung von Skripten,...). Um nun nicht zweigleisig fahren zu müssen, hätte ich das SP halt gerne in die Verteilung durch WPKG reingenommen. Letztendlich ist es aber auch kein Beinbruch! Werd berichten, ob ich mit einer Verteilung über das AD erfolgreich bin. Hehe das komplette SP liegt da schon ;-) Es gibt ja auch Silent-Parameter für das komplette .exe-File (WindowsServer2003.WindowsXP-KB914961-SP2-x64-ENU.exe). Leider tritt der gleiche Fehler auf, wenn ich darüber eine Installation versuche. Treiber sind aktuell.

Guten Morgen, das SYSTEM-Konto hat sowohl Vollzugriff auf die Schlüssel mit den jeweiligen GUIDs, sowie auf die beiden Dateien selber. Als AntiVirus kommt KAV 6.0 zum Einsatz. Ich hatte auch schon den Verdacht, dass die Software den Zugriff behindert und hab sie daher komplett deinstalliert. Leider ohne Erfolg... Den "Notfallplan" mit der Verteilung des SP2 über die Gruppenrichtlinien liegt schon 2 Tage bei mir auf dem Schreibtisch. Werd in diesem Fall wohl kapitulieren müssen, auch wenn ich das garnicht mag ;-) Achja sind ca. 30 Clients. Vielen Dank für die bisherigen Bemühungen.

Das Zurücksetzen der Berechtigungen durch das Skript hat leider nichts gebracht. Bei der SP2 Installation werden folgende Logdateien im Windows Verzeichnis erstellt. - spupdsvc.log (Auszug != Return code: 0) - setupapi.log keine Auffälligkeiten - svcpack.log (Errormeldung im 1. Post) Access denied Meldung im Logfile des Process Monitors: Die Meldung, welche das *.tmp File betrifft kann als beispielhaft betrachtet werden. Hab noch ca. 200 weitere solche Meldungen. Ich habe nicht eine ACCESS DENIED Meldung, welche die Registry betrifft.

Die fehlenden Berechtigungen in der Registry sind bei Microsoft wohl nicht ganz unbekannt. Fehlermeldung "Zugriff verweigert" oder "Die Service Pack-Installation wurde nicht abgeschlossen" bei der Installation von Windows XP Service Pack 3 Leider helfen die genannten Maßnahmen nicht. Ich hab mit dem ProcessMonitor den Ablauf überwacht. Allerdings war für mich in der Fülle der ganzen Einträge kein Spezieller ersichtlich, der auf das Problem mit der Registry hindeutet. Ich monitore gerade nochmal eine manuelle Installation, um einen Vergleich zwischen erfolgreich und nicht erfolgreich zu erhalten. Ich habe aber wenig Hoffnung, dass sich daraus etwas ergibt. Eine KBXXXXX.log wird nicht erstellt.