Door Anoniem: Wel vraag ik mij persoonlijk af waarom je dit zou willen?
Dat is niet zo moeilijk. Als serverbeheerder wil je niet afhankeljik zijn van een desktop-OS om je servers te kunnen beheren. Wellicht heb je nog een roedel servers met linux (of andere Unix-smaakjes) en die wil je ook allemaal via kereros benaderbaar laten zijn en zodra daar windows bij komt kijken heb je de compatibiliteit met de "embrace and extend"-uitbreidingen van microsoft nodig.
Wat is het voordeel tegenover bv. Windows Server 2019 Core (minimale versie zonder GUI) :
Het is geen windows, en de gebruikelijke scripting-tools zijn ervoor beschikbaar, in plaats van dat je afhankelijk bent van wat microsoft je toestopt met hun GUI-loze GUI-OS.
Puur uit nieuwsgierigheid, vind wel interessant.
Samba is software die het mogelijk maakt dat windows mee kan doen met "echte computers" (zie Dilbert), dus samba-als-AD, net zo. Als je alleen maar in microsoft denkt, dan heb je het niet nodig.
Door Anoniem: dat het kan, wil niet zeggen dat je het moet doen.
Dat geldt voor wel meer software.
Maar als het moeilijk stuk gaat, wie bel je dan?
Dan bel je minder vaak dan als het makkelijk stuk gaat.
Maar er zijn best wel freelancers en bedrijfjes die je support kunnen leveren. Je kan het ook als voordeel zien: Als de ene het niet goed doet kun je overstappen op een andere, zonder van een enkele fabrikant afhankelijk te zijn. Je huurt ze liever niet pas bij een calamiteit in. Je zorgt dat je weet wat ze kunnen en dat zij jouw infrastructuur kennen en je betaalt ze dus een beetje voor het stand-by staan en bijvoorbeeld patches bijhouden en andere administratrivia, en wat meer als ze moeten komen opdraven als er iets is.
Maar als je dit laat bouwen door een medewerker, die het bedrijf kan verlaten, dan loop je als eigenaar een groot risico dat een core-applicatie in je netwerk door niemand meer begrepen of beheerd kan worden.
Dan huur je een nieuwe. Of je belt zo'n support-bedrijfje.
Idem dito met een microsoft-monocultuur-infrastructuur, want je belt microsoft niet zelf, daar huur je "most valued partners" voor in. Je kan hooguit roepen dat daar de kennis of dan tenminste de certificaathouders makkelijker te vinden en dus in te huren zijn, maar ik heb daar geen cijfers van gezien.
Trouwens, in de enterprise-wereld kun je net zo goed een red hat enterprise linux inzetten, compleet met onderhoudscontracten en gecertificeerd personeel en weetikhet. Dus support daar is ook prima te regelen.
Je hebt wel gelijk dat als je (enige, met het bedrijf vergroeide) ITer ophoepelt er "core infrastructuur" op het spel staat, maar aanwezigheid van een clickibunti-GUI is geen garantie dat de achterblijvers het automatisch wel snappen. Obscure kaartenhuizen zijn altijd een risico. Daar doe je wat aan door secuur te (laten) documenteren, en iemand anders de documentatie te laten testen. Ongeacht het systeem wat je inzet.
Iets met een commandolijn heeft hier de voorkeur, want dat scheelt eindeloze bergen screenshots om je op allerlei miniscule belangrijke grafische details te wijzen.
Door Anoniem: Ik will alleen niet hebben dat ik dan een Samba 4 server heb maar dat die qua beveiligingsupdates achter loopt of wat dan ook.
Van microsoft ga je geen samba-updates krijgen. Die komen van samba, meestal via je linux distributie. Dat is dus appels met peren vergelijken.
En doordat het op Linux loopt lijkt het mij dat veel Windows Exploits niet zullen werken. Alhoewel het natuurlijk nog altijd veel van dezelfde protocollen gebruikt.
Er bestaan wel multi-platform-exploits maar die zijn heel erg zeldzaam. Als je iets weet van hoe dat met de exploits werkt dan snap je vanzelf waarom het niet zomaar multiplatform zal werken. Het is best interessant er wat te vinden en te kijken hoe en waarom ze wel werken.
Maar alleen al het feit dat samba een compleet andere code base is dan de microsoft smb/wins/ad/... implementatie betekent dat een exploit in de code niet automatisch overdraagbaar is. Ook al zijn het dezelfde protocollen, en als er misbruik wordt gemaakt van een protocol-feature dan moet je alle implementaties langslopen om te kijken of ze kwetsbaar zijn.
Tenzij het bijvoorbeeld een probleem is in de kerberos- of ldap-code die microsoft ongewijzigd heeft overgenomen. Dan ben je wellicht nog beter af met open source omdat de turnaround op bekend worden en patchen daar veel korter kan zijn. Je kan als je er goed inzit zelfs zelf de patches aanbrengen, of zelfs schrijven als je weet wat het probleem is. Dat is een hogere school die wel beschikbaar is met open source en met closed source veel minder. Maargoed, niet iedereen doet aan hogere school-IT.