NorbertFe

vor 1 Stunde schrieb Dutch_OnE:

Da lohnt sich kein WSUS

Hmm, aber wenns dann doch funktioniert? ;)

vor 1 Stunde schrieb Dutch_OnE:

Der Verkäufer hatte noch einen anderen Download

vor 1 Stunde schrieb Dutch_OnE:

Detail kann ich aber leider auch nicht mehr dazu sagen

hmm. Wäre aber interessant, was da jetzt eine Lösung gewesen sein soll. ;) 

Kann ich morgen gern hier posten. Aber exo hat soviele ip Adressen, da ist es recht wahrscheinlich, dass regelmäßig mal welche drauf und wieder runter sind. ;) Ich kann diesbezüglich aber mit exo keine besonderen Probleme bei mir erkennen. 

vor 2 Stunden schrieb Squire:

Also Spamcop betrachte ich eigentlich schon als eine "vernünftige" RBL

 

Ich nicht, deswegen benutze ich die nicht mehr. Viel zu viele False positives.

vor 2 Stunden schrieb Squire:

die Standardlisten die im NoSpamProxy eingestellt sind. U.a. SpamCop (

Und welche noch? Sind da dieselben IPs in anderen Listen? ;)

Achja stimmt. Das gibt rein technisch eigentlich auch kein RFC her. Ich vermute aber, dass das früher oder später kommen wird. Allerdings führt das im Normalfall auch nur dazu, dass die Spammer einfach entsprechend konfigurierte Domains verwenden werden und das als "Authentizitätsprüfung" am Ende auch nichts mehr aussagen wird.

Ja, das stimmt, aber auf halbwegs vernünftigen RBLs landet auch eher seltener solche Systeme.  Ich überleg grad, aber mein Spamfilter hat aktuell noch keine Option Mails ohne SPF und ohne DKIM abzulehnen. Wie nennt sich bei euch denn das?

Welche Blacklists nimmst du denn? Ich hab da eigentlich kaum verstärkt Probleme mit ExO festgestellt. Aber ja, je größer der Absender, umso mehr kann er ja auftrumpfen. :/ Ist leider so.

Liest du die Fehlermeldungen auch?

Target host responded with error. -> 554 IP=MX-IP - Dialup/transient IP not allowed. Use a mailgateway or contact toda@rx.t-online.de if obsolete. (DIAL)'

Wie deutlich solls dir denn der T-Online Postmaster noch mitteilen? ;)

vor 7 Minuten schrieb fredy_oelschlaeger:

Meine Vermutung liegt darin begründet, da sonst AutoMapping nicht funktioniert (habe ich irgendwo bei Frankys Web gelesen).

Automapping funktioniert auch mit ausgeblendeten Mailboxen soweit mir bekannt. Aber unabhängig davon hat das ja nichts mit deinem Problem zu tun. Wo befinden sich denn die User? Auch on-premises oder sind die in der Cloud?

vor 20 Minuten schrieb dormi98:

Danke wieder was gelernt.

Vorher readme lesen ;)

vor 20 Minuten schrieb dormi98:

 

Fragt sich nur noch was an den beiden Clients nicht passt. 

Das kann man ggf. auch nachlesen: https://learn.microsoft.com/de-de/exchange/plan-and-deploy/post-installation-tasks/security-best-practices/exchange-extended-protection?view=exchserver-2019#prerequisites-for-enabling-extended-protection-on-exchange-server

War vorher schon die Extended Protection konfiguriert? Falls nein, dann wird da die Ursache zu suchen sein. (Abschalten der Extended Protection wird das Problem auf Kosten der Sicherheit erstmal lösen, aber keine Dauerhafte Lösung darstellen).

vor einer Stunde schrieb WilhelmR:

Kann ich diese Applikationen denn über den neuen Terminalserver starten?

Also Anmelden an neuen Terminalserver und über Programmlink auf den alten?

Nein. Wie soll das gehen? Wenn das installierbare Applikationen sind, wirst du die wohl neu auf dem neuen TS installieren müssen. Du kannst auf einer TS Session nicht ein Word 2016 starten, welches auf einem anderen Server installiert ist. ;)

vor 4 Stunden schrieb testperson:

soll es "Modify" sein. Mit den Rechten "Read" / "Write" funktioniert es jedenfalls nicht. Sobald ich "Full Access" delegiere gehts. ;) Hat jemand zufällig einen Link oder eine Übersicht zu den minimalen Rechten?

Im Worst Case mal das auditing anschalten und schauen, woran es scheitert ;)

vor 37 Minuten schrieb MrCocktail:

gerade weil Exchange ExtendedProtection nicht mal eben so eingerichtet ist, wenn es dass dann heute noch nicht.

Schönes Beispiel für meine Frage oben. Und wenn das selbst bei Exchange so ist, dass da Lücken über Monate offen gelassen werden, weil sich keiner drum schert, dann will ich gar nicht wissen, wie das mit Diensten ist, wo das auch noch viel umständlicher oder gar nicht dokumentiert ist. ;)

Naja ein Sessionhost wär schon notwendig, oder? ;)

müßte ich echt mal nachschauen. ich hab das neulich für den AADC konfiguriert und ein install-MSA gabs da gar nicht mehr als befehl oder es gab irgendeinen Fehler (ich schau nachher mal)

Gerade eben schrieb WilhelmR:

Deshalb sind die Cals auf 2019 downgraded worden und sollte so laut MS auch gehen.

Das ist ja auch korrekt so.

Super ;) wer hat eigentlich neben seiner sonstigen Arbeit Zeit, die ganzen CVE usw. zu lesen und ggf. Gegenmaßnahmen umzusetzen? ;)

vor 8 Minuten schrieb zahni:

Habe leider keine Header. In den weitergeleiteten Mails der MA steht

Aber der User sollte also in der Lage gewesen sein, anhand dieser Info klar zu erkennen, dass die Mail eben nicht von euch ist, oder?

Install-ADServiceAccount geht das unter 2019/2022 überhaupt noch? ich bekam da eigentlich immer Fehler. Unter 2016 war das noch notwendig.

Ist das vielleicht wieder so ein Trigger um den NTLM Hash abzugreifen aus Outlook heraus? Denn Outlook wird ja evtl. erstmal zum angegebenen Ort switchen wollen und ggf. die Anmeldedaten rübergeben (wobei es das eigentlich aufgrund der Sicherheitszone eigentlich nicht sollte.

vor 20 Minuten schrieb zahni:

Mail, die vorgibt aus unserem Haus zu sein (mit sehr alter Signatur, usw,.)

 

Wie sieht in so einem Fall denn der Sender usw. aus?

Übrigens hatte ich gestern den Fall, dass der Adobe Sign Account wohl von einem externen Partner übernommen wurde und darüber dann diverse Mails mit Aufforderung rausgegangen sind. Schöne neue Welt, wenn niemand mehr seine Credentials bei den richtigen Services eingeben kann, weil er nicht mal mehr weiß, welches die richtigen Services sind und welche nicht. ;)

vor 17 Minuten schrieb testperson:

Ich hätte _vor_ deinem Einwand hoch und heilig geschworen, dass es schon immer so war, dass der RDLic >= neuestem RDSH OS sein muss.

Ist doch auch so, oder wie muss ich das verstehen? Dein RDS Lizenzserver ist 2022 und verteilt 2022 und 2019er RDS CALs. Obwohl er nur 2022 RDS CALs installiert hat. Letzteres ist dann definitiv neu, denn ein 2019er RDS Server hat afaik keine RDS CALs für 2016 rausgerückt, wenn man die nicht auch vorher auf ihm installiert hatte. Und ein 2019er RDS Lizenzserver verteilt afaik auch keine 2022er CALs.

OK, das ist dann aber neu. Ist das bei MS irgendwo dokumentiert?

vor 37 Minuten schrieb Ferdinand:

"Sicherheitsmaßnahme" der Miccrosoft Updates sein sollte, um das "abhören" oder den Zugriff von Außen auf die Kamera verbieten soll.

Weil nur Admins interessante Dinge zu sagen und zeigen haben, oder wie stellt man sich das vor? ;)

vor 50 Minuten schrieb Toffel0815:

Erstmal kann ich nur eine Domain für 1 Benutzer hinterlegen im Exchange/AD.

Nein, nur kann ein User natürlich im ad nur einen Anmeldenamen haben.

smtp domains kannst du sehr viele an einen User vergeben.

wenn du das getrennt haben willst, wäre vermutlich ein Hauptpostfach und dann jeweils eine Shared Mailbox für jeden User ein Äquivalent zum Strato Konstrukt.

vor 6 Minuten schrieb magheinz:

Hat jemand webex dafür im Einsatz?

 

Ja wir. Aber das Remote Support Gedöhns kenne ich nicht. Aber wenn das ähnlich schlecht ist, wie die normale Desktop Sharing, dann will man das nicht haben. ;)

vor 10 Minuten schrieb MurdocX:

TBH Wir haben nur Tensor angefragt. Andere Modell haben nicht die benötigten Features gehabt und kamen nicht in Frage.

Das wär für unseren Einsatzzweck mit sehr hoher Wahrscheinlichkeit einfach nur überteuert. Und wenn SSO das einzige Feature ist, warum man nicht die Business Lizenz nimmt, dann ist das ein sehr teures Feature. ;) Ich fänds toll, wenn Teamviewer die Option einfach monatlich eingepreist mit im normalen Lizenzmodell mit anbieten würde.