10
Outlook 2016 fragt nach Kennwort eines deaktivierten Benutzers
Hallo zusammen,
zu diesem Thema gibt es ja 1000 Beiträge.
Habe auch schon viele gelesen, finde aber keine Lösung.
Wir haben hier Exchange2010 der Intern wie Extern über mail.domaeneA.com erreichbar ist.
Email-Adresse lautet Vorname.nachname@Firma.com, entspricht also nicht domaeneA.com.
Ab und zu werden Nutzer von Outlook aufgefordert, das Kennwort für das eigene Konto erneut einzugeben.
Ich hatte hier den Eindruck, dass es Probleme nach einem Kennwortwechsel gibt.
Teilweise bessert es sich für einige Zeit indem man den Windows-Tresor löscht.
Insgesamt aber nicht so wild.. die Abfrage kommt nicht sehr häufig und die Mitarbeiter ignorieren es mittlerweile meistens.
Unser GF1 ist da hartnäckiger.. wird aber auch öfter mit Abfragen genervt.
Er wird häufiger aufgefordert und muss auch noch Abfragen für verschiedene Konten einzugeben die er nicht hat (Besprechungsräume sowie von anderen Nutzern).
Insbesondere dann, wenn er mit dem Notebook unterwegs ist (Zuhause oder z.b. bei Kunden) kommen die Abfragen häufiger.
Ich hab mir da schon nen Wolf gesucht, die Meldung kommt ja nicht nur ab und zu.
Jedenfalls verschärft sich das Problem aktuell bei unserem GF (hilft ja evtl. bei der Suche).
Ich habe gestern das Konto eines anderen GF´s (GF2) deaktiviert da dieser das Unternehmen verlassen hat.
GF1 bekommt nun alle paar Minuten die Aufforderung, Zugangsdaten für GF2 anzugeben.
Es wird kein weiteres Postfach bei GF1 geöffnet.
Der zusätzlich geöffnete Kalender von GF2 wurde entfernt.
Meiner Meinung nach hat Outlook von GF1 nichts mit GF2 zu tun.
Vielleicht kann ja jemand etwas aus dem Log Auszug entnehmen:
C:\Program Files\Microsoft\Exchange Server\V14\Logging\RPC Client Access
2019-02-05T07:36:46.727Z,2292,169,/o=Firmenname-Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Vorname GF320,,OUTLOOK.EXE,16.0.11231.20122,Cached,,,ncacn_ip_tcp,,DelegateLogon,0,00:00:00.0937500,"Logon: Delegate, /o=Firmenname-Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Deakt Nutzer in database DB4 last mounted on EXSERVER01.Firmenname-gmbh.com at 26.01.2019 11:59:07, currently Mounted; LogonId: 3",
Ich bin da ziemlich ratlos..
Hoffe auf Hilfe!
Vielen Dank im voraus!
zu diesem Thema gibt es ja 1000 Beiträge.
Habe auch schon viele gelesen, finde aber keine Lösung.
Wir haben hier Exchange2010 der Intern wie Extern über mail.domaeneA.com erreichbar ist.
Email-Adresse lautet Vorname.nachname@Firma.com, entspricht also nicht domaeneA.com.
Ab und zu werden Nutzer von Outlook aufgefordert, das Kennwort für das eigene Konto erneut einzugeben.
Ich hatte hier den Eindruck, dass es Probleme nach einem Kennwortwechsel gibt.
Teilweise bessert es sich für einige Zeit indem man den Windows-Tresor löscht.
Insgesamt aber nicht so wild.. die Abfrage kommt nicht sehr häufig und die Mitarbeiter ignorieren es mittlerweile meistens.
Unser GF1 ist da hartnäckiger.. wird aber auch öfter mit Abfragen genervt.
Er wird häufiger aufgefordert und muss auch noch Abfragen für verschiedene Konten einzugeben die er nicht hat (Besprechungsräume sowie von anderen Nutzern).
Insbesondere dann, wenn er mit dem Notebook unterwegs ist (Zuhause oder z.b. bei Kunden) kommen die Abfragen häufiger.
Ich hab mir da schon nen Wolf gesucht, die Meldung kommt ja nicht nur ab und zu.
Jedenfalls verschärft sich das Problem aktuell bei unserem GF (hilft ja evtl. bei der Suche).
Ich habe gestern das Konto eines anderen GF´s (GF2) deaktiviert da dieser das Unternehmen verlassen hat.
GF1 bekommt nun alle paar Minuten die Aufforderung, Zugangsdaten für GF2 anzugeben.
Es wird kein weiteres Postfach bei GF1 geöffnet.
Der zusätzlich geöffnete Kalender von GF2 wurde entfernt.
Meiner Meinung nach hat Outlook von GF1 nichts mit GF2 zu tun.
Vielleicht kann ja jemand etwas aus dem Log Auszug entnehmen:
C:\Program Files\Microsoft\Exchange Server\V14\Logging\RPC Client Access
2019-02-05T07:36:46.727Z,2292,169,/o=Firmenname-Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Vorname GF320,,OUTLOOK.EXE,16.0.11231.20122,Cached,,,ncacn_ip_tcp,,DelegateLogon,0,00:00:00.0937500,"Logon: Delegate, /o=Firmenname-Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Deakt Nutzer in database DB4 last mounted on EXSERVER01.Firmenname-gmbh.com at 26.01.2019 11:59:07, currently Mounted; LogonId: 3",
Ich bin da ziemlich ratlos..
Hoffe auf Hilfe!
Vielen Dank im voraus!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 400452
Url: https://administrator.de/contentid/400452
Ausgedruckt am: 03.12.2024 um 17:12 Uhr
10 Kommentare
Neuester Kommentar
Moin,
Stichwort: DelegateLogon
prüf mal die Delegierungen mit Get-MailboxPermission oder Get-MailboxFolderPermission, eventuell ist das schon die Ursache.
Und in Zukunft, wenn jemand das Unternehmen verlässt, ggfs. zuerst die erteilten Rechte auf Mailbox und Ordner entziehen und dann erst Account löschen/deaktivieren.
Gruss
Zitat von @Knorkator:
2019-02-05T07:36:46.727Z,2292,169,/o=Firmenname-Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Vorname GF320,,OUTLOOK.EXE,16.0.11231.20122,Cached,,,ncacn_ip_tcp,,DelegateLogon,0,00:00:00.0937500,"Logon: Delegate, /o=Firmenname-Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Deakt Nutzer in database DB4 last mounted on EXSERVER01.Firmenname-gmbh.com at 26.01.2019 11:59:07, currently Mounted; LogonId: 3",
2019-02-05T07:36:46.727Z,2292,169,/o=Firmenname-Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Vorname GF320,,OUTLOOK.EXE,16.0.11231.20122,Cached,,,ncacn_ip_tcp,,DelegateLogon,0,00:00:00.0937500,"Logon: Delegate, /o=Firmenname-Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Deakt Nutzer in database DB4 last mounted on EXSERVER01.Firmenname-gmbh.com at 26.01.2019 11:59:07, currently Mounted; LogonId: 3",
Stichwort: DelegateLogon
prüf mal die Delegierungen mit Get-MailboxPermission oder Get-MailboxFolderPermission, eventuell ist das schon die Ursache.
Und in Zukunft, wenn jemand das Unternehmen verlässt, ggfs. zuerst die erteilten Rechte auf Mailbox und Ordner entziehen und dann erst Account löschen/deaktivieren.
Gruss
Hallo und Danke für den Hinweis.
Das Konto von GF2 wurde noch nicht gelöscht sondern nur im AD deaktiviert.
GF1 bekommt auch Kennwortabfragen für andere Konten.. die GF2 Abfrag kommt nur häufiger seit der Deaktivierung.
Woher die verwaiste SID kommt, kann ich leider nicht sagen.
Leider kann ich keine "Sonderkonfiguration" oder Fehlkonfiguration mit den beiden PS-Befehlen ermitteln.
Um die Übersicht nicht noch unübersichtlicher zu machen, habe ich die Accessrights weggelassen.
Ich bin hier aber der Meinung, dass in u.a. Daten GF1 bei GF2 stehen müsste.. oder?
get-mailboxpermission -identity gf1
get-mailboxpermission -identity gf2
Vielen Dank
Das Konto von GF2 wurde noch nicht gelöscht sondern nur im AD deaktiviert.
GF1 bekommt auch Kennwortabfragen für andere Konten.. die GF2 Abfrag kommt nur häufiger seit der Deaktivierung.
Woher die verwaiste SID kommt, kann ich leider nicht sagen.
Leider kann ich keine "Sonderkonfiguration" oder Fehlkonfiguration mit den beiden PS-Befehlen ermitteln.
Um die Übersicht nicht noch unübersichtlicher zu machen, habe ich die Accessrights weggelassen.
Ich bin hier aber der Meinung, dass in u.a. Daten GF1 bei GF2 stehen müsste.. oder?
get-mailboxpermission -identity gf1
Identity User IsInherited Deny
dom.tld/ou1/ou2/GF1 NT-AUTORITÄT\SELBST False False
dom.tld/ou1/ou2/GF1 S-1-5-21-848101936-616177408-388697493-3409 True False
dom.tld/ou1/ou2/GF1 dom\Domänen-Admins True True
dom.tld/ou1/ou2/GF1 dom\Organisations-Admins True True
dom.tld/ou1/ou2/GF1 dom\Organization Management True True
dom.tld/ou1/ou2/GF1 dom\Administrator True True
dom.tld/ou1/ou2/GF1 dom\Exchange Servers True False
dom.tld/ou1/ou2/GF1 dom\Organization Management True False
dom.tld/ou1/ou2/GF1 dom\Public Folder Management True False
dom.tld/ou1/ou2/GF1 NT-AUTORITÄT\SYSTEM True False
dom.tld/ou1/ou2/GF1 NT-AUTORITÄT\NETZWERKDIENST True False
dom.tld/ou1/ou2/GF1 dom\Exchange Servers True False
dom.tld/ou1/ou2/GF1 dom\Delegated Setup True False
dom.tld/ou1/ou2/GF1 dom\Organization Management True False
dom.tld/ou1/ou2/GF1 dom\Exchange Trusted Subsystem True False
dom.tld/ou1/ou2/GF1 dom\Administrator True False
dom.tld/ou1/ou2/GF1 dom\Organisations-Admins True False
dom.tld/ou1/ou2/GF1 dom\Domänen-Admins True False get-mailboxpermission -identity gf2
Identity User IsInherited Deny
dom.tld/ou1/ou2/gf2 NT-AUTORITÄT\SELBST False False
dom.tld/ou1/ou2/gf2 S-1-5-21-848101936-616177408-388697493-3409 True False
dom.tld/ou1/ou2/gf2 dom\Domänen-Admins True True
dom.tld/ou1/ou2/gf2 dom\Organisations-Admins True True
dom.tld/ou1/ou2/gf2 dom\Organization Management True True
dom.tld/ou1/ou2/gf2 dom\Administrator True True
dom.tld/ou1/ou2/gf2 dom\Exchange Servers True False
dom.tld/ou1/ou2/gf2 dom\Organization Management True False
dom.tld/ou1/ou2/gf2 dom\Public Folder Management True False
dom.tld/ou1/ou2/gf2 NT-AUTORITÄT\SYSTEM True False
dom.tld/ou1/ou2/gf2 NT-AUTORITÄT\NETZWERKDIENST True False
dom.tld/ou1/ou2/gf2 dom\Exchange Servers True False
dom.tld/ou1/ou2/gf2 dom\Delegated Setup True False
dom.tld/ou1/ou2/gf2 dom\Organization Management True False
dom.tld/ou1/ou2/gf2 dom\Exchange Trusted Subsystem True False
dom.tld/ou1/ou2/gf2 dom\Administrator True False
dom.tld/ou1/ou2/gf2 dom\Organisations-Admins True False
dom.tld/ou1/ou2/gf2 dom\Domänen-Admins True False Vielen Dank
Und was wirft Get-MailboxFolderPermission aus?
Du kannst unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList den Wert ProfileImagePath prüfen, ggfs. findest Du hier den Namen der SID.
Sonst könntest Du noch die Auditlogs checken, vielleicht steht da mehr drin.
Du kannst unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList den Wert ProfileImagePath prüfen, ggfs. findest Du hier den Namen der SID.
Sonst könntest Du noch die Auditlogs checken, vielleicht steht da mehr drin.
Search-MailboxAuditLog -Identity GF1 -LogonTypes Delegate -StartDate 1/1/2019 -EndDate 1/31/2019 -ResultSize 2000
Oder mal den Cachemodus deaktivieren
Get-MailboxFolderPermission wird bei GF1/GF2 die gleichen Wert aus:
Auditlog habe ich für GF1 aktiviert und schaue später mal nach.
Danke!
RunspaceId FolderName User AccessRights Identity IsValid
---------- ---------- ---- ------------ -------- -------
21386d6d-c579-4b6a-a44c-fe6b151c10a5 Oberste Ebene des Informationsspeichers Standard {None} Standard True
21386d6d-c579-4b6a-a44c-fe6b151c10a5 Oberste Ebene des Informationsspeichers Anonym {None} Anonym TrueAuditlog habe ich für GF1 aktiviert und schaue später mal nach.
Danke!
Ab Outlook 2016 hat sich das Autodiscover Verhalten geändert (haben viele Admins nicht mitbekommen), es ist eine Option für Office365 hinzugekommen die solche Probleme verursacht weil Outlook ungefragt im Hintergund versucht sich mit Office 365 mit den Benutzerdaten zu verbinden, dadurch das die Autodiscover Option auch noch höhere Priorität zu den anderen Optionen hat verschlimmert das ganze.
Das Verhalten lässt sich durch einen simplen Registry Eintrag am Client verhindern
https://www.frankysweb.de/exchange-2016-moegliche-ursachen-fuer-abfrage- ...
Das sollte deine Probleme sehr wahrscheinlich lösen.
Gruß l.
Das Verhalten lässt sich durch einen simplen Registry Eintrag am Client verhindern
https://www.frankysweb.de/exchange-2016-moegliche-ursachen-fuer-abfrage- ...
Set-ItemProperty -Path "HKCU:\Software\Microsoft\Office\16.0\Outlook\AutoDiscover" -Name "ExcludeExplicitO365Endpoint" -Value 1 -Type DWORD Gruß l.
Moin,
ich dachte dein Link bezieht sich nur auf die eigenen Anmeldedaten, beim TO werden doch aber Anmeldedaten für andere Accounts abgefragt, oder?
Gruss
ich dachte dein Link bezieht sich nur auf die eigenen Anmeldedaten, beim TO werden doch aber Anmeldedaten für andere Accounts abgefragt, oder?
Gruss
Trotz rumgesuche im WWW kannte ich den Link noch nicht.
Gute Übersicht!
Ich meine, dass ich den Key bei GF1 schon eingepflegt habe und er nichts gebracht hat.
Werde mir das Gerät aber später nochmal für 20min schnappen und incl. Neustart prüfen, ob der Wert erhalten bleibt.
Eine "Besonderheit", die wir hier bei uns einsetzen, ist die Freigabe der Kalender für jedermann.
https://www.movetech.net/index.php/blog/exchange-kalender-aller-benutzer ...
Interessant ist auch ein anderer Links aus den Kommentaren:
Es wird z.b. ein weiterer Link erwähnt, der den ExcludeExplicitO365Endpoint Wert an anderer Stelle setzt.
Diesen habe ich gestern gesetzt und GF1 hat bisher (gestern daheim und seit ner std im Büro) keine weiteren Meldungen erhalten.
Mal abwarten.
Vielen Dank für die Beiträge!
Gute Übersicht!
> Set-ItemProperty -Path "HKCU:\Software\Microsoft\Office\16.0\Outlook\AutoDiscover" -Name "ExcludeExplicitO365Endpoint" -Value 1 -Type DWORD
> Werde mir das Gerät aber später nochmal für 20min schnappen und incl. Neustart prüfen, ob der Wert erhalten bleibt.
Zitat von @sabines:
ich dachte dein Link bezieht sich nur auf die eigenen Anmeldedaten, beim TO werden doch aber Anmeldedaten für andere Accounts abgefragt, oder?
Sowohl als auch.. insbesondere bei GF1 werden auf Mitarbeiterkonten abgefragt, die absolut und überhaupt-nix mit ihm zu tun haben..ich dachte dein Link bezieht sich nur auf die eigenen Anmeldedaten, beim TO werden doch aber Anmeldedaten für andere Accounts abgefragt, oder?
Eine "Besonderheit", die wir hier bei uns einsetzen, ist die Freigabe der Kalender für jedermann.
https://www.movetech.net/index.php/blog/exchange-kalender-aller-benutzer ...
Interessant ist auch ein anderer Links aus den Kommentaren:
Es wird z.b. ein weiterer Link erwähnt, der den ExcludeExplicitO365Endpoint Wert an anderer Stelle setzt.
HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\office\16.0\outlook\autodiscover
DWORD: ExcludeExplicitO365Endpoint
Value = 1Diesen habe ich gestern gesetzt und GF1 hat bisher (gestern daheim und seit ner std im Büro) keine weiteren Meldungen erhalten.
Mal abwarten.
Vielen Dank für die Beiträge!
Es wird z.b. ein weiterer Link erwähnt, der den ExcludeExplicitO365Endpoint Wert an anderer Stelle setzt.
Das ist das selbe nur ist der zweite eine eine Policy der andere eine normale Einstellung. Policies haben immer Vorrang vor Einstellungen! Wenn du eine Domäne hast verteilt man sowas natürlich per GPO und dann landet die Einstellung auch im Policy-Key denn dafür gibt es in den Office GPOs eine entsprechende GPO.
Wenn dieser Eintrag die Lösung war, werde ich dies per GPO verteilen und dann sollte Ruhe sein.
