olc

Hi, ich stimme dem Doc da absolut zu - man hört immer wieder das Argument, daß Software XY nicht korrekt auf neueren Systemen läuft. Die Lösung dafür ist ganz einfach: Löst die Software ab. Alles andere ist in meinen Augen grob fahrlässig. Ansonsten als rein technischen Hinweis: - Windows 98 cannot join a Windows Server 2008 domain (dsforum2wiki) - TechNet Articles - Home - TechNet Wiki - The Net Logon service on Windows Server 2008 and on Windows Server 2008 R2 domain controllers does not allow the use of older cryptography algorithms that are compatible with Windows NT 4.0 by default - Client computers may not work correctly when you add a Windows Server 2008-based domain controller to an existing pre-Windows Server 2008 domain Habe ich übrigens über die Suchmaschine meiner Wahl in 1 Minute gefunden... ;) Viele Grüße olc

...wie oben schon geschrieben bist Du sicherlich schneller und für das Testen effektiver, wenn Du dem Client schlichtweg eine feste IP-Adresse gibst und ggf. auch die Netzwerkkartentreiber aktualisierst. Für ein Troubleshooting einen DHCP Server aufzusetzen halte ich für "overkill" bzw. holst Du Dir damit unter Umständen Probleme an anderen Stellen ins Haus. P.S.: Meine anderen Fragen hast Du auch nicht beantwortet... ;) Viele Grüße olc

Hi, ja, remote sessions. Oder wie außerdem angesprochen einmal PsExec + certutil probieren (falls Du es darfst). Habe ich aber noch nie probiert. Ein anderer Weg würde mir spontan auch nicht einfallen. Viele Grüße olc

Hi, Du suchst hier verkrampft nach einem Problem, wo keines ist. ;) Wie blub schon sagte ist in diesem konkreten Fall nicht entscheidend, ob dort eine aus Deiner Sicht inkorrekte DNS Abfrage läuft. Jede Applikation kann mittels diverser Flags bestimmen, wie genau eine Auflösung erfolgen soll - ggf. also auch aus Deiner Sicht "falsch". Außerdem hast Du nicht erwähnt, was nach der auf den ersten Blick inkorrekten DNS Abfrage geschieht - hier wäre also eher interessant, was der gesamte Startvorgang des Clients in Bezug auf DNS Traffic sagt. Wo genau hast Du den Trace gezogen? An einem Mirror Port des Switches? Stimmen die Zeiten der NETLOGON.log und des Netzwerktraces (Fehler im Log und Anfrage im Trace) überein? Wenn ich mir das NETLOGON.log anschaue, fallen mir zwei Dinge auf: Wenn ich mir den weiteren Verlauf des Logs anschaue, finde ich folgenden Eintrag: Wenn es sich hier um das Clientlog handelt, dann hat der Client nach meinem Verständnis zu diesem Zeitpunkt scheinbar vom DHCP Server noch keine korrekte Adresse bekommen und nimmt daher eine APIPA Adresse. Das würde das Problem erklären. Vergib testweise einmal eine feste IP-Adresse für den Client, aktualisiere den Treiber der Netzwerkkarte und prüfe, ob das Problem dann weiterhin auftritt. Viele Grüße olc

Hi, wie sehen die DNS TCP/IP Einstellungen auf dem DC aus, bitte poste einmal die Ausgabe von "ipconfig /all". Was sagen die Ereignisprotokolle - irgendwelche Hinweise im Application, System oder DNS Eventlog zu finden? Viele Grüße olc

Hi blub, der Mechanismus dahinter geht (neben anderen Punkten) davon aus, daß nur ein Administrator Zugang zum Computerspeicher hat. Ein dort importiertes Zertifikat hat dann "computerweite" Gültigkeit, also für alle Benutzer, Dienste und SYSTEM. Wenn jedoch ein Benutzer ein Zertifikat importiert (etwa nach dem im Internet Explorer eine entsprechende Fehlermeldung wegen einer fehlenden vertrauenswürdigen Zertifikatkette gemeldet wurde), dann kann der Benutzer das Zertifikat in den eigenen Speicher für vertrauenswürdige Zertifizierungsstellen importieren (nicht wirklich empfehleswert). Dieser gilt dann nur für ihn. Bevorzugt werden sollte meiner Meinung nach die GPO Variante für Domänen oder die AD Configuration NC Variante für den Forest. In beiden Fällen landen die Zertifikate dann im Computerspeicher. @Brenni: Ja, prüf einmal, ob es nun klappt. :) Viele Grüße olc

Hi blub, doch, es gibt zwei Speicher, auch für die vertrauenswürdigen Stammzertifizierungsstellen. :) Ein dort importiertes Zertifikat gilt dann nur für den aktuellen Benutzer, nicht für die Maschine. @Brenni: Schau in das Zertifikat hinein der Remote Apps und der Root (bzw. Zertifikatkette dahin) hinein - dort siehst Du, welche CRL URLs verwendet werden. Als Buchempfehlung wie immer: http://www.amazon.de/Windows-Server%C2%AE-Certificate-Security-PRO-Other/dp/0735625166/ref=sr_1_1?ie=UTF8&qid=1297239247&sr=8-1 Viele Grüße olc

Hi fleipe, es gibt im Kern keine "feste" Anmeldung an einem DC. Je nach Applikation kann die Authentifizierung an verschiedenen DCs stattfinden, die Variable %LOGONSERVER% ist also wirklich mit Vorsicht zu genießen. Was ist denn das Ziel der Übung? Was genau möchtest Du erreichen? Viele Grüße olc

Hi Brenni, das Installieren des Root-Zertifikats im Computerspeicher hat nichts mit dem von mir angesprochenen Lösungsansatz zu tun ;) - aber gut, daß es damit nun geklappt hat. Wenn das Zertifikat nicht im Computerspeicher lag, sondern im Benutzerspeicher, ist das Problem auch nachvollziehbar. Der Computer vertraut schlichtweg der Root CA nicht, solange es nicht im eigenen Speicher liegt. Du kannst das Root-Zertifikat innerhalb einer Domäne über GPOs verteilen oder aber über den Import in den "Public Key Services" Container im Configuration NC der AD (Stichwort "certutil.exe -dsPublish"). Das macht es in Zukunft vielleicht einfacher. Viele Grüße olc

...oder genau anders herum: Anonym würde klappen, nur die Computeridentität nicht. Ab Windows 7 verwendet ein SYSTEM Dienst bei NTLM Authentifizierung keine NULL Session mehr, sondern standardmäßig den Computer als Authenticator. Wenn dieser nicht berechtigt ist, auf die CRL zuzugreifen, dann kann es bei NTLM Zugriff zu Problemen kommen. Kerberos dagegen würde korrekt funktionieren. Changes in NTLM Authentication Also beides prüfen: blubs Idee mit der Berechtigung als auch die Frage, ob der Computer ggf. im Gegensatz zum anonymen Benutzer nicht authorisiert ist. Viele Grüße olc

Hallo AnTri, Du kannst das Scripten und dann über einen Task automatisieren. Spontan fallen mir dafür (je nach Betriebssystem) die "DS-Tools" ein (dsquery + dsmod in Deinem Fall) oder die PowerShell. Was genau ist denn der Hintergrund für die Fragestellung? Was möchtest Du damit erreichen? Über welche Größenordnung sprechen wir bei Deiner Umgebung? Hat vielleicht auch ein Provisioning / IdM System Sinn? Viele Grüße olc

Moin, moin, mit der PS 2.0 sollte sich der .Net Code doch direkt auf den Zielmaschinen ausführen lassen oder? Oder reden wir von PS 1.0? Falls PS 1.0 wäre vielleicht PsExec und certutil.exe eine Möglichkeit, habe ich aber noch nie getestet. Viele Grüße olc

Hi carnivore, ist unter Umständen die Umleitung per RDP Einstellungen oder GPO verboten worden? Ich meine mich zu erinnern, daß man das unterbinden kann. Gibt es im Ereignisprotokoll irgendwelche Meldungen, die auf die SmartCard hinweisen? Viele Grüße olc

Hi carnivore, ist auf dem Zielsystem der entsprechende CSP für die SmartCards installiert? Auf beiden Systemen muß dieser vorhanden sein, nicht nur auf dem Quellsystem. Ggf. einmal einen Blick in das Ereignisprotokoll werfen. Viele Grüße olc

Hi, aktiviere einmal das Logging and Tracing für die GPP (GPO --> Computer Settings --> Administrative Templates --> System --> Group Policy --> Logging and Tracing --> dann DSN CSE mit Warnings and Errors aktivieren). Vielleicht finden sich darin Hinweise auf das Problem. Viele Grüße olc

Hi, der "bind DN" ist der Benutzer, mit dem Du die Verbindung zum LDAP Server herstellst, also Deine Authentifizierung durchführst. Die "base DN" ist der "Einstiegspunkt", also zum Beispiel der Pfad innerhalb des Verzeichnisses / directories, von welchem aus eine Suche o.ä. stattfindet. Dieser muß nicht dem "root" Knoten entsprechen, sondern kann irgendwo innerhalb der Verzeichnisstruktur liegen. Damit schränkst Du also den Bereich ein, den Du verwaltest, durchsuchst o.ä. Hier findest Du dazu auch eine kurze Beschreibung: Lightweight Directory Access Protocol ? Wikipedia Viele Grüße olc

Hi, hast Du die Option "Prozesse aller Benutzer anzeigen" gewählt? Falls nicht, tue dies - es verändert die Prozessliste bzw. die Auslastungsanzeige. Viele Grüße olc

Hi onurbi und willkommen an Bo(a)rd, :) das aktuell für die EFS Verschlüsselung des Benutzers eingesetzte Zertifikat wird in folgendem Registry Schlüssel angegeben: HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\EFS\CurrentKeys Dort könntest Du - bei Bedarf - das "alte" Zertifikat bzw. dessen Hash hinterlegen. Du kannst auf die alten Dateien zugreifen, solange das alte Zertifikat inkl. des privaten Schlüssels auf dem Client vorhanden ist. Es ist also grundsätzlich erst einmal nicht notwendig, alle Dateien noch einmal anzufassen. Wenn Du möchtest, daß alle Dateien mit dem aktuellen Schlüssel verschlüsselt werden, kannst Du dies mit cipher.exe /u erledigen. Insgesamt macht eine Sicherung der EFS Zertifikate inkl. der privaten Schlüssel Sinn, um Datenverlust vorzubeugen. Frage am Rande: Handelt es sich um einen Domänenclient oder ein alleinstehendes System? Ich vermute letzteres, korrekt? Viele Grüße olc

Ich wiederhole mich nur ungern, besonders wenn ich Lernresistenz spüre: Du bist auf dem Holzweg. Laß es Dir einfach noch einmal durch den Kopf gehen, alles fachliche ist schon gesagt. Viele Grüße olc

Hi, Das ist (tut mir Leid für den Ausdruck) totaler Quatsch. Was ist zum Beispiel mit UMTS Sticks? Sicherheit erreicht Ihr nicht durch solche Maßnahmen wie dem Deaktivieren von DHCP im "fremden" Netz. Aber das wurde ja schon gesagt. Auf diesem Weg wirst Du Dein Ziel nicht erreichen. Viele Grüße olc

Hi, Genauso froh, wie es die "Virenschreiber" sein könnten, wenn sie Euer Netz anschauen. :p Mal ehrlich: Heute noch auf NT zu arbeiten ist fast schon grob fahrlässig. Ihr solltet wirklich schnellstmöglich auf ein aktuelles OS umstellen. Viele Grüße olc

...und vielleicht noch als generellen Hinweis zu dem Thema: Die "Sicherheitsfragen" in Bezug auf die Angabe des Kennworts mittels GPP (und damit einer "kodierten" Variante im SYSVOL) hast Du auf dem Schirm? Soll heißen: Deine Risikobewertung sagt, es ist kein Problem, daß hier das Kennwort des Benutzers unter Umständen ausgespäht werden kann? Viele Grüße olc

Hi Nizo, nur, um das Thema hier abschließend noch einmal ein wenig zu ordnen und strukturieren eine kurze Einschätzung der Lage: Punkt 1, SSL: Das Thema ist offensichtlich nicht relevant, weil es ausschließlich bei Deinen LDP.exe Tests aufkam. Ich würde es also erst einmal nicht weiter betrachten. ld = ldap_open("192.168.0.232", 636); Error <0x51>: Fail to connect to 192.168.0.232. Punkt 2, LDAP bind Ein potentielles Problem findet sich im LDAP bind. Aus meiner Sicht mußt Du hier in der Kerio Konfiguration einen Account angeben, der die Verbindung zum AD herstellt (mittels LDAP bind). Prüfe also noch einmal die Kerio Konfiguration. 192.168.0.232 192.168.0.236 LDAP searchResDone(2) operationsError (000004DC: LdapErr: DSID-0C0906DD, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1772) [0 results] Punkt 3, SPN: Ich weiß nicht so recht, wie Du auf das Thema gekommen bist. Aber aus den bisher genannten Daten geht nicht hervor, daß Kerberos zum Einsatz kommt zwischen AD und Kerio. Daher würde ich erst einmal auch das Thema SPN nicht weiter betrachten. Punkt 4, Scope der LDAP Suche Wenn ich mich nicht irre, ist die Angabe von "cn=groups,dc=KU,dc=local" nicht korrekt. Auch hier vermute ich, daß in der Kerio Konfiguration die richtige "LDAP base" angegeben werden muß. Also zum Beispiel: - cn=users,dc=KU,dc=local - cn=builtin,dc=KU,dc=local - dc=KU,dc=local oder so etwas in der Art. Das kommt auf Deine AD Struktur an und Du bist der einzige, der diese hier kennt. Also prüfe die Kerio Konfiguration auf die "Base DN" [21/Dec/2010 18:02:03] LDAPS: Cannot search in cn=groups,dc=KU,dc=local on LDAP server 192.168.0.231, error: Operations error (code 1) [21/Dec/2010 18:02:03] Cannot list all users, LDAP server error: 801. [21/Dec/2010 18:02:09] Cannot list all users, LDAP server error: 801. [21/Dec/2010 18:02:09] Cannot list all users, LDAP server error: 801. [21/Dec/2010 18:02:10] Cannot list all users, LDAP server error: 801. [21/Dec/2010 18:02:15] LDAPS: Schema extensions have not found on LDAP server 192.168.0.231: Operations error Punkt 5, DNS Mir ist auch hier nicht ganz klar, was Du mit dem DCDIAG Befehl da eigentlich testen wolltest. Aber ich denke im Moment nicht, daß hier Dein Problem liegt. Also laß es erst einmal außen vor und prüfe die anderen Fehler - bzw. lasse diese durch einen Dienstleister prüfen. C:\Users\Administrator>dcdiag /test:outboundsecurechannels /s:kde2k8mail, /testdomain:ku.local Verzeichnisserverdiagnose Anfangssetup wird ausgeführt: Auf dem Server kde2k8mail, ist beim Suchen des LDAP-Suchfunktionsattributs ein Fehler aufgetreten. Rückgabewert = 81 Der Host kde2k8mail, konnte nicht zu einer IP-Adresse aufgelöst werden. Überprüfen Sie DNS-Server, DHCP, Servername, usw. Ich verabschiede mich mit der Einschätzung aus diesem Thread - ich denke ich habe alle mir möglichen Hinweise gegeben. Viele Grüße olc

Hi carnivore, Du solltest mit dem folgenden Befehl die Hilfe zu der Option bekommen: C:\> certutil -URLCache -? Dort erscheint dann auch die "-v" und "CRL" Option. Aber certutil.exe ist tatsächlich ein nicht so einfach zu benutzendes "Schweizer Taschenmesser der PKI". :) Sofern Du nicht jede CRL umbenennen möchtest, kopierst Du Dir den Dateinamen der lokalen CRL und führst folgenden Befehl aus (ggf. Pfad bei XP/2003 anpassen): C:\>certutil -dump "C:\Users\<DEIN_BENUTZER>\AppData\LocalLow\Microsoft\CryptnetUr lCache\Content\<ThumbPrint_der_CRL>" Das ganze kannst Du meines Wissens auch über die CryptoAPI mit VBScript o.ä. abfragen. Aber das ist nicht so meine Baustelle. ;) Viele Grüße olc

Hi, mittels "certutil -v -URLCache CRL" bekommst Du nur die CRLs angezeigt. Diese kannst Du dann entweder mit certutil dumpen oder wie von Dir beschrieben einfach per "*.crl" Anhang in der GUI öffnen. Viele Grüße olc