Installationsprobleme guacamole

grefabu 2020-04-20 19:18:22 UTC #1

Moin,

auf meinem Testsystem zu Hause habe ich nach der Anleitung: https://github.com/EGroupware/egroupware/wiki/Apache-Guacamole-managed-by-EGroupware Guacamole installiert.

Bei der Angabe des HTTP_HOST habe ich die Hostadresse eingegeben, nicht die Domain. Wo findet sich der Eintrag wieder?

Die mysql Tabelle wurde angelegt, der Admin Eintrag in der Groupware ist vorhanden.

Allerdings klappt der Zugriff noch nicht, da wird Server wurde nicht gefunden gemeldet. Das System läuft überigens noch nicht per TLS abgesichert, da von Außen nicht erreichbar,…

Ich habe in verschiedenen Conf Dateien danach das https herausgenommen, ebenso beim OAuth. Danach wechselt die Fehlermeldung im Browser:

Ein Fehler ist aufgetreten und die gewünschte Aktion kann nicht fortgesetzt werden. Bitte informieren Sie ihren Systemadministrator oder prüfen Sie die Logdateien, falls das Problem bestehen bleiben sollte.

Im log des docker containers wurde ausgegeben, das der Container sich nicht bei der Mysql DB anmelden kann.
Per mysql -h localhost -u guacamole -p geht der Zugriff mit dem generierten Passwort auch nur, wenn ich in der Tabelle user den host von * auf localhost stelle, ebenso muss ich die änderunge in der Tabelle db durchführen.

Die Fehlermeldung im log habe ich weiterhin.

Die Installation von EGroupware war überigens noch recht frisch, direkt mit Docker.

RalfBecker 2020-04-20 19:57:27 UTC #2

Hmm, das soll der HTTP Host Header rein, sprich der vollständige Domainname, wie egw.example.org.

Du kann das jetzt an diversen Stellen umarbeiten und dabei gleich auch mit auf http umstellen, das habe ich in meiner Installation nicht vorgesehen:

Datei /etc/egroupware-guacamole/guacamole-home/guacamole.properties und danach container neu machen
EGroupware: Admin > Anwendungen > OpenID Connect / OAuth Server > Clients: guacamole bearbeiten und die Redirect-URL und die Startseite umstellen

Der Zugriff erfolgt aber nicht von localhost, sprich Unix Domain Socket, sondern per TCP aus dem Guacamole Container, von daher ist ‘%’ beim Hostname richtig.

Hast Du die Sachen die ich unter Troubleshooting geschrieben habe mal nachgeschaut, speziell ob die MariaDB nicht auf 127.0.0.1 gebunden ist, dann geht der Zugriff per TCP aus dem Container natürlich nicht.

Ralf

grefabu 2020-04-20 20:16:56 UTC #3

Schon richtig verstanden, FQDN halt,…

Ist ja auch nicht der Normalfall, nur der Tatsache geschuldet, das ich den Server zum Testen daheim ohne Zugriff von außen aufgesetzt hatte,…

Das neu bauen des Containers habe ich nicht durchgeführt, jetzt bin ich einen Schritt weiter habe noch einen weiteren Fehler, muss noch mal die Configs durchgehen:

guacamole | 20:12:56.470 [http-nio-8080-exec-6] INFO o.a.g.a.o.t.TokenValidationService - Rejected invalid OpenID token: JWT (claims->{“aud”:“guacamole”,“iss”:“https://eg001.rabadanten.de”,“iat”:1587413575,“exp”:1587417175,“sub”:“admin”,“name”:“Admin Strator”,“family_name”:“Strator”,“given_name”:“Admin”,“middle_name”:null,“nickname”:"",“preferred_username”:“admin”,“profile”:"",“picture”:“https://www.gravatar.com/avatar/e4312c58058ef0e96803959b9da10bcd",“website”:null,“gender”:“n/a”,“birthdate”:null,“zoneinfo”:“Europe/Berlin”,“locale”:“de_DE”,“updated_at”:“2020-03-22”,“email”:“admin@rabadanten.de”,“email_verified”:true,“nonce”:"mnp5o4pqjiv6ep2tg3namd0qi9”}) rejected due to invalid claims. Additional details: [Issuer (iss) claim value (https://eg001.rabadanten.de) doesn’t match expected value of http://eg001.rabadanten.de]

Und es wurden jede Menge Tokens generiert, naja, nicht mehr heute Abend.

RalfBecker 2020-04-20 20:35:15 UTC #4

grefabu:

guacamole | 20:12:56.470 [http-nio-8080-exec-6] INFO o.a.g.a.o.t.TokenValidationService - Rejected invalid OpenID token: JWT (claims->{“aud”:“guacamole”,“iss”:“https://eg001.rabadanten.de”,“iat”:1587413575,“exp”:1587417175,“sub”:“admin”,“name”:“Admin Strator”,“family_name”:“Strator”,“given_name”:“Admin”,“middle_name”:null,“nickname”:"",“preferred_username”:“admin”,“profile”:"",“picture”:“https://www.gravatar.com/avatar/e4312c58058ef0e96803959b9da10bcd",“website”:null,“gender”:“n/a”,“birthdate”:null,“zoneinfo”:“Europe/Berlin”,“locale”:“de_DE”,“updated_at”:“2020-03-22”,“email”:“admin@rabadanten.de”,“email_verified”:true,“nonce”:"mnp5o4pqjiv6ep2tg3namd0qi9”}) rejected due to invalid claims. Additional details: [Issuer (iss) claim value (https://eg001.rabadanten.de) doesn’t match expected value of http://eg001.rabadanten.de]

Das hatte ich befürchtet, ist hardcoded auf https, weißt ja nie mehr ohne

github.com

EGroupware/openid/blob/master/src/ResponseTypes/IdTokenResponse.php#L47


	 *
	 * @param AccessTokenEntityInterface $accessToken
	 * @param UserEntityInterface $userEntity
	 * @return Builder
	 */
	protected function getBuilder(AccessTokenEntityInterface $accessToken, UserEntityInterface $userEntity)
	{
		// Add required id_token claims
		$builder = (new Builder())
			->setAudience($accessToken->getClient()->getIdentifier())
			->setIssuer('https://' . Http::host())
			->setIssuedAt(time())
			->setExpiration($accessToken->getExpiryDateTime()->getTimestamp())
			->setSubject($userEntity->getIdentifier());


		return $builder;
	}


	/**
	 * Reimplemented to:
	 * - make it public, to add id_token responses for implicit grant

War schon in der jetzt überschriebenen Methode so, kann ich aber umbauen:

Ralf

grefabu 2020-04-21 07:03:37 UTC #5

Gut, ist ja bis jetzt nur das Testsystem. Ich muss halt mal ein selbssigniertes Cert nehmen oder schaeuen, das ich über Let’s Encrypt auch für die Kiste ein Zertifikat generiere. Den Zugriff auf Port 80 und 443 von außen benötige ich ja nur temporär für die Erstellung des Zerts,…

Wir werden aber zeitnah guacamole hier in der Firma aufsetzen. Da haben wir natürlich TLS,…

RalfBecker 2020-04-21 07:51:05 UTC #6

Ich gehe ja mal davon aus, das Du Kontrolle über Deine Domain, sprich Dein DNS hast.

Dann kannst du z.B. mit dem Lego Komandozeilen Client ganz einfach beliebige Zertifikate für Deine Domain ausstellen. Das mache ich inzwischen für unsere Domains im Hosting und die Entwicklersysteme.

https://go-acme.github.io/lego/usage/cli/

Wenn Dein DNS Provider nicht von Lego direkt unterstützt ist, wie bei uns zum Beispiel, kannst Du einfach einen CNAME auf einen unterstützten bei dem Du einen Account hast machen und dort eine Subdomain hin delegieren. Wir machen das z.B. mit Amazon Route53, die Liste der unterstützten ist lang.

Ralf

grefabu 2020-04-21 07:55:39 UTC #7

Lego kannte ich eigentlich nur im anderen Zusammenhang, ich war bis jetzt mit dem acme.sh Script oder dem certbot unterwegs. Da mein provider aber keine DNS API anbietet, habe ich das erst mal nicht weiterverfolgt.

Das mit dem CNAME klingt nach einer Alternative,…

RalfBecker 2020-04-21 08:12:09 UTC #8

Das ist was ich für mein Entwicklungssystem verwende:

#!/bin/bash

cd $(dirname $0)

LEGO_EXPERIMENTAL_CNAME_SUPPORT=true \
AWS_HOSTED_ZONE_ID=*** \
AWS_ACCESS_KEY_ID=*** \
AWS_SECRET_ACCESS_KEY=*** \
lego    --domains boulder.egroupware.org \
        --key-type rsa2048 \
        --email rb@egroupware.org --path . --dns route53 run && \
cat certificates/boulder.egroupware.org.{key,crt} > certificates/boulder.egroupware.org.pem

Und das der relevante CNAME:

dig +short _acme-challenge.boulder.egroupware.org
_acme-challenge.farm.egroupware.org.

Ralf

grefabu 2020-04-21 08:23:15 UTC #9

Macht immer mal wieder sinn sich mit dem Thema zu beschäftigen, acme.sh bietet auch einen Alias Mode:

grefabu 2020-04-21 09:47:24 UTC #10

Noch eine kleine Anmerkung: Nach der Initialen Installation ist Guacamole ohne Neustart des EGroupware Containers nicht in EGroupware verfügbar?:

Die OpenID wurde aber angelegt:

Oder muss ich erst ins /setup ?

EDIT: Im setup ist guacamole auch vorhanden:

RalfBecker 2020-04-21 10:11:41 UTC #11

In der aktuellen Version des Pakets bekommt die Admin Gruppe noch nicht automatisch Rechte für die Guacamole Anwendung, sondern nur die Default Gruppe. Das habe ich inzwischen geändert, da viele Instanzen die Default Gruppe umbenennen oder leer lassen.

Einfacher Workaround, Admin Gruppe auch Ausführungsrechte für Gucamole geben und neu anmelden.

Ralf

grefabu 2020-04-21 10:14:17 UTC #12

Das dachte ich auch, aber auch in der Rechte Tabelle ist guacamole nicht enthalten:

Auf meinem Testsystem musste ich IMHO egroupware (oder den ganzen Host) neu starten, werde ich gleich noch mal machen,…

RalfBecker 2020-04-21 10:29:19 UTC #13

Und die guacamole_* Tabellen und Views sind angelegt worden, bzw. Setup zeigt Guacamole als installiert?

Evtl. haben wir da noch ein Caching Problem …

Ralf

grefabu 2020-04-21 10:37:36 UTC #14

Nach dem Neustart des egroupware-docker containers habe ich guacamole jetzt Verfügbar, du must aber in Deinem Script noch einen Fehler haben:

Ich wusste doch, das der Asterisk nicht auf meinem Mist gewachsen ist

grefabu 2020-04-21 10:40:24 UTC #15

Jetzt läuft es bei uns (mein Testsystem lasse ich mal außen vor)

RalfBecker 2020-04-21 11:34:02 UTC #16

Ok, dachte ich hätte den * schon durch ein % ersetzt gehabt, kommt mit dem nächsten Paket.

Ralf