iDiddi

Dann aktiviere doch mal die Transportprotokollierung, falls noch nicht geschehen. Dann schau Dir die SMTP-Kommunikation an. Dort siehst Du dann ganz genau, was im SMTP-Protokoll ausgehandelt wird und wann ein Abwurf erfolgt. Falls dort nichts aufgeführt ist, dann kam auch nichts an.

Scheint sich ja erledigt zu haben, wuschba. Wäre trotzdem schön, hier das Thema noch abzuschließen.

Danke dmetzger. Auf Google hätte ich aber auch kommen können :o

Scheint ja gar nicht schlecht zu sein. Kann man vielleicht denen empfehlen, die immer noch den Exchange-Pop3-Connector einsetzen :)

Hi Deejoy,

Ich hole die Email mit P2S per Pop3 ab

Tschuldige, aber was ist P2S?

Hat jemand vielleicht eine Ahnung wo ich da nioch suchen kann ?

Schon mal in das Nachrichtenprotokoll geschaut (unter Exch-Tools)? Dort sollten die Nachrichten aufgeführt sein.

Hallo aldisachen,

Ihr werdet doch irgendwo eine Outlook-Installation auf irgendeinem Rechner in der gleichen Domäne haben, oder? Dort soll er sich dann einfach anmelden und Outlook starten. Von dort kann er die alten Mails dann in eine PST-Datei archivieren. Falls er doch noch oft auf diese Nachrichten zugreifen muss, muss er Diese dann halt in einen eigens dafür erstellten öffentlichen Ordner verschieben (man kann natürlich auch extra einen Archivbenutzer mit Postfach anlegen). Auf diesen kann er dann per OWA jederzeit zugreifen ;)

Davon ab, dass ich ich das unschön finde, irritiert mich das auch. Im Übrigen ist dies eine DHCP-Adresse.

Wie kann man das ändern?

Wenn Du IPv6 nicht benötigst, dann schalte es doch einfach ab. Geht über die Registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters]
"DisabledComponents"=dword:0xffffffff

Danach neu starten.

WICHTIG: Falls Du ein SBS2k8 hast, beachte dabei aber unbedingt diesen Artikel, sonst bekommst Du Probleme:

Issues After Disabling IPv6 on Your NIC on SBS 2008 - The Official SBS Blog - Site Home - TechNet Blogs

Hallo Yusuf,

welch Ehre :). Danke für Deine Antwort. Jetzt hab auch ich es verstanden ;)

Aber da hat Microsoft beim SBS2k3 offensichtlich geschlampt. Im SBS2k8 gibts die Gruppenrichtlinie dann auch nicht mehr.

OK. Interessant. Hab noch nie was davon gehört und es so auch nicht gelernt, aber die Links sind eindeutig. Hab aber nicht verstanden, was das jetzt genau für Auswirkungen hat.

Unter anderem überträgt er die Kennworteinstellungen direkt in das Domänenobjekt in Active Directory. Dort kann man sie ohne Zugriff auf die Default Domain Policy direkt auslesen (das Dokumentationswerkzeug José macht sich dies seit Version 3.0 zunutze).

 

Tatsächlich geht dieser Prozess aber noch einen Schritt weiter. Ändert man auf dem PDC-Emulator die Kennworteinstellungen direkt im Domänenobjekt (dem sog. “Domain Head”), so schreibt Windows die Daten zurück in die Default Domain Policy. Dies ist der einzige bekannte Fall, in dem Windows ein GPO ohne direktes Zutun des Administrators inhaltlich verändert.

 

Dieser Umstand hat allerdings Folgen, die u.U. unerwünscht sind. Hat man nämlich die effektive Kennworteinstellung nicht über die Default Domain Policy vorgenommen, sondern über ein eigenes GPO, so berücksichtigt der “Rückwärts-Schreibvorgang” dies nicht. Stattdessen überträgt er die Daten in die Default Domain Policy – offenkundig hartkodiert und ohne Logik zur Prüfung, welches GPO denn tatsächlich entscheidend ist.

Was wird wo wann rückwärts geschrieben? Ich verstehe irgendwie das Problem nicht.

Zu Deutsch: Kennwortrichtlinien gehören in die Standard-Domänenrichtlinie.

Dann frag ich mich aber, warum es z.B. beim SBS2k3 standardmäßig eine Small Business Server Domänenkennwortrichtlinie gibt :suspect: .

Ausserdem habe ich die Default Domain Policy bei allen meinen Kunden kopiert. Habe noch nie Schwierigkeiten damit gehabt. Die Default Domain Policy wurde immer korrekt überdeckt.

Oder ist der SBS hier mal wieder ein Sonderfall?

Also nochmal: Was kann passieren, wenn man so wie ich vorgeht :confused:

Hallo,

dann versuche doch mal eine Testsicherung auf die lokale Platte zu erstellen. Klappt es, ist es definitiv ein Berechtigungsproblem.

Glaube aber das es mit dem Hacken im AD zusammen hängt.

Nein. Den brauchst Du im Normalfall nicht setzen. Und lass die Finger von den Default-Richtlinien. Wenn Du einen Richtlinie ändern musst, dann kopiere diese (Berechtigungen bitte kopieren), benenne Sie um (z.B. Firma-Default Domain Policy) und verknüpfe sie dort, wo auch die Original-Richtlinie verknüpft ist. Nun setze sie einfach in der Reihenfolge eine Position über das Original.

So kannst Du alle Änderungen ganz leicht wieder rückgängig machen, indem Du die Verknüpfung wieder löschst.

Ich hatte Dein Problem vor ein paar Tagen auch. Ich meine, die betreffende Richtlinie ist aber nicht die Default Domain Policy, sondern irgendeine andere (texte morgen, welche genau). Gehe alle nochmals durch und ändere die Kopie wie von dmetzger beschrieben ab.

es war und ist Port 8530.

Ups :o . Ist natürlich 8530.

Stimme dmetzger zu. Würde einfach nochmal neu installieren. Vielleicht stimmen ja die Einträge im IIS nicht mehr oder sonst was.

Definiere "nicht allzu schützenswerte Daten".

Ist schon richtig. Ich meinte auch nur, dass es sich nicht um geheime CIA-Berichte handelt :)

ich würde eine reine anmeldung per "kennwort" durchaus als unsicher(er) ansehen. besser ist natürlich eine zweifaktor authentifizierung.

OK. Aber eine reine Anmeldung in Verbindung mit einem sicheren Kennwort reicht nicht für einen SBS mit 5 Arbeitsplätzen und nicht allzu schützenswerten Daten?

welche Argumente wurden denn in den Quellen angegeben, dass das bordeigene VPN "nicht sicher" sei?

Das ist ja der Grund, warum ich mich an Euch wende. Da gibt es meist nur pauschale Aussagen. Hab jetzt leider keine Quellenangabe. Mein Vorgänger bei einem Kunden hat das z.B. in sein Status-Bericht geschrieben. Und seine sonstige Beurteilung des Netzwerks war eigentlich sehr gut.

PPTP ist ganz gewiss sicherer, da L2TP nichts verschlüsselt ...

Ok. Also, ich interpretiere dann mal: Sicher genug für meine Zwecke :)

OK, das ist ein Argument :D

Dann lass ich es einfach so.

Besten Dank

Ok, Julia.

Zum Thema Sicherheit kannst Du bei Deinem Chef mit dem IPv6-Protokoll aber auch punkten. Ich zitiere einfach mal aus einem Beitrag aus silicon.de (Link hab ich am Ende beigefügt):

...Nicht der schlechteste Grund sind Überlegungen zur Sicherheit. Während bei der ursprünglichen Konzeption von IPv4 die Sicherheit kaum eine Rolle spielte, sondern erst nachträglich implantiert worden ist, waren bei der Planung von IPv6 Sicherheitsaspekte von Anfang an im Zentrum der Überlegungen. Mit dem Sicherheitsprotokoll 'IPSec' (IP Security) wird die IPv6-Kommunikation schon auf der Netzwerk-Ebene 3 abgesichert. Ebene 3 im OSI-Modell ist bekanntlich die so genannte Vermittlungsschicht (Network Layer), die für IP-Pakete eine Leitung zwischen Absender und Empfänger schaltet. Bei IPv4 greifen dagegen viele Sicherheitsmechanismen, beispielsweise die Verschlüsselung, erst auf Netzwerk-Ebene 7 (Anwendungsschicht), wodurch weitaus mehr Spielraum für Einbruchstraftaten gegeben ist...

Und hier der vollständige Beitrag:

IPv6 ist weit sicherer als IPv4 | silicon.de

Danke für Deinen Beitrag, gradma :)

Das sollte natürlich dabei mit berücksichtigt werden. Bei allen Neuanschaffungen in diesem Bereich sollte auf die IPv6-Kompatibilität geachtet werden.

Danke Günther. Das beruhigt mich ein wenig.

Allerdings hat die Firma gar keinen externen DNS-Eintrag. "remote.firma.de" gibt es halt nicht und wird es auch nicht geben. Kann ich denn dann die lokale DNS Forward-Lookup-Zone remote.firma.local einfach löschen (stört mich halt irgendwie :rolleyes: ) oder ist es dann vielleicht besser, wenn ich einfach alles so belasse?

An alle Sicherheitsexperten,

ich betreue einige kleine Firmen und setze dort auf den Windows-eigenen VPN-Dienst Routing & RAS in der Standard-Konfiguration.

Jetzt habe ich schon einige Male gelesen, dass dies nicht sicher sein soll. Trifft das so zu?

Ich lege dafür extra VPN-Benutzer mit beschränkten Rechten und 12-stelligen sicheren PW an. Sollte das nicht reichen?

Danke vorab

Hallo zusammen,

hab folgendes Problem beim Neukunden:

Mein Vorgänger hat diesen Server eingerichtet. Sieht auch ganz gut aus, allerdings hat er wohl im Assistenten, wo man den externen DNS-Namen eingibt, einen Namen in der lokalen Domäne genommen (remote.firma.local) :confused:

Ich weiß nun nicht, ob das irgendwelche Auswirkungen haben kann. Immerhin gibt es jetzt im DNS unterhalb von firma.local einen Untereintrag remote.firma.local :(

Da der Kunden keinen externen Zugriff benötigt (extern gibts halt nur den MX-Eintrag), würde ich alles gerne Rückgängig machen. Hab schon versucht, den Assistenten nochmals auszuführen, kann dort aber nur Dinge ändern, nicht löschen.

Gibt es da Möglichkeiten? Falls nicht, was für Probleme könnte ich durch diesen Schmuh bekommen (beispielsweise mit Exchange, Sharepoint etc.)?

Dieser Beitrag ist Teil des Gewinnspiels "Rette Julia" zur Monatsaufgabe November.

Der Beitrag ist geschlossen, da die Monatsaufgabe November erfüllt wurde.

Mehr dazu: http://www.mcseboard.de/rettejulia.php

__

Hallo Julia,

da die IP-Adressen für IPv4 immer knapper werden, ist es um so wichtiger für ein modernes Betriebssystem, das neue Internet-Protokoll IPv6 zu beherrschen.

Dieses ist jetzt schon fester Bestandteil einiger Microsoft-Technologien (z.B. Heimnetzgruppen).

Und deaktiviere nach Einrichtung einer DaSi die Umlaufprotokollierung. Die Transportprotokollierung würde ich auch noch aktivieren. Gerade für den Anfang. Die Nachrichtenprotokollierung sollte standardmäßig aktiviert sein

Ich würde jetzt noch prüfen, ob es ein reines Explorer-Problem ist. Wenn's ein Netzlaufwerk ist, dann mit cmd in die Freigabe wechseln und ein "dir" abschicken, oder mit ext. Software (TotalCommander und co.)

Sonst hab ich auch keine Idee mehr :(

Alles klar. Dann kann man wohl nichts dran machen. Danke für Deine Antwort :)

Und? Hast Du's hin bekommen?

Ne Rückmeldung wäre schon ganz nett, wenn man Dir schon versucht, zu helfen :(

Und folgender Eintrag ist im Ereignisprotokoll auch wirklich vorhanden?

Ereignistyp:	Informationen
Ereignisquelle:	ESE
Ereigniskategorie:	Protokollierung/Wiederherstellung 
Ereigniskennung:	224
Datum:		03.11.2010
Zeit:		23:58:24
Benutzer:		Nicht zutreffend
Computer:	<EXCH-SERVER>
Beschreibung:
Information Store (3164) Erste Speichergruppe: 
Die Protokolldateien E:\Programme\Exchsrvr\mdbdata\E000E88F.log bis 
E:\Programme\Exchsrvr\mdbdata\E000E907.log werden gelöscht.  

Weitere Informationen erhalten Sie unter 
[url]http://www.microsoft.com/contentredirect.asp[/url].