wznutzer

Guten Abend, weil es hier angesprochen wurde, ja ich versuche schon ein Schutzkonzept (Tier 0 usw.) umzusetzen. Den Restore habe ich mir nicht aus der Sicht, dass ein Update den AADC kaputt macht vorgestellt. Ich denke, dann habt ihr das schon erlebt. Mein Restore-Konzept wäre gewesen, neuer DC, replizieren lassen, alter raus aus der Domäne und AADC lt. meiner Doku neu installieren. Aber das will ich natürlich nicht jeden Monat machen, weil es ein Update von AADC gibt. Wenn es da ein erhöhtes Risiko gibt, habe ich darauf keine Lust und ich lasse das. Meine Motivation war einfach, wegen so einem kleinen Programm nicht eine weitere VM haben zu müssen auf die ich aufpassen muss. Ab Herbst hätte ich auf einem Host eine Datacenter-Lizenz. Da würde die separate VM noch nicht einmal etwas kosten. Vielen Dank für euren Input.

Guten Abend, lt. Doku ist es problemlos möglich AADConnect auf einem Domänencontroller zu installieren, aber ist das eine gute Idee? Lt. Microsoft muss der Server ohnehin so "beschützt" werden wie alle Member in Tier 0. Es muss ein SQL-Server installiert werden, da ist jetzt eher so mittelgut auf einem DC, aber ist es so schlimm? Bei Problemen mit AADConnect müsste ich vielleicht mal den Server starten, dann ist auch der DC weg, aber ich habe ja sowieso mehrere. Der DC ist nicht mehr identisch zu den anderen, wäre aber auch egal. Ein DC ist ja schnell installiert und hinzugefügt. In einer sehr großen Umgebung ist das vielleicht etwas anderes, aber bei < 200 User will mir kein trifftiger Grund einfallen das nicht zu tun. Evtl. irre ich mich, aber deswegen frage ich. Danke und Grüße

Inzwischen ca. 130 User. Jede Menge Einstellungen, Gerätschaften und vergebene Rechte und leider erst seit ca. 5 Jahren vollständig dokumentiert. Davor . Ja, Upgrade. Habe ich bei faq-o-matic glatt übersehen. Danke. Aber ich habe verstanden. Es gibt keinen technischen Grund das unbedingt machen zu müssen. Vielen Dank

Guten Tag, mich würde eure Meinung interessieren. Gegeben ist eine Domain firma.local die komplett auf Server 2022 migriert werden soll. Nun frage ich mich, ob es mir irgendeinen Vorteil bringt eine neue Domäne firma.de zu machen und mit ADMT zu migrieren. Die Anmeldung mit @firma.de kann ich ja auch mit einem Suffix machen. Gibt es einen gravierenden Nachteil bei firma.local? Mir fällt keiner ein und bemerkt habe ich auch noch nichts. Grüße und Danke.

Das habe ich verstanden und will da auch gar nicht dagegen argumentieren. Die Idee war ja, durch das Trennen per Multiboot, beide Bereiche zufriedenstellend abzudecken. Und da scheinen die Meinungen auseinander zu gehen mit der Tendenz: Nicht so schlecht , aber wenn möglich lass es lieber.

Ja, z. B. ob das überhaupt stimmen kann. Weil die Anzahl der Computer im Internet auf 4,9 Mrd. geschätzt wird und somit 1/5 betroffen gewesen wäre. Ich kann ja nicht in Panik ausbrechen, sondern muss entscheiden ob das was mit Smartphones gang und gäbe ist, auch auf Windows-Rechner übertragbar ist. Wenn nicht, dann ist das auch in Ordnung, aber ich muss das schon stichhaltig mit einem realen Szenario begründen. Genau um solche Meinungen zu hören suche ich ja den Austausch. Was ich selber denke weiß ich ja schon .

Hoppla: https://www.it-daily.net/it-sicherheit/cybercrime/uefi-malware-bleibt-bedrohung-fuer-privatanwender-und-unternehmen Über eine Milliarde Windows-Rechner weltweit waren von Lojax betroffen.

Wir hantieren da ja mit Wahrscheinlichkeiten. Ich bin mir der Gefahr bewusst, aber wie groß ist die Gefahr, dass das passiert? Das versuche ich herauszufinden, ob das akzeptabel ist. Klar ist natürlich, dass ich am Ende kein Konstrukt will das aufwändiger, teurer und unsicherer ist, als wenn ich jedem Kollegen einfach ein separates Notebook in die Hand drücke. Da würde ich einfach den Rat des CSP einholen, wenn das relevant wird. Wobei das schon schräg wäre, wäre das nicht erlaubt. Eine Lizenz aus dem Abo, welche komplett lt. Bedingungen genutzt wird und eine Lizenz die mit dem Gerät zusammen erworben wurde. Das entspricht ja genau dem Grundsatz, dass jede Installation eine Lizenz benötigt.

OK, falsch im Gedächtnis abgespeichert. Müsste trotzdem OK sein, weil der geschäftliche Zweck dem entspricht und für die private Nutzung der Key aus dem Bios (W10 Pro) verwendet werden könnte. Zielkonflikt. Dem Mitarbeiter den Vorteil zu bieten sich kein eigenes Gerät anschaffen zu müssen und trotzdem alle geschäftlichen Anforderungen zu erfüllen. Aber wenn es keine zufriedenstellende Lösung gibt, ist auch das ein Weg. Die Idee ist eine Vereinbarung zu treffen, dass private Daten in der Verantwortung des Nutzers liegen und die Nutzung das Einverständnis darstellt im Fall der Fälle ein frisches Windows zur Verfügung gestellt zu bekommen und den Rest selber erledigen zu müssen. Variante 2 ist derzeit mein Favorit. Nur bei der Ausbreitung von Malware vom privaten OS auf das geschäftliche bin ich mir nicht 100%ig sicher. Aber wenn es sich nicht gerade um eine raffinierte Malware für das UEFI handelt, doch eher unwahrscheinlich. Für Variante 3 habe ich noch keine genaue Vorstellung ==> zu wenig Wissen über Microsoft Intune. Ich lese nur, dass sich damit auch auf W10 Geräten ein privater Bereich abbilden lässt. Ich hatte auf Erfahrungen gehofft . Mit privat ist wirklich "ohne Einschränkung" gemeint, also: "Klick auf alles was du meinst, es ist privat und trifft die Firma nicht." Auch wenn es auf der Firmeninstallation möglich wäre, soll es per Vereinbarung unterbunden werden.

Guten Morgen, mich würden eure Meinungen zu folgendem Thema interessieren. Für ein paar wenige Geräte (W10 Enterprise - Notebooks) soll die private Nutzung neben dem Home-Office erlaubt werden, wenn es denn von der Sicherheit vertreten werden kann. Da die Lizenzen aus einem MSDN-Abo kommen, die Geräte der Firma gehören und auch nur persönlich genutzt werden, sind beliebig viele Installationen erlaubt. Variante 1) Alles geschäftliche wird in einer Installation "auf dem Blech" gemacht und für die private Nutzung gibt es eine VM. Das funktioniert so lange bis der Nutzer externe Hardware anschließen will. Von der Sicherheit gibt es wenig Bedenken, wenn der User sich an die Richtlinien hält. Variante 2) Beim User wird W10 2x installiert (Multiboot). 1 x geschäftlich 1 x privat. Das hätte den Reiz, dass der User alles nutzen kann. Unter W10 kann man zwar per Bootmanager die Laufwerke nicht mehr zuverlässig verstecken, aber die geschäftliche Installation wäre sowieso per Bitlocker verschlüsselt. Aber es gibt ja die gemeinsame Bootpartition. Könnte sich darüber Malware auf die geschäftliche Installation ausbreiten? Die Wald und Wiesen Malware wohl eher nicht, meines Wissens nach. Variante 3) Die Geräte per Microsoft Intune verwalten. Kenne ich noch nicht im Detail, aber darüber sollen sich ja auch geschäftliche und private Daten trennen lassen. Die Frage ist halt, ob sich privat installierte Malware auf die geschäftlichen Dinge auswirken kann. Privat soll der User alle Rechte haben können und alles machen können. Vielen Dank für eure Meinungen

Danke für den Link .

Als Teilzeitadmin kann ich mich natürlich immer irren . Es gibt ja die Richtlinie "Lokal anmelden zulassen". Da sind Administratoren und Benutzer drin. In den Benutzer (lokal) sind die Domänen-Benutzer drin und in den Administratoren (lokal) sind die Domänen-Admins drin. Ich habe in den Administratoren (lokal) die Domänen-Admins entfernt per GPO. Ich denke Ihr nehmt die Domänen-Admins in die Richtlinie "Lokal anmelden verweigern" auf? Kommt auf das Gleiche raus, oder? Organisatorisch ist es sowieso verboten sich mit dem Domänen-Admin (und einigen anderen) auf Workstations anzumelden bzw. zu arbeiten, die nicht zu den Admin-Workstations gehören. Etwas unbehagen bereitet mir immer, dass sich ein Kollege, der das Adminpasswort kennt, es trotzdem versuchen könnte sich auf einer Workstation mit dem Domänenadmin anzumelden, weil es halt so einfach ist, gehen tut es nicht, weil ja technisch unterbunden, aber eingetippt ist es dann ja schon. Ein Keylogger könnte das loggen. Ist das realistisch? Man sollte sich ja immer klar machen gegen was man sich schützen will, um es nicht zu übertreiben.

Vielen Dank euch für die Antworten. Der Gedanke war tatsächlich sicherheitsgetrieben. Eine Abteilung die besonders schützenswert ist wollte ich abtrennen. Aber je länger ich nachdenke, je mehr zweifle ich an meinem Vorhaben. Was ich bisher gemacht habe Domänenadmins dürfen sich nicht über das Netzwerk an den Workstations anmelden. Ebenso User aus Abteilungen mit denen sie nichts zu tun haben. Emails / Internet über einen TSE. Von diesem aus, dürfen sie sich auch nicht an Ihrem PC anmelden. Sollte jemand auf dem TSE, trotz aller Vorkehrungen, Malware starten, würde diese ja mit den Benutzerrechten der Kollegen laufen, die auf Ihren Workstations Adminrechte haben und somit hätte die Malware auch Zugriff mit Adminrechten. Die Verbindung TSE -> Workstation ist aber verboten. Die Kollegen benötigen Adminrechte (Debugger). RDP geht nur vom userspezifischen VPN (Home-Office) aus. Die lokalen User dürfen sich nicht über das Netzwerk anmelden. In der Firewall (Windows) ist alles abgedreht was ich für möglich gehalten habe. Regelmäßige Scans mit Thor-Lite. Genaugenommen habe ich MIKRO-Segmentierung betrieben, ich hatte nur kein Wort dafür . Danke nochmals. VLANs wären wohl das falsche Werkzeug aus dem Werkzeugkasten.

Hallo, wenn ich mein Netzwerk segmentiere, also z. B. eine Abteilung vom Rest per VLAN trenne, müssen ja trotzdem Zugriffe untereinander notwendig sein. Ich meine jetzt nicht ein Gastnetz oder Testnetz das komplett abgeschottet ist, sondern das produktive Netz soll untergliedert werden. Die Broadcasts werden verringert, aber das ist bei ~100 Clients nicht so sehr das Problem. Mir geht es eher um die Sicherheit. Wenn ich jetzt für eine Abteilung ein separates Segment erstelle, müssen sich diese ja immer noch am AD authentifizieren und auch Fileserver / Drucker im Netzwerk müssen erreichbar sein. Also benötige ich jede Menge Freigaben. Teilweise sollen auch die Clients untereinander Daten per Freigabe austauschen. Überlegungen Es bringt nix, einfach mal so VLANs zu erstellen und dann alles freizugeben, damit wieder alles möglich ist. Datenaustausch muss über zentrale Ablagen stattfinden. Also die Berührungspunkte der Segmente müssen reduziert werden. Das Routing nicht über die Switche machen, sondern granular über eine Firewall. Es ist kein Allheilmittel z. B. gegen "lateral movement", nur halt eine weitere Hürde. Am AD selbst ändert es nichts, das muss sowieso nach Best Practive gehärtet werden. Wenn jemand den Domänencontroller kompromittiert, hilft auch keine Segmentierung. Kann man machen, ist aber in kleineren Netzen eher dann an der Reihe wenn schon alles andere gemacht wurde (Mitarbeiterschulung, AD gehärtet, reduzierte Rechte usw.) Wie seht Ihr das. Macht Ihr das schon von Anfang an, auch in kleinen Netzen? Vielen Dank

Noch zwei Fragen zu FSLogix. Die Profile werden auf einer Freigabe per NTFS-Berechtigungen geschützt. Mehr Anforderungen gibt es nicht. Aber was ist da als performant anzusehen? Ich meine jetzt nicht die Verfügbarkeit, sondern was das Storage können muss? (1) Wenn ich die Profile z. B. auf einem per Speicher ablege der mit 10Gb angebunden ist und das Storage darunter ein Raid10 mit SATA-SSDs ist, läuft es dann mit z. B. 75 User performant? Wäre es denkbar das beim RDP-Connection-Broker unterzubringen? Am gleichen vSwitch sollte die einzige Begrenzung dann das darunter liegende Storage sein. (2) Wie würde man die Profile "aufräumen". Derzeit (lokale Profile) lösche ich 1 x täglich bei allen Usern den Browsercache und den Temp-Ordner. Man könnte das per An-/Abmeldescript machen oder einmal in der Nacht alle *.vhdx mounten und dann bereinigen (z. B. Powershell). Oder bereinigt Ihr gar nicht? Danke

OK, vielen Dank. Dann werde ich das wohl mit FSLogix machen.

Guten Morgen, erstellt man eine Sammlung auf einem RDSH kann man die Benutzerprofile direkt auf dem RDSH speichern oder Benutzerprofildatenträger aktivieren. In diesem Fall wird für jeden User eine separate *.vhdx für das Profil erstellt. Nachdem ich mir die Doku angesehen habe, kann ich mir folgende Fragen nicht erklären. 1) Wenn ich die Benutzerprofildatenträger aktiviere, dann sollte jeder Benutzer immer sein persistentes Profil haben, auch wenn es mehrere RDSHs gibt. Der User landet nach der Anmeldung auf einem RDSH in der Bereitstellung und hat durch die *.vhdx immer sein Profil. Das steht zwar nirgendwo explizit, aber so verstehe ich das. Korrekt? 2) Warum braucht es dann noch FSLogix? Mit der RDP-Cal kostet es seit der Übernahme durch MS nichts zusätzlich. Aber was kann das besser als der Benutzerprofildatenträger? Ist FSLogix vorzuziehen? Vielen Dank bereits im voraus.

Der MX liegt derzeit auf einem hMailServer mit SpamAssassin. Der hMail leitet dann an den lokalen Exchange weiter und dazwischen ist dann Sophos. Das hätte ich gerne weg. Aber klar, würde gehen. Testen? Da bekomme ich Bluthochdruck. Wenn da was durchrutscht? Meine User klicken leider auf alles was nicht bei drei auf dem Baum ist. Am ehesten sagt mir die Strategie doppelt und dreifach zu. Aber ich schaue halt auch immer, dass ich keine Ausgaben generiere die unnötig sind. NoSpamProxy soll gar nicht schlecht sein. Redoxx soll auch nicht schlecht sein, aber dieses CISS? Wie sollen denn da automatisierte Emails jemals wieder empfangen werden?

Guten Abend, ich werde wohl den lokalen Exchange nach Exchange-Online umziehen. Derzeit nutze ich einen Spamassassin mit vielen selber gebastelten Regeln und die Funktionen der Sophos UTM. Das funktioniert ziemlich gut. Bei Exchange-Online ist EOP standardmäßig aktiv und es kann das Microsoft ATP dazugekauft werden. Aber taugt EOP auch was? Ich habe mir jetzt die Doku von Microsoft EOP und ATP angeschaut und bin der Meinung, dass das unzureichend bis unbequem ist. Hat da jemand Erfahrung ob Microsoft da einen so guten Job macht, dass ich nichts anderes benötige? Ich spiele mit dem Gedanken einen NoSpamProxy davor zu setzen. Auf den ersten Blick gefällt mit gar nicht, dass es keine Quarantäne gibt, aber beim weiteren Nachdenken sollte das gar nicht so schlecht sein. Quarantäne ist ja doch ziemlich ätzend. Der User soll nicht und ich will nicht ständig die Quarantäne beobachten. Also, nutzt jemand Exchange-Online ohne eine zusätzliches Tool um Spam zu filtern und ist völlig zufrieden damit? Danke für eure Meinungen. P.S. Ich will es auch nicht ausprobieren, weil eine durchgerutschte Email die hätte blockiert werden können, könnte ziemlich blöde Folgen haben.

Entschuldige die Verspätung. Lt. der verlinkten Übersicht nur wenn es ein E3 oder E5 Abo ist. Was meinst Du mit contitional Access?

Bedeutet das, dass andere Hersteller die Limits nicht ausreizen oder Ubiquiti das einfach nicht beachtet? Bundesnetzagentur: Im Frequenzbereich 2,400 GHz - 2,4835 GHz darf die maximale Strahlungsleistung 100 mW (EIRP*) nicht übersteigen. Im Frequenzbereich 5,150 GHz - 5,350 GHz sind maximal 200 mW (EIRP*) zulässig, während im Bereich 5,470 GHz - 5,725 GHz maximal 1 W (EIRP*) abgestrahlt werden darf.

Dass der MFA-Server nicht mehr installiert werden kann von hier: https://docs.microsoft.com/de-de/azure/active-directory/authentication/howto-mfaserver-nps-rdg Bestandskunden des MFA-Servers können diesen weiterverwenden. Die Lizenzierung von hier: https://docs.microsoft.com/de-de/azure/active-directory/authentication/concept-mfa-licensing

Vielen Dank. Ubiquiti ist vergleichsweise so günstig (im Vergleich zu Ruckus), dass ich das auf einem Stockwerk testen kann. Ich werde berichten wie es geklappt hat.

Hallo, ich würde einen RD-Gateway gerne per MFA absichern. Das Problem ist nicht so sehr wie das geht oder welche Anbieter es gibt. Es ist vielmehr unter den vielen Möglichkeiten eine möglichst gute Lösung zu finden. Die Anforderungen sind: grob 50 User, der 2. Faktor sollte eine App auf dem Smartphone sein (Push-Nachricht oder Eingabe eines OTP), kompatibel mit RDG. Ich liste mal auf was ich mir schon angesehen habe (Homepage gelesen). Evtl. gibt es von euch ein paar Meinungen was Ihr erfolgreich einsetzt. Azure MFA. Die Variante mit dem MFA-Server gibt es nicht mehr und die NPS-Erweiterung ist nur mit einen Azure AD P1/P2 Abo kompatibel. Selbst vorhandene E3-Abos sollen nicht reichen. Duo (www.duo.com) Rohos (www.rohos.com) SecureMFA (www.securemfa.com) OpenOTP (www.rcdevs.com) 40 User kostenlos UserLock (www.isdecisions.com) AuthPoint (www.watchguard.com) www.wikidsystems.com So wie es ausschaut, macht man mit Duo nicht so viel verkehrt. Aber wie immer geht es natürlich auch um die Kosten. Wenn es etwas günstiger gehen würde, warum nicht. Vielen Dank

Vielen Dank für eure Einschätzungen. Ich werde mich jetzt erst mal genauer mit Ubiquiti und Aruba beschäftigen. Bei Ubiquiti braucht man ja eine Controller. Entweder so ein Cloud-Key oder (es ist ja gar nicht so teuer) diese UDM Pro. Diese UDM Pro will ja ein kompletter Security Gateway sein. Macht das Ärger wenn das nur der WLAN-Controller sein soll oder reicht dann auch der Cloud-Key V2 aus? Das Ubiquiti-Universum ist mir noch nicht so geläufig. Vielen Dank