# ISPConfig3: Templates auch fuer Reseller Kunden



## mattula (2. Jan. 2012)

System: Debian Squeeze mit ISPConfig3 aus dem SVN stable Revision 2834

Wenn ich einen Reseller anlege, hat dieser nicht die Moeglichkeit Templates fuer seine Kunden anzulegen oder zu verwenden.

Bearbeite ich den Reseller per [System/Benutzer bearbeiten] und mache ihn dort zum Typ "admin", dann hat er Zugriff auf die vom admin schon erstellten Tepmlates bzw. kann auch selbst Templates anlegen und seinen Kunden zuweisen.

Ist das der richtige Weg?

Ein Nebeneffekt ist, dass nun bei den Kunden Accounts der "Login as" Button auftaucht. Klickt der Reseller darauf, passiert jedoch nichts.

Gebe ich dem Reseller jedoch das Modul "admin", dann funktioniert der "Login as" button fuer die Kunden des Resellers. Anscheinend ist die Abfrage "Moechten sie sich als ... einloggen?", die nach dem Klick auf den "Login as" Button kommen soll, Bestandteil des Admin Moduls.

Da der Reseller aber das Admin Modul selbst gar nicht haben soll, scheidet diese Variante eigentlich aus.

Oder gibt es auch hier einen Trick / eine Konfiguration, die es erlaubt, das Admin modul fuer admins weiter einzuschraenken?

Oder ist es ein Bug, dass "Login as" nur mit aktiviertem Admin Modiul funktioniert?

Wenn nein, wuerde ich gerne als Feature Request eintueten, dass ein Reseller sich auch als Kunde einloggen koennen sollte, bzw. und vor allem auch Templates fuer seine Kunden benutzen koennen sollte, ohne dafuer gleich admin sein zu muessen.

Gruss,
Matthias


----------



## Till (2. Jan. 2012)

Templates sind zur Zeit nur für den Admin implementiert, das gleiche gilt für die login as Funktion.


----------



## mattula (2. Jan. 2012)

Zitat von Till:


> Templates sind zur Zeit nur für den Admin implementiert, das gleiche gilt für die login as Funktion.


OK, aber ist es im Prinzip OK, den Reseller als Typ: admin zu definieren, um ihm somit Zugang zu den Templates zu ermoeglichen?

Solange er das admin Modul nicht hat, kann er sonst nicht viel anstellen, oder doch?

Dass der "Login as" dann  nicht funktioniert koennte ich in dem Fall als "Schoenheitsfehler" ignorieren.


----------



## Till (2. Jan. 2012)

> OK, aber ist es im Prinzip OK, den Reseller als Typ: admin zu definieren, um ihm somit Zugang zu den Templates zu ermoeglichen?


Das würde ich nicht machen. Beim typ admin werden alle Berechtigungsprüfungen des Systems deaktiviert. Er hat also Zugriff auf alle Daten aller User und Reseller des Servers.



> Dass der "Login as" dann nicht funktioniert koennte ich in dem Fall als "Schoenheitsfehler" ignorieren.


Login as wird in ISPConfig selten benötigt, denn der Reseller hat auch so Zugriff auf alle Daten, als ob er als Kunde eingeloggt wäre. Es ist also nicht so wie bei anderen Controlpanels, wo Du Dich als Kunde einloggen musst bevor Du bestimmte Aktionen ausführen kannst. In ISPConfig hat die jeweisl übergeordnete Administartionsschicht alle Möglichkeiten der untergeordneten Schicht auch, nicht so wie bei Confixx nd anderen panels, wo Du erst den Modus wechseln musst um an bestimmte Optionen ran zu kommen.


----------



## mattula (2. Jan. 2012)

Zitat von Till:


> Das würde ich nicht machen. Beim typ admin werden alle Berechtigungsprüfungen des Systems deaktiviert. Er hat also Zugriff auf alle Daten aller User und Reseller des Servers.


Hm ... wuerdest du es auch dann nicht machen, wenn der Reseller sowieso der einzige Kunde (also Kunde im Sinne von: der Server ist ein Root-Server und soll von einem Kunden als Reselling Plattform benutzt werden) auf dem System ist? 
Mir geht es ja nur darum, dass dieser Kunde (Reseller) in seinem Control Panel lediglich die Dienste sieht und konfigurieren kann, die er benoetigt (also z.B. kein E-Mail und DNS). Es waere auch kein Drama, wenn er es koennte, schliesslich ist es "sein" Server.



Zitat von Till:


> Login as wird in ISPConfig selten benötigt, denn der Reseller hat auch so Zugriff auf alle Daten, als ob er als Kunde eingeloggt wäre.


Das stimmt schon, das Schoene an dem "Login as" finde ich, dass man einfach ueberpruefen kann, ob man dem Kunden alles richtig gesetzt hat, dass er nicht zuviel sieht, etc.
Klar, im End koennte sich der Reseller auch mit den Zugangsdaten des Kunden einloggen, aber das ist halt umstaendlicher und geht erstmal nur solange, wie der Kunde sein Passwort nicht aendert.


----------



## Till (2. Jan. 2012)

> Hm ... wuerdest du es auch dann nicht machen, wenn der Reseller sowieso der einzige Kunde (also Kunde im Sinne von: der Server ist ein Root-Server und soll von einem Kunden als Reselling Plattform benutzt werden) auf dem System ist?
> Mir geht es ja nur darum, dass dieser Kunde (Reseller) in seinem Control Panel lediglich die Dienste sieht und konfigurieren kann, die er benoetigt (also z.B. kein E-Mail und DNS). Es waere auch kein Drama, wenn er es koennte, schliesslich ist es "sein" Server.


Dann kannst Du das machen. Aber wenn es sowieso sein Server ist, dann würde ich ihm doch einfach das ganze Controlpanel als administrator geben.



> Das stimmt schon, das Schoene an dem "Login as" finde ich, dass man einfach ueberpruefen kann, ob man dem Kunden alles richtig gesetzt hat, dass er nicht zuviel sieht, etc.
> Klar, im End koennte sich der Reseller auch mit den Zugangsdaten des Kunden einloggen, aber das ist halt umstaendlicher und geht erstmal nur solange, wie der Kunde sein Passwort nicht aendert.


Login as ist sicherheitstechnisch sehr kritisch, da es bei dem geringsten Fehler ermöglichen würde sich die Rechte anderer user anzueignen. Daher ist die Funktion so implementiert, dass sie nur für den Admin aufrufbar ist und jegliche andere User blockiert.


----------



## mattula (2. Jan. 2012)

Zitat von Till:


> Dann kannst Du das machen. Aber wenn es sowieso sein Server ist, dann würde ich ihm doch einfach das ganze Controlpanel als administrator geben.


Aber dann lassen sich doch die Module wieder nicht so schoen einschraenken, oder?

Er soll eigentlich kein E-mail oder DNS konfigurieren. Er soll auch keine ISPConfig oder System Updates einspielen, usw. Zumindest sollte es durch uns konfigurierbar sein, was er sieht und was nicht. Root-Server war jetzt auch nicht die 100% richtige Beschreibung, es ist eher ein betreuter Root-Server, d.h. fuer Security Updates, Wartung, etc sind wir zustaendig.


Ziel ist quasi eine einigermassen idiotensichere Oberflaeche, die den Zweck des Webhostings und Resellings erfuellt.

Ich hab auch grad noch einen Nebeneffekt entdeckt, wenn der Reseller Typ admin ist: Er sieht alles unlimitiert, egal was in den Limits des Resellers konfiguriert ist.


----------



## Till (2. Jan. 2012)

> Ich hab auch grad noch einen Nebeneffekt entdeckt, wenn der Reseller Typ admin ist: Er sieht alles unlimitiert, egal was in den Limits des Resellers konfiguriert ist.


Richtig. Denn ein user vom Typ admin ist sowas wie der root User unter Linux, es gelten keine Berechtigungen und Limits für ihn.

Aber Du kannst ihm doch ohne weiteres den Admin user selbst geben, denn wenn Du das admin Modul für den admin user Ausschaltetst und dich einmal neu einloggst, kann der Admin auch nicht mehr an den Punkt wo er sich das admin Modul wieder selbst aktivieren kann und wenn Du dem Kunden dann auch nicht das root Passwort für die MySQL DB gibst, dann kann er sich das Admin Modul ja auch nicht ohne weiteres wieder selbst aktivieren, da er sich dazu ja in die ISPConfig MySQL DB einloggen müsste um den Datensatz in der sys_user Tabelle zu ändern.


----------



## mattula (2. Jan. 2012)

Zitat von Till:


> Aber Du kannst ihm doch ohne weiteres den Admin user selbst geben, denn wenn Du das admin Modul für den admin user Ausschaltetst und dich einmal neu einloggst, kann der Admin auch nicht mehr an den Punkt wo er sich das admin Modul wieder selbst aktivieren kann und wenn Du dem Kunden dann auch nicht das root Passwort für die MySQL DB gibst, dann kann er sich das Admin Modul ja auch nicht ohne weiteres wieder selbst aktivieren, da er sich dazu ja in die ISPConfig MySQL DB einloggen müsste um den Datensatz in der sys_user Tabelle zu ändern.


OK, das ist was dran. Zumal die Security in dem Fall nicht so wichtig ist, da er sich ja nur selbst schaden wuerde, wenn er was verhaut.

Ich habe jetzt einfach mal einen Benutzer mit Name "administrator" analog zum "admin" angelegt, mit der Ausnahme, dass er kein Mail, DNS, VM, Admin und Domain Modul aktiviert hat.

Sieht prinzipiell nicht schlecht aus. 
Makel ist nur dergleiche wie beim Reseller mit Admin-Recht: 


In der Kontolimits Liste steht wieder alles unlimitiert drin (auch E-Mail und DNS, obwohl die Module deaktiviert sind)
 Er kann das "login as" nicht benutzen, da er dafuer das admin Modul braeuchte
Also ich glaube schicker und sauberer ist dann doch die Reseller Variante ohne Admin-Rechte. Es sei denn unser Kunde benoetigt tatsaechlich die Moeglichkeit selbst Reseller anzulegen (was bislang kein Thema war).



Und ich bleibe bei meinem Feature Request: Templates fuer alle!


----------



## Till (2. Jan. 2012)

Zitat von mattula:


> Und ich bleibe bei meinem Feature Request: Templates fuer alle!


Ateht doch bereits als feature request im tracker 

FS#1763 : Reseller Templates


----------

