Welcher Domänenname?

UCS - Univention Corporate Server
#1

Welcher Domänenname sollte für eine neue Domäne gewählt werden? Ein Name, welcher mit der Organisation tu tun hat oder lieber ein neutraler?

Sollte eine interne Domainendung (z.B. .local, .intranet, .internal, .lan, …) gewählt werden oder eine registrierte Domain?

Verständnisfrage zur Installation
#2

Hallo,

ich persönlich empfehle eigentlich immer eine Subdomain einer öffentlichen Domain zu nehmen, die einem gehört bzw. deren DNS-Einträge man unter Kontrolle hat.

Als Beispiel:

Deine Organisation heißt “Cabbage Corp” und du hast schon “cabbage.org” als externe Domain registriert, bspw. für die Website. Dann könnte die interne UCS Domäne bspw. “intern.cabbage.org” heißen oder “corp.cabbage.org”. Das hat folgende Vorteile:

  • Du kontrollierst die DNS-Einträge für “*.cabbage.corp” und kannst sicherstellen, dass es niemals eine Namenskollision zwischen internen und externen Systemen geben wird
  • Wenn du von UCS intern bereitgestellte Dienste (sagen wir mal ownCloud/Nextcloud) auch extern erreichbar machen willst, kann man das reicht einfach so konfigurieren, dass bspw. “cloud.cabbage.org” von extern erreichbar ist, aber auf ein internes UCS-System geNATet wird. Doppelter Vorteil: Auch die internen Systeme könne einfach “cloud.cabbage.org” verwenden und man muss interne und externe Clients (oder gar wechselnde Clients wie Notebooks) nicht unterschiedlich konfigurieren.
  • Durch die Verwendung einer Subdomain einer offiziell registrierten Domain spart man sich viel Ärger, der einen bei der Verwendung von inoffiziellen TLDs (.local, .int, .lan …) heimsuchen kann. Zum einen sind diese TLDs nicht RFC-konform (.int ist bspw. eine offizielle TLD des Internets für internationale Unternehmen) und zum anderen macht insbesondere .local gerne Probleme bei mDNS.

Just my 2 cents :slight_smile:

1 Like
Postfix PTR error
"Host settings" in field "Fully qualified domain name" I must enter "examp.com" or "XXXX.examp.com"?
Real domain useful for installation?
#3

Meine Empfehlung sieht praktisch genau so aus wie die von @Grandjean, aus den gleichen Gründen.

Das einzige, was man wirklich, wirklich, wirklich nicht machen sollte, ist einen Domänennamen zu nutzen, den man schon für andere Dinge nutzt (um beim Beispiel von @Grandjean zu bleiben: “cabbage.org” sollte nicht gewählt werden). Grund ist, dass das UCS-System davon ausgeht, dass es der alleinige Herrscher über diese DNS-Domäne ist. Es gibt nur Probleme, wenn man so etwas macht. Unterdomänen wie oben beschrieben sind hingegen OK.

Das gilt übrigens analog für Windows-basierte Active Directories; ist nicht UCS-spezifisch.

1 Like
#4

Vielen Dank für eure/Ihre Rückmeldung.

Für zukünftige Planungen/Konzepte würde ich mich hieran orientieren. Macht es noch Sinn eine bestehende Domänenstruktur entsprechend anzupassen?

#5

Wie würde ich den Dienste, wie Nextcloud/ownCloud oder OpenExchange öffentlich erreichbar machen? Also ich würde dann um dein Beispiel zu nehmen “cloud.cabbage.org” auf die öffentlich/statische IP zeigen lassen. Und am Router eine Portweiterleitung auf den UCS Server, wo die Applikation installiert ist einrichten? Wie kann ich sagen, dass nur z.B. Nextcloud extern erreichbar ist und nicht noch weitere installierte Apps?

#6

Moin,

Wenn mit einer Portweiterleitung gearbeitet wird, so muss der Apache auf dem UCS-System so konfiguriert werden, dass er den Zugriff auf bestimmte URLs nur bestimmten IP-Adressen gestattet (nämlich denen des internen Netzes). Der Zugriff auf andere URLs hingegen (z.B. Nextcloud) ist für alle Quell-IPs zulässig.

Was Sie probieren können, ist eine Datei in /etc/apache2/conf-available anzulegen (z.B. my-access.conf) und diese von …/conf-enabled zu verlinken (oder mit a2enconf my-access.conf). Dort könnte dann z.B. folgender Inhalt stehen:

<Location />
  Require ip 192.168.42.0/24
  Require all denied
</Location>

<Location /nextcloud>
  Require all granted
</LocatioMatch>

Das Subnetz muss natürlich angepasst werden. Anschließend einen Reload vom Apache nicht vergessen.

Das erlaubt den Zugriff auf /nextcloud/… für alle, und auf den Rest nur für lokale Quelladressen.

Gruß,
mosu

#7

Huhu,

wenn ich die Konfiguration im Apache auf für IPv6 vornehmen muss, welche Angaben trage ich am besten ein?
Reicht bei einem ULA-Netz fe80::/64?
Bei einem Netz ohne ULA, wie mache ich es dort, dass ich z.B. nur den 64 Bit-Adressraum (48 Bit vom ISP und 16 Bit für das Subnet) angebe?

Die Apache config sieht bei mir wie folgt aus:

<Location />
  Require ip 10.11.12.0/23
  Require all denied
</Location>

<LocationMatch /kix>
  Require all granted
</LocationMatch>

<LocationMatch /webapp>
  Require all granted
</LocationMatch>

<LocationMatch /univention/self-service>
 Require all granted
</LocationMatch>

Der UCS Self Service soll auch extern aufrufbar sein, leider ist es nun so, dass beim Aufruf der Seite nur der obere gelbe balken lädt. Was kann man dort am besten machen?

#8

Huhu,

Ich verstehe die Frage nicht. Einfach ein Require ip <lokales IPv6-Subnetz> eintragen. Welches das Subnetz genau ist, wie groß die Netzmaske ist, das hängt von Ihrem Setup up. Das Minimum ist vermutlich das, was Ihr Server anzeigt, wenn Sie mal ip -6 addr show eingeben.

Wenn Sie vom ISP größere Netze bekommen (sehr gut!), dann halt eine entsprech größere Netzmaske nehmen, wenn Sie all Ihre Netze zulassen wollen. Allerdings häng halt auch das davon ab, wie Sie Ihre Netzwerke aufteilen. Vielleicht verwenden Sie ein /64er für Gäste-WLAN, und genau das soll keinen Zugriff bekommen? Und ein weiteres /64er wird die DMZ, auch die soll nicht dürfen?

Gruß
mosu

#9

Huhu nochmals,

Ein kurzer Load der Self-Service-Seite zeigt in der access.log vom Webserver Zugriffe auf die folgenden URLs:

univention/get/meta
univention/js/config.js
univention/js/dgrid/css/dgrid.css
univention/js/dijit/icons/editorIcons.css
univention/js/dijit/themes/dijit.css
univention/js/dijit/themes/umc/bootstrap.css
univention/js/dijit/themes/umc/fonts/Roboto-Bold.woff
univention/js/dijit/themes/umc/fonts/Roboto-Medium.woff
univention/js/dijit/themes/umc/fonts/Roboto-Regular.woff
univention/js/dijit/themes/umc/images/icons.svg
univention/js/dijit/themes/umc/images/icons-white.svg
univention/js/dijit/themes/umc/images/univention-white.svg
univention/js/dijit/themes/umc/umc.css
univention/js/dojo/cldr/nls/en/currency.js
univention/js/dojo/cldr/nls/en/gregorian.js
univention/js/dojo/cldr/nls/en/number.js
univention/js/dojo/dojo.js
univention/js/dojo/hash.js
univention/js/dojo/nls/dojo_ROOT.js
univention/js/dojo/resources/blank.gif
univention/js/dojo/resources/dojo.css
univention/js/dojo/selector/acme.js
univention/js/dojo/selector/lite.js
univention/js/dojox/encoding/base64.js
univention/js/dojox/grid/enhanced/resources/Common.css
univention/js/dojox/grid/resources/Grid.css
univention/js/dojox/image/resources/LightboxNano.css
univention/js/umc/hooks.json
univention/js/umc/i18n/en/app.json
univention/js/umc/i18n/en/branding.json
univention/languages.json
univention/login/i18n/en/main.json
univention/login/LoginDialog.js
univention/login/main.js
univention/saml/iframe/
univention/self-service/
univention/self-service/css/self-service.css
univention/self-service/i18n/en/main.json
univention/self-service/lib.js
univention/self-service/main.js
univention/self-service/NewPassword.js
univention/self-service/PasswordBox.js
univention/self-service/PasswordChange.js
univention/self-service/PasswordForgotten.js
univention/self-service/ProtectAccountAccess.js
univention/self-service/TextBox.js

Ich empfehle daher, den Zugriff auf /univention allgemein zu erlauben und auf /univention/management auf lokale Netze zu beschränken.

Gruß
mosu

#10

Hallo zusammen,

ich bin dank @lebernd auf diesen Beitrag gekommen und würde gerne ein Detail noch klären.

Damit die interne Dienste wie: NextCloud, Rocket.Chat, Jitsi von extern über HTTPS/443 erreichbar sind lege ich auf dem externen DNS-Server hierzu immer Subdomains an:

  • cloud.cabbage.org → UCS-Node1
  • chat.cabbage.org → UCS-Node2
  • jitsi.cabbage.org → UCS-Note3
  • …

Die UCS-Umgebung ist inter jedoch unter: intern.lan installiert.

Als Router-Firewall nutze ich die pfSense. Der darauf laufende HA-Proxy mappt die ankommenden HTTPS-Anfragen anhand ihrer Subdomain auf die entsprechende IP durch. Ebenfalls läuft auf der pfSense ACME und hät für jede Subdomain das entsprechende LetsEncrypt-Zertifikat vor ist im HA-Proxy dem entsprechenden Frontend zugeordnet. Der Dienst kümmert sich auch um die Erneuerung der Zertifikate.

Um die Dienste intern auch unter ihrem “externen” Namen zu erreichen z.B. cloud.cabbage.org habe ich früher NAT-Reflection genutzt. Mittlerweile habe ich das mit einer zusätzlichen virtuellen LAN-IP auf der pfSense und einem daran “lauschenden” HA-Proxy gemacht der das entsprechend umsetzt.

Das funktioniert bei vielen Diensten gut. Bei NextCloud z.B. rufe ich intern: https://cloud.cabbage.org/nextcloud, lande im Anmeldefenster von Nextcloud und die URL bleibt im Browser auch so erhalten.

Jitsi hingegen verhält sich da ganz anders. Das erreiche ich von intern unter: https://jitsi.cabbage.org aber die URL im Browser wird zu: https://jitsi.gw01.intern.lan/ Also den FQHN des UCS-Node mit vorgestelltem 'jitsi'.

Ich habe die Lösung zum umschreiben mittels VHOST hier im Forum gefunden:

Zum testen damit einfach mal auf 'jitsi.intern.lan' umgeschrieben. Von intern kommt dann unter dieser URL mit vorangestelltem https:// auch Jitsi aber wenn ich eine Meeting starte kommt sofort “Verbindung getrennt”. Habe dann gesehen dass einige Variablen im UCR für Jitsi auf https://jitsi.gw01.intern.lan/ gesetzt sind. Das soll jetzt aber nicht das Thema sein. Ich denke mit der Installation mit einer Subdomain diesen Ärger umgehe.

Sorry für die lange Vorrede! Jetzt zur eigentlichen Frage. Ich lege extern nun eine Subdomain intern.cabbage.org an. Den lokalen UCS-Master installiere ich mit dieser Sub-Domäne. Wenn dann alles installiert ist wird meine VM auf der Jitsi läuft den FQHN:

gw.intern.cabbage.org

haben. Das darauf laufende Jitsi demzufolge:

jitsi.gw.intern.cabbage.org

Ist es in dieser Konstellation dann einfacher über einen VHOST dies auf:

jitsi.cabbage.org

umzuschreiben?

Beste Grüße
Sven

Mastodon