phatair 39 Geschrieben 14. Juni Melden Teilen Geschrieben 14. Juni Hallo zusammen, wir setzen bei uns Docusnap zum Inventarisieren und Dokumentieren der IT Landschaft ein bzw. sind dabei es noch weiter zu implementieren. Aktuell ist es so, dass die Inventarisierung der AD, DHCP, Server, Exchange, Veeam, SQL usw. über den Docusnap Server laufen. Das heißt dort ist ein Service Account hinterlegt der dann zusätzlich auf allen zu inventarisierenden Servern lokaler Admin ist. Diese lokalen Adminrechte werden laut Docusnap oft einfach benötigt. Dort wo es nicht notwendig ist, sind die Rechte granular vergeben. -> gefällt mir aktuell nicht so gut, da ein einzelner Service Account doch sehr weitreichende Berechtigungen auf mehreren Servern hat. Nun gibt es auch die Möglichkeit die Inventarisierung über ein Script laufen zu lassen, dass wird dann lokal auf dem jeweiligen Server ausgeführt und das Ergebnis (eine XML Datei) wird dann auf einen Share abgelegt und vom Docusnap Server eingelesen. -> würde mir besser gefallen. Ich würde für jeden Server einen eigenen AD Service Account erstellen. Dieser wird mit unserer bestehenden GPO dann in die lokale Admin Gruppe des jeweiligen Servers mit aufgenommen. Somit könnte ein Scheduled Task auf jedem Server laufen, der mit dem jeweiligen Service Account ausgeführt wird und die XML Datei erstellt und im Share ablegt. Vorteil wäre, ich habe nicht mehr einen Account der auf mehreren Servern gleichzeitig lokaler Admin ist. Wie würdet ihr das sehen? Macht der Aufwand Sinn oder macht der Aufwand wenig Sinn, wenn man grundsätzlich kein Tiering Modell oder ähnliches nutzt? Ich kann natürlich nicht unser komplettes Sicherheitskonzept hier erklären und mir ist auch klar das ihr deswegen keine 100% Aussage treffen könnt, aber mich würde mal interessieren ob der grundsätzliche Denkansatz in die richtige Richtung geht oder ob ich mich hier im "Klein Klein" verliere. Grobe Info zu unserem Sicherheitskonzept der Admin Accounts - Niemand hat zusätzliche Domänen Admin Rechte und der default DA ist deaktiviert und hat auch auf Member Server / Clients kein Zugriff - die bestehenden DA Accounts werden nur für die Tätigkeiten in der AD genutzt, wozu DA Rechte notwendig sind - für die IT gibt es getrennte Client und Server Admins und die Anmeldung ist an den jeweils anderen System unterbunden - kein "normaler User" hat Adminrechte oder einen Admin Account - Default Admin auf den Servern ist deaktiviert und jeder Server hat einen eigenen lokalen Admin mit unterschiedlichen Kennwort - Es gibt fast keine Service Sammelaccounts mehr, jeder Service Account wird einer Aufgabe zugeordnet und danach benannt - LAPS leider noch nicht aktiv Vielen Dank. Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 14. Juni Melden Teilen Geschrieben 14. Juni Die Berechtigungen der Docusnap Accounts kann man anpassen, dann brauchen die keine Admin Berechtigungen mehr. Dazu kann ich am Montag vom Arbeitsplatz aus etwas schreiben, dort hab ich die Details dazu. 1 Zitieren Link zu diesem Kommentar
phatair 39 Geschrieben 14. Juni Autor Melden Teilen Geschrieben 14. Juni Hi sunny61, das wäre ja wundervoll. Ich hatte nur diese whitepaper bei docusnap selber gefunden. Dort werden die notwendigen Berechtigungen für die Inventarisierung aufgelistet. https://media.docusnap.com/media/doc/howto/Docusnap_Whitepaper_Docusnap-Inventarisierung.pdf Dort ist z.b. bei der windows Inventarisierung erwähnt das es lokale Admin Rechte braucht. Bei exchange oder dhcp wird sogar von Domänen Amin Rechten gesprochen. Bei uns läuft aktuell der Docusnap Server Dienst mit einem AD Service Account der entweder lokale Admin auf den entsprechenden Servern ist. Wenn ich das, wie du schreibst anpassen kann, wäre das eine weitere Lösung. Vielen Dank und ein schönes Wochenende Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 14. Juni Melden Teilen Geschrieben 14. Juni Bei Docusnap hat mein früherer Kollege nichts dazu gefunden, ich such das am Anfang der Woche mal zusammen, falls ich bis Dienstag nichts geschrieben habe, meld dich einfach nochmal hier im Thread. ;) Die Variante mit dem Script verwenden wir tatsächlich nur für Geräte die sehr sehr selten an oder im Netz sind. 1 Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 18. Juni Melden Teilen Geschrieben 18. Juni (bearbeitet) Auf die Schnelle hab ich noch das hier gefunden: https://martellotech.com/blog/enable-remote-wmi-access-for-a-domain-user-account/ Und noch eine URL für ein Script: https://docs.microsoft.com/de-de/archive/blogs/spatdsg/set-wmi-namespace-security-via-gpo-script Das schon gen. Script brauchst Du doppelt, einmal für die DCs und einmal für die Member Server. Deinen User am besten in eine Gruppe, und die Gruppe anstatt dem User verwenden. Auf einem Member Server wmimgmt.msc als Admin starten > WMI-Kontrolle > Eigenschaften >Reiter Sicherheit > Root markieren > Sicherheit unten anklicken > Erweitert anklicken > über Hinzufügen die Gruppe hinzufügen und diese Berechtigungen vergeben. Ebenfalls auf diesen und untergeordneten Namespaces anwenden. Jetzt in einer Admin Commandline diesen Befehl ausführen: wmic /namespace:\\root /output:c:\sd.txt path __systemsecurity call getSD In der auf c:\ erstellten sd.txt findet sich ein langer String: {1, 0, 4, 129, 148, 0, 0, 0, 164, 0, 0, 0, 0, 0, 0, 0, 20, 0, 0, 0 und so weiter und so fort. Diesen String von den Leerzeichen befreien und ohne die Leerzeichen in die passende VBS-Datei kopieren und die Datei speichern. Die gleiche Vorgehensweise muss auf einem DC durchgeführt werden, jetzt hast Du 2 VB-Scripte, eins für die DCs und eins für die Member Server. Die beiden Scripte kannst Du in ein Share legen und als Computerstartupscript von den Servern ausführen lassen. DCs und Member separat natürlich. Bevor es weiter geht, noch auf einen anderen Server switchen, als Admin eine Commandline öffnen und die VBS-Datei für Server ausführen: cxcript.exe c:\Pfad-zur-WMI_Server.vbs Kontrolle: Jetzt auf dem Server wmimgmt.msc als Admin ausführen und die o.g. Schritte ausführen. Ist dort die Gruppe mit den passenden Berechtigungen zu sehen? Wenn ja, dann kann das Script verwendet werden. Nach Möglichkeit auch mit dem DC-Script so verfahren. Ein GPO für DCs und ein GPO für Memberserver erstellen. Beispielhaft die Vorgehensweise für Member Server: Sicherheitseinstellungen > Lokale Richtlinien > Sicherheitsoptionen > DCOM: Computerstarteinschränkungen und Computerzugriffseinschränkungen jeweils über Sicherheit bearbeiten die Gruppe hinzufügen. Die Gruppe braucht an der Stelle alle Rechte: Lokaler Start, Remotestart, Lokale Aktivierung und Remoteaktivierung. Mit OK alles bestätigen. Jetzt noch in die eingeschränkten Gruppen, dort über den Durchsuchen Dialog die Gruppen Leistungsüberwachtungsbenutzer und Remoteverwaltungsbenutzer hinzufügen. In jede der beiden Gruppen kommt deine Gruppe als Mitglied rein. Windows Firewall Regel für WMI nicht vergessen. Ich hoffe nichts vergessen zu haben, einfach mal den ersten Teil mit dem manuellen ausprobieren, wenn das klappt, sollte es mit dem GPO auch klappen. bearbeitet 18. Juni von Sunny61 3 Zitieren Link zu diesem Kommentar
phatair 39 Geschrieben 19. Juni Autor Melden Teilen Geschrieben 19. Juni Hi sunny, Vielen Dank für die ausführlichen Infos und die Mühe das zusammenzutragen!! Ich bin auch etwas blöde und hab den Wald vor lauter Bäumen nicht gesehen. Ich habe für das PRTG monitoring schon eine Gruppe für die wmi/dcom Berechtigung erstellt und diese dann immer manuell für wmi berechtigt, damit wir dafür keine Admin Berechtigung benötigt wird. Die Infos helfen mir aber noch um das zu automatisieren und um das Ganze noch besser zu verstehen. Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 19. Juni Melden Teilen Geschrieben 19. Juni Ja, für PRTG haben wir das auch so umgesetzt. Vor allem die Automatisierung mit dem Script ist praktisch. ;) Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.