Gratis Domaincontroller

[AliManali]

Hi

Ich habe diverse Clients (Win XP, 2k3, 7, 8.1, 10, ubuntu, opensuse, endian, freenas, enigmabox) auf meinem ESXi, und auf VMware Workstation auf dem Desktop und dem Laptop.

Nun wäre es schön, wenn ich da ein AD, bzw. DC hätte. Der soll, bzw. darf aber nichts kosten. Ich hätte da zur Verfügung: zywall 110, den ESXi mit 8 NIC's, Windows 2003 Server, freenas. Kann ich da was dafür nutzen? Kann das eventuell sogar meine zywall? Oder gibts da eine freie Lösung dafür? Kann das eventuell das NAS auch? -> Wenn nein, kann ich für "moderne" Clients noch den 2k3 Server nehmen, wenn der wirklich nur DC und DNS spielt, und ich auch sein Verkehr dementpsrechend beregle in der Zywall?

Ich hatte vor ein paar Jahren schon mal einen DC in Betrieb, aber schlussendlich hatte ich das Konzept dann wieder verworfen. Ich habe jetzt halt alles auf WORKGROUP gesetzt, allerdings sind es deutlich mehr Client's wie dort vorgesehen. Verteilt auf diverse VLAN's, bzw. Schnittstellen.

Ich brauche nicht die volle Funktionalität des M$ Server, nur Benutzerverwaltung und SMB, drucken und sowas. Darf auch gerne ein Linux sein.

Die Clients sollen auch laufen, wenn der DC aus ist.

 

[fdsonne]

Die Clients sollen auch laufen, wenn der DC aus ist.

Wie stellst du dir das vor?
Entweder der DC ist da und spielt zentrale Userdatenbank -> inkl. dem Connect für alle anderen oder du lässt es...

Mir scheint, dass du gar nicht weist, was du überhaupt willst bzw. welchen Zweck das überhaupt erfüllen soll. Warum also Aufwand betreiben? Lass es wie es ist und gut ist. Oder bau es um auf ein zentrales AD. Der 2003 Server geht grundsätzlich, wie lange noch, kein Plan. Win10 in einer 2003 AD geht wohl generell noch. Ob alles geht? Fraglich... Zumindest einige der GPOs könnten schwierig werden.
Du solltest dann aber eben auch sicherstellen, dass das Ding verfügbar ist. Sinnvollerweise solltest du dir gleich zwei von den DCs hinstellen als Redundanz. Von mir aus eins aufs Blech und eins in eine VM oder 2x VMs auf verschiedenen Hosts. Die DNS Infrastruktur MUSS funktionieren und die Zone des ADs muss für die AD Member verfügbar sein, sonst geht es imho nicht und/oder gibt Dreckeffekte.

 

[Batey]

ein DC sollte immer laufen, solange ein anderer Rechner in der Domaene auch an ist.

Das heisst nicht, dass gleich alles kaputt geht, wenn er aus ist.
Aber das ist schon ein essentielles Merkmal eines zentralen DC, das bei der Planung beruecksichtigt werden sollte.

 

[Steggi]

Oder gibts da eine freie Lösung dafür? [...] Ich brauche nicht die volle Funktionalität des M$ Server, nur Benutzerverwaltung und SMB, drucken und sowas. Darf auch gerne ein Linux sein.

Klar, du kannst dir unter Linux auch eine Samba Domäne hochziehen, wenn dir der 2003er Server zu alt / unsicher ist.
Mit Samba hast du zwar nicht alle Funktionen, die dir ein MS DC bietet, aber deine hier genannten Anforderungen sind kein Problem

Die Clients sollen auch laufen, wenn der DC aus ist.

Der DC sollte schon verfügbar sein, wenn du einen Client starten willst, vor allem, da deine Clients ihn auch als DNS Server nutzen müssen. Ist die DNS Zone deiner Domain für deine Clients nicht auflösbar, geht das ganze in die Hose.

Was mit Windows Clients recht problemlos läuft ist ein offline Login mit einem Domain Account. (Stichwort Cached Credentials) Vorausgesetzt du hast dich mit diesem Benutzeraccount bereits ein mal erfolgreich angemeldet. Etwas Lesestoff dazu gibts hier --> https://support.microsoft.com/en-us/kb/172931

Aber auch da gibts so einige Stolperfallen, angefangen von Benutzeraccounts deren Cached Credentials nicht mehr syncron mit denen des AD sind (weil du z.B. an einem anderen Client zum Passwortwechser für diesen User gezwungen wurdest) bis hin, dass du einfach zum falschen Zeitpunkt bzw. zu lange offline warst, so dass das AD das Passwort für den Computer Account automatisch geändert hat (das passiert defaultmäßig alle 30 Tage), dein Offlineclient davon aber nix mitbekommen hat, weil er eben offline war.

Überleg dir am besten noch mal deine Voraussetzungen und lies dich in das Thema ein, sonst gehts schief.

 

[AliManali]

Hi

Ja danke!

Mir geht es vor allem um die Namensauflösung der Clients im LAN. Da ich früher bereits ein AD wieder verworfen habe, werde ich wohl jetzt darauf verzichten. Ich glaube, das zieht mehr Nach- als Vorteile nach sich.

 

[rayze]

Wenn es dir rein um die Namensauflösung geht schnell dir nen kleinen rpi hin der bind (dns) + dhcp server spielt. Richte es ein und schon hast du eine Namensauflösung für deine Clients. Dafür ist kein AD nötig.

 

[tbol]

Wenn es dir rein um die Namensauflösung geht schnell dir nen kleinen rpi hin der bind (dns) + dhcp server spielt. Richte es ein und schon hast du eine Namensauflösung für deine Clients. Dafür ist kein AD nötig.

Oder zu setzt noch einen drauf und baust dir eine sambabasierende Windows-Domain auf den RPi. Der RPi kostet zwar, aber der DC wäre 4 free.
Ich selbst habe das vergangene Woche auch getan und der DC macht nun genau das was er soll: Verzechnisdienst, DNS, Gruppen & User-Management, Berechtigungen.

Edit: +DFS, um alle Shares aller Systeme, die ich brauche zentral zu halten.

 

[AliManali]

Hi

Ja, danke!

Ich würde das wenn schon virtuell auf dem ESXi aufsetzen, aber das ist ja nebensächlich. Den DNS und den DHCP lasse ich ich nun von der Zywall ausführen. Ich habe da mal alle MAC's eingetragen, und lasse die Adressen von der Zywall per DHCP vergeben. Das waren ganz schön viele MAC's und IP's ^^

Trotzdem wäre es noch nice, wenn ich trotzdem Usermanagement und Berechtigungen (AD) hätte. Macht das Sinn, bzw. wie verhält sich das, wenn der Samba also nur die genannten Dienste ausführt (DC/AD), NS und DHCP die Firewall übernimmt? Oder soll ich NS redundant machen, einmal zywall, einmal Samba?

Kann man die Samba Domain denn über den Browser administrieren? Oder läuft das über Konfigfiles und die Konsole? Ich habe da noch andere Baustellen im Linux Bereich, und habe da eigentlich schon genug Probleme mit. Ist zwar ziehmlich sexy, die Konfiguration von bspw. mySQL über die Konsole; aber für einen DC hätte ich schon gerne ein GUI, wenns geht.

Was mir auch nicht ganz klar ist, wie sich das mit der Namensauflösung momentan in der Workgroup verhält: macht da jeder Host seine eigene Namensauflösung? Wie finden sich denn die Clients untereinander im LAN? Ist die Broadcast IP für das da? An der Firewall habe ich bislang noch keine der betreffenden Host's im Nameserver eingetragen. Das habe ich dann als nächstes auf dem Plan.

Auf jeden Fall muss ich das erst mal testen mit der Samba Domain, bevor ich das produktiv einsetze. Da habe ich noch genug von meiner Erfahrung mit dem 2k3 DC.

Was soll ich denn für die Samba Domain für ein Linux einsetzen? Würds da z.B. ein Ubuntu 16.04 LTS mit GUI tun, oder gibts da gar spezielle Distris dazu?

Edit:

Dann, was ich in Erinnerung habe, funktioneren ja z.B. Nameserver oder Berechtigungen bei Windows und Linux nicht ganz gleich. Linux NS Server unterscheiden so Gross- und Kleinschreibung, während das Windows Pendant das nicht tut. Und bei den Berechtigungen gibt es auch gravierende Unterschiede. Wenn ich also eine Samba Domain aufsetze, nennen wir das einen Samba Domaincontroller, habe ich dann die Features von Linux, oder Windows auf beispielsweise einen meiner Windows Clients?

Ja, das +DFS Ding brauche ich glaube ich hauptsächlich. Es geht mir ja vor allem um die SMB Shares...

 

[tbol]

Hi

Ja, danke!

Ich würde das wenn schon virtuell auf dem ESXi aufsetzen, aber das ist ja nebensächlich. Den DNS und den DHCP lasse ich ich nun von der Zywall ausführen. Ich habe da mal alle MAC's eingetragen, und lasse die Adressen von der Zywall per DHCP vergeben. Das waren ganz schön viele MAC's und IP's ^^

Glaub ich gerne, aber so ist das nunmal. Wir tragen in der Firma auch alle IPs und MACs in eine Infoblox ein.

Trotzdem wäre es noch nice, wenn ich trotzdem Usermanagement und Berechtigungen (AD) hätte. Macht das Sinn, bzw. wie verhält sich das, wenn der Samba also nur die genannten Dienste ausführt (DC/AD), NS und DHCP die Firewall übernimmt? Oder soll ich NS redundant machen, einmal zywall, einmal Samba?

Der Samba Server kann auch ohne DNS und DHCP betrieben werden. Das ist kein Problem. Zu der Frage der Redundanz... Wie in den meisten Fällen kommt es auf die Umgebung drauf an.
Ich stelle mir dazu immer folgende Frage: Muss der Dienst permanent erreichbar sein?

• Ja -> Redundantes System aufbauen
• Nein, nur ein paar Stunden am Tag on -> keine Redundanz nötig

Natürlich kann man auch ein redundantes System aufbauen, wenn man nur x bis y Stunden am Tag den Dienst mal braucht. Generell muss das ja jeder für sich entscheiden.

Kann man die Samba Domain denn über den Browser administrieren? Oder läuft das über Konfigfiles und die Konsole? Ich habe da noch andere Baustellen im Linux Bereich, und habe da eigentlich schon genug Probleme mit. Ist zwar ziehmlich sexy, die Konfiguration von bspw. mySQL über die Konsole; aber für einen DC hätte ich schon gerne ein GUI, wenns geht.

Eine WebGUI gibt es meines Erachtens nicht, aber Samba lässt sich auch mit den RSAT-Tools administrieren.
Allerdings ist das bei Samba so eine Sache... hier in Kurzform was damit per GUI geht, soweit ich weiß:

• Active Directory-Benutzer und -Computer: Ja
• Active Directory-Domänen und -Vertrauensstellung: Ja
• Distributed File System (DFS): Nein
• ADSI Edit: Ja
• Gruppenrichtlinienverwaltung: Ja

Was mir auch nicht ganz klar ist, wie sich das mit der Namensauflösung momentan in der Workgroup verhält: macht da jeder Host seine eigene Namensauflösung? Wie finden sich denn die Clients untereinander im LAN? Ist die Broadcast IP für das da? An der Firewall habe ich bislang noch keine der betreffenden Host's im Nameserver eingetragen. Das habe ich dann als nächstes auf dem Plan.

Das kommt auf dein Netzwerk-Setup drauf an. Hostnamen können entweder im lokalen Cache eines Clients, in seiner Hosts Datei oder auf einem NS liegen.

Auf jeden Fall muss ich das erst mal testen mit der Samba Domain, bevor ich das produktiv einsetze. [...]
Was soll ich denn für die Samba Domain für ein Linux einsetzen? Würds da z.B. ein Ubuntu 16.04 LTS mit GUI tun, oder gibts da gar spezielle Distris dazu?

Zum Besipiel! Ich betreibe zu Hause eine Samba-Domain auf einem Raspberry Pi 3, dessen Betriebssystem Raspbian ist (eine Debian-Variante für den RPi).
Es gibt Linux-Distributionen, die auf so etwas spezialisiert sind oder zumindest damit werden sehr MS freundlich zu sein wie z.B.: Univention Corporate Server oder Zentyal Small Business Server

Dann, was ich in Erinnerung habe, funktioneren ja z.B. Nameserver oder Berechtigungen bei Windows und Linux nicht ganz gleich. Linux NS Server unterscheiden so Gross- und Kleinschreibung, während das Windows Pendant das nicht tut. Und bei den Berechtigungen gibt es auch gravierende Unterschiede. Wenn ich also eine Samba Domain aufsetze, nennen wir das einen Samba Domaincontroller, habe ich dann die Features von Linux, oder Windows auf beispielsweise einen meiner Windows Clients?

Wenn du einen Samba Domaincontroller aufsetzt dann in der Regel, um Windows-Clients anzubinden. Demnach kannst du davon ausgehen, dass du "Windows"-Shares hast und die Berechtigungen, dementsprechend, die von Windows sind.

Ja, das +DFS Ding brauche ich glaube ich hauptsächlich. Es geht mir ja vor allem um die SMB Shares...

An der Stelle kann ich dir gleich den Wind aus den Segeln nehmen, DFS geht (, soweit ich das weiß,) nur per Kommandozeile.
Aber DFS-Trees lassen sich dabei genau so bauen, wie man es unter Windows kennt.

Mit der einen Ausnahme, dass DFS-R und DRS (noch) NICHT funktionieren.


Alles in Allem ist die reine Installation einer Samba-Domäne in 10 Minuten erledigt und bietet (zumindest mir) alle Features, die ich benötige:

• DNS
• Benutzer-/Gruppenverwaltung (um die Bande zu Hause berechtigen zu können)
• DFS (für zentrale Zugriffsstelle unterschiedlicher Storage-System)
• Gruppenrichtlinien (um die diversen Windows-Clients zu Hause optisch anzupassen)
• DNS-Forwarding (für Anfragen außerhalb meines LANs -> dadurch Entlastung des Routers)

 

[AliManali]

Hi

Danke für Deinen ausführlichen Post! Da wurde ja schon mal Licht ins Dunkel gebracht.

Ich glaube, ich werde es einmal mit UCS Core Edition versuchen. Da mein ESXi sowie mein Desktop (Host win 10 mit VMware WS) 24/7 laufen, stellt sich die Frage, ob ich das Backupsystem auch auf dem Desktop in der WS laufen lassen könnte. Ist suboptimal, da das Windows 10 pro sich gerne mal nen unerwünschten Neustart genehmigt. Vielleicht wechsle ich aus dem Grund mal wieder auf Win 7 am Desktop. Aber wär das Szenario denkbar? Ein zusätzliches Blech kommt nicht in Frage. Auch wenn der Server die Grätsche machen würde, ist nicht gesagt, dass da schnell Ersatz kommt.

Dann habe ich jene Gateways, vLAN's, Firewall und VPN Apps und sowas. Das Netzwerk ist recht umfangreich. Kann/soll ich den Samba Server gleichzeitig an mehrere Netze hängen (also mit mehreren Adaptern)? Oder gehört der nur ins LAN, nur in die DMZ, oder wie läuft das?

Da ja offensichtlich ein offline Login möglich ist, welche Restriktionen habe ich dann in dem offline Modus? Sonst kann ich ja an den betreffenden Clients je einen lokalen sowie einen Domian-Benutzeraccount einrichten. So dass ich im Notfall die Clients wenigstens benutzen könnte. So hatte ich es mit meiner 2k3 Domain schon gelöst gehabt.

 

[Steggi]

Was mir auch nicht ganz klar ist, wie sich das mit der Namensauflösung momentan in der Workgroup verhält: macht da jeder Host seine eigene Namensauflösung? Wie finden sich denn die Clients untereinander im LAN? Ist die Broadcast IP für das da? An der Firewall habe ich bislang noch keine der betreffenden Host's im Nameserver eingetragen. Das habe ich dann als nächstes auf dem Plan.

Da gibts tatsächlich noch das gute alte NetBIOS Protokoll. Mal davon abgesehen, dass auch viele Homeroute z.B. die Fritzboxen, die Hostnames in ihren eigenen DNS schreiben, wodurch die lokal auflösbar sind.

Und bei den Berechtigungen gibt es auch gravierende Unterschiede. Wenn ich also eine Samba Domain aufsetze, nennen wir das einen Samba Domaincontroller, habe ich dann die Features von Linux, oder Windows auf beispielsweise einen meiner Windows Clients?

Die Dateisystemrechte unter Linux unterscheiden sich teils deutlich von den NTFS Rechten aus der Windowswelt. Unter Linux gibts nur den Besitzer, die Gruppe und den rest der Welt, denen du jeweils Lese-, Schreib- und Ausführungsrechte geben kannst. Das ganze kannst du zwar noch um ACLs erweitern, womit du die Berechtigungen auf weitere Benutzer bzw. Gruppen ausdehnen kannst, aber das wars dann auch schon.

Auf welche Features beziehst du dich genau?

Dann habe ich jene Gateways, vLAN's, Firewall und VPN Apps und sowas. Das Netzwerk ist recht umfangreich. Kann/soll ich den Samba Server gleichzeitig an mehrere Netze hängen (also mit mehreren Adaptern)? Oder gehört der nur ins LAN, nur in die DMZ, oder wie läuft das?

Der Domaincontroller sollte von jedem Client aus erreichbar sein, schließlich läuft die Authentifizierung darüber. Du solltest also schauen, dass auch der Traffic aus den VLANs am DC ankommt bzw. diese Clients über eine andere NIC den DC erreichen können.

Da ja offensichtlich ein offline Login möglich ist, welche Restriktionen habe ich dann in dem offline Modus? Sonst kann ich ja an den betreffenden Clients je einen lokalen sowie einen Domian-Benutzeraccount einrichten. So dass ich im Notfall die Clients wenigstens benutzen könnte. So hatte ich es mit meiner 2k3 Domain schon gelöst gehabt.

Der offline Login ist eigentlich eher für Notebook User gedacht, die auch mal von unterwegs mit ihrem Läppi arbeiten müssen. Generell fällt in deinem Szenario halt alles weg, was über die Domäne authentifiziert wird. Das könnte z.B. ein NAS mit seinen Freigaben sein, dass im Falle, dass du den DC abschaltest, nicht mehr prüfen kann, ob dein Domänenuser auf die Shares zugreifen kann.

 

[besterino]

Bringt denn ein SAMBA-DC auch sämtliche Features mit, die Server brauchen um sich gegenseitig zu vertrauen? Ich habe da noch so Kerberos-Themen (z.B. für Hyper-V Clustering) im Hinterkopf und und und. Ich habe davon nicht wirklich Ahnung - weder von Windows DCs noch von Linux DCs - und mit Windows-DCs funktioniert sowas natürlich ohne Probleme und ohne besondere Einstellungen.

Bevor ich mich damit auseinander setze, wäre das eine sehr interessante Vorabinformation! WENN es aber geht, wäre das ziemlich kewl, denn dann käme man dem kostenlosen Hyper-V Cluster mit EINFACHER Administration wieder einen Schritt näher...

Nachtrag: Ich glaub ich probier das einfach mal mit dieser Anleitung. Ein Ubuntu-Server ist ja schnell mal aufgesetzt.

 

[tbol]

Bringt denn ein SAMBA-DC auch sämtliche Features mit, die Server brauchen um sich gegenseitig zu vertrauen? Ich habe da noch so Kerberos-Themen (z.B. für Hyper-V Clustering) im Hinterkopf und und und. Ich habe davon nicht wirklich Ahnung - weder von Windows DCs noch von Linux DCs - und mit Windows-DCs funktioniert sowas natürlich ohne Probleme und ohne besondere Einstellungen.

Kerberos funktioniert mit Samba. Du kannst dir da ganz einfach *.ktab files erstellen und benutzen.
Alternativ geht natürlich immer ein eigener Kerberos-server, aber dafür braucht man m. E. nach schon eine gewisse größere Umgebung, die einen dedizierten Kerberos-Server rechtfertigen, ansonsten ist das "nice to have" oder aber Ressourcenverschwendung.

Kurz: Ja, geht mit Samba-Domain.

 

[besterino]

Puh. Dann muss ich also wohl wirklich mich mal dransetzen...

 

[danielmayer]

Evtl. mal den UCS ausprobieren?
https://www.univention.de/produkte/ucs/
Ist in der Core-Edition kostenlos, die Einrichtung ist webbasiert-

 

[besterino]

Core kann aber, wenn ich das und dies richtig verstehe, nur einem AD beitreten.

 

[AliManali]

Nachtrag: Ich glaub ich probier das einfach mal mit dieser Anleitung. Ein Ubuntu-Server ist ja schnell mal aufgesetzt.

Hi Hast Du das schon versucht? Ich habe mal UCS aufgesetzt. Aber ich denke, dass ich mich mal an Deine Anleitung ran mache. Dort konfiguriert man das AD auch über die MMC vom Client aus, so ist das bei M$ glaub ich auch üblich. Hinzu kommt, dass die Anleitung für ubuntu ist, da kenne ich mich auch am besten aus mit.

Core kann aber, wenn ich das und dies richtig verstehe, nur einem AD beitreten.

Eine Domain konnte ich erstellen damit, allerdings bevor ich das Lizenzfile eingegeben habe. Das geht also schon, so wie ich das verstanden habe.

Und dann stellt sich mir immer noch die Frage, dass wenn ich DNS und DHCP die Firewall machen lasse, was entstehen mir da für Nachteile? Ist das üblich, oder sollte ich das besser sein lassen? Ich habe halt schon alle Gateways, Host's und DHCP per MAC eingerichtet. Dazu muss ich sagen, falls es keinen Unterschied macht, würde ich das schon gerne die Firewall machen lassen,...

 

[tbol]

Und dann stellt sich mir immer noch die Frage, dass wenn ich DNS und DHCP die Firewall machen lasse, was entstehen mir da für Nachteile? Ist das üblich, oder sollte ich das besser sein lassen? Ich habe halt schon alle Gateways, Host's und DHCP per MAC eingerichtet. Dazu muss ich sagen, falls es keinen Unterschied macht, würde ich das schon gerne die Firewall machen lassen,...

Nachteile entstehen dir keine. Es ist (wie fast immer) eine Frage des Anwendungsfalles und der Größe deiner Umgebung/Anzahl der Zugriffe von innen/außen und deines Verständnisses von Performance.

Beispiel:

• Viel Traffic intern, weil viele Personen und viele Systeme oder Netze miteinander sprechen, dann ist DNS/DHCP auf Firewall vielleicht keine gute Wahl, weil die schon genug mit den Firewall-Themen beschäftigt ist.
• Wenig Traffic intern: Alles auf einer Kiste ist schöner, da bequemer zu administrieren
• Ist Ausfallsicherheit ein wichtiges Thema: Alles auf dedizierten Maschinen, die redundant vorhanden sind
• ...

Hier mal ein Auszug aus meiner Umgebung.

Auf AD-Domain-Controller (auf RPi):

• DNS-Server mit Forward auf Router für Anfragen nach draußen

Auf Router/Firewall:

• DHCP-Server
• Gateway

Weiteres:
Jeder Client, der die Domain joint bekommt per Group-Policy DNS-Server und Search-Scope aufgebügelt, d.h. alle Clients der Domäne nutzen den DC als DNS-Server. Sollten Anfragen nach draußen gehen (google.de, hardwareluxx.de, etc.) werden an den Router geforwarded (furchtbares Denglisch, sorry).


Der Bequemlichkeit halber lass alles auf der FW, wenn du es eh schon eingerichtet hast.