Dynamics CRM / Dynamics 365 CE (IFD)

Uppsättning

Rekommendation: wildcard-certifikat validerat via DNS

CRM med IFD nås på flera namn i samma domän: ett per organisation (contoso.crm.example.se), auth. för inloggning, dev. för discovery och den interna adressen för anspråksbaserad inloggning (till exempel internal.crm.example.se). Varje ny organisation ger ett nytt namn. Ett wildcard-certifikat, *.crm.example.se, täcker alla, även de som tillkommer senare. Ett wildcard kan bara valideras via DNS (DNS-01), så konfigurera domänen för FairSSL AutoDNS eller förhandsvalidera den innan du börjar.

Steg 1: Ladda ner och installera simple-acme-klienten

Ladda ner FairSSL-versionen av simple-acme och packa upp den i C:\simple-acme på CRM-servern (servern som kör CRM-webbplatsen). Den är förkonfigurerad med rätt ACME-server och förnyelseinställningar, så det finns inget att redigera.

FairSSL-versionen innehåller även ett litet notifieringsskript som rapporterar resultatet av varje förnyelse och installation (domän, certifikatets tumavtryck, servernamn samt detaljer om lyckat resultat eller fel) tillbaka till FairSSL, så att du kan övervaka dina certifikat och få varningar i kontrollpanelen. Det skickar aldrig privata nycklar eller certifikat. Se fairssl-readme.txt i nedladdningen för den fullständiga fältlistan och hur du stänger av det.

Steg 2: Förbered din miljö

• Beställ wildcardet för den domän dina CRM-adresser ligger i, till exempel *.crm.example.se. Det måste täcka alla värdnamn i CRM-webbplatsens https-bindningar och den interna adressen. Ligger ett namn utanför wildcardet, lägg till det med kommatecken i värdlistan.
• Logga in på CRM-servern som CRM Deployment Administrator (till exempel kontot som installerade CRM) och öppna ett PowerShell-fönster som administratör i C:\simple-acme. Första körningen byter oftast certifikatets subject, och bara en Deployment Administrator kan ge CRM det nya (ClaimsSettings). Förnyelser behåller subject och körs automatiskt som SYSTEM.
• Planera avbrott: skriptet startar om IIS (iisreset) vid första körningen och vid varje förnyelse. Förnyelser körs som standard på natten.

Steg 3: Installera certifikatet i CRM

Kör detta kommando i PowerShell som administratör. Det beställer certifikatet med en RSA-nyckel och lägger det i Windows certifikatarkiv. Därefter ger ImportDynamicsCRM.v1.ps1 CRMAppPool-kontot läsbehörighet till den privata nyckeln, sätter krypteringscertifikatet för anspråk om subject har ändrats, flyttar alla https-bindningar på CRM-webbplatsen till certifikatet, arkiverar det föregående certifikatet med samma subject (CRM hittar inte certifikatet vid duplicerat subject), kör iisreset och väntar tills CRM publicerar det nya certifikatet i sina federation metadata. Körs AD FS på samma server uppdaterar skriptet även CRM:s relying party trusts.

.\wacs.exe `
  --verbose `
  --baseuri "https://fairssl.dk/acme" `
  --eab-key-identifier DIN_EAB_KID `
  --eab-key DIN_EAB_HMAC `
  --accepttos `
  --source manual `
  --host "*.crm.exempel.se" `
  --csr rsa `
  --certificatestore My `
  --validation none `
  --installation script `
  --script ".\Scripts\ImportDynamicsCRM.v1.ps1" `
  --scriptparameters "'{CertThumbprint}'" `
  --friendlyname "fairssl-acme-*.crm.exempel.se"

Steg 4: AD FS på en annan server

AD FS krypterar varje inloggning till CRM:s certifikat. Tills AD FS har läst det nya från CRM:s federation metadata misslyckas både intern och extern inloggning. På sin egen server gör AD FS det vid nästa metadatakontroll, som standard var 24:e timme. Kör detta en gång på AD FS-servern så att den kontrollerar var 15:e minut i stället (CRM:s relying party trusts måste ha övervakning och automatisk uppdatering påslagna, vilket är standard när de skapats från CRM:s metadataadress):

Set-AdfsProperties -MonitoringInterval 15

Uppdatera AD FS direkt

Kör detta på AD FS-servern direkt efter en förnyelse. Det uppdaterar alla relying party trusts som läser federation metadata, däribland CRM:s. Skriptet skriver samma kommando med det föregående tumavtrycket i sin logg när AD FS inte körs på CRM-servern.

Get-AdfsRelyingPartyTrust | Where-Object { $_.MetadataUrl -like '*/FederationMetadata/2007-06/FederationMetadata.xml' } | ForEach-Object { Update-AdfsRelyingPartyTrust -TargetName $_.Name }

Certifikat på AD FS och Web Application Proxy

Skriptet ändrar bara CRM och CRM:s relying party trusts. AD FS eget TLS-certifikat och en Web Application Proxy framför IFD förnyas med FairSSL-guiderna Microsoft Active Directory Federation Services och Microsoft Web Application Proxy (ImportADFS-WAP.v1.ps1). Körs AD FS på CRM-servern, ge AD FS-förnyelsen ett eget namn, till exempel sts.crm.example.se, inte CRM-wildcardet: två certifikat med samma subject på en server stoppar inloggningen i CRM.

Se guiden för AD FS och Web Application Proxy.

Steg 5: Kontrollera

Logga in i CRM både på den interna adressen och utifrån på organisationens adress. Loggen från simple-acme slutar med SUCCESS: Dynamics CRM certificate ... installed.

Om en förnyelse misslyckas

Misslyckas ett steg sätter skriptet tillbaka CRM på det föregående certifikatet (bindningar, ClaimsSettings, arkivering, iisreset), avslutar med ett fel och skriver orsaken i loggen från simple-acme. CRM fortsätter på det föregående certifikatet. simple-acme 2.4 registrerar ändå förnyelsen som klar, så den försöker inte igen av sig själv och rapporten till FairSSL säger att den lyckades: läs loggen, åtgärda orsaken och kör .\wacs.exe --renew --force. En förnyelse med nytt subject stoppar med Only a CRM Deployment Administrator can change that: kör .\wacs.exe --renew --force en gång som Deployment Administrator, som i steg 2.

Privat nyckel i en CSP

CRM använder bara ett certifikat vars privata nyckel ligger i det äldre CryptoAPI (CSP), och det är så simple-acme sparar nycklar som standard. En nyckel i en CNG key storage provider avvisas innan något ändras. Ta i så fall bort "UseNextGenerationCryptoApi": true från settings.json och förnya igen.