soulseeker

So, hier die "Lösung" --- nix hab ich falsch gemacht, zumindest nicht mit dem Zertifikat. Den entsprechenden Dienst hätte ich aber doch mal neustarten sollen. :rolleyes:

Hallo zusammen, ich habe für einen Lync-Server ein neues Zertifikat beantragt - über die MMC mit einem custom request. Ich habe von Globalsign eine cer-Datei zurückbekommen und im IIS "complete certifikate request" gewählt. Dann erscheint das Zertifikat auch im Store (mmc-certificates-computer-personal) und ich kann es anschließend mit privatem Schlüssel exportieren. Wenn ich diesen Key aber auf meinem Lyncedge-Server importiere, startet ein Service nicht und bringt die Meldung: PrivateKey not accessible ... dadurch funzt der ganze Edge-Dienst natürlich nicht richtig. Jetzt frage ich mich zum einen, ob der private Key evtl. nicht zum öffentlichen Schlüssel passt, bzw. ob ich einen Fehler beim "complete cert req" gemacht habe... ich habe nämlich, weil ich etwas testen wollte, noch einen zweiten Request mit der mmc erzeugt, aber ich finde weder den alten, noch den neuen pending request. Da ich über den IIS "complete certificate request" gewählt habe, kann ich davon ausgehen, dass dieses Zertifikat grundsätzlich richtig eingebunden wurde? Wie finde ich überhaupt meine pending requestst? In der mmc zumindest nicht unter certificate enrollment requests ... Viele Grüße Marcel

Mit dem Powershell-Script auf dieser Seite bzw: ist nun alles scheinbar ok ...

Ich habe gerade in der Shell geprüft, wie die Rechte vergeben sind - Accept any Sender/Recipient ist zum Glück nicht aktiv.

Nur mal so zur Info - ich denke es ist das Problem, was hier beschrieben wird: http://superuser.com/questions/120038/changing-network-type-from-unidentified-network-to-private-network-on-an-openvpn Ich teste das gerade.

OK ich hatte das so verstanden, dass ich einen offenen relay habe wenn ich auf dem default connector mehr als anonymous aktivieren. Das mit dem zusätzlichen Recht war mir nicht so recht klar. Danke euch!

Hallo zusammen, ich hab mich eine Weile nicht mehr mit Exchange beschäftigt und muss feststellen, dass ich mit den Konnektoren ein kleines Verständnissproblem habe. Es gibt ja standardmäßig nach dem Setup erst einmal zwei Empfangskonnektoren namens client und default "client" ist doch wie der Name sagt für die Mailannahme der clients zuständig und sollte soweit ich das sehe nur Exchange users in den Permission groups haben. Ich habe gerade allerdings entdeckt, dass alles außer "Partners" dort aktiviert ist. "default" sollte für die Annahme aus dem WWW oder popcon u.ä. dienen und damit das funzt, sollte "anonymous" aktiv sein, damit der Exchange auch Mails von externen Usern annimmt. Das ist so auch konfiguriert mit einer entsprechenden IP-Range (nämlich alles). Jetzt würde mich mal interessieren, ob das so grundsätzlich korrekt ist. Auf dieser Seite steht nämlich z.B. geschrieben, dass man durch das Erlauben von anonymous auf default einen offenen Mail-Relay produziert: http://www.frankysweb.de/exchange-2010-standardeinstellungen-fr-die-empfangsconnectoren/ Ist das wirklich so? Ich dachte eigentlich, damit nach außen relayed werden kann und man zur Spamschleuder wird, muss "externally secured" im Konnektor angehakt sein und man muss "vergessen" den Konnektor auf bestimmte gewünschte IPs zu beschränken ? Danke für eure Anregungen :) Marcel

Bei mir erscheint sofort Domänennetzwerk ... bei den Usern sehe ich nur den "Windows-Kreisel".

Hi, die Routen werden korrekt gesetzt, ich kann ja auch alle Ressourcen per IP-Adresse erreichen. Ich habe Routen auf der Firewall eingetragen, die der Client nach der Einwahl erhält. Der restliche Webtraffic wird zum Standard-GW des externen Clients gesendet. In der Watchguard wird nichts geblockt, wenn, dann wohl eher die Win-Firewall ... Keines, man sieht im Fehlerfall nur den typischen Win7-Kreisel ... einige User berichteten allerdings, dass es nach ca. 10 Minuten ab und an mal geht. Dummerweise kann ich es nicht nachvollziehen, auf meinem Notebook, dass komplett identisch installiert ist, klappt es.

Hallo, ich habe ein merkwürdiges Problem. Und zwar benutzen wir den OpenVPN-Client von Watchguard und auf einigen Notebooks funktioniert das wunderbar, bei anderen Notebook verbindet sich der Client zwar, aber ich kann keine internen Ressourcen erreichen ... nslookup hostname gibt allerdings die IP-Adresse, insofern funzt also die Namensauflösung. ping hostname geht allerdings nicht raus, nur per IP-Adresse. Mir ist aber aufgefallen, dass der virtuelle TAP-Netzwerktreiber nach der Verbindung seinen Netzwerk-Typ bei einigen Clients nicht ändert, normalerweise sollte der bei einer aktiven Verbindung als Domänen-Netzwerk eingetragen sein. Bei den funktionierenden Clients klappt das jedoch problemlos. Die Reihenfolge der Netzwerk-Treiber habe ich schon geprüft, auch die Netzwerk-Komponenten neuinstalliert. Woran kann das liegen? Gruß Marcel

Also in der Prod-Domäne sind nur sichere Updates erlaubt, in der dev.-Domäne sichere und unsichere. Bei beiden ist unter advanced/credentials ein DNS-User eingetragen, der nur Mitglied der Gruppe der Domainbenutzer ist. Ansonsten habe ich derzeit im DHCP "Enable DNS dynamic updates according to the setting below" aktiv und dort derzeit ""Dynamically update DNS A and PTR records only if requested by the DHCP clients " ... vorher war "Always dynamically update DNS A and PTR Records"-

Hallo zusammen, wir haben eine Produktiv-Domäne mit zwei Win2008 R2-DCs und eine Develop-Domäne mit einem Win2008 R2 und "einseitiger" Vertrauensstellung (d.h. develop vertraut produktiv). Seit einigen Monaten kommt es unregelmäßig immer wieder mal dazu, dass einzelne A-Records von Workstations oder auch Servern einfach so verschwinden ... nur der ipv6-Eintrag bleibt noch bestehen. Das passiert gefühlt öfters in der develop-Umgebung, wo jede Menge Testserver laufen. Aber gestern war auch ein Produktiv-Server "weg". Da kann ich mir aber ganz gut vorstellen, dass es in diesem Fall an einem Netzwerk-Problem gelegen hat, da dieser Server nach einem Switch-Ausfall kurzfristig in einem anderen Netz/vlan gelandet ist. Ist aber auch mit einigen Testservern aus der dev-Domäne schon passiert. Ich habe mal ein wenig gegoogelt und das hier gefunden: Hatte jemand von euch dieses Problem schon einmal? Replikationsfehler oder bemerkenswerte Fehler im eventlog sehe ich übrigens nicht. Ich löse das Problem ansonsten immer per ipconfig /registerdns ... aber das ist ja dauerhaft keine Lösung. VG Marcel

Hi@all, ich versuche gerade, Lync über die Watchguard zu veröffentlichen um unseren TMG zu ersetzen ... dazu ist es u.a. notwendig, von außen 443 zu einem internen Server zuzulassen, aber dazu muss man diesen Port auf 4443 umzubiegen, da darauf der Listener auf dem internen Server horcht. Ich habe also auf der Watchguard eine Rule erzeugt mit SNAT + Set internal port to different port from: WAN-IP (für Lync) to: WAN-IP (für Lync) -> interne IP des Frontend-Servers : 4443 Allowed Ports: 443 Leider kann ich den Port von außen nicht antelnetten ... telnet ip 443 -> keine Verbindung Wenn ich 4443 noch zu den allowed ports hinzufüge, hab ich sofort eine Verbindung ... also setzt die Firewall den Port nicht um. Hat jemand eine Idee, warum nicht? Die Watchguard-Logs zeigen keinen geblockten Traffic an. VG Marcel Ok, Fehler gefunden ... ein Zahlendreher, wie sollte es anders sein ...

Die letzte Antwort habe ich irgendwie übersehen, sorry. Das Problem habe ich allerdings immer noch, jedoch stellt es sich doch etwas anders dar. Um es nochmals zu verdeutlichen - am Hauptstandort klappts mit Radius-Authentifizierung. Von einem anderen Standort hinter einem VPN-Tunnel auch. Bei einem weiteren Standort (gleiche Firewall, auch mit VPN-Tunnel) jedoch nicht. Dort erscheint die FM: Es gibt aber natürlich eine Network Policy, in der nur geprüft wird, ob der User in einer bestimmten Gruppe ist. Aber diese Policy wird hier scheinbar gar nicht benutzt. In der Connection policy steht habe ich eingetragen: NAS Port Type Ethernet or Wireless Der einzige Unterschied zwischen den Standorten: bei dem einen (funktionierenden) Standort ist eine Fritzbox im "DMZ-Modus" vor der Hardware-Firewall mit einem Transfernetz, das alles zur Firewall weiterleitet, bei dem anderen Standort ist es eine Vodafone Easybox, ebenfalls mit DMZ. Ich habe natürlich zunächst diese Box im Auge gehabt, aber mit einem Radius-Test-Tool (NTradping) kann ich mich problemlos authentifizieren ... also sollte es eigentlich nicht an geblockten Paketen etc. liegen. Was ich seltsam finde - der Eintrag User:Security ID: domain\NPC047$ ... hier wird kein Username eingetragen, sondern der Hostname des Notebooks. Vielleicht hat ja noch jemand eine Idee ...

Ok, so ist es bereits konfiguriert ... zwei DCs in der Zentrale, beide sind GC, aber nur einer hat alle FSMO-Rollen. Ich dachte halt, dass es grundsätzlich eine gute Idee ist, die Rollen zu verteilen. Bei dem Thema gibt's bei mir scheinbar noch etwas Lernbedarf. Ich denke hiermit komme ich ganz gut weiter: http://www.faq-o-matic.net/2010/09/09/ad-betriebsmaster-ausfall-was-tun/ http://www.mcseboard.de/topic/174527-best-practices-fsmo/ Danke!

Hallo, wir haben einen Hauptstandort mit zwei externen Offices, die per Tunnel angebunden sind ... an einem der Standorte möchte ich gerne einen DC bereitstellen, in erster Linie, damit dort ein eigener DNS-Server steht und natürlich auch zur Ausfallsicherheit. Jetzt frage ich mich aber, was "best practise" bei der Vergabe von FSMO-Rollen ist für externe Standorte ist. Also anders gefragt - welche Rollen sollte ein "externer" DC am besten halten. Vermutlich ja nicht alle, um nicht unnötigen Replikationstraffic zu erzeugen. Kann ich auch für externe Standorte nach diesem Schema verteilen (http://www.sole.dk/how-to-place-fsmo-and-global-catalog-roles-in-active-directory/), oder gilt das nur für DCs am gleichen Standort? Danke für euren Input :) Marcel

Hallo zusammen, ich habe hier ein merkwürdiges Problem mit meinem Radius-Server + WLAN-Authentifizierung. Intern funktioniert alles, auch aus einem anderen per VPN-Tunnel angebundenem Office kann der Accesspoint den Radius-Server kontaktieren und den User am WLAN authentifizieren. Aus einem anderen Branch Office jedoch nicht, obwohl beide identisch konfiguriert sind. Das VPN wird über Watchguards abgebildet, zwischen den Tunnelendpunkten ist alles an Traffic erlaubt und ich sehe auch keine denys. Im Security-Log des Radius-Servers finde ich jedoch folgende Einträge: Also zunächst mal wundert mich, warum der Network policy name "Connections to other access servers" verwendet wird, da ich eine eigene namens "Secure WLAN" habe. Die Dial-in-Properties des Users sind auch nicht auf deny gesetzt ... Vermutlich nur eine Kleinigkeit, aber ich finde es einfach nicht ;). Radius-Clients mit dieser IP-Range gibt es auch. Danke für Hilfe und Grüße Marcel

Gerade hab ich von Kabel DE die Info bekommen, dass der Backbone in unserem Gebiet total überlastet ist und bis Mai ausgebaut werden soll. Das sei aber nur der Plan, ob das was wird konnte man noch nicht sicher sagen. Der Hotliner riet mir dann dazu, den Vertrag erst einmal wieder zu stornieren. Zumindest sind sie ja ehrlich ...

Hmm mal schauen ... ich habe den Router nun als Modem umkonfiguriert aber der Tunnel verabschiedet sich trotzdem alle paar Stunden. Dazu kommt noch - Kabel Deutschland hat uns eine feste IP zugesagt, aber die gibts dort gar nicht, auch für Business-Kunden nicht. Dyndns ist ja auch nicht mehr für lau :(. Ich denke ich werde den Vertrag wiederufen, Vodafone ist zwar langsamer, aber die Verbindung stabiler.

Ok danke ... ich habe gerade herausgefunden, wie ich dieses Teil in den Bridge-Modus versetzen kann - das macht man remote über eine Kabel-Deutschland Webseite, sehr komfortabel :(. Derzeit hat der Router sein eigenes Netz, durch das alle Pakete und Protokolle durchgeschleust werden ... wenn das wegfällt, wäre das sicher eine Störquelle weniger.

Hallo zusammen, ich habe einen Hauptstandort, dort angebunden sind zwei kleinere Standorte per IPsec-Tunnel (Phase1 SHA1-3DES, Phase2 ESP-AES-SHA1) An beiden Außenstandorten haben wir Kabel-DSL mit einem Router, dahinter sind jeweils Watchguards, die die Tunnel verwalten. An Standort 1 läuft der Datenverkehr über die Tunnel ohne Probleme - sieht man sehr schön am VOIP-Datenverkehr, der weitgehend jitterfrei ist. Am Standort 2 ist die Performance aber äußerst mies, seitdem wir dort von Vodafone-DSL auch auf Kabel umgestellt haben. Sobald man die Tunnel neu aufbaut, sind die ping-Anwortzeiten erst ok, werden dann aber immer mieser bis >1000 ms. Das WAN-Interface ist aber vom ping her immer ok. Ich habe als erstes die MTU-Größe verdächtigt und mit ping x.x.x.x -f -l MTU-Wert herausgefunden, dass ich bis 1394 verwenden kann ... mit dieser Info habe ich den MTU-Wert der Watchguard geändert (zuerst auf 1400) und sofort wurde der Ping besser, aber nach einigen Minuten wird der Wert immer wieder schlechter. Ich habe testweise dann sogar verschiedene Werte zwischen 1200-1350 ausprobiert, aber es passiert immer wieder das gleiche - erst ok, danach immer schlecht. Ich habe den Billig-Router vor der Firewall im Verdacht, da das aber ein Kabelmodem/Router ist, habe ich derzeit keine Möglichkeit, einen anderen zu testen. Was meint ihr dazu? Oder sollte ich mal mit anderen Tunnel-Verschlüsselungen testen? Grüße Marcel

Hallo zusammen, ich habe vor kurzem Watchguards in unseren Firmenstandorten verteilt und noch ein kleines, aber unschönes DNS-Problem beim SSL VPN-Client. Wir haben für einige hostnamen sowohl intern als auch externe DNS-Einträge. Bei den meisten mobilen Clients funktioniert die DNS-Auflösung korrekt, d.h. ist der Client nicht im VPN fragt er den DNS seines Providers (und man landet auf unserem Access Gateway), ist er per VPN eingewählt, dann wird der Hostname über den firmeninternen DNS-Server aufgelöst. Ich habe nun allerdings ein paar hartnäckige Win8-Rechner, die nach der Einwahl ins SSL VPN trotzdem den DNS-Server des Providers als höchste Prio verwenden ... mit ipconfig /flushdns kann man das Problem zwar einmal, aber nicht dauerhaft lösen. Ich würde gerne die Reihenfolge des Netzwerkadapters ändern, aber in der Netzwerkumgebung taucht der "tap driver" (das ganze ist wohl openvpn basierend) nicht auf und auch unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage finde ich keinen Eintrag der zum Watchguard-VPN-Adapter passt. Kennt jemand dieses Problem? LG Marcel Hat sich erledigt, hab den Adapter gefunden :) ... war die ganze Zeit da, ich hab nur drumherum gelesen. Manic monday ...

Hi Daniel, Danke! Auf den Useraccount bin ich gestern auch gekommen, ich habe einen eingetragen und seitdem tauchen wieder PTR-Einträge auf. Im DHCP-Server ist aktiviert "enable DNS dynamic updates according to the settings below" und "always dynamically update DNS A and PTR records". Mir ist heute allerdings ein weiteres Problem aufgefallen ... bei einigen hosts "verschwindet" der IPv4-Eintrag und ich sehe nur noch den IPv6-Eintrag ... beheben kann ich das Problem nur, indem der Client sich mit ipconfig /registerdns neu registriert. Wie kann es denn dazu kommen?

Hallo Forum, ich haben mal wieder eine Frage. Und zwar ist mir folgendes aufgefallen: Wir haben hier einen Core-Switch mit diversen VLANS und entsprechendem Routing, als DHCP-Server nutzen wir einen 2008R2-DC. Auf dem DHCP-Server sind verschiedene Scopes definiert und die entsprechenden Clients erhalten auch ihrem Netzwerk-Segment entsprechende IP-Adressen. Was allerdings nur bedingt funktioniert, ist der reverse Lookup. Für das 0.x-Netzwerk, in dem auch der DHCP-Server liegt, werden (meist) entsprechende PTR-Einträge erstellt. In den anderen reverse Lookup-Zonen tut sich jedoch (meist) nichts, außer in einem Fall, wo ich zwei IP-Adressen fest vergeben habe ... die Zonen sind jedoch alle gleich eingerichtet. Ich bin mir auch nicht sicher, ob das mit den beiden IP-Adressen jetzt nur Zufall war. Hat da jemand eine Idee? Grüße Marcel

Falls es jemand interessiert - ich habe das Problem so gelöst, dass ich dem Exchange als Standard-GW den TMG gegeben habe und zusätzlich (Rück)routen für die Clients hinterlegt habe. So versendet der Exchange alles was er nicht kennt wieder über den TMG und die Clients können sich trotzdem noch am Exchange anmelden.