Namenswahl - Wie bestimmte ich die Domäne meiner Dienste

Ein Versuch einer Gegenüberstellung von verschiedenen Benennungen.

Wenn sie früher eine Firma oder Niederlassung gegründet haben, dann mussten Sie neben dem Sitz sich auch einen Namen einfallen lassen. Bezüglich der Kommunikation konnten Sie nur einen Telefonanschluss bei der Post beantragen und eine WahlMöglichkeit bei der Rufnummer war nicht vorhanden. Die Vorwahl wurde durch das Ortsnetz vorgegeben und die Rufnummer wurde eben „vergeben“. Heute stellen Firmen vor ganz neuen Kommunikationsoptionen. Sie haben alle mit Namen zu tun, die an den unterschiedlichsten Stellen zum Einsatz kommen.

Erste Überlegungen

Es gibt ein paar generelle Empfehlungen für einen Namen, wenn es NICHT der Firmenname sein soll. Einige Namen sind sehr schwer oder gar nicht mehr zu ändern wie z.B. den AD-Forestname mit Exchange oder die Exchange Organisation. Das kann ein Argument sein, nicht den Firmennamen zu nehmen, um auch Übernahmen politisch zu vereinfachen. Aber es gibt ein paar allgemeine Regeln.

• DNS-Name im Internet
  Wenn Sie einen Namen verwenden, dann sollten sie vorab vorsichtig prüfen, ob der Namen als Internet DNS-Name schon belegt ist. Sie sollten unbedingt einen Namen wählen, den Sie im Zuge der Nutzung auch als DNS-Name in den relevanten Domänen (COM, DE, NET, u.a.)registrieren können. Sie sollten NIE einen Namen verwenden, der einer anderen Firma gehört und besser keinen ".local" o.ä.
• Länge = Kurz
  Sie ersparen sich viel Arbeit bei der späteren Nutzung, wenn der Name "kurz" ist. Der Windows NT4-Domänenname ist auch 14 ZEichen beschränkt und auch ein DNS-Name sollte nicht länger als 127 Zeichen sein. Aber wollen Sie wirklich ein "User@das-ist-der-zentrale-forest.de" als UPN eingeben ?.
• Aussprache
  Ob es nun ein Wort aus dem deutschen, englischen oder anderem Sprachraum ist, ist solange egal, wie es weltweit einfach zu sprechen und verstanden werden kann. Es kann nerven, wenn ein Helpdesk am Telefon solche Basisdaten buchstabieren muss.
• Bedeutung
  Das Problem können schon Autohersteller, die ihre Fahrzeuge mit Namen versehen und erschreckt feststellen, dass das gleiche Wort in anderen Sprachen eine gänzlich unerwartete Bedeutung hat.
• Generisch
  Speziell größere Firmen oder unternehmen, die mehrere Töchter unter einem Dach vereinen, sind mit einem generischen Namen vielleicht besser beraten. Das verhindert spätere Probleme bei Zusammenschlüssen mit der Identitätsfindung.
• Doppelt prüfen statt umbenennen
  Sprechen Sie mit möglichst viele Personen, Welche Namen ein "Problem" darstellen könnten. Aber nutzen Sie bitte immer eine Namensliste und nicht nur einen Vorschlag, sonst kommt ihnen jemand bei der DNS-Registrierung zuvor. Eine nachfolgende umbenennung verursacht in der Regel sehr hohe Kosten.

Die Tragweite des Namens kann nur immer wieder betont werden. Hier ein paar Stellen, an denen ein Name "sichtbar" werden kann.

Wo werden Domänennamen genutzt ?

Hier ein paar Stellen, bei denen Namen verwendet werden.

• öffentliche Webseite
  Als Außendarstellung sind die Adressen für die Webseiten primär für das Marketing interessant. Hier gibt es eigentlich keine Abhängigkeiten zur internen IT und die Domänennamen können im Rahmen der verfügbaren Namen selbst gewählt werden. Es ist also kein Problem auch „pro Land“ eine Domäne zu kaufen (www.firma.de, www.firma.com. www.firma.ru) und häufig sogar gewollt, um den Namen möglichst zu belegen und Domaingrabber abzuhalten.
  Aufgrund der Vielzahl an „Top Level Domain“ und Kosten gibt es aber auch Firmen, die nur noch „die eine“ Domäne nutzen und bewerben.
  Wenn über diese Webseiten auch „Shop-Systeme“ betreiben, dann kommt die Verschlüsselung ins Spiel. Jeder bei einer Verschlüsselung verwendete Name muss in einem Zertifikat aufgeführt werden, was zu Kosten führt.
• Private Webseite und Webdienste
  Neben den öffentlichen Seiten gibt es immer mehr Webseiten, die nicht für die Allgemeinheit bestimmt sind.
  Teils werden sie zur Kommunikation von Mitarbeitern aus dem Internet (z.B. Mails per Browser lesen, Mails per Mobiltelefon synchronisieren, Instant Messaging) genutzt.
  Andere Webseiten dienen der Bereitstellung von Portalen für Partner, Lieferanten oder generische Datenaustauschschnittstellen.
  Oder diese Dienste werden für die Verbindung von Servern (z.B. sicherer Mailaustausch, Federation mit MSN, Skype, Lync etc.) benötigt.
  All diesen Diensten ist gemeinsam, dass Sie in der Regel per SSL verschlüsseln, die Identität anhand der Namen prüfen und teilweise eine Anmeldung erfordern.
  Auch hier kommen fast immer Zertifikat mit den entsprechenden Namen zum Einsatz
• Maildomäne
  Der Versand von Mails über das Internet ist per Default „unsicher“. Die Server fragen nach dem Zielsystem (DNS Abfrage auf MX-Record) und senden ihre Mails ohne zu prüfen, ob sie beim richtigen Ziel gelandet sind und ohne Verschlüsselung.
  Für ein unternehmen stellt sich erst einmal die Frage der Außenwirkung der Mailadresse auf Visitenkarten. Sollen alle Mitarbeiter als „firma.com“ erreichbar sein. Das wirkt „global“ aber große Firmen werden eher mit Namenskonflikten zu tun haben. Gibt es hingegen für jede Ländergesellschaft mit eigener Webadresse auch eine korrespondierende Mailadresse, dann kommt schnell einige Domains zusammen, die auf dem Mailserver verwaltet werden müssen.
  Es ist übrigens problemlos möglich, einem Benutzer mehrere Adressen zuzuteilen, so dass er über mehrere Namen erreichbar ist. Er sendet aber immer mit seiner primären Adresse
  Dennoch ist die Wahl der „Maildomäne“ für ein unternehmen wichtig, weil auch Mails und Mailserver verschlüsselt und signiert werden können.
  Ein KO-Kriterium für viele Domains könnte sein, dass Mailprogramme wie Outlook oder Smartphone vom Anwender nur die Mailadresse und das Kennwort erfragen. Im Hintergrund läuft dann ein „Autodiscover“ ab, bei der das Endgerät nach einen bestimmten Namen (autodiscover.<maildomain>) fragt. Die Verbindung muss verschlüsselt sein. Ein zentrales Mailsystem muss demnach ein Zertifikat mit vielen Namen (einem je Domain) für diese Autodiscover-Adresse haben.
  Dies kann schnell teuer oder gar unmöglich werden, da die Anzahl der Namen im einem Zertifikat beschränkt sind. Es ist möglich, auf diese „Autoerkennung“ zu verzichten, was aber an anderer Stelle mit Einschränkungen verbunden ist, z.B. dass die Anwender die Adresse des Servers manuell eingeben müssen oder andere Produkte wie Lync von extern nicht die Voicemail-Nachrichten anzeigen können.
• SIP-Adresse
  Die SIP-Adresse wird irgendwann wichtiger werden, als die Telefonnummer. Je mehr sich VoIP durchsetzt, desto weniger ist es erforderlich „Rufnummern“ zu nutzen. Besonders wenn die SIP-Adresse sich aus der Mailadresse ableiten kann, wird die Integration der Kommunikation stark zunehmen. Das kann natürlich auch gerade nicht gewollt sein. Im internen Netzwerk ist die Vergabe der Adressen weniger kritisch, da interne Zertifikate quasi nichts kosten und Gruppenrichtlinien eine Anpassung der Konfiguration zumindest für Windows PCs im Forest leicht ermöglich. Mit der Zunahme von Geräten wie iPad, Android etc., die auch intern arbeiten, wird sich dies aber auch ändern bzw. diese Gerät sollten selbst bei einer „internen“ Verbindung arbeiten, als wären sie extern. Dies erleichtert auch das Wechseln zwischen WiFi und GSM. Denkbar wäre eine eigene WiFi-SSID für Mobilgeräte.
  Ganz wichtig werden die Namen aber, wenn externe Teilnehmer z.B.: bei Meetings teilnehmen sollen oder Partnerschaften zu anderen Firmen per SIP aufgebaut werden. Die Server erwarten, dass untereinander die Gegenstellen auch in den Zertifikaten erscheinen. Hier kann es sich lohnen, Namen zu reduzieren.
• UPN
  Benutzer melden sich an der Domäne mit einem Benutzernamen und Kennwort an. In Umgebungen mit mehreren Domänen müssen Sie „ihre“ Domäne auswählen oder als „DOMAIN\Username“ vorweg schreiben. Seit Windows 2000 ist es möglich, sich mit einem „UserPrincipalName“ (UPN) anzumelden der frei wählbar ist und über alle Domänen hinweg erhalten bleiben kann. Es bietet sich an hierzu z.B.: die Mailadresse zu nutzen, die der Anwender sowieso schon kennt und flüssig eintippen kann. Spätestens bei der nächsten Migration wird die Umstellung für alle einfacher, wenn der UPN genutzt wird.

Dies sind zumindest die "häufigsten" Einsatzzwecke aber natürlich nicht die einzigen. öffentliche Zertifikat kommen z.B.: auch oft für VPN-Zugänge, WiFi-Authentifizierung, Lieferantenportal etc. zum Einsatz.

Zertifikate

Es geht aber nicht nur im den "sichtbaren" Namen, der bei Kunden oder Kommunikationspartnern erschein. Sobald die Kommunikation z.B. verschlüsselt werden soll oder die Gegenstelle die Identität des Servers prüfen will, kommen Zertifikate ins Spiel. Zertifikate koste Geld und es gibt Auch die ein oder andere Einschränkung zu beachten. Das sind reale wiederkehrende Kosten. Die Aufgabe von Zertifikaten sind:

1. Sicherstellen, dass die richtige Gegenstelle erreicht wurde
2. Sicherstellen, dass der der richtige Client fragt
3. Verschlüsselung von Daten

Das Ganze funktioniert natürlich nur, wenn die Zertifikate von einer „vertrauenswürdigen“ Stelle ausgestellt wurden. Es gibt einige dieser „Root Certificate Authorities“, die sich diese Dienstleistung auch bezahlen lassen. Der Einsatz einer eigenen Zertifizierungsstelle ist zwar möglich, erfordert aber die Verteilung des Stammzertifikats auf alle Systeme. Dies funktioniert mit den eigenen Windows PCs im gleichen Forest noch einfach. Aber losgelöste Geräte oder gar andere Server anderer Firmen werden ihren selbst ausgestellten Zertifikaten sicher nicht vertrauen. Damit ist klar, dass Zertifikate auf jeden Fall „gekauft“ werden müssen.

Zertifikate enthalten neben Informationen über den Aussteller, Rückruflisten, Gültigkeitsdauer, Einsatzzweck als wesentlichen Bestandteil auch einen Namen. Alle Prozesse prüfen die Gültigkeit und der Name ist besonders wichtig.
Der Austausch der Schlüssel und die Überprüfung der Namen passiert übrigens ganz am Anfang einer Verbindung noch ehe überhaupt Nutzdaten übertragen werden.
Ein Zugriff auf https://www.google.com erfolgt auf die per DNS aufgelöste IP-Adresse. Der Webserver dahinter kann nicht auswählen, welches Zertifikat er an den Client sendet, da er noch gar nicht weiß, welchen Namen der Client ansprechen will. Daraus resultiert, dass auf einer Kombination von IP-Adresse und TCP-Port immer nur genau ein Zertifikat gebunden sein kann. Soll der gleiche Webserver als unter mehreren „Namen“ per SSL erreichbar sein, dann muss das Zertifikat alle Namen enthalten.

Es gibt klassische drei Arten von Zertifikaten, die beim Einsatz auf Servern eine Rolle spielen

• Simple Name
  Das Zertifikat enthält genau einen Namen. Das ist das einfachste und meist billigste Zertifikat, aber war lange Zeit für Webseiten vollkommen ausreichend. Allerdings musste der Server natürlich eine eigene IP-Adresse bekommen, die kein anderer Dienst noch weiter verwenden kann. Bei Webservern ist es schon üblich, dass viele unterschiedliche Webseite unter der gleichen IP-Adresse zu erreichen sind. Das geht dank "HostHeader" problemlos, solange keine Verschlüsselung ins Spiel kommt.
• Wildcard *.firma.com
  Als erste Lösung, mehrere Webseiten unter der gleichen Adresse zu betreiben, galten Wildcard-Zertifikate. Sie sichern z.B. den Namen "*.firma.de" ab, so dass Sie viele Subdomains anlegen konnten, z.B. www.firma.de, support.firma.de, autodiscover.firma.de, etc. Allerdings mussten alle in der gleichen Stammdomäne liegen. Der Name ist ja nicht auf www.firma.* ausgestellt, um ihre unterschiedlichen Länderpräsenzen mit einem Zertifikat abzusichern. Sie sind zudem teurer und wenn es gelänge das Zertifikat zu stehlen, könnte jemand eine eigene Webseite, z.B. "bestellung.firma.de" einrichten, noch etwas DNS-Spoofing anwenden und schon würde kein Kunde mehr merken, dass er seine Daten an eine fremde Stelle sendet. Aus Sicherheitsüberlegungen sind Wildcard-Zertifikate kritisch zu sehen.
• SAN-Zertifikate
  Die Lösung dieses Konflikts sind Zertifikate, die mehrere "Subject Alternate Names" enthalten. Ein Zertifikat, welches viele Namen enthält erlaubt den Betrieb mehrere Hostname unterschiedlicher Domains hinter einer IP-Adresse, wobei diese Namen maximal 1024byte belegen dürfen. Voraussetzung ist natürlich, dass die Gegenstelle auch damit umgehen kann. Sie sind sicherer als Wildcard Zertifikate aber natürlich lässt sich auch hier eine ausstellende Zertifizierungsstelle für die Namen bezahlen. Sie muss ja auch für jeden Namen prüfen, dass Sie zurecht dafür ein Zertifikat anfordern. Das ist besonders aufwändig, wenn mehrere Domänen aus unterschiedlichen Ländern und vielleicht Tochterfirmen zusammengefasst werden. So ein Zertifikat kann aber verschiedene Dienste, die sowieso auf dem gleichen Server laufen, einfach erreichbar machen. Das gilt z.B. für Lync oder Exchange, weswegen diese Zertifikate auch oft Unified Communication "UC"-Zertifikate genannt werden.

Sie können all diese Zertifikate bei öffentlichen Zertifizierungsstellen kaufen. Im rein internen Gebrauch kann auch eine korrekt installierte Firmen CA ausreichend sein. Aber sehr schnell werden Sie auch Systeme unterstützen müssen, die nicht ohne weitere Vorarbeiten damit funktionieren.

Welche Anwendungen benötigen denn Zertifikatnamen ?

Ehe ich im nächsten Kapitel endlich den Kreis zur "Findung" von sinnvollen Domänennamen schließe, muss ich noch ein Kapitel Hintergrundinformationen einschieben. Wie müssen nämlich wissen, welche Anwendungen später aus den festgelegten Domänennamen andere Adressen ableiten, für die eventuell Zertifikate erforderlich werden. primär sind dabei zwei Anwendungen interessant, die auch direkten Einfluss auf die Anwender haben.

Ich beschreibe ich den "Standardfall" mit der höchsten Kompatibilität. Wenn man mit Einschränkungen leben kann oder Vorarbeiten leistet, sind die Einflüsse auf die erforderlichen Namen in Zertifikaten reduzierbar.

• Exchange Autodiscover
  Früher war es eine halbe Wissenschaft ein Outlook so einzurichten, das es den Server gefunden hat. Seit Exchange 2007 und Outlook 2007 gibt es den "Autodiscover"-Automatismus, der von immer mehr Programmen genutzt wird, die auf Exchange Informationen zugreifen wollen. Der Client erwartet in der Regel nur, dass der Anwender im die Mailadresse mitteilt, z.B. vorname.nachname@firma.de. Die Software nimmt dann den Domänenname "firma.de" und ergänzt ihn um "https://autodiscover". Der Client greift auf diese URL zu, um die erforderlichen Parameter der Einrichtung zu erfahren. Wer also viele SMTP-Domains auf seinem Server betreibt und diesen Automatismus nutzt, braucht für jede Domäne einen passenden DNS-Eintrag und Namen im Zertifikat.
  Ein umleiten von "autodiscover.tochterfirma.tld" auf "autodisover.firma.tld" wird vom Client zumindest mit einer Warnung über die Umleitung oder Zertifikatsfehler quittiert, die der Anwender beantworten muss.
• Lync Clientzugriff
  Das gleiche Spiel gibt es beim Lync Client, welcher extern nach _sip._tls.<sipdomain.tld> fragt und als Hostname einen Rechner in der DNS-Domäne <sipdomain.tld> erwartet. Eine Umleitung auf einen anderen Hostname wird auch mit einem Fehler oder Warnung unterbrochen.
  Modernere Clients nutzen mittlerweile einen alternativen Weg, der über einen Webservice unter "Lyncdiscover.<sipdomain> geht. Auch hier empfiehlt Microsoft den SSL Zugriff mit der gleichen Folge für Zertifikate aber es ist auch ohne SSL möglich.
• Lync Federation
  Ein zweiter Bereich ist die Open-Federation mit anderen Firmen. Ein DNS-Eintrag zeigt den Edge-Servern den Weg zum Partner. Auch hier muss der NDS-Name des Servers mit der SIP-Domain übereinstimmen. Wer also mehrere SIP-Domains betreibt, muss den Access-Edge unter allen Domänen erreichbar machen und entsprechend ein Zertifikat kaufen. Das ist klassischerweise auch ein SAN-Zertifikat mit der erforderlichen Anzahl.
  Diese Voraussetzungen gelten nicht, wenn Sie die Partnerbeziehungen explizit einrichten. Dann können Sie problemlos sagen, das das Ziel für Empfänger der SIP-Domäne über einen Host in einer anderen DNS-Domäne erreichbar sind. Gleiches gilt für die Einrichtung von Hosting-Systemen.
• Lync Meeting (Meet/Join)
  Wer mit Lync Meetings nach extern versendet, liefert ebenfalls eine Adresse mit, um in dem Meeting teilzunehmen. Oft ist dies dann https://join.firma.tld oder https://meet.firma.tld. Wenn jede ihrer Firmen mit eigener SIP-Domäne aber auch eine eigene "Meeting-URL" haben will, dann brauchen Sie auch für diese Webveröffentlichung ein Zertifikat mit den verschiedenen Namen oder mehrere offizielle IP-Adressen mit eigenen Webveröffentlichungen.

All dies sind Dinge, die eine einfache "Plug and Play"-Nutzung von Diensten erlaubt. Natürlich lässt sich die ein oder andere Voraussetzung auch etwas anders lösen, z. B. durch manuelle Konfiguration auf den Client, der Verzicht auf eine automatische "Findefunktion". Hier gilt es dann die Kosten für Zertifikate und den Arbeitsaufwand und andere Einschränkungen gegeneinander aufzuwägen.

Beispielbedarf für unterschiedliche Modelle

Ausgehend von der "perfekten" Konfiguration, bei der alle automatische Funktionen gewährleistet sind, habe ich eine Übersicht der mindestens erforderlichen Zertifikatnamen für verschiedene Modelle gegenüber gestellt. Im wesentlichen geht es ja um die Exchange Namen "autodiscover", die Adressen "Lyncdiscover" und "sip" für Lync. Als Muster habe ich die MSXFAQ- Domänennamen verwendet, die natürlich nicht real sind.

Allgemeine Zugriffe wie die Lync Webservices (z.B. lyncweb.<hauptdomain>), Exchange OWA (z.B. mobile.<hauptdomain> oder die MeetingURLs (meet.<hauptdomain>/msxfaq und join..<hauptdomain> habe ich aus Kostengründen aber nicht für jede Mail oder SIP-Domain getrennt ausgeführt.

Der UserPrincipalName (UPN) ist für Zertifikate nicht relevant aber wird oft mit der Mailadresse oder SIP-Adresse verwechselt. Es gibt Menschen, die behaupten steif und fest, dass sie sich mit ihrer "Mailadresse" an Windows anmelden. Das hat nur den Anschein.

Ich bin eigentlich ein Verfechter der UPN-Adresse=SIP-Adresse=MAIL-Adresse und in einem Firmenverbund besser eine Hauptdomäne statt viele "Länderdomänen". Aber es gibt auch Gründe für abweichende Modelle. z.B.: weil man nicht möchte, dass man von der Mailadresse auf die SIP-Adresse schliessen kann, um "nervige SIP-Kommunikation" zu verhindern oder weil ein Angreifer nicht das Anmeldekonto frei Haus geliefert bekommen sollte.

Hier eine Aufstellung von drei Modellen und den dazu erforderlichen Zertifikaten:

• Einzeldomain
  Alle nutzen den einen gemeinsamen DNS-Namen für Mail und Lync. Eine durchaus übliche Konfiguration, auch für größere Firmen.
• Single SIP
  Speziell aufgrund der Zertifikatproblematik mit Federation und der "Neueinführung" von Lync wird gerne die SIP-Adresse mit einer Domäne abgebildet. Die bestehende "MultiDomain"-SMTP-Adressen werden aber meist nicht umgestellt. Oft umgehen solche Firmen die Thematik um Exchange-Zertifikate durch den Verzicht auf private Geräte und verwenden z.B. Gruppenrichtlinien zur Vorgabe der Server oder manuelle Konfiguration bei Mobilgeräten.
• MultiDomain
  Wer wirklich jeder Ländergesellschaft ihren eigenen Namensraum für Mail und SIP? zugesteht, wird eine ganze Menge von Zertifikaten benötigen oder Sie müssen Einschränkungen bei automatischen Funktionen in Kauf nehmen.
• MultiSubDomain
  Eine Variante Zertifikate zu sparen könnten Subdomains z.B. für Länder sein, z.B.: de.msxfaq.com. Die Intension dahinter ist mit Wildcard-Zertifikaten dann mehrere Domänen bedienen zu können. Dies erspart natürlich nicht die erforderlichen DNS-Einträge für die Namen und Wildcard-Zertifikate unterliegen auch verschiedenen Einschränkungen.

Hier die Beispiele:

Schauen Sie, wie die Anzahl der Namen ansteigt und bedenken Sie, dass jeder Name Geld kostet, verwaltet und erneuert werden muss und sie gegenüber der Zertifizierungsstelle auch die Rechtmäßigkeit am Namen belegen müssen. Hinzu kommt., dass die meisten Zertifizierungsstellen nur eine begrenze Anzahl von Namen im SAN-Feld zulässt und zudem das Feld selbst max. 1024Byte groß sein darf.

Sollten Sie dann nachträglich noch einen Namen dazu addieren wollen, dann lassen dies nur ganz wenige Zertifizierungsstellen zu. Es kann also sein, dass Sie ein Zertifikat komplett "neu" beantragen (und bezahlen) müssen.

Hinweis: Die Namen kommen auf verschiedenen Systemen mit unterschiedlichen IP-Adressen zum Einsatz. Sie müssen also nicht alle Namen in ein einziges Zertifikat pressen.

Weitere Links

• SAN-Zertifikate
• Wildcard Zertifikate
• Firmen CA
• Autodiscover
• Single Label Domain
• Active Directory: Wie soll das neue Active Directory heißen?
  https://www.frankysweb.de/active-directory-name-fr-ein-neues-active-directory/