Samba unter FreeBSD mit oder ohne Active Directory Domain Controller?

obsigna

Well-Known Member
Ich richte einen File-Server für eine kleine Firma ein, derzeit 35 Benutzer.

Ausser Dateidienste sind nur noch MySQL-DB für eine Windows Application, DNS, L2TP/IPsec-Einwahl und ipfw als Firewall installiert. Web- und Mail-Services laufen auch unter FreeBSD auf einer AWS-EC2-Instanz unter meiner Kontrolle.

Was bringt mir ein Active Directory Domain Controller unter Samba?

Was sind die Sicherheitsrisiken?
 
Naja, AD ist ja ne sache die vor allem für Windows-Clients interessant ist um eine zentrale Authentifizierung zu haben, außerdem kann man zb Gruppenrichtlinien Pushen etc etc

Ob man das bei 35 Benutzern (Alles Windows Clients?) "braucht" ist eine sehr komplexe Frage - ich kenn Szenarien da hat bereits bei unter 10 Clients sinn gemacht, und bei anderen braucht mans mit 100 Clients nicht.

Man sollte sich dann aber auch ggf. nen bisschen mit Windows, AD etc ia auskennen und am besten auch wissen wo die grenzen von SAMBA-AD vs Windows-Server sind in beide richtungen. Das ist schon eine etwas komplexere Technik
 
Ja, alles Windows 10 mit Office 365. Die Firma hat Performance-Probleme weil die keinen lokalen File- und DB-Server haben, alles in der MS-Cloud. Der Netzanschluß ist eigentlich nicht so schlecht (Glasfaser 300 MBit/s), aber nachdem denen der alte Windows-Server von 2008 abgeraucht ist, hat jemand an den Glasfaser-Router (im Bridge-Modus) einen SOHO-Router mit rudimentärer Firewall angeschlossen und der versorgt das ganze Netz -> Flaschenhals 100 MBit/s, wenn überhaupt.

Die Dateien sollen alle aus der MS-Cloud zurückgeholt werden. Und der MySQL-DB-Server soll auch wieder lokal im Netz laufen - bisher VPN in die Cloud, damit die 3306 nicht offen im Internet rumhängt - alles träge.

Ich habe mir jetzt die Sache mit den Gruppenrichtlinien durchgelesen, und ich glaube das brauchen wir hier nicht, es sei denn man könnte MS-Office 365 bei allen Usern gleichzeitig davon abhalten sich ständig mit OneDrive zu synchronisieren. Die Verzeichnis-Hierarchie auf dem Server habe ich schon mit den simplen UNIX-Zugriffsrechten konfiguriert, das reicht.
 
Bitte bedenken, dass Samba unter FreeBSD auf eher wackeligen Beinen steht, kaum Maintainer hat und ein ziemlich umfangreiches Patchset benötigt, um überhaupt unter FreeBSD zu funktionieren. Zusätzlich gibt's "nur" bis zur Version 4.16 (aktuell ist 4.18). Das ist auch alles nicht sehr umfangreich getestet und läuft eher unter "Works for me".

Wäre etwas vorsichtig das als zentralen AD in einer Firma auszurollen.
 
Wenn du nicht weißt, ob du es brauchst, brauchst du es vermutlich nicht!

Dazu kommt: Wenn ich AD wollen würde, dann mit nem MS Server. Einer der wenigen guten Gründe einen MS Server zu betreiben. Bei einem Unternehmen mit 35 Clients sollte der auch finanziell nicht ins Gewicht fallen.
 
Dazu kommt: Wenn ich AD wollen würde, dann mit nem MS Server. Einer der wenigen guten Gründe einen MS Server zu betreiben. Bei einem Unternehmen mit 35 Clients sollte der auch finanziell nicht ins Gewicht fallen.
Stimmt, in der Regel reicht eine kleine BHYVE VM mit einen aktuellen 2019/21 Server, der nur die AD Dienste zur Verfuegung stellt. Dann hat man mit ZFS darunter auch gleich die Snapshots erledigt und ggf sogar auf einer anderen BSD mit einen gleich einen Backup AD. Ich wurde mir da keinen Kopp machen.
 
Ich habe im Netz gesucht warum wir einen ADDC benötigen, und bin auf folgendes gestoßen:

Was ist ein Domänen-Controller...?
Der Domänen-Controller (DC) ist damit sozusagen die Truhe mit den Schlüsseln zum Königreich – dem Active Directory (AD). Angreifer verfügen über alle möglichen Tricks, um sich erweiterten Zugriff im Netzwerken zu verschaffen, einschließlich Angriffe auf den DC selbst. Aber Sie können Ihre DC nicht nur gegen Angriffe schützen, sondern den DC auch nutzen, um laufende Cyberangriffen zu entdecken.
Warum ist ein Domänen-Controller wichtig?
Domänen-Controller enthalten die Daten, mit denen Zugriffe auf Netzwerke geregelt und validiert werden, einschließlich aller Gruppen-Richtlinien und Computernamen. Auf dem DC liegt alles, was ein Angreifer gebrauchen könnte, um massive Schäden an Daten und Ihrem Netzwerk zu verursachen, weshalb der DC bei Cyberangriffen ein Hauptziel ist.
Brauche ich einen Domänen-Controller?
Im Allgemeinen: Ja. Jedes Unternehmen, das Kundendaten in seinem Netzwerk speichert, braucht – unabhängig von seiner Größe – einen Domänen-Controller, um die Sicherheit seines Netzwerks zu verbessern.
...
Die Einrichtung eines sicheren und stabilen DC kann Ihre Sicherheit nicht für immer gewährleisten. Angreifer werden dennoch versuchen, Ihren DC zu hacken, um sich erweiterte Berechtigung zu verschaffen oder sich lateral durch Ihr Netzwerk bewegen zu können. Varonis überwacht das AD für GPO-Änderungen, die nicht den Richtlinien entsprechen, Kerberos-Angriffe, Berechtigungseskalationen usw.
Hmm, ich sehe schon, ein DC ist eine nicht-Lösung für Probleme, die man ohne DC gar nicht hätte -- „Aber Sie können Ihre DC nicht nur gegen Angriffe schützen, sondern den DC auch nutzen, um laufende Cyberangriffen zu entdecken.“

Besonders das letztgenante Argument ist was für die ganz schweren Jungs mit dem Microsoft-Admin-Zertifikat. Die entdecken andauernd auf ihren sieben nebeneinander aufgereihten 32“ curved Monsterbildschirmen im Dark-Mode die laufenden Cyberangriffe auf ihre DCs, in der einen Hand ´ne Cola und in der anderen ´ne Pizza. Wenn ein User anruft weil er Hilfe braucht, dann hat man keine Hand frei um abzunehmen, und ausserdem hat man eh keine Zeit, weil der Hacker kurz davor ist die letzte Hürde zu knacken, und dann muß man - Cola/Pizza hin oder her - sowieso den Stecker ziehen, und das User-Problemchen spielt dann auch keine Rolle mehr. Auf’s neue 4 Wochen später, wie in Potsdam, nicht wahr?

Als FreeBSD-Leichtgewicht, das auch mal gerne die Treppe und nicht den Aufzug nimmt (geht schneller) um das User-Problem vor Ort zu lösen, hat man keine Zeit für so einen Scheiß. Die nimmt man sich für ein nettes Pläuschchen mit den Kollegen und Kolleginnen, wo man dann erfährt wo tatsächlich der Schuh drückt, so das man das System verbessern kann.

Die Frage ist also gelöst, wir brauchen keinen ADDC.
 
Es wäre schon praktisch, wenn man alle Benutzerrechte auf einem Server unter Kontrolle hätte. Dabei geht es nicht nur um die Rechte auf dem Fileserver, sondern auch um die Rechte auf dem Client. Wo darf was gespeichert werden. Was darf verändert werden. Was darf installiert werden. Was darf gedruckt werden... usw.
 
Es wäre schon praktisch, wenn man alle Benutzerrechte auf einem Server unter Kontrolle hätte. Dabei geht es nicht nur um die Rechte auf dem Fileserver, sondern auch um die Rechte auf dem Client. Wo darf was gespeichert werden. Was darf verändert werden. Was darf installiert werden. Was darf gedruckt werden... usw.
Was die Rechte auf dem Client angeht, reicht mir der Unterschied zwischen Standard-User und Admin-User. Der S.U. kann Dateien im eigenen Home-Ordner speichern (darunter wohl am meisten genutzt der Desktop), in eine Dateihierarchie die der User auf dem Root-Laufwerk selber angelegt hat, und auf die eingerichteten Freigaben des Servers. Er kann keine Programme und Dienste (de-)installieren und nur sehr eingeschränkte Änderungen in der Registry, z.B. Settings von Anwendungen vornehmen. Ausser bei der Frage, was darf gedruckt werden, kommt alles was ich wünsche frei Haus mit dem Standard-User. Da geht aber immerhin, daß die Einstellung wo darf gedruckt werden, nicht geändert werden kann.

Ich gebe aber zu, daß derjenige, der das ganze finetunen möchte, mit ADDC die ideale Spielwiese zur Verfügung gestellt bekommt, da kommt dann auch gewiss keine Langeweile auf. Ich habe auch so schon keine Langeweile, und das spare ich mir also.
 
Besonders das letztgenante Argument ist was für die ganz schweren Jungs mit dem Microsoft-Admin-Zertifikat. Die entdecken andauernd auf ihren sieben nebeneinander aufgereihten 32“ curved Monsterbildschirmen im Dark-Mode die laufenden Cyberangriffe auf ihre DCs, in der einen Hand ´ne Cola und in der anderen ´ne Pizza. Wenn ein User anruft weil er Hilfe braucht, dann hat man keine Hand frei um abzunehmen, und ausserdem hat man eh keine Zeit, weil der Hacker kurz davor ist die letzte Hürde zu knacken, und dann muß man - Cola/Pizza hin oder her - sowieso den Stecker ziehen, und das User-Problemchen spielt dann auch keine Rolle mehr. Auf’s neue 4 Wochen später, wie in Potsdam, nicht wahr?
Das ist ein gar nicht so blödes Argument. ;) Active Directory ist ein absolut bevorzugtes Einfallstor von Ransom Ware Gangs und anderem Gesocks in ein Netzwerk, weil es durch das Single Sign On Modell ausreicht, einen einzigen privilegierten AD-Account zu bekommen und dann hat man praktisch überall Zugriff drauf. Und das ist nur der einfache Fall. Dazu kommen eine ganze Reihe mehr oder weniger elaborierter und schwer zu verhindernder Angriffe auf die zugrundeliegende Authentifizierungsinfrastruktur. Einige, wie zum Beispiel Golden Certificates [1] sind irgendwo prinzipbedingt, andere wie Petit Potam [2] nutzen aus, dass Microsoft 40 Jahre IT-Geschichte mit sich rumschleppt und in der Standardkonfiguration eingeschaltet hat.

Wenn man ein AD betreiben will oder muss, sollte man als absolutes Minimum Microsofts Enterprise Access Model [3] umsetzen. Das macht aber nur Sinn, wenn man es komplett durchzieht und dann schon einen Großteil der durch AD gewonnenen Bequemlichkeit wieder zunichte. Außerdem ist eine gute Idee eine der diversen, oft extrem umfangreichen Härtungsanleitungen für AD und Windows 10 / 11 durchzuarbeiten und umzusetzen. Es gibt buchstäbliche tausende GPO und andere Optionen, von denen viele in Standardeinstellung fragwürdig gesetzt sind.

1: https://www.hackingarticles.in/domain-persistence-golden-certificate-attack/
2: https://www.heise.de/news/Windows-Netze-verwundbar-fuer-Relay-Angriff-PetitPotam-6147467.html
3: https://learn.microsoft.com/en-us/s...s-workstations/privileged-access-access-model
 
Klar, so eine zentrale Benutzerverwaltung und Rechtevergabe birgt Risiken, aber mal ehrlich: Wie handhabt ihr denn ein Netzerk mit 50 Windows Rechnern und Benutzern und diversen Severn und Zugriffsrechten? Alle Benutzer auf den Clients von Hand anlegen, ebenso auf den diversen Servern? Was passiert denn, wenn der Benutzer sein Kennwort aendert? Wer macht das auf den Servern? Wie werden die Benutzerrechte dann gepflegt?
Gruppenrichtlinien werden ersetzt duch was?

Ich wuerde liebend gerne auf einen AD verzichten im Win Umfeld, nicht falsch verstehen, aber es muss ja alles auch noch handhabbar bleiben?
 
Falls man AD nicht braucht, wie wäre es mit NIS?


Da müsste man allerdings alle Clients / Arbeitsplätze auf UNIX (FreeBSD oder Linux) umstellen, aber wenn in der Firma eh nur Office 365 zum Arbeiten benutzt wird, würde dann nicht auch Libreoffice reichen? M.E. hat OpenSuse in YAST sogar ein Tool, mit dem man einen NIS Client sogar einfach einrichten kann. Und FreeBSD selbst ist ja auch wunderbar um am Desktop zu arbeiten... Dann könnte man sich Windows mit den Lizenzen komplett sparen.
 
Die allermeisten sind schon mit Windows komplett ueberfordert und wehe es sieht auch nur ein Fitzel anders aus nach einen Update. Meine bisherigen Umstellungen auf M365 sind meist so: Ja, ein Teil kann auf Offline Programme verzichten, ein gewisser Teil nicht. Trotzdem sind dann andere Programme (z.b. diverse WAWI, Zeiterfassung, etc) leider auch nur wieder unter WIN lauffaehig. Ich koennte stand heute keinen meiner Kunden (in Summe mehrere hundert Arbeitsplaetze) auf einem Linux geschweige den BSD Destop setzen, auch wenn es mit den Web Apps immer einfacher zu werden scheint. Der Anspruch der Menschen lauft dem komplett zuwieder. Klar, kann man das mal probieren (wuerde ich wirklich gerne), aber ob das meine Nerven aushalten weiss ich nicht. Drucker oder Netzlaufwerke einzeln auf den Clients verteilen is auch fuern Popo, da lob ich mit die Richtlinien.
 
Wie handhabt ihr denn ein Netzerk mit 50 Windows Rechnern und Benutzern und diversen Severn und Zugriffsrechten?
Ich kann nur sagen wie ich es mache. Die User auf dem FreeBSD-File-Server (lokal) und Mail-Services und Web-Anwendungen (FreeBSD bei AWS-EC2) habe ich angelegt, inklusive Passwörter.

Zur Verwaltung habe ich Scripts und für die Mail-Services und die Web-Anwendungen ein C-Programm geschrieben, mit denen die Berechtigungs-Listen via ssh-pipe auf die Server neu eingespeist und aktiviert werden können. Ich ändere die Liste auf meinem lokalen Rechner und rufe die ssh-pipe-Kommandos auf und in weniger als einer Sekunde sind jeweils die neuen Rechte und ggf. neuen User aktiv.

Die Windows-Clients sind mit Standard-Accounts unterwegs. Die Passwörter dort interessieren mich nicht. Für den Mail-Zugriff mußten wir Outlook einmal konfigurieren, dabei hat mir ein technisch visierter Kollege geholfen - Outlook ist vielleicht ein Mist, aber was soll’s, das müssen wir ja nur einmal anfassen.

Jeder User hat auf dem Server einen Home-Ordner, da kann er seinen privaten Kram abspeichern und es befindet sich darin ein Backup-Verzeichnis, in dem stündlich die inkrementellen Backups des Windows-User-Ordners über den Windows eigenen Dienst (unter Update & Sicherheit) eingespielt werden. Ferner ist im Home-Ordner ein Link zu den Gemeinsamen Daten hinterlegt, von dort aus kann man in die mit diversen Zugriffs-Rechten ausgestattete Verzeichnisstruktur navigieren und alles erreichen, was nötig ist.

Dafür muß man unter Windows nur ein Netzlaufwerk verknüpfen (mit dem sog. anderen Benutzer) und legt davon einen Link auf dem Desktop an, fertig.

Wenn neue Verzeichnisse auf dem Server dazukommen, muß bei den Clients nichts gemacht werden.

Wenn sich ein Client einen Cyrpto-Trojaner einfängt, dann sind auf dem Server allenfalls die Verzeichnisse betroffen in denen der betreffende User Schreibrechte hat. Dafür hat man ja tägliche Backups und ferner wird jede Nacht das von mir entwickelte clone-Utility im Hard-Link-Modus aufgerufen, d.h. es wird jeweils von der gesamten Verzeichnisstruktur ein Hard-Link-Clone angelegt, selbst wenn also ein nennenswerter Teil cryptografiert würde, sind die Daten immer noch da, und man kann sie infach auch mit clone zurückholen. Zuvor werden mit find die nicht mehr gelinkten Dateien gezählt, wenn das in die tausende geht, dann ist was faul.

Nochmal, ich bin jetzt überzeugt, daß ich ADDC nicht brauche.
 
Outlook ist vielleicht ein Mist, aber was soll’s, das müssen wir ja nur einmal anfassen.
Kann man das nicht durch Thunderbird ersetzen? Hat Outlook da irgendwelche Funtionen, die Thunderbird nicht hat und die man unbedingt braucht?

NIS is gut und ist einfach aufgesetzt - aber das Passwort wandert da bei ner Loginaktion im Klartext durchs Netzwerk; das war, als ich Anfang der 2000er mal in ner gemischten Win/Unix Klitsche arbeitete, schon problematisch - und ist es vermutlich im Jahr 2023 erst recht
Aber das Netzwerk sollte ja nach außen geschützt sein. Wurde an anderer Stelle nicht gesagt, dass ein Problem von Active Directory ist, dass es genau darauf spezialisierte Hacker gibt? Wenn derartige Spezialisten also von außen auf einen NIS stoßen würden, könnten die vielleicht nichts damit anfangen?
 
@cabriofahrer - Prinzipiell hast du schon recht, aber... ein Unternehmensnetz gegen Angriffe von außen zu schützen ist immer nur 50% des Ganzen - es gibt auch den Themenbereich "Angriffe von innen" zu klären, Klartextpasswörter auf der Leitung will man eigentlich da nicht sehen (im Wortsinn :)).
 
Aber das Netzwerk sollte ja nach außen geschützt sein.
Naja. Das ist ein wenig altes denken. Von früher. Heutzutage kalkuliert man auch inner-attacks ein. Die es ja immer geben kann. Gerade durch virenverseuchte PCs oder auch dieser ganze Smartkram.
Inzwischen ist es sogar so weit, das wir innerhalb von Mikrochips Kryptograhie habe. :-) Da irgendwie mit völlig unterschlüsselten LAN so auf "telnet-Niveau" herumzufuhrwerken wird modernen Anforderungen nicht gerecht.

Und das Grundproblem an NIS ist ja nicht nur die Verschlüsselung. NIS ist halt sehr auf UNIX zugeschnitten. Wenn man in einer heterogenen Umgebung ist, wo dann auch noch Windows-PCs und sonstwas zum Einsatz kommt, dann wirds auch schnell "ungemütlich". In einer reinen UNIX-Umgebung ist NIS schnell aufgezogen und hat dadurch vielleicht noch ne gewisse Attraktivität. Sobald es gemischt wird, verflüchtigt sich aber dieser Vorteil.
 
Kann man das nicht durch Thunderbird ersetzen?
Thunderbird deckt aber im wesentlichen nur den eMail-Teil von Outlook ab. Alles andere was man so gewöhnlich unter Groupware-Funktionalität subsummiert, da ist Thunderbird schlechter aufgestellt. Du darfst auch nicht vergessen das Outlook eine integrierte Lösung ist die auch mit dem Exchange-Server daher kommt. Es gibt ja in dem Sinne kein Thunderbird-Server. Klar kann man sich vieles zurecht basteln aber mit Outlook kriegt man halt das "Rundumsorglos-Paket".

Die Frage ist weniger, ob man das ersetzen kann. Sondern wie bequem es ist das zu nutzen. Und nicht zuletzt ist es auch immer eine Frage der Nutzerschaft und Nutzerakzeptanz. Mit Outlook ersetzen (was aufwendig genug ist) ist es ja nicht getan. Die Nutzer müssen ja auch damit zurecht kommen und geschult werden usw.
Du hast also sehr viel Aufwände, wenn Du von Outlook wegmigrieren willst. Und das überlegt man sich natürlich gründlich.
 
Wichtiger Punkt noch gegen Thunderbird: Es kann nicht vernünftig zentral verwaltet werden. In einer Firma eigentlich ein no Go.

Weiterer Punkt gegen Thunderbird: Das Festhalten am elendigen mbox Format für die Mailboxen.
 
Zur Verwaltung habe ich Scripts und für die Mail-Services und die Web-Anwendungen ein C-Programm geschrieben, mit denen die Berechtigungs-Listen via ssh-pipe auf die Server neu eingespeist und aktiviert werden können. Ich ändere die Liste auf meinem lokalen Rechner und rufe die ssh-pipe-Kommandos auf und in weniger als einer Sekunde sind jeweils die neuen Rechte und ggf. neuen User a

Ich denke damit hast du alles das für deinen Anwendungsfall relevante, was du mittels AD erreicht hättest, bereits erreicht - und brauchst AD nicht (meine Meinung, ohne jetzt tiefere Details deiner Umgebung zu kennen).

Die Stärke von AD ist die zentralisierte Verwaltung für Benutzer, Gruppen, Computer (auch DNS/DHCP) und deren Richtlinien - alles halt primär erstmal auf die Windows-only-Welt bezogen.
 
Wichtiger Punkt noch gegen Thunderbird: Es kann nicht vernünftig zentral verwaltet werden. In einer Firma eigentlich ein no Go.

Weiterer Punkt gegen Thunderbird: Das Festhalten am elendigen mbox Format für die Mailboxen.
Zentrale Verwaltung von E-Mail-Clients? Ehrlich jetzt? Bei manchen Firmen ist offenbar die DSGVO in der Firewall stecken geblieben.

Und inwiefern ist das unsäglich elendige PST-Format nun besser als mbox ist, erschließt sich auch nur für die MS-Adepten.
 
Zurück
Oben