[English]Frage an die Administratoren, die bereits Windows 11 24H2 im Einsatz haben und dort auch Microsoft Outlook gegen einen Exchange-Server betreiben. Stellt ihr fest, dass Benutzerkonten im Active Directory wiederkehrend blockiert werden? Mir ist dieses krude Problem von meinen englischsprachigen Nutzern gemeldet worden, und es scheint kein Einzelfall zu sein.
Anzeige
Ein Leserhinweis auf das Problem
Blog-Leser CR hat sich im englischen Blog per Kommentar gemeldet und schreibt, dass er mit Windows 11 24H2 als Client ein seltsames Verhalten in einer AD-Domäne feststellen musste. AD-Benutzerkonten werden hin und wieder gesperrt. Er schreibt, dass es ihm so vorkommt, dass dies nur passiert, wenn der Sperrbildschirm dieses Benutzers aktiv ist.
Der Leser fragte, ob andere das auch beobachtet hätten. In der Tat meldete sich ein weitere englischsprachiger Blog-Leser, der diese Beobachtung bestätigt. Beide Leser verlinkten später auf eine Diskussion in der Spiceworks-Community, wo noch mehr Nutzer dieses Problem diskutieren.
Diskussion in der Spiceworks-Community
In der Spiceworks-Community gibt es den Beitrag Win11 24H2 update + Outlook client + Exchange account = repetitive AD account locked vom 15. Oktober 2024, wo jemand seine Beobachtung beschreibt.
Er beobachtete, dass mehreren Benutzern ihre AD-Konten gesperrt wurden. Auf dem betreffenden Domain Controller (DC) finden sich Ereignisse mit der ID 4740, deren Quelle vom PC des Benutzers stammt.
Anzeige
Nach einer längeren Analyse stellte sich heraus, dass alle drei betroffene Nutzer mit Windows 11 24H2 Pro, installiertem Outlook-Client (Office 365 Desktop-Suite) und einem Exchange-Konto unterwegs sind.
Ist Outlook beteiligt?
Der betroffene Administrator hat dann einen ausführlicheren Test gefahren und das gesperrte AD-Konto erneut für den Benutzer freigegeben. Gleichzeitig wurde dem Benutzer untersagt, während des Testzeitraums Microsoft Outlook zu verwenden.
Während mehrerer Stunden trat keine AD-Kontensperre mehr auf. Sobald der Benutzer Outlook auf seinem PC wieder öffnet, tritt die Blockierung in weniger als 2 Minuten wieder auf.
Weitere Benutzerbeobachtungen, keine Lösung
Im oben erwähnten Spiceworks Community-Thread beschreibt der Thread-Starter, was er alles getestet und unternommen hat, um die Ursache zu finden. Er hatte allerdings keinen Erfolg. Inzwischen haben sich dort weitere Betroffene gemeldet. Ein Betroffener beschreibt, das die Art der Anmeldung eventuell eine Rolle spielt.
Inzwischen hat der Thread-Starter klar bestätigt, dass es wohl nur mit Windows 11 24H2 in Verbindung steht. Ein Nutzer, der mit Windows 11 23H2 bisher problemlos unterwegs war, habe trotz Warnungen auf die 24H2 aktualisiert. Seitdem sperrt sich das AD-Konto des betreffenden Clients (auf dem auch Outlook und ein Exchange-Konto konfiguriert sind).
Aktuell ist derzeit die einzige Möglichkeit, das Problem zu lösen, in einem Rollback auf Windows 11 23H2, da dort die AD-Kontosperre noch nicht beobachtet wurde. Ist jemand aus der Leserschaft betroffen?
Anzeige
Hi, ich habe ein ähnliches? Problem mit EINEM Benutzerkonto. Kein Office 365 sonder 2021 LTSC. Problem tritt auf, wenn ich ein Upgrade von Win11 durchgeführt habe. Heißt auch bei 23H2 wenn vorher 22H2 drauf war. Bei einer absolut frischen Installation, auch mit 24H2 habe ich das Problem nicht.
Versucht habt ich schon alles typische, Profil vom Client gelöscht, sowohl Userprofil als auch Outlook. Die Netzwerkweiten Einstellungen zur Authentifizierung sowohl AD als auch Exchange sind alle sauber, kann auch keine Fehler finden.
Ereignislog am DC meldet dann immer das Kennwort des Users sei falsch. Outlook fragt dann immer wieder nach den User-Credentials und im AD wird dann das Konto gesperrt (Passwortrichtlinie).
Umweg aktuell (für die Clients dieses User) Clean-Install und kein Upgrade.
Auch gespeicherte Anmeldedaten in Systemsteuerung > Anmeldeinformationsverwaltung mal gelöscht? Klingt mir sehr nach einem Fall, wo das helfen könnte.
Ja sicher, die temporären Anmeldedaten in der Domäne für SSO in Outlook fallen da aber nicht rein. Es sei denn es sind manuell weitere Konten verbunden und man hat bewusst da reingeschrieben. Aber nein, daran liegt es ("leider") nicht. Gruß
Hi,
ich bin bei einem Kunden genau in die gleiche Problematik gelaufen (Outlook + Windows 11 24H2 + Exchange Postfach bei externem Hoster mit eigenem AD). Sobald der User Outlook öffnete wurde der User im lokalen AD gesperrt. Das haben ich nach etwas Suchen und Prüfen herausgefunden. Ich bin auch auf den Spiceworks-Artikel gestoßen aber wollte kein Rollback durchführen. Dort war die Lösung nach längerer Suche den Benutzernamen (nicht UPN) in der lokalen Domäne anzupassen, damit dieser nicht gleich ist, wie beim Postfach/Hoster ist. Danach funktionierte es wieder problemlos.
Ich vermute es liegt im Hintergrund an der Windows-Anmeldeverwaltung dort wird eine Windows-Identität für das Postfach angelegt, welche wohl dann auch für die lokale Domäne verwendet wird seit Windows 11 24H2.
Man sollte hier noch einschränkend erwähnen, dass in dem Spiceworks Thread von unterschiedlichen Passwörtern für AD und Exchange Konten gesprochen wird. Exchange in einem anderen Domäne als den Client zu betreiben, dürfte eher ein seltenes Szenario sein.
Einer der Betroffenen hat nun die Migration nach 365 gestartet, um das Problem zu umgehen. Alles richtig gemacht, Microsoft. :)
Ein hosted Exchange in einem RZ und eine lokale Anmeldedomäne sind ein seltenes Szenario?
Interessant.
Gebe dir recht, das ist nicht so selten.
Habe dies nun in mehreren Firmen und Standorten mitbekommen, externer Exchange und lokales AD.
Problem ist heute bei uns vermehrt ebenfalls aufgetaucht.
Alle wie beschrieben Windows 11 24H2, etc.
Lösung bis jetzt rollbacks aber auf Dauer wird das langweilig.
Das Problem habe ich auf dem Hauptrechner sofort nach einem Fresh-Install von Windows 24H2und Office 365 x64. Dachte mir nach ein paar Jahren Inplace-Upgrades mal aufzuräumen – never touch a running system :[
Auf dem NB fand ein Inplace-Upggrade statt. Da tauchte das Problem bis dato nicht auf.
Exchange 2019 CU14 onPrem (nicht Hybrid) und AD-Konten Sync in Entra.
Wir haben noch kein 24H2, sondern noch 23H2, Win 10 und 11, wir migrieren noch und tauschen Hardware aus wo nötig. Was ich aber sehe, ist dass sich Outlook regelmäßig und ziemlich oft mit der Emailadresse des Nutzers am Office-AD anzumelden versucht, statt mit dem Samaccount-Namen. Es ist sicher, dass es Outlook ist, sobald man das beendet, ist Ruhe. Die Exchange-Server sind bei uns in einer anderen Sub-Domäne des Forests, mit AD-Trust, versteht sich. Da könnte es einen Zusammenhang geben, Outlook scheint regelmäßig eine AD-Authentifizierung gegen das lokale AD durchführen zu wollen, und das komischerweise mit der Mailadresse, deren "Syntax" vom Samaccoun-Namen abweicht. Obwohl das fehlschlägt und den Eventlog der DCs damit füllt, funktioniert Outlook aber.
Als Laie lese ich hier gerne mit. Nun könnte das die Antwort auf ein Phänomen meines Firmensrechners sein. Seit Ende August (August Updates) wird mein Outlook im Hintergrund gestartet sobald eine Netzwerkverbindung hergestellt wird. Da ich eine pst eingebunden habe, die bei Bedarf mit VC gemountet wird, wird die pst beim normalen Start nicht gefunden und ich muss das Einbinden abbrechen. So fiel mir auf, das seit August das Outllok (365) Symbol mit einem 'orangenem Punkt' in der Taskleiste erscheint der besagt 'Outlook wird von einem anderen Programm verwendet. Um Programme zu unterbrechen und Outlook zu beenden, klicken Sie zuerst auf '. Tja, da bricht der Text ab. Die IT konnte mir dazu nix sagen, aber nun glaube ich mein Fall hängt mit dem Thema zusammen. Das Symbol erscheint sporadisch alle paar Minuten, falls ich nicht Outlook öffne Wurde der Outlook Unterbau schon auf die neue App getrimmt?
"Blockiert"? Also gesperrt vermutlich?
Nein, das Problem sehen wir nicht mit Windows 11 24H2 in der Fläche.
Outlook 2021 LTSC + Exchange Server 2019
Ich war einer derjenigen die in dem Spiceworks Thread geschrieben hatten, und zwar derjenige der das mit der alternativen Anmeldeversion per Zufall "gefunden" hatte, als ich das mit einem Techniker des Dienstleisters, bei dem unser Exchange läuft, überprüft hatte. Ich hatte 3 Konten, die sich in wenigen Minuten bis zur "10 mal falsches Passwort" Sperre hochgearbeitet hatten.
Ich kann das Problem also bestätigen im Zusammenhang von 24H2 mit Exchange welcher in einer anderen Domäne läuft.
Nach Änderung der Eingabe der Domäne für die Benutzerdaten kam das Problem nicht mehr vor, bei keinem der 3 User, auch wenn ich offen gestanden keine Ahnung habe warum das ein entscheidender Unterschied gewesen sein sollte.
"Nach Änderung der Eingabe der Domäne für die Benutzerdaten"
Wie ist das genau gemeint? Suche noch verzweifelt nach einer Lösung!
Das Hochschrauben der fehlerhaften AD-Anmeldungen kann keine dauerhafte Lösung sein. Das Ändern der Benutzernamen im DC ist für mich auch eher die letzte Lösung, das fände ich sehr unschön.
Hallo CR,
grundsätzlich wäre es eine Lösung wenn das AD Kennwort und das externe das gleiche sind, das ist aber natürlich keine schöne Lösung.
Bei uns hat es das Problem behoben das ich statt Domäne.de\benutzernamen nur domäne\benutzernamen eingegeben hatte.
Vielleicht ist das ein Versuch wert, sollte das überhaupt zutreffend sein
hello! please where do you input domain\username? on Outlook client? Exchange server? AD?
Thanks
Ich kann es auch bestätigen. Klassischer Fall wenn man Hosted-Exchange einsetzt und der Benutzername des Active Directory dem ersten Teil der E-Mail Adresse gleich (also vor dem @), dann meldet sich Outlook (!) am Domaincontroller mit dem ersten Teil der Mailadresse + gespeicherten Exchange Passwort am Active Directory an. Das schlägt natürlich fehl, und irgendwann wird der AD User gesperrt, sofern im AD ein lockout nach x Fehlversuchen eingestellt ist.
Wiedermal eine grandiose Microsoft Leistung!
Workaround:
1.) AD Lockout für User abschalten
2.) im AD einen anderen Benutzernamen für die betroffenen User nehmen
Aber ist es nicht so, dass es sogar von Microsoft vorgeschlagen ist, dass die Email-Adresse dem UPN entsprechen soll? Das wäre ja dann das entspr. Szenario, nicht?
Was verstehst du unter Benuztername? UPN oder SamAccount?
Ich kann das Problem bestätigen, mit folgenden Abhängigkeiten:
1. AD-Username (ohne Domain) und Exchange Username (ohne Domain) sind gleich.
2. Passwörter unterscheiden sich, weil Exchange ein hosted Exchange in einem RZ ist und die lokale Anmeldedomäne Onsite im Haus liegt.
Das Problem tritt definitiv mit 24H2 auf, Win10 Rechner sind vorläufig nicht betroffen. Die Outlook Version ist von 2019 bis 2021, spielt keine Rolle.
Das Problem tritt definitiv erst auf, wenn man Outlook startet.
Hallo!
Ich habe ein ähnliches, vielleicht sogar das gleiche Problem. Ein User bei mir wird nach dem Aktivieren der Bildschirmsperre (Win + L) oder nachdem die Bildschirmsperre nach Zeitablauf automatisch aktiv wird, vom System in der AD gesperrt. Nach den voreingestellten 10 Minuten Sperrfrist kann er sich wieder anmelden und weiterarbeiten. Unter Windows 23H2 und 24H2. Keine lokalen Nutzerkonten.
Nun habe ich mich daran erinnert, dass es vormals (schon vier, fünf Jahre her) das Problem gab, dass wenn der Nutzer Netzlaufwerks- oder Serverordnerverknüpfungen auf dem Desktop – die er u.U. vor geraumer Zeit als er noch ein anderes Passwort hatte – dort abgelegt hat, der Rechner beim Aufheben der Sperre, versucht auf diese Ordner- und NLW-Verknüpfungen mit den veralteten User-Credentials (gespeichert unter den Windows-Anmeldeinformationen) zuzugreifen. Diese sind natürlich nicht mehr gültig und je nach Anzahl der Ordner sind die fünf Anmeldeversuche schnell aufgebraucht und das Konto wird gesperrt.
Ich hatte dieses Problem definitiv schonmal, finde dazu aber nichts mehr.