Samba naar Azure AD

[SpecialK]

Ik beheer de IT voor een kleine organizatie. We zijn 6 jaar geleden opgestart met een paar medewerkers en hebben toen gekozen voor Samba als Active Directory en Google Workspace als mail/file storage.

Ondertussen lopen we tegen wat beperkingen aan, en zou ik willen starten met de AD te verhuizen van Samba naar Azure AD.
We gebruiken Samba 4.14 op een Debian machine. Het is geen evidentie om te migreren oa omdat je eerst een Windows 2008 DC moet opzetten om de data te importeren; nieuwere versies zijn niet ondersteund. Ik heb in het verleden al eens een poging gedaan en ben tegen dezelfde problemen aangelopen als Sasuke in het frustratie-topic uitte; op den duur heb ik het maar zo gelaten.

Momenteel zitten er een kleine 20 users in de AD waardoor ik me afvraag of het eigenlijk wel de moeite is om die bestaande database te migreren. Ik kan eigenlijk evengoed een nieuwe AD in Azure opzetten en op een maandelijkse teammeeting zeggen: zometeen krijgen jullie allemaal een nieuw wachtwoord en gewoon van nul beginnen.

Wat ik wel wil vermijden is dat ze een nieuw profiel krijgen op hun pc. Ik vrees echter dat het niet zo simpel is als de DNS-records omzetten naar de nieuwe server, en de users met hun nieuw paswoord laten inloggen. Maar is er een mogelijkheid om toch het bestaande profiel te behouden? De naam van het domein blijft uiteraard dezelfde.

[Sasuke]

ProfWiz ... gratis, snel en werkt perfect Is wel manueel ff de PC's aflopen, maar voor 20 werkstations is dat nog wel te doen denk ik, met 2 man al eens een productiehal van 100PC's op 1 dag gedaan ...

Domeinnaam moet zelfs niet eens behouden worden (zou ik ook afraden trouwens ... beter iets nieuws, zeker de netbios naam niet gelijk houden !)

[SpecialK]

Wat zijn de nadelen van de Netbios naam gelijk houden?

[Sasuke]

netbios is broadcast, dus buiten DNS om. Als beide domaincontrollers in zelfde netwerk zitten ga je vodden krijgen ... daarom best de netbios naam niet gelijk houden. UPN/fqdn maakt ni uit, das puur DNS.

[SpecialK]

Dat begrijp ik toch niet helemaal. Als ik Azure AD gebruik staat die tweede toch sowieso niet in hetzelfde netwerk?

Maar kan je Azure AD eigenlijk wel gebruiken als een alternatief voor een lokale AD, wat betreft de authenticatie? GPO en zo hebben we vandaag ook niet, dus het feit dat je dat via Intunes moet regelen is wel acceptabel. En als het al kan, kan je dan je de klassieke syntax van een gebruikersnaam behouden (DOMAIN\username)? Of zie ik het allemaal wat te simpel?

[meon]

Windows-machines kunnen puur met Azure AD gejoined zijn, zonder lokale domeincontroller.

Je hebt geen SAMAccountname en domeinnaam meer, enkel een UserPrincipalName die meestal gelijk gehouden wordt met het e-mailadres.
Op je pc zit je profiel dus in een map C:\Users\[email protected]\Documenten etc.
De vraag is vooral of er nog lokale resources zijn waar je aan moet kunnen?

[SpecialK]

Nee, geen lokale fileservers. Wel een aantal RDP servers maar die kunnen mee naar de nieuwe AD gemigreerd worden.

Bijkomende complexiteit is dat de mail (en dus de domeinnaam) momenteel bij Google zit en dat we voor de Office pakketten een Microsoft-account hebben met het onmicrosoft.com domein. Daarom had ik graag de bestaande syntax van gebruikersnamen behouden, anders sleuren we die onmicrosoft tot in de eeuwigheid mee.

[Sasuke]

Ben niet helaas mee wat je nu wenst te doen ? Je kan geen onpremise domainconteoller houden als je naar full AzureAD wil gaan.

Ik zou in geval gewoon een nieuw domein maken met domainconteoller, je pc’s omschakelen en je lokale AD KOPPELEN/ synch en met AzureAD voor SSO en logons tussen lokaal en AAd gelijk kan houden. Daarna kan je nog kijken naar hybrid azuread join op op termijn je lokale infra af te bouwen.

Je kan bvb je lokale Onpremise servers (eg rds) niet in AzureAD joinen, dus als je je samba weg wil moet je die uit het domein halen en standalone/workgroup gebruiken (andere logons) als je geen lokaal domein houdt. Of staan je rds’en al in Azure ?

[SpecialK]

Huidige situatie: een lokale ESXi cluster met daarop (Debian) Samba server die als AD dienst doet, en een aantal virtuele desktops (allemaal Windows 10 LTSC). De reden waarom we die nodig hebben, is omdat we een paar programma's gebruiken die "node locked" zijn, maw hun licentie via een USB dongle afdwingen. Er zijn een paar verschillende mensen die die programma's gebruiken; om te vermijden dat USB dongles doorgegeven moeten worden en zeker in combinatie met homeworking heb ik het dan maar met lokale Windows virtual desktops opgelost waarbij we de USB-sticks in de ESXi host laten zitten. De node locked programma's werken niet op een multi-user omgeving zoals Windows Server (want dan zou je meerdere sessies tegelijk kunnen opstarten met dezelfde USB dongle) dus we hebben een paar van die Windows 10 virtuele desktops opgezet met daarop telkens het programma geïnstalleerd, en elke desktop heeft zijn eigen dongle. Deze virtuele desktops gebruiken de lokale AD voor authenticatie.
De programma's bestaan ook niet node-locked (met netwerk license manager) waarbij je de USB dongles niet nodig hebt, en dan zou de hele omgeving kunnen verhuizen naar een cloud provider. Maar als je ziet wat dat programma per jaar extra kost als je NIET node locked verkiest...daarvoor kon ik een mooie ESXi omgeving opzetten

Tot nu toe werkt dat eigenlijk goed; enkel als een VM van fysieke host verhuist loopt het mis omdat de USB dongle dan niet meer fysiek bereikbaar is. Maar daar hebben we eigenlijk nog geen problemen mee gehad.

Daarnaast een twintigtal laptops (allemaal Windows 10).
Ik zou het liefst geen lokale AD meer opzetten, de Samba afvoeren en alles ineens in Azure opzetten. Ik zou op termijn ook naar Office365 willen switchen want Google Workspace heeft toch wel een aantal serieuze nadelen én kost evenveel. Maar momenteel zitten we dus nog op Google Workspace, en dat volledig overzetten gaat wel wat tijd kosten, waardoor de domeinnaam dus ook nog bij Google zit. Bij de migratie Google -> Office365 wil ik liefst niet teveel op elke lokale pc aanpassen; als je pc al in AD zit kan je bij mijn weten vrij makkelijk de Outlook/Teams instellingen pushen; met mijn Samba oplossing moet dat helaas nog manueel.
Of zie ik dat verkeerd en doe ik het beter in de andere volgorde?

[Sasuke]

Zelfs Samba ondersteund Group Policies, dus pushen van settings kan. Je wil geen lokale AD , dat kan … maar je servers kunnen niet volgen dus user auth zal niet meer AD integrated zijn.

Daarnaast, je gaat je PC’s best uit het domein halen (profwie kan daar ook mee helpen) om ze daarna AzureAD te joinen. Opgelet, als je settings e.d. Via AzureAD wil regelen heb je ook een Intune licentie of de juiste M365 licentie nodig.

Ik zou je toch laten bijstaan, je gaat anders toch snel voor een blok staan als je niet op voorhand alles goed bekijkt qua authenticatie en AD.

[SpecialK]

Ik overweeg het uit te besteden, maar ik moet natuurlijk wel de juiste vraag kunnen stellen en weten wat de opties zijn.
Vandaag zijn de "servers" ook niet geïntegreerd; wanneer een gebruiker met zo'n remote desktop verbindt krijgt die opnieuw een login scherm te zien. De "servers" maken wel gebruik van dezelfde AD database natuurlijk. De servers draaien Windows 10 en hebben internetconnectiviteit. Dus waarom zouden die zich met Azure AD anders gedragen dan de laptops?

[Sasuke]

Je 'kan' een server niet joinen in AzureAD. AzureAD != ActiveDirectory
Je kan een lokale AD wel compleet verbinden (federeren) met AzureAD zodat je bvb je clients in AzureAD hebt zitten, maar dat beide directories de nodige attributen uitwisselen zodat devices en users zowel lokaal als Cloud gekend en vertrouwd zijn. Zonder lokale AD kan je met een useraccount die in AzureAD bestaat niet aanloggen op je RDS bijvoorbeeld (Om het simplistisch voor te stellen: Je hebt een user in de cloud [email protected] - dan ga je met die user niet kunnen aanloggen op je RDS. Je RDS gaat een lokale user uit AD of workgroup verwachten want die kent geen 'cloud' AzureAD)

Wat is eigenlijk je doelstelling ? Voor je verder staart op die AzureAD, wat wil je eigenlijk bekomen .. want uiteindelijk blijf je inderdaad nog (tijdelijk) met die google workspace zitten. Heb je reeds een M365 tenant voor je Office (apps) licenties toevallig, of andere dingen ? Is het de bedoeling om ooit alle (lokale) servers weg te doen ?

[SpecialK]

De bedoeling is om op termijn van een paar "infrastructuur" servers (waaronder de AD) af te raken.

Als we migreren naar O365 zou ik graag de instellingen naar pc's kunnen pushen; zodra een medewerker de eerste keer aanmeldt worden Outlook en Teams automatisch geconfigureerd. Voor Google Workspace moet ik momenteel nog op elke nieuwe pc de Outlook sync applicatie configureren. Niet onoverkomelijk veel werk maar ik zou het graag wat meer automatiseren. Maar om daarvoor nu speciaal een Windows Server te gaan opzetten ter vervanging van mijn Samba server, dat vind ik eigenlijk wat teveel moeite want dan zit ik nadien gewoon met een Windows server ipv een Linux server die ik moet beheren.

Wat ik echter nog altijd niet begrijp is waarom ik op een RDS (die een "gewone" Windows 10 is) niet via Azure AD credentials zou kunnen aanmelden, als het op een laptop wel kan. Als ik op een laptop RDP zou toelaten zou ik toch ook met de "gewone" credentials van die laptop kunnen aanmelden?

[Sasuke]

Omdat Microsoft een commerciële partij is die heenreis ziet in servers toe te laten op AzureAD zolang ze onpremise staan. Een server in Azure kan je, mits beperkingen, toevoegen aan AzureAD.

Als je me niet gelooft, zoek het op

Wat betreft instellingen pushen … dat kan dan enkel met Intune mits de juiste licentie. Je hebt namelijk geen AD, AzureAD is een directory, de functionaliteit van group policies e.d. Is niet aanwezig. En fileserver Security op basis van AzureAD groepen kan ook niet trouwens…

Er is een reden waarom niet alle kmo’s reeds volledig in de cloud zitten hoor
En zie dat je zeker afstapt van de illusie dat een AzureAD/Intune/O365 combinatie makkelijker in beheer is dan een kleine AD omgeving

[SpecialK]

Dus als ik het goed begrijp is nog eventjes verderdoen zoals ik het nu doe nog niet zo'n slechte optie? De Samba server MOET niet weg; het is eerder vanuit het standpunt: elke server die weg is is er één minder waar het mis kan gaan

Iemand al enige ervaring met Jumpcloud? Dat lijkt op het eerste zicht ook een mogelijk alternatief.

[Sasuke]

Jumpcloud is 'een' alternatief, maar kan geen proprietary AD vervangen spijtig genoeg ... maar ik snap dan echt niet waarom die lokale AD optie géén optie is ? Beheer van een lokale AD voor een kleine KMO is na de setup toch redelijk beperkt tot patch management ? niet ?

Eens je dat hebt, dan kan je de inbegrepen voordelen van een hybride koppeling met AzureAD ook gaan gebruiken (e.g. self-service password reset - writeback to local AD), Single SignOn (zowel handig voor de gebruiker als veilig), integrated MFA, ....

't is echt kiezen hoor. Ofwel blijf je bij ActiveDirectory (Samba of Microsoft), ofwel ga je naar de cloud. Maar in de laatste optie heb je géén oplossing voor lokale servers (indien Windows) zonder lokale AD.

Succes !

PS: Ja, blijven voortdoen is dan de betere optie ... maar ik zou die SAMBA toch vervangen door een Windows DC zodat je ADMX'en voor Teams e.d. kan inladen. Licentiegewijs ben je toch al in flagrante overtreding met die virtuele Win10 desktops, dus die 1 server zal het niet meer uitmaken