RalphT

Moin, ich habe hier eine 2-stufige Zertifizierungstelle. Hier habe ich folgendes Phänomen: Wenn ich über den Webbrowser Zertifkate anfordern möchte, dann werden mir hier nicht alle Vorlagen angezeigt. So ganz bin ich da nicht dahinter, warum bestimmte Vorlagen dort nicht erscheinen. Ich habe etwas rumprobiert und dabei habe ich folgendes festgestellt: Zertifikatvorlagen für die Benutzer werden wohl alle angezeigt. Bei den Vorlagen für Computer werden die Vorlagen wohl nur angezeigt, wenn ich unter dem Reiter "Antragstellername" die Option "Informationen werden in der Anforderung angegeben" wähle. Kann mir jemand sagen, warum nicht alle Vorlagen im Webbrowser angezeigt werden? In der MMC wird alles korrekt angezeigt.

Ich wollte noch mal kurz eine Rückmeldung geben: In diesem Fall war es einfach: Ein Neustart half.

Moin Norbert, Nein, den habe ich nicht. Ja, der Panda. Dazu muss ich sagen, dass ich den auch schon im Verdacht hatte. Mein nächster Weg wäre jetzt erst mal einen Neustart durchzuführen. Nur geht das gerade jetzt nicht. Dazu müsste ich bis heute abend warten. Evtl. könnte ich mal testweise den AV deinstallieren. Äh, nein leider nicht. Wäre wohl der nächste Schritt, wenn ein Neustart nichts bringt. Ja, ich weiß, man sollte immer up to date sein. Aber die Kiste läuft schon so lange ohne Probleme, dann denkt man an ein Update nicht so oft. Die Clients sollten auf dem aktuellen Patchstand sein.

Moin, ich habe hier ein Problem mit einem Exchange 2010 SP3. Wenn ich im Outlook eine Mail versende, bleibt manchmal unten im Outlook der grüne Balken mit "Nachricht 1 von 1 wird versendet" für ca. 2 Min. stehen. Beim Emfänger ist die Mail jedoch schon angekommen. Das geschieht auch immer sehr zeitnah. Parallel zum E-Mail-Konto habe ich den OWA dazu aufgerufen. Im OWA habe ich mehrmals eine Nachricht an einen selbst versendet. Vom OWA aus scheint das alles sehr schnell zu funktionieren. Auch im Outlook des Empfängers erscheinen zügig die neuen Mails. In der Ereignisanzeige vom Exchange ist keine Fehlermeldung zu sehen. Testweise habe ich mal den lokalen Cache vom Outlook gelöscht und Outlook wieder gestartet. Die anschließende Replikation schien soweit zu funktionieren, brachte aber keine Besserung. Der Fehler scheint wohl nur beim Versenden im Outlook aufzutreten. Was könnte das denn sein? PS: Manchmal ist es auch so, dass bei Outlook steht "Übermittlung wird vorbereitet". Die Mail ist aber schon sofort raus und auch beim Empfänger angekommen. Das habe ich eben auch mal an einen anderen Arbeitsplatz ausprobiert.

Nein, wichtig ist das nicht. Ich bin da heute durch Zufall drauf gestoßen. Hätte ja sein können, dass das auch schon mal jemand hier hatte. Ich weiß auch garnicht, ob die Mehrheit einen Client über diesen Weg in die AD bringt oder mit dem Button darunter "Ändern". Dann gibt es diesen Fehler nicht und hier ist auch weniger Tipparbeit erforderlich.

Moin, ich bin heute über eine Sache gestolpert, die ich derzeit nicht verstehe. Die Umgebung: 2 DCs 2008 R2 und ein Client Win10. Domäne = SUB.FIRMA.DE Netzwerk: Die beiden DCs sind im LAN 192.168.10.0/24. Auf dem einzigen Switch ist noch zusätzlich ein VLAN konfiguriert: 192.168.21.0/24. Der Switch macht zwischen den beiden LANs das Routing. Firewalls auf DCs sind testweise mal deaktiviert. Der Client ist derzeit im VLAN 192.168.21.0/24. Ich nehme den Client aus der Domäne. Das Konto auf dem DC lösche ich nicht. Ich nehme den Client wieder in die Domäne. Dazu gehe ich den Weg mit dem Button "Netzwerk-ID..." Dort trage ich im ersten Fenster die Daten ein. Klicke ich auf Weiter, sagt mir das System, dass schon ein Konto existiert und fragt, ob ich das Konto verwenden möchte. Ich klicke auf JA. Jetzt kommt folgender Fehler: Fehler: "Der DNS-Name ist nicht vorhanden." (gekürzt) Lösche ich das Computer-Konto in der AD, dann kann ich den Client der Domäne hinzufügen. Wenn ich den Client im gleichen LAN in dem auch die beiden DCs sind, dann habe ich das o.g. Problem nicht. Der Client bekommt sein IP-Konfiguration vom DHCP. Die beiden DNS-Einträge auf dem Client zeigen auf die beiden DCs. Fehlt hier im DNS ein Eintrag oder ist das Verhalten normal?

Alles klar, danke Dir! Ich hatte das zwar nur testweise gelöscht, aber vielleicht sollte ich dafür zusätzlich ein GPO verwenden. Das ist dann wohl doch sicherer. Gerade eben hatte ich noch folgendes ausprobiert: Client aus Domäne raus und rein. Danach waren die Einträge wieder da.

Ich wollte eigentlich nur wissen, wie diese Einträge in dem lokalen Zertifikatsspeicher unter "Zwischenzertifizierungsstellen" erscheinen. Irgenwie scheint das automatisch nicht zu funktionieren. Bislang ist mir das nie aufgefallen, da diese Einträge eigentlich bei jedem Client auch immer vorhanden sind. (Wenn man sie nicht händisch löscht)

Daran hatte ich schon gedacht, mir dann aber überlegt, dass das ja vorher auch immer so funktionierte. Ich hatte mir über diesen Speicherort bislang keine Gedanken gemacht. Wie lange muss man da denn warten? Ein gpupdate half hier auch nicht. Eigentlich nicht weiter wild, denn die Zertifkate an den wichtigen Orten sind ja vorhanden.

Moin, ich habe eine 2-stufige PKI. Auf jedem Server/Client in der Domäne sind Einträge im lokalen Zertifikatsspeicher unter "Zwischenzertifizierungsstellen". Dort ist das ROOT und SUB-Zertifikat zu finden. Bei einem Client habe ich das mal gelöscht. Nach dem Neustart des Clients waren die beiden Zertifkate nicht mehr da. Wie kommen diese Einträge dort hin? Wozu dienen diese beiden Zertifkate an diesem Speicherort? Der Eintrag vom ROOT-Zertifikat ist unter "Stammzertifizierungsstellen" weiterhin zu finden. Dort sorgt ja eine GPO für die Verteilung.

Ich sehe gerade, dass auf der Seite Verbindungsliste die Regelerzeugung auf automatisch steht.

Ich bin gerade am suchen, wo der Eintrag geblieben ist. Seit diesem Update finde ich den gerade nicht. Bei den anderen Lancoms steht der Wert immer auf "Jede einzeln nach Bedarf". Ich bin mir sehr sicher, dass ich hier nichts verändert habe, daher behaupte ich mal, dass das auch für diese Lancom zurifft.

Nun habe ich heute die Version 10.20 RU2 aufgespielt. Nachdem der Router seinen Neustart beendet hatte, hatte ich gleich gesehen, dass das nicht Erfolg führte. Ich musste also beim Tunnelaufbeu bei 2 Netzen wieder nachhelfen. Jetzt bin ich mir nicht sicher, ob ich dich richtig verstanden habe: Besteht das Problem im VPN immer noch bei der aktuellen Version oder redest hier von VRRP?

Danke dir. Ich habe einen Lancom, der ist derzeit nicht so wichtig. Da werde ich die 10.20 RU aufspielen. Dann mal sehen. Auf der Lancomschulung hat man mir zig mal eingetrichtert, dass ich immer die neueste Firmware nehmen soll. Ok, ich gucke da nicht immer regelmäßig drauf. Vielleicht auch deshalb, weil alles funktioniert. Bei der Sonicwall hatte ich auch mal ohne vorher nachzufragen, die neueste Firmware aufgespielt. Naja, danach hatte ich große Augen: Es waren im Firewallregelwerk nicht mehr alle Regeln zu sehen. Aber sie wirkten noch - zum Glück. Eine Nachfrage beim Händler ergab, dass es dort einen BUG gab. Regeln, die in der Beschreibung Umlaute hatten, wurden nicht mehr angezeigt. Da gab es auch von der Sonicwall einen Beitrag dazu, wie man das wieder in Ordnung bringt.

Hmmm, also auf dem Problemlancom ist die 10.12.038RU9. Auf einem anderen Lancom, der auch mal Probleme macht ist sogar noch die 9.24.0070 drauf. Ich habe gerade nachgesehen: Derzeit ist 10.20 RU2 aktuell. Dazu muss ich sagen, dass ich bei keinen der Lancoms VRRP nutze. Dann könnte ich die doch nehmen - oder??

Moin, ich habe hier schon länger ein Problem. Der VPN-Tunnel zwischen einer Sonicwall NSA 2600 und einem Lancom 1783 VAW ist nach einer gewissen Zeit immer gestört. Wenn das der Fall ist, dann ist zwischen den verbundenen LANs keine Datenübertragung mehr möglich. Zwischen der Sonicwall bestehen auch noch andere VPN-Verbindungen zu anderen Lancoms. Auch zwischen diesen Verbindungen tritt ab und zu mal dieses Problem auf. Auf der Sonicwall und auf dem Lancom ist der Tunnel immer noch verbunden. Hier etwas zur Konfiguration: Zwischen der Sonicwall und dem Lancom bestehen mehrere Netzbeziehungen. Auf der Sonicwallseite sind es derzeit 5 verschiedene LANs und auf der Lancomseite sind es 2 verschiedene LANs. Der Fehler äußert sie wie folgt: Es wird oder wird nur meist nur eine LAN-Verbindung unterbrochen. Also die anderen bestehenden Netzbeziehung zwischen den beiden Firewalls funktionieren einwandfrei. Jetzt ist natürlich die Frage, was ist an dieser gestörten LAN-Verbindung anderes? Da habe ich länger geforscht und bin jetzt der Meinung, dass das am Traffik liegt. Denn zwischen diesen LANs wird fließt der meiste Datenverkehr. Abhilfe schafft entweder ein erneuter, kompletter Tunnelaufbau auf der Seite vom Lancom oder ein erneuter Aufbau nur von diesem Netz auf der Sonicwall. (Button Renegotiate) Anschließend wird nur diese Netzbeziehung wieder erneut aufgebaut und das Problem ist für mehrere Stunden ok. Auf der Lancomseite und Sonicwall habe ich folgende Werte für den Tunnel konfiguriert: --------------- Sonicwall -------------- Phase 1: Main-Mode DH-Group 2 AES-128 SHA-1 Lifetime 108.000s Phase 2: ESP AES-128 SHA-1 Lifetime: 28.800s --------------- Lancom -------------- Phase 1: AES-128 SHA-1 Liftetime: 108.000s Phase 2: AES 128 SHA-1 Liftime: 28.800 0 kBytes Hier die Netzbeziehungen (die habe ich zig mal auf beiden Seiten auf Richtigkeit kontrolliert): Seite Sonicwall: 192.168.1.0/24 192.168.2.0/24 192.168.3.0/24 192.168.4.0/24 192.168.5.0/24 Seite Lancom: 192.168.10.0/24 192.168.12.0/24 Hier wird auf beiden Seiten mit fester IP-Adresse und Presharedkey gearbeitet. Der meiste Traffik läuft auf der Sonicwallseite im Netz: 192.168.5.0/24. Und genau nur diese Verbindung zu den Remotenetzen im Lancom ist gestört. Alle anderen Netzbeziehungen laufen ständig. Ode sagen mir vorsichtig so: Hier wurde bislang keine Fehler festgestellt. Wenn der Tunnel händisch neu aufgebaut wird, dann hält das für ca. 6-7 Std. Diese Zeit entspricht aber nicht dem Erneuerungsintervall von 28.800s. Anschließend darf man wieder "Hand anlegen". Was mich dabei stutzig macht ist folgendes: In der Sonicwall kann ich für den gesamten Tunnel die Option "Disable IPsec Anti-Replay" aktivieren. Wenn man das dann abspeichert, funktioniert der VPN manchmal wochenlang tadellos. Bis der Fehler dann wieder auftritt. Ab dann tritt das Phänomen wieder regelmäßig auf. Dann nehme ich in der Sonicwall wieder diese o.g. Option raus. Danach läuft das wieder wochenlang. Ich denke mal, dass diese Option mit diesem Fehler nichts zu tun hat. Ich tippe eher darauf, dass dieser Fehler durch eine Konfigurationsänderung erstmal weg ist. Das wird wohl Zufall sein. Meine letzte Idee war, dass die Sonicwall mit der Firmware dieses Problem hat. Ich hatte aber, mit Rücksprache von Sonicwall, eine aktuelle, gut lauffähige Firmwareversion aufgespielt. Aber daran lag es nicht. Ja, jetzt die spannende Frage: Hat da jemand eine Idee?

Mir ist das nur aufgefallen, wenn Nutzer sich eine E-Mailadresse notieren. Da wird das gerne so notiert: Vorname.Nachname@firma.de Was die dort in Outlook nun genau eintippen, weiß ich nicht.

Ist das technisch gesehen egal , ob hier Groß- und Kleinschreibung verwendet wird?

Hm, da bin ich mir selber nicht so sicher. Ich habe gerade etwas tiefer den "Bauchschußthread" gesehen. Hier war wohl das gleiche Problem. Hier noch mal das Zitat daraus: Bauchschuß: krbtgt-Kennwort nicht mehr synchron... Lösung: kdc auf allen DCs außer dem PDC deaktivieren, dann alle außer dem PDC neu booten. Ist das krbtgt-Kennwort das Gleiche, wie das Computertkennwort? Oder besser gesagt, redet man hier von der gleichen Sache?

Hab ich auch. Ich habe gerade mal nachgesehen. Jetzt ist dort auch ein Eintrag. Sieht gut aus. Eine Frage noch: Wie lange könnte man eine Seite komplett down lassen? Ich habe in den Metadaten gesehen, dass eine Aktualisierung des Kerebos-Passworts wohl alle 5 Min. durchgeführt wird.

Hier schien wohl dieses Problem die Ursache gewesen zu sein. Siehe hier:

So, jetzt bin ich weiter. Wie es aussieht funktioniert das wieder. Die große Hilfe kam von hier: https://blogs.technet.microsoft.com/deds/2009/04/02/fehlerbehebung-zu-replikationsfehler-mit-the-target-principal-name-is-incorrect-unter-windows-server-2008/ In dem o.g. Beispiel ging es um 2 DCs. Ich habe dann von allen Vieren mir die Metadaten anzeigen lassen. Dort habe ich dann gesehen, dass die Kerberos-Passwörter von der Außenstelle deutlich älter, als die beiden in der Haupstelle waren. Anschließend habe ich dann auf den beiden DCs von der Außenstelle, das o.g. Verfahren durchgeführt. Nach einer Minute lief wieder alles. Eine Kontrolle mit repadmin /showrepl zeigt bei allen DCs keine Fehler. Meistens ist es ja so, wenn man vorher irgandwo etwas herumgeschraubt hatte, dass auf diese Sache sofort der Verdacht fällt. Ist ja meistens auch richtig, nur nicht in diesem Fall. Hier war wohl die Offlinezeit der beiden DCs einfach zu hoch. Noch eine abschließende Frage: Bei der Kontrolle der NTDS-Settings ist mir bei dem DC-Paar in der Haupstelle aufgefallen, dass bei einem Server (DC-1) keine automatisch generierte Verbindung besteht. Auf dem anderen Server (DC-2) ist eine automatische Verbindung zum DC-1 vorhanden. Wird das irgendwann noch wieder automatisch erstellt? Ich wollte das jetzt nicht manuell hinzufügen.

Was bedeutet Zeitlang? DC-1 und DC-2 waren ca. 5 Std. offline. Die anderen beiden DCs in der Nebenstellen waren jedoch immer an. Nachtrag: In der Zeit, wo die beiden DCs aus waren, habe ich in beiden Geräten eine neue Netzwerkkarte eingebaut. Nach dem Hochfahren des DC-1 fiel mir sofort auf, dass bei beiden die Windowsaktivierung futsch war. Das muss jetzt nicht unbedingt mit diesem Fehler zusammenhängen, nur ich vermute es schon fast. Siehe auch hier:

Hier noch ein paar Ausgaben, die ich gerade erstellt habe. Server-DC-1 und Serer-DC-2 stehen in der Haupstelle und die anderen beiden Server-DC-3 und 4 in der Nebenstelle. Ausgabe repadmin /replmon auf Nebenstelle DC-3: ==== EINGEHENDE NACHBARN===================================== DC=ForestDnsZones,DC=SUB,DC=FIRMA,DC=DE Sande\SERVER-DC-4 über RPC DSA-Objekt-GUID: c24f5916-0819-463c-9a67-3cdb9bbefa72 Letzter Versuch am 2019-01-15 13:56:58 war erfolgreich. Quelle: SUB\SERVER-DC-2 ******* 5 AUFEINANDERFOLGENDE FEHLER seit 2019-01-15 13:11:03 Letzter Fehler: -2146893022 (0x80090322): Der Zielprinzipalname ist falsch. Namenskontext: DC=ForestDnsZones,DC=SUB,DC=FIRMA,DC=DE Quelle: Sub\SERVER-DC-2 ******* WARNUNG: KCC konnte diese REPLIKATVERKNPÜFUNG aufgrund eines Fehlers nicht hinzufügen. Ausgabe repadmin /replmon auf Nebenstelle DC-4: DC=SUB,DC=FIRMA,DC=DE Sande\SERVER-DC-3 über RPC DSA-Objekt-GUID: 2b58a3ff-cae0-49b6-99ec-234893fb7905 Letzter Versuch am 2019-01-15 14:21:51 war erfolgreich Ausgabe repadmin /replmon auf Hauptstelle DC-2: DC=ForestDnsZones,DC=SUB,DC=FIRMA,DC=DE SUB\SERVER-DC-1 über RPC DSA-Objekt-GUID: c450d19c-1343-4e32-a8d5-e5ce37d4d636 Letzter Versuch am 2019-01-15 13:58:33 war erfolgreich. Sande\SERVER-DC-3 über RPC DSA-Objekt-GUID: 2b58a3ff-cae0-49b6-99ec-234893fb7905 Letzter Versuch am 2019-01-15 14:13:34 war erfolgreich.

Moin, ich habe auf zwei DCs die folgende Fehlermeldung: Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server "server-DC-2$" empfangen. Der verwendete Zielname war SERVER-DC-2$. Dies deutet darauf hin, dass der Zielserver das vom Client bereitgestellte Token nicht entschlüsseln konnte. In der Hauptstelle stehen 2DCs, in der Nebenstelle stehen auch zwei DCs. Zwischen den beiden zusammenstehenden DCs scheint die Replikation wohl zu stimmen. Zwischen der Haupstelle und Nebenstelle besteht das Problem. Wenn ich jetzt eine Verbindung von der Nebenstelle zu einem der beiden DCs in Hauptstelle einrichte dann bekomme ich diese Fehlermeldung. Diese sind dann nur den beiden DCs der Nebenstelle. Auch ein REPADMIN /SHOWREPL zeigt auf den beiden besagten DCs Fehler. Hier scheint mit den SPS etwas nicht zu stimmen. Nur hier komme ich derzeit nicht weiter. Wer hat eine Idee, wo ich nachsehen sollte?