none
Exchange Zertifikat Sicherheitshinweis RRS feed

 > 

  • Allgemeine Diskussion

  • Discussion
    Anmelden
    0
    Anmelden

    Hallo,

    nachdem ich ein neues öffentliches Zertifikat im IIS hinzugefügt habe und auf den Exchange-Servern die Outlook Anywhere Adressen ausgetauscht habe, erscheint beim Start von Outlook immer 2x die Meldung "Sicherheitshinweis" dann die interne Adresse des Servers sprich "server1.do.local" "Der Name auf dem Sicherheitszertifikat ist ungültig oder stimmt nicht mit dem namen der Webseite überein" wenn ich auf Zertifikat anzeigen klicke, steht bereits das neue öffentliche Zertifikat in "Ausgestellt für" ... der Server versucht also für den internen Namen das externe Zertifikat zu verwenden.

    Das Selbe dann mit "server2.do.local" ... 

    Zum Schluss kommt dann noch einmal die Kennwortabfrage / die meist erst nach 2 bis 3 mal versuchen klappt und auch nicht gespeichert wird ... beim nächsten Neustart von Outlook kommt wieder eine Kennwortabfrage trotz "Anmeldedaten speichern".

    Kann mir hier jemand helfen? Vielen Dank!


    Donnerstag, 4. September 2014 10:32
    |

Alle Antworten

  • Discussion
    Anmelden
    0
    Anmelden

    Noch zur Info ... ich hab auch den Sendeconnector FQDN

    auf den offiziellen Namen umgestellt.

    Donnerstag, 4. September 2014 10:53
    |
  • Discussion
    Anmelden
    1
    Anmelden

    Hi xxx,

    warum änderst du das Cert ium IIS? Du macht alles in der Console bzw. der Shell.

    Welcher Dienst ist welchem Service zugeordnet, welche Certs kennt Exchange und welchen setzt du überhaupt ein?

    Get-ExchangeCertificate

    Enable-ExchangeCertificate

    Viele Grüße

    Christian

    Donnerstag, 4. September 2014 11:48
    |
    Moderator
  • Discussion
    Anmelden
    0
    Anmelden

    Hi Christian,

    danke für deine schnelle Antwort! 

    Hatte wohl eine falsche Anleitung im Internet gefunden und das Cert im IIS ausgetauscht. Kenn mich leider noch nicht so gut aus (bin 15).

    Unter Server/Zertifikate werden mir 4 angezeigt

    Das neue öffentliche (Dienste IMAP, POP, IIS, SMTP)

    Microsoft Exchange (Dienst SMTP (ausgestellt von Server2))

    Exchange Delegation Federation (Dienste SMTP, Federation (ausgestellt von Federation)

    WMSVC (Keine Dienste (Ausgestellt von WMSvc-Server2)

    Nochmals vielen Dank für deine Hilfe!

    Schöne Grüße

    Stefan

    Donnerstag, 4. September 2014 12:41
    |
  • Discussion
    Anmelden
    1
    Anmelden

    Hi Stefan, 

    das sieht eigentlich soweit ganz gut aus. Du kannst ja zur Sicherheit an dieser Stelle versuchen, das Zertifikat nochmal allen Diensten zuzuweisen und als Standardzertifikat zu hinterlegen. Dümmstenfalls kommt halt eine Fehlermeldung.

    Ansonsten solltest Du auch mal die URLs der ganzen virtuellen Verzeichnisse überprüfen (unter Serverkonfiguration, da kannst Du die URLs für OWA, EWS, ActiveSync anpassen; für Autodiscover musst Du die Powershell bemühen: Set-AutodiscoverVirtualDirectory -InternalUrl https://<Dein Server>/Autodiscover/Autodiscover.xml -ExternalUrl <Noch mal das gleiche>)

    Wichtig: die jeweiligen Links müssen zu dem Namen passen, den Du im Zertifikat hast!

    Gruß
    Ben
    MCITP Windows 7

    Wenn Dir meine Antwort hilft, markiere sie bitte entsprechend als Antwort! Danke! :-)

    Hinweis: Meine Posts werden "wie besehen" ohne jedwede Gewähr bereitgestellt, da menschliche, technische und andere Fehler nicht ausgeschlossen werden können.

    Donnerstag, 4. September 2014 15:19
    |
  • Discussion
    Anmelden
    2
    Anmelden

    Hi Stefan, 

    ; für Autodiscover musst Du die Powershell bemühen: Set-AutodiscoverVirtualDirectory -InternalUrl https://<Dein Server>/Autodiscover/Autodiscover.xml -ExternalUrl <Noch mal das gleiche>)

    Wichtig: die jeweiligen Links müssen zu dem Namen passen, den Du im Zertifikat hast!

    Gruß
    Ben

    Diese Legende stirbt auch nie aus.. Das ist schlicht falsch, die Autodiscover URL setzt du per Set-Clientaccessserver -AutoDiscoverServiceInternalUri "Https://<Server oder LBname>/Autodiscover/Autodiscover.xml"

    Dadurch wird der SCP in der Configuration Partiton gesetzt den alle domain-joined Clients abfragen. Nicht domain- joined Clients nutzen dann die üblichen Autodiscover Records (entweder als SRV Record oder direkt als Hostrecord)

    http://blogs.technet.com/b/rmilne/archive/2013/04/02/busting-the-set-autodiscovervirtualdirectory-myth.aspx

    Grüße

    Jörg

    Donnerstag, 4. September 2014 17:41
    |
  • Discussion
    Anmelden
    1
    Anmelden

    Hallo Stefan,

    mit 15 muss ja jemand sehr viel Vertrauen haben, um eine unternehmenskritische Anwendung in deine Hände zu geben.

    Wie Ben und Jörg beschrieben haben, sind die URLs enorm wichtig und daher die Frage, welche im Namen hinterlegt sind. Ist dort nur der externe Name hinterlegt, musst du noch eine Dinge anpassen.

    Hier mal eine Anleitung, um mit einem Namen zu arbeiten:

    http://blog.cohesivelogic.com/exchange-2010-single-name-ssl-certificates

    Wir wissen noch gar nicht, welche Exchange-Version du einsätzt...

    Viele Grüße

    Christian

    Freitag, 5. September 2014 04:18
    |
    Moderator
  • Discussion
    Anmelden
    0
    Anmelden

    Hi Jörg,

    das wusste ich noch gar nicht, vielen Dank für den Link! Es stellt sich dann natürlich die Frage, warum Microsoft das im eigenen TechNet anders schreibt und es dann die Möglichkeit zur Konfiguration überhaupt gibt, wenn das völlig nutzlos ist...

    Anyway...

    Gruß
    Ben
    MCITP Windows 7

    Wenn Dir meine Antwort hilft, markiere sie bitte entsprechend als Antwort! Danke! :-)

    Hinweis: Meine Posts werden "wie besehen" ohne jedwede Gewähr bereitgestellt, da menschliche, technische und andere Fehler nicht ausgeschlossen werden können.

    Freitag, 5. September 2014 07:15
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Gerne gerne... ;>

    Wenn man sich aber die Technet Einträge zu Set-AutodiscoverVirtualDirectory anschaut, dann steht dort auch das die Parameter InternalURL und ExternalURL für die Verwendung von MS reserviert sind.

    Freitag, 5. September 2014 07:54
    |
  • Discussion
    Anmelden
    0
    Anmelden
    Was auch immer das heißt... ich hab bei anderen Befehlen auch schon Parameter gehabt, die "für MS reserviert" sind, aber eingestellt werden konnten (d.h. die Änderung wurde auch ohne Eingriff von MS angenommen). ;-)

    Gruß
    Ben
    MCITP Windows 7

    Wenn Dir meine Antwort hilft, markiere sie bitte entsprechend als Antwort! Danke! :-)

    Hinweis: Meine Posts werden "wie besehen" ohne jedwede Gewähr bereitgestellt, da menschliche, technische und andere Fehler nicht ausgeschlossen werden können.

    Freitag, 5. September 2014 07:57
    |
  • Discussion
    Anmelden
    0
    Anmelden
    Heißt normalerweise außerhalb der MS eigenen Umgebungen funktioniert der Parameter nicht. Und für Exchange wüßte ich z.B auch keinen. Gibt ja z.B auch ein paar andere Attribute die zwar vorhanden sind, aber keine Funktion haben z.B msTSHomeDirectory
    Freitag, 5. September 2014 08:22
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Vielen Dank für eure Hilfe!!!

    @Ben: Hab jetzt die alle virtuellen Verzeichnisse angepasst.

    @Jörg: Bei Set-Clientaccessserver -AutoDiscoverServiceInternalUri "Https://offiziellername.do.local/Autodiscover/Autodiscover.xml" bekomme ich immer folgende Eingabeaufforderung Geben Sie Werte für die folgenden Parameter an: Identity:

    @Christian: Sind ja nur meine Server Zuhause (hier sind max. 6 Familienmitglieder betroffen) ;-) Server1= Exchange 2010 (14.3) Server2= Exchange 2013 (15.0)

    Hab alles nach Anleitung http://blog.cohesivelogic.com/exchange-2010-single-name-ssl-certificates durchgeführt (auf dem neuen Exchange 2013)  bekomme ich bei dem Befehl:

    Get-ClientAccessServer | Set-ClientAccessServer -AutodiscoverServiceInternalUri "https://öffentlicher_und_interner_fqdn/Autodiscover/Autodiscover.xml"

    folgende Fehlermeldung:

    Diese Änderung kann nicht vorgenommen werden, da 'CN=Server1(alt),CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=do,DC=local' für die aktuelle Version von Exchange schreibgeschützt ist.
        + CategoryInfo          : InvalidOperation: (:) [Set-ClientAccessServer], CannotModifyCrossVersionObjectException
        + FullyQualifiedErrorId : 1CD237E5,Microsoft.Exchange.Management.SystemConfigurationTasks.SetClientAccessServer
        + PSComputerName        : server2(neu).do.local

    und bei dem Befehl:

    Get-ActiveSyncVirtualDirectory -Server $CASserver | Set-ActiveSyncVirtualDirectory -InternalUrl "https://öffentlicher_und_interner_fqdn/Microsoft-Server-ActiveSync" 

    folgende Fehlermeldung:

    Das Argument kann nicht an den Parameter "Server" gebunden werden, da es NULL ist.
        + CategoryInfo          : InvalidData: (:) [Get-ActiveSyncVirtualDirectory], ParameterBindingValidationException
        + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Get-ActiveSyncVirtualDirectory
        + PSComputerName        : server2(neu).do.local

    Wenn ich die folgenden Abfragen ausführe, stimmen aber alle Einträge:

    Get-AutodiscoverVirtualDirectory | ft Identity,InternalURL,ExternalUrl
    Get-webservicesVirtualDirectory | ft Identity,InternalURL,ExternalUrl
    Get-OabVirtualDirectory | ft Identity,InternalURL,ExternalUrl
    Get-OwaVirtualDirectory | ft Identity,InternalURL,ExternalUrl
    Get-EcpVirtualDirectory | ft Identity,InternalURL,ExternalUrl

    Get-ActiveSyncVirtualDirectory | ft Identity,InternalURL,ExternalUrl

    Nun kommt auch keine Kennwortabfrage mehr :-), die Zertifikatsmeldungen sind aber noch da (hab schon bei verschiedenen PCs probiert und das Profil auch schon neu im Outlook angelegt), Hat jemand eine Idee?

    Noch zur Info: Server1 (Exchange 2010 war lange der Hauptexchange, hab vor einigen Monaten den 2. Exchange (2013) hinzugefügt und die Postfächer auf den neuen migriert / hab mich den alten aber noch nicht aus dem Netz hängen getraut, wo ich das das letzte Mal gemacht habe, hat nicht mehr richtig funktioniert und ich hab auf den ESX Servern die Snapshots wiederhergestellt und den neuen Exchange noch einmal neu installiert und neu in die Domäne eingebunden / war also alles auf Anfang. Falls mir also noch jemand sagen könnte, wie ich den alten Exchange am besten entferne, wär das auch klasse (Postfächer hab ich natürlich inzwischen wieder auf den neuen Server migriert).

    Nochmals vielen Dank für eure Hilfe!

    Grüße Stefan
    • Bearbeitet MyMays Freitag, 5. September 2014 18:45
    Freitag, 5. September 2014 18:42
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hi Stefan,

    die Abfrage "Identity" kommt, weil Exchange wissen will, welcher Server angepasst werden soll. Ändere den Befehl so ab:

    Get-ClientAccessServer | Set-ClientAccessServer... (Deine Parameter wie oben)

    Der Fehler bei Set-ActiveSyncVirtualDirectory kommt wahrscheinlich daher, weil Du als Servernamen die Variable $CasServer verwendest, aber die nirgendwo deklariert hast...? Den Befehl könntest Du ähnlich umbauen:

    Get-ClientAccessServer | Get-ActiveSyncVirtualDirectory | ... (deine Parameter wie oben)

    Diese URLs kannst Du zur Not aber auch in der Verwaltungskonsole ändern.

    Bzgl. des alten Exchange: einfach mit dem Domänenadministrator komplett deinstallieren, dann sollten auch alle Einträge im AD verschwinden. Einfacher geht's fast nicht mehr. :-) Den Server selbst zum Schluss noch aus der Domäne nehmen, bevor Du ihn endgültig löschst. Und lass Dir damit am Besten noch 1 Tag Zeit, falls irgendwelche Probleme auftreten sollten.

    Gruß
    Ben
    MCITP Windows 7

    Wenn Dir meine Antwort hilft, markiere sie bitte entsprechend als Antwort! Danke! :-)

    Hinweis: Meine Posts werden "wie besehen" ohne jedwede Gewähr bereitgestellt, da menschliche, technische und andere Fehler nicht ausgeschlossen werden können.

    Sonntag, 7. September 2014 18:15
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo,

    ich habe ein sehr ähnliches Problem auf einem SBS2011 mit Exchange 2010. Unsere Outlook Clients erhalten folgende Warnhinweise beim Outlook-Start.

    Anklicken, um das Original-Bild in einem neuen Fenster zu sehen

    Wir haben zwar kein Problem mit Passwortabfragen gehabt, aber ansonsten ist das doch das gleiche Problem, oder? Wir erhalten auch die Meldung, dass der CAS Eintrag nicht verändert werden kann, da es sich um eine ältere Version von Exchange handelt und daher schreibgeschützt ist.

    Das Problem wurde bei uns von einer SBS Vorversion übernommmen. Den alten Server können wir leider nicht mehr starten.

    Hast Du eine Möglichkeit gefunden den CAS Eintrag zu verändern, bzw. zu entfernen?

    danke!

    Montag, 9. Februar 2015 15:29
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo,

    ich habe ein sehr ähnliches Problem auf einem SBS2011 mit Exchange 2010. Unsere Outlook Clients erhalten folgende Warnhinweise beim Outlook-Start.

    Anklicken, um das Original-Bild in einem neuen Fenster zu sehen

    Wir haben zwar kein Problem mit Passwortabfragen gehabt, aber ansonsten ist das doch das gleiche Problem, oder? Wir erhalten auch die Meldung, dass der CAS Eintrag nicht verändert werden kann, da es sich um eine ältere Version von Exchange handelt und daher schreibgeschützt ist.

    Das Problem wurde bei uns von einer SBS Vorversion übernommmen. Den alten Server können wir leider nicht mehr starten.

    Hast Du eine Möglichkeit gefunden den CAS Eintrag zu verändern, bzw. zu entfernen?

    danke!

    Hallo,

    eigentlich sollte es reichen wenn du in der SBS Konsole unter Netzwerk -> Konnektivität -> auf "Beheben von Netzwerkproblemen" klickst.

    Sonst sieh mal nach wenn du in dem Fenster auf "Zertifikat anzeigen" klickst was im Zertifikatsnamen steht

    Falls das nichts geholfen hat, halte mal bei geöffnetem Outlook die STRG-Taste gedrückt und klicke mit der rechten Maustaste auf das Outlook Icon rechts unten.
    dann auf "E-Mail Autokonfiguration testen" - dann siehst du die internen/externen URLs, wenn dort noch andere URLs sind als der Host welcher im Zertifikat steht, dann musst du dies manuell berichtigen.

    Montag, 9. Februar 2015 17:44
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Klein-IT,

    es ist immer schlecht, sich an einen älteren Beitrag anzuhängen, vor allem, wenn der schon Status Diskussion hat.

    Ich würde an deiner Stelle einen neuen Beitrag öffnen und auf diesen verweisen.

    Dein Problem tritt sehr oft beim SBS auf, da dort sehr viele Dinge von den Assistenten anders gemacht werden als üblich.

    Du brauchst eigentlich nur das Zertifikat neu / richtig ausstellen und die URL anpassen.

    Der SBS installiert per Default eine Root-CA mit, damit musst du das Zert ausstellen - besser noch, von extern signiert.

    Dann wie bereits beschrieben die URL anpassen, fertig.

    ;)

    Gruß Norbert

    Dienstag, 10. Februar 2015 07:22
    |
    Moderator
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo und danke für die Antwort.

    "Beheben von Netzwerkproblemen" hatten wir auf der alten Maschine (war noch ein SBS08) schon probiert, leider ohne Erfolg. Habs gerade auf dem SBS2011 nochmal durchlaufen lassen, es konnte ein Problem behoben werden, ein DNS - A Eintrag...

    Der Zertifikatsname ist unsere öffentlich IP Adresse - das ist wahrscheinlich Ursache des Problems, da hier eigentlich remote.xxx.xxx stehen sollte! Wir haben aber keine Ahnung, was dieses Verhalten verursacht hat, es kam "aus dem Nichts".

    Die gepostete Fehlermeldung kann einfach weggeklickt werden, der Server und die Outlook Clients funktionieren einwandfrei.

    Freitag, 13. Februar 2015 13:47
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo und danke für Deine Antwort!

    Zitat:

    Du brauchst eigentlich nur das Zertifikat neu / richtig ausstellen und die URL anpassen.

    Der SBS installiert per Default eine Root-CA mit, damit musst du das Zert ausstellen - besser noch, von extern signiert.

    OK, kannst du die Vorgehensweise bitte etwas beschreiben? DANKE!

    Freitag, 13. Februar 2015 13:49
    |