8
Zugriff für Software-Entwickler auf Server (VM)
Hallo,
ich hab einen Windows Server 2022 als Hyper-V VM als Domänen-Mitglied, auf der eine spezielle Software läuft.
Dieser Server soll eben auch jederzeit von der Software-Firma erreichbar sein. Ein VPN dafür ist eingerichtet (VPN nur auf die IP-Adresse des Servers mit Port 3389 möglich).
Ich möchte den Jungs natürlich ungern den Domänen-Admin geben ... da aber durch Installationen, Updates etc. Adminrechte notwendig sind, erstelle ich dann einfach für das Unternehmen einen lokalen User und gebe diesem lokale Adminrechte?
ich hab einen Windows Server 2022 als Hyper-V VM als Domänen-Mitglied, auf der eine spezielle Software läuft.
Dieser Server soll eben auch jederzeit von der Software-Firma erreichbar sein. Ein VPN dafür ist eingerichtet (VPN nur auf die IP-Adresse des Servers mit Port 3389 möglich).
Ich möchte den Jungs natürlich ungern den Domänen-Admin geben ... da aber durch Installationen, Updates etc. Adminrechte notwendig sind, erstelle ich dann einfach für das Unternehmen einen lokalen User und gebe diesem lokale Adminrechte?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 62733409207
Url: https://administrator.de/contentid/62733409207
Ausgedruckt am: 21.11.2024 um 21:11 Uhr
8 Kommentare
Neuester Kommentar
Moin...
hm, je nach art der software, kommst du nicht weit mit lokalen admin rechten, in einem AD Netzwerk.
Frank
Ich möchte den Jungs natürlich ungern den Domänen-Admin geben ... da aber durch Installationen, Updates etc. Adminrechte notwendig sind, erstelle ich dann einfach für das Unternehmen einen lokalen User und gebe diesem lokale Adminrechte?
hm, je nach art der software, kommst du nicht weit mit lokalen admin rechten, in einem AD Netzwerk.
Frank
Moin,
Hat den Vorteil, dass man div. Dinge per GPO noch mit regeln kann, wenn es ein AD-User ist. Z.B. Regeln in der Firewall dem WebProxy oder aber mitgeben bestimmter Einstellungen etc..
Und du kannst in den Eventlogs der DCs auslesen, wann der User sich irgendwo an-/ abgemeldet hat…
erstelle ich dann einfach für das Unternehmen einen lokalen User und gebe diesem lokale Adminrechte?
Wir legen immer einen User im AD an, der dann auf der Maschine lokale Adminrechte bekommt. Der User darf sich dann auch nur dort anmelden.Hat den Vorteil, dass man div. Dinge per GPO noch mit regeln kann, wenn es ein AD-User ist. Z.B. Regeln in der Firewall dem WebProxy oder aber mitgeben bestimmter Einstellungen etc..
Und du kannst in den Eventlogs der DCs auslesen, wann der User sich irgendwo an-/ abgemeldet hat…
1
Zitat von @em-pie:
Moin,
Hat den Vorteil, dass man div. Dinge per GPO noch mit regeln kann, wenn es ein AD-User ist. Z.B. Regeln in der Firewall dem WebProxy oder aber mitgeben bestimmter Einstellungen etc..
Und du kannst in den Eventlogs der DCs auslesen, wann der User sich irgendwo an-/ abgemeldet hat…
Moin,
erstelle ich dann einfach für das Unternehmen einen lokalen User und gebe diesem lokale Adminrechte?
Wir legen immer einen User im AD an, der dann auf der Maschine lokale Adminrechte bekommt. Der User darf sich dann auch nur dort anmelden.Hat den Vorteil, dass man div. Dinge per GPO noch mit regeln kann, wenn es ein AD-User ist. Z.B. Regeln in der Firewall dem WebProxy oder aber mitgeben bestimmter Einstellungen etc..
Und du kannst in den Eventlogs der DCs auslesen, wann der User sich irgendwo an-/ abgemeldet hat…
Klingt gut. Wie bekomm ich das denn hin das sich der User dann NUR auf der Maschine anmelden kann / darf?
Moin,
die Begrenzung auf welchen AD-Objekten eine Anmeldung ermöglicht werden soll, klappt via User-Tab und dort "LogOnTo" oder so ähnlich, da konnte man die dementsprechenden Computer-Objekte auswählen.
Den lokalen Admin würde ich in eine Gruppe packen und diese Gruppe via "Restricted Groups"-GPO als lokalen Admin verteilen.
Noch hast du dadurch zwar nur wenige Vorteile, allerdings wachsen solche Lösungen wie deine idr immer an. Heute gibts eine Instanz, morgen 2, nächsten Montag 5, weil noch mehr darauf arbeiten müssen / wollen.
Dann kannst du die ganzen Computer-Objekte in eine OU packen, die GPO dort drauflegen und hast deinen Admin immer auf allen Systemen verteilt ;)
die Begrenzung auf welchen AD-Objekten eine Anmeldung ermöglicht werden soll, klappt via User-Tab und dort "LogOnTo" oder so ähnlich, da konnte man die dementsprechenden Computer-Objekte auswählen.
Den lokalen Admin würde ich in eine Gruppe packen und diese Gruppe via "Restricted Groups"-GPO als lokalen Admin verteilen.
Noch hast du dadurch zwar nur wenige Vorteile, allerdings wachsen solche Lösungen wie deine idr immer an. Heute gibts eine Instanz, morgen 2, nächsten Montag 5, weil noch mehr darauf arbeiten müssen / wollen.
Dann kannst du die ganzen Computer-Objekte in eine OU packen, die GPO dort drauflegen und hast deinen Admin immer auf allen Systemen verteilt ;)
Deine Formulierung lässt durchscheinen, dass Du selbst den Domänenadmin für die Administration von Memberservern nutzt. Dafür ist er nicht gedacht und die Risiken, ihn auf Servern zu nutzen, wo auch Dritte (Externe sogar!) Adminrechte haben, sind ernst.
Setze dich mit dem Stichwort Admin-Tiering auseinander und nutze in Zukunft den Domänenadmin nur noch auf DCs.
Wenn die Externen Adminrechte auf dem Server brauchen, dann gib ihnen einen lokalen Benutzer und pack den in die lokale Admingruppe. Müssen Sie auf Domänenressource zugreifen, gib ihnen stattdessen einen Domänennutzer und pack den in die lokale Admingruppe. Stelle zudem auf dem Server sicher, dass dort keine zwischen gespeicherten Credentials liegen, denn die kann jeder andere lokale Admin nun auslesen.
Setze dich mit dem Stichwort Admin-Tiering auseinander und nutze in Zukunft den Domänenadmin nur noch auf DCs.
Wenn die Externen Adminrechte auf dem Server brauchen, dann gib ihnen einen lokalen Benutzer und pack den in die lokale Admingruppe. Müssen Sie auf Domänenressource zugreifen, gib ihnen stattdessen einen Domänennutzer und pack den in die lokale Admingruppe. Stelle zudem auf dem Server sicher, dass dort keine zwischen gespeicherten Credentials liegen, denn die kann jeder andere lokale Admin nun auslesen.
1
... hab das ganze jetzt mal so ausgetestet.
Wenn ich nun die RDP Verbindung aufbaue (wenn Log-on to auf diesen einen Server beschränkt ist) ... bekomme ich die Fehlermeldung:
"Der Systemadministrator hat die Computer beschränkt, mit denen Sie sich anmelden können. ........"
Sobald ich das "Log on to" herausnehme, klappt soweit alles.
Habs mit domain\user und user@domain.tld versucht. Bei erstem kommt die Meldung und bei zweiten sagt er einfach nur Anmeldung fehlgeschlagen.
Hast du da ne Ahnung?
Wenn ich nun die RDP Verbindung aufbaue (wenn Log-on to auf diesen einen Server beschränkt ist) ... bekomme ich die Fehlermeldung:
"Der Systemadministrator hat die Computer beschränkt, mit denen Sie sich anmelden können. ........"
Sobald ich das "Log on to" herausnehme, klappt soweit alles.
Habs mit domain\user und user@domain.tld versucht. Bei erstem kommt die Meldung und bei zweiten sagt er einfach nur Anmeldung fehlgeschlagen.
Hast du da ne Ahnung?
Wenn am Zielserver NLA für RDP aktiv ist (und das ist der default), dann musst du auch den Rechnernamen, von dem die Verbindung kommt, bei Logon to eintragen.
Moin,
Wäre es nicht sinnvoller die VM in ein abgeschotteten Bereich (extra VLAN, Trennung durch eine Firewall) abzulegen und durch ein zentrales VPN Gateway in der DMZ den Zugriff erlauben.
Gruß,
Dani
ich hab einen Windows Server 2022 als Hyper-V VM als Domänen-Mitglied, auf der eine spezielle Software läuft.
Dieser Server soll eben auch jederzeit von der Software-Firma erreichbar sein. Ein VPN dafür ist eingerichtet (VPN nur auf die IP-Adresse des Servers mit Port 3389 möglich).
Wer Sicherheit groß schreibt (nicht nur weil es ein Hauptwort ist), dürfte solch ein Konstrukt nicht absegnen. Alleine schon das Konstrukt Domänen Mitglied in Verbindung mit eine VPN Verbindung aus dem Internet, halte ich für gefährlich. Nicht zu vergessen, was die Entwickler da für Löcher in dem Server bohren könnten...Dieser Server soll eben auch jederzeit von der Software-Firma erreichbar sein. Ein VPN dafür ist eingerichtet (VPN nur auf die IP-Adresse des Servers mit Port 3389 möglich).
Wäre es nicht sinnvoller die VM in ein abgeschotteten Bereich (extra VLAN, Trennung durch eine Firewall) abzulegen und durch ein zentrales VPN Gateway in der DMZ den Zugriff erlauben.
Gruß,
Dani
