fremdes Postfach EW...
 
Benachrichtigungen
Alles löschen

fremdes Postfach EWS (Exchange Server 2016 CU14)

12 Beiträge
3 Benutzer
0 Reactions
3,819 Ansichten
(@jan-werner)
Eminent Member
Beigetreten: Vor 5 Jahren
Beiträge: 16
Themenstarter  

Hallo Zusammen,

wir haben ein extrem seltsames Problem. Eingerichtet ist ein Postfach (kann ein beliebiges sein) im "eM Client" per EWS. Nach geraumer Zeit wird ein sync Fehler geworfen und während der sync wieder läuft, wird das komplette Postfach inkl. Unterordner eines anderen Benutzers angezeigt (sporadisch 2 Unterschiedliche konnten wir aktuell beobachten). Sobald der sync abgeschlossen ist, wird wieder das korrekte Postfach angezeigt. Es sind keine Berechtigungen auf die jeweiligen Konten gesetzt, also nur jeder selbst. Deaktivierung diverser Dienste auf dem fremden Konten (OWA für Geräte, Outlook im Web usw.) hat keine Änderung gebracht.

Wir sind mit unserem Latain am Ende und hoffen auf Hinweise.

Vielen Dank

Jan


   
Zitat
Frank Zöchling
(@franky)
Honorable Member Admin
Beigetreten: Vor 15 Jahren
Beiträge: 512
 

Hallo Jan,

ich weiß nicht was ein "eM Client" ist, was meinst du damit?

Gruß,

Frank


   
AntwortZitat

(@jan-werner)
Eminent Member
Beigetreten: Vor 5 Jahren
Beiträge: 16
Themenstarter  

Hallo Frank,

"eM Client" ist ein E-Mail Client, da kann man u.a. Exchange Konten per EWS einbinden.

https://de.emclient.com/ (ich hoffe das ist OK mit dem Link)

Ich denke aber, das unser Problem nicht an diesem eM Client liegt, sondern generell am EWS. Wir konnten feststellen, das immer wieder mal kurzzeit andere E-Mail Konten in dem Account auftauchen. Dabei ist es egal welchen Account man einrichtet, es tauchen immer wieder mal andere Postfächer auf. Davon abgesehen, das die fremden Postfächer angezeigt werden (es ist sogar möglich auf E-Mails zu antworten), frage ich mich wo das Loch der Berechtigung ist. Benutzerkonto A hat keine Berechtigung auf Benuterkonto B oder Benuterkonto X und dennoch wieder es, meistens bei syncproblemen mit dem Original Konto angezeigt.

Vielen Dank

Jan

 


   
AntwortZitat
Frank Zöchling
(@franky)
Honorable Member Admin
Beigetreten: Vor 15 Jahren
Beiträge: 512
 

Hallo Jan,

ah ok, ich kannte eM Client nicht. Kann es sein, dass die Benutzer Impersonation-Rechte haben? Wenn die Benutzer keine Zugriffsrechte auf andere Postfächer haben, dann wäre Impersonation eine mögliche Ursache. Falls keine eigene RBAC Rolle erstellt wurde, kannst du dies mit folgendem Befehl prüfen:

Get-ManagementRoleAssignment -Role ApplicationImpersonation

Gruß,

Frank


   
AntwortZitat

(@jan-werner)
Eminent Member
Beigetreten: Vor 5 Jahren
Beiträge: 16
Themenstarter  

Hallo Frank,

danke für den Hinweis. Ich kann es erst kommende Woche prüfen. Auf dem Server läuft auch Mailstore und der greift auch per EWS zu, evtl. ist da der Knopf.

Gruß

Jan

 


   
AntwortZitat
Frank Zöchling
(@franky)
Honorable Member Admin
Beigetreten: Vor 15 Jahren
Beiträge: 512
 

Hallo Jan,

generell ist das Verhalten natürlich ziemlich untypisch. Ich könnte mir Vorstellen das gearde in Verbindung mit Mailstore (welcher wahrscheinlich auch Impersonation nutzt) dieses Problem auftritt. Das ist aber nur eine Vermutung.

Gruß,

Frank


   
AntwortZitat

(@jan-werner)
Eminent Member
Beigetreten: Vor 5 Jahren
Beiträge: 16
Themenstarter  

Hallo Frank,

es gibt Tatsache 7 ApplicationImpersonation Type User. Alle 7 Stück wurden zum gleichen Zeitpunkt angelegt (alles gleich bis auf Name / ID). Leider kann niemand sagen was zu diesem Zeitpunkt gemacht/ installiert wurden ist.

Eine Info noch die ich bis dato nicht in bedracht gezogen habe. Es gibt per VPN angebunden einen weiteren Exchange (gleiche Domain) an einem anderen Standort.

Bitte korrigiert mich, für Frei/Gebucht Informationen werden keine Impersonationen gebraucht?!

Ich würde diese 7 Impersonationen löschen und für Mailstore explizit eine anlegen. Die "Interaktion" zwischen den beiden Exchange sollte dadurch nicht beeindrächtigt sein?!

Danke für weitere Hinweise, Bedenken und Informationen!

Viele Grüße
Jan


   
AntwortZitat
Frank Zöchling
(@franky)
Honorable Member Admin
Beigetreten: Vor 15 Jahren
Beiträge: 512
 

Hallo Jan,

nein, ein normaler Benutzer benötigt keine Impersonationsrechte, das ist sogar als ziemlich kritisch anzusehen. BenutzerA kann ja mittels Impersonation die Identität von BenutzerB annehmen. Für ein normalen Benutzer ist dies nicht erforderlich. Für Mailstore macht es wahrscheinlich Sinn.

Gruß,

Frank


   
AntwortZitat

(@jan-werner)
Eminent Member
Beigetreten: Vor 5 Jahren
Beiträge: 16
Themenstarter  

Hallo Frank,

tausend Dank!

Also werden diese Rechte auch nicht für die Interaktion zwischen den Exchangeservern (sind ja "Userrechte" - Administrator) benötigt?! Ich werde bei Gelegenheit die Impersonationsrechte entfernen und dann berichten.

Schönen Abend

Jan


   
AntwortZitat
Frank Zöchling
(@franky)
Honorable Member Admin
Beigetreten: Vor 15 Jahren
Beiträge: 512
 

Hallo Jan,

nein, in der Regel nicht.

Gruß,

Frank


   
AntwortZitat

(@jan-werner)
Eminent Member
Beigetreten: Vor 5 Jahren
Beiträge: 16
Themenstarter  

Hallo Frank,

heute konnte ich wieder einen Test fahren. Leider, auch nach löschen der Impersonationen, tauchen die fremden Mailkonten wieder auf. Somit bin ich wieder komplett am Anfang. Der Effekt tritt bei Syncfehlern mit dem Originalkonto auf. So in der Art, kann das Eigene nicht syncen, nehme ich ein Anderes.  Im LAN passiert das nicht, weil wahrscheinlich das Netz schnell genug ist und daher auch keine Syncfehler auftauchen.

Danke für weitere Ideen

Gruß

Jan


   
AntwortZitat
(@alfredo)
New Member
Beigetreten: Vor 5 Jahren
Beiträge: 1
 

Wir hatten kurzzeitig ähnliche Effekte. Ursache war ein Apache Reverseproxy. Da der Apache die Authentifizierung des Exchange nicht ausreichend unterstützt, bekamen andere Nutzer Session-Cookies einer gerade erfolgten Authentifizierung zugewiesen.

Abhilfe schafft erst die Nutzung der Standardauthentifizierung

https://znil.net/index.php?title=Apache2_als_Reverse_Proxy_f%C3%BCr_Exchange_2010_2013_2016_2019_inklusive_Outlook_Anywhere_RPC_over_http#Apache_Reverse_Proxy


   
AntwortZitat

Teilen: