Vinc211
-
Gesamte Inhalte
247 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von Vinc211
-
-
vor 12 Stunden schrieb Nobbyaushb:
Ich terminiere VPN grundsätzlich am Router / Firewall, alles andere ist mir zu gefährlich
Löst das Problem nicht. Gibt es einen OpenVPN CLient der auf der Logon Seite mit auftaucht, außer dem von Windows? Damals Bei Ccheckpoint VPN ging das, das weiß ich.
-
Gerade eben schrieb NorbertFe:
Ist sicher nur eine Einstellungsfrage.
Klar, ich komm nur nicht dahinter welche Einstellung es ist. Meine Versuche haben nichts ergeben und ich finde den Punkt nicht.
-
Gerade eben schrieb NorbertFe:
Pptp sollte man aus Sicherheitsgründen nicht mehr verwenden. Ja l2tp sollte sich ähnlich verhalten, ist aber sicherer.
Ok ich habs in der zwischenzeit mit L2TP versucht, aber habe das selbe Problem. Er versucht immer direkt den Login, und merkt dann das dies nicht geht, und kappt dann auch das L2TP
-
Guten Tag,
ich muss mit einem Windows 10 Client eine VPN Verbindung vor dem Windows Login einbauen. Dazu habe ich auf der Firewall zum Test mal PPTP aktiviert und einen lokalen User auf der Firewall eingerichtet.
Über die Systemsteuerung im Windows Client hab ich eine VPN Verbindung angelegt. PPTP eingestellt und die Verbindung so eingestellt das ich diese auf dem Login Screen aktivieren kann.
Wenn ich als User angemeldet bin funktioniert das PPTP sehr gut. Wenn ich dies aber vor dem Login machen möchte Verbindet sich die VPN Verbindung (im PPTP Log der Firewall nachvollziehbar) aber es wird auch direkt ein Login in Windows mit den Anmeldedaten versucht, das natürlich fehlschlägt und die PPTP Verbindung wird getrennt.
Wo ist der Fehler in den Einstellungen? Nachdem PPTP aktiviert ist, muss ich zurück zum Windows Login Screen für die Domäne kommen.
Wenns mit PPTP nicht geht, wäre das mit L2TP machbar?
-
Okay ich bin mir ein wenig unsicher, da meine 3 Sites alle durch eine FW getrennt sind.
Die Site Link Bridge wird im Beispiel ja nur angewendet wenn wirklich traffic möglich wäre, was bei mir über die Zentrale nicht funktioniert.
-
Okay. Ich habe die DefaultIPSiteLink entfernt und einmal Zentrale nach Standort A und einmal Zentrale mit Standort B angelegt.
Den Haken mit Brücke zwischen allen Standorten habe ich entfernt.
https://www.faq-o-matic.net/2005/02/15/replikation-standorte-standortverknuepfungsbruecken/
Die beiden Seiten unterscheiden sich etwas in dem nutzen der Site Link Bridge wenn ich das richtig sehe. Benötige ich eine in der ich beide Sitelinks die ich jetzt erstellt habe einfüge oder nicht?
-
Guten Tag,
ich habe gestern den 4ten Domaincontroller in unsere Domäne eingefügt, da ein dritter Standort dazu gekommen ist.
Aktuell sieht es so aus das am Hauptstandort 2 DC'S sind. DC1 und DC2. Die beiden haben jeweils eine automatisch genertierte Verbindung zu einander für die Replikation.
Zudem hat DC1 einee automatische Replikation zu DC3. Dieser DC3 steht an unserem zweiten Standort in Berlin. Der DC3 hat selber unter den NTDS Settings 2 Einträge, diese sind aber beide nicht automatisch generiert.
Wenn ich jetzt repadmin /kcc am DC4 ausführe, also an unserem neuen DOmaincontroller im neuen Standort, dann bekommt DC3 eine neue automatisch generierte Verbindung, und den DC4 keinen Eintrag in den NTDS Settings.
Ich möchte allerdings nicht das der DC4 sich mit dem DC3 austauscht, und die Verbindung einträgt ( vorallem weil die gar nicht miteinander kommunizieren können, weil es keinen Tunnel zwischen diesen gibt ) sondern das der DC4 mit DC1 eine automatisch generierte Verbindung eingeht.
WIe komme ich zu diesem Ziel?
-
vor 4 Minuten schrieb NorbertFe:
Ja klar.
Okay, dann hat sich das ja eigentlich mit dem Signaturdienst. Wenn ich die Mail auf dem Server ändern kann, dann ist ja nie gewährleistet das die Mail nicht manipuliert ist bevor diese in den Archivspeicher geht. Würdest du mir da zustimmen?
Als Anwalt würde ich genau an dem Punkt ansetzen.
-
Guten Tag,
wir haben neben unserem Exchnage 2016 Server einen Emailarchivierungsdienst laufen der alle ausgehenden und eingehenden Mails archiviert und mit einer digitalen Signatur versieht, das aussagt das die Mail nicht verändert wurde im Archiv.
Dieser Signaturdienst kostet ziemlich viel Geld. Das Emails archiviert werden finde ich gut und wichtig und das alles auf externen Maschinen noch mal vorhanden ist ist eine gute Gewissheit, nur stelle ich mir die Frage was die digitale Signatur genau bringt, wenn die Mails vorher die Firewall und den Exchange passieren. Dort könnten die Mails von theoretisch verändert werden, und das Archiv hätte somit eine veränderte Mail mit einer Signatur versehen.
Ist es Möglich auf dem Exchange Emails zu verändern?
-
Okay, hät ja sein können das MS so nett ist und die als Offline Paket bereitstellt. Wenn Sie schon sagen welche Root Certs sie aktuell im "Programm" haben, wäre ein offline updater ja ein einfaches gewesen, aber auch entgegen der MS Politik (always online und so =)
Danke soweit. Thema ist für mich gelöst.
-
Gerade eben schrieb NorbertFe:
Klar. Root Certificates per GPO an alle verteilen. :P Ist eben manuell.
Ja aber ich habe die Zertifikate ja gar nicht =D Kann ich die "Sammlung" irgendwo runterladen.
Verteilen wäre kein Problem.
-
vor 2 Minuten schrieb NorbertFe:
Ja. Das automatische Root Zertifikatsupdate gibts seit XP SP2 meine ich:
https://gpsearch.azurewebsites.net/Default.aspx?PolicyID=4716
Ah und da steht ja auch das die Windows Update Website angefragt wird. Das ist nicht machbar.
Weißt du ob es einen manuellen weg gibt?
-
vor 2 Minuten schrieb zahni:
Die Stammzertifikate werde schon seit Windows XP automatisch aktualisiert. Dort gab es einen extra Dienst dafür. Bei Windows 10 kann man den nicht mehr abschalten (ich wüsste nicht wie). Abschalten per GPO geht aber sicher weiterhin. Das hat aber mit den WSUS-GPOs nichts zu tun. Wenn Zertifikate automatisch aktualisiert werden, wird ein Event der Quelle CAPI2 protokolliert.
Naja hat schon mit der GPO zu tun, wenn ich den Servern und Clients im Netz untersage mit den Microsoft Diensten zu kommunizieren oder? Der Store etc. geht ja dann auch nicht.
Ansonsten ist nämlich ein Problem vorhanden, dass ich nicht erklären kann. Das wäre schlecht.
-
vor 14 Stunden schrieb zahni:
Hat das Gerät Interzugang? Windows lädt diese Root-Zertifikate automatisch herunter.
Internetzugang ist vorhanden, aber die Verbindung zu den Windows Diensten wird untersagt (GPO WSUS).
Werden diese Zertifikate also nur bei Bedarf runtergeladen?
-
Guten Tag,
bei einem unserer Windows Server 2012 R2 ist es vorgekommen das ich ein Programm nicht updaten konnte, da sich das Programm die entsprechenden Datein die es noch benötigt nicht per https ziehen konnte, da ein Root Zertfikat gefehlt hat.
Nachdem ich dann das entsprechende Zertfikat in die Vertrauenswürdigen Stammzertifikate importiert hatte ging alles wie geschmiert.
Ich habe dann bei MS nachgeschaut und das "Microsoft Trusted Root Certificate Program" gefunden und gesehen, dass das Zertifikat mit in den Participants steht. Generell ist die liste sehr lang: https://social.technet.microsoft.com/wiki/contents/articles/51151.microsoft-trusted-root-certificate-program-participants-as-of-january-30-2018.aspx
Doch sind bei weitem nicht alle drin. Sollte sowas nicht über Windows Update aktuell gehalten werden? Oder ist es normal das nicht alle Root Zertifikate die in der Liste aufgeführt sind in meinen Vertrauenswürdigen Stammzertifikaten zu finden sind?
Auch bei einem frischen Windows Server 2016 oder einem Windows 10 1709 finde ich das Zertifikat nicht obwohl es in der MS Liste steht. (Amazon Root CA 1)
-
vor 48 Minuten schrieb NorbertFe:
Du kannst natürlich auch deinen Webserver korrekt konfigurieren. ;) Dann mußt du nix löschen.
ich weiß immernoch nicht was damit gemeint ist. um welchen webserver geht es? den bei meinem Provider? den vom Exchange?
-
Naja, das eigentliche PRoblem ist ja nicht vorhanden. Ich bin davon ausgegangen das die Angezeigte Meldung wichtig ist. Sie ist es ja allerdings nicht, da Sur eine Information für den nicht funktionierenden weg darstellt. Somit muss ich auf die GPO Lösung zurückgreifen oder den Eintrag für *.domain.de löschen. (Den Post wo du dies beschreibst, erschien mir allerdings erst jetzt).
-
owa.domain.tld ist die externe Adresse und ex1.domain.tld die interne Adresse. Je nachdem ob er Rechner extern oder intern ist verbindet er sich auch mit diesen Adressen.
Warum das Provider Zertifikat mir diese Probleme macht versteh ich nicht, ganz generell verstehe ich anscheinend nicht worum es in dieser Diskussion geht.
-
okay ich muss mich korrigieren.
internes netz und externes netz bekomen per https://owa.domain.tld/autodiscover/autodiscover.xml Den Fehler 600
https://domain.tld/autodiscover/autodiscover.xml leitet mich auf unserer Website https://www.domain.tld/autodiscover/autodiscover.xml und zeigt einen 404 nothing found here.
https://exchange.domain.tld/autodiscover/autodiscover.xml von intern ist ebenfalls auf Fehler 600
https://exchange.domain.tld/autodiscover/autodiscover.xml von extern zeigt mir: Diese Verbindung ist nicht sicher. SEC_ERROR_UNKNOWN_ISSUER und dann kann ich per Ausnahme das Zertifikat des Providers erlauben.
Und ja der DC ist SSL fähig. IIS ist installiert.
-
Okay ja mit dem SRV haste recht. hab ich schon wieder vergessen.
Ich bemerke das ich intern wie extern ein 600 kriege und kein 404. Heißt das Problem liegt am autodiscover?
Html 600 kann ich als Fehlercode auf anhieb nicht finden. -
Es gab einen SRV Eintrag mit protokoll etc. Habe ihn gegen den A Record autodiscover.domain.tld ersetzt.
Wenn ich https://owa.domain.tld/autodiscover/autodiscover.xml aufrufe bekomme ich:
<Autodiscover><Response><Error Time="14:32:10.9370600" Id="2929850477"><ErrorCode>600</ErrorCode><Message>Ungültige Anforderung</Message><DebugData/></Error></Response></Autodiscover>
Also das was ich erwartet habe.
-
Siehe Post nr.1 es ist ein Zertifikat des Providers. Ich komme aber nicht dahinter warum.
-
Forward Proxies nicht vorhanden wenn man nicht im Netz ist.
Exchange 2016 CU7 (Fehlen also 2)
-
Die Reaktionszeit ist der Hammer =D
Problem tritt bei Outlook 2016 und Outlook 2013 auf. Frisch gepatched oder etwas älter ist dabei egal. Problem tritt direkt auf wenn ich z.b. von internem WLAN auf Gast-Wlan wechsel, oder generell mich nicht in der Domäne (Also Domänennetzwerk) befinde.
Reverse Proxy ist nicht vorhanden. Der Exchange hat ein wildcard Zertifikat für *.domain.tld. Im Outlookverbindungssatus sehe ich ja auch das die Verbindung zu der externen Adressse des Exchange hergestellt wird. Was mich wundert ist warum der interne/FQDN des Servers (Siehe erster Post) angezeigt wird.
Auf der Firewall ist ein NAT eingerichtet welches alle Anfragen von https an die externe Exchnageadresse an den Exchange intern weiterleitet.
VPN Verbindung versucht direkten Login
in Windows 10 Forum
Geschrieben
Weil die Gruppenrichtlinien und die Verbindung zur Domäne beim Windows Logon wichtig sind. Ich hoffe das dadurch ein paar Probleme gelöst werden können.