Statt Windows Server kann man auch ein Linux-System mit SAMBA als Domain Controller für ein Active Directory verwenden. Ein Leser hat mich vor einiger Zeit auf dieses Thema hingewiesen, und schrieb, dass er das in seinem Umfeld einsetzt.
Active Directory heißt Windows Server?
Active Directory ist der Name des mit Windows 2000 eingeführten Verzeichnisdiensts von Microsoft Windows Server. Active Directory ist in Windows-Umgebungen kaum noch weg zu denken, ermöglicht es, ein Netzwerk entsprechend der realen Struktur des Unternehmens oder seiner räumlichen Verteilung zu gliedern.
Active Directory verwaltet verschiedene Objekte wie beispielsweise Benutzer, Gruppen, Computer, Dienste, Server, Dateifreigaben und andere Geräte wie Drucker und Scanner und deren Eigenschaften in einem Netzwerk. Mit Hilfe von Active Directory kann ein Administrator die Informationen der Objekte organisieren, bereitstellen und überwachen.
Den Benutzern des Netzwerkes können Zugriffsbeschränkungen erteilt werden. So darf zum Beispiel nicht jeder Benutzer jede Datei ansehen oder jeden Drucker verwenden. So weit so bekannt – und im größten Teil der Active Directory (AD)-Systeme dürften Windows Server als Domain Controller, die die Verwaltung übernehmen, verwendet werden.
Aber es nicht zwingend, dass Active Directory (AD) auf einem Windows Server als DC aufsetzen muss. Auch ein Server mit Linux kann über das Paket Samba als Domain Controller für ein Active Directory fungieren.
Für Ubuntu gibt es diese archivierte Anleitung für Samba als Domain Controller (wird aber nicht mehr für aktuelle Ubuntu-Versionen getestet). Eine aktuelle Anleitung findet sich in diesem Dokument. Und es gibt ein Samba Wiki, wo der Beitrag Setting up Samba as an Active Directory Domain Controller das Setup beschreibt. Eine weitere Anleitung gibt es hier.
Es gibt eine sechs Jahre alte Diskussion auf reddit.com, wo Leute behaupten, dies erfolgreich einzusetzen.
Ein Leserhinweis auf diese Lösung
So ganz erinnere ich die Details nicht mehr, da es bereits einige Monate her ist. Ich hatte irgend etwas zu Windows Server im Kontext mit Domain Controller und Active Directory in einer Administratorengruppe auf Facebook gepostet.
DC durch Linux Server mit Samba realisiert
Damals meldete sich ein Administrator, der angab, mit seinen Kollegen in seiner Umgebung – erinnerungsmäßig eine Schule oder Behörde – Windows Server als Domain Controller durch Linux-Server mit Samba ersetzt zu haben. Ich hatte den Leser seinerzeit kontaktiert, und gefragt, ob er mir einige Stichpunkte aufschreiben könne, da ich dann einen Artikel drüber machen will.
Inzwischen habe ich einige dieser Stichpunkte bekommen. Da der Leser ungenannt bleiben will, werde ich keine Details zum Einsatzort posten, sondern das Ganze allgemeiner als Denkanstoß formulieren.
Die grobe Konstellation
Der Leser schrieb, dass das als Domain Controller fungierende Linux-System als virtualisiert auf einem Host läuft, der mit Proxmox VE in Kombination mit Proxmox Backup Server realisiert wurde. Für die Netztrennung wird eine OPNsense Firewall in einer weiteren VM verwendet.
Der Linux Domain Controller läuft als 4 Core mit 4 GB RAM. Das Rollout der Erstkonfiguration erfolgt zuerst manuell. Später wurde die Verwaltung der Konfiguration auf Ansible Playbooks umgestellt.
Die Active Directory-Verwaltung sei mit Windows 11 VM mittels der AD-Tools, oder mit den Shell Samba Tools am DC selbst möglich. Der DC besitzt keine GUI schrieb der Leser.
File Server seien ebenfalls auf Linux-Basis an das Active Directory gekoppelt.
Noch einige Details
Wenn ich es richtig interpretiere, läuft die Konstellation über einen Hauptstandort auf 23 Schulstandorten. Jeder dieser Standorte bindet die Software per OPNsense mit VPN an den Hauptstandort an.
Zum Patchmanagement werden Systeme mit Windows Server (WSUS) mit FOG Project eingesetzt. Das FOG-Projekt ist eine Suite von Softwaretools zur Bereitstellung von Disk-Images von Microsoft Windows und Linux mithilfe der Preboot Execution Environment. Der Leser schreibt, dass man FOG Project zum Software-Rollout und System Cloning verwendet.
Es gibt eine Windows 11 VM als Administrations-Maschine für das Active Directory (AD) und die Administration des Standorts. Weiterhin gibt es noch ein Windows 11-System am Standort, die als Print-Server fungiert. Jeder Standort habe einen Server mit je einem Domain Controller, einem Files-Server (Linux) einen WSUS Replika Server, einen FOG Replika Server, eine Admin VM, und einen Print-Server als VM.
FOG Projekt und WSUS werden zentral vom Hauptstandort verwaltet. Auch die Linux-Maschinen werden zentral vom Hauptstandort durch Ansible verwaltet. Aktuell ist man dran, die Firewalls ebenfalls zentral vom Hauptstandort durch Ansible und die OPNsense API zu verwalten. Ein Kollege des Lesers hat ein AD Import-Programm geschrieben, womit wir durch einen csv import Benutzer (Schüler) in die Active Directory-Umgebung importieren und das ganze auch aktualisieren kann. Das passiert pro Standort; die CSV wird aus den Programmen fuxschool und winschool generiert.
Wenn ich es richtig mitbekommen habe, sind in dieser Konstellation aktuell knapp 500 Clients, davon ca. 80% auf Windows 11, eingebunden – in der Endausbaustufe sollen es 1.000 bis 1.200 Clients werden. Die Updates werden per WSUS verwaltet und es gibt die oben erwähnten 23 Replikations-Server.
Der WSUS fungiert als Master und ist halbautomatisch mit PowerShell automatisiert . Windows Defender bzw. dessen Updates und das Windows Tool zum Entfernen bösartiger Software kommt automatisch, ist so freigegeben. Den Rest an Updates rollte der Administrator manuell aus.
Positive Erfahrungen des Lesers
Der Leser schrieb Mitte Dezember 2025, dass der größte Vorteil der als Linux Server mit Samba als DC implementierten Active Directory-Umgebung einerseits darin liegt, dass keine Lizenzkosten anfallen (scheint in diesem Bereich ein Thema zu sein). Weiterhin gab der Leser an, dass er mehr Stabilität in dieser Umgebung erreicht habe, wobei die Lösung ressourcensparender als mit einer Windows Server-Implementierung sei.
Unter dem Strich schreibt er, dass er eine "fast gleichwertige Funktionalität wie Windows Server DCs erreicht habe". Ich denke, das Szenario wird nicht für jeden Anwendungsfall zutreffen. Aber es ist vielleicht eine Anregung, bei Projekten über den Schüsselrand hinaus zu denken und solche Alternativen zu prüfen.
Weil es gerade irgendwie passt, die Tage bin ich auf absatzwirtschaft.de auf den Artikel Deshalb sollten Unternehmen Microsoft abschalten gestoßen. Das Thema ist also außerhalb unserer IT-Blase angekommen.
MVP: 2013 – 2016
Auch diverse NAS-Systeme lassen sich als DC mit AD nutzen.
Beispielsweise QNAP NAS.
Es muss also nicht zwingend ein Windows DC sein.
Betr. "Auch diverse NAS-Systeme lassen sich als DC mit AD nutzen.":
Das wird ja immer abenteuerlicher. Als hätte man nicht schon genug Probleme mit dem Original, werden jetzt auch noch leidliche bis angestaubte Kopien aus dem Giftschrank gezogen.
Was glaubt ihr wohl wie euch der Chef den Kopf abreisst, wenn ihr plötzlich auf Dutzenden bis Hunderten Clients Anmeldeprobleme habt und nicht zu 120 % belegen könnt, dass euer Samba DC keine Implementationslücken/Implementationsfehler in den einschlägigen Protokollen (1) hat sondern die Ursache einzig und allein auf Windows 11 Seite liegt, das Vorhandensein nativer DC also auch nichts ändern würde?
_
(1) https://winprotocoldoc.z19.web.core.windows.net/MS-ADOD/%5bMS-ADOD%5d.pdf
da habe ich noch einen Beitrag zu, als Exchange-Ersatz in Planung
Domain Controller Funktion gibt es auch von Synology. Das ist ja einer der größten NAS Anbieter für Privat und KMU Nutzer. Wenn die Funktion standardmäßig angeboten wird, sollte es dann nicht funktionieren? Ich habe das noch nicht getestet, deswegen kann ich dazu nichts sagen.
Habe ich in einer kleinen Volksschule im Einsatz.
Funktioniert wunderbar.
Ist halt nicht so "mächtig" wie der Windows DC.
Aber für ~30 User und paar kleine GPOs reichts.
Die Frage ist, warum man überhaupt in einer Windows Welt ist.
Die Antwort ist meist: Man hat eine Anwendung, die nur unter Windows läuft.
Wenn ich diese Anwendung habe, benötige ich einen Windows Server, auf dem diese Anwendung läuft (neben den Clients, die ja die Windows Lizenzen oft ohnehin mitbringen).
Wenn ich diesen Server habe, kann ich aber 'gratis' auch gleich einen zweiten, 'leeren' Server als DC betreiben, weil die Windows Server Standard Lizenz zwei Instanzen erlaubt.
Ich habe dann lizenzkostentechnisch nichts gespart. Und die Ressourcen, die ich dem DC gebe (3 GB RAM, 2 Core) sind auch eher gering.
Dabei ist unabhängig, ob ich Proxmox als Hypervisor einsetze, oder Hyper V, denn auch die Hyper V Instanz als Hypervisor gibt das Lizenzmodell noch her.
Ressourcen einsparen kann man bei anderen Produkten wahrlich mehr. Bei Exchange empfiehlt Microsoft 128 GB [sic!] RAM, ein Linux Mail-Server kommt mit 4 GB aus.
Insofern hat sich bei mir noch kein Einsatzzweck herauskristallisiert.
Könnte ich 1.000 € Lizenzen sparen, ich wäre sofort dabei.
Guten Morgen,
bei den Lizenzkosten wurde nur vergessen, dass nicht die zweite Serverlizenz alleine genügt, für den Betrieb des AD DCs sind auch nach MS Lizenzrecht Zugriff CALs nötig. Diese benötige ich bei einem Samba DC nicht.
Die braucht er für seinen Windows Anwendungsserver doch sowieso. Die sind also schon vorhanden.
Die Device/User-CAL benötige ich doch immer, sobald ich irgendwas von einem MS-Server nutze. Da reicht schon ein WSUS oder IIS. CIFS sowieso.
Es war daher für mich immer klar, dass pro neuester MS-Serverversion genügend Device oder User CAL vorhanden sein müssen.
Kommt ein Exchange on Prem ins Spiel, dort ebenfalls. Und sobald Exchange on Prem gesetzt ist, ist das auch schon der Todesstoß für einen SAMBA basierten Domain Controller.
In wie fern sich so in SAMBA DC mit einer Entra Sync verheiraten lässt, ist auch fraglich. Denn alle meiner Kunden wollen und nutzen Teams. Also ist Entra Sync auch gesetzt….trotz Exchange on Prem
Für den IIS braucht man keine CALs.
Denn du kannst den ja auch als öffentlichen Webserver betreiben und da kennst du die Zahl der zugreifenden User gar nicht.
Hallo wenn auf dem Windows Server nur der Wsus Dienst betrieben wird dann sind laut Microsoft keine CAL erforderlich.
Und nicht zu vergessen die Cores, die der Server hat.
Eine Serverlizenz ist nur für max. 16 Cores.
Hat man einen Server mit z.B. 24 Cores, dann braucht man 2 Serverlizenzen. bzw. eine Serverlizenz und eine Add-On Lizenz.
Und die CALs gelten pro Instanz.
Hat man 10 User, die alle auf 2 Instanzen zugreifen, braucht man 20 CALs.
Bei 24 Cores wäre auch eine 24 Core (ROK) Lizenz ausreichend. ;)
Aber: Das mit den CALs pro Instanz ist falsch:
– Bei Device CALs braucht genau jedes Gerät, dass einen Windows Server Dienst (bspw. auch DHCP, DNS, …) beansprucht genau eine CAL für das höchste Server OS, auf das zugegriffen wird.
– Bei User CALs braucht jeder atmende Mensch eine einzige CAL für das höchste Server OS, auf das zugegriffen wird.
(Wer das mischen möchte, kann das tun, sollte es aber gut dokumentieren.)
Einen Datacenter-Server hinstellen, Hyper-V aufsetzen und alle Win-Server VMs darauf sind in der Lizenz drin. Fertisch.
Die Antwort auf die Frage warum man in einer Windows Welt ist, ist zu kurz gedacht. Weil die Anwendung die man benötigt unter Windows läuft und ich nur in dieser Konstellation professionellen Support bekomme. Das ist zumindest im geschäftlichen Umfeld ein nicht zu unterschätzender Faktor.
Vor allem, wenn die Koriphäen, die das Samba-AD mit Ansible und Co aufgebaut haben und betreiben mal ausfallen. Diese Spezialkompetenz bekommst du so schnell nicht wieder. Es reicht nur wenn die zweidrei Superadmins nach der Firmenweihnachtsfeier gemeinsam ins Auto steigen und verunfallen.
Mich interessiert schon länger, wie man sich von M$ lösen kann.
Privat habe ich das seit mehreren Monaten erledigt und bin mehr als zufrieden.
Wie schaut es denn eigentlich mit GPO´s aus?
Die gibt es unter Linux ja nunmal nicht.
Wie werden größere Umgebungen (also auch mit Userbasierten Client-Settings Pro OU) unter verwaltet?
Ansonsten: Guter Beitrag und vielen Dank für den Blick über den Tellerrand!
GPO ist machbar. Die Frage wäre, ob man die dann beibehält oder das dann mit einem "Endpoint Management" erschlägt (und dadurch evtl. noch weitere Optionen bekommt).
Ein Windows Client mit RSAT ist Pflicht – egal ob MS AD oder SAMBA.
Dann klapp es auch mit Gruppenrichtlinien, etc.
Es gibt auch unter Linux den Univention Corporate Server, mit diesem fahren wir gut bei einigen Kunden.
Gruppenrichtlinien, Freigaben, Berechtigungen sind kein Problem.
in einer Umgebung, in der man Kleinigkeiten scripten möchte muss man bedenken, das diverse AD Powershell cmdlets im Samba AD nicht funktionieren. es fehlt eine Komponente, über die diese cmdlets mit den MMC Konsolen kommunizieren.
man muss zurück auf VB, nur wird es mittlerweile schwerer, dafür Code Samples zu finden.
Ausnahme ist die GPMC, deren cmdlets funktionieren (andere Entwickler, andere AD Kommunikation)
ebenfalls hatte das Samba AD Probleme mit RDS Farmen/Sammlungen und kann/konnte diese nicht verwalten.
eventuell gibt es dazu Updates. es ist 2 Jahre her, das ich damit zu tun hatte.
Zum Thema Automatisierung: Linux Hosts mit Samba administriert man auch nicht mehr mit Powershells sondern dann eher mit Ansible/Puppet & Co und da sieht das Angebot wieder sehr gut aus.
Zum Thema RDS/RDP Farmen: Es gibt mit Thinstuff eine komplett von Microsoft unabhängige Terminalserver Lösung mit dem charmanten Vorteil Legacy Uralt-Anwendungs-Schrott halbwegs sicher und isoliert in sichere Umgebungen zu hieven.
Wer Windows 11 mit Samba nutzt, noch dieser Hinweis:
https://blog.jakobs.systems/blog/20251201-wsd-windows-netzwerk/
Ich möchte ja nicht den Host mit Ansible administrieren, sondern das AD.
Simples Beispiel: Alle DCs fragen, ob die krbtgt Password Änderung bei allen angekommen ist oder ob ein User schon auf allen DC repliziert ist oder alte DNS SOA Einträge des alten DC in allen Zonen entfernen … Gut, der DNS könnte auch ein BIND sein, das das fiel mir gerade als Beispiel ein :-)
Die Skript-Logik in PoSh und gegen das SAMBA AD mit dsadd, dsmod, etc. läuft gut.
Es ist ein Notnagel. Die ds*.exe stellen nicht alle Attribute zur Verfügung, da waren die Entwickler zu faul, leider haben die cmdlet Entwickler dieselben Lücken gelassen, sie haben dort abgeschaut.
Die Frage ist, wie oft scriptet man, was scriptet man, was will man überhaupt erreichen und und wie leicht findet man Beispiele, wenn man es selten macht.
Ich sehe in diesem Bericht, nichts über "Windows-Gruppenrichtlinien". Geht das nicht mit Samba? Wäre für mich ein absolutes K.O. Kriterium
Ja. Geht. Du verwendest einen Windows Rechner mit RSAT Tools, die MMC Konsolen wissen garnicht, das sich das AD auf einem Linux System befindet.
Hallo,
das ist ja ein (ur)alter Hut!
Am LMZ (https://www.lmz-bw.de/) wird schon seit vielen Jahren
Univention Corporate Server (UCS)
https://www.univention.de/produkte/ucs/
als AD-Ersatz im professionellen Umfeld – hauptsächlich in Schulen – eingesetzt.
Natürlich ist das auch für Privatpersonen verfüg- und nutzbar.
Interessant wäre hier mehr Details wie die Clients verwaltet werden… GPOs können vermutlich nicht verwendet werden, wie sieht es mit Loginscripts aus oder wird eine Softwareverteilserver dafür eingesetzt…
Windows Clients können in einer Samba Ad genauso mit gpo verwaltet werden.
Klingt nach einem sehr durchdachten Konzept, dass man als Schablone auf ähnliche Kunden/Schulen ausrollen könnte. Meist gibt es dort kein Budget für IT.
ABER: Der Hauptgrund diesen Aufwand zu treiben wäre für mich von den Kosten für die Client CALs wegzukommen. Das wird aber konterkariert durch den Einsatz des WSUS. Es ist hier nicht davon die Rede, dass dieser auf Linux-Basis betrieben wird und ich bezweifle, dass das ginge. Entsprechend müssten alle 1.000+ Clients lizenziert werden. Dann kann ich auch nen Windows Server fürs AD nutzen…
Genau so ist es. Ist ein MS Server im Haus, ist der DC quasi gratis und Beifang.
1 Windows Server STD-Lizenz:
HyperV auf nacktes Blech
AD-Server
weitere Serverinstanz
Zu bezahlen über die Server STD-Lizenz und genügend User/Device CAL
Windows 11 als Print Server könnte – je nach Lizenzkanal / Vertrag – in diesem Szenario nicht lizenzkonform sein.
Bspw. aus den PURs von Win11 im OVS-ES (https://www.microsoft.com/licensing/terms/productoffering/WindowsDesktopOperatingSystem/OVSES):
-> Customer may connect up to 20 devices to the Licensed Device for file sharing, printing, Internet Information Services, Internet Connection Sharing or telephony services.
Findet sich auch in den OEM PURs 2.d.iii (https://www.microsoft.com/content/dam/microsoft/usetm/documents/windows/11/oem-(pre-installed)/UseTerms_OEM_Windows_11_English.pdf):
-> Device connections. You may allow up to 20 other devices to access the software
installed on the licensed device solely to use the following software features for
personal or internal purposes: file services, print services, Internet information
services, and Internet connection sharing and telephony services on the licensed
device.
(Wobei hier die Frage wäre, warum der Pintserver nicht ebenfalls unter Linux bereitgestellt wird.)
die Verwendung von FOG zum Verteilen von Betriebssystem Abbildern ist genauso ein Lizenzverstoß und dürfte so nicht angewendet werden, wenn ich mit meiner Annahme richtig bin, dass hier wahrscheinlich Windows Pro und keine Enterprise Variante verteilt wird. Also das Clonenen von Systemen erfordert das Reimaging Recht, was aber in der Windows Professional Version nicht enthalten ist.
Ich könnte mir vorstellen, dass die Schule durchaus Verträge haben könnte, die ein Re-Imaging erlauben. Am Ende ist aber auch ein "Re-Imaging" mit Windows Pro aus dem "OEM Kanal" nicht ausgeschlossen, sofern das originale OEM Image verteilt wird. (https://www.microsoft.com/licensing/guidance/Reimaging-rights)
(AFAIK dürfte es fürs Re-Imaging sogar reichen, eine einzige der möglichen OEM Lizenzen, mit Software Assurance auszustatten, um alle PCs dann betanken zu dürfen.)
das Recht für Reimaging muss auf alle Target und nicht nur der Source angewendet werden. Software Assurance würde das Recht jedenfalls erweitern, ist korrekt, muss aber für alle ZielComputer vorhanden sein. Weiß allerdings nicht ob es Software Assurance auch für Pro Versionen gibt oder ob man da nicht generell auf Enterprise oder EDUs ausweichen muss.
Nachdem explizit von Clonen gesprochen wurde, dürften hier keine OEM Systemabbilder verteilt werden, was dann Reimaging Rechte voraussetzt.
Ich war mit der SA falsch abgebogen. Im "OEM Fall" sollte es genügen eine zum Win OS passende (upgrade) "Volume License" zu haben, die dann den entsprechenden Key sowie das Installationsmedium bereitstellt.
Fürs Re-Imaging müssen definitiv nicht alle Devices eine "Volume License" haben.
Ebenfalls wäre es weiterhin durchaus möglich, dass die Schule Zugriff auf passende "Rahmenverträge" hat und Win 11 (Edu) lizenziert, was dann eh "VL" ist und ebenfalls pro Device SA inkludiert ist.
(Da wir aber im zweifelsfrei undurchsichtigen MS Lizenzrecht sind und die Kommentarspalte auch nicht endlos ist, müssen wir hier aber auch nicht der gleichen Meinung sein. :))
Doch ganz sicher für alle, wo das Reimaging Image aufgespielt werden soll brauchst du Reimaging Rechte. Ich weiß das ist ein gern verwendeter Irrglaube, dass man nur 1 Device entsprechend lizenzieren muss, macht aber auch logisch betrachtet kein Sinn, warum muss ich dann überhaupt lizenzieren, wenn es nur ein Gerät benötigt…ne ne alle Target Devices müssen entsprechend lizenziert sein um solche Custom Images aufspielen zu dürfen.
Soweit mir bekannt benötigt man nicht für alle PCs die SA. Man kann auch das Image benutzen und damit OEM Systeme betanken, entscheidend ist das man sich im selben Produkt bewegt. Wenn also die SA Version Win11 Pro ist muss auch die OEM Version Win11 Pro sein. Am Ende trägt man den OEM Key ein und alles ist gut, das was man nicht darf ist 10 VL Lizenzen haben und damit 50 PCs betreiben. Das ist aber keine Frage des Image, das dürfte ich auch so nicht
du benötigst für alle PCs ein Reimaging Recht, die ein Custom Image installiert bekommen, das wird jedoch nicht einzeln verkauft sondern ist gebündelt mit anderen Lizenzen. Wie du zu dem kommst ist da nebensächlich, es ist jedenfalls nicht im WindowsPro standardmäßig enthalten.
Wenn ein Image mit sysprep vorbereitet wird und danach geclont wird, dieses geclonte Image verteilt wird und im Nachgang lizenziert wird benötigt man doch kein imaging Recht, die sysprep Werkzeuge beinhaltet Windows in 10/11.
Man hat hier auch keine Id Dopplungen sondern nur ein gleich aufgebautes system mit je einem eigenen Schlüssel.
@ARC4
setzt "Re-Imaging" nicht ein Sysprep und Capture, bzw. Cloning vorraus?
Bei der Verteilung/Installation einer originalen Install.wim per unattended install mit einem beliebigem Werkzeug plus Joblauf/Tasksequenz, sollte das Thema rechtlich erledigt sein. Oder?
Es ist dann ja eine Erst-Installation , kein widerverwenden eines angepassten Images (Re-Image)
Ich bin mir jetzt nicht so ganz sicher, ob der gesamte Diskussionsfaden hier gerade in eine falsche Richtung abbiegt. Die lizenzrechtlichen Fragen wird jeder in seiner Umgebung abklären müssen. So ist das hier eine Diskussion am "grünen Tisch", da keiner die Details kennt – und ich werde da auch nichts weiter offen legen.
Der Beitrag ist als Denkanstoß zu sehen, den jeder bei sich selbst an eigenen Projekten spiegeln und prüfen könnte, was geht. Stattdessen erlebe ich hier in den Diskussionen X Argumente, warum das irgendwie prinzipiell nicht gehen kann oder darf.
Ich sage es mal so: Wenn es wirklich lizenzrechtlich verboten ist, dass ich als Endanwender (nicht OEM) eine Windows 10 Pro-Lizenz legal erwerbe, einrichte, dann ein Abbild zentral ablege, welches ich im Fall der Fälle über Netzwerk booten kann, um ein sauberes Images zu haben (wird auf Schulungs-PCs doch häufiger verwendet), sollte man alle Hebel in Bewegung setzen, von dieser Knebelei weg zu kommen.
Ich erlebe es recht häufig, dass genau so Dinge wie ein "Win 11 Server" und die 20 Verbindungen oder auch das von @ARC4 angesprochene Re-Imaging / Cloning gerne übersehen werden. Das wollte ich dem unbekannten "Administrator" ans Herz legen, es zu prüfen. Ich hatte keinerlei Intention irgendwem, irgendwas zu verbieten oder madig zu machen.
Für mich ist das schon in Ordnung (daher danke für deinen Einwurf) – ich habe den Leuten, von denen der Rohtext kam, auch freigestellt, hier zu kommentieren – mitlesen werden die auf jeden Fall. Ich muss davon ausgehen, dass dieser Fall (max 20 Nutzer gleichzeitig) abgedeckt ist – andernfalls kann die IT da nachsteuern und ggf. Linux als Printserver einsetzen.
ich finde nicht, dass das am Thema vorbeigeht. Die richtige Lizenzierung in Mischumgebungen ist doch genauso wichtig und muss bedacht werden, weshalb ich das schon als wertvollen Input mit Mehrwert empfinde.
Und ja ist natürlich ein Argument mehr um weg von Windows Umgebungen zu kommen. Im Unternehmensumfeld ist das aber von der falschen Seite angepackt, wenn meine Software, die ich betreiben muss, Windows voraussetzt…aber das ist nur meine Meinung.
Es geht mir nicht um diese Diskussion gänzlich zu unterbinden. Aber gelegentlich habe ich schon das Gefühl, dass Diskussionen zu arg am grünen Tisch erfolgen, ohne die Details zu kennen. Der Tipp-Geber schrieb allgemein von Windows 11 Clients – im schulischen Bereich würde ich davon ausgehen, dass da eine Education-Edition verwendet wird. Jetzt mäandert die obige Diskussion um das Recht zum Re-Imaging bei Windows 11 Pro. Ein Hinweis: Beachtet die Lizenzierungsanforderungen für Re-Imaging, CALs, … hätte doch gereicht – und die Information wäre da gewesen. Das ist etwas, was mich beim Querlesen der Kommentare gelegentlich stört – aber vielleicht sehe ich das etwas zu kritisch, und würde meinen Kommentar zurückstufen, wenn es für das Groß der Leserschaft wirklich essentiell ist (meine Denkweise ist etwas burschkioser: "sauber prüfen und Haken dran oder verwerfen, fertig").
das Thema mit der Lizenzierung ist relativ komplex und gerade im Zusammenspiel mit OpenSource und Kosteneinsparungen geht das dann oft unter.
Den Artikel hatte ich als allgemeine Information verstanden, selbst wenn ich dann WindowsPro falsch hinein interpretiert hätte, dürfte das Thema dennoch viele tangieren, die sich mit dem Thema "weg von Microsoft" auseinander setzen müssen.
Schulungs-PCs… Der "Schüler" hat da nichts zu ändern, der ist kein lokaler Admin, speichert idealerweise sein Zeugs auf einem Netzlaufwerk, so dass außer dem Userprofil des Users an dem PC keine Änderungen passieren. (Roaming-Profiles sind heutzutage verpöhnt)
Aber das ist auch nur ein "Nebenschauplatz" des Themas, musste aber bei dem Beispiel diese Kerze mal werfen.
Wir sind ja recht Linuxlastig und betreiben u.a. auch Samba-Filesserver als Domainmember. Was mich vom Einsatz AD abhält ist GPO-Verwaltung, evt. CA für die Windows-Clients. Prinzipiell sollte das auch funktionieren, die Frage ist wie gut.
Moin,
Das Thema "Kosten sparen" lese ich hier nicht, sondern "Digitale Souveränität" …
Frohes Schaffen
"Digitale Souveränität"
Dann darfst Du auch keine Windows Clients einsetzen und baust Dein Netzwerk aus 100% Linux (Server und Clients) auf.
Also für diesen Fall würde ich eher zu Univention Corporate Server raten, die arbeiten auch mit SAMBA als Basis. Nicht nur bringt die Software eine GUI (Webinterface) mit, aber das Unternehmen dahinter bietet vor Allem auch professionellen Support, das wird bei so OpenSource Lösungen oft gerne Mal vergessen, und wenn es denn Mal kracht sollte man sich als Verantwortlicher soweit auch absichern.
Nachdem die Tage vom WSUS gezählt sind, würde ich persönlich das Ganze mit OPSI zur Sotwareverteilung und Patchmanagement abrunden.
Beide Unternehmen sind in Deutschland beheimatet, was dem Punkt der digitalen Souverenität noch mehr stärken dürfte.
Ich war schon drauf und dran einen ähnlichen Artikel zu verfassen.
Ich habe ja von dem ganzen Zeugs Null praktische Ahnung – bin ja nur Schreiberling/Blogger, der seit 32 Jahren die Niederungen der IT-Administration "wie der Teufel das Weihwasser" meidet und sich höchstens auf die Kanzel stellt und schöne Predigten hält. Daher spiele ich den Ball jetzt mal in euer Spielfeld: Kling für mich spannend – wenn mir jemand von Euch beiden oder ein anderer Leser einen Rumpftext samt einigen Links zukommen lässt (E-Mail-Adresse steht ja weiter im Impressum), versuche ich einen Artikel draus zu machen – dann profitiert die Leserschaft davon. Könnte da jetzt zwar selbst etwas recherchieren, aber wenn praktisches Erfahrungswissen aus der Leserschaft dazu kommt, hat das ein anderes Level.
Jedenfalls stelle ich fest, dass der Artikel bereits in den Kommentaren viele Schwarmwissen zu Tage gefördert hat. Und genau dafür investiere ich die Zeit, in der Hoffnung, dass am Ende des Tages ein sinnvoller Input für die Leserschaft heraus kommt. Daher: Danke für die zahlreichen Einwürfe – und nicht von abhalten lassen, wenn ich manchmal "vom grünen Tisch" rede und Kommentar-Threads einfange – ich denke, die reguläre Leserschaft weiß, wie ich das meine.
Es gibt alternativ zu MS, UCS, Collax und Zental auch noch die Sambabox (sambabox.io).
Konzeptionell und auch von der Umsetzung durchaus interessant. Vor allem im Bezug auf "Digitale Souveränität" – nicht auf den Preis, der jährlich und nach Usern geht.
Ich hatte das mal vor einiger Zeit getestet (V5.1) und massive Probleme mit dem deutschen Webinterface gehabt, english war alles OK.
Das Konstrukt, das im Beitrag beschrieben ist, sehe ich da auch nicht als komplett richtig lizenziert (CALs) an. Aber da Günther hier leider nicht alles Details posten kan/darf ist einiges Spekulation.
Wenn ich schon Linux / SAMBA einsetze, warum greife ich beim drucken dann nicht auf CUPS zurück – ein Windows 11 Client als PrintServer? Wenn WSUS auf Windows Servern läuft kann der auch gleich den Druckerspooling mit abwickeln. Das wird wahrscheinlich eine überschaubaure Menge an Netzwerkdruckern sein am Standort.
Hallo Günther, alle,
natürlich kann man einen SAMBA4 professionell als DC nutzen und das wird in der Praxis auch gemacht, sonst wäre ja der ganze Aufwand der Samba-Community und der dahinterstehenden Firmen wie z.B. SerNet umsonst. Mich wundert, dass Du nicht auf das hervorragende Samba-Buch von Stefan Kania verweist, in dem der Aufbau einer Windows Domäne mit Samba4 ausführlich erläutert wird (und das gerade in einer neuen Auflage erschienen ist). Zur Klarstellung: GPOs gehen natürlich über die normalen Verwaltungstools. Beschränkungen gibt es an einigen Stellen der Administration mit den klassischen Windows-Tools, und, wichtiger, nicht alle AD Functional Levels werden vollständig unterstützt, was auch Sicherheitsimplikationen haben kann. Besonders geeignet ist so ein setup halt, wenn ich eigentlich keine Windows-basierten Serverdienste brauche und das auch alles mit Linux abwickle (z.B. ein Linux SMB-Fileserver mit SAMBA). Dann dient das AD hauptsächlich zur Benutzer- und Gruppenverwaltung und zur Verteilung von GPOs. In so einem Fall kann man beträchtliche Lizenzkosten sparen. Wer so etwas versuchen möchte, dem sei dringend geraten, sich vorab bei der Auswahl der Distribution zu informieren; nicht alle Linux-Distributionen ermöglichen ein Samba-AD-Setup "out of the box".
Irgendwo muss ich bei jedem Artikel einen Punkt ziehen, wo ich den Schluss setze. Du hast ja jetzt auf das Samba-Buch verwiesen und ich habe hier im Kommentar (stelle fest, ich kann in Nutzerkommentaren nicht verlinken) auf die Seite von Stefan Kania zum Buch verlinkt – Win-Win für alle Seiten ;-).
Betr. "auf das hervorragende Samba-Buch von Stefan Kania":
+ Betr. "SAMBA4 professionell als DC":
Professionell? Wie ist das gemeint? In (1) warnt Kania holprig, O-Ton: "Denn es ist genau das passiert, wovor ich immer waren: Louis van Belle hat das Erstellen der Pakete für verschiedene Distributionen von einem auf den anderen Tag eingestellt. Sodass es für seine Pakte keine Updates mehr gibt. Der Tot alle Pakete oder Software, die nur von einer Person gewartet werden. "
+ Nichtsdestotrotz wollte ich heute Nachmittag die lt. Autor (1) aktuelle, fünfte Auflage zur Ansicht bestellen. Keine Buchhandlung konnte diese ermitteln geschweige denn bestellen. Von Thalia (2) gab 's ein lapidares 'gibt es nicht', im für den deutschen Buchhandel autoritativen Verzeichnis Lieferbarer Bücher (VLB) (3) war sie ebenfalls nicht nachzuweisen.
Wenn einem Autor sowas entgeht, habe ich auf den Inhalt schon keine Lust mehr.
_
(1) https://www.kania-online.de/fachbuecher/samba-4/
(2) https://www.thalia.de/suche?sq=kania+samba
(3) https://buchhandel.de/suche/ergebnisse?query=kania%20samba
Wenn man sein AD schon auf Linux aufsetzt, warum weiter ein Print Server auf Windows, statt ein Cups Server auf Linux Basis?
Genau, es geht auch um die Datensouveränität, und UCS usw. verwenden genau das offizielle SAMBA4 System, evtl. mit Anpassungen, für einen "All in One" Ansatz. Wer das abseits dieser Pfade machen will, sollte das als Projekt ansehen, es gibt da schon Fallstricke wie z.B. die Wahl des DNS-Systems, oder die Synchronisation des SYSVOL bei mehreren DCs (das ist nicht ims Samba4 eingebaut, geht aber mit Ergänzungstools problemlos). Leider enthält das SAMBA-Wiki nicht alle notwendigen Informationen und ist auch nicht immer 100% aktuell, ist halt Open Source. Außer dem Buch kann ich hier noch die Samba-Users Mailingliste empfehlen, dort werden oft Fragen im Zusammenhang mit Samba4 als DC besprochen.
"Datensouveränität" geht auch heute noch mit Windows-Servern als DCs und Fileservern usw. Kannst auch auf M365 verzichten, Libreoffice und Thunderbird geht ja prinzipiell auch, und allen Mühlen den direkten HTTP(S)-Internetverkehr per Firewall verbieten. Auch WSUS kann man bis zum Supportende von Server 2025 (also bis 2035) nutzen. Nimmste halt einen Proxy, kann z.B. ein Linux-Squid sein, oder was kommerzielles von Sophos, Trellix, … je nachdem wie tief der Geldbeutel ist. Und schon kannst du dein AD und deine Members betreiben wie vor 10+ Jahren. Auch einen 2025er DC kannst du noch auf DC-Level 2012 oder 2016 betreiben (nur runterstufen geht nicht, musst ihn nur vonvorneherein in das Korsett zwingen)
Deine User können aber Angst bekommen, weil sie glauben, mangels Nutzung modernster (KI-)Technologien nicht mehr mit euren Mitberwerbern mithalten zu können. Kann sein, dass sie recht haben, kann auch nicht sein, aber wer kann das momentan mit Sicherheit sagen? Am Ende bist nur du der Dumme, der sich gegen den "Fortschritt" gewehrt hat, egal wie ehrbar das grundsätzlich ist.
Spätestens wenn deine Leute mit Kunden oder Lieferanten per Teams quatschen müssen bekommst du ein Problem.
Also SAMBA ist ne nette Geschicht aber im professionellen Umfeld nicht Fisch nicht Fleisch.
Man sollte sich entscheiden entweder Windows oder Linux, ein Mischmasch macht nur Probleme.
Man sollte prüfen was man in seinem Umfeld nutzt und wirklich auch testen ob es SAMBA kompatibel ist.
Exchange – nein
SharePoint – nein
Entra ID Connect – nein
Powershell CMDLets – teilweise
Skype for Business – nein
Teams – nein
GPO – teilweise
AD Zertifikatsdienste – nein
ADFS – nein
Netlogon-RPC – nein
O365 Hybrid – nein
Intune -nein
Claims – nein
RDS/Terminalserver – nein
Was geht gut
Logon Services – ja
Profile Service – ja
einfache GPO – ja
File Services – ja
Print Services – ja
ganz ehrlich dann den ganzen Schritt gehen und komplett zu *nix wechseln und wenn es dann noch irgend etwas gibt was nur unter Win kann in ein KVM oder Docker drängen
Danke für die Zusammenfassung. Meine Befürchtungen bestätigen sich.
"Was geht gut"
Dann komplett auf *nix wechseln ist ein guter Vorschlag. Nur selbst mit einem anderen dann eingesetzten Verzeichnisdienst (radius) hast du funktional auch nicht mehr, wenn nicht sogar weniger. Gut, Gruppenrichgtlinien brauchst du dann auch nicht mehr. Kannste ja alles per Ansible. Und wenn du dann auch noch puristisch auf nfs-Shares ausweichst, hast du auch nur noch ein sehr flaches Rechtemanagements (root, ich, meine Gruppe, die anderen). Da lässt sich ein gescheites komplexes Zugriffsmanagement für die Shares nicht abbilden.
Für kleine Ansprüche sicher ausreichend, aber für Größeres schlicht nicht geeignet.
Man merkt, dass man in Deutschland ist…
Wollte einen gepfefferten Post machen aber – was nutzt es bei solchen M$ FUD Nachplapperern.
Microsoft und Recht und Gesetz – der ist gut. Da hat @Günter satt und genug Artikel zu.
Danke – es waren ein paar technisch interessante Infos drin.
Habe einige jahre eine Umgebung mit Samba betrieben. Funktioniert. Auch wenn so manches mühsam war (was heute vermutlich i.O. ist).
Problem ist, finde als KMU jemand zuverlässiges, der dir das managed. Ist wie mit Siemens SPS, die wahre Pest, völlig überteuert (alleine schon um Backups zu ziehen), aber jeder kanns. Kenne einige kleinere Betriebe die mit Mitsubishi oder Beckhoff gearbeitet haben und genau deswegen nach Jahren wieder umgestiegen sind. Keine Progger gefunden oder direkt wieder abgeworben von Grossfirmen mit utopischen Löhnen, da rar. Auch wenn jede SPS +- gleich ist, hat jede so seine Eigenheiten. Am Ende fügt sich fast jeder KMU. So ähnlich isses mit MS umd deren Produkten.
Dank Copilot und co. bekommen die Konzerne endlich auch deren Know how.
Was? Erst seit 6 Jahren? … Das ist jetzt nun schon 15 Jahre her als ich in einem Systemhaus gearbeitet habe, in dem Samba 4 auf Linux alternativ zu Windows-Servern für Kunden angeboten wurde. Wir hatten auch einen Kunden, der das hessenweit vernetzt benutzt hat, einige von euch waren da sicher schon Kunden. Man spart erstmal Geld für die Serverlizenz, richtig. Aber das Gefrickel, bis das in den verschiedenen Kundensituationen lief, das war sportlich, vor allem wenn man mehrere DCs braucht und die ordentlich miteinander replizieren sollen, über viele Standorte hinweg. Auch braucht man gut funktionierendes DNS, grundsätzlich braucht man das immer für AD, und es muss auf jeden Fall redundant sein, denn wenn nur ein DNS eingesetzt wird und der mal ausfällt, steht der ganze Laden, das heißt man muss auch den Bind gut beherrschen, und zwar dass er AD-integriertes DNS funktional ersetzen kann. Also, was du an Lizenzen einsparst, kostet dich dann halt Frickelzeit und Lehrgeld. Auch das Thema "Härtung" dieser DCs ist eine Herausforderung. Man kann auch Policies machen, wenn man eine Windows-Maschine mit RSAT Tools nutzt. Aber diese "Lösung" hat rundherum Einschränkungen, ein Gegenstück zu "RODC", "ADFS" und AD integrierte PKI sind so Themen. "Sites" funktiuonierten damals nicht, die Clients funkten kreuz und quer über die VPN Verbindungen um einen Ameldeserver zu nutzen, statt den per Site definierten nächsten DC im gleichen Standort zu nutzen, also AD-Traffic auf WAN-Strecken noch und nöcher. Und ich weiß auch noch von Kunden, die den Kladderadatsch am Ende gegen Windows DCs ausgetauscht haben. Weil es einfach funktioniert.
… in einer Stadt das Schulnetz … Da schüttle ich doch den Kopf! Denn gerade Schulbehörden bekommen das Windows-Zeugs von Microsoft sowas von reingebuttert. Dazu noch kostenlose Schul-M365-Lizenzen für die Kids, was dann auch wieder erfordert, dass das AD an den Azure-Tenant angebunden sein muss, was sicher entweder ein riesen Abenteuer mit Samba-4-DC sein muss (man braucht mindestens einen ADFS dafür) oder garnicht geht.
Unsere virtuellen Server-2022 DCs sind übrigens auch nur 4-Kerner mit 4 GB RAM, reicht völlig für über 1000 Member-Server und Clients und 4000 User (viel auf Terminalservern). Die müssen ja nur ja/nein sagen, wenn sich jemand anmeldet oder wo zugreifen will. Ich glaube das ganze Monitoring kostet mehr Performance als die eigentliche Aufgabe.
"Ein Kollege des Lesers hat ein AD Import-Programm geschrieben, womit wir durch einen csv import Benutzer (Schüler) in die Active Directory-Umgebung importieren und das ganze auch aktualisieren kann. Das passiert pro Standort; die CSV wird aus den Programmen fuxschool und winschool generiert."
Wott??? Keine AD-Syncs über Standorte hinweg? Wasn das fürn Gefrickel?
(Solche Scripte kann sich jeder Idi von Copilot für Powershell generieren lassen)
Windows 11 als Printserver? Das Client-OS in Serverfunktionen nur 10 SMB-Verbindungen gleichzeitig unterstützen, ist bekannt? 10 Leute können dann da drucken, der elfte nicht! 1elf11!!!
Betr. "Wott??? Keine AD-Syncs über Standorte hinweg? Wasn das fürn Gefrickel?":
Dir ist der Unterschied nicht bekannt zwischen einem Benutzerdatenimport und einer Active Directory Domain Services typischen Replikation (1)(2). Und bitte etwas weniger schnoddrig, die jüngeren Teile der Leserschaft brauchen Vorbilder.
_
(1) https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/f2e2f6c7-b232-406d-b48a-fc6ccf231202
(2) https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/b645c125-a7da-4097-84a1-2fa7cea07714#gt_a5678f3c-cf60-4b89-b835-16d643d1debb