none
Konfiguration Dynamics CRM 2013 für Internet-Facing Deployment

    Allgemeine Diskussion

  • Hallo Zusammen,

    Oben genannte Konstellation habe ich bei einem
    Kunden installiert. Soweit läuft auch alles zzgl. IFD und ADFS. Ich kann
    mich von außerhalb der Domäne per ADFS/IFD auf den CRM-Server
    aufschalten.

    Nun soll das Konstrukt noch im Internet
    veröffentlicht werden. Doch dabei habe ich ein kleines
    Verständigungsproblem. In der offiziellen Dokumentation von Microsoft
    (http://www.microsoft.com/en-us/download/details.aspx?id=41701) wird
    beschrieben, dass man, wenn CRM im Internet veröffentlicht wird, noch
    einige DNS-Records eingetragen werden müssen, was auch verständlich ist.
    Dies habe ich bereits im ADFS-Proxy gemacht, der in einer DMZ steht.
    Dort habe ich die HOSTS-Datei entsprechend angepasst.

    Nun soll das
    ganze über eine weitere öffentliche Domain und einer öffentlichen
    IP-Adresse über das Internet zugänglich sein. Allerdings kann ich a)
    nicht bei jedem die HOSTS Datei anpassen und b) keine Einträge im DNS
    hinzufügen, da bekanntlich das ganze über das Internet funktionieren
    soll und die Anwender von dort nur Zugriff auf die öffentlichen
    DNS-Server haben.

    Daher nun meine Frage, wie ich mein Ziel, Erreichbarkeit über Internet, erreichen kann?

    Bin für jeden Tipp dankbar..

    Beste Grüße

    Daniel Broz

    Donnerstag, 8. Januar 2015 15:24

Alle Antworten

  • Hi Daniel,

    dazu musst Du eine Domain bzw. die Domain der Firma, für die Du das machst, bei einem Hoster registrieren, z.B. www.contoso.com (normalerweise kostenpflichtig), wenn das nicht schon gemacht ist. Wenn die Firma eine Webseite hat, dann solltest Du Dich an den Anbieter wenden, bei dem sie gehostet ist.
    Bei dem Anbieter kannst Du dann i.d.R. über eine Weboberfläche steuern, auf welche IP der DNS-Name zeigen soll.

    Darüber kannst Du dann beispielsweise den DNS-Namen "crm.contoso.com" anlegen, der auf die IP 123.234.123.234 zeigt (die öff. IP, unter der der CRM-Server erreichbar ist).

    Noch ein Tipp: Du solltest schauen, dass Du Systeme im Internet nach Möglichkeit auch nur per HTTPS erreichbar machst.


    Gruß

    Ben

    MCITP Windows 7

    Wenn Dir meine Antwort hilft, markiere sie bitte entsprechend als Antwort! Danke! :-)

    Hinweis: Meine Posts werden "wie besehen" ohne jedwede Gewähr bereitgestellt, da menschliche, technische und andere Fehler nicht ausgeschlossen werden können.

    Donnerstag, 8. Januar 2015 15:45
  • Hallo Ben,

    Erstmal vielen Dank für deine Antwort!

    Das ist soweit alles verständlich. Damit der Zugriff von extern also reibungslos funktioniert, bedarf es nur einer öffentlichen IP und der dazugehörigen Domäne, also z.B. crm.Firma.de -> Public-IP, die ich beim ISP pflegen muss?

    Aber da das ganze über einen ADFS-Proxy läuft, der in der DMZ steht und die anderen Server (3 insgesamt) in einer eigenständigen Domäne stehen, müssten doch normal 2 öffentliche IPs notwendig sein, oder? 1 für den ADFS-Server bzw. ADFS-Proxy und eine weitere für den CRM-Server? Oder reicht eine völlig aus?

    Was ich nämlich nicht so ganz verstehe, ist, wie veröffentliche ich CRM im Internet, wenn ich nach dem offiziellen Guide von Microsoft ein IFD einrichte. Welche Voraussetzungen sind dazu notwendig?

    2 oder 1 öffentliche IP?

    Welche DNS-Records muss ich pflegen?

    Grüße Daniel

    Donnerstag, 8. Januar 2015 15:57
  • Hi,

    d.h. Du hast in der DMZ einen WAP (Web Application Proxy) stehen? Damit kenne ich mich noch nicht so gut aus, aber nach meinem Verständnis (von einem üblichen Reverse Proxy) sollte der externe Link auf die öffentliche IP des WAP zeigen.

    Der gibt die Anfrage ja dann intern an den CRM-Server weiter, somit sollte eigentlich eine öffentliche IP für den WAP reichen. Der DNS-Eintrag zeigt dann entsprechend auf diese IP.


    Gruß

    Ben

    MCITP Windows 7

    Wenn Dir meine Antwort hilft, markiere sie bitte entsprechend als Antwort! Danke! :-)

    Hinweis: Meine Posts werden "wie besehen" ohne jedwede Gewähr bereitgestellt, da menschliche, technische und andere Fehler nicht ausgeschlossen werden können.

    Donnerstag, 8. Januar 2015 16:07
  • Hallo Daniel,

    das ganze ist etwas komplizierter.

    Zum einen musst du eine externe URL auf die öffentliche IP eures ADFS-Proxy zeigen lassen, z.B. crm.contoso.com auf 1.1.1.1 wenn die öffentliche IP des ADFS-Proxys 1.1.1.1 lautet und euer CRM über crm.contoso.com erreichbar sein soll.

    Zusätzlich müssen die folgenden DNS-Einträge im öffentlichen DNS eingetragen werden:

    dev.contoso.com
    crmorganisation.contoso.com
    adfs.contoso.com
    auth.contost.com

    Das sind die Namen der offiziellen Unterlagen. Wenn ihr diese geändert habt, müssen die obigen DNS-Einträge entsprechend angepasst werden.

    Die Anpassung der Host Datei auf dem ADFS-Proxy musst du entfernen und diese in eurem internen DNS-Server eintragen. Nur die Hostdatei anzupassen wird für externe Zugriffe nicht funktionieren. Auf dem internen DNS-Server musst du die extern Domäne, in diesem Beispiel contoso.com, als neue Rootdomäne eintragen und dort die Hosts mit den internen Server-IPs einrichten.

    Das Ganze kann aber nur funktionieren, wenn euer SSL Zertifikat des ADFS-Servers auf *.contoso.com ausgestellt wurde und alle Verweise, auch die internen im CRM, auf constoso.com verweisen.


    Viele Grüße

    Michael Sulz
    MVP für Microsoft Dynamics CRM
    Blog
    Website XING LinkedIn Facebook Twitter

    Donnerstag, 8. Januar 2015 16:15
    Moderator
  • Hallo Michael,

    Vielen Dank für deine Antwort.

    Das macht dann nun alles schon mehr Sinn und klingt nun für mich auch einleuchtend. Die öffentliche IP und der gewünschte Name, über den CRM von außen erreichbar sein soll, sind bereits festgelegt und stehen zur Verfügung.

    Allerdings habe ich die Umgebung mit den internen Namen eingerichtet und das SSL-WildCard-Zertifikat auch entsprechend auf den internen Namen erstellt. Allerdings war das Problem, dass der Kunde seine IT sehr resktriktiv führt, sprich es sind keine weiteren Zonen im DNS-Server erlaubt und auch keine weiteren Einträge. Des Weiteren sollen die externen Anwender nur auf den Proxy zugreifen können und nicht diretk auf den Server. Selbst ein Mapping auf die interne Server-IP ist nicht erwünscht.

    Kann ich den Zugriff irgendwie anders realisieren? Z.b noch einen weiteren Server/Proxy davor setzen oder eine VPN-Verbindung erstellen?

    Grüße Daniel

    Donnerstag, 8. Januar 2015 16:26
  • dev.contoso.com
    crmorganisation.contoso.com
    adfs.contoso.com
    auth.contost.com


    Auf welche Adressen müssen die DNS-Records im öffentlichen DNS verweisen? Auf die öffentlich oder internen IPs der Server? Dann bräuchte man also doch zwei öffentliche IPs oder?

    Gäbe es vielleicht ein Workaround, um die internen CRM-Links auf die neue Domäne umzustellen? Das ZErtifikat könnte man zur Not noch austauschen, was sowieso geplant war, da noch einSelfSigned-Zertifikat eingesetzt wird und das richtige noch nicht zur Verfügung stand. Ist halt nur die Sache mit den CRM-Links..

    Donnerstag, 8. Januar 2015 17:20
  • Hi Daniel,

    öffentliche DNS-Records verweisen IMMER auf öffentliche IP-Adressen. Die internen IP-Adressen eines Netzwerks sind aus dem Internet nicht erreichbar.

    Stell Dir folgende Situation vor: zwei unterschiedliche Firmen verwenden intern das Netzwerk 192.168.1.0/24. Woher sollten hier die öffentlichen Server wissen, in welches der Netze sie Anfragen routen sollen? Aus diesem Grund gibt es öffentliche IP-Adressen. Das ganze Konstrukt wird sich durch IPv6 aber entscheidend verändern, so viel erst mal dazu. ;-)

    So, wie ich Michael verstehe, verweisen alle DNS-Records auf die gleiche IP (in seinem Beispiel also die 1.1.1.1 bzw. auf den ADFS-Proxy). CRM wird diese 4 URLs für bestimmte Abfragen nutzen und muss dementsprechend diese Namen mit einer öff. IP auflösen können.


    Gruß

    Ben

    MCITP Windows 7

    Wenn Dir meine Antwort hilft, markiere sie bitte entsprechend als Antwort! Danke! :-)

    Hinweis: Meine Posts werden "wie besehen" ohne jedwede Gewähr bereitgestellt, da menschliche, technische und andere Fehler nicht ausgeschlossen werden können.

    Freitag, 9. Januar 2015 06:48
  • Hi Ben,

    Wozu öffentliche und private IP-Adressen notwendig sind, ist mir bewusst. So ganz neu in der Materie bin ich nicht. Damit verdiene ich ja auch mein Geld. ;-) Mir ging es hier in erster Linie, um das Verständnis der CRM-Installation, damit ich das korrekt umsetzen kann. Dennoch Danke für die ausführliche Erklärung.

    Alles in allem habe ich aber sowieso nun das Problem, dass ich nur eine öffentliche IP zur Verfügung habe. Zudem ist der Kunde aufgrund seiner Sicherheitsrichtlinien nicht bereit dazu, die Adressen in seinem öffentlichen DNS bekannt zu geben. Er möchte nur eine öffentliche IP und eine Adresse benutzen.

    Daher habe ich mir nun folgendes überlegt:

    1. Die öffentliche IP wird auf die gewünschte Adresse verweisen

    2. In der Firewall wird die öffentliche IP auf die private IP geNATet (ADFS-Proxy)

    3. Ich werde auf dem ADFS-Proxy einen Apache installieren

    4. Diesen werde ich so einrichten, dass er die öffentliche Adresse per Redirect auf die interne Adresse umleitet

    5. Zusätzlich werde ich Bind 9 installieren, der dann als authoritativer Nameserver fungiert

    6. In diesem werde ich die übrigen internen Namen auf die internen IPs auflösen lassen

    7. Der Apache greift somit auf diesen Nameserver zu

    Ziel ist es, dass der Anwender dann nur eine Adresse eingeben muss und im Hintergrund läuft die komplette Kommunikation ab. Soweit die Theorie. Was meint ihr? Könnte das funktionieren?

    Freitag, 9. Januar 2015 09:14
  • Hi Daniel,

    ich schreibe immer zur Sicherheit etwas ausführlicher, manchmal sind hier auch Leute unterwegs, die "etwas weniger" Erfahrung haben. ;-)

    ME wird es mit den Namen zu Problemen kommen, sofern man CRM nicht so konfigurieren kann, dass es andere URLs verwendet. Wenn er die Namen beim Zugriff von extern nicht auflösen kann, wird es sicherlich in einigen Bereichen zu Fehlern kommen. Genaues wird Michael hierzu sagen können, wofür die Namen genau benötigt werden.

    Aus meiner Sicht macht die Installation eines Nameservers hier keinen Sinn, weil die Namen ja extern aufgelöst werden müssen (der Client bedient sich bei den Nameservern im Internet, die Deinen internen Nameserver nicht kennen und daher auch nicht anfragen werden).

    Ich kenne es aber von anderen Applikationen, die zwingend diese Namen auflösen können müssen, damit andere Funktionen problemlos klappen. Ein Beispiel hierzu wäre Exchange: klar kannst Du nur "owa.contoso.com" hinterlegen, allerdings wird es dann bei anderen Sachen zu Problemen bzw. manuellem Aufwand auf Client-Seite kommen, wenn beispielsweise "autodiscover.contoso.com" nicht aufgelöst werden kann.

    Du kannst es natürlich erst einmal so ausprobieren, wie Du es beschrieben hast (ohne Bind), dann wirst Du ja relativ schnell sehen, ob alles problemlos funzt oder nicht. Dass nur eine öff. IP zur Verfügung steht, sollte ja kein Problem sein, da nur eine benötigt wird.


    Gruß

    Ben

    MCITP Windows 7

    Wenn Dir meine Antwort hilft, markiere sie bitte entsprechend als Antwort! Danke! :-)

    Hinweis: Meine Posts werden "wie besehen" ohne jedwede Gewähr bereitgestellt, da menschliche, technische und andere Fehler nicht ausgeschlossen werden können.


    • Bearbeitet Ben-neB Freitag, 9. Januar 2015 10:47
    Freitag, 9. Januar 2015 10:47
  • Hi Ben,

    Ich hatte vor nach folgenden HowTos den BIND NameServer zu installieren:

    http : // blog . pluralsight . com / install-bind-dns-on-windows-web-server-2008

    http : // blog . pluralsight . com / configure-bind-dns-on-windows-web-server-2008

    Den Apache habe ich bereits auf mehreren Servern erfolgreich installiert, unter anderem in einer Konstellation mit Websphere. Hier wird der Apache auch nur für den Redirect auf eine andere URL verwendet und der gleichzeitigen Verwaltung von SSL-Zertifikaten.

    Ich werde nicht nur BIND installieren, sondern davor auch noch einen Apache Webserver. Letztendlich ist dieser Webserver dann nur für die Weiterleitung von crm.Firma.de auf crm.Firma.internal zuständig. Da der Apache dann aber auf den lokalen Nameserver zurück greift, sind meines Erachtens doch keine Records im öffentlichen DNS notwendig.. Das öffentliche DNS muss nur die Adresse crm.Firma.de auflösen können. Alles andere macht der Apache Webserver.

    Grüße Daniel

    Freitag, 9. Januar 2015 12:48
  • Ich habe das Problem gelöst. Allerdings habe ich mich nicht für meinen ersten Lösungsvorschlag entschieden, sondern für den einfacheren Weg. Und zwar die Umgebung auf die neue Domäne zu konfigurieren. Dazu muss die ADFS-Rolle nur deinstalliert und wieder installiert werden. Dann kann man den Konfigurationsassistent neu starten und das ADFS auf eine neue Domäne konfigurieren. Voraussetzung hierbei ist ein WildCard-Zertifikat, das auf die neue Domäne ausgestellt ist. Ansonsten kann man die identischen Schritte in der offiziellen Doku von MS zur CRM-Konfiguration für Internet-Facing Deployment durchführen.

    Um die Umgebung von außen erreichbar zu machen, habe ich im öffentlichen DNS folgende Einträge:

    - HOST-Record auf die IP des ADFS-Proxy

    - CNAME-Records auf (auth, dev, adfs, CRM-Organisation) auf den zuvor konfigurierten HOST-Record

    Des Weiteren muss die HOSTS-Datei des ADFS-Proxy angepasst werden. Denn dieser muss die bereits im öffentlichen DNS eingetragenen Namen auf die internen IP-Adressen auflösen können. Diese müssen wie folgt aussehen:

    - auth, dev und CRM-Organisation --> CRM-Server

    - adfs --> ADFS-Server

    Und das war es auch schon.. Somit steht euch nun eine CRM-Umgebung zur Verfügung, die unter einer andere Domäne läuft, als die eigentliche AD-Domäne. CRM und das komplette AD kann so bestehen bleiben und muss nicht neu installiert werden. Lediglich die ADFS-Rolle und die Anspruchsbasierte Authentifizierung.

    Grüße danielpi

    Sonntag, 18. Januar 2015 10:48