mcdaniels

Hallo, die Updates des Mai-Patchdays verursachten auf DCs ja tlw. Probleme bei der Anmeldung. Nun stellt MS hierfür quasi "Hotfixes" bereit, die allerdings NICHT via WSUS kommen sondern manuell geladen und installiert werden müssen. Korrigierte Updates Kumulative Updates: Windows Server 2022: KB5015013 Windows Server 20H2: KB5015020 Windows Server 2019: KB5015018 Windows Server 2016: KB5015019 Standalone-Updates (die bisherigen Windows-Updates müssen zuvor installiert werden): Windows Server 2012 R2: KB5014986 Windows Server 2012: KB5014991 Windows Server 2008 R2 SP1: KB5014987 Windows Server 2008 SP2: KB5014990 Wie geht man hier richtig vor? Bei Server 2012 / R2 müsste man also zuerst alle Updates einspielen die automatisch kommen und dann die entspr. KB herunterladen und manuell installieren? D.h. ich handle mir aber mit der automatischen Installation die Bugs ein? (oder hat MS die fehlerhaften Updates mittlerweile zurückgezogen?) Bei Server 2016 und neuer (automatische Updates sind noch nicht installiert): Ich installiere KEINE automatischen Updates sondern lade das "gefixte" Update manuell herunter und installiere es? Wird das "gefixte Update" dann im nächsten kumulativen Paket (Patchday Juni) dabei sein, oder ist selbiges IMMER manuell zu installieren? Danke!

Hallo, herzlichen Dank für eure Mühe und die Antworten. Unterm Strich kann also festgehalten werden, dass eine wirklich praktikable und in letzter Instanz saubere und sinnvolle Lösung nur dann möglich sein wird, wenn man die Kommunikationsplattform auf MS-Exchange basiert, wo dann quasi alles aus einer Hand kommt. Alles andere ist Flickwerk und mit Einschränkungen verbunden. LG

Was meinst du konkret mit hybrider Version? deinen zweiten Satz versteh ich nicht. Welche Supportgründe meinst du. D.h. also ich brauche UNBEDINGT einen Exchange Server. Entweder on premise, oder in der Cloud (Office 365). Ich müsste also meine / unsere gesamte Infrastruktur umstellen, da wir Exchange nicht einsetzen, sofern ich MS Teams sinnvoll einsetzen will. Wenn Exchange online verwendet wird, müsste ich die MX Records anpassen bzw. einige DNS Einträge setzen (Die Mails laufen ja dann in der / über die MS Cloud, sozusagen). Wie wäre das, wenn der Exchange intern läuft, mach das einen Unterschied? Danke nochmals für eure Hilfe.

Liebe Community, ist es möglich MS Teams im Unternehmensumfeld ohne MS Exchange bzw. Office 365 (mit Exchange online) einzusetzen, wenn man von MS Teams zumindest folgende Funktionen benötigt / folgende Infrastruktur hat: Verwendung der firmeneigenen Emaildomain u.a. für das Login / Versenden von Einladungen. Verwendung eines NICHT Exchange Servers (Mails laufen nicht über Microsoft) Besprechungen/Konferenzen planen/durchführen/aufzeichnen/transkribieren (Einladungen versenden). Danke!

richtig, ich hab in diesem Kontext noch kein Konzept von maximaler Sicherheit. Deshalb versuchte ich hier ein wenig Input zu bekommen. Nein haben wir nicht. ich meinte auch nicht das WLAN oder LAN der Anwender, sondern einfach das, dass es ein "Fremdnetz" ist. Auch ist mir klar, dass ein VPN nichts mit Sicherheit in dem Sinne zu tun hat. Jedenfalls danke für die Antworten.

Zur Zielsetzung: Hauptziel ist es, mit den vorhandenen Mitteln das Maximum an (vermeintlicher) Sicherheit bzgl. Außendienstlaptops herauszuholen. Zusätzlich soll das "Verbesserungspotential" (bzgl. die Sicherheit) eruiert werden. Die Mitarbeiter dürfen hierbei auch nicht so eingeschränkt werden, dass sie nur noch via VPN arbeiten können. (Das wäre mir am Liebsten gewesen). Vorhanden: UTM Appliance (Content-Filter, Mail-Filter, DNS-Filter, IPS) Zugang von außen via VPN (über die Appliance) mit Username / Passwort kombiniert mit Hardwaretoken. Über das VPN dann auf den Terminalserver. Einschränkung des Zugriffs von außen auf die IP des Terminalserver im LAN. Verwendetes Konto zum Anmelden am Laptop = Domänenaccount mit Cached credentials (Hier wäre meine Idee gewesen, für RDP im Außendienst ein lokales Konto zu verwenden. Dies wurde aber ad absurdum geführt). Notebooks sind Bitlocker-verschlüsselt. Nice to have: Möglichkeit die Außendienst-Endgeräte auch dann zu "monitoren" wenn sie sich nicht innerhalb der VPN Verbindung, oder dem LAN bewegen. (Also zb im WLAN zu Hause sind) Fragen: Oben Beschriebenes ist alles, was ich bezüglich Remotezugriff mit den vorhandenen Mitteln "liefern" kann. Seht ihr hier ein gravierendes Problem? Die User bewegen sich auch wenn sie zu Hause in ihrem WLAN sind und surfen mit dem Domänenaccount. Auch dies ist grundsätzlich ein gangbarer Weg in einem solchen Szenario?

ich fotografier jeden Tag die Inhalte jeder Word- und Exceldatei

Stimmt. Hier kann ich aber ggf. zumindest mit einem SMTP(S) Scan entgegenhalten Fischt mir bislang 99% der "bösen" Mails weg.

Ja, ich weiß. Ich meinte ohne zb. eine Firewallappliance wie eine Fortigate. Eine moderne Unternehmensfirewall kann aber zb Verbindungen zu Botnets blockieren, oder aber einen SSL Scan durchführen. (Hier können wir dann darüber diskutieren, wie legitim ein derartiger Scan ist). Wir fangen gerade erst damit an, das wirklich zu forcieren und ich wollte eure generelle Meinung dazu hören (lesen).

Hallo Nils, grundsätzlich ist es ja bei uns schon so, dass wir via VPN -> RDP (auf einem Terminalserver) arbeiten. (mit den Mobilgeräten und auch was das Homeoffice betrifft). Das hatte ich aber im Startthread erwähnt. Mein Gedankengang war der, dass ich so die Kontrolle darüber habe, was der User zb ansurft & Malwarescan & Contentfilter ... (da der Datentransfer dann über die Firmenappliance läuft und eben nicht "einfach mal so" direkt über einen WLAN Router der daheim steht (ohne diverse Scans und Kontrollen). Natürlich. Jedoch differenziere ich hier eben ein wenig, da ich im Firmen LAN wenigstens einige Ausstattung habe, die man eben zu Hause nicht hat. Ausstattung, die beim Surfen schonmal einiges "wegfischt". @home hab ich das nicht, wenn ich "quasi direkt" im Internet bin. Ist die Variante: Home-Office-Endgerät -> VPN -> RDP (Terminalserver) also quasi als Standard zu sehen? Was meinst du mit "Notebooks als dummes Teminal" ? So eingeschränkt, dass man quasi nichts darauf machen darf bis auf die VPN/RDP Lösung? Wenn ich keinen direkten Zugriff habe, muss ich mich auf dem mobilen Endgerät (bei Zugriff auf die Firma) an sich nicht mit dem Domänenkonto anmelden (man arbeitet ja via VPN & dann RDP). Ich dachte an eine Trennung: Wenn unterwegs lokaler User / VPN / RDP (eigenes Profil) / wenn im LAN (Domänenkonto). Danke!

Hallo, wie geht ihr mit Notebooks um, die einerseits von Mitarbeitern im Außendienst verwendet werden, andererseits aber auch in der Domäne (im internen Netzwerk) Verwendung finden? Die Mitarbeiter können auch von zu Hause aus (via VPN) auf das interne Netzwerk zugreifen. Sie melden sich hier mit den Cached Credentials der Domäne an (mit einem Standaruser ohne Adminrechte). --> Vermutlich ist hier ein lokaler User einzurichten und dieser für das Arbeiten außerhalb des Domänennetzwerk jedenfalls vorzuziehen? Momentan lösen wir das (schematisch) so: Mitarbeiter (daheim oder unterwegs) -> SSL VPN -> Terminalserver (internes Netzwerk) Dennoch schließt dies nicht aus, dass Mitarbeiter X das Notebook @home im Wlan hat und dort dann in der Gegend rumsurft. Angenommen er würde sich etwas "einfangen" und würde das Notebook dann wieder an die Domäne hängen, wäre dies ggf. ein großes Problem. Welche Möglichkeiten gibt es, diese Situation zu verbessern? Ich denke da an einen VPN Zwang. Sprich also, wenn der MA mit dem Gerät surfen will, geht das nur, wenn er zuvor die VPN Verbindung aufgebaut hat. Er surft dann über die VPN Verbindung und die Firewall in der Firma. Gibt es eine solche Möglichkeit und ist das sinnvoll? Weiters wäre eine Device Management Software sicher nicht schlecht, die die Geräte auch dann "überwacht" wenn sie nicht direkt mit dem Netzwerk verbunden sind. (z.b. in Form einer Software, die die Geräte auch dann monitored wenn sie eben nicht über die VPN Verbindung im Internet aktiv sind). Anm.: Wenn man eine VPN Verbindung erzwingen kann, ist dies dann zumindest in dieser Form hinfällig. Freue mich auf eure Expertise. Danke!

kurzes Update der Situation: Die Sache mit der Adaptierung der lokalen Admingruppe (auf den Domänen-PC) via GPO funktioniert schonmal.

@daabm: Danke für die Blumen. ;) ok, jetzt sag ich nix mehr ... mit meinen rund 120 Arbeitsplätzen und 15 Servern.

wenigstens das gibts ;) nebst einer sehr guten Filterung & UTM-Appliance. Bislang keine Probleme gehabt, aber ich will es nicht verschreien. du willst mir grade mitteilen, dass mir die Arbeit sicher nicht ausgeht ;) Falls hier jemand mitliest, den das auch interessiert, hab ich grade das ergoogelt: https://www.gruppenrichtlinien.de/artikel/applocker-oder-software-restriction-policies-loecher-im-sicherheitszaun

Das wäre schön, wenn man sojemanden hätte. Ich mach halt so gut wie alles allein und wir sind nicht ganz so klein. Wie du sagst: Das Bewusstsein für Sicherheit wird unterbewertet. Das Drama dabei ist, dass -selbst wenn man es klipp und klar auf den Tisch bringt - heißts oft... Wieso... ? Geht ja eh alles. Diese Einstellung werde ich aber in diesem -meinem- Leben nicht mehr ändern können. ich muss nur das mir mögliche Maximum rausholen und schauen, dass die "Hütte" läuft.

Der Punkt war der: Es hat alles funktioniert, bis ich heute das aktuellste Windows 10 auf diesem einen Client installiert hab. Ich habe bezüglich die lokalen Gruppen / Benutzer (auf den PC) nie etwas modifiziert. Den Domänen-Admin und die Gruppenzuordnungen in der Domäne gibt es, seit die Domäne besteht. (Die Standardgruppen wurden nicht adaptiert). Deshalb hats mich halt so gewundert. Wahnsinn... Wäre dann wohl zb auch im Falle von div. Cryptolockern der Fall, die ja auch so arbeiten (Passwörter etc. abgreifen ev. auch über den Hash (oder gar keylogger) -> Domänenadmin -> dann gute Nacht). Deshalb wärs ja nicht schlecht, wenn man im Betrieb einen Spezialisten hat, der sich nur mit derartigen Dingen beschäftigt. Sicherheit, Hardening etc. Als eierlegender-Wollmilchsau-Admin ist das halt schwierig. (Extrem breites Spektrum, das es abzudecken gilt). Soll jetzt keine Entschuldigung sein. Ist einfach schwer, immer vorne dabei zu bleiben. Wie @MurdocX sagt ist das alles ein laufender Prozess... Danke für die Warnung! (Im Nachhinein gedacht, hätte ich da aber auch selbst draufkommen können).

Stimmt, daran habe ich noch gar nicht gedacht. *lach* So ich habe jetzt zumindest mal die AD Gruppe erstellt. Einen neuen User erstellt, der in der Gruppe ist. Eine Test-Group-Policy bzgl. Group Policy Preferences angepasst (lokale Benutzer und Gruppen -> Administratoren (integriert) -> Die Client-Admin-Gruppe hinzugefügt) Morgen schau ich dann ob diese Anpassung auf den Testclients ankommt. Danach werd ich mich nochmals eingehend mit der Konfiguration lt. Blogartikel beschäftigen. Ich mein, jetzt wo der Tag ja eh 48 Stunden hat.... Danke @NorbertFe :-P Vielen Dank nochmal. Vor allem für den Link und die zusätzliche Erklärung! Was auf dem einen Client diese Situation ausgelöst hat, ist aber nach wie vor unklar... ;) ...was meinst du mit "fallen gelassen" ?

...dass mir das jetzt gar nicht passt, wie das aktuell eingerichtet ist. ;) ...dass ich das jedenfalls angehen will... ...dass ich hoffe, dass der Arbeitstag bald 48 Stunden hat.... Nachsatz: ...dass ich anfange zu hoffen, dass ich nix verbiege. ;)

Vielen Dank euch allen. Na das wird ja ein Spaß. Wobei: Ist das Ausgangsproblem mit dem Client mit der aktuellsten Win 10 Version nun ein Sicherheitsfeature, oder ist auf dem Client einfach etwas verbogen? Nebenbei erwähnt: Ich möchte nicht wissen, wie oft das nicht so wie im Link beschrieben umgesetzt ist... Sprich -> Domänenadmin wird für alle Adminaufgaben verwendet.

da hat sich was überschnitten... ;) Gibt es bzgl. des Client-Admin ein best-practise Beispiel?

ich bezog mich nur auf das was daabm gesagt hat um das grundlegende Problem zu verstehen, wenn ich jetzt vom Clientadmin anfange, wird das unklar, denk ich. Gibt es bzgl. des Client-Admin ein best-practise Beispiel?

Ok. Ich muss also die Domänen-Admins in die lokale Gruppe (am Problem-PC) der Administratoren hinzufügen, dann sollte das wieder klappen. Hab ich euch da korrekt verstanden?

Am Domänencontroller sind sie dabei. Allerdings werden sie mir auf dem einen Client nicht angezeigt mit whoami /groups

Ja, gerade geprüft.

Hi, whoami /groups: Benutzer Ineraktiv Gruppe Konsolenanmeldung Diese Organisation Lokal Richtlinien-Ersteller-Besitzer Domänen-Admins Schema-Admins Guter Einwand. Werd das gleich mal ändern bzw. einen Clientadmin anlegen. Wenn an sich nix bekannt ist, kann es gut sein, dass die Kiste einfach einen Tusch hat und neu aufgesetzt werden sollte. Bezüglich Fehlermeldung: zb. beim Versuch via Systemsteuerung die IP Konfigruation zu ändern: Ich klicke auf IPV4 -> Eigenschaften -> dann will der PC eine Authentifizierung -> ich gebe den Domänenadmin ein (jetzt dann den Clientadmin) mit Kennwort und: Sie verfügen nicht über die erforderlichen Berechtigungen um die Verbindungseigenschaften zu konfigurieren. Setzen Sie sich mit dem Administrator in Verbindung.