Server dumm installiert...

[klayman]

Hallo zusammen,

der Titel sagt es schon ziemlich genau. In einem kleinen Unternehmen mit 5 PC Arbeitsplätzen und Mitarbeitern wurde ein Windows 2022 Standard Server von einem "IT-Frank" aufgesetzt (jeder hat einen IT-Frank...). Auf dem Server laufen File Shares und eine Art Warenwirtschaftssystem, außerdem wurde der Server als DC installiert. Nach einem ersten Blick (aufgrund privater Hilferufe) habe ich ein paar haarsträubende Probleme entdeckt:

• Alle User sind Domain Admins (das mach Fileshare Berechtigungen witzlos)
• Admin User noch aktiv und Passwort besteht aus Teil vom Domänennamen und Jahreszahl
• Manche Client PCs in der Domain, manche nicht
• Backup auf lokaler Festplatte abgelegt
• Jeder Nutzer hat Zugriff auf die Backup-Files (inkl. der DB-backups)
• RDP per Portweiterleitung frei im Internet erreichbar
• Eingerichtete Domäne trägt den gleichen Namen wie eine bereits existierende, der Firma aber nicht gehörende Domain

Klar, das Ding muss neu, zumindest wenn man sicher sein will, dass es nicht schon kompromittiert ist. Was mich aber noch dringend interessiert: Welchen Einfluss hat ein im Internet bereits existierender Domänenname, außer dass die Namensauflösung für diesen aus dem internen Netz nicht funktioniert? Kann es zu Problemen kommen, wenn z.B. beide Firmen zukünftig mal MS Azure Services nutzen wollen? Gibt es noch andere Nachteile?

Danke & Viele Grüße,
Klayman

 

[besterino]

Das läuft bei mir nicht unter dumm installiert, sondern völlig ahnungslos wenn nicht gar böswillig hingerotzt…

 

[Eye-Q]

Welchen Einfluss hat ein im Internet bereits existierender Domänenname, außer dass die Namensauflösung für diesen aus dem internen Netz nicht funktioniert? Kann es zu Problemen kommen, wenn z.B. beide Firmen zukünftig mal MS Azure Services nutzen wollen?

Das sind auf jeden Fall die gravierendsten Nachteile, mehr Gründe braucht es eigentlich gar nicht, den vorhandenen Server softwaremäßig komplett wegzuwerfen und eine komplett neue Domäne einzurichten.

Es wurde mal geraten. als TLD für interne Domänen .local zu verwenden, das ist aber inzwischen auch überholt. Aktuell wird empfohlen, eine Subdomain einer (hoffentlich) vorhandenen öffentlichen Domain zu verwenden, also wenn die öffentliche Domain beispiel.de heißt, dann könnte die interne Domäne intern.beispiel.de genannt werden.

Das läuft bei mir nicht unter dumm installiert, sondern völlig ahnungslos hingerotzt…

Diese Aussage hilft dem Threadersteller nur leider genauso wenig wie der schon eingerichtete Server...

 

[klayman]

Herzlichen Dank für Eure schnellen Antworten. Ja, schon klar dass das ohne Ahnung war. Das erkenne selbst ich ;-) Wir sammeln gerade Argumente warum neu installiert werden muss. Eine potentielle Komprimittierung lässt sich schlecht nachweisen. Das mit dem Domänennamen ist einfacher. Hintergrund: Die Installation des WW-Systems erfordert Herstellersupport der dann erneut bezahlt werden will. Die Kosten möge der IT-Frank bitte tragen, der ziert sich aber ;-)

Also: Das mit der Domäne ist so als würde jemand einen DC mit der Domain spiegel.de installieren. Ich brauche Argumente was jetzt nicht mehr geht oder man sich zukünftig verbaut hat.

 

[p4n0]

Lauf einfach weg. Das brennt doch einfach nur. Was willst da groß argumentieren?
NEU MACHEN, punkt.

 

[Tremendous]

Ich frage mich was für Argumente du noch brauchst außer den genannten. Selbst einer davon rechtfertigt ein neues Aufsetzen der Infrastruktur.
Alle zusammen eine fristlose Kündigung, das ist schon grob fahrlässig.

 

[Senator Wurstbein]

Ich würde erstmal Backups ziehen und außer Haus lagern. Falls die Bude noch nicht kompromitiert ist, kann das sehr bald passieren. Dann will man wenigstens möglichst frische Sicherungen haben, da die WW Daten und fileshare sonst unwiederbringlich weg sind.

Danach alles mit Feuer töten.

 

[p4n0]

Was bringen denn hier irgendwelche Sicherungen von einem System, wo jeder mit DA herumturnt?
Man kann bei so nem Truemmerhaufen davon ausgehen, dass saemtliche Daten manipuliert sind. Das ist alles kernschrott und gehoert entsorgt und neu gemacht.

 

[Steggi]

Grundsätzlich ist eine Sicherung / Archivierung des Jetzt-Zustandes erstmal nicht verkehrt.

Anschließend um folgende Dinge kümmern:

• Anständige Firewall anschaffen, optimalerweise ist ein VLAN fähiger Switch vorhanden, Stichwort eigenes Backup VLAN, falls du auf ein NAS sichern willst / kannst.
• Server neu aufsetzen mit Hyper-V Rolle, darauf zwei VMs: DC mit Fileshare und einen Appserver für deine Warenwirtschaft.
• Auf dem Hyp (der im AD nix verloren hat) die Backupsoftware z.B. Veeam, alternativ in eine eigene VM, falls weitere Lizenzen vorhanden sind.
• VLAN für Backupnetz anlegen. In dieses kommt nur das NAS als iSCSI Target.
• Firewall passend konfigurieren, nur der Hyp darf das NAS erreichen.
• Zusätzliche Offsite-Kopie der Backups konfigurieren z.B. auf wöchendlich wechselnde USB Platten.
• Sinnvolles Rechtekonzept nach Least-Privilege-Prinzip ausarbeiten und umsetzen.
• Ggf. VPN konfigurieren, Erreichbarkeit von RDP und sonstigen Management Möglichkeiten auf administrativen VPN User beschränken.
• Ggf. eigenes Management VLAN für Hyper-V, Switchmanagement, IPMI / iDRAC / ILO konfigurieren und den Zugriff darauf einschränken.

Was mich aber noch dringend interessiert: Welchen Einfluss hat ein im Internet bereits existierender Domänenname, außer dass die Namensauflösung für diesen aus dem internen Netz nicht funktioniert?

Es wurde mal geraten. als TLD für interne Domänen .local zu verwenden, das ist aber inzwischen auch überholt. Aktuell wird empfohlen, eine Subdomain einer (hoffentlich) vorhandenen öffentlichen Domain zu verwenden, also wenn die öffentliche Domain beispiel.de heißt, dann könnte die interne Domäne intern.beispiel.de genannt werden.

Kann man natürlich so machen, man muss dann aber natürlich auch in der Lage sein 1. Split-DNS korrekt zu konfigurieren und 2. damit klarkommen, dass Clients außerhalb des Firmennetztes versuchen interne Ressourcen über öffentliche Resolver aufzulösen und somit Informationen preisgeben.

Kann es zu Problemen kommen, wenn z.B. beide Firmen zukünftig mal MS Azure Services nutzen wollen? Gibt es noch andere Nachteile?

Optimalerweise bindest du deine eigene (öffentliche) Domäne an Azure an, damit z.B. User sich nicht mit einer .onmicrosoft.com Domain einloggen müssen, du diese Domain für den Mailversand usw. nutzen kannst.
Wird diese bereits von einem anderen Tenant genutzt, hast du Pech gehabt.
Wenn dein on premise AD eine nicht öffentlich erreichbare Domain nutzt z.B. firma.local, dann ist das auch kein Problem, aber du musst dann eben die öffentliche Domain im AD als UPN-Suffix hinzufügen und den UPN deiner User anpassen.
Ist die öffentliche Domain dann auch an Azure angebunden kannst du recht einfach deine User per Azure AD Connect mit dieser Domain hochsyncen.

 

[klayman]

Danke Steggi und allen anderen. Backups werden glücklicherweise regelmäßig über mehrere Generationen gemacht und auch außer Haus auf Bändern gelagert. Deine Vorschläge kann ich alle nachvollziehen, das ist aber nicht mein Home Turf, sprich die Firma muss sich ohnehin einen professionellen Dienstleister suchen. Die Hinweise zu AAD Connect waren nochmal gut, ich denke wir werden jetzt ein ernstes Gespräch mit dem IT-Frank suchen ;-)

 

[OlafE]

Moin,
eine Domäne könnte man umbenennen, kann allerdings auch schief gehen..

AD-Domäne umbenennen: Was man dazu wissen sollte | faq-o-matic.net

www.faq-o-matic.net

Ansonsten alle wesentlichen Infos zu Benutzerobjekten und gewollten Berechtigungen mit PowerShell in eine Datei exportieren (und später aus dieser in die neue Domäne importieren). DHCP und besondere DNS-Einträge nicht vergessen.
Das Warenwirtschaftssystem könnte eine Herabstufung als Domänencontroller und die Auflösung der Domäne ggf. überleben, wenn keine Domänenkonten für Dienste oder innerhalb des Systems verwendet werden, sondern dieses seine eigene Benutzerdatenbank hat. Danach bleibt der Server am besten ein Mitgliedsserver, ließe sich aber notfalls auch wieder hochstufen. (Ich hatte das Szenario auch mal bei einem Kunden, allerdings blieb dabei die Domäne noch erhalten.

Ist die Maschine direkt auf Blech oder virtualisiert? Steht ggf. weitere Serverhardware (auch leihweise) zur Verfügung, auf die man den Server virtualisieren könnte? Eine Windows Server-Standardlizenz ermöglicht ja, den Basisserver ohne weitere Aufgaben als Hyper-V-Host aufzusetzen und dazu zwei virtuelle Maschinen mit demselben Key. (Ich nutze für solche Migrationsübungen gern StarWind Converter.)

Wenn die Ressourcen reichen, virtualisieren, physische Box herunterfahren, alles ausprobieren und umstellen wie gewollt und dann Hyper-V Host auf der Ursprungshardware einrichten und die VMs zurückverschieben.

Viele Grüße
Olaf