mcdaniels
-
Gesamte Inhalte
1.840 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von mcdaniels
-
-
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
-
vor 2 Stunden schrieb Nobbyaushb:
Moin,
das ist meines Wissens nur in einer Hybriden Version möglich, jedenfalls wenn du ohne manuell eingreifen zu müssen die bisherige Maildomain verwenden willst.
sonst eben User (at) Firma.onmicrosoft.com
Wie gesagt, mein Wissensstand
Was meinst du konkret mit hybrider Version?
vor 22 Minuten schrieb MrCocktail:Hi,
kurz und knapp, nein, kann man nicht, wenn man es stabil betreiben möchte.
Da man ja, wenn man eine gesyncte Identität hat, auch aus Support Gründen einen Exchange braucht, macht es auch keinen Unterschied mehr.
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!
-
vor 20 Minuten schrieb NilsK:
Weder hast du (anscheinend) ein Konzept von "maximaler Sicherheit" noch eins von "User dürfen nicht so eingeschränkt werden, dass ...". Ohne diese Begrenzungen wirst du aber kein passendes Konzept aufbauen können.
richtig, ich hab in diesem Kontext noch kein Konzept von maximaler Sicherheit. Deshalb versuchte ich hier ein wenig Input zu bekommen.
vor 21 Minuten schrieb NilsK:Meiner Erfahrung nach wirst du nicht eine Definition davon haben bzw. brauchen, sondern mehrere, weil auch in eurem Unternehmen die Anwender sicher unterschiedliche Arbeitsbereiche haben.
Nein haben wir nicht.
vor 23 Minuten schrieb NilsK:Da du immer das heimische WLAN der Anwender erwähnst: An dem wird ja kein Weg vorbei gehen. Irgendwie müssen die Notebooks ja an das VPN rankommen.
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?
-
vor 2 Minuten schrieb BOfH_666:
Also Backup und Recovery sind mindestens genauso wichtig wie der Bedrohungsschutz an sich.
ich fotografier jeden Tag die Inhalte jeder Word- und Exceldatei
-
vor 15 Minuten schrieb BOfH_666:
Wenn das Haupteinfallstor für Schädlinge z.B. der Mail-Client ist, kann Dir die teuerste und beste Firewall auch nicht mehr helfen. Dann kommt die Bedrohung quasi von Innen.
Stimmt. Hier kann ich aber ggf. zumindest mit einem SMTP(S) Scan entgegenhalten
Fischt mir bislang 99% der "bösen" Mails weg.
-
vor 1 Minute schrieb NilsK:
Dass man zuhause "direkt im Internet sei", ist in aller Regel schon lang nicht mehr so. Auch Heimrouter haben einen okayen Firewallschutz, dazu kommt das, was Windows mitbringt. Wir sind nicht mehr im Jahr 2000. Und gegen moderne Bedrohungen für Clients hilft eine Unternehmensfirewall oft auch nicht viel, weil sowas eben heute völlig anders funktioniert.
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).
vor 7 Minuten schrieb NilsK:Am Ende eine Sache der Abwägung - man kann Maßnahmen aus meiner Sicht nicht bewerten, ohne das Szenario zu kennen.
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.
vor 34 Minuten schrieb NilsK:Ein "VPN-Zwang" wird das Risiko typischerweise nicht verringern, sondern erhöhen.
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).
vor 34 Minuten schrieb NilsK:Moderne Malware kann im gesicherten Firmen-LAN genauso zuschlagen wie im Heim-WLAN.
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.
vor 34 Minuten schrieb NilsK:Wie wäre es, wenn du dich erst mal allgemein informierst und dann mit konkreten Fragen kommst?
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?
vor 34 Minuten schrieb NilsK:"von - bis". Ein lokaler User statt eines Domänenusers löst jedenfalls kein einziges Problem, schafft dafür aber viele neue. Warum würdest du das erwägen?
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.
-
1
-
-
@daabm: Danke für die Blumen. ;)
vor 4 Minuten schrieb daabm:Doch - so ein Mid-Size Familienunternehmen mit 10 bis 20 k Accounts, das wäre meine Wunschumgebung.
ok, jetzt sag ich nix mehr ... mit meinen rund 120 Arbeitsplätzen und 15 Servern.
-
vor 5 Minuten schrieb daabm:
Makro-Policies
wenigstens das gibts ;) nebst einer sehr guten Filterung & UTM-Appliance. Bislang keine Probleme gehabt, aber ich will es nicht verschreien.
vor 5 Minuten schrieb daabm:AppLocker oder Software Restriction Policies (SRP) sind eine gute Gegenmaßnahme. Erstaunlich günstig (da in Windows enthalten), erstaunlich einfach "grundlegend" zu konfigurieren, erstaunlich wirksam.
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
-
vor 4 Minuten schrieb MurdocX:
Muss es auch nicht. Meiner Meinung nach ist der „Admin“ breit gefächert. Da braucht es einfach einen der nur im Bereich Sicherheit arbeitet. Für kleine und mittelständische Firmen ist es schwer, denn das Bewusstsein auf geschäftlicher Ebene für Sicherheit im Allgemeinen fehlt oder wird unterbewertet.
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.
-
vor 17 Minuten schrieb daabm:
Das weiß von uns niemand, da wir nicht wissen, wie Deine Domäne aussieht. Hier werden alle (!) lokalen Benutzerrechte (47 Stück, in der Tat) und Gruppenmitgliedschaften per GPO durchgesetzt, lokale Änderungen sind durch lokale Admins zwar möglich (geht auch nicht zu verhindern, Admin ist Admin), aber nicht persistent. Ob das bei Dir auch so ist? Warum sollte ein Domain Admin bei Dir in den lokalen Admins drin sein - oder warum sollte er das nicht? Ich kann es nicht sagen.
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.
vor 17 Minuten schrieb daabm:Ja, Klassiker. Ameisenlöwe - Loch graben, reinlegen, auf Beute warten
Sofortige Minimalprävention: Cached Credentials auf 1 runtersetzen. Aber halt nur minimal. Besser siehe oben, Deny logon locally.
vor 20 Minuten schrieb MurdocX:Das war symbolisch für die Dame auf dem Schachbrett. In einem Fall hat er sich den Hash eines Domänen-Admins auf einem Client geschnappt und konnte sich dann damit am DC anmelden. Einmalige Anmeldung an einem Client reicht um sich das Bein zu stellen. Der Klassiker. Deshalb der deutliche Hinweis der Kollegen hier, zur Erklärung.
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).
-
vor 13 Minuten schrieb NorbertFe:
Hat er doch. Der Tag hat 24h und die Nacht nochmal 12h und nachmittags sind auch noch 6h genau wie vormittags. ;)
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... ;)
vor 41 Minuten schrieb MurdocX:Ein Pentester hat bei einem Freund den Domänen-Admin mehrmals in 1,5 Tagen fallen gelassen.
...was meinst du mit "fallen gelassen" ?
-
vor 8 Minuten schrieb NorbertFe:
Und das bedeutet was für deine Umgebung? ;)
...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?
-
vor 4 Minuten schrieb NorbertFe:
Wie dir gesagt wurde, haben domänenadmins auf einem pc genau nichts verloren!
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?
-
vor 7 Minuten schrieb daabm:
Ja, sag ich doch. "whoami" sagt Dir, in welchen Gruppen du EFFEKTIV Mitglied auf dem Client bist. Administratoren fehlt. Und die Domain Admins sind nicht in der "lokalen" Gruppe "Administratoren"; sondern in der "domänenlokalen" Gruppe "Administratoren". Kleiner, aber wesentlicher Unterschied.
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?
-
vor 12 Minuten schrieb daabm:
In deinem whomai-Output oben steht aber nichts von "Administratoren"... Und eine Konsole braucht man dafür auch nicht: "net localgroup administratoren" reicht meistens
Am Domänencontroller sind sie dabei. Allerdings werden sie mir auf dem einen Client nicht angezeigt mit whoami /groups
-
vor 2 Minuten schrieb MurdocX:
Sind die Domänen-Admins noch Mitglied in den Administratoren?
lusrmgr.msc ist die Konsole zum nachsehen.
Ja, gerade geprüft.
-
Hi,
whoami /groups:
Benutzer
Ineraktiv Gruppe
Konsolenanmeldung
Diese Organisation
Lokal
Richtlinien-Ersteller-Besitzer
Domänen-Admins
Schema-Admins
vor 27 Minuten schrieb daabm:PS: Warum meldet sich ein Dom-Admin auf einem Client an? Der hat da nichts verloren, dafür erstellt man sinnvollerweise eine AD-Gruppe "Client-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.
Mai Patchday - Probleme: Vorgangsweise manuelle "Hotfixes"
in Windows Server Forum
Geschrieben
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:
Standalone-Updates (die bisherigen Windows-Updates müssen zuvor installiert werden):
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!