Regelung in der EULA

Der tenfold-Endbenutzerlizenzvertrag (EULA) sieht vor, dass alle physischen, aktiven IT-Benutzer, die mit tenfold verwaltet werden sollen, lizenziert werden müssen. Diese Lizenzierungsrichtlinie findet – strenggenommen – unabhängig von Active Directory Anwendung, auch, wenn die Lizenzierung in den meisten Fällen auf Active Directory beruht, da hier oftmals jeder Mitarbeiter verwaltet wird.
Beispiel für eine Ausnahme: Der Werksmitarbeiter ist am Client über einen dauerhaft angemeldeten Sammelbenutzer angemeldet. Der Werksmitarbeiter startet anschließend die SAP-GUI und meldet sich mit einem personalisierten SAP-Benutzer an, der über tenfold verwaltetet wird. Der Werksmitarbeiter ist zu lizenzieren, auch wenn er kein AD-Konto hat.
Nicht unter die Lizenzierungspflicht fallen alle Benutzerkonten, die entweder deaktiviert sind, oder nicht einer Person zuzuordnen sind (Systembenutzer, Dienstkonten).

Melden Sie sich zu unserem Webinar an!

“Top 5 Gefahren im Access Management” –
mit Helmut Semmelmayer, tenfold Software GmbH

Jetzt kostenlos anmelden

Melden Sie sich auch zu unserem Webinar an!

“Top 5 Gefahren im Access Management” –
mit Helmut Semmelmayer, tenfold Software GmbH

Jetzt kostenlos anmelden

Teilweise Lizenzierung des Active Directory

Relativ häufig tritt die Frage auf, ob tenfold grundsätzlich immer für die gesamte Active Directory-Landschaft lizenziert werden muss. Die Antwort hierauf lautet grundsätzlich: Nein – aber eben nur „grundsätzlich“.

Technisch ist es möglich, nicht alle Objekte aus der Active Directory-Umgebung über tenfold zu verwalten:

  • Es kann der Scope innerhalb einer Domain auf bestimmte Organisationseinheiten (OUs) beschränkt werden.
  • In einer Multi-Domain-Umgebung ist es möglich, nicht alle Domains mit tenfold zu verbinden und so bestimmte Domains von der Verwaltung gänzlich auszuschließen

Ob dies jedoch sinnvoll, und gegebenenfalls sogar gefährlich ist, muss im Einzelfall bewertet werden.

Konsequenzen bei teilweiser Lizenzierung

Das trägt allerdings Konsequenzen mit sich. Objekte (Benutzer, Gruppen und Computer) die sich in Bereichen (OUs oder Domains) befinden, die von tenfold nicht verwaltet werden, werden in tenfold auch nicht eingelesen und sind tenfold daher auch nicht bekannt.
Wenn nunmehr diese Objekte in anderen – in tenfold bekannten – Objekten (Benutzer, Gruppen, Computer, Fileserver, Exchange oder SharePoint) verwendet werden, so scheinen bei deren Verwaltung die in tenfold nicht bekannten Objekte nicht auf.
Beispiel: Eine Gruppe „g-citrix-excel“ aus einer in tenfold gescannten OU hat ein Gruppenmitglied „mschwarz“ aus einer in tenfold nicht lizenzierten und daher nicht eingescannten OU. Bei der Betrachtung der Gruppe „g-citrix-excel“ wird der Benutzer „mschwarz“ nicht angezeigt, da er in tenfold nicht aufgelöst werden kann.
Beispiel: Ein Benutzer „kmayer“ aus einer nicht eingescannten OU hat Berechtigungen auf einem Verzeichnis, das von tenfold verwaltet wird. tenfold liest das Verzeichnis beim Scan aus, aber kann die Benutzerkennung (SID; Security Identifier) hinter der Berechtigung nicht auflösen, da der zugehörige Benutzer nicht bekannt ist. Der Benutzer scheint auf dem Bericht für das Verzeichnis nicht auf.

Zusammenfassung

Eines der Hauptziele von tenfold ist es, dem Anwender zuverlässige und übersichtliche Auswertungen zu den eingestellten Berechtigungen zu geben.
Wie anhand der Beispiele erkennbar ist, führt eine nicht vollständige Lizenzierung von tenfold zu erheblichen Problemen hinsichtlich der Zuverlässigkeit und Authentizität von Reports.
Es ist daher zusammenfassend technisch zwar möglich, aber nicht empfehlenswert, tenfold in Umgebungen einzusetzen, in denen es nicht beabsichtigt ist, alle Bereiche der AD-Infrastruktur zu lizenzieren.

Hinweis: Änderungen im Lizenzvertrag sind selbstverständlich vorbehalten. Diese unverbindliche Richtlinie zur tenfold-Lizenzierung ist nicht Bestandteil bestehender oder zukünftiger Lizenzverträge.