Verwaltung von Berechtigungen mit OTRS

Hilfe zu OTRS Problemen aller Art
Post Reply
tomS
Znuny newbie
Posts: 28
Joined: 08 Dec 2018, 11:43
Znuny Version: 6 Patch Level18
Real Name: Thomas Schachtner
Company: privat

Verwaltung von Berechtigungen mit OTRS

Post by tomS »

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
wurzel
Znuny guru
Posts: 3232
Joined: 08 Jul 2010, 22:25
Znuny Version: x.x.x
Real Name: Florian

Re: Verwaltung von Berechtigungen mit OTRS

Post by wurzel »

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).
Ich könnte sämtliche Gruppen und relevante Verzeichnisse als CIs in der CMDB anlegen und mit entsprechenden Tickets verknüpfen.
korrekt. Ist in der ((OTRS)) Community Edition machbar, aber umständlich.

Allerdings fehlt dann der Zusammenhang zu den jeweiligen Benutzern...
Wie geht man an dieses Thema ran?
Du hast ja immer ein Ticket dazu, dann hast Du auch den Benutzer.
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:
Macht es Sinn, auch alle Benutzer als CIs zu erfassen?
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.
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?
Dann heisst es lernen, Schulungen, selber testen, ausprobieren. Change Management ist nicht trivial.
Ob es so "gedacht" ist Benutzer als CI zu verwalten? Ich vermute nicht. Wenn es Deine Bedürfnissen am Besten abdeckt? Spricht nichts dagegen.
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?
siehe meinen Weg oben. Change Management etablieren, Ergebnisse sauber dokumentieren, RequestForChanges sauber dokumentieren. Ich würde das über Tickets machen.

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.
Post Reply