olc

Was hat "A-G-DL-P" mit fehlenden Werkzeugen zur Dokumentation und einfacher Verwaltung zu tun? Irgendwann sind die Grenzen von ADUC, Freigabe-Manager und Excel-Dateien erreicht und spätestens wenn ITIL ins Spiel kommt, muss man quasi zwangsläufig auf Dritt-Anbieter zurückgreifen.

 

Aber das war jetzt nicht Thema hier.

 

Sofern das A-G-DL-P onzept sauber umgesetzt wurde, brauchst Du nicht auf der Zielressource prüfen, welche Zugriffe existieren. Du kannst es schlicht anhand der Gruppenmitgliedschaften evaluieren.

 

Aber ja, das ist die rein technische Betrachtung. Workflows und Prozessmanagement sind eine andere Ebene dabei.

 

P.S.: ADUC ist tot. ADAC/PowerShell lebt. 

 

Viele Grüße

olc

Ok, vielleicht habe ich mich falsch ausgedrückt.

 

Es ging mir um das konkrete Problem der lokalen Anmeldung eines lokalen Admins.

Hier könnte ich mir eine Art Challenge-Response-Verfahren vorstellen.

Natürlich nur, wenn entsprechende Masterschlüssel der Lösung gut gesichert sind. Z.B. mit einer HD-Verschlüsselung.

 

Ok, angekommen. :)

 

Dass die Windows-Passwort-Hash u.a. in der SAM-DB nicht sicher sind, ist schon klar. 

(schöne Grüße von SySS ;) )

Zumindest hier könnte Microsoft mal ein wenig nachsalzen.

 

Hat Microsoft, die "Mitigation" heißt Bitlocker.

 

Die  Alternativ für PiH (bezogen auf NTLM) ist dann vermutlich Kerberos mit AES256 Verschlüsselung.

Leider in Windows als alleiniges Protokoll nur schwer bis nicht  implementierbar.  Wobei hier  vermutlich wieder die Bugtraq 42435 in die Suppe spuckt.

 

Na ja, leider auch nicht wirklich. Es gibt ein ähnliches Angriffsszenario auch für Kerberos, siehe Stichwort "Golden Ticket": http://rycon.hu/papers/goldenticket.html

 

Das ist allgemein vollkommen klar. In der IT-Sicherheit kann es schon per Definition keinen Stillstand geben. Wir sind immer nur "Verteidiger" und haben Angreifer gegen uns, die über eine theoretisch unbegrenzte Zeitmenge verfügen. Es wird daher nie eine vollkommen sichere Umgebung geben, und man darf sich nie ausruhen.

 

:)

 

Ist schon kein Problem. Aber irgendwo muss man anfangen.

 

Ja, dann aber gleich beim Fundament anstatt ein paar Fenster ins Leere zu bauen. :)

 

Bitte verzeih mir da meine Erbsenzählerei - leider sehe ich nur allzu häufig den "Vorsatz" es besser zu machen, um dann schlußendlich (wenn überhaupt) bei halbgaren Umsetzungen zu landen, bei denen sich die Firmen dann noch einreden, sie wären nun "sicher" (Zitat) oder hätten das Sicherheitsniveau spürbar angehoben.

 

Meine persönliche Erfahrung ist: ehrlich sein, egal wie schmerzhaft es ist. Solange wir uns noch gegenseitig einreden, es würde alles nicht so schlimm werden, wird sich nichts ändern. Siehe mein Zitat oben zu den beiden Kategorien von IT-Netzwerken. Nicht paranoid sein, aber auch nicht vollkommen naiv. Letzteres ist zumindest meiner Erfahrung nach die Regel. Und/oder noch renitent dazu.

 

Wie oben schon gesagt: Prinzipbedingt sind die Zäune immer zu niedrig.

 

:)

 

FIM hatten wir schon beleuchtet und erfüllte mehrere Wünsche nicht und war damit zu teuer. Für Berechtigungsmanagement wird zur Zeit "8MAN" angeschaut. Auch eine Baustelle. Was nützen die besten Passworte, wenn niemand einfach nachvollziehen kann, wer wo Berechtigungen auf diversen TB Storage mit 5000 bis 6000 Freigaben hat.

 

Soll ich jetzt mal provozieren und "A-G-DL-P" einwerfen? *duckundweg*

 

Viele Grüße

olc

...schau Dir PtH einmal genauer an. :)

 

Etwa hier:

• http://en.wikipedia.org/wiki/Pass_the_hash
• http://www.microsoft.com/en-us/download/details.aspx?id=36036

 

Viele Grüße

olc

Ja. "Aufgeweckt" wurden meine Cliente-Betreuer, als beim diesjährigen Premier-Auftakt ein Microsoft-Sicherheitsmensch erklärt, dass bei so gut wie allen gehakten ADs, die sie gefunden haben, PtH im Spiel war.

 

Ah, ok. Kenne die Veranstaltung und den Inhalt. :)

 

Es gibt dazu eine nette Aussage (sicher nicht neu, aber ich finde sie gut):

 

Es existieren genau zwei Arten von IT-Umgebungen

• In Kategorie 1 wissen die Verantwrtlichen davon, daß sie von Malware befallen oder alternativ gehackt (APT) wurden (oder beides).
• In Kategorie 2 wissen sie es nicht.
• Eine Kategorie 3 gibt es nicht. ;)

 

Vollkommen korrekt. Natürlich wäre es perfekt, wenn man ein Tool hat, das alle Aspekte erfüllt.

 

Gibt es das jemals...? :) Zumal sich Angriffsvektoren ja mit den Gegenmaßnahmen ändern...

 

Aber selbst wenn man weiß, dass man einen Aspekt mangels Werkzeug zuerst mal nur organisatorisch und mit Disziplin erfüllen kann, heißt das nicht, dass man die anderen Aspekte deswegen komplett ignorieren kann.

 

Bin ich vollkommen bei Dir. Jede Maßnahme ist für sich genommen erst einmal eine gute Maßnahme.

 

Der Sicherheitsbeauftragte hier fährt da ein ziemlich gute Linie: Anstelle eines massiven Stahltor und dann links und rechts einen kaputten Jägerzaun, lieber ein nicht ganz so gutes Tor, dafür aber insgesamt einen besseren Zaun.

 

Ich weiß natürlich nicht woher ihr kommt (historisch betrachtet in Bezug auf IT-Security) - sicher ist das ein erster guter Start, aber mittelfristig reicht das eben (leider) nicht.

Verstehe mich nicht falsch - ich sitze nicht im Elfenbein-Turm. Es muß nur immer klar sein, daß die ganzen "halben" Maßnahmen schlicht fast nichts bringen.

Solange nicht fundamentale Änderungen im Betrieb von IT-Umgebungen stattfinden, in Bezug auf die Prozesse, Administration, die Benutzer als auch eingesetzter Technik, sind die "Zäune" immer zu niedrig. Punkt. :)

 

Prima. Danke für den Link, sieht auf den ersten Blick gar nicht schlecht aus.

 

Gibt noch mehr und ähnliche Systeme, je nach Anwendungszweck.

Microsoft Consulting hat da soweit ich weiß auch eine Lösung gebaut, FIM basierend. Weiß nicht, ob da auch lokale Kennwörter geändert werden.

"CyberArk" hat auch in die Richtung etwas.

 

Eine  Idee  wäre noch ein Challenge/Response-Verfahren  über Telefon.

 

Ich meine, in Safeguard gibt  es ein solches  Verfahren. Eine  Verschlüsselung mobiler Geräte sollte eh  Standard sein.

 

Nein, ist es nicht. Denn wenn Du erst ein Benutzer-Ticket hast, bist Du durch mit dem Thema. Game Over.

 

Viele Grüße

olc

Moin, moin,

 

Moin,

 

danke für die rege Beteiligung. Ich hatte aufgrund der komplexen Fragestellung weniger befürchtet.

 

Ist ein aktuelles und interessantes Thema... :)

 

ansehen werde ich mir das ganz sicher. Es sind ja auch "kleine" Lösungen mit Scripten denkbar.

 

Des Teufels Advokat: ob diese "Lösungen" dann wirklich "sicherer" sind...? :)

 

Nicht "meist", sondern "auch". Bei einem Server-/Client-Dienst würde ich hier gar keine technischen Schwierigkeiten sehen. Wenn der Server nicht erreichbar ist, wird das Passwort nicht geändert und landet auch nicht neu in der zentralen Datenbank. Damit sind dann die PW in DB und Client synchron, nur nicht so oft geändert.

 

Ok, Du hattest eingangs explizit erwähnt, daß die Notebook-Systeme "offline" / ohne Netzwerk sind. Das hatte ich dahingehend interpretiert, daß es Dir auch um diesen konkreten Punkt geht. Mein Fehler, es war eine Annahme.

 

Das spielt aber auch keine Rolle. Wichtig ist zuerst, dass die Hashes auf den einzelnen Clients unterschiedlich sind. Da ist es erstmal egal, ob das Passwort 1 Tage oder 1 Monat alt ist - es soll nur anders sein, als bei den anderen Clients. Und mehr oder weniger regelmäßig geändert werden.

 

Ok, der Vollständigkeit halber sei dann aber auch gesagt, daß das nur ein ganz kleiner Teil der ganzen PtH Geschichte ist. Du scheibst weiter unten, daß es Dir grundsätzlich um unterschiedliche Kennwörter geht - volle Zustimmung hierbei. Wenn Du das aber in Deinem beschriebenen Szenario in den Kontext von PtH hebst, möchte ich widersprechen. :) Denn "nur" das Setzen von Kennwörtern löst das Problem nicht, solange administrative Gruppenmitglieder Anmeldungen am Zielsystem durchführen können. Das sind ja nur sehr bedingt lokale Administratoren.

 

Benutzerservice, eventuell auch lokale Systembetreuer. Diese haben keine weiteren Privilegien in Domäne oder Memberserver.

 

...und sie melden sich (remote) an den Systemen auch interaktiv an, korrekt? Das ist ein Problem im Kontext von PtH.

 

Admins -> nie, aber es gibt halt auch kein Prinzip, dass das verhindert. In diesem Punkt geht es also nicht um 100%ige Sicherheit, sondern nur um Risiko-Senkung. Das Risiko, dass sich ein Trojaner, der PtH-Attacken fährt wird verringert, wenn Admins-Accounts auf den verschiedenen Clients andere PW haben. Und damit sinkt das Risiko, dass im Falle einer unerwünschten Admins-Anmeldung genau auf diesem Client ein Trojaner den Hash mitbekommt.

 

Siehe oben. Ich stimme Dir zu, es ist eine sinnvolle und "erste" Maßnahme. Aber adressiert es wirklich das Problem? Meines Erachtens wirklich nur sehr, sehr begrenzt.

 

Systemaccounts lassen wir mal bewusst außen vor. Natürlich sind Accounts für Virenscanner-, Softwareverteilung und Systemmanagement ein sehr hohes Risiko.

 

Definitiv. Und genau daher müssen sie mit betrachtet werden. Und ja, ich weiß daß das wirklich nicht einfach ist. Aber die Weichen müssen eben gestellt werden.

 

Bei den lokalen Admins-Accounts geht es ja nicht nur um PtH. Wenn Kennwörter auf den Rechner überall gleich sind, sprechen die sich auch mal rum. Auch dass soll ja verhindert werden.

 

Das ist absolut sinnvoll und valide. :)

 

Service-Accounts müssen davon getrennt, für jede Anwendung einzelnen untersucht und im Sinne des "Least Privileges" angewendet werden.

 

Definitiv. 

 

Aber ich denke, nur weil man einen Punkt hat, der man als Risiko schlecht eindämmen kann, sollte man nicht alle anderen deswegen vernachlässigen.

 

+1

 

Vollkommen klar. Aber Sicherheit ist eben nicht nur ein Schalter, sondern besteht aus vielen Bestandteilen.

 

+1

 

Mir ging es hier explizit um lokale Admins-Accounts.

 

Ja, ich verstehe das. Mir wiederum ist wichtig darzustellen, daß Du damit den Schweizer Käse nur um ein Loch erleichterst, er aber dennoch genauso duftet wie vorher. ;)

Beispiele? Wenn Du Angst hast, Namen zu nennen (was bei einer solchen Fragestellung i.d.R. kein Problem ist, denn ich frage ja explizit nach Anbietern), schick mir eine PM.

 

Ein Beispiel wäre Lieberman: http://www.liebsoft.com/Random_Password_Manager/

Was keine Empfehlung darstellt, sondern nur ein Beispiel. :)

 

Das Produkt tut auch etwas mehr als "nur" Kennwörter ändern (lokal und AD), es geht um "temporäre" Gruppenmitgliedschaften usw.

 

Cursor in das Zitat stellen und mehrfach die Entertaste drücken. Zuerst kommen Leerzeilen, danach unterbrichst Du das Zitat.

 

Ok, danke auch dafür! Mein IE hat mir schlicht keinerlei Zitate angezeigt, Chrome tut es aber. Dann klappt es auch. :)

 

Viele Grüße (und viel Erfolg ;))

olc

Hi Norbert,

 

ich hab das Gefühl, daß wir uns hier bald im Kreis drehen... ;)

 

Darum hier mein finales Statement zu diesen Punkten - denn ich gehe davon aus, daß sie korrekt ankamen. ;)

 

Zu #1:
Es gibt am Markt diverse Drittanbieter, die solche Lösungen anbieten. Microsoft kann auch keine Lösungen für jedwede Fragestellung anbieten - Kritik also in allen Ehren, aber es ist eben wie es ist.

Und ja, ich stimme Dir zu: die Idee als solches ist smart, dem habe ich auch nicht widersprochen. Ich habe lediglich auf eine bisher nicht genannte Ebene hingewiesen, die insbesondere bei Sicherheitsdiskussionen zentrale Bedeutung hat.

 

Zu #2:

Ggf. muß der Ansatz verändert werden - siehe meine Fragen an Robert. Es geht mir also wie so häufig nicht darum, eine Lösung für eine Fragestellung zu finden, bei dem Ursache und Wirkung verwechselt wird.

 

BTW: wie kann man hier zitieren? Ich finde keine Möglichkeit eine Textpassage aufzuteilen in kleine Teile.

 

P.S.: So, nun wird es Zeit für Dein letztes Wort dazu. ;)

 

Viele Grüße

olc

Hi Norbert,

 

ohne die Diskussion hier abgleiten lassen zu wollen: nur das letzte Wort zu haben, ist kein Argument. ;) :P

 

Zu Deinem Punkt 1:

Wenn ich die Sicherheit erhöhen will stellt sich die Frage, wie ich das tue. Nutze ich ein Tool dafür (neben Prozessen usw.), muß ich sicherstellen, daß dieses Tool meinen Sicherheitsanforderungen gerecht wird. Ob ein Tool auf Codeplex dem entspricht, muß ich bewerten. Das ist mein Argument, nicht mehr und nicht weniger. :)

 

Zu Deinem Punkt 2:

Klar, aber das Anliegen des TO ist recht eindeutig und daher ist der Zeitraum, wie lange die Systeme offline sind, ein durchaus wichtiger Bewertungspunkt. Denn die Zeit, die bis zu einer Kennwortänderung vergeht, ist auch bei PtH sehr relevant.

 

Viele Grüße

olc

Hi Robert,

 

die Lösung von Norbert ist tatsächlich ganz nett, auch wenn es offiziell nur ein "Sample" ist und sicher offene Fragen dazu existieren.

 

Wenn die PCs jedoch meist "offline" sind wird es grundsätzlich schwer, die Kennwörter zu ändern und zentral zu hinterlegen (in welcher Art auch immer).

 

Davon einmal ab zwei Rückfragen:

#1: Wer genau hat das administrativen Zugriff und wie findet die Rollentrennung auf den Systemen statt?

#2: Welche Domain-Accounts melden sich außer den lokalen Konten an den Systemen an (Admins, Service Accounts usw.)? In Bezug auf PtH eine nicht unwichtige Fragestellung. :)

 

Als grundlegende Aussage, egal ob die lokalen Administratoren-Kennwörter unterschiedlich sind auf den Maschinen oder nicht: die Ebene der Workstations läßt sich kaum langfristig schützen, je nach Umgebung. Das heißt Ihr müßt sinnvoll diese "low security" Systeme von den "high security" Systemen trennen(!) durch Zonenmodelle.

 

P.S.: Auch wenn es ein anderes Angriffsszenario (Stichwort "Golden TGT") ist - auch Kerberos ist in ähnlicher Art angreifbar. Nur als Hinweis, da Du lediglich LM/NTLM angesprochen hast. :)

 

Viele Grüße

olc

Hi,

 

davon abgesehen, daß eine 100% Kopie der AD zumindest den reinen AD-Teil an Tests gut abdecken kann, gibt es auch ein, zwei Gegenargumente:

 

• Security: ist die Testumgebung mindestens genauso "abgesichert" (physisch, logische Zugriffe usw.) wie die produktive AD
  ?
• Kannst Du wirklich 100% sicherstellen, daß es keinen Netzwerkkontakt der beiden Umgebungen gibt und geben wird?
• Wie hältst Du nach der initialen Installation der "Spiegelumgebung" die ADs synchron
• usw. usf.

 

Die Alternative zu einem Klon, der übrigens zumindest offiziell durch die meisten technischen Microsoft Mitarbeiter NICHT empfohlen wird, wer das Übertragen aller relevanten Einstellungen aus der Produktion in die Testumgebung. Dazu gehören unter anderem die Einstellungen, die Du oben erwähnt hast und sicher noch ein paar mehr. Das müßte gescriptet werden und ist mit einigem Aufwand verbunden, zugegeben.

 

Viele Grüße

olc

Hi,

 

um ehrlich zu sein mag ich diese Diskussion nicht unbedingt weiterführen - ich denke ich habe oben alles gesagt, was für eine Bewertung notwendig ist. Wir drehen uns im Kreis.

 

Wenn die Sicherheitsanforderungen Deiner Firma eine online Root CA für korrekt befinden, richte es gern so ein. Ich gehe davon aus, daß Ihr diese Sicherheitsanforderungen vorher definiert habt.

 

Die einzige Aussage, die für mich in diesem Kontext dann noch Sinn hat, lautet: Ihr braucht eigentlich keine PKI, denn offensichtlich geht es nicht darum, das Sicherheitsniveau spürbar anzuheben. Wozu dann die Mühe, überhaupt eine PKI zu betreiben?

 

P.S.: Alle(!) relevanten Guides zu PKI sprechen von einer offline Root CA. Wozu also diese Grundsatzdiskussion?

 

Viele Grüße

olc

:)

Hi,

 

wie genau möchtest Du das Root CA Zertifikat zurückziehen...? ;)

 

Der Unterschied zwischen einer Root CA und einer Sub/Intermediate/Issuing CA ist schlicht der, daß die Root CA Deine Wurzelinstanz ist. Ist diese kompromittiert, ist die ganze PKI nicht mehr vertrauenswürdig. Und das stellt Dich vor große Probleme, denn Du hast keine Instanz mehr, die dieses Vertrauen "beenden" (revozieren) könnte.

 

Ist "nur" eine Sub/Intermediate/Issuing CA betroffen, die Root CA jedoch nicht, läßt sich das Vertrauen in die PKI weiter erhalten, nämlich über den Rückruf des Zertifikats (und damit der ausgestellten Zertifikate) der kompromittierten CA.

 

Die Root CA ist also in einer PKI der schützenswerteste Punkt. Systeme, die online betrieben werden, haben per se größere Angriffspunkte als offline geschaltene Systeme. Das liegt in der Natur der Sache. Ich sage nicht, daß sie damit grundsätzlich "sicher" wären, nur sind die Angriffspunkte andere bzw. sind diese verschoben.

 

Viele Grüße

olc

Hi,

 

3. Treffer bei der Suchmaschine meiner Wahl: http://powershell.com/cs/media/p/30201.aspx ;) .

 

Viele Grüße

olc

Hi,

 

in welchem Status befinden sich denn die Verbindungen? FIN_WAIT?

 

Es gibt verschiedene Parameter, sie die jeweiligen TCP Timeouts bestimmen (siehe HKLM/System/CurrentControlSet/Services/TCPIP/Parameters). Aber da solltest Du nach Möglichkeit nicht herumschrauben. ;).

Ggf. hält auch ein Filtertreiber (z.B. Firewall oder Virenscanner) den Socket fest.

 

Ein Neustart löst das "Problem". Bei dem Thema: was genau ist eigentlich das Problem? ;)

 

Viele Grüße

olc

Mi Micha,

 

Du hast da meines Erachtens einen Denkfehler. :)

 

Die offline Root CA sorgt ja gerade dafür, daß Deine PKI Struktur nicht(!) oder nur mit enormen Aufwand kompromittiert werden kann. Sie online zu betreiben erhöht den Angriffsvektor massiv, was Du per Definition der Root CA (Wurzelvertrauen) verhindern möchtest.

 

Viele Grüße

olc

Hi Uwe,

 

kannst Du einmal ein ipconfig /all von dem System posten? Ggf. anonymisieren, bitte jedoch nicht den ersten Teil bis zum Doppelpunkt.

 

Viele Grüße

olc

Ergänzend: http://blogs.technet.com/b/deds/archive/2009/08/31/hinweise-zur-einfuehrung-bzw-aktivierung-von-kennwortrichtlinien.aspx

Absatz: Update 10.09.2009

 

Viele Grüße

olc

Nein - es ist nicht "oversized". Du mußt Dein angestrebtes Sicherheitsniveau definieren und davon abhängig machen, wie Du die PKI betreiben möchtest.

 

Es gibt im Kern eigentlich so gut wie kein Szenario, in dem eine offline Root CA keinen Sinn haben würde. Du betreibst eine PKI per Definition, um die Gesamtsicherheit in Deiner Umgebung zu steigern. Eine online Root CA setzt genau dieses Sicherheitsniveau wieder herunter. Ich würde soweit gehen zu sagen, daß Du Dir dann auch gleich die PKI sparen kannst - was sicherlich etwas übertrieben ist, den Hintergrund jedoch recht gut darstellt.

 

Viele Grüße

olc

Hi,

 

starte LDP.exe und verbinde Dich mit dem Knoten "CN=Policies,CN=SYSTEM,DC=<domain>,DC=<tld>".

 

Dort gehst Du jede GUID durch und schaust, welche der GUIDs Dir keine Attribute anzeigen, sprich Du kein Leserecht hast. Diese GUIDs (=GPOs) versorgst Du dann per Rechtsklick --> Advanced --> SACL (glaub ich) und gibst Deinem Administrativen Benutzer wieder Zugrff auf die jeweiloge GPO.

 

Dann kannst Du die GPOs wieder mit der GPMC verwalten.

 

Achtung:

- Nur dem administrativen Benutzer READ+WRITE Rechte geben, nicht "APPLY" für ihn oder andere Benutzer. Sonst greifen die GPOs wieder, was Du nicht möchtest.

- Zusätzlich beachte, daß im SYSVOL ebenso die alten GPOs liegen (sprich der Group Policy Template Teil). D.g. bearbeite die GPOs nach dem Setzen der ACLs wieder in der GPMC - dort sollte beim Klicken einer entsprechenden GPO der Hinweis kommen, daß das AD Objekt nicht mit dem SYSVOL Objekt (ACLs) übereinstimmt. Klicke hier "OK", um das wieder gerade zu ziehen.

 

Die Links der betreffenden GPOs zu löschen ist eine sinnvolle Idee - jedoch nur, wenn Du nicht das gesamte Attribut leerst, sondern nur diejenigen GUIDs entfernst, die zu den "problematischen" GPOs gehören... Warte also lieber, bis Du sie wieder normal mit der GPMC bearbeiten kannst nach der LDP Aktion. :)

 

Viele Grüße

olc

Hi,

 

wie ist es mit so etwas in der Art?

 

$services = Get-WmiObject -Query "Select StartMode, State, Name From Win32_Service"
$services | ForEach-Object { if ($_.startmode -eq "Auto" -AND $_.state -ne "Running") {write-warning $_.name}}

Viele Grüße

olc

P.S.: Du weisst, dass es nicht immer ein Problem sein muss, wenn so ein Dienst nicht läuft? Was konkret möchtest Du mit der Information erreichen bzw. was davon ableiten?

^{Das ist der aktuellste Microsoft-Artikel dazu: http://technet.microsoft.com/en-us/library/hh994562(v=ws.10).aspx}

 

^{Viele Grüße}

^olc

Vielen Dank für Deine Rückmeldung. :)

 

Viele Grüße

olc

Hi,

 

nur der Vollständigkeit halber - das AdminCount Attribut selbst wirkt sich nicht auf den AdminSDHolder Prozess aus. Das Attribut gibt nur einen Status und hat keinen Einfluss auf das Schützen oder nicht-Schützen von Accounts.

 

Zur Dokumentation bzw. besseren Nachvollziehbarkeit: http://gallery.technet.microsoft.com/scriptcenter/Reset-AD-adminCount-195bf65e

 

Viele Grüße

olc

..der Haken "Register this connection's addresses in DNS" in den TCP/IP Einstellungen der Netzwerkkarte ist gesetzt?

 

Viele Grüße

olc

Hi,

 

schau einmal hier hinein, beschreibt in etwa das Szenario: http://support.microsoft.com/kb/295049/en-us

 

Ansonsten als Hintergrund-Informationen: http://blogs.technet.com/b/askds/archive/2009/02/15/test2.aspx

 

Viele Grüße

olc