Hallo zusammen,
ich bin gerade dabei, ein System zur Verwaltung ungefähr Genehmigung von Zugriffsberechtigungen auf Verzeichnisse bzw. Mitgliedschaften zu Gruppen zu erstellen.
Hat jemand bereits Erfahrung damit?
Ich kenne da jetzt keine spezielle Software, sondern hätte mir überlegt, OTRS dafür einzusetzen.
Ich könnte sämtliche Gruppen und relevante Verzeichnisse als CIs in der CMDB anlegen und mit entsprechenden Tickets verknüpfen.
Allerdings fehlt dann der Zusammenhang zu den jeweiligen Benutzern...
Wie geht man an dieses Thema ran?
Macht es Sinn, auch alle Benutzer als CIs zu erfassen?
Ich hab da grad zu wenig Überblick über das System bzw. die "Denke" dahinter...
Oder ist es so nicht gedacht, auch Benutzer als CIs zu verwalten?
Ich möchte halt sehen können:
Wer hat auf Ressource A Zugriff bekommen?
Auf welche Ressourcen hat Benutzer xy Zugriff?
Ich hätte mir im einfachsten Fall gedacht, dass zu einem entsprechenden Ticket dann die jeweiligen CIs verknüpft werden...
Ist das so ein gangbarer Weg oder gibt's da bessere Lösungen?
Viele Grüße
Tom
Verwaltung von Berechtigungen mit OTRS
Re: Verwaltung von Berechtigungen mit OTRS
Hi,
das ist klassches "Change Management" + Dokumentation. Ich würde das ohne CMDB machen.
Ich würde nur dynamische Felder dafür verwenden und einen (oder mehrere) Prozess bauen.
Hätte ich zusätzliche Features, vielleicht auch mit der CMDB.
Ich habe z.B. einen Change Prozess, in dem ich alle Änderungen eintrage. Ich sehe über eine Auswertung immer die Zustände
ob der Change beantragt, genehmigt, abgelehnt, fehlgeschlagen oder erfolgreich oder sostwas ist/war.
Sowie alle Ursachen, Fehler, Ergebnisse.
Ich kann also relativ schnell auch sagen: System x hat zum Zeitpunkt y die Änderung z erhalten.
wobei x ein System, ein User oder auch eine Software/Lizenz sein kann.
Somit sehe ich auch zum Zeitpunkt z das Ergebnis aller Änderungen der letzten Jahre.
Das ist nicht einfach, ich bin da gut 4 Wochen (vermutlich viel länger) drangesessen. Und optimiere eigentlich immer noch, und das seit zwei Jahren.
Für meine Bedürfnisse passts. Aber ob das der Beste Weg ist? Ich sage ja. Für mich schon.
Es gibt sicher andere/einfachere/bessere Wege (auch mit der CMDB).
Aber ja, den Benutzer da mit reinzukriegen an das CI, so dass Du da eine Übersicht bekommst, ist ohne Tickets nicht möglich, oder Du brauchst (kommerzielle) Features für die CMDB:
Ob es so "gedacht" ist Benutzer als CI zu verwalten? Ich vermute nicht. Wenn es Deine Bedürfnissen am Besten abdeckt? Spricht nichts dagegen.
viele Grüße
Flo
das ist klassches "Change Management" + Dokumentation. Ich würde das ohne CMDB machen.
Ich würde nur dynamische Felder dafür verwenden und einen (oder mehrere) Prozess bauen.
Hätte ich zusätzliche Features, vielleicht auch mit der CMDB.
Ich habe z.B. einen Change Prozess, in dem ich alle Änderungen eintrage. Ich sehe über eine Auswertung immer die Zustände
ob der Change beantragt, genehmigt, abgelehnt, fehlgeschlagen oder erfolgreich oder sostwas ist/war.
Sowie alle Ursachen, Fehler, Ergebnisse.
Ich kann also relativ schnell auch sagen: System x hat zum Zeitpunkt y die Änderung z erhalten.
wobei x ein System, ein User oder auch eine Software/Lizenz sein kann.
Somit sehe ich auch zum Zeitpunkt z das Ergebnis aller Änderungen der letzten Jahre.
Das ist nicht einfach, ich bin da gut 4 Wochen (vermutlich viel länger) drangesessen. Und optimiere eigentlich immer noch, und das seit zwei Jahren.
Für meine Bedürfnisse passts. Aber ob das der Beste Weg ist? Ich sage ja. Für mich schon.
Es gibt sicher andere/einfachere/bessere Wege (auch mit der CMDB).
korrekt. Ist in der ((OTRS)) Community Edition machbar, aber umständlich.Ich könnte sämtliche Gruppen und relevante Verzeichnisse als CIs in der CMDB anlegen und mit entsprechenden Tickets verknüpfen.
Du hast ja immer ein Ticket dazu, dann hast Du auch den Benutzer.Allerdings fehlt dann der Zusammenhang zu den jeweiligen Benutzern...
Wie geht man an dieses Thema ran?
Aber ja, den Benutzer da mit reinzukriegen an das CI, so dass Du da eine Übersicht bekommst, ist ohne Tickets nicht möglich, oder Du brauchst (kommerzielle) Features für die CMDB:
Ich kenne ein paar Systeme, manche haben die Benuter als CI erfasst. Ich fand die Lösung interessant, aber Du hast halt Redundanzen weil Du die Kundendaten in der Regel in einem LDAP/CRM/... hast. Ich würde den Benutzer nicht als CI erfassen.Macht es Sinn, auch alle Benutzer als CIs zu erfassen?
Dann heisst es lernen, Schulungen, selber testen, ausprobieren. Change Management ist nicht trivial.Ich hab da grad zu wenig Überblick über das System bzw. die "Denke" dahinter...
Oder ist es so nicht gedacht, auch Benutzer als CIs zu verwalten?
Ob es so "gedacht" ist Benutzer als CI zu verwalten? Ich vermute nicht. Wenn es Deine Bedürfnissen am Besten abdeckt? Spricht nichts dagegen.
siehe meinen Weg oben. Change Management etablieren, Ergebnisse sauber dokumentieren, RequestForChanges sauber dokumentieren. Ich würde das über Tickets machen.Ich möchte halt sehen können:
Wer hat auf Ressource A Zugriff bekommen?
Auf welche Ressourcen hat Benutzer xy Zugriff?
Ich hätte mir im einfachsten Fall gedacht, dass zu einem entsprechenden Ticket dann die jeweiligen CIs verknüpft werden...
Ist das so ein gangbarer Weg oder gibt's da bessere Lösungen?
viele Grüße
Flo
OTRS 8 SILVER (Prod)
OTRS 8 auf Debian 11 (Test)
Znuny 7.x latest version testing auf Debian 11
-- Ich beantworte keine Forums-Fragen PN - No PN please
I won't answer to unfriendly users any more. A greeting and regards are just polite.
OTRS 8 auf Debian 11 (Test)
Znuny 7.x latest version testing auf Debian 11
-- Ich beantworte keine Forums-Fragen PN - No PN please
I won't answer to unfriendly users any more. A greeting and regards are just polite.