Authentifizierungsprobleme Autodiscover Exchange 2019

[LukiHoer 2]

Hallo an alle!

 

ich habe vor langer Zeit schonmal von diesem Problem berichtet. Da jedoch damals mein Zeitfenster geschlossen war musste ich die Problemlösung verschieben.

Ich habe einen Exchange 2016 auf einen 2019 migriert. Bei der Migration an sich sind keinerlei Probleme aufgetreten. Doof war nur:

Nachdem ich das Postfach vom Exchange Admin und Administrator in die DB des 2019er Migriert hatte habe ich nur per OWA getestet ob alles passt.

Da ich mich dort anmelden konnte, Test-Mails empfangen und versenden konnte habe ich mit allen andern Postfächern weitergemacht.

Nach fertigstellen das Böse erwachen. Alle DNS auf den 2019er umgestellt und ALLE Outlook Clients fragen nach dem Passwort. Sowohl Clients innerhalb der Domäne also auch Clients die nicht in der Domäne sind und die Anmeldung manuell durchgeführt wurde.

Sobald ich auf die DNS Einträge zurück auf den 2016 stelle alles i.o.

Ich bin dabei wie immer nach der Anleitung von Frankys vorgegangen.

Alle virtuellen Verzeichnisse des 2019er = des 2016er.

Authentifizierung bei den Verzeichnissen abgeglichen.

Zertifikat ist von einer öffentlichen Zertifizierungstelle und auf beiden Servern hinterlegt.

Im Netzwerk gibt es nur einen DC.

 

Naja ende vom Lied war das die Postfächer in der DB vom 2019 verblieben sind und der 2016 angesprochen wird. Solange der 2016 Supportet und gewartet wird ist das ja auch erstmal i.O.

Jetzt hat der Kunde Betriebsferien und ich kann mich der Sache wieder annehmen ohne diesen zu stören. Weil wir ehrlich sind weiß der Kunde auch davon, wie gesagt solange der 2016er unterstützt wird ist das ja auch kein Problem, zu mindestens nicht für den Kunden.

Nach wie vor ist ein Login per OWA über den 2019er Problemlos machbar. Jegliche Clients die ich per hosts dazu zwinge den 2019er anzusprechen haben das Passwort-Problem.

Das gilt auch für ActivSync Geräte.

Beide sind auf aktuellest CU und Patchstand.

 

Nun hoffe ich auf das Schwarm-Wissen.

Wo würdet ihr ansetzten? Welche Logs sollten geprüft werden?

Vielen Dank schonmal vorab!

 

Gruß,

Luki

 

p.s. Die Autodiscover.xml auf dem 2016 kann nach angaben der Benutzerdaten aufgerufen werden. Beim 2019er kommt immer nur das Benutzerdaten Pop-Up wieder.

Das wäre ja schonmal ein Ansatz aber in welchen Logs muss ich da nach Fehlern suchen?

 

[Nobbyaushb 1.471]

Split-DNS richtig einrichten 

Den SCP im AD prüfen

[testperson 1.677]

Hi,

 

ein Schuss ins Blaue: Extended Protection auf dem Exchange 2019 aktiv und an den Clients passt das "LmCompatibilityLevel" (Exchange Server support for Windows Extended Protection | Microsoft Learn) nicht. Bzw. "SSL Offloading", ein Anti Virus, der https aufbricht, ...

 

Gruß

Jan

[LukiHoer 2]

N'Abend,

 

vor 23 Stunden schrieb Nobbyaushb:

Split-DNS richtig einrichten 

Den SCP im AD prüfen

Keine Fehler im DNS auffindbar. Haben jetzt 3 Leute drüber geschaut. Jegliche DNS abfragen werden wie gewünscht aufgelöst.

SCP: jetzt mal ne ganz selten dämliche Frage: muss die Sub Domain = autodiscover sein? Bei diesem kunden Wurde mit mail. gearbeitet.

Soweit ich weiß macht das kein unterschied oder? Die XML wird auf jeden Fall aufgerufen und am 2016 kann ich diese auch nach Anmeldung sehen.

Nur wie gesagt am 2019 kommt immer wieder das Popup.

 

vor 21 Stunden schrieb testperson:

ein Schuss ins Blaue: Extended Protection auf dem Exchange 2019 aktiv und an den Clients passt das "LmCompatibilityLevel" (Exchange Server support for Windows Extended Protection | Microsoft Learn) nicht. Bzw. "SSL Offloading", ein Anti Virus, der https aufbricht, ...

Das hatte ich bereits bei einem Kunden und hatte die Hoffnung das es auch bei diesem der Fall war. Leider kann ich das ausschließen :(

 

Vielen Dank für die Ansätze und Ideen! Gibts noch weitere?

 

Gruß

Luki

[Nobbyaushb 1.471]

vor 9 Minuten schrieb LukiHoer:

Keine Fehler im DNS auffindbar. Haben jetzt 3 Leute drüber geschaut. Jegliche DNS abfragen werden wie gewünscht aufgelöst.

SCP: jetzt mal ne ganz selten dämliche Frage: muss die Sub Domain = autodiscover sein? Bei diesem kunden Wurde mit mail. gearbeitet.

Soweit ich weiß macht das kein unterschied oder? Die XML wird auf jeden Fall aufgerufen und am 2016 kann ich diese auch nach Anmeldung sehen.

Nur wie gesagt am 2019 kommt immer wieder das Popup.

Im DNS musst du einen Eintrag für autodiscover.deinedomain.irgendwas haben, und diese muss auf den Exchange 2019 zeigen

Von daher - ja, muss autodiscover sein

mail.deinedomain.irgendwas wäre z.B. der Einstiegspunkt für OWA oder die Verbindung von Outlook zum Exchange und auch das muss im AD auf die IP vpm 2019 zeigen

Macht man eigentlich bevor Mailboxen verschoben werden

Vielleicht hilft das von meinem Freund:

New Set-AutodiscoverSCP v2 script is on the TechNet Gallery | The EXPTA {blog}

[cj_berlin 1.315]

Moin,

 

im SCP und im SRV, falls vorhanden, kann es mail.doma.in sein, und Outlook wäre zufrieden. Für alle anderen Clients muss es ein A/CNAME für autodiscover.doma.in geben.

[LukiHoer 2]

Meine Frage war vermutlich irreführend.

Die Primäre Zone autodiscover. gibt es natürlich und zeigt auch auf den 2019 (also wenn ich gerade teste ;)   )

mail. dementsprechend auch.

Mit meine Frage war wirklich der SCP Eintrag gemeint.

 

Weiß jemand ob es Logs gibt die solche Fehlerhaften Anmeldeversuche mitschreiben würden? Vielleicht gibt es dort einen Hinweis.

[NorbertFe 2.034]

vor 29 Minuten schrieb Nobbyaushb:

Von daher - ja, muss autodiscover sein

mail.deinedomain.irgendwas wäre

Nein der scp kann auch direkt auf owa.domain.tld zeigen. Wozu sollte er auf autodiscover zeigen müssen?

[Nobbyaushb 1.471]

Gerade eben schrieb NorbertFe:

Nein der scp kann auch direkt auf owa.domain.tld zeigen. Wozu sollte er auf autodiscover zeigen müssen?

Korrekt

[LukiHoer 2]

Um die gesamte DNS Geschichte etwas zu vereinfachen habe ich jetzt alle virtuellen Verzeichnisse auf autodiscover. Per Script am 2019 umschreiben lassen.

Alle DNS abfragen die an autodiscover.derdomain.gerät werden am Client mit der richtigen IP aufgelöst. Der SCP hat sich so wie er soll aktualisiert nach Ausführung des Scripts.

Ich habe grade zu testzwecken den R-Proxy auf ein NAT und dann auf den 2019 umgestellt.

Outlook will immer noch nicht aber mein Samsung konnte sich gerade problemlos Anmelden!!!!

 

Nachtrag. Auch mit R-Proxy geht es... der ist es also nicht.