Dynamics CRM / Dynamics 365 CE (IFD)

Opsætning

Anbefaling: wildcard-certifikat valideret via DNS

CRM med IFD bruger flere navne i samme domæne: ét pr. organisation (contoso.crm.example.dk), auth. til login, dev. til discovery og den interne adresse til claims-login (f.eks. internal.crm.example.dk). Hver ny organisation giver et nyt navn. Et wildcard-certifikat, *.crm.example.dk, dækker dem alle, også dem der kommer senere. Et wildcard kan kun valideres via DNS (DNS-01), så sæt domænet op til FairSSL AutoDNS eller forhåndsvalidér det, inden du går i gang.

Trin 1: Download og installer simple-acme-klienten

Download FairSSL-udgaven af simple-acme, og pak den ud i C:\simple-acme på CRM-serveren (den server, der kører CRM-websitet). Den er forudkonfigureret med den korrekte ACME-server og fornyelsesindstillinger, så der er intet at redigere.

FairSSL-udgaven indeholder desuden et lille notifikationsscript, der melder resultatet af hver fornyelse og installation (domæne, certifikat-thumbprint, servernavn samt succes- eller fejldetaljer) tilbage til FairSSL, så du kan overvåge dine certifikater og få advarsler i kontrolpanelet. Det sender aldrig private nøgler eller certifikater. Se fairssl-readme.txt i download-pakken for den fulde feltliste, og hvordan det slås fra.

Trin 2: Forbered dit miljø

• Bestil wildcardet til det domæne, dine CRM-adresser ligger i, f.eks. *.crm.example.dk. Det skal dække alle hostnavne i CRM-websitets https-bindinger og den interne adresse. Ligger et navn uden for wildcardet, så tilføj det med komma i host-listen.
• Log på CRM-serveren som CRM Deployment Administrator (f.eks. kontoen, der installerede CRM), og åbn et PowerShell-vindue startet som administrator i C:\simple-acme. Første kørsel skifter som regel certifikatets subject, og kun en Deployment Administrator kan give CRM det nye (ClaimsSettings). Fornyelser beholder subject og kører af sig selv som SYSTEM.
• Planlæg nedetid: scriptet genstarter IIS (iisreset) ved første kørsel og ved hver fornyelse. Fornyelser kører som standard om natten.

Trin 3: Installer certifikatet i CRM

Kør denne kommando i PowerShell som administrator. Den bestiller certifikatet med en RSA-nøgle og lægger det i Windows Certificate Store. Derefter giver ImportDynamicsCRM.v1.ps1 CRMAppPool-kontoen læseadgang til den private nøgle, sætter claims-krypteringscertifikatet, hvis subject er ændret, flytter alle https-bindinger på CRM-websitet til certifikatet, arkiverer det forrige certifikat med samme subject (CRM kan ikke finde certifikatet ved dubleret subject), kører iisreset og venter, til CRM udgiver det nye certifikat i sine federation metadata. Kører AD FS på samme server, opdaterer scriptet også 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.eksempel.dk" `
  --csr rsa `
  --certificatestore My `
  --validation none `
  --installation script `
  --script ".\Scripts\ImportDynamicsCRM.v1.ps1" `
  --scriptparameters "'{CertThumbprint}'" `
  --friendlyname "fairssl-acme-*.crm.eksempel.dk"

Trin 4: AD FS på en anden server

AD FS krypterer hvert login til CRM's certifikat. Indtil AD FS har læst det nye fra CRM's federation metadata, fejler både internt og eksternt login. På sin egen server gør AD FS det ved næste metadata-tjek, som standard hver 24. time. Kør dette én gang på AD FS-serveren, så den tjekker hvert 15. minut i stedet (CRM's relying party trusts skal have overvågning og automatisk opdatering slået til, hvilket er standard, når de er oprettet fra CRM's metadata-adresse):

Set-AdfsProperties -MonitoringInterval 15

Opdatér AD FS med det samme

Kør dette på AD FS-serveren lige efter en fornyelse. Det opdaterer alle relying party trusts, der læser federation metadata, heriblandt CRM's. Scriptet skriver samme kommando med det forrige thumbprint i sin log, når AD FS ikke kører på CRM-serveren.

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

Certifikater på AD FS og Web Application Proxy

Scriptet ændrer kun CRM og CRM's relying party trusts. AD FS' eget TLS-certifikat og en Web Application Proxy foran IFD fornyes med FairSSL-vejledningerne Microsoft Active Directory Federation Services og Microsoft Web Application Proxy (ImportADFS-WAP.v1.ps1). Kører AD FS på CRM-serveren, så giv AD FS' fornyelse sit eget navn, f.eks. sts.crm.example.dk, og ikke CRM-wildcardet: to certifikater med samme subject på én server stopper CRM's login.

Se vejledningen til AD FS og Web Application Proxy.

Trin 5: Kontrollér

Log på CRM både på den interne adresse og udefra på organisationens adresse. Loggen fra simple-acme slutter med SUCCESS: Dynamics CRM certificate ... installed.

Hvis en fornyelse fejler

Fejler et trin, sætter scriptet CRM tilbage på det forrige certifikat (bindinger, ClaimsSettings, arkivering, iisreset), afslutter med en fejl og skriver årsagen i loggen fra simple-acme. CRM kører videre på det forrige certifikat. simple-acme 2.4 registrerer alligevel fornyelsen som gennemført, så den prøver ikke igen af sig selv, og dens melding til FairSSL siger succes: læs loggen, ret årsagen, og kør .\wacs.exe --renew --force. En fornyelse med nyt subject stopper med Only a CRM Deployment Administrator can change that: kør .\wacs.exe --renew --force én gang som Deployment Administrator, som i trin 2.

Privat nøgle i en CSP

CRM bruger kun et certifikat, hvis private nøgle ligger i det gamle CryptoAPI (CSP), og sådan gemmer simple-acme nøgler som standard. En nøgle i en CNG key storage provider afvises, før noget ændres. Fjern i så fald "UseNextGenerationCryptoApi": true fra settings.json, og forny igen.