6
Visual Studio 2017 ohne lokale Adminrechte
Hallo zusammen,
ich werde vor der Herausforderung gestellt eine AD in einem Unternehmen einzuführen, welches in den letzten Jahren in der Softwareentwicklung rapide gewachsen ist; ohne großartige Netzwerkstrukturen.
Da es sich wie gesagt um eine Softwareschmiede handelt, arbeiten viele Leute hier mit Visual Studio. Wenn die AD steht und die Mitarbeiter dieser joinen, werden lokale Adminrechte der Vergangenheit angehören. Mich würde interessieren ob ich meine Softwareentwickler, die alle mit Visual Studio 2017 arbeiten (falls noch jemand mit einer älteren Version arbeiten sollte wird er hoch gezogen, hier sehe ich kein Problem), in ihrer Arbeit eingeschränkt werden wenn ich ihnen die lokalen Adminrechte nehme.
Ich habe natürlich schon viel recherchiert und auch Kollegen gefragt, aber wer will sich schon gerne freiwillig die lokalen Adminrechte nehmen lassen. Also ist die Antwort meist "ja, brauche ich".
Was habt ihr da für Erfahrungen sammeln können?
Läuft Visual Studio 2017 in einer AD ohne lokale Adminrechte produktiv?
Falls nicht, habt ihr ein Workaround dafür gefunden?
Mir würde im schlimmsten Fall nur ein dafür angelegter Benutzer der Adminrechte verfügt einfallen, der über die Verknüpfung von Visual Studio hinterlegt ist und dieses als Admin öffnet. Den User könnte ich noch etwas kastrieren, eine sichere Lösung bleibt es trotzdem nicht..
Ich freue mich auf eure Resonanz!
ich werde vor der Herausforderung gestellt eine AD in einem Unternehmen einzuführen, welches in den letzten Jahren in der Softwareentwicklung rapide gewachsen ist; ohne großartige Netzwerkstrukturen.
Da es sich wie gesagt um eine Softwareschmiede handelt, arbeiten viele Leute hier mit Visual Studio. Wenn die AD steht und die Mitarbeiter dieser joinen, werden lokale Adminrechte der Vergangenheit angehören. Mich würde interessieren ob ich meine Softwareentwickler, die alle mit Visual Studio 2017 arbeiten (falls noch jemand mit einer älteren Version arbeiten sollte wird er hoch gezogen, hier sehe ich kein Problem), in ihrer Arbeit eingeschränkt werden wenn ich ihnen die lokalen Adminrechte nehme.
Ich habe natürlich schon viel recherchiert und auch Kollegen gefragt, aber wer will sich schon gerne freiwillig die lokalen Adminrechte nehmen lassen. Also ist die Antwort meist "ja, brauche ich".
Was habt ihr da für Erfahrungen sammeln können?
Läuft Visual Studio 2017 in einer AD ohne lokale Adminrechte produktiv?
Falls nicht, habt ihr ein Workaround dafür gefunden?
Mir würde im schlimmsten Fall nur ein dafür angelegter Benutzer der Adminrechte verfügt einfallen, der über die Verknüpfung von Visual Studio hinterlegt ist und dieses als Admin öffnet. Den User könnte ich noch etwas kastrieren, eine sichere Lösung bleibt es trotzdem nicht..
Ich freue mich auf eure Resonanz!
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: 347098
Url: https://administrator.de/contentid/347098
Ausgedruckt am: 22.11.2024 um 12:11 Uhr
6 Kommentare
Neuester Kommentar
Moin,
ich verstehe zwei Dinge nicht:
1. Wie kommst du darauf, das ein AD per se Einfluss auf Visual-Studio hat?
2. Wie kommst du darauf, das man zum Entwickeln Admin-Rechte braucht?
Gruß
ich verstehe zwei Dinge nicht:
1. Wie kommst du darauf, das ein AD per se Einfluss auf Visual-Studio hat?
2. Wie kommst du darauf, das man zum Entwickeln Admin-Rechte braucht?
Gruß
Hi!
Zu 1: Ein sicheres Netzwerk bzw. ein vernünftiges Sicherheitskonzept sieht vor, dass normale Anwender auch als solche arbeiten, sprich sie haben keine lokalen Adminrechte mehr. Dass ein AD per se Einfluss auf Visual Studio hat sollte mein Aufruf nicht ausdrücken, falls das so rüber kam, entschuldige dafür.
Zu 2: Ich bin kein Entwickler, deshalb der Aufruf. Hier wird es vermutlich einige Entwickler geben die mit VS in einer AD ohne lokale Adminrechte arbeiten.
Zu 1: Ein sicheres Netzwerk bzw. ein vernünftiges Sicherheitskonzept sieht vor, dass normale Anwender auch als solche arbeiten, sprich sie haben keine lokalen Adminrechte mehr. Dass ein AD per se Einfluss auf Visual Studio hat sollte mein Aufruf nicht ausdrücken, falls das so rüber kam, entschuldige dafür.
Zu 2: Ich bin kein Entwickler, deshalb der Aufruf. Hier wird es vermutlich einige Entwickler geben die mit VS in einer AD ohne lokale Adminrechte arbeiten.
2. Wie kommst du darauf, das man zum Entwickeln Admin-Rechte braucht?
Zumindest die Entwickler die Setups und Programme Schreiben die Admin-Rechte vom Anwender beim Testen einfordern 
.Das sollte man dann aber, wie die meisten Entwickler es sowieso machen, in einer VM abfackeln, wo sie schalten und walten können wie sie wollen.
Beim ändern von Systemeinstellungen für Tests, z.B. von COM-Parametern etc. wird es dann aber trotzdem haarig, wenn sich bestimmte Dinge nicht in eine VM auslagern lassen. Das wird man evaluieren müssen was an Entwicklung stattfindet.
Gruß
Was hindert dann den Programmierer seine Kiste nur in der AD anzumelden und alles was er sonst so tun und lassen will in einer VM erledigt?
Somit wird diese "Lücke" für den User der sich von mir "beschnitten" fühlt nur attraktiver..
Somit wird diese "Lücke" für den User der sich von mir "beschnitten" fühlt nur attraktiver..
Zitat von @Pakko0:
Was hindert dann den Programmierer seine Kiste nur in der AD anzumelden und alles was er sonst so tun und lassen will in einer VM erledigt?
Nichts, so lange die VM-Host für Ihn als Otto Normalo von dir für Ihn installiert wurde.Was hindert dann den Programmierer seine Kiste nur in der AD anzumelden und alles was er sonst so tun und lassen will in einer VM erledigt?
Somit wird diese "Lücke" für den User der sich von mir "beschnitten" fühlt nur attraktiver..
Wieso Lücke, der Gast der VM muss ja nicht im AD sein und muss auch keinen Netzzugang haben, je nachdem was halt entwickelt wird.Entwickler sind bei uns in einem speziell abgeschotteten Bereich des Netzes, und wenn sie mal was an Ihren Kiste mit lokalen Adminrechten verbasteln, kommt halt schnell das Image wieder drauf, feddich. Ich seh da kein Problem.
Der Ansatz gefällt mir. Den Entwicklern per GPO Hyper-V aktivieren, Netzwerkadapter in allen Hyper-V Maschinen nur intern kommunizieren lassen, dann sollte sich der Spaßfaktor in Grenzen halten..
