7
Fehlerhafte Anmeldung (Fehler bei der Kerberos-Vorauthentifizierung 0x12) bei EventID 4771
Hallo zusammen,
wie es nicht anders sein kann, hat ausgerechnet der Chef als einer der wenigen um nicht zu sagen fast als einziger das Problem, dass sein Konto oft gesperrt wird.
Ich hoffe Ihr habt genug Geduld, denn nachfolgend muss ich etwas ausholen, ich entschuldige mich schon im Voraus und danke euch:
Ich glaube, dass hier aber fast zwei Probleme vorliegen.
Zu den wenigen Mitarbeitern haben wir gesperrte Konten OHNE dass der "Bad Password" Counter hoch gezählt wird. Wir haben uns eine Benutzerdefinierte Ansicht der Ereignisse auf z.B. 4771 gesetzt. Dort sehen wir relativ oft, dass dort folgendes steht:
"Fehler bei der Kerberos-Vorauthentifzierung" und unten dann der Fehlercode 0x12"
Laut dieser Seite: https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.a ...
steht folgendes: 0x12 Clients credentials have been revoked Account disabled, expired, locked out, logon hours.
Der Account ist aber weder deaktiviert, noch abgelaufen oder sonst was. In der Tat aber gesperrt, wobei wir es einfach nicht greifen können warum?!
Unsere Konfiguration:
3x Server 2012 R2 als DC (1 an einem anderen Standort und 2 am gleichen Standort)
- GPO mit Kennwortrichtlinie (max. 3x falsch, Länge, Sonderzeichen etc.)
Server 2008 R2 mit Exchange 2010 SP3
W-LAN läuft auch über Authentifizierung mit Rechner bzw. User
Clients sind Windows 10 Ent. 64bit und Office 2013 Plus in 32bit
Der Exchange hängt hinter einem Nginx! Sprich alles was Exchange per Web zur Verfügung stellt läuft durch den Nginx (ActivSync, OWA etc.) was auch seit knapp einem halben Jahr problemlos funktioniert. Wie schon erwähnt, es betrifft hauptsächlich 1 Chef von 3 (phew, zum Glück nicht der Schlimmste) und vllt. 2-5% der restlichen Belegschaft.
Was haben wir bis jetzt gemacht?
- KeyManager geleert damit definitiv kein altes PW genutzt wird
- Einstellungen von Outlook überprüft
- TCPLogView mitlaufen lassen, so ganz sicher sind wir nicht, aber wir würden es fast auf Outlook eingrenzen.
Er hat noch 2 private Konten mit drin und zusätzlich haben wir hier noch ein Tool (Addin) zur Telefonsteuerung im Einsatz wozu auch eine Anmeldung benötigt wird.
- diese Addins hatten wir meines Wissens auch schon deaktiviert
- Office schon "repariert"
Ich habe es live gesehen... sprich nebenher, nachdem ich auf Fehlersuche war kam plötzlich die Anmeldung in Outlook und keine Verbindung mehr zum Exchange (verwirrenderweise manchmal mit BadPassword und 0x12 aber eher ohne BadPassword) obwohl an dem Rechner in der Zeit absolut KEINER dran war sondern neben mir stand!
Laut Log kam die fehlerhafte Anmeldung aber definitiv von seinem Rechner! Man kennt es ja, wenn man von LAN zu WLAN wechselt, dass er schlichtweg die Verbindung verliert und über WLAN eine neue Verbindung aufbaut. Und so ähnlich auch bei Ihm.
- Netzwerk haben wir auch geprüft, da war kein Verbindungsabbruch und selbst wenn, das erklärt aber nicht die Kontosperrung teils mit und teils ohne BadPassword.
Jetzt kommt aber der Oberknaller... manchmal wird sein Konto NICHT gesperrt, aber trotzdem kommt eine Anmeldemaske von Outlook, worin dann der Name eines Kollegen steht?! Die einzige Möglichkeit, wie er überhaupt mit diesem Kollegen in Verbindung stehen kann ist, dass der Chef auf dessen Kalender gucken kann. Wenn mein Chef jetzt aber die Outlookanmeldung sieht, hat er bedenken, dass das auch umgekehrt passiert. In der Tat hat wieder ein komplett anderer Kollege auch davon berichtet, der unsere Kalender in der IT sieht, dass er hin und wieder auch von Outlook eine Anmeldung bekommt, worin unserer Namen dann vorkommen.
Jetzt ist es natürlich naheliegend, dass die Konten von anderen Leuten gesperrt werden, aber das kann man eigentlich ausschließen, da im Log ja zu ersehen ist, dass es von deren Rechnern selbst kommt.
Hier jetzt nochmals die Zusammenfassung der Themen:
- Fehler im Log beim DC für fehlerhafte Anmeldungen bei EreignisID 4771 mit Fehlercode 0x12 (teils mit BadPassword, teils ohne! und trotzdem gesperrt), gibt es ein Tool welches mitloggen kann, woher und wohin eine Anmeldung gehen soll? Es geht hier echt nicht darum eine Anmeldung auszuspähen sondern den Fehler zu finden, woher die falsche Anmeldung kommt
- Warum kommen von Outlook Anmeldungen, mit teilweise anderen Anmeldecredentials?
Wir sind hier zu dritt und komplett ratlos. Selbst wenn Verbindungsabbrüche vorhanden wären, dann ändert das doch aber nichts daran, dass auf einmal falsche Anmeldedaten übermittelt werden?
Ich hoffe ihr habt die Muse gehabt bis hier her zu lesen und ich hoffe es auch "verständlich" rüber gebracht zu haben und top wäre es, wenn einer ein Tipp für uns hätte
Ich danke.
Gruß Mike
wie es nicht anders sein kann, hat ausgerechnet der Chef als einer der wenigen um nicht zu sagen fast als einziger das Problem, dass sein Konto oft gesperrt wird.
Ich hoffe Ihr habt genug Geduld, denn nachfolgend muss ich etwas ausholen, ich entschuldige mich schon im Voraus und danke euch:
Ich glaube, dass hier aber fast zwei Probleme vorliegen.
Zu den wenigen Mitarbeitern haben wir gesperrte Konten OHNE dass der "Bad Password" Counter hoch gezählt wird. Wir haben uns eine Benutzerdefinierte Ansicht der Ereignisse auf z.B. 4771 gesetzt. Dort sehen wir relativ oft, dass dort folgendes steht:
"Fehler bei der Kerberos-Vorauthentifzierung" und unten dann der Fehlercode 0x12"
Laut dieser Seite: https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.a ...
steht folgendes: 0x12 Clients credentials have been revoked Account disabled, expired, locked out, logon hours.
Der Account ist aber weder deaktiviert, noch abgelaufen oder sonst was. In der Tat aber gesperrt, wobei wir es einfach nicht greifen können warum?!
Unsere Konfiguration:
3x Server 2012 R2 als DC (1 an einem anderen Standort und 2 am gleichen Standort)
- GPO mit Kennwortrichtlinie (max. 3x falsch, Länge, Sonderzeichen etc.)
Server 2008 R2 mit Exchange 2010 SP3
W-LAN läuft auch über Authentifizierung mit Rechner bzw. User
Clients sind Windows 10 Ent. 64bit und Office 2013 Plus in 32bit
Der Exchange hängt hinter einem Nginx! Sprich alles was Exchange per Web zur Verfügung stellt läuft durch den Nginx (ActivSync, OWA etc.) was auch seit knapp einem halben Jahr problemlos funktioniert. Wie schon erwähnt, es betrifft hauptsächlich 1 Chef von 3 (phew, zum Glück nicht der Schlimmste) und vllt. 2-5% der restlichen Belegschaft.
Was haben wir bis jetzt gemacht?
- KeyManager geleert damit definitiv kein altes PW genutzt wird
- Einstellungen von Outlook überprüft
- TCPLogView mitlaufen lassen, so ganz sicher sind wir nicht, aber wir würden es fast auf Outlook eingrenzen.
Er hat noch 2 private Konten mit drin und zusätzlich haben wir hier noch ein Tool (Addin) zur Telefonsteuerung im Einsatz wozu auch eine Anmeldung benötigt wird.
- diese Addins hatten wir meines Wissens auch schon deaktiviert
- Office schon "repariert"
Ich habe es live gesehen... sprich nebenher, nachdem ich auf Fehlersuche war kam plötzlich die Anmeldung in Outlook und keine Verbindung mehr zum Exchange (verwirrenderweise manchmal mit BadPassword und 0x12 aber eher ohne BadPassword) obwohl an dem Rechner in der Zeit absolut KEINER dran war sondern neben mir stand!
Laut Log kam die fehlerhafte Anmeldung aber definitiv von seinem Rechner! Man kennt es ja, wenn man von LAN zu WLAN wechselt, dass er schlichtweg die Verbindung verliert und über WLAN eine neue Verbindung aufbaut. Und so ähnlich auch bei Ihm.
- Netzwerk haben wir auch geprüft, da war kein Verbindungsabbruch und selbst wenn, das erklärt aber nicht die Kontosperrung teils mit und teils ohne BadPassword.
Jetzt kommt aber der Oberknaller... manchmal wird sein Konto NICHT gesperrt, aber trotzdem kommt eine Anmeldemaske von Outlook, worin dann der Name eines Kollegen steht?! Die einzige Möglichkeit, wie er überhaupt mit diesem Kollegen in Verbindung stehen kann ist, dass der Chef auf dessen Kalender gucken kann. Wenn mein Chef jetzt aber die Outlookanmeldung sieht, hat er bedenken, dass das auch umgekehrt passiert. In der Tat hat wieder ein komplett anderer Kollege auch davon berichtet, der unsere Kalender in der IT sieht, dass er hin und wieder auch von Outlook eine Anmeldung bekommt, worin unserer Namen dann vorkommen.
Jetzt ist es natürlich naheliegend, dass die Konten von anderen Leuten gesperrt werden, aber das kann man eigentlich ausschließen, da im Log ja zu ersehen ist, dass es von deren Rechnern selbst kommt.
Hier jetzt nochmals die Zusammenfassung der Themen:
- Fehler im Log beim DC für fehlerhafte Anmeldungen bei EreignisID 4771 mit Fehlercode 0x12 (teils mit BadPassword, teils ohne! und trotzdem gesperrt), gibt es ein Tool welches mitloggen kann, woher und wohin eine Anmeldung gehen soll? Es geht hier echt nicht darum eine Anmeldung auszuspähen sondern den Fehler zu finden, woher die falsche Anmeldung kommt
- Warum kommen von Outlook Anmeldungen, mit teilweise anderen Anmeldecredentials?
Wir sind hier zu dritt und komplett ratlos. Selbst wenn Verbindungsabbrüche vorhanden wären, dann ändert das doch aber nichts daran, dass auf einmal falsche Anmeldedaten übermittelt werden?
Ich hoffe ihr habt die Muse gehabt bis hier her zu lesen und ich hoffe es auch "verständlich" rüber gebracht zu haben und top wäre es, wenn einer ein Tipp für uns hätte
Ich danke.
Gruß Mike
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: 316517
Url: https://administrator.de/forum/fehlerhafte-anmeldung-fehler-bei-der-kerberos-vorauthentifizierung-0x12-bei-eventid-4771-316517.html
Ausgedruckt am: 23.12.2024 um 05:12 Uhr
7 Kommentare
Neuester Kommentar
Hallo.
Nur ganz fix aus der Hüfte geschossen:
Wirklich die einzige? Könnte das eine Profilangelegenheit sein? War dieser Kollege, auf dessen Credentials der Chef in Outlook manchmal (irre)geleitet wird , vielleicht doch schonmal auf dem Rechner des Chefs angemeldet (hat also auf diesem ein Profil - warum auch immer)?
Daß andere manchmal die Credentials von Euch IT-Leuten präsentiert bekommen, spricht auch irgendwie dafür, denn sicherlich wart Ihr ITler schon mal zu Wartungszwecken mit Euren Anmeldungen auf deren Rechnern.
Oder kannst Du Profile komplett ausschließen?
Viele Grüße
von
departure69
Nur ganz fix aus der Hüfte geschossen:
Die einzige Möglichkeit, wie er überhaupt mit diesem Kollegen in Verbindung stehen kann ist, dass der Chef auf dessen Kalender gucken kann ...
Wirklich die einzige? Könnte das eine Profilangelegenheit sein? War dieser Kollege, auf dessen Credentials der Chef in Outlook manchmal (irre)geleitet wird , vielleicht doch schonmal auf dem Rechner des Chefs angemeldet (hat also auf diesem ein Profil - warum auch immer)?
Daß andere manchmal die Credentials von Euch IT-Leuten präsentiert bekommen, spricht auch irgendwie dafür, denn sicherlich wart Ihr ITler schon mal zu Wartungszwecken mit Euren Anmeldungen auf deren Rechnern.
Oder kannst Du Profile komplett ausschließen?
Viele Grüße
von
departure69
Hi,
danke für die schnelle Antwort, aber Profile schließe ich aus. Am Chef seinem Notebook ist definitiv kein anderer als wir dran und wir haben Admin- und normale Konten, die Rede war demnach wenn (aber nicht beim Chef, sondern bei einem anderen Kollegen) die Anmeldung von meinem "Normalo-Konto".
Gruß
danke für die schnelle Antwort, aber Profile schließe ich aus. Am Chef seinem Notebook ist definitiv kein anderer als wir dran und wir haben Admin- und normale Konten, die Rede war demnach wenn (aber nicht beim Chef, sondern bei einem anderen Kollegen) die Anmeldung von meinem "Normalo-Konto".
Gruß
Die Fehler treten aber ausschließlich da auf, wo wer Zugriff auf Kalender- oder andere Postfachelemente eines anderen hat, richtig?
Falls ja, zumindest hab' ich es so verstanden, daß dies die einzigen "Gemeinsamkeiten" sind, dann ist beim Freigeben von z. B. Kalendern irgendwas schiefgelaufen.
Oder ich überlege, ob hier was mit ablaufenden bzw. abgelaufenen Windows-Passwörtern los sein könnte.
Bei uns sind die Passworte genau 42 Tage (=1.008 Stunden) gültig, so daß es vorkommt, wenn die User bis zum letzten Tag mit der PWD-Änderung warten, sie mitten am Tag (also genau dann, wenn genau die 1.008 Stunden vorüber sind) von Outlook nach dem PWD gefragt werden, da kommt dann auch in Outlook der Anmeldedialog, obwohl der Windowsaccount bzw. das angemeldete Profil ohne weitere Passwortabfrage bis zum Ende des Tages normal weiterläuft. Offenbar ist jede Transaktion in Outlook ein erneutes Login. Und der (berechtigte) Zugriff auf einen anderen Kalender natürlich auch. Läuft dann das eigene Passwort mitten am Tag, genau nach der Stundenanzahl, aus, und wird dann in Outlook nach dem PWD gefragt, könnte es nicht sein, daß der letzte Login (aus Outlook-Sicht) der auf den Kalender des Kollegen war, und dieser somit wieder präsentiert wird?
Also, sieh' vielleicht mal, ob diese Vorkommnisse genau dann auftreten, wenn bei den Betroffenen genau an dem Tag das Windows-Passwort abläuft. Könnte mir vorstellen, daß das dahintersteckt.
Ansonsten ist das natürlich wildeste Spekulation von mir, und auf die genannten Sperrungen bin ich überhaupt nicht eingegangen (wobei, wenn Outlook abgelaufene PWDs weiterhämmert ...), vielleicht antwortet nochmal jemand anderes was dazu.
Viele Grüße
von
departure69
Falls ja, zumindest hab' ich es so verstanden, daß dies die einzigen "Gemeinsamkeiten" sind, dann ist beim Freigeben von z. B. Kalendern irgendwas schiefgelaufen.
Oder ich überlege, ob hier was mit ablaufenden bzw. abgelaufenen Windows-Passwörtern los sein könnte.
Bei uns sind die Passworte genau 42 Tage (=1.008 Stunden) gültig, so daß es vorkommt, wenn die User bis zum letzten Tag mit der PWD-Änderung warten, sie mitten am Tag (also genau dann, wenn genau die 1.008 Stunden vorüber sind) von Outlook nach dem PWD gefragt werden, da kommt dann auch in Outlook der Anmeldedialog, obwohl der Windowsaccount bzw. das angemeldete Profil ohne weitere Passwortabfrage bis zum Ende des Tages normal weiterläuft. Offenbar ist jede Transaktion in Outlook ein erneutes Login. Und der (berechtigte) Zugriff auf einen anderen Kalender natürlich auch. Läuft dann das eigene Passwort mitten am Tag, genau nach der Stundenanzahl, aus, und wird dann in Outlook nach dem PWD gefragt, könnte es nicht sein, daß der letzte Login (aus Outlook-Sicht) der auf den Kalender des Kollegen war, und dieser somit wieder präsentiert wird?
Also, sieh' vielleicht mal, ob diese Vorkommnisse genau dann auftreten, wenn bei den Betroffenen genau an dem Tag das Windows-Passwort abläuft. Könnte mir vorstellen, daß das dahintersteckt.
Ansonsten ist das natürlich wildeste Spekulation von mir, und auf die genannten Sperrungen bin ich überhaupt nicht eingegangen (wobei, wenn Outlook abgelaufene PWDs weiterhämmert ...), vielleicht antwortet nochmal jemand anderes was dazu.
Viele Grüße
von
departure69
Das hat damit leider nichts zu tun... wie schon erwähnt... der Fehler 0x12 heißt u.A. auch "expired" und dem ist nicht so... wir haben schon nachgeschaut, ob das Konto abgelaufen sein könnte, ist es nicht... dennoch wurde es in gewissen Abständen (an einem Tag!!!) immer wieder gesperrt. Da man in Outlook ja auch den Haken setzen kann mit PW merken, so haben wir auch im KeyManager alles gemerkten PWs extra gelöscht, dass da auch kein altes PW drin sein konnte.
Moin @Pampersjoe
Sind evtl. an den betroffenen Clients bzw. Benutzer unter Systemsteuerung\Alle Systemsteuerungselemente\Anmeldeinformationsverwaltung irgendwelche Zugänge gespeichert?
Was gibt ein nltest /sc_verify:NameDerDomäne aus?
Was spuckt den das Ereignisprotokoll -> System auf dem Exchange-Server zum Zeitpunkt des Problem aus?
Datum/Uhrzeit ist auf allen Systemen synchron und vorallem korrekt?
Gibt es sonst noch Geräte/Anwendungen welche sich gegen das AD authentifizieren und evtl. noch ein altes Paswort hinterlegt ist?
Habt ihr Office 365 Accounts?
Gruß,
Dani
Das hat damit leider nichts zu tun... wie schon erwähnt... der Fehler 0x12 heißt u.A. auch "expired" und dem ist nicht so...
Und wie hast du das festgestellt? In Vergagenheit schon oft feststellen müssen, dass die Fehlermeldung zwar richtig ist, aber der Auslöser dafür nicht dokumentiert war. Gerade wenn Exchange, Sharepoint, etc... aufeinander treffen wird es komplex. W-LAN läuft auch über Authentifizierung mit Rechner bzw. User
Mischbetrieb? Sprich manche Computer werden via Zertifikat bzw. Benutzer melden sich mit ihrem AD-Zugangsdaten an.gibt es ein Tool welches mitloggen kann, woher und wohin eine Anmeldung gehen soll?
Woher sollte eigentlich im Event stehen, Client Address. Was menst du "wohin"? - Warum kommen von Outlook Anmeldungen, mit teilweise anderen Anmeldecredentials?
Wie hasts du die Kalender von euch freigeben bzw. bei den betroffenen Kollegen eingebunden. Via Stellvertreterberechtigung oder Vollzugriff über die EMC? Wenn das Problem regelmäßig auftritt, würde ich z.B. deinem Kollegen einfach temporär den Zugriff auf den IT Kalender entziehen.Sind evtl. an den betroffenen Clients bzw. Benutzer unter Systemsteuerung\Alle Systemsteuerungselemente\Anmeldeinformationsverwaltung irgendwelche Zugänge gespeichert?
Was gibt ein nltest /sc_verify:NameDerDomäne aus?
Was spuckt den das Ereignisprotokoll -> System auf dem Exchange-Server zum Zeitpunkt des Problem aus?
Datum/Uhrzeit ist auf allen Systemen synchron und vorallem korrekt?
Gibt es sonst noch Geräte/Anwendungen welche sich gegen das AD authentifizieren und evtl. noch ein altes Paswort hinterlegt ist?
Habt ihr Office 365 Accounts?
Gruß,
Dani
Moin!
Und wie hast du das festgestellt? In Vergagenheit schon oft feststellen müssen, dass die Fehlermeldung zwar richtig ist, aber der Auslöser dafür nicht dokumentiert war. Gerade wenn Exchange, Sharepoint, etc... aufeinander treffen wird es komplex.
Na ja, gibt ja Tools womit man erkennt, ob ein Account ausgelaufen ist, oder nicht... wir haben auf dem DC direkt AccountInfo laufen, was als Tabber beim User mit drin ist, damit kannst sehr schön die Daten zum Account sehen.
Mischbetrieb? Sprich manche Computer werden via Zertifikat bzw. Benutzer melden sich mit ihrem AD-Zugangsdaten an.
Zwangsläufig ja, da es auch User gibt, die einen Domänenaccount haben, aber nicht mit dem Rechnerin der Domäne sind... aber ja... der Chef ist direkt mit seinem Rechner in der Domäne.
Woher sollte eigentlich im Event stehen, Client Address. Was menst du "wohin"?
Na ja... im Event steht zwar vom Client mit der IP xyz aber mit einem dynamischen Port.
Wie hasts du die Kalender von euch freigeben bzw. bei den betroffenen Kollegen eingebunden. Via Stellvertreterberechtigung oder Vollzugriff über die EMC? Wenn das Problem regelmäßig auftritt, würde ich z.B. deinem Kollegen einfach temporär den Zugriff auf den IT Kalender entziehen.
Also es gibt eine Order von ganz oben, dass alle User-Kalender für jeden "eingeschränkt" freigegeben sein sollen, sprich ob jemand einen Termin hat und den Blocker dazu aber keine Details, dass man wenigstens grob einschätzen kann, ob man jemanden zu einem bestimmten Zeitpunkt einladen kann/darf oder nicht. In diesem Zuge haben wir es über die Powershell gemacht. Spezielle Berechtigungen vergeben die Leute in der Regel selbst ansonsten auch über die Powershell.
Sind evtl. an den betroffenen Clients bzw. Benutzer unter Systemsteuerung\Alle Systemsteuerungselemente\Anmeldeinformationsverwaltung irgendwelche Zugänge gespeichert?
Hatte ich ja gemeint mit "Keymanager" ... (glaub das nannte man auch Tresor oder so) da habe ich "sicherheitshalber" alles rausgelöscht.
Was gibt ein nltest /sc_verify:NameDerDomäne aus?
Am Client? Noch nicht getestet.
Was spuckt den das Ereignisprotokoll -> System auf dem Exchange-Server zum Zeitpunkt des Problem aus?
Hier "glauben" wir fast schon den Fehler eingrenzen zu können. Wenn ein Fehler im Log stand, der über den Exchange ausgelöst wurde und man dort reingeschaut hat in das Fehlerlog, dann hat man die IP-Adresse vom NginX gesehen, d.h. trotz dessen, dass die Leute in der Firma waren, ging die Verbindung wohl immer über den NginX. (den habe ich nicht eingerichtet, das hat ein Kollege gemacht) Ich habe den DNS jetzt intern auch bei "intern" belassen und bislang (vllt. auch nur Zufall) hat mein Chef keine Problem "in der Firma" von extern habe ich jetzt noch kein Feedback.
Andererseits, warum haben andere das Problem des Kontosperrens bislang nicht bis kaum gehabt? Vllt. Sonderzeichen im PW? Aber warum ist es nicht "sofort" immer bei Ihm gesperrt gewesen? Alles verwirrend.
Datum/Uhrzeit ist auf allen Systemen synchron und vorallem korrekt?
Jup, schon geprüft... und ist absolut korrekt und synchron.
Gibt es sonst noch Geräte/Anwendungen welche sich gegen das AD authentifizieren und evtl. noch ein altes Paswort hinterlegt ist?
Leider irgendwie alles mögliche, OpenVPN läuft über AD, WLAN, Ticketsystem, CRM-System und was weiß ich nicht alles. Ist halt das bequemste für die Leute ein Account für alles.
Habt ihr Office 365 Accounts?
Nö
Gruß,
Gruß zurück.
Also es gibt eine Order von ganz oben, dass alle User-Kalender für jeden "eingeschränkt" freigegeben sein sollen, sprich ob jemand einen Termin hat und den Blocker dazu aber keine Details, dass man wenigstens grob einschätzen kann, ob man jemanden zu einem bestimmten Zeitpunkt einladen kann/darf oder nicht.
Ist doch ein Standard Feature innerhalb der Exchange-Organisation...Am Client? Noch nicht getestet.
Client und Server...Wenn ein Fehler im Log stand, der über den Exchange ausgelöst wurde und man dort reingeschaut hat in das Fehlerlog, dann hat man die IP-Adresse vom NginX gesehen, d.h. trotz dessen, dass die Leute in der Firma waren, ging die Verbindung wohl immer über den NginX. (den habe ich nicht eingerichtet, das hat ein Kollege gemacht) Ich habe den DNS jetzt intern auch bei "intern" belassen und bislang (vllt. auch nur Zufall) hat mein Chef keine Problem "in der Firma" von extern habe ich jetzt noch kein Feedback.
Kläre mit deinem Kollegen ab, warum interne Verbindungen über den Nginx laufen (müssen). Der Sinn leuchtet mir noch nicht ganz ein... und gerade mit Exchange 2010 und RPC hätte ich Bauschmerzen. Es gibt dafür Lösungsansätze unter Nginx aber da muss man auch verstehen was zu tun ist. Also abklären warum was wie ist und anschließend die Infrastruktur so anpassen dass Outlook wieder direkt mit dem Exchange-Server kommuniziert. Eine Fehlerquelle weniger...Zwangsläufig ja, da es auch User gibt, die einen Domänenaccount haben, aber nicht mit dem Rechnerin der Domäne sind
Hört sich ingesamt bei euch recht abenteuerlich an... Arbeit wird wohl nicht ausgehen. Gruß,
Dani
