Beiträge von Stefan12

Alles klar, dann passt das ja :). Wollte eigentlich schon auf 2007 umstellen, jedoch sind da die meisten nicht sehr begeistert von, weil Outlook 2007 ja so anders wäre .
Vielen Dank für deine Bemühungen, du hast mir echt weitergeholfen!

Gruß

Zitat

Natürlich würde das reichen, ist sicherheitstechnisch aber nicht zu empfehlen. Und Du musst daran denken, eventuell die Einstellungen für AutoDiscover, OAB und Verfügbarkeitsdienst anzupassen.

Wieso ist das sicherheitstechnisch nicht zu empfehlen?
Also autodiscover brauche ich ja eigentlich nur, wenn ich will, dass die Outlook 2007 Clients sich automatisch konfigurieren. Das werden wir nicht einsetzen, da wir momentan nur Outlook 2003 benutzen. Also bräuchte ich kein zertifikat für autodiscover.domain.tld.
Was muss denn da bei OAB und Verfügbarkeitsdienst angepasst werden?

Gruß

Eigentlich bräuchte ich doch nur eins oder? Ich kann ja auch vom internen Netzwerk über die externe Domain auf OWA etc. zugreifen, dann würde ja eins für die externe Domain reichen?

Also hauptsächlich geht es um IPhones die ActiveSync nutzen sollen. Wenn das da schonmal geht, da man die Zertifikatsmeldung ignorieren kann, ist das schonmal was . Haben momentan aber auch zum Teil Sony Ericsson Handys die ActiveSync unterstützen, muss ich dann wohl mal Testen ob das da auch klappt. Habe hier grad folgende Info gefunden:
Exchange ActiveSync: Das selbstsignierte Zertifikat kann nicht zum Verschlüsseln der Kommunikation zwischen Microsoft Exchange ActiveSync-Geräten und dem Servercomputer mit Exchange verwendet werden. Es wird empfohlen, ein Zertifikat von einer Windows-PKI oder einem vertrauenswürdigen kommerziellen Drittanbieter für die Verwendung mit Exchange ActiveSync zu beziehen.

Demnach sollte es mit einem Zertifikat der eigenen CA ja eigentlich klappen (http://technet.microsoft.com/de-de/library/bb851554.aspx).

Falls ich ein öffentliches Zertifikat holen würde, müsste ich dabei irgendwas beachten? Gibt ja da verschiedene zu unterschiedlichen Preisen. Würde da ein billiges für ca. 15 € im Jahr reichen? Wie zum Beispiel hier https://www.godaddy.com/gdshop/ssl/ssl.asp das Standard SSL Zertifikat.

Danke für die Infos, nur wie soll ich auf einem gewöhnlichem Handy Zertifikate importieren? Geht doch eigentlich in der Regel nicht. Heißt das um mit den Handys ActiveSync nutzen zu können, müsste ich ein öffentliches Zertifikat kaufen?

Grüße

Danke, jetzt klappt alles. Hatte die Zertifitierungsstellen-Webregistrierung nicht mal installiert .
Braucht man für ActiveSync eigentlich öffentlich vertraute Zertifikate oder reicht dafür auch eins, das man mit einer eigenen Zertifizierungsstelle signiert hat, bzw. selbst signiert hat?
Kennt jemand eventuell ein Tutorial, in dem beschrieben wird, wie man OMA und OWA unter dem gleichen Verzeichnis erreichbar machen kann? Also damit man nicht immer mail.domain.de/owa etc. angeben muss sondern OMA und OWA beide unter mail.domain.de erreichbar sind?

Gruß

Hallo, danke für die Infos. Also ich habe momentan folgendes Problem. Beim Einreichen eines Zertifikates kommt immer folgende Meldung: "Fehler bei der Analyse der Anforderung. Der angeforderte Antragstellername ist ungültig oder zu lang. 0x80094001(-2146877439).
Unter dem Punkt "Fehlgeschlagene Anforderungen" steht als Antragssteller bei den Zertifikaten DOMAIN\Administrator. Bei den gültigen steht DOMAIN\NameDerZertifizierungsstelle.

Weiterhin kommt sobald ich statt "LOCAL" "DE" verwende, also:

Mit folgendem Befehl

New-ExchangeCertificate -GenerateRequest -Path c:\mail_domain_local.csr -KeySize 2048 -SubjectName "c=LOCAL, s=, l=, o=DOMAIN, cn=mail.domain.local"  -PrivateKeyExportable $True

kommt die oben erwähnte Fehlermeldung.
Wenn ich jedoch versuche für mail.domain.de ein Zertifikat auszustellen, kommt folgende:
Die Anforderung enthält keine Zertifikatsvorlageninformationen. 0x80094801(-2146875391) Verweigert vom Richtlinienmodul 0x80094801, Die Anforderung enthält weder die Erweiterung für die Zertifikatsvorlage, noch das Anforderungsattribut "CertificateTemplate".

Das habe ich mit folgendem Befehl getestet:

New-ExchangeCertificate -GenerateRequest -Path c:\mail_domain_local.csr -KeySize 2048 -SubjectName "c=LOCAL, s=, l=, o=DOMAIN, cn=mail.domain.local"  -PrivateKeyExportable $True

Hallo,

ich habe eine Frage zu SSL-Zertifikaten in Bezug auf Exchange 2007.

Ich habe mit folgendem Befehl über die Exchange-PowerShell ein SSL-Zertifikat erzeugt:

New-ExchangeCertificate -GenerateRequest -SubjectName "c=LOCAL, o=DOMAIN, cn=mail.domain.local" -IncludeAcceptedDomains -privatekeyexportable $true -Path c:\domain.local.req

Anschließend an der selbst installierten Zertifizierungsstelle eingereicht und mit

Import-ExchangeCertificate -Path c:\domain.local.cer Enable-ExchangeCertificate -Thumbprint <Fingerabdruck des Zertifikats> -Services IIS

importiert und aktiviert.
Nun habe ich allerdings folgendes Problem. Im internen LAN funktioniert zunächst alles wunderbar. Allerdings soll von extern über eine Domain die von unserem ISP gehostet wird (beispielsweise mail.domain.de) den Mitarbeitern Zugriff auf OWA ermöglicht werden. Da jedoch das Zertifikat für mail.domain.local ausgestellt ist kommt ständig die Warnung, dass das Zertifikat für einen anderen Host ausgestellt wurde. Gibt es eine Möglichkeit ein SSL-Zertifikat für mehrere Hosts / Domains gültig zu machen? (Sprich mail.domain.local und mail.domain.de) oder irgendwelche anderen Lösungsmöglichkeiten für das Problem? Ebenfalls wäre es ganz gut, wenn man beispielsweise auch owa.domain.local aufrufen könnte, ohne dass man eine Zertifikatswarnmeldung erhält.

Liebe Grüße

Ja nur schade, dass ich vorher stundenlang den Fehler suchte. Ich konnte die Benutzerkontensteuerung noch nie leiden^^ Danke euch allen für eure Bemühungen schönen Abend noch.

Gruß

Hallo,
das mit der Benutzerkontensteuerung wird schätzungsweise das Problem gewesen sein. Ich hatte es schon zum Laufen gebracht, allerdings indem ich das Administrator Domänenkonto wieder aktiviert habe und es mit diesem installiert habe. Die Benutzerkontensteuerung würde das Problem natürlich erklären.