Hello @lebernd,
as you already mentioned, I think the point is this guacamole_default docker bridge. A docker network inspect guacamole_default didn’t show up any Options:
"Options": {
as i.e. the default docker bridge does:
docker network inspect bridge:
"Options": {
"com.docker.network.bridge.default_bridge": "true",
"com.docker.network.bridge.enable_icc": "true",
"com.docker.network.bridge.enable_ip_masquerade": "true",
"com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
"com.docker.network.bridge.name": "docker0",
"com.docker.network.driver.mtu": "1500"
in order to remove an apply them to the default docker bridge i did the following (in this order):
docker network disconnect guacamole_default guacamole_guacamole_1
docker network disconnect guacamole_default guacamole_guacd_1
docker network connect bridge guacamole_guacd_1
docker network connect bridge guacamole_guacamole_1
I never restarted any docker container from the console - for this i always used the web-ui for starting/stopping guacamole app.
I never touched the /etc/hosts file.
What works:
*Logging into Guacamole “Website” using https://ucs-server.domain/guacamole/#/ with any user (or user, member of defined AD-Group) allowed to
*Using defined connections (RDP - Domain Auth / SSH Username/Password-Auth)
What doesn’t work (actually):
*Passthrough/or SSO in Order to use defined connections WITHOUT having to define the credentials inside the ldap object (don’t know if this ever was intended - but would be pretty cool 
)
*Using SSH Connections with Public Key Authentication as there must be some miss-interpretation while reading the private key and/or passphrase from the ldap object (defined there as parameter private-key= and passphrase=)
Grüße und viel Glück 
Debug-Info:
While debugging the initial problem I ended up tcpdumping on the host (ucs domain controller) and another webserver (same subnet as the DC and domain member).
The strange thing was, that even with the “broken” guacamole_default docker network in use, requests have been kind of forwarded/NATed from the host BUT on the destination host the requests shows up comming from the docker container IP (172.17.0.x). tcpdump showed all requests with checksum-errors.
As far as I understand, the requests should have been NATed on the host into the hosts IP-address.
This way no responses from the targeted server were possible, as this server doesn’t even know about the existence of the docker network (172.17.0.0).
This problem was solved (for me) by using the default docker bridge network
I gave up already …
)