jimmyone

Sorry, mir war nicht klar, das ich das Grundprinzip eines SMTP Proxy noch erklären muss. Das hatte ich irgendwie vorausgesetzt. Also vom Grunsatz her sind SMTP-Proxys MTAs, die, ähnlich wie andere Proxy-Server, SMTP-Sitzungen an andere MTAs weiterleiten, ohne dabei den typischen Store-and-Forward-Ansatz eines üblichen MTA zu verwenden. Wenn ein SMTP-Proxy eine Verbindungsanfrage erhält, initiiert er eine weitere SMTP-Sitzung zu seinem Ziel-MTA. Fehler oder Statusinformationen vom Ziel-MTA werden über den Proxy an den sendenden MTA zurückgegeben. Heißt: Ich erreiche bei einem Connect den Exchange on-premise nicht direkt sondern nur über den Proxy und zwischengeschaltete Firewalls. Nach außen sieht es aber so aus, als würde ich diesen direkt erreichen. Für meine Begriffe liegt da irgendwo der Hase im Pfeffer. Ich kann mir sonst nicht erklären, warum ich diese Meldung von außen erhalte, von innen aber nicht.

Aber nur auf diesem einen Connector, sonst nicht. Und auch nicht unmitelbar sondern über den Proxy.

Es ist nur ein Server. Früher waren es mal mehrere, inzwischen liegt das alles auf EXO und die sind zurückgebaut worden. Dazwischen befinden sich ein Proxy und 2 Firewalls. Sowie ein externes Mailgateway. Heißt: Der Exchange ist nicht direkt über das Netz erreichbar, weder für SMTP nocht für https Verbindung, wobei letztere inzwischen auch dicht sind, weil die Postfächer in EXO sind. Der Connector, dessen Port etc. aber sind erreichbar und werden laut den Netzwerkern und das sagt ja auch das Protokoll bis zum Exchange on-prem geroutet. Haelth Checker vom meldet derzeit mal keine Probleme. Zumindest solange nicht, bis es wieder Sicherheitsupdates gibt. Das meine ich ja auch, das dass Netzwerkseitig ist. Ich erhalte derzeit nur als Meldung: Netzwerkseitig keine Probleme oder Fehlconfig. Keine Fehlermeldung im Log des Exchange on-prem ersichtlich. Im Grunde will ich sicherstellen, bevor ich das erneut eskaliere an die Netzwerker, das nicht ich der Depp war, der eine Fehlconfig gebaut hat und man sich am Ende entschuldigen muss. Deshalb dachte ich, geh mal in den Austausch. Manchmal übersieht man ja was.

Zur Zeit knapp 400 GB. Edit: Zusatzinfo: Wartungsmodus ist nicht, auch nicht teilweise aktiv.

Hallo Zusammen, wir haben einen speziellen Connector auf einem Exchange on-prem, der bestimmte Aufgaben übernimmt und als einziger auch von außen über einen Proxy, DMZ, aber nur von bestimmten public IPs angesprochen werden darf. Die Frewall und Netzwerk Jungs haben bereits geprüft und melden, das die Pakete und Anfragen vom Exchange on-prem angenommen werden. Ein entsprechendes Protokoll liegt mir vor. Teste ich das ganze intern oder via VPN meldet sich der Exchange auf dem betreffenden Connector. Rufe ich das nun komplett von außen auf, wie das Szenario gedacht ist, erhalte ich als Meldung: 421 4.3.2 Service not active. Ich hatte vermutet, das der Proxy irgendwas filtert oder die Firewall, aber nichts dergleichen trifft hier zu. Die Konfiguration des Connectors lässt die anfragenden IPs zudem zu, heißt der Scope ist dafür gesetzt. Was übersehe ich denn hier? Hat ggf. jemand eine Idee, die vielleicht weiterhelfen könnte? Vielen Dank und LG

Hallo Zusammen, gibt es Erfahrungen bezgl. dem Einsatz des SPO Migrations-Manager und der betreffenden Agents bezgl. Zuverlässigkeit und Durchführung in der Migration von Fileservern? Zusätzlich wäre interessant (ich weiß nicht ob ich das bei der umfangreichen Doku einfach überlesen habe) ob und wie ggf. NTFS Berechtigungen migriert werden. LG

Hallo Zusammen, ich befasse mich derzeit mit dem Thema Migration on-prem Exchange nach Exchange Online. Ich betreue das derzeit alleine, deshalb habe ich niemanden, mit dem ich mal Gedanken austauschen kann. Nicht das noch jemand denkt, ich habe hier Lack gesoffen. Keine Ahnung davon und will migrieren, so ist das nicht. Es geht hier nur um Überlgungen zu einem möglichen Szenario. Zur Zeit verwenden wir den Agent Hybridmouds mit AD-Connect und zugehörigen Settings. Meine Frage bezieht sich ganz konkret auf den Mailflow im Hybrid-Szenario. Derzeit zeigen die MX'er auf ein Mailgateway, das vor dem on-prem Exchange in einer DMZ steht. Mailgateway als auch Exchange sollen in dem Szenario migriert werden. Für das Mailgateway gibt es derzeit noch die Problemstellung des blocked Port 25 in Azure ohne Ent. Agreement. Die machen den Port auch nicht frei. Also wandert das GW ggf. nach AWS, weil wir keinen Zusatzdienst für den Mailflow nutzen wollen oder verzichten zukünftig auf das versenden über das Mail GW und regeln nur noch den Empfang. In meinem Szenario wird der MX'er weiterhin auf das Mailgateway zeigen und damit ist kein Flow Problem da. Wie wäre das aber, zum Verständnis, wenn ich das Mailgateway nicht hätte, dann würde der MX'er ja auf den on-prem Exchange zeigen. Der Eintrag müsste aber ja eigentlich zukünftig auf Exchange Online zeigen oder bleibt dieser auf der on-prem Variante solange eingetragen als dieser als Hybrid noch verfügbar ist? Insbesondere wenn nicht unmittelbar alle Postfächer migriert werden oder es Postfächer gibt, die nicht ohne B-Rat oder DS Zustimmung migriert werden dürfen. Auf der anderen Seite muss ich auch auf dem Mailgateway zukünftig entscheiden, wohin ich die Nachricht zustelle. Also müsste doch in der Grundüberlegung ein System das "führende" bleiben, bis ein kompletter Switch auf Exchange Online mit allen Postfächern, Freigaben etc. stattgefunden hat. Könnt ihr da etwas Licht ins Dunkel bringen? Danke vorab.

Vielen Dank, für die Hinweise, für welche Szenarien AADDS geeignet ist. In meinem Fall habe ich dann diese Szenarien so nicht.

Hallo Zusammen, bei einem per VPN an das on-premise angebundene Azure Netzwerk kann eine Azure Windows VM ob Server oder Workstation an das on-premise AD per Join hinzugefügt werden. Nun gibt es aber ja auch noch die Azure AD Domainservices, die ja quasi das Pedant zur on-prem Welt sind. Seht ihr besondere Vor oder Nachteile, warum man Azure AD Domainservices anstelle on-prem nehmen sollte? Jetzt mal ohne Berücksichtigung, das man dadurch mit on-prem wieder stark verzahnt ist und die Ausfallsicherheit wieder stärker auch von on-prem abhängt. Würde mich über einen Meinungsaustausch freuen. LG Jimmyone

Jup. Aber: Mein innerer Monk hatte kurzzeitig Probleme mit dieser Thematik.

Ok, ja dann passt es ja. Ja, genau das meinte ich in meinem Einleitungstext mit ich sehe auch die Änderungen im Filesystem. Ich war nur etwas irritiert. Aber passt dann so für mich. Ganz herzlich bedankt bei allen. :)

Hallo Zusammen, aktualisieren eure Exchange Server 2016 die Buildnumber nach Security Updates im ECP und PS Abfrage auch nicht? Nachweislich sehe ich in der Systemsteuerung die eingespielten Updates durch ihre KB Nummer. Auch die Änderungen im Filesystem. Die Buildnumber bleibt aber im ECP auf der des CU22 (2375.7) für Exchange 2016. Auch über die PS erscheint nicht die Buildnumber des Patches. In der PS nutze ich zur Abfrage: Get-ExchangeServer | Format-List Name,Edition,AdminDisplayVersion Jetzt interessiert mich: Ist das nur bei mir so oder auch bei euch? LG

Hallo Zusammen, kann jemand das folgende Verhalten bestätigen oder nachstellen? Wir haben eine moderne hybrid Exchange Umgebung. Eine Kennwortänderung des hinterlegten Admins in Exchange Online für den Batchvorgang war notwendig. Über den Hybridassistenten auf der on-premise Seite muss man diesen vergeben, also habe ich den Assistent entsprechend gestartet und dort verändert. Dem Anschein nach wird diese Änderung aber nicht nach Exchange Online für den Endpunkt repliziert. Auch dann nicht wenn ich einen völlig anderen Nutzer eintrage. Das führt bei einem Batch zu dem Fehler, dass keine Verbindung mit dem Appproxy hergestellt werden kann. Sobald ich das Kennwort manuell in Exchange Online anpasse ist der Vorgang wieder erfolgreich durchführbar. Ist das ein Fehlerbild nur bei mir oder für euch auch nachvollziehbar?

Also laut Doku war das System niemals PDC oder sonst wie FSMO Owner. Aus Interesse: Von welchem How-to ist hier die Rede? Ich weiß heute ehrlich gesagt nicht mehr wirklich, wo wir die Lösung damals her hatten. Ich weiß noch, das rum gekrebse mit dem Zeitgeber war irgendwann so nervig, dass wir eine Domänenweite Lösung gesucht haben. Vielleicht basiert diese Lösung sogar auf dem von Dir genannten How to.

Prima, das hat geklappt. Danke NorbertFe. Tatsächlich hätte ich darauf ja auch noch kommen können. Insbesondere weil ich diese Möglichkeit kannte. Was solls, vielen Dank für den Tipp. Ich kann aktuell nicht sagen, ob der fehlerhafte DC mal die PDC Rolle hatte. Auszuschließen ist das allerdings nicht. VG Jimmyone

Moin, vielleicht hat jemand einen heißen Tipp, wie ich dem folgenden Problem weiter begegnen könnte... Es fing damit an, dass ein SQL Server nicht mehr per SSMS erreichbar war. Wir nutzen Kerberos an dieser Stelle. Die Untersuchungen zeigten, das Problem entsteht durch Timedrifting. Eigentlich dürfte es das gar nicht geben. Wir haben in der Vergangenheit über zwei GPOs eine Festlegung Domänenweit definiert. Auf Basis der Doku von damals, haben zu dieser Zeit alle DCs die richtigen Zeitdaten empfangen. Dabei wird u.a. per WMI die PDC Rolle erfasst und diese erfragt bei pool.ntp.org die aktuellen Zeitdaten. Eine zweite GPO gibt diese an alle Systeme weiter bzw. legt die Art des Sync fest. Bisher klappte das prima. Ein DC empfängt jedoch keine Zeitdaten mehr. Ein Resync Befehl meldet das entsprechend. Ein Query auf den peer vermeldet, dass er keinen entsprechenden Host mehr zur Abfrage hat. Die anderen DCs orientieren sich jedoch an der PDC Rolle sprich haben diesen als Zeitgeber. Eine RSOP Auswertung liefert für diesen fehlerhaften DC den Hinweis, dass er das GPO Objekt zieht und auch entsprechend synchronisieren sollte. Ein FSMO Query meldet auf dem betreffenden DC auch das richtige System als PDC. Die Vererbung der GPOs auf dem DC Container passt ebenfalls. Die Netzwerker melden, dass es keinen Firewall Blocker gibt. Wir haben das damals so gemacht, weil wir mit dem Thema nie wieder etwas zu tun haben wollten Hat ja gut geklappt. Hat jemand eine Idee, wie wir dem Thema weiter begegnen könnten? LG Jimmyone

Moin, das geht über folgenden Pfad: Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections Hier gibt es einmal: Limit number of connections und: Restrict Remote Desktop Services user to a single Remote Desktop Services session auf Deutsch dann entsprechend anders benannt. Mit diesen beiden Elementen kannst Du das steuern. Die GPO musst Du dann nur entsprechend über die Gruppe steuern.

Nein, das geht ja nicht. Das memberOf Attribut ist ja nicht verfügbar. Sonst hätten wir das mittels dynamischer Gruppen so umgesetzt, wie beschrieben. Siehe die Anforderung an das Azure AD Team: Dynamic Groups: Member of group – Customer Feedback for ACE Community Tooling (azure.com)

Hey, Benutzer können keine Gruppen oder Teams erstellen, also die Gruppen dahinter sind von uns erzeugt. Die Frage kann ich aber mit Ja beantworten. Mitglieder der on-premise Gruppe sollen Mitglieder dieses Teams werden.

Hi, eigentlich trivialer. Es geht um Zugehörigkeit in MS TEAMS - Teams. Wer in Gruppe XY ist, ist auch im Team in Teams.

Hallo Zusammen, leider gibt es ja noch immer nicht die Möglichkeit, dynamische Gruppen auf Basis des memberOf Attribut zu befüllen. Ich überlege nun also folgendes zu machen und wollte mal hören, ob es ggf. einen eleganteren Weg gibt, den ich nicht beachtet habe. Vielleicht vorweg: Ja, ich könnte die MS 365 Gruppe auch direkt im Azure AD befüllen. Allerdings hat nicht jeder Admin Zugriff auf das Azure AD, wohl aber auf Teile des on-premise AD. Eine derzeit gesetzte Entscheidung, ob persönlich für gut befunden oder nicht sei mal dahingestellt, ist: Das wir möglichst viel im Identity Management über das on-premise AD abwickeln. Ich würde jetzt eine on-premise Gruppe erstellen, dieser das Sync Flag geben, damit sie im Azure AD verfügbar und entsprechend mit Usern aufgefüllt ist. Zusätzlich erstelle ich eine Microsoft 365 Gruppe für die nötigen Dienste. Per Powershell hole ich mir dann die beiden Gruppen, setze die "on-premise" Gruppe als Referenz und fülle mit einem for each entweder die MS 365 Gruppe auf oder lösche einzelne Benutzer aus dieser. Mir erscheint das aber irgendwie sehr umständlich, zumal das bei wenigen Usern gut gehen könnte, bei vielen aber vielleicht ewig läuft. Habt ihr für einen solchen Fall Best Practices oder steuert ihr das dann über AAD direkt? Liebe Grüße jimmyone

Du sprichst vom Compare Hashes Powershell Script? Das hat bei uns auch ein seltsames Verhalten gezeigt. Es hat die web.config aus dem wwwroot des iis als verdächtig markiert. Wir haben das File geprüft, hatten das vorher auch schon geprüft und keine Veränderungen festgestellt.

Das Microsoft Threat Response Team hat heute Material bereitgestellt, welches bei der Bekämpfung und dem Verständnis helfen soll. Offenkundig ist es so, dass es immer noch zu viele gibt, die meinen uns kann nichts passieren oder nicht wissen, wie sie updaten sollen und können. 1. Troubleshooting Folien: https://webcastdiag864.blob.core.windows.net/2021presentationdecks/March 2021 Exchange Server Security Update - EN.pdf 2. 12 Minütiger Webcast zu dem Thema: https://webcastdiag864.blob.core.windows.net/2021webcastrecordings/Exchange Server OOB Release Webcast March 2021.mp4 3. Folien zu 2 https://aka.ms/ExOOB VG Jimmyone

Hallo Zusammen, offensichtlich gibt es in aktuellen Releases der Windows Server und Windows Client Varianten ein Deep Inspection Problem, wenn man Captive Portals einsetzt. Das äußert sich bei uns so, dass die Anmeldung erfolgreich abgeschlossen werden kann und die Maschine dann ein ERR_INVALID_RESPONSE meldet. Die Verbindung wird also als nicht sicher zurückgemeldet, weil statt dem Serverzertifikat das Zertifikat des Authentication Gateways zurück kommt. Ablauf: Wenn ich google.de öffne erhalte ich als Zertifikat nicht *.google.de sondern companyGatreway.domain.de. Wenn ich den Browser dann mehrmals refreshe klappt das irgendwann. In älteren Varianten tritt das so nicht auf. Es ist kein Cache Problem und auch kein Konfigurationsproblem. Ersteres wurde mehrfach gelöscht, letzteres mit dem Hersteller geprüft. In älteren W10 und Server Clients tritt das Problem wie beschrieben nicht auf. Netzwerkseitig haben wir das mal untersucht durch Anlage eines PCAP, was nach der Authentifizierung passiert. Es sieht aktuell so aus, dass der Client FIN/ACK Pakete an das Gateway sendet, wenn die Anmeldung durchgeführt wurde und das jedes Mal wiederholt, wenn eine erneute Anfrage gestellt wird. Es macht den Anschein, dass da irgendwo im Drei-Wege-Handschlag ein Problem zu suchen ist. Nehmen wir für den betreffenden Client das Captive Portal raus und lassen die Kommunikation direkt zu gibt es allerdings keine Probleme. Dann sieht man aber auch wieder entsprechende SYN Flacks. Die sieht man aber auch wenn man den Browser mehrfach refresht, was zu o.a. Verhalten passt. In einem mir gerade nicht näher bekannten Release scheinen u.a. auch echte Root Zertifikate zu fehlen, was aber hier jetzt nicht von Relevanz ist. Habt ihr solche Phänomene ggf. auch bemerkt? VG Jimmyone

Wir haben heute erzählt bekommen, dass ein System eines befreundeten Unternehmens, also im Dialog erfahren, nach einer internen Untersuchung bereits Mitte Januar ohne aufzufallen kompromittiert wurde. Für unsere Umgebung scheint zum Tagesschluss immer klarer zu werden, dass wir nur aus wenigen Gründen wahrscheinlich der Kompromittierung entgangen sind. 1.) Der Benutzer Administrator der Domäne war nicht verfügbar. Das Log gibt Aufschluss, dass über den Autodiscover Versuche mit verschiedenen TLDs und Domainnames unternommen wurden. In einem weiteren Schritt wurde versucht per MAPI dennoch zugreifen zu können, auch das war aufgrund des fehlenden Benutzers nicht erfolgreich. Die Meldungen lauten entsprechend. Z.b. S-ID-2-5456- can't act as mailbox owner. User not available. 2. Das Gateway Log gibt Aufschluss, das die dahinterliegende Scan Engine Javascript Files (y.js, x.js und CNAuth.js) heraus gefiltert hat. 3. Die DLLs App_Web im .Net Verzeichnis sind wohl kein Kriterium wie oben angenommen und werden wohl auch durch Exchange selbst erzeugt. 4. Wir haben sämtliche Dienste, die sonst ohne VPN erreichbar wären zunächst abgeschaltet und triggern nun einige Tage ob es versteckte Webshells gibt, die entweder selbst eine Kommunikation aufnehmen oder von außen angesprochen werden. Stellt sich auch das als negativ heraus wird das System wieder bereitgestellt, bleibt aber zunächst weiter unter Beobachtung. @gallahead: Ich vertrau der Engine der Systemwiderherstellung nicht wirklich. Wenn das System wieder aufgebaut werden soll, würde ich es from scratch hochziehen, Backups der DB einspielen und dann eine Bereitstellung wieder vornehmen. LG