Univention Bugzilla – Bug 44524
hardcoded FQDN in univention-proxy.conf site prohibits access in DMZ
Last modified: 2017-08-18 16:18:01 CEST
The ucr template for /etc/apache2/sites-available/univention-proxy.conf defines the FQDN for the server based on $hostname and $domainnane. In many use cases both are valid only for an internal network (like "server.domain.local"). A typical scenario for the Univention Portal is to allow access to web based applications from the internet. This is typically done by a UCS system in a DMZ with external access by port forwardings or reverse proxies. As the univention-proxy.conf apache site redirects all requests to the internal FQDN external access is impossible. Currently there is no way to configure the FQDN.
Sounds like Bug #44124.
Since Bug #44124 the FQDN of univention-proxy.conf is only(!) used for redirections when accessing path's of ucs-sso.$domainname which don't belong to simplesamlphp. This affects therefore only the login process but has nothing to do with the portal or regular UMC use. I cannot reproduce any problems regarding this. I configured a reverse proxy as well as port forwarding via ssh (ssh -L 0.0.0.0:91:xen3:80 xen3 && firefox http://localhost:91/).
@Ingo, to me, this sounds like Bug 44371? But then the problem is not really related to the proxy, but more generic in its nature.
(In reply to Alexander Kläser from comment #3) > @Ingo, to me, this sounds like Bug 44371? But then the problem is not really > related to the proxy, but more generic in its nature. No, this is not about the links on the portal (I didn't even get to that point in my setup). I have to re-test based on Florians feedback, but I suspect a difference in the use case. A typical network has several internal servers and only one external IP. The external IP has to be used to exposed several internally hosted services, typically based on a reverse proxy. Let's say we have three internal hosts: * host A: webmail/groupware * host B: SAML / SSO * host C: Univention Portal, etherpad, dudle So a reverse proxy needs to offer all these services, for example: * /portal -> <Host C>/univention/portal * /sso -> <Host B>/univention/login * /dudle -> <Host C>/dudle * ... In my tests this failed, both for the portal itself and for SAML.
@Ingo: We released the errata updates yesterday. Can you please check if this error still happens on your machine. If it does, let's have a look together.
The main issue in my setup was the fact that I tried to use an UCS instance to be both the apache reverse proxy for the portal running on an internal server and other UCS apps. Seems like Apache tried to deliver a mix of the local portal and the proxified one. So no issue related to the fixed address.
Thanks!