Wolke2k4

Hallo allerseits, ich habe mal eine Frage: Ein Kunde hat an 2-4 seiner Rechner im Outlook ein Konto, welches als Microsoft Exchange gelistet ist und als Domain @outlook.de nutzt. Der Kunde hatte das Konto von einem IT-Dienstleister bekommen. Rechnungen für Office 365 hat der Kunde angeblich nicht, kann das Konto aber schon gut 3 Jahre nutzen. Worum kann es sich bei diesem Konto handeln? Ist das einfach ein kostenfreies 365 Konto? Nutzen tut der Kunde es primär für einen zentralen Kalender...

Danke, das ist, was ich "gesucht" habe! Da kann ich dann auch schon absehen, was der DMS Dienstleister argumentativ vorbringen wird: "Geht nicht, weil blablabla..." Aber das ist dann Nachgeplänkel, um das wir uns dann mit dem Kunden kümmern müssen. Mal schauen, wie das Ganze endet.

Das ist eine Alternative, die ich noch klären werde, hatte ich auch schon auf dem Radar.

Ja, selbst mit RP ist mir OWA und EWS alles nichts. Das ganze Gedöns und angepasse und all das, was so an Sicherheitslücken in der Vergangenheit lief und künftig noch kommt... Microsoft macht hier einfach großen Grütz. Und mir ist das eigentlich deutlich zu viel Aufwand für den Abgriff eines einzigen popligen Postfaches... Grundlegend seht Ihr in der Anpassung der Berechtigungen aber kein Problem?

Moin zusammen, ich habe hier eine extwas komplexere Situation, bei der mir leider auch nicht alle Details Dritter Beteiligter bekannt sind: - gehostetes DMS System von Dienstleister 1, welches via VPN an das Kundennetz angebunden ist - Hersteller des DMS und somit Dienstleister 2 - Supportdienstleister des DMS und daher Dienstleister 3 - IT-Dienstleister des Kunden und somit Dienstleister 4 - Kunde Soweit erstmal zu den Beteiligten. Nun soll vom DMS ein Zugriff auf ein einziges Exchange Postfach (liegt auf onPrem Exchange 2016 des Kunden) mittels EWS erfolgen (eRechnungen sollen dort abgegriffen werden), für das der Hersteller des DMS gern folgendes realisiert haben möchte (Aufgabe für IT-Dienstleister des Kunden) Sie müssen sicherstellen, dass das Benutzerkonto über die erforderlichen Berechtigungen für Microsoft Exchange Server verfügt, insbesondere das Recht Exchange-Identitätswechsel (Rolle Exchange Impersonation). Mit diesem Recht können Aktionen auf allen Postfächern im Namen der entsprechenden Besitzer ausgeführt werden. Sie benötigen für das Benutzerkonto zum Identitätswechsel nur dann ein Microsoft Exchange-Postfach, wenn Sie xyz Dienst verwenden. Für abc Dienst in Microsoft Outlook ist kein Microsoft Exchange Postfach für den Identitätswechsel notwendig. Sie können die Berechtigungen mit dem folgenden PowerShell-Befehl ändern: New-ManagementRoleAssignment –Name:impersonationAssignmentName – Role:ApplicationImpersonation Wenn Sie dem Benutzerkonto nur Rechte auf bestimmte Postfächer erteilen möchten, können Sie mit einem Filter für einen regulären, gefilterten Empfängerbereich (RecipientRestrictionFilter) die Berechtigungen einschränken. Sie können z.B. einen PowerShell-Befehl angeben, um einen Exchange-Identitätswechsel für das Dienstkonto auf die Postfächer 1 und 2 zu erteilen. Die beiden fett markierten Dienstnamen sind von mir geändert. Das sind Dienste des DMS, die anders benannt sind. Mich würde generell mal eure Einschätzung zu dieser Rechteanforderung interessieren. Glücklicherweise haben wir sonst solche Anwendungsanforderungen nicht. Rein vom Bauchgefühl her ist der unbeschränkte Zugriff auf alle Postfächer schon mal ein NoGo, sodass der Zugriff mindestens auf das eine Postfach beschränkt werden muss. Aber auch sonst halte ich eigentlich nicht viel vom EWS Zugriff von Third Party Anwendungen. Wie schätzt Ihr das ein?

Hallo allerseits, ich nutze seit geraumer Zeit ein Class 4 SMIME Zertifikat von CERTUM und verschicke damit alle Mails standardmäßig signiert. Immer wieder kommt es leider vor, dass bestimmte Empfänger diese signierten (wohlgemerkt nicht verschlüsselten) E-Mails (verschickt über Outlook 2019) aber nicht lesen können. Diese seien entweder leer oder enthielten einen Anhang, der den Mailtext aber nicht enthält... Certums Rückmeldung hierzu bisher unbrauchbar: Kann auftreten, wenn mehr als ein Zertifikat installiert ist, ich soll den Zertifikatsordner löschen und das Zert noch mal neu installieren. Häufig, wenn nicht gar immer, tritt das Problem auf jeden Fall bei Android auf. Ich habe aber auch schon Empfänger, die Office 365 nutzen... Hat jemand zufällig ähnliches erlebt und das fixen können? Im Support benutzen wir kein Class4 Zertifikat sondern ein Class1, solche Probleme haben wir dort bisher noch nie gehabt.

Das AD Snapin auf dem neuen DC zeigt nicht zufällig auf den alten DC? Die DNS Einstellungen des neuen DCs sind auch auf ihn selbst konfiguriert/zeigen auf seine eigene IP und nicht auf den alten DC?

Update zum Thema hierzu meinerseits: Zwischenzeitlich haben wir nun auch ein paar ASUS Boards von Wortmann Servern in den Fingern gehabt aber da ist es kaum besser. Mal wieder beschleicht einem das Gefühl, dass wieder nur Praktikaten an kritischen Stellen Entwicklungsarbeit leisten... Was wir (in Summe bei Intel und Asus aber auch Raid Controller Software wie bspw. LSI bei den Wortmann Servern) feststellen mussten: 1. keine Testfunktion für den Mailversand 2. kein Support für SMTPS 3. keine Verwendung von DNS Namen für SMTP Server 4. kein Customizing meldender Komponenten wie BMC/Management Interface und/oder RAID Controller, die für unsere automatisierte E-Mail Auswertung wichtig ist, um Kundensysteme eindeutig zuzuordnen... Ich meine wovon reden wir hier? Sicher nicht von Sachen, die es erst seit 2 Tagen gibt sondern von Basics. Ja die Wortmann Server sind günstig/günstiger, teils immer noch deutlich, wenn es gerade um die Verwendung von SSD/NVMe geht aber was diese Automatisierungsfunktionen für den Mailversand angeht, waren wir mit Fujitsu besser aufgestellt... Aber irgendwas ist ja immer. Wir werden nun mal den RASPI als separates Mail Relay ins Auge fassen.

Ja das sind Optionen, die ich auf jeden Fall forcieren werde, sollte der Umzug auf den 2003-er Member funktionieren. Danke erstmal fürs Feedback.

Hmmm Norbert, die Idee ist so simpel... Ich wusste schon, warum ich hier schreibe... Ich muss mal schauen, ob ich einen 2003-er Datenträger ISO bekomme (Actionpack wo bist Du?) Und dann ist die Frage, ob man diese Spezialsoftware darauf umgezogen bekommt. Zumindest für das Domain Thema wäre das erstmal eine Variante: 1. 2003-er Member Server installieren 2. Spezialsoftware darauf umziehen/lauffähig bekommen 3. SBS komplett ablösen --> Swing auf den 2012R2 DC und von dort zu 2022 4. SBS Goodbye... Wenn allerdings schon 2. nicht funktioniert, dann... A Karte...

Hallo zusammen, ich habe hier eine Umgebung vorgesetzt bekommen mit folgender Konstellation: 1. Windows Server 2003 SBS, der FSMO Halter und GC ist! (läuft glücklicherweise auf einem Hyper-V 2022 als VM) 2. Windows Server 2012R2, der auch DC ist (der alte Hyper-V) Nun soll die Umgebung aktualisiert/abgelöst werden und ich überlege gerade zu den entsprechenden Stolpersteinen: Das Kernproblem: Auf dem 2003-er Server läuft eine Spezialsoftware, dessen Entwicklerfirma es nicht mehr gibt, die aber eben leider noch immer im Unternehmen genutzt wird/werden muss. Mir ist klar, dass ich weder einen 2019 DC noch geschweige denn einen 2022 in dieses Uralt AD integriert bekomme. Soweit ich mich erinnern konnte und es eben recherchiert habe, muss der SBS FSMO Halter sein, da nach einem Transfer der Rollen dieser nach dem Kulanzzeitraum von 7 Tagen anfängt herunterzufahren?!? Damit bleibt m.E. der schlichte Umstand, dass im Grunde der SBS leer gezogen und für diese Spezialsoftware eine Lösung gefunden werden muss? Ich hatte überlegt, ob es vielleicht machbar wäre eine 2022-er Domain aufzusetzen, dort die Clients und die anderen beiden Server (1x neuer 2022-er Fileserver + 1x noch abzulösender 2012R2 Server) zu integrieren und dann eine Vertrauensstellung von der 2022-er Domain zur 2003-er herzustellen, damit die Spezialsoftware weiter genutzt werden kann... Letztlich ist mir aber auch klar, dass das nur ein weiteres hinauszögern des Unausweichlichen ist. Trotzdem würde mich eure Meinung interessieren, ob das Szenario mit der Vertrauensstellung möglich wäre. Danke schon mal vorab füre eure Antworten.

Also ich sag mal so: Als Fujitsu vor 2-4 Jahren massiv mit seinen Lieferproblemen anfing (das war noch vor Corona), sind wir auf Wortmann umgestiegen. Ich habe bei der Wortmann sicher bei den Servern nicht die bis ins kleinste ausgefeilten Funktionen und Features wie bei HP, Dell, Fujitsu usw. Aber ich sagt Dir, diese großen Player disqualifizieren sich aus mindestens folgenden Gründen: 1. schlechte Zuarbeit/Bearbeitungsdauer bei Angeboten (Fujitsu) 2. Preislich total überteuerte Server, wenns um NVMEs und SSDs geht 3. outgesourcter Support, dem Du oft erstmal erklären musst, was genau dein Problem ist 4. Zumeist nur max. 6 Jahre Garantieverlängerung --> Bei Wortmann hatte ich letztens ein System, wo die Wortmann nach 8 Jahren Laufzeit sagte: Sorry, können wie nicht mehr anbieten. Fujitsu und Co. kannste max. noch durch Drittanbeiter Garantieseitig verlängern... Ist aber auch wieder aufwand und dann eben ein neues Unternehmen in der Kette. Ich war viele Jahre auf Fujitsu festgelegt und punktuell hatten wir immer mal wieder HP und Dell in den Fingern. Bei Wortmann stimmt aber das Gesamtpaket und passt für uns und unsere Kunden besser.

Wortmann deckt sich noch mit Intel Boards ein und wird dann auf/mit MiTEC umstellen/weitermachen. Der Kollege meinte allerdings auch, dass MiTEC schon länger für Intel hinter den Kulissen produziert... Heißt aber wohl auch, dass dieser MIST mit den DNS/IP Adressen in der BMC sich wohl nicht so schnell verbessert.

Interessant, wohin das Thema geführt hat... da werde ich glatt mal bei meinem Wortmann Vertrieb anfragen! Danke für die Randinfo!!!

Ja das ist von allen Varianten wahrscheinlich die Beste, wenngleich wir es bei diesem Kunden erstmal dann doch mit HMAIL machen ("müssen") werden. Ein eigenständiger MTA (Firewall geht wie gesagt nicht) der losgelöst vom Serverblech ist, deckt damit alles ab, was notwendig ist. Danke @Intel für diesen Mist!!!!!!!

Ist eine Wortmann Maschine, nagelneu! Hatte das bereits mit dem Wortmann Support erörtert, der diesen Intel-Schwachsinn bestätigt hat... Firewall ist Sonicwall, die hat sowas leider nicht... verweisen auf Ihre E-Mail Security Lösung. Ein Unglück kommt halt selten allein.

Das ist ja fast älter als alle meine Kinder zusammen!!! Ja da wäre ich doch eher vorsichtig... die SMTP Daten sollten jetzt nicht irgendwo im Netz landen...

Müsst ihr dann aber mit den/der festen IP des SMTP Servers arbeiten... das möchte ich aber nicht. HMail ist mir eigentlich auch schon zu viele Aufwand... sollte wirklich eine kleine Lösung sein, die als Dienst läuft.

Moin allerseits, habe hier einen Kunden, der keinen Exchange oder anderen Mailserver im Netz nutzt. Leider kann die Intel BMC des neuen Hyper-V Servers kein DNS!?!?!?!? Demzufolge kann ich der BMC nicht mitteilen, dass sie DNS Namen für den SMTP Versand nutzen soll... sie übernimmt die Einstellungen schlichtweg nicht! Gedanke war jetzt einfach auf einer der VMs einen simplen SMTP Relay Dienst zu installieren, der dann für den Versand zuständig ist und via IP von der BMC angesprochen werden kann. Klar ist auch nicht ganz ideal, weil wenn das Blech tot ist, kann auch keine VM mit SMTP Relay Mails versenden aber immer noch besser als keine Benachrichtigungen und 90% der häufigsten Störfälle dürften damit abgedeckt sein. Sowas wie Multisendcon wäre schon schön aber ich hätte gern eine kostenlose aber vertrauenswürdige Lösung. Kann jemand von euch was empfehlen?

Ich will gerade prüfen, wie ich diesen Kram in unseren Firewall sperren kann, finde zwar an allen Ecken Berichte, die sich (zurecht) über diese TLD beschweren aber irgendwie keine vertrauenswürdige .zip Domain, die man einfach mal aufrufen kann um seine Einstellungen zu testen. Mein Ziel: Einfach jeglichen Zugriff auf *.zip Domains sperren.

Kam vielleicht nicht ganz richtig rüber: Selbstverständlich sollte das hier erstmal "Input sammeln" sein um das Thema zu beleuchten. Ob es dann umgesetzt wird/praktikabel ist, steht auf einem anderen Blatt und hängt natürlich von der anzuwendenden Umgebung ab. Die Konstellation bei den Ukraine Leaks ist hier doch etwas kleinteiliger, weil der Kreis der Personen mit den betreffenden Daten doch deutlich kleiner ist. Danke erstmal für's erste Feedback an alle!

Das hier: ...vor unerlaubtem Datenexport bspw. von Mitarbeitern... Das Setzen von NTFS Berechtigungen (was selbstverständlich bereits der Fall ist) heißt doch noch lange nicht, dass ich den Leuten auch ermöglichen möchte die Daten beliebig oft zu kopieren... Fragen wir mal so: Wie machen es Unternehmen, die hoch kritische Geschäftsgeheimnisse auf den Platten haben. Wie stellen die Sicher, dass die Daten nicht auf externe Datenträger gehen, wenn sie trotzdem Datenträger für die Arbeit erlauben müssen... Einfaches Beispiel wäre eine Visio Doku... Hab mich da etwas unglücklich ausgedrückt... Daher zieh ich das mal anders auf: Backup Software wie Veeam und Backup Exec werben doch doch damit, dass sie bei B2D die Sicherungsfiles sicher vor Cryptoangriffen ablegen... sowas in der Art schwebt mir auch vor, wobei sich die Frage nach dem "Spagat" zwischen gewollter und notwendiger Veränderung der Dateien durch die Benutzer und ungewollter Veränderungen durch Cryptoangriffe stellt... Danke, schau ich mir mal an!

Hallo zusammen, ich suche nach einem Weg einen bestimmten Ordner auf einem Server (aktuell freigegeben und via DFS als Unterordner in einem Netzlaufwerk angebunden) für die Nutzer: A. zu verschlüsseln (Cryptotrojaner Schutz und Schutz vor unerlaubtem Datenexport bspw. von Mitarbeitern) B. nur zugreifbar zu machen, wenn man den Schlüssel für die Entschlüsselung besitzt... Damit würde selbst beim simplen kopieren der Daten auf ein USB Stick die Daten nur dann lesbar, wenn man den Schlüssel/das Passwort dazu kennt/besitzt. Bitlocker wollte ich eigentlich nicht einsetzen. Könnt Ihr Alternativen empfehlen?

Danke, hatte mich chatGPT auch drauf gebracht, war aber zu faul da auf die Schnelle was zu suchen, was ich dann jetzt noch mal gemacht habe. Hier das Ergebnis: CONNECTED(000000D0) Didn't find STARTTLS in server response, trying anyway... 04190000:error:0A00010B:SSL routines:ssl3_get_record:wrong version number:ssl\record\ssl3_record.c:355: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 257 bytes and written 330 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) Würde sagen, dass das recht eindeutig ist und der Server kein STARTTLS anbietet... Wenn ich das mit einem Test in richtung bspw. 1und1 SMTP Server versuche schaut das Ergebnis deutlich anders aus.

Hallo zusammen, kann jemand ein Tool empfehlen, mit dem man im LAN einen SMTPS Server testet? Mir gehts aktuell um Troubleshooting. Hab da einen Tobit David Server auf Windows laufen aber so richtig nimmt der aus dem WAN keine Mails via TLS an. Spuckt nur folgendes aus: 250-TURN 250-ETRN 250-8BITMIME 250 SMTPUTF8 SendTCPDataSSLEx: (00000712) write (130) (00000712) No more data available: Got=-1 [712] 421 betreffendedomain.de Service not available SendTCPDataSSLEx: (00000712) Write failed: [ 712] SMTP RX Connection closed