Hallo Forum,
leider reicht meine expertiese nicht aus um diese Fehler selbständig mit Hilfe von Suchmaschinen und anderen Beiträgen zu beheben.
Ich möchte mich in diesem Fall an euch wenden und um Unterstützung beten.
Zur Struktur und dem Vorgehen:
Hierbei handelt es sich um eine Migration von Exchange 2010 SP3 UR30 auf Exchange 2016 CU15.
Im Einsatz sind Outlook 2010 und 2013.
Für weitere Tests habe ich ein Outlook 2016 und 2019.
Ich habe die Migration wie hier auf der Website beschrieben gestartet.
Nachdem die ersten Tests erfolgreich durchgeführt wurden habe ich die Migration soweit durchgeführt, dass alle Postfächer auf den neuen Exchange verschoben wurden, die URLs auf den neuen Server zeigen und die Öffentlichen Ordner zu sehen waren.
Es konnten alle Outlook Versionen von 2010 bis 2019 verbunden werden.
Am nächsten Morgen die Ernüchterung:
Die Bestandspostfächer der Outlook 2010 Clients und 2013 Clients verbinden sich auch regulär per Mapi mit dem Exchange 2016.
Neue Profile verbinden sich nur noch per RPC.
Neuere Outlook Versionen lassen sich aber nicht mehr einrichten, da das Autodiscover intern nicht mehr funktioniert.
Ja genau, bei meinen Tests habe ich herausgefunden, dass von extern alles Prima funktioniert, nur von intern nicht.
Folgende Tests wurden durchgeführt:
Microsoft Remote Connectivity Analyzer: Jeder Test, sauber
Verbindung von externen Outlook 2016 und 2019: funktioniert, sind auch per MAPI verbunden (Verbindungstatus)
Test der Autokonfiguration innerhalb der Umgebung: der Aufruf der Autodiscover.xml schlägt immer mit dem httpStatus=401 fehl
Es kommt zwar immer wieder ein Anmeldefenster hoch, dieses wird aber mit NETBIOS sowie UPN Format mit 401 abgelehnt.
Test auf dem Exchange 2016 Server:
Test-OutlookWebServices -identity: test@domain.de -MailboxCredential (Get-Credential) |fl
Cmdlet Get-Credential an der Befehlspipelineposition 1
Geben Sie Werte für die folgenden Parameter an:
Credential
RunspaceId : 4c02f2dc-7ec2-4841-8835-c6bb6a3f1e87
Source : ex16.domain.local
ServiceEndpoint : mail.domain.de
Scenario : AutoDiscoverOutlookProvider
ScenarioDescription : AutoErmittlung: Outlook-Anbieter
Result : Failure
Latency : 21
Error : System.Net.WebException: Der Remoteserver hat einen Fehler zurückgegeben: (401) Nicht autorisiert. ---> System.ComponentModel.Win32Exception: Der Zielprinzipalname ist
falsch
bei System.Net.NTAuthentication.GetOutgoingBlob(Byte[] incomingBlob, Boolean throwOnError, SecurityStatus& statusCode)
bei System.Net.NTAuthentication.GetOutgoingBlob(String incomingBlob)
bei System.Net.NegotiateClient.DoAuthenticate(String challenge, WebRequest webRequest, ICredentials credentials, Boolean preAuthenticate)
bei System.Net.NegotiateClient.Authenticate(String challenge, WebRequest webRequest, ICredentials credentials)
bei System.Net.AuthenticationManagerDefault.Authenticate(String challenge, WebRequest request, ICredentials credentials)
bei System.Net.AuthenticationState.AttemptAuthenticate(HttpWebRequest httpWebRequest, ICredentials authInfo)
bei System.Net.HttpWebRequest.CheckResubmitForAuth()
bei System.Net.HttpWebRequest.CheckResubmit(Exception& e, Boolean& disableUpload)
--- Ende der internen Ausnahmestapelüberwachung ---
bei System.Net.HttpWebRequest.GetResponse()
bei Microsoft.Exchange.Management.SystemConfigurationTasks.ServiceValidatorBase.InternalInvoke()
bei Microsoft.Exchange.Management.SystemConfigurationTasks.ServiceValidatorBase.Invoke()
Verbose : [2020-04-09 11:27:56Z] 'AutoErmittlung' stellt eine Verbindung mit 'https://mail.domain.de/Autodiscover/Autodiscover.xml' her.
[2020-04-09 11:27:56Z] Testkonto: test@domain.de Kennwort: ******
[2020-04-09 11:27:56Z] Anforderung von AutoErmittlung:
User-Agent: EX16/Test-OutlookWebServices/test@domain.de
Content-Type: text/xml; charset=utf-8
Authorization: Negotiate oYIGazCC[...]zS+htj4MwPQSM4ACEe1EI
Host: mail.domain.de
Content-Length: 461
Expect: 100-continue
[2020-04-09 11:27:56Z] Anforderung von AutoErmittlung:
<?xml version="1.0"?>
<Autodiscover xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006">
<Request>
<EMailAddress>test@domain.de</EMailAddress>
<AcceptableResponseSchema> http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema>
</Request>
</Autodiscover>
[2020-04-09 11:27:56Z] Antwort von AutoErmittlung:
request-id: 4662e627-4fc3-49e2-9fcb-e7502700f127
Server: Microsoft-IIS/10.0
WWW-Authenticate: Negotiate
oXYwdKADCgEBom0Ea2BpBgkqhkiG9[...]MMAobCHRoLWV4MDIk,NTLM,Basic
realm="mail.domain.de"
X-Powered-By: ASP.NET
X-FEServer: EX16
Date: Thu, 09 Apr 2020 11:27:56 GMT
Content-Length: 0
[2020-04-09 11:27:56Z] Antwort von AutoErmittlung:
System.Net.WebException: Der Remoteserver hat einen Fehler zurückgegeben: (401) Nicht autorisiert. ---> System.ComponentModel.Win32Exception: Der Zielprinzipalname
ist falsch
bei System.Net.NTAuthentication.GetOutgoingBlob(Byte[] incomingBlob, Boolean throwOnError, SecurityStatus& statusCode)
bei System.Net.NTAuthentication.GetOutgoingBlob(String incomingBlob)
bei System.Net.NegotiateClient.DoAuthenticate(String challenge, WebRequest webRequest, ICredentials credentials, Boolean preAuthenticate)
bei System.Net.NegotiateClient.Authenticate(String challenge, WebRequest webRequest, ICredentials credentials)
bei System.Net.AuthenticationManagerDefault.Authenticate(String challenge, WebRequest request, ICredentials credentials)
bei System.Net.AuthenticationState.AttemptAuthenticate(HttpWebRequest httpWebRequest, ICredentials authInfo)
bei System.Net.HttpWebRequest.CheckResubmitForAuth()
bei System.Net.HttpWebRequest.CheckResubmit(Exception& e, Boolean& disableUpload)
--- Ende der internen Ausnahmestapelüberwachung ---
bei System.Net.HttpWebRequest.GetResponse()
bei Microsoft.Exchange.Management.SystemConfigurationTasks.ServiceValidatorBase.InternalInvoke()
bei Microsoft.Exchange.Management.SystemConfigurationTasks.ServiceValidatorBase.Invoke()
MonitoringEventId : 6001
Hier ist der Fehler:
System.Net.WebException: Der Remoteserver hat einen Fehler zurückgegeben: (401) Nicht autorisiert. ---> System.ComponentModel.Win32Exception: Der Zielprinzipalname ist falsch
Mit ein bisschen überlegen suchen bin ich auf folgende Möglichkeiten gekommen:
Abgleichen aller URLs: stimmen
Eventlog auf Fehlgeschlagene Anmeldungen geprüft: nicht vorhanden, aber auch keine erfolgreichen für den Benutzer?
IIS Logs geprüft, hier finden sich folgende Einträge bei einem Outlook 2016 Autodiscover Test:
020-04-09 08:26:30 <ServerIP> POST /autodiscover/autodiscover.xml &CorrelationID=<empty>;&cafeReqId=921d8188-e7a2-43a9-93a0-2848566529d7; 443 test@domain.de <ClientIP> Outlook/16.0+(16.0.4266.1001;+MSI;+x86) - 401 1 1326 38
Dieser sagt mir dann über den sc-win32-status 1326 des IIS: The user name or password is incorrect.
Ähm ja, nein!
Die stimmen, den Copy-Paste funktionieren die im OWA.
Hier muss also irgendwo das Problem liegen:
Darauf hin habe ich folgende Schritte durchgeführt:
Authentifizierungsmethoden im IIS und Exchange mit funktionerenden Exchange 2016 Umgebungen und MS Standard: keine differenzen Festzustellen
Prüfung der SPN Einträge:
Leider finden sich hier auch keine Einträge die mein Autodiscover betreffen:
setspn -L domain\EX10
exchangeMDB/EX10.domain.local
exchangeAB/EX10.domain.local
exchangeRFR/EX10.domain.local
setspn -L domain\EX16
exchangeMDB/EX16.domain.local
exchangeAB/EX16.domain.local
exchangeRFR/EX16.domain.local
Testweise hinzugefügter SPN:
setspn -S http/autodiscover.domain.local domain\EX16
setspn -L domain\EX16
http/autodiscover.domain.de
exchangeMDB/EX16.domain.local
exchangeAB/EX16.domain.local
exchangeRFR/EX16.domain.local
Brachte leider keinen Erfolg.
Ich habe zusätzlich noch eine Lösungsversuch ausprobiert, bei dem zwei Regitry-Einträge zu setzen waren unter:
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\
Leider weiß ich nicht mehr genau wie diese genau hießen.
Nachdem dies auch keinen Erfolg brachte habe ich diese wieder entfernt.
Ein anderer funktionierender Exchange 2016 hatte diese Einträge auch nicht.
Leider habe ich nun vorerst keine weiteren Ideen.
Wenn Ich mehr Informationen liefern soll, werde ich dem Umgehend nachkommen.
Für Unterstützung bei diesem Thema wäre ich sehr Dankbar!
Mit freundlichen Grüßen
Martin
Hi. Das hört sich nach einem Autodiscover Problem an. Dazu brauchen wir aber ein paar Informationen.
'AutoErmittlung' stellt eine Verbindung mit 'https://mail.domain.de/Autodiscover/Autodiscover.xml' her.
Erste Frage: Welches Zertifikat hast du aktiviert für IIS im Exchange? Auf welche(n) Namen ist dieses ausgestellt?
Zwote Frage: Welchen Wert liefert Get-ClientAccessService -Identity SERVERNAME | ft AutodiscoverServiceInternalUri?
Dritte Frage: Welchen Wert liefert -InternalUrl für die VirtualDirectories?
Vierte Frage: hast du einen DNS Record für das Ergebnis aus 2. und 3.?
Bitte mach noch Folgendes: Konfiguriere in einem internen Outlook Client ein Dummykonto (POP3), so dass du Outlook starten kannst. Wenn es gestartet ist, such im Systray (an der Uhr) das Outlooksymbol, drücke STRG und die rechte Maustaste darauf und wähle aus dem Kontextmenü "Autokonfiguration testen". Gib eine existierende Mailadresse des angemeldeten Benutzers ein, entferne die beiden Häkchen bei "Guess Smart..." und starte die Autoermittlung. Poste das Ergebnis aus dem Reiter "Protokoll" hier. Danke.
Gruss,
M.
Hallo Maboh,
vielen Dank für deine Antwort.
Gern reiche ich dir die notwendigen Informationen nach:
Erste Frage: Welches Zertifikat hast du aktiviert für IIS im Exchange? Auf welche(n) Namen ist dieses ausgestellt?
Hierbei handelt es sich um ein Multidomänzertfikat mit folgenden SANs:
- mail.domain.de
- owa.domain.de
- autodiscover.domain.de
- proxy.domain.de
Zwote Frage: Welchen Wert liefert Get-ClientAccessService -Identity SERVERNAME | ft AutodiscoverServiceInternalUri?
Ausgabe:
AutoDiscoverServiceInternalUri
------------------------------
https://autodiscover.domian.de/Autodiscover/Autodiscover.xml
Dritte Frage: Welchen Wert liefert -InternalUrl für die VirtualDirectories?
Ausgabe:
Get-OwaVirtualDirectory
InternalUrl : https://mail.domain.de/owa
Get-EcpVirtualDirectory
InternalUrl : https://mail.domain.de/ecp
Get-WebServicesVirtualDirectory
InternalUrl : https://mail.domain.de/EWS/Exchange.asmx
Get-ActiveSyncVirtualDirectory
InternalUrl : https://mail.domain.de/Microsoft-Server-ActiveSync
Get-OabVirtualDirectory
InternalUrl : https://mail.domain.de/OAB
Get-MapiVirtualDirectory
InternalUrl : https://mail.domain.de/mapi
Get-OutlookAnywhere
InternalHostname : mail.domain.de
Vierte Frage: hast du einen DNS Record für das Ergebnis aus 2. und 3.?
Ja, bei einem nslookup, ping owa-oder ecp-Aufruf funktioneren beide URLs (mail.domain.de und autodiscover.domain.de) und/oder geben die richtige IP aus.
Ergebnis des Outlook Autodiscover Tests:
Ich hoffe das es so passt, sollten noch Informationen fehlen reiche diese ebenfalls gern nach.
Schönen Ostersonntag!
Martin
Hallo,
das Problem konnte durch die Unterstützung eines externen Consultants erfasst werden.
Im Enddefekt gab es zwei Probleme:
Mein WebProxy hat sich beim Aufruf der "internen URL's" für mail.domain.de und autodiscover.domain.de eingemischt, dadurch gab es dann den Fehler beim Autodiscover.
(Anmeldefenster klappt hoch beim zweiten Schritt der Outlook Einrichtung und die oben gelogten Fehler erscheinen in den Logs)
Ein einfacher Test um dies Auzuschließen ist alle internen URLs Testweise auf den FQDN des E-Mail-Servers zu setzten.
Dann bekommt man zwar erstmal einen Zertifikatsfehler, dass Autodiscover und die Anmeldung müssen aber funktionieren.
Desweiteren muss ich noch suchen welche Probleme die URL "mail.domain.de" intern hat, den die Authentifizierung klappte damit dann immernoch nicht.
Ich habe nun die URLs am Exchange für Intern auf "owa.domain.de" gesetzt um das Problem kurzfristig zu umgehen.
Wenn ich wieder Muse habe, werde ich das Problem genauer Analysieren.
Vielen Dank für die Unterstützung
Martin
Hi, gut dass das Problem für euch zunächst mal gelöst werden konnte.
Im Autoermittlungstest siehst du schön, dass der Autodiscover zuerst auf mail.xxx.de/autodiscover/autodiscover.xml läuft. Hier sollte eigentlich die per AutodiscoverServiceInternalUri annoncierte Adresse drinstehen, daher ist mir nicht wirklich klar, ob deine Angabe von autodiscover.xxx.de/.... korrekt war. Die Reihenfolge von Outlook ist immer:
- O365 (bei Outlook 2019 oder neuer)
- Dienstverbindungspunkt
- autodiscover.domain.tld/autodiscover/autodiscover.xml
- domain.tld/autodiscover/autodiscover.xml
- SRV Record im DNS für _autodiscover._tcp.domain.tld
Wenn dein Dienstverbindungspunkt tatsächlich mail.xxx.de/autodiscover/autodiscover.xml wäre (was er meiner bescheidenen Meinung nach nicht war), dann musst du eigentlich nur sicherstellen, dass du eine entsprechende Zone in deinem internen DNS hast für mail.xxx.de mit einem einzigen A Record
@ INTERNE_IP-ADRESSE_DES_EXCHANGE
Wenn das der Fall ist und die Authentifizierung trotzdem scheitert, dann würde ich was im Netz vermuten, das hier zwischenfunkt - das hat dein Externer ja offenbar auch festgestellt, Proxy im Netz versucht natürlich mail.xxx.de nach EXTERN aufzulösen, respektive unterstützt keine Kerberos/NTLM Authentifizierung. Du brauchst also eine Ausnahme in deinen Proxy Optionen (am Einfachsten per PAC Datei) für mail.xxx.de, damit Outlook nicht versucht, die Verbindung über den Proxy herzustellen, sondern direkt auf den Server.
Lass mich dir noch was Grundsätzliches sagen, das ist eher als gut gemeinter Hinweis zu verstehen, nicht als Schelte ;-)
Es macht aus meiner Sicht in den wenigsten Umgebungen Sinn, den Exchange unter verschiedenen URLs anzusteuern. Ich sage nicht, dass es nicht Umgebungen gibt, wo das Sinn machen könnte, aber es gibt nur sehr wenige wo das zutrifft. Daher reicht es vollkommen, dem Exchange ein Webserverzertifikat auszustellen, das auf EINEN dedizierten Namen hört, also bspw. mail.domain.tld. Es gibt in der Regel keine Notwendigkeit, die AutodiscoverServerInternalUri auf explizit autodiscover.domain.tld laufen zu lassen. Der Vorteil eines Webserver Zertifikates ist einfach der Preis, dürfte 1/3 oder sogar weniger sein als der eines SAN Zertifikats.
Den Zugriff von extern lasse ich grundsätzlich nur über einen Reverse Proxy zu, dabei kann ich sämtliche URLs auch im externen DNS steuern und könnte dem Proxy ggf sogar ein anderes Zertifikat verpassen, das ist wesentlich flexibler. Als Reverseproxy kann man haproxy oder squid3 oder pound oder nginx einsetzen, für uns hat sich haproxy am flexibelsten erwiesen, da er Docker fähig ist.