Når man installerer Microsoft Dynamics CRM 4.0, vil der blive oprettet fem sikkerhedsgrupper i Active Directory. I version 3.0 blev der kun oprettet fire grupper. Gruppen PrivReportingGroup er den nye gruppe som oprettes i 4.0.

Under installationen af MS CRM kan man angive et navn på en gruppe (nærmere en container), hvor i sikkerhedsgrupperne samt AD-brugere bliver placeret, se illustration herunder.

De fem sikkerhedsgrupper bliver, og skal være, placeret i samme Organisation Unit (OU) i Active Directory.

Forklaring på sikkerhedsgrupperne

Sikkerhedsgrupperne er disse, og med følgende formål.

Gruppe	Beskrivelse
PrivReportingGroup	MS CRM-brugergruppe med rettigheder til at udføre rapporteringsfunktioner. Denne gruppe oprettes under installationen af MS CRM Server og konfigureres under installationen af MS CRM-tilslutning til SQL Server Reporting Services.
PrivUserGroup	MS CRM-brugergruppe med rettigheder til at udføre specielle administrative funktioner, herunder kørsel af CRMAppPool-identitet (domænebruger eller NetworkService). De brugere, der konfigurerer MS CRM Server, skal føjes til denne gruppe.
SQLAccessGroup	Alle serverprocesser/tjenestekonti, der kræver adgang til SQL Server, herunder CRMAppPool-identitet (domænebruger eller NetworkService).
ReportingGroup	Alle MS CRM-brugere er medtaget i denne gruppe. Denne gruppe opdateres automatisk, efterhånden som brugere føjes til og fjernes fra MS CRM. I alle MS CRM Reporting Services-rapporter tildeles som standard tilladelsen Gennemse til denne gruppe.
UserGroup	Alle MS CRM-brugere er medtaget i denne gruppe. Denne gruppe opdateres automatisk, efterhånden som brugere føjes til og fjernes fra MS CRM.

I praksis kan det tage sig sådan ud:

I denne installation er der oprettet en container med navnet Microsoft CRM. Denne gruppe indeholder såvel AD-brugere som sikkerhedsgrupperne.

BEMÆRK! De almindelige AD-brugere vil ofte være placeret i containeren Users, men er altså flyttet over i containeren Microsoft CRM under installationen af MS CRM. Dette skal man være opmærksom på, især hvis man har applikationer som ikke kan håndtere dette.

Lad os kigge nærmere på de forskellige sikkerhedsgrupper, men lige lidt om Group scope først.

Group scope kan indstilles for alle sikkerhedsgrupperne, og har følgende betydning:

• Domain local: Denne indstilling kan kun anvendes når der er tale om et enkelt domæne, altså hvor der kun er en domain controller. I relation til MS CRM vil man ofte anvende denne indstilling hvis domain controller'en er på en maskine og MS CRM er på en anden maskine.
• Global: Denne indstilling er tilgængelig hvis der eksisterer et domain tree, og hvor der ofte er flere domain controllers. I relation til MS CRM vil man ofte anvende denne indstilling hvis der skal gives adgang til andre maskiner i et globalt domain tree, f.eks. andre selvstændige domain controllers. Men dog kun controllers som indgår som child domains i forhold til den aktuelle domain controller (altså dens egne childs).
• Universal: Denne indstilling er tilgængelig hvis der eksisterer et domain tree, og hvor der ofte er flere domain controllers. I relation til MS CRM vil man ofte anvende denne indstilling hvis der skal gives adgang til andre maskiner i et globalt domain tree, f.eks. andre selvstændige domain controllers. Der kan gives adgang til alle controllers uanset hvor de befinder sig i domain tree'et.

PrivReportingGroup

Her er et eksempel på sikkerhedsgruppen PrivReportingGroup:

Den maskine (Computer), hvor på Reporting Services er installeret skal være inkluderet som Member af denne sikkerhedsgruppe, i ovenstående tilfælde er det maskinen CRM, som Reporting Services er installeret på. Hvis man installererer Reporting Services på en anden maskine kan man erstatte/tilføje maskinen til denne sikkerhedsgruppe.

Hvis man gør brug af MS CRM Data Connector, skal den maskine hvorpå denne er installeret være medlem af denne sikkerhedsgruppe.

PrivUserGroup

Her er et eksempel på sikkerhedsgruppen PrivUserGroup:

Den maskine (Computer), hvor på de brugere som skal have ret til at lave administrative opgaver i MS CRM, såsom konfiguration, skal være inkluderet som Member af denne sikkerhedsgruppe, i ovenstående tilfælde er det maskinen CRM. De brugere som har adgang til maskinen CRM (som er navnet på maskine i dette eksempel), vil have disse rettigheder.

Den konto som IIS'en bruger til at køre CRMAppPool samt ASP.NET-processer (ofte kontoen NT AUTHORITY\NETWORK SERVICE) skal være medlem af denne gruppe.

Brugere som skal foretage installation eller konfiguration af MS CRM skal være medlem af denne gruppe. De er det ofte automatisk, da de ofte er Administrators eller Domain Admins.

Den computer hvorpå MS CRM-Exchange E-mail Router er installeret på, skal være medlem af denne gruppe.

SQLAccessGroup

Her er et eksempel på sikkerhedsgruppen SQLAccessGroup:

Alle de brugere og services, som skal have adgang til SQL Serveren, skal være medlem af denne sikkerhedsgruppe. Ofte vil Domain Admins og Domain Computers være medlem af denne sikkerhedsgruppe.

Den konto som IIS'en bruger til at køre CRMAppPool samt ASP.NET-processer (ofte kontoen NT AUTHORITY\NETWORK SERVICE) skal være medlem af denne gruppe.

ReportingGroup

Her er et eksempel på sikkerhedsgruppen ReportingGroup:

Alle brugere, som skal have adgang til rapporter (via Reporting Services), skal være medlem af denne gruppe. Ofte er det alle brugerne, som er medlem af denne gruppe.

Brugere som skal foretage installation eller konfiguration af MS CRM skal være medlem af denne gruppe. De er det ofte automatisk, da de ofte er Administrators eller Domain Admins.

UserGroup

Her er et eksempel på sikkerhedsgruppen UserGroup:

Alle brugere som skal have adgang til MS CRM skal være medlem af denne gruppe. Ofte er det alle brugerne, som er medlem af denne gruppe.

Brugere som skal foretage installation eller konfiguration af MS CRM skal være medlem af denne gruppe. De er det ofte automatisk, da de ofte er Administrators eller Domain Admins.

 

Hvornår opstår der problemer med sikkerhedsgrupperne?

Det er ikke så ofte at der opstår problemer med sikkerhedsgrupperne, eller installationen, når der laves en ny installation. MS CRM-installationsprogrammet sørger for at alt oprettes og indstilles korrekt. Man skal dog være opmærksom på, at den som installerer MS CRM, skal havde de fornødne rettigheder (ofte Administrator, Domain Admin eller Local Administrator) ellers kan installationsprogrammet fejle, da det ikke har lov til at oprette og indstille grupperne.

Ved opgraderinger af MS CRM kan der opstå en række problemer.

Ofte handler det om at grupperne ikke er tilgængelige i den container, som MS CRM "kigger" i under opgraderingen. Er dette tilfældet så flyt sikkerhedsgrupperne over i den container MS CRM kigger i.

Nogle gange eksisterer sikkerhedsgrupperne ikke i SQL Serveren, hvilket tre af dem skal, se herunder. Hvis dette ikke er tilfældet så skal de oprettes.

Som udgangspunkt kan man indstille alle tre grupper til at have adgang til såvel Reporting Server-databasen, <organisation>_MSCRM som MSCRM_CONFIG. Det kompromiterer ikke sikkerheden at lave disse indstillinger.