Hallo
da ich grade bei einem Kunden ein komische Problem habe hoffe ich auf gute Ideen aus der Community. Mir fällt nämlich nichts mehr ein wo ich noch suchen könnte.
Hier mein Problem: Outlook Clients innerhalb der Domäne haben von jetzt auf gleich die Verbindung zum Exchange verloren. Das äussert sich darin das auf einmal das Kennwort vom Benutzer unendlich abgefragt wir und keine Verbindung mehr zustande kommt.
Extern angebunden Outlooks Clients waren kurzfristig auch nicht mehr verbunden laufen aber jetzt wieder ohne Probleme nachdem ich den Exchange auf das aktuelle CU gebracht habe.
Webaccess lief die ganze Zeit ohne Probleme. Konfiguriert ist Split-Brain. Hat auch bis vorgestern einwandfrei funktioniert. Clients lösen intern auch die richtige IP auf können sich aber scheinbar nicht richtig anmelden.
Habe schon einige Sachen hier aus dem Forum ausprobiert, bisher ohne Lösung des Problems.
Ich hoffe Ihr habe noch Tips für mich.
Mit freundlichem Gruß
Kai
Bitte folgende Informationen liefern:
- Internal und External URLs der Virtual Direcories
- –AutoDiscoverServiceInternalUri des ClientAccessService
- Name des Zertifikats, das für IIS aktiviert ist
- IP des Exchangeservers
- DNS A Record für AutoDiscoverServiceInternalUri
Danke.
ECP
int: https://mail.rxxxs.de/ecp
ext: https://mail.rxxxs.de/ecp
EWS
int: https://mail.rxxxs.de/EWS/Exchange.asmx
ext: https://mail.rxxxs.de/EWS/Exchange.asmx
MAPI
int: https://mail.rxxxs.de/mapi
ext: https://mail.rxxxs.de/mapi
ActiveSync
int: https://mail.rxxxs.de/Microsoft-Server-ActiveSync
ext: https://mail.rxxxs.de/Microsoft-Server-ActiveSync
OAB
int: https://mail.rxxxs.de/OAB
ext: https://mail.rxxxs.de/OAB
OWA
int: https://mail.rxxxs.de/owa
ext: https://mail.rxxxs.de/owa
PowerShell
int: http://ex01.rxxxs.local/powershell
ext:
AutoDiscoverServiceInternalUri
https://autodiscover.rxxxs.de/Autodiscover/Autodiscover.xml
Zertifikat ist von Commodo und beinhaltet:
mail.rxxxs.de
autodiscover.rxxxs.de
IP des Exchange
int: 192.168.111.xxx
ext: 62.55.xx.xx
AutoDiscoverServiceInternalUri
int: per Forward-Lookupzone auf 192.168.111.xxx
ext: 62.55.xx.xx
Extern funktioniert auch alles. MS RemoteConn Test läuft erfolgreich durch.
Hi, das sieht doch auf den ersten Blick mal ziemlich gut aus. Wenn du ne Endlos Anmeldeschleife bekommst, deutet das in erster Linie auf ein Autodiscoverproblem, also irgendein Problem mit dem DNS, denn die Pfade passen alle zum Zertifikat. Mich würden 2 Dinge interessieren:
1. Was passiert, wenn du ein Konto neu einrichtest? Findet Outlook den Server und die Einstellungen?
2. Wenn du ein Dummikonto anlegst (POP3 oder IMAP mit Fantasiedaten), kannst du Outlook mit diesem Profil starten und dann einen Autoermittlungstest durchführen. Dazu auf das Outlooksymbol im Systray mit gedrückter STRG Taste und rechte Maustaste drücken und dann Autoermittlung auswählen. Füll die Emailadresse aus und entferne die beiden Häkchen bei Guesssmart. Bitte poste hier das Protokoll.
Gruss,
M.
Hallo Maboh,
das ist ja mein Problem, es sieht alles richtig aus.
Zu 1. Ja, findet alle Einstellungen.
Zu 2. Arbeite ich noch dran, ein erster Versuch ist gescheiteter. Aber ich versuche es weiter und dann gibt es Update.
In dem Zusammenhang habe ich folgendes auf dem Client gefunden:
Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server "ex01$" empfangen. Der verwendete Zielname war HTTP/mail.rxxxs.de. Dies deutet darauf hin, dass der Zielserver das vom Client bereitgestellte Token nicht entschlüsseln konnte. Dies kann auftreten, wenn der Ziel-Serverprinzipalname (SPN) nicht bei dem Konto registriert ist, das der Zieldienst verwendet. Stellen Sie sicher, dass der Ziel-SPN nur bei dem Konto registriert ist, das vom Server verwendet wird. Dieser Fehler kann auch auftreten, wenn das Kennwort für das Zieldienstkonto nicht mit dem Kennwort übereinstimmt, das im Kerberos-KDC (Key Distribution Center) für den Zieldienst konfiguriert ist. Stellen Sie sicher, dass der Dienst auf dem Server und im KDC beide für die Verwendung des gleichen Kennworts konfiguriert sind. Wenn der Servername nicht vollqualifiziert ist und sich die Zieldomäne (RxxxS.LOCAL) von der Clientdomäne (RxxxS.LOCAL) unterscheidet, prüfen Sie, ob sich in diesen beiden Domänen Serverkonten mit gleichem Namen befinden, oder verwenden Sie den vollqualifizierten Namen, um den Server zu identifizieren.
Könnte das mein Problem sein weswegen nur die Internen Clients nicht mehr funktionieren?
Kai
Hier noch die Screenshots vom AutoKonfiguration Test in Outlook.
Problem gelöst!
Nachdem ich mich etwas eingehender mit dem Kerberos Fehler beschäftigt habe bin ich über die folgende Seite http://briandesmond.com/blog/active-directory-spn-mappings-and-kerberos/ zur richtigen Lösung gekommen. Unter der SPN http/mail.rxxxs.de gab es keinen Eintrag im AD vom Kunden, wohl aber unter HOST/mail.rxxxs.de. Dieser zeigte allerdings nicht auf den Exchange-Server unter EX01 sondern auf ein kurz vorher neu im AD angemeldetes Computerobjekt "mail" das zum beim Kunden verwendeten Clearswift Gateway gehört. Da Windows sich laut dem Blog-Eintrag automatisch SPNs "ausdenkt" wenn sie nicht vorhanden sind ist das ganze dann falsch abgelaufen.
Ein einfaches setspn -a http/mail.rxxxs.de ex01 hat dann ausgereicht um den Fehler zu beheben.
Schönes WE noch an alle.
Kai
Hi, danke, auch das sieht gut aus. Wurde eventuell die Authentifizierungsmethode bei Outlook Anywhere aus irgendwelchen Gründen umgestellt? Also von NTLM auf Standard? Und nochmal die Frage: was passiert, wenn du das Konto neu einrichtest? Findet er dann alles?
Hallo maboh,
eigentlich wurde da von mir gar nichts umgestellt, aber scheinbar ist es ja so. Egal, ich konnte den Fehler ja beheben. Was deine andere Frage betrifft, ja es konnte ganz normal angelegt werden und es wurde alle Daten gefunden. Nur dann ging es halt nicht mehr weiter weil nicht korrekt angemeldet werden konnte.
Gruß