knorkator
Goto Top

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!

Content-Key: 400452

Url: https://administrator.de/contentid/400452

Printed on: April 25, 2024 at 04:04 o'clock

Member: sabines
sabines Feb 05, 2019 updated at 09:09:25 (UTC)
Goto Top
Moin,

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",


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
Member: Knorkator
Knorkator Feb 06, 2019 at 12:15:56 (UTC)
Goto Top
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
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
Member: sabines
sabines Feb 06, 2019 at 12:48:11 (UTC)
Goto Top
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.
Search-MailboxAuditLog -Identity GF1 -LogonTypes Delegate -StartDate 1/1/2019 -EndDate 1/31/2019 -ResultSize 2000
Member: sabines
sabines Feb 06, 2019 at 13:03:29 (UTC)
Goto Top
Oder mal den Cachemodus deaktivieren
Member: Knorkator
Knorkator Feb 06, 2019 at 13:14:07 (UTC)
Goto Top
Get-MailboxFolderPermission wird bei GF1/GF2 die gleichen Wert aus:
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      True

Auditlog habe ich für GF1 aktiviert und schaue später mal nach.

Danke!
Mitglied: 138721
138721 Feb 06, 2019 updated at 13:44:00 (UTC)
Goto Top
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- ...
Set-ItemProperty -Path "HKCU:\Software\Microsoft\Office\16.0\Outlook\AutoDiscover" -Name "ExcludeExplicitO365Endpoint" -Value 1 -Type DWORD  
Das sollte deine Probleme sehr wahrscheinlich lösen.

Gruß l.
Member: sabines
sabines Feb 07, 2019 updated at 06:33:00 (UTC)
Goto Top
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
Member: Knorkator
Knorkator Feb 07, 2019 at 07:21:08 (UTC)
Goto Top
Trotz rumgesuche im WWW kannte ich den Link noch nicht.
Gute Übersicht!
> Set-ItemProperty -Path "HKCU:\Software\Microsoft\Office\16.0\Outlook\AutoDiscover" -Name "ExcludeExplicitO365Endpoint" -Value 1 -Type DWORD  
> 
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.

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..

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 = 1

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!
Mitglied: 138721
138721 Feb 07, 2019 updated at 07:26:23 (UTC)
Goto Top
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.
Member: Knorkator
Knorkator Feb 07, 2019 at 07:30:00 (UTC)
Goto Top
Wenn dieser Eintrag die Lösung war, werde ich dies per GPO verteilen und dann sollte Ruhe sein.